North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: 16-bit ASN kludge
I think all the meaningful parties have already pretty much agreed on
32bit ASNs in BGP4. I think that will be coded in the routers well before
any attribute-based thing for 32bit ASNs is. As such, I don't see much
point to kludging this instead of just going for it assuming a 32bit world.
--On Saturday, December 4, 2004 0:30 +0000 "Edward B. Dreger" <email@example.com> wrote:
OD> Date: Fri, 03 Dec 2004 14:45:17 -0800 OD> From: Owen DeLong <firstname.lastname@example.org> OD> I think the original proposal was to still go with 32 bit ASNs, but, adapt OD> a range of 32 bit ASNs for the assignment to "NON-TRANSIT" ASNs leaving OD> the entire 16 bit range reserved for "TRANSIT" ASNs. Correct. BGP would still carry traditional 16-bit ASNs, which would be used strictly by transit networks. Leaf ASes would use the "new" 32-bit ASNs, which would be carried as BGP attributes. It's similar to a transit provider with a downstream connected to multiple POPs: $transit_provider assigns all downstreams a private AS, which is stripped from outbound advertisements. OD> I think there's merit to the idea, but, I think that it could use some OD> refinement. I agree there will be many more non-transit than transit ASNs No disagreement re needing refinement. I lack the clout to push BGPv8 on the world. ;-) OD> (non-transit is an ASN that does not provide transit, transit is an OD> ASN that provides transit). OD> OD> I think it would make more sense to put the boundary somewhere around 12 OD> bits or so. If we reserved the first meg 1024k ASNs for transit providers OD> (excepting the Private ASN reservation already in place), and, allowed the OD> remaining ASNs to be assigned to non-transit ASNs, this functionality could OD> be implemented relatively easily with maximum backward compatibility. Part of the kludge intent was to create something that standard routers would carry. Hence 16-bit traditional ASNs, with extended information as an attribute. It certainly would be possible to reserve 2^20 "new" ASNs, though, for when BGP5 (or whatever) had native 32-bit support. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: email@example.com -*- firstname.lastname@example.org -*- email@example.com Sending mail to spambait addresses is a great way to get blocked.