Hank, At 09:13 29/07/2005, Hank Nussbacher wrote:

"Of the 32,557 assigned AS numbers, some 19,859 are advertised, while 12,698 have been allocated in the past, but are not currently advertised in the BGP routing table."

I would have liked to see how well the RIRs are at recovering unused ASNs, if at all. For example ARIN has a 30 day policy: http://www.arin.net/registration/templates/asn-request.txt

Do the RIRs *ever* revoke an ASN after the customer does not follow the RIR stated rules? Would love to see numbers on that issue. No wonder the ASN pool will expire in 2010.

I'd think that 30 days is too low. What we see (*) is that after 30 days, only half of the assigned ASN have appeared on the Internet. Some 75% of the assigned ASN appear on the net in the first 6 months after assignment, 80-85% after a year. Anything not seen after a year (15-20%), is unlikely to ever appear, these can be recovered (at least in theory). While this looks like a lot, it does not really solve any problem. Geoff's numbers show that the pool will expire in 5 years. Our estimate is a little bit longer, but not that much. 2010-2005 is 5 years, if the trend that 20% never appears continues and all these ASN are revoked, this simply means that the pool will expire in 6 years. 2010 or 2011 hardly makes a difference. Henk * Some of our research was presented by Rene Wilhelm @ RIPE50 last May, http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-mon-a..., we have some additional results. We are working on a write-up of all our results, stay tuned. ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine)

...

While this looks like a lot, it does not really solve any problem. Geoff's numbers show that the pool will expire in 5 years. Our estimate is a When discussed a few years back, I was told that this was already solved by 32bit AS numbers (ASxxxxx:xxxxx).

you may want to read the referenced article <http://www.potaroo.net/ispcol/2005-08/as.html> randy

The article states it's not fixed.

that seems to agree with at least one of my routers rtr42#conf t Enter configuration commands, one per line. End with CNTL/Z. rtr42(config)#router bgp 0:3130 ^ % Invalid input detected at '^' marker. my point was that the roll-out geoff suggests may be more conservative than needed. depends on how long the ivtf takes to specify and how long the vendors take to implement. randy

On 29.07 09:59, Henk Uijterwaal wrote:

I'd think that 30 days is too low. What we see (*) is that after 30 days, only half of the assigned ASN have appeared on the Internet. Some 75% of the assigned ASN appear on the net in the first 6 months after assignment, 80-85% after a year. Anything not seen after a year (15-20%), is unlikely to ever appear, these can be recovered (at least in theory).

While this looks like a lot, it does not really solve any problem. Geoff's numbers show that the pool will expire in 5 years. Our estimate is a little bit longer, but not that much. 2010-2005 is 5 years, if the trend that 20% never appears continues and all these ASN are revoked, this simply means that the pool will expire in 6 years. 2010 or 2011 hardly makes a difference.

Henk hits the nail on the head. And reclamation is not straightforward: The RIPE NCC has hit strong resistance to reclamation, most often with the argument that the ASes are used in inter-domain routing on the Internet but our BGP data collectors just do not see the paths concerned. It takes considerable effort to do reclamation properly whithout putting the future user of any reclaimed number space at risk! Also: I think we should all be very concerned about this. As with all such projections, Geoff's are valid only for an unchanged consumtion pattern. If I was running a network I would start to ask my vendors serious questions and start to prepare deployment scenarios. Daniel

On 30 Jul 2005, at 15:03, Hank Nussbacher wrote:

On Sat, 30 Jul 2005, Daniel Karrenberg wrote:

...

The RIPE NCC has hit strong resistance to reclamation, most often with the argument that the ASes are used in inter-domain routing on the Internet but our BGP data collectors just do not see the paths concerned. It takes considerable effort to do reclamation properly whithout putting the future user of any reclaimed number space at risk!

Anyone who uses the argument of inter-domain routing that are not seen by any data collectors on the Internet should be pointed at RFC1930 and told to renumber their private ASNs.

Just because public route collectors can't see use of an ASN, that doesn't mean the ASN isn't in use; just because it can't be seen doesn't mean it's private-use: it might still feature on routes announced on the Internet, even if the routes don't propagate globally. For a trivial example of this, consider a multilat route server at an exchange point. Unless you measure from within (or downstream of) a peer of the route server, you'll never see the AS number in an AS_PATH attribute. It's fairly clear to me that this is not a suitable candidate for private-use numbering, however. Joe

