16-bit ASN kludge
Edward B. Dreger
eddy+public+spam at noc.everquick.net
Sat Dec 4 20:04:43 UTC 2004
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 at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net
Sending mail to spambait addresses is a great way to get blocked.
More information about the NANOG
mailing list