Along these lines, one could leave the transit AS networks alone if a parallel 16 bit ASN space were created. Essentially, any non-transit network would have it's non-public ASN retranslated NAT-style by upstream transit network border routers. Only the border routers would have to be changed. They would have to differentiate between public ASN X and non-public ASN X (same number) based on the which side of the router the ASN was learned from. This would essentially double the ASN numbers available. All that being said, I'd much rather see 32-bit ASNs. John At 10:48 AM 12/3/2004, Edward B. Dreger wrote:
Perhaps transit networks should receive 16-bit ASNs. Leaf networks would use { a special ASN | I'm still brainstorming | who knows } and carry an "available upstreams" BGP tag for each upstream.
Metrics are calculated for each transit AS. Those metrics are then combined with <as yet unspecified intelligence in "available upstreams" tag> for each leaf ASN.
BGP loop detection might present a problem if all leaf ASNs use, say, 16-bit AS65535. If existing allowas-in is too coarse, refer to "32-bit ASN" BGP attribute for fine-grained control.
In short: I'm trying to think up a mechanism that performs full Dijkstra calculations _only_ for transit networks, and uses some cheaper version for the degenerate case of a leaf network.
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.
I think the original proposal was to still go with 32 bit ASNs, but, adapt a range of 32 bit ASNs for the assignment to "NON-TRANSIT" ASNs leaving the entire 16 bit range reserved for "TRANSIT" ASNs. I think there's merit to the idea, but, I think that it could use some refinement. I agree there will be many more non-transit than transit ASNs (non-transit is an ASN that does not provide transit, transit is an ASN that provides transit). I think it would make more sense to put the boundary somewhere around 12 bits or so. If we reserved the first meg 1024k ASNs for transit providers (excepting the Private ASN reservation already in place), and, allowed the remaining ASNs to be assigned to non-transit ASNs, this functionality could be implemented relatively easily with maximum backward compatibility. Just my $0.02. Owen --On Friday, December 3, 2004 16:36 -0600 John Dupuy <jdupuy-list@socket.net> wrote:
Along these lines, one could leave the transit AS networks alone if a parallel 16 bit ASN space were created. Essentially, any non-transit network would have it's non-public ASN retranslated NAT-style by upstream transit network border routers. Only the border routers would have to be changed. They would have to differentiate between public ASN X and non-public ASN X (same number) based on the which side of the router the ASN was learned from.
This would essentially double the ASN numbers available.
All that being said, I'd much rather see 32-bit ASNs.
John
At 10:48 AM 12/3/2004, Edward B. Dreger wrote:
Perhaps transit networks should receive 16-bit ASNs. Leaf networks would use { a special ASN | I'm still brainstorming | who knows } and carry an "available upstreams" BGP tag for each upstream.
Metrics are calculated for each transit AS. Those metrics are then combined with <as yet unspecified intelligence in "available upstreams" tag> for each leaf ASN.
BGP loop detection might present a problem if all leaf ASNs use, say, 16-bit AS65535. If existing allowas-in is too coarse, refer to "32-bit ASN" BGP attribute for fine-grained control.
In short: I'm trying to think up a mechanism that performs full Dijkstra calculations _only_ for transit networks, and uses some cheaper version for the degenerate case of a leaf network.
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.
-- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
OD> Date: Fri, 03 Dec 2004 14:45:17 -0800 OD> From: Owen DeLong <owen@delong.com> 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: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked.
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. Owen --On Saturday, December 4, 2004 0:30 +0000 "Edward B. Dreger" <eddy+public+spam@noc.everquick.net> wrote:
OD> Date: Fri, 03 Dec 2004 14:45:17 -0800 OD> From: Owen DeLong <owen@delong.com>
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: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked.
OD> Date: Fri, 03 Dec 2004 18:09:48 -0800 OD> From: Owen DeLong 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 assuming a 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 well be needed. I still have to wonder if some leaf optimizations are possible. Perhaps an incompatible protocol would leave more implementation wiggle room. 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.
I think the general idea of dividing ASNs into LEAF and TRANSIT categories is 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. Like I said, I think it requires some additional thought and refinement, but, I like the general idea. Owen --On Saturday, December 4, 2004 3:03 AM +0000 "Edward B. Dreger" <eddy+public+spam@noc.everquick.net> wrote:
OD> Date: Fri, 03 Dec 2004 18:09:48 -0800 OD> From: Owen DeLong
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 assuming a 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 well be needed.
I still have to wonder if some leaf optimizations are possible. Perhaps an incompatible protocol would leave more implementation wiggle room.
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.
-- If it wasn't crypto-signed, it probably didn't come from me.
On 4-dec-04, at 9:47, Owen DeLong wrote:
I think the general idea of dividing ASNs into LEAF and TRANSIT categories is 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 assuming a 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 well be 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. Perhaps an incompatible protocol would leave more implementation wiggle room.
What would you like to optimize for?
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.
On 4-dec-04, at 21:04, Edward B. Dreger wrote:
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.
How does this make sense? If you have one of the ASes in the range 2^16 - 2^20-1 you, your customers and your transits still need to be able to handle 32 bit AS numbers. Apart from the backward compatibility being slightly more important for transit networks there is no upside to having a separate transit network and leaf network AS space.
IvB> What would you like to optimize for?
Application of Dijkstra's algorithm.
Well, then you're in luck as BGP is highly optimized in this regard: it doesn't use the Dijkstra or SPF algorithm. BGP is pretty much a distance vector routing protocol.
--On Sunday, December 5, 2004 3:55 PM +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 4-dec-04, at 21:04, Edward B. Dreger wrote:
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.
How does this make sense? If you have one of the ASes in the range 2^16 - 2^20-1 you, your customers and your transits still need to be able to handle 32 bit AS numbers. Apart from the backward compatibility being slightly more important for transit networks there is no upside to having a separate transit network and leaf network AS space.
My thinking was that transit networks could aggregate leaf advertisements and share only the aggregates instead of the more specifics. The hope here was that by having separate leaf/transit ASNs, we could perform another level of routing table size management/optimization. I think optimizing for backward compatibility for transit initially, and, eventually, for transit routing table size while still providing leaf multihoming capabilities is desirable. Owen -- If it wasn't crypto-signed, it probably didn't come from me.
IvB> Date: Sun, 5 Dec 2004 15:55:04 +0100 IvB> From: Iljitsch van Beijnum IvB> Well, then you're in luck as BGP is highly optimized in this IvB> regard: it doesn't use the Dijkstra or SPF algorithm. BGP is pretty IvB> much a distance vector routing protocol. D'oh. Pardon the round of public stupidity. I think I need to back away from OSPF for a bit. 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.
"Owen" == Owen DeLong <owen@delong.com> writes:
Owen> I think all the meaningful parties have already pretty much Owen> agreed on 32bit ASNs in BGP4. I think that will be coded in Owen> the routers well before any attribute-based thing for 32bit Owen> ASNs is. As such, I don't see much point to kludging this Owen> instead of just going for it assuming a 32bit world. Was I the only person who noticed when someone (apparently) typoed their router config and leaked a 32-bit ASN into the global table? (This was about 3 months back - I don't recall any mention of it then) -- Andrew, Supernews http://www.supernews.com
On Fri, 03 Dec 2004 16:36:39 CST, John Dupuy said:
Along these lines, one could leave the transit AS networks alone if a parallel 16 bit ASN space were created. Essentially, any non-transit network would have it's non-public ASN retranslated NAT-style by upstream transit network border routers. Only the border routers would have to be changed. They would have to differentiate between public ASN X and non-public ASN X (same number) based on the which side of the router the ASN was learned from.
So given the lack of trouble with NAT sites leaking rfc1918 addresses, you foresee no problems with sites accidentally leaking the non-public ASN's, right?
I don't see non-transit ASN leakage as any greater issue than current private ASN leakage. However, I do see the ability to use non-transit ASNs to multihome end sites with provider independent addresses and allow better aggregation as a good thing. In this case, leakage would only have the same consequences as doing things the way we do them now. I don't see a real downside. Owen --On Friday, December 3, 2004 18:08 -0500 Valdis.Kletnieks@vt.edu wrote:
On Fri, 03 Dec 2004 16:36:39 CST, John Dupuy said:
Along these lines, one could leave the transit AS networks alone if a parallel 16 bit ASN space were created. Essentially, any non-transit network would have it's non-public ASN retranslated NAT-style by upstream transit network border routers. Only the border routers would have to be changed. They would have to differentiate between public ASN X and non-public ASN X (same number) based on the which side of the router the ASN was learned from.
So given the lack of trouble with NAT sites leaking rfc1918 addresses, you foresee no problems with sites accidentally leaking the non-public ASN's, right?
-- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
On Fri, 03 Dec 2004 15:23:55 PST, Owen DeLong said:
I don't see non-transit ASN leakage as any greater issue than current private ASN leakage.
If somebody leaks a private ASN, we can tell that it's a private ASN by inspection. If somebody is using '1312' inside their parallel ASN space and accidentally leaks it, it's a bit harder to diagnose. And if somebody is leaking 1312, I'll be quite put out... ;)
The proposal was that transit ASNs would begin with 12 leading 0 bits and non-transit ASNs would not. As such, 1312 would not be a non-transit ASN. The proposal wasn't for "parallel" ASN space. The proposal was to have a range of ASNs for leaf-networks and a range for transit networks, allowing transit networks to make more rational (possibly automated) decisions about route aggregation. Owen --On Monday, December 6, 2004 12:54 PM -0500 Valdis.Kletnieks@vt.edu wrote:
On Fri, 03 Dec 2004 15:23:55 PST, Owen DeLong said:
I don't see non-transit ASN leakage as any greater issue than current private ASN leakage.
If somebody leaks a private ASN, we can tell that it's a private ASN by inspection.
If somebody is using '1312' inside their parallel ASN space and accidentally leaks it, it's a bit harder to diagnose.
And if somebody is leaking 1312, I'll be quite put out... ;)
-- If it wasn't crypto-signed, it probably didn't come from me.
On Mon, 06 Dec 2004 10:14:12 PST, Owen DeLong said:
The proposal wasn't for "parallel" ASN space. The proposal was to have a range of ASNs for leaf-networks and a range for transit networks, allowing transit networks to make more rational (possibly automated) decisions about route aggregation.
That may be sane, but that's not how I read John's actual proposal: On Fri, 03 Dec 2004 16:36:39 -0600, John Dupuy said:
Along these lines, one could leave the transit AS networks alone if a parallel 16 bit ASN space were created. Essentially, any non-transit network would have it's non-public ASN retranslated NAT-style by upstream transit network border routers. Only the border routers would have to be changed. They would have to differentiate between public ASN X and non-public ASN X (same number) based on the which side of the router the ASN was learned from.
I don't see anything about ranges, but an entire parallel 16 bit space. And John's definitely talking about them possibly having a 1312 on both sides, because it matters which side you hear about it from. Conversely, if it matters which side you hear about it from, it also matters which side you announce it on.. which was my point.
Sorry... I was talking about Eds proposal... I hadn't noticed the shift to an entirely different proposal by John. I think Eds proposal (which I proposed some modification to) has merit. I think Johns alternative is far less desirable and agree with your concerns about it. Owen --On Monday, December 6, 2004 1:32 PM -0500 Valdis.Kletnieks@vt.edu wrote:
On Mon, 06 Dec 2004 10:14:12 PST, Owen DeLong said:
The proposal wasn't for "parallel" ASN space. The proposal was to have a range of ASNs for leaf-networks and a range for transit networks, allowing transit networks to make more rational (possibly automated) decisions about route aggregation.
That may be sane, but that's not how I read John's actual proposal:
On Fri, 03 Dec 2004 16:36:39 -0600, John Dupuy said:
Along these lines, one could leave the transit AS networks alone if a parallel 16 bit ASN space were created. Essentially, any non-transit network would have it's non-public ASN retranslated NAT-style by upstream transit network border routers. Only the border routers would have to be changed. They would have to differentiate between public ASN X and non-public ASN X (same number) based on the which side of the router the ASN was learned from.
I don't see anything about ranges, but an entire parallel 16 bit space. And John's definitely talking about them possibly having a 1312 on both sides, because it matters which side you hear about it from.
Conversely, if it matters which side you hear about it from, it also matters which side you announce it on.. which was my point.
-- If it wasn't crypto-signed, it probably didn't come from me.
participants (6)
-
Andrew - Supernews -
Edward B. Dreger -
Iljitsch van Beijnum -
John Dupuy -
Owen DeLong -
Valdis.Kletnieks＠vt.edu