At 05:13 PM 30/07/2005, Daniel Karrenberg wrote:

Henk hits the nail on the head. And reclamation is not straightforward:

The RIPE NCC has hit strong resistance to reclamation, most often with the argument that the ASes are used in inter-domain routing on the Internet but our BGP data collectors just do not see the paths concerned. It takes considerable effort to do reclamation properly whithout putting the future user of any reclaimed number space at risk!

Also: I think we should all be very concerned about this. As with all such projections, Geoff's are valid only for an unchanged consumtion pattern. If I was running a network I would start to ask my vendors serious questions and start to prepare deployment scenarios.

The trends --within the current figures-- appear to indicate that the first >0:xxxxx AS number will be issued no later than 2010, and more likely to be sometime in 2009. The write-up referenced by Randy at the start of the thread shows the underlying basis of this predictive exercise, and illustrates the nature of the non-linear drivers behind AS number consumption. (http://www.potaroo.net/ispcol/2005-08/as.html) When reviewing the 4-byte AS draft on this I sensed that the authors were skeptical that all AS's would be running an upgraded BGP version that had the 4-byte capabilities at any particular time, and for that reason devised the mechanisms for the upgraded BGP speakers on a 4-byte / 2-byte boundary to package up the 4-byte AS path information in a special attribute that is opaque to the 2-byte BGP speaker and unwrap it at corresponding 2-byte -> 4-byte transition. This approach appears to be robust to me, on the basis that we can take the additional memory hit of having some additional 12Mb or so in each ADJ-RIB within the 2-byte world, and then do not have to pull the entire inter-domain routing world into a coordinated software upgrade. I have looked at reclamation - the basic observation is that old AS's do gradually disappear off the network, and the longer the time period since the original allocation the more likely it is that the AS has disappeared (the relationship appears to be close to directly proportional). But reclamation will buy you some further time, but not an indefinite future. And here, unlike the v4 / v6 transition, there is no _need_ for the existing 2-byte AS to change any time soone - they can still exist in a mixed 2 / 4 byte AS world (the only change that may have some minor impact is the issue of embedding AS numbers in BGP communities, in which case support for extended communities is necessary. So it appears to me that the 'piecemeal' transition will work well, and the big milestone right now is to convince BGP providers, such as Open BGP, Zebra, Cisco, Juniper, etc to produce 4-byte versions of their BGP implementations right _now_ that supports all the functionality as described in the 4-byte AS draft. Last time I raised this matter with a large vendor I received the response (paraphrased) "Our customers have not said they want this, so we will not be doing anything until our customers say that they need this added to our BGP implementation." This kind of response does have a certain market-based logic to it, I must admit, but its highly risky. I don't think its all that wise for this to be delayed indefinitely until the point at which its turning from an orderly transition into a last second panic, and I don't think that many customers will place this high on their vendor support priority list until they are actually allocated a 4-byte AS number because the 2-byte pool has been exhausted. . So - to NANOG at large - if you want your vendor to include 4-Byte AS support in their BGP code anytime soon, in order to avoid some last minute panic in a couple of years hence, then it would appear that you should talk to them now and say clearly that you want 4-Byte AS support in your BGP software right now. regards, Geoff

On 1 Aug 2005, at 06:15, Stephen J. Wilcox wrote:

On Sun, 31 Jul 2005, Geoff Huston wrote:

...

So - to NANOG at large - if you want your vendor to include 4-Byte AS support in their BGP code anytime soon, in order to avoid some last minute panic in a couple of years hence, then it would appear that you should talk to them now and say clearly that you want 4-Byte AS support in your BGP software right now.

Geoff, excellent idea..

before I forward this email to my suppliers tho, is there a reference I can send.. excuse my ignorance but I'm not familiar with research done on 4-byte ASNs, is there a proposed standard implementation?

If I have something definite to request I will immediately send those emails,

draft-ietf-idr-as4bytes-10 seems to be the document to point them at. http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-10.txt Joe