[ppml] IPv6 flawed?

On Wed, Sep 05, 2007 at 06:30:22PM -0700, David Conrad wrote:
> Since IPv6 uses the same  
> routing and traffic engineering technology as IPv4, I am curious what  
> constraints could be put in place to keep PI space down to about 1  
> per ASN.  Particularly given PI allocation policies either have been  
> or are being liberalized in all the RIRs (for sound economic and  
> business reasons, at least from the perspective of the Internet end  
> users).

I don't understand why you single out PI holders in this.  I'm
wondering how many ASNs now advertise more than 2 PI prefixes...I know
that the six ASNs I have some control over have single PI chunks
assigned to them.  I have an association with another org that has two
PI announcements from a single AS, primarily because one of them is
from the class C swamp.

I suspect that PA holders are just as guilty of deaggregation.  Outside
of TE or simple sloppiness, there's been a lot of business activity
that leads to a lot of mergers and associated extra announcements.

Finally, there's all of the PA space that's getting used for
multi-homing.  From a routing point of view, that's exactly the same as
PI space - it's some smallish chunk in the middle of some other block
that's still attached to a single ASN (and different from the parent
chunk).

I'm sorry, but I don't see how PI space (when used responsibly) is a
culprit in the growth of the routing table any more than PA space.  The
real culprit is multi-homing and TE.  Clearly, we should just forbid
that.  (Yeah, right.)

As a network operator, I entirely agree that the problem is going to
come to a head at some point, and things are going to break.  What
things break and how remains to be seen...but something has got to
change.

Personally, I suspect we're going to see more and more long IPv4
prefixes in the DFZ.  I don't think it's up to ARIN or the other RIRs
to figure out how that will work.  I do think it's up to ARIN to hand
out space in a sensible manner, possibly including longer prefix PI and
PA space.  The routing community is going to have to figure out how to
either:

a) scale the routing system appropriately, or

b) figure out how to value a specific prefix.

For the latter, consider if windowsupdate.microsoft.com was a single
VIP or set of VIPs that resides in a /29.  As an ISP, would you route
that /29?  You bet you would...or you'd lose customers to the guy that
is.  How do you differentiate the value of that /29 versus some random
/29 that appears in the routing system for something of much lesser
value?  I haven't the faintest idea on that.  If I did, I'd quit may
day job and start consulting full-time.

Anyway, now that I've ranted on this topic space a bit, I'm hoping
someone can provide some numbers to show that PI space is more
responsible than PA space for the deaggregation noted in the posts in
this thread.  I really don't see it as any different.

-David