as numbers

Sun Jul 31 05:12:31 UTC 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