North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: as numbers

  • From: Geoff Huston
  • Date: Sun Jul 31 01:13:43 2005

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