Seems relevant.
Afraid so. I'm hoping to be out of the industry before calls for 128 bit AS#s come down the pipe and people (at that time) are laughing about how silly 32 bit AS#s seem.
Does anyone have a current projection of when AS# (16 bit) exhaust will occur?
Thanks,
Deepak
Marshall Eubanks wrote:
anyone have a swag at the number of things that this (32bit asn) touches?
netflow
bgp (duh!)
provisioning databases/systems
web-pages (really the backend parts like routeviews query/search tools)
yeesh 
Seems relevant.
Any word from vendors on supporting images? I found some old presentations that said Juniper (ERX) and Redback had announced supporting images and Cisco had an unannounced version, but thats all.
http://www.potaroo.net/drafts/draft-huston-idr-as4bytes-survey-00.txt has some relevant info, although that draft is a year or so old now.
Joe
I hope to be long dead before we exhaust >4 billion ASNs. If I'm
still alive then, someone probably transferred my brain into a
positronic neural network, and Earth is long since uninhabitable by
organic life. But I wouldn't doubt if some threads like this are
still running on HSNOG (Hyperspace Network Off-topic Gripes).
Hm. I think I need to get some lunch before the office cafeteria closes.
Joe Abley wrote:
Seems relevant.
Any word from vendors on supporting images? I found some old presentations that said Juniper (ERX) and Redback had announced supporting images and Cisco had an unannounced version, but thats all.
http://www.potaroo.net/drafts/draft-huston-idr-as4bytes-survey-00.txt has some relevant info, although that draft is a year or so old now.
Last time I spoke to them, the Juniper and Cisco versions only ran on
a subset of their routers. Their claim was that almost nobody had
asked for this so it doesn't have any priority.
For those using software routers: there is an unannounced patch for
Quagga that supports this.
Henk
Yes, and it means plenty of work for us all - hurray. But we need to take action to preserve the availability of new AS numbers for new network builders.
RIPE will be accepting requests for 32-bit ASNs from 1/1/07, according to an email to ncc-services two weeks ago. It does not feel too early to start to understand what we must do to as a community to guarantee ubiquity of reachable networks.
There were no definitive answers when John Payne asked on the list about images supporting 32 bit as numbers - are any independent bodies going to setup a route behind a 32-bit ASN so that we can start public reachability testing ?
Andy
Andy Davidson wrote:
RIPE will be accepting requests for 32-bit ASNs from 1/1/07, according to an email to ncc-services two weeks ago.
Actually, all 5 RIRs will accept requests for 32 bit ASNs from 1/1/2007.
It does not feel too early to start to understand what we must do to as a community to guarantee ubiquity of reachable networks.
I couldn't agree more.
Henk
'the power of the market place!' ... perhaps now is the time to call your
local (Juniper|Cisco|Other) router vendor sales rep and ask? 
RIPE will be accepting requests for 32-bit ASNs from 1/1/07,
according to an email to ncc-services two weeks ago. It does not
feel too early to start to understand what we must do to as a
community to guarantee ubiquity of reachable networks.
So, all of the current devices need to get upgraded before 'day one' of
32-bit ASN use... that'll be fun 
Why is RIPE passing out the 32-bit
ASN's now? aren't there still plenty (+20k or so) 16-bit ASN's out there
for assignment? (perhaps I'm missing something on the need to allocate the
new asn's?)
There were no definitive answers when John Payne asked on the list
about images supporting 32 bit as numbers - are any independent
bodies going to setup a route behind a 32-bit ASN so that we can
start public reachability testing ?
Given a 32-bit ASN I'd be happy to upgrade code on a connected device and
announce a route... of course I'm not sure my upstream will do the right
thing with the announcement since it doesn't know (probably) about 32-bit
asn's...
Testing -- better to find out now what breaks, before we really need it.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
So, all of the current devices need to get upgraded before 'day one' of
32-bit ASN use... that'll be fun
ASN's now?
ARIN will begin passing out 32 bit ASN's to anyone who asks as of January 1, 2007. This is the same policy as RIPE so I don't see what the big deal is.
aren't there still plenty (+20k or so) 16-bit ASN's out there
for assignment? (perhaps I'm missing something on the need to allocate the
new asn's?)
By all means let's wait until the last possible second to upgrade ASN support. The waiting approach has worked so well for IPV6 Seriously though- why not let people start registering now. The only way we'll know if 32 bit ASN's will work is if we start using them.
-Don
understood, but I took the 'RIPE has been assigning 32-bit ASN's
since....' to mean that people actually expected them to work.
> So, all of the current devices need to get upgraded before 'day one' of
> 32-bit ASN use... that'll be fun
> ASN's now?
ARIN will begin passing out 32 bit ASN's to anyone who asks as of January
1, 2007. This is the same policy as RIPE so I don't see what the big deal
is.
Uhm, I think I mis-read the date on the original 
I thought they HAD
been passing them out, not WILL BE need more coffee
> aren't there still plenty (+20k or so) 16-bit ASN's out there
> for assignment? (perhaps I'm missing something on the need to allocate the
> new asn's?)
By all means let's wait until the last possible second to upgrade ASN
support. The waiting approach has worked so well for IPV6
though- why not let people start registering now. The only way we'll know
if 32 bit ASN's will work is if we start using them.
agreed, let's NOT do the v6 thing... do the 32-bit asn's give us more than
just 'more bits' ? (Sorry, I couldn't resist). So, yes, let's get
someone to start testing, I'd just caution on assigning the 32-bit asn's
for real-users, since much of the net might not be able to use them,
partial reachability will/could-be a problem.
* Chris L. Morrow:
So, all of the current devices need to get upgraded before 'day one' of
32-bit ASN use... that'll be fun
6. Transition
The scheme described in this document allows a gradual transition
from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one
Autonomous System or one BGP speaker at a time.
Routers on stub ASs don't need upgrading at all, for instance.
but filter lists and such I imagine might
* Chris L. Morrow:
> 6. Transition
>
> The scheme described in this document allows a gradual transition
> from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one
> Autonomous System or one BGP speaker at a time.Routers on stub ASs don't need upgrading at all, for instance.
but filter lists and such I imagine might
Only if you want to keep your fine-grained filters, which shouldn't be
a problem over the next few years. From a purely BGP 4 perspective,
the transition looks like a new tier 1 ISP entering the stage.
(But if more than one of your peers switch, you better upgrade as
well.)
aren't there still plenty (+20k or so) 16-bit ASN's out there
for assignment? (perhaps I'm missing something on the need to allocate the
new asn's?)By all means let's wait until the last possible second to upgrade ASN
support. The waiting approach has worked so well for IPV6
though- why not let people start registering now. The only way we'll know
if 32 bit ASN's will work is if we start using them.agreed, let's NOT do the v6 thing... do the 32-bit asn's give us more than
just 'more bits' ?
someone to start testing, I'd just caution on assigning the 32-bit asn's
for real-users, since much of the net might not be able to use them,
partial reachability will/could-be a problem.
Wouldn't this just mean (Since Jan 1 2007 hasn't come to pass yet) setting up a Quagga router and plugging it into your existing network? Seems to me that without real support for the existing operating systems... um, the old
neighbor xxx.xxx.xxx.xxx remote-as [32bit ASN notation]
would pretty much end the experiment.
I can easily imagine setting up some test beds with multi-hop so people can test their implementation with real "talkers" -- lol, which is a lot like the way IPV6 is/was set up.
If anyone wants to play with this, we'll do our part and set up an AS in the development space of 32bit-AS land and peer with anyone who wants to bang on it...
DJ
I've hit up my big 3 vendors... no response yet, but it is holiday season