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