geoff has a quite good article on antonymous systems, usage, ... at
<http://www.potaroo.net/ispcol/2005-08/as.html>.
randy
geoff has a quite good article on antonymous systems, usage, ... at
<http://www.potaroo.net/ispcol/2005-08/as.html>.
geoff,
why not assume
o all speakers will not transition at the same time, but
o before the first > 0:xxxx is issued/used that all will
transition?
i would think this is operationally viable.
randy
Geoff,
"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.
-Hank
Hank,
"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.txtDo 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-asmia.pdf, we have some additional results. We are working on a write-up
of all our results, stay tuned.
When discussed a few years back, I was told that this was already solved by 32bit AS numbers (ASxxxxx:xxxxx).
Has anything changed?
Henk Uijterwaal wrote:
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.
Also consider that there will be likely a clearance sale rush, so I
expect, unless there is a practical solution, the pool will expire even
earlier, 2008 or 2009.
Fredy
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 aWhen 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. I guess what I was told back then was false, considering <http://en.wikipedia.org/wiki/Autonomous_system_(Internet)> states:
"While there is no immediate danger of exhausting the 16-bit AS number space, several factors, principally the need of enterprises to run BGP to multihome, is reason for concern that more space will be needed in the moderate term. As of mid-2005, the IETF has several drafts underway that define mechanisms for the use of an upwardly compatible four-octet, or 32-bit, AS number space. This space will not replace the existing 16-bit space."
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
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
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.
-Hank
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
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
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,
Steve
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
I can see that happening all over the place where external connectivity is pre-dominantly over satellite, or where there is a monopoly in transit services. The ASN are used mainly at the local IXP, where RFC 1930 and private ASN won't be useful, but at the same time external connectivity is default routed to the transit provider. Thus the ASN are not seen in any AS_PATH by any data collector, doesn't mean that they are not being used.
thanks
-- gaurab
/////////////////////////////////////////////////////+9779851038080
gaurab at lahai dot com
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
> 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?
There is a draft draft-ietf-idr-as4bytes-10.txt- it is a draft because under the current
IETF procedures there needs to be 2 independent implementations of the specification,
and at the moment only Redback's BGP has implemented this. Once there is a 2nd
implementation it will enter the Internet Standards track as a Draft Standard.
If I have something definite to request I will immediately send those emails,
http://www.potaroo.net/ispcol/2005-08/as.html
contains the analysis of the AS number consumption data
regards,
Geoff
There is such as thing as "Proposed Standard" ...