[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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