On 28/Feb/15 08:07, David Farmer wrote: > If IPv6 PI allocations gets too liberal, the routing system as we know it > will implode long before we allocate 4.2 billion ASNs. Restricting the > number of ASNs in use in the routing system isn't really going to help that > much. The total number of prefixes, PA or PI, has been the primary limiting > factor historically. Limiting the portability of PI prefixes by not > allocating ASNs won't save the routing system. Only ensuring that the growth > in the number of prefixes, both PA and PI, is sustainable and doesn't exceed > the growth in the prefix limit for the typical router in use in the Internet > at any point in time will keep the current routing system going.
My lack of support of being willy-nilly with ASN allocations has nothing to do with the state (or decline) of routing system. It's not IP addresses' or ASN's fault that the community de-aggregates the way it does. So while this is a valid concern, it does not take away from the fact that ASN's are finite, and IMHO, should not be allocated linearly with PI space "just because". If there is policy that supports linear allocation between PI and ASN resources that makes sense, I'm more than happy to support such policy. As of now, there isn't such policy, and without such policy, current policy is good enough. > > We need a new kind of routing system, we've known that for a while. But that > is not a policy issues for the RIRs, that is a technology issues for the IETF > and the IRTF. I think things like LISP and ILNP are promising in the long > run. We just have to keep the current routing system going until those > technologies can prove themselves. We do that by keeping total prefix growth > sustainable, not by limiting portability of PI prefixes. This ties back to what I was saying about, in general, getting the RIR and operational community to develop policies, together, which track practical day-to-day experiences about running IP networks. But that is a discussion for another thread, or as we shall experiment, which operators get involved in the policy development process. Mark. * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
