[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] Consequences of no renumbering...
hi marcelo, all
> -----Original Message-----
> From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf
> Of marcelo bagnulo braun
> Sent: Thursday, September 11, 2008 2:27 PM
> To: tony.li@tony.li
> Cc: rrg@psg.com
> Subject: Re: [RRG] Consequences of no renumbering...
>
> Hi Tony,
>
> One question that i think someone asked but wasn't really captured in
> the consensus call is whether we are requiring no EID
> renumbering or no
> locator renumbering or both.
>
> No EID renumbering seems feasible, you can run LISP, HIP, Six/One,
> transport based solutions or some forms of shim6 based on
> ULAs and with
> some hacks you may get there imho . However, i guess that if we are
> looking to avoid renumbering pain, it won't be enough and you
> will also need to avoid locaotr renumbering.
> If that is the case, then ou run out of options very fast.
> Translation as you suggest also impose renumbering at least the
> addresses of the translation devices and probably the ACLs of these
> devices will also be locator based so, it is not clear to me how much
> renumbering pain can be avoided.
>
> It may well be that you need to start looking into a completelly
> different direction, like Kriukov et al. compact routing schemes, or
> other forms of flat routing. That would probably provide no
> renumbering
> at all, but seems a significant shift from current internet.
it may be suitable to start investigate the compact routing direction. indeed since so far, in any of the proposed approaches, the routing protocols themselves (being all stretch-1 shortest path based) can not scale better than nlogn.
thanks,
-d.
> Regards, marcelo
>
>
> Tony Li escribió:
> > Hi all,
> >
> > So in thinking more about our recent consensus on
> renumbering, it seems to
> > me that this helps us prune the solution tree a bit. In particular:
> >
> > - For the entire class of 'transport' solutions that we've
> discussed, it
> > seems like renumbering would always be required for these
> solutions. All of
> > the obvious transport protocol changes would utilize
> multiple PA addresses,
> > and since changing PA addresses would result in a
> renumbering event, it
> > seems like these solutions should be avoided.
> >
> > - For the map-and-encap solutions, there seems like a
> similar issue. If we
> > look at the current LISP transition plan, there is
> currently a requirement
> > for sites to renumber once to get into an aggregateable EID space.
> >
> > If renumbering is not required, then EID space doesn't
> aggregate. If
> > transition boxes (PTRs) advertised EID space into legacy
> routing, then it
> > would imply that there wouldn't be any reduction in prefix
> count until
> > transition was wholly complete. That doesn't seem very practical.
> >
> > I'm not ready to say that there aren't transition schemes
> that could get
> > around this, but these are the issues that I'm seeing.
> >
> > Comments?
> >
> > Nomex on,
> > Tony
> >
> >
> > --
> > 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