Re: [RRG] Consequences of no renumbering...

[Stephen Sprunk <stephen@sprunk.org>]

Tony Li wrote:
> 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.
>   

I agree.  I don't see any way that would work, though I'm open to 
suggestions if anyone has one.

However, I have some disagreement about some hidden assumptions you 
appear to be making below:

> - 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.
>   

First of all, this problem only applies to sites that _already_ have PI 
space.  One of my goals here is to make multihoming achievable for 
orders of magnitude more sites which currently do not qualify for PI 
space (even with the low bar that has been set).  I discount the first 
renumbering from PA to EID space because they would _also_ have to 
renumber from PA to PI space if the latter were available to them.

Second, in v6, most sites that qualify still have not requested a PI 
prefix yet -- just a few hundred so far out of tens of thousands.  The 
sooner we finish, and PI is replaced with EID, the fewer sites that 
would theoretically have to renumber (unless you count moving from v4 to 
v6 as "renumbering").

> 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.
>   

In v6, all existing PI space is in five clearly marked blocks (one per 
RIR).  All it takes to convert the entirety of PIv6 to EID space is a 
redesignation by the IETF, IANA, and/or RIRs and getting those folks (or 
their upstreams) to implement ETRs.  I would prefer that IANA be 
directed to issue a new top-level prefix so that all new EIDs can be 
aggregated into a single route, but that's an optimization for the future.

Lack of aggregation is a serious problem in v4, however.  The vast 
majority of PIv4 space is legacy.  It's also out of a dozen or so 
well-known /8s, and AFAIK there has not been any non-legacy PA 
assignment in those blocks to date.  It's theoretically possible to 
aggregate those /8s into EID prefixes and let non-participating sites 
punch out more-specifics.  It's certainly possible to have the IETF 
direct IANA and the RIRs to not make any more PA assignments in those 
/8s, to reuse any empty space in the existing /8s for new PI 
assignments, and to not mix PI and PA in any /8s allocated to them in 
the future.  (That directive, I think we'd listen to; it's only the 
total ban on PIv6 that we felt justified in ignoring.)

S

--
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