Criteria for initial PA Allocation
Jorma Mellin jorma.mellin at teliafi.net
Tue May 22 15:43:54 CEST 2001
> One should keep in mind this number is also limited, on cisco routers AS > number is two byte unsigned integer thus we can have max 65536 ASes. > Conclusion: BGP "address space" (ASes) is even easier to exhaust than > IPv4 address space. Of course one can always request IOS modification, > but it will also require change in BGP specification. Taking into account > scale of change and resulting growth of routing tables it won't be easy. yes, I do agree that we run out of ASN's before IPv4 addresses. The problem doesn't get fixed by IOS update, because there do exists also other vendor boxes out there and therefore we need a RFC update (what is coming if I remember correctly). > LIRs provide internet connectivity and assign IP addresses > to end customers. The problem here is that organisations that want portable address space do not necessarily want to be a LIR, nor do they have any end-users, or customers. The system is forcing them to apply a LIR status anyway and if they are not willing to take the risk with PI space they end up having a /20 from PA space at least. Maybe this dilemma can be solved by adjusting the rules a bit. Although much can be done by BGP parameters I do admit that there can be huge problems with it. Another problem with highly advanced BGP configs is the case-by-case planning they require, and general rules or guidelines are difficult to give. What if we modify the rule stating that only one origin-AS for a route-obj can exist in the db? And add that more-spesifics are allowed as valid route-objects as long as they are part of portable address space. This gives us another problem, how do we tell what is portable NLRI and what is not. Maybe we need an additional status -id, PO = allocated portable, and something to tag the NLRI at routers (so that we can filter it, trigger it, and so on). If this would work we could assign portable space a short as we want (and save address space), and aggregate it efficiently to keep the routing table growth at minimum. Jorma
[ lir-wg Archives ]