nanog mailing list archives
Re: 16-bit ASN kludge
From: Iljitsch van Beijnum <iljitsch () muada com>
Date: Sat, 4 Dec 2004 12:17:22 +0100
On 4-dec-04, at 9:47, Owen DeLong wrote:
I think the general idea of dividing ASNs into LEAF and TRANSIT categoriesis a good one. A method of determining which ASs need to know about a given LEAF AS is needed, and, I think a lot of optimizations may well be possible.
So now people have to renumber their AS when they start selling transit? Not such a great idea...
Now watch out, since you completely unnecessirily quoted Eddy's message in full, I'm going to reply to that here rather than use a separate message for this.
OD> I think all the meaningful parties have already pretty much agreed on OD> 32bit ASNs in BGP4. I think that will be coded in the routers well before OD> any attribute-based thing for 32bit ASNs is. As such, I don't see much OD> point to kludging this instead of just going for it assuminga 32bit world.
Then belay my 16-bit ramblings. I'm probably a bit naive in thinking a new attribute would be passed along by enough transits to be useful; an "adopt this incompatible protocol or become an island" approach may wellbe needed.
This is not what the 32 bit AS draft proposes. (From memory, so I might get some of the small details wrong.) The idea is that the new 32 bit AS path is a new transitive attribute, which should be carried by existing BGP implementations. However, the 16 bit AS path is still there as well, with all the 16 bit incompatible ASes replaced by a "special" AS.
So all of this should work with existing implementations except that they don't see the full picture so AS path filtering on 32 bit ASes won't work. Basic operation shouldn't be a problem, though.
Note that I suggested starting to give out 32 bit AS numbers to new 32 bit compatible leaf sites while giving out 16 bit AS numbers to transit ASes as a way to ease in to all of this with the least amount of operational trouble. But at some point we'll run out of 16 bit AS numbers and 32 bit leaf networks will become transit networks, so people should upgrade at some point or live with the reduced filtering capabilities. And new ASes can't get around 32 bit support if their AS number isn't 16 bit safe, of course.
I still have to wonder if some leaf optimizations are possible. Perhapsan incompatible protocol would leave more implementation wiggle room.
What would you like to optimize for?
Current thread:
- 16-bit ASN kludge Edward B. Dreger (Dec 03)
- Message not available
- Re: 16-bit ASN kludge John Dupuy (Dec 03)
- Re: 16-bit ASN kludge Owen DeLong (Dec 03)
- Re: 16-bit ASN kludge Edward B. Dreger (Dec 03)
- Re: 16-bit ASN kludge Owen DeLong (Dec 03)
- Re: 16-bit ASN kludge Edward B. Dreger (Dec 03)
- Re: 16-bit ASN kludge Owen DeLong (Dec 04)
- Re: 16-bit ASN kludge Iljitsch van Beijnum (Dec 04)
- Re: 16-bit ASN kludge Edward B. Dreger (Dec 04)
- Re: 16-bit ASN kludge Iljitsch van Beijnum (Dec 05)
- Re: 16-bit ASN kludge Owen DeLong (Dec 05)
- Re: 16-bit ASN kludge Edward B. Dreger (Dec 05)
- Re: 16-bit ASN kludge John Dupuy (Dec 03)
- Message not available
- Re: 16-bit ASN kludge Andrew - Supernews (Dec 04)
- Re: 16-bit ASN kludge Valdis . Kletnieks (Dec 03)
- Re: 16-bit ASN kludge Owen DeLong (Dec 03)
- Re: 16-bit ASN kludge Valdis . Kletnieks (Dec 06)
- Re: 16-bit ASN kludge Owen DeLong (Dec 06)
- Re: 16-bit ASN kludge Valdis . Kletnieks (Dec 06)