
IvB> Date: Sat, 4 Dec 2004 12:17:22 +0100 IvB> From: Iljitsch van Beijnum IvB> So now people have to renumber their AS when they start selling IvB> transit? Not such a great idea... Yeah. They'll have to tell their upstreams "here's our new ASN". No downstreams will be affected -- by definition. Hopefully routers will be friendlier to ASN changes; else one can use confederations. How is this half as bad as renumbering even a /22 of IPv4 space? I'll grant that it's imperfect, and there'd be the occasional large leaf with many routers to reconfigure, but leaves tend to be _small_ networks. IvB> This is not what the 32 bit AS draft proposes. (From memory, so I might IvB> get some of the small details wrong.) The idea is that the new 32 bit IvB> AS path is a new transitive attribute, which should be carried by IvB> existing BGP implementations. However, the 16 bit AS path is still IvB> there as well, with all the 16 bit incompatible ASes replaced by a IvB> "special" AS. Close, except I initially suggested 16-bit ASNs be reserved for transit networks. IvB> So all of this should work with existing implementations except that IvB> they don't see the full picture so AS path filtering on 32 bit ASes IvB> won't work. Basic operation shouldn't be a problem, though. Correct. Existing software would see the "special" 16-bit AS for all leaves. Newer software would understand $attribute and supply the correct AS path. IvB> Note that I suggested starting to give out 32 bit AS numbers to new 32 IvB> bit compatible leaf sites while giving out 16 bit AS numbers to transit IvB> ASes as a way to ease in to all of this with the least amount of IvB> operational trouble. But at some point we'll run out of 16 bit AS IvB> numbers and 32 bit leaf networks will become transit networks, so I suppose there could be in excess of 65431 transit networks. I think that's why Owen suggested reserving, say, 2^20 ASNs for transit in 32-bit space. That's probably wise, and at that point 16-bit ASNs would be totally unsuitable. Until then, though... IvB> people should upgrade at some point or live with the reduced filtering IvB> capabilities. And new ASes can't get around 32 bit support if their AS IvB> number isn't 16 bit safe, of course. No matter _what_ the implementation details of expanded ASN space, people must upgrade or lose <varying amounts of> capabilities. IvB> What would you like to optimize for? Application of Dijkstra's algorithm. Perform full SPF calculations on transit networks. Leaves carry "my upstream" attributes with metrics a la DPA; such information is combined with relevant transits' metrics. Although not directly akin to OSPF stub areas and NSSAs, the basic premise is the same. 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: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked.