Re: [RRG] Renumbering...

[Peter Sherbin <pesherb@yahoo.com>]

> 32-bits prefix, than by default all IDs will have 92 bits.

32-bits prefix suggests 96-bits ID, sorry for the typo


--- On Thu, 8/21/08, Peter Sherbin <pesherb@yahoo.com> wrote:

> From: Peter Sherbin <pesherb@yahoo.com>
> Subject: Re: [RRG] Renumbering...
> To: "Dino Farinacci" <dino@cisco.com>
> Cc: rrg@psg.com, tony.li@tony.li
> Date: Thursday, August 21, 2008, 2:50 PM
> > If you have variable length IDs,
> 
> Just to clarify: I did not mean to suggest variable length
> ID. Any length means not strictly 64 and determined by the
> prefix. E.g. if the earth's hierarchy will be based on
> 32-bits prefix, than by default all IDs will have 92 bits.
> 
> 
> --- On Thu, 8/21/08, Dino Farinacci <dino@cisco.com>
> wrote:
> 
> > From: Dino Farinacci <dino@cisco.com>
> > Subject: Re: [RRG] Renumbering...
> > To: pesherb@yahoo.com
> > Cc: rrg@psg.com, tony.li@tony.li
> > Date: Thursday, August 21, 2008, 12:04 PM
> > >> Why is this useful for the unnecessary
> complication
> > of the
> > >> flexibility?
> > >
> > > For example it allows users flexibility in
> managing
> > their IDs;  
> > > decide what to expose externally vs. internally;
> > create applications  
> > > utilizing the vast pool of permanent unique
> > identifiers; change  
> > > providers, etc.
> > 
> > You are going to hear over and over again that users
> > don't want to  
> > manage anything.
> > 
> > Regarding unique IDs, they should be able to assume
> the IDs
> > are unique  
> > because underlying layers take care of it for them.
> > 
> > Regarding changing providers, with a decent Loc/ID
> split
> > solution, IDs  
> > don't have to change when you change service
> providers.
> > 
> > >> I would think that net admins don't want
> users
> > to have
> > >> this flexibility and why would they care?
> > >
> > > Need a definition of the user, e.g. a large
> enterprise
> > is an end  
> > > user to SP. The enterprise may want the above
> > flexibility. SP on  
> > > their side would focus on capacity and traffic.
> > 
> > If you have variable length IDs, then remote sites
> will
> > have to  
> > capable of parsing the different lengths.
> > 
> > I don't think it's a good idea. We have enough
> fish
> > to fry and this  
> > flexibility is not really providing any real value.
> > 
> > Dino
> > 
> > >
> > >
> > >
> > > --- On Wed, 8/20/08, Dino Farinacci
> > <dino@cisco.com> wrote:
> > >
> > >> From: Dino Farinacci <dino@cisco.com>
> > >> Subject: Re: [RRG] Renumbering...
> > >> To: pesherb@yahoo.com
> > >> Cc: rrg@psg.com, tony.li@tony.li
> > >> Date: Wednesday, August 20, 2008, 6:18 PM
> > >>> ILNP specifically calls for 64-bits ID
> for a
> > node. What
> > >> I was
> > >>> suggesting is a range that can be any
> (64, 86,
> > etc)
> > >> based on the set
> > >>> prefix length.
> > >>> Also end users can put that ID anywhere
> they
> > see fit:
> > >> node,
> > >>> interface, port, application etc. If
> necessary
> > it will
> > >> be an
> > >>> architectural decision to recommend where
> > exactly to
> > >> put the ID.
> > >>
> > >> Why is this useful for the unnecessary
> > complication of the
> > >> flexibility?
> > >>
> > >> I would think that net admins don't want
> users
> > to have
> > >> this
> > >> flexibility and why would they care?
> > >>
> > >> Dino
> > >>
> > >>
> > >> --
> > >> to unsubscribe send a message to
> > rrg-request@psg.com with
> > >> the
> > >> word 'unsubscribe' in a single line
> as the
> > message
> > >> text body.
> > >> archive: <http://psg.com/lists/rrg/>
> &
> > >> ftp://psg.com/pub/lists/rrg
> > >
> > >
> > >
> > 
> > 
> > --
> > to unsubscribe send a message to rrg-request@psg.com
> with
> > the
> > word 'unsubscribe' in a single line as the
> message
> > text body.
> > archive: <http://psg.com/lists/rrg/> &
> > ftp://psg.com/pub/lists/rrg
> 
> 
>       
> 
> --
> to unsubscribe send a message to rrg-request@psg.com with
> the
> word 'unsubscribe' in a single line as the message
> text body.
> archive: <http://psg.com/lists/rrg/> &
> ftp://psg.com/pub/lists/rrg


      

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg