> 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 <[EMAIL PROTECTED]> wrote: > From: Peter Sherbin <[EMAIL PROTECTED]> > Subject: Re: [RRG] Renumbering... > To: "Dino Farinacci" <[EMAIL PROTECTED]> > Cc: [email protected], [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > wrote: > > > From: Dino Farinacci <[EMAIL PROTECTED]> > > Subject: Re: [RRG] Renumbering... > > To: [EMAIL PROTECTED] > > Cc: [email protected], [EMAIL PROTECTED] > > 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 > > <[EMAIL PROTECTED]> wrote: > > > > > >> From: Dino Farinacci <[EMAIL PROTECTED]> > > >> Subject: Re: [RRG] Renumbering... > > >> To: [EMAIL PROTECTED] > > >> Cc: [email protected], [EMAIL PROTECTED] > > >> 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 > > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
