Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes
[Also catching upŠ] Bill: I want to say up front that the proposal is not for this draft to be a standards track document and to have everyone do it by default. It provides a tool that people may want to use, as reflected by some interest at the WG meeting. This is why we intended the draft to be Experimental at this point. On 10/2/12 5:46 PM, William Herrin b...@herrin.us wrote: On Tue, Oct 2, 2012 at 5:20 PM, Russ White ru...@riw.us wrote: - Path information is lost. While this doesn't impact loop prevention, this information is operationally useful. I'll offer the counter that this is already done today through explicit policy, typically either because the operator knows this is safe or because they simply don't care about the Consequences to forwarding. I don't get how path information is lost in this draft. The AS Path is not altered in any advertisement, so it's not like aggregation, where you replace a series of AS' with a single AS, or anything like that. Hi Russ, 10.1.0.0/16 AS path 12 5 4 2 10.1.1.0/24 AS path 12 1 The 12-1 path, 1 being a completely different origin AS than the covering route's origin from 2, is lost when 10.1.1.0/24 is aggregated into 10.1.0.0/16. The path is not aggregated. Instead, the /24 would be marked as BOUNDED; the draft explains what that means: = 3.3 Handling Marked Routes Within the AS Routes marked with the BOUNDED community MAY not be installed in the local RIB of routers within the AS. This optional step will reduce local RIB and forwarding table usage and volatility within the AS. 3.4 Handling Marked Routes at the Outbound Edge Routes marked with the BOUNDED community SHOULD NOT be advertised to external peers. If they are advertised, they SHOULD then be marked with the NO_EXPORT community. = The proposal is for the /24 to not be advertised further. I can see how this looks like loss of path information. However, we also wrote the following: = 3.1 Marking Overlapping Routes As each prefix is received by a BGP speaker from an external peer, it is evaluated in the light of other prefixes already received. If two prefixes overlap in space (such as 192.0.2.0/24 and 192.0.2.128/25), the longer prefix SHOULD be BOUNDED. A BGP speaker MAY also choose to check the AS_PATH attribute length and contents before marking a prefix as BOUNDED. = The intent of the last paragraph was to have the local network decide whether the AS_PATH should somehow match or not. Given the comments, maybe we should change the 'MAY' above for 'SHOULD' (??), and clarify what the checking would/could entail. .. - But even if they do share a common origin AS, if you have an internal AS partition, things may be unhappy if the more specific provided you forwarding coverage and it got suppressed. AS partitions are already handled in the draft as written. If the two routers with overlapping prefixes aren't reachable through iBGP (no matter what their AS numbers might happen to me), then the mechanism won't suppress the longer prefix. Suppose an Internet-connected network consists of site A and site B. .. Yes, that is a problem. I do want to note that the same problem exists today if the more specific route is discarded due to a policy related to the length of the prefixes accepted by a given SP -- or any other such policy that can be implemented with a manual filter. As with the manual filter (as I said above), our proposal is optional, it is intended to facilitate the operation if you want to use it.. Thanks! Alvaro. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes
I don't get how path information is lost in this draft. The AS Path is not altered in any advertisement, so it's not like aggregation, where you replace a series of AS' with a single AS, or anything like that. Hi Russ, 10.1.0.0/16 AS path 12 5 4 2 10.1.1.0/24 AS path 12 1 The 12-1 path, 1 being a completely different origin AS than the covering route's origin from 2, is lost when 10.1.1.0/24 is aggregated into 10.1.0.0/16. No more than if the longer prefix were filtered for any other reason --such as if the provider is originating the shorter prefix, and decides to filter the longer prefix for whatever local policy reason. The only way to see this as losing AS Path information, is to see the filtering of any possible route, including routes lost because they aren't the best path, as losing AS Path information. - But even if they do share a common origin AS, if you have an internal AS partition, things may be unhappy if the more specific provided you forwarding coverage and it got suppressed. AS partitions are already handled in the draft as written. If the two routers with overlapping prefixes aren't reachable through iBGP (no matter what their AS numbers might happen to me), then the mechanism won't suppress the longer prefix. Suppose an Internet-connected network consists of site A and site B. 10.1.1.0/24 is advertised from and used by site A while 10.1.2.0/24 is advertised from and used by site site B. Both sites advertise 10.1.0.0/16. Sites A and B are connected to each other, so if site A receives a packet for 10.1.2.1, it will forward it to site B. If site B should lose its internet connection, packets for 10.1.2.1 will follow the covering route via site A and still reach site B. Regardless of aggregation. This has always been true of any form of aggregation --this draft doesn't introduce any new risk in this area. When you aggregate at any level, ever, you always introduce the risk of suboptimal routes and/or routing black holes. Does this mean all routes advertised into the DFZ should be /24's, or host routes? :-) Russ ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes
The problem as I see it is many of those that operate in the BGP/DFZ don't know what they are doing. ??? Then they shouldn't be using this technique. Or perhaps even running BGP. Protocols provide rope. It's choice whether you make good things or bad things with the rope provided. :-) Russ ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes
Russ, Hmmm, I don't think this is a consistent message.. When I attempted to give people rope i.e BGP Persistence IETF chairs felt that this was too much rope ?? IMO it takes very little rope to hang oneself so, let's be consistent as a starting point... Jim Uttaro -Original Message- From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On Behalf Of Russ White Sent: Wednesday, October 03, 2012 10:22 AM To: Jared Mauch Cc: grow@ietf.org Subject: Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes The problem as I see it is many of those that operate in the BGP/DFZ don't know what they are doing. ??? Then they shouldn't be using this technique. Or perhaps even running BGP. Protocols provide rope. It's choice whether you make good things or bad things with the rope provided. :-) Russ ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes
Suppose an Internet-connected network consists of site A and site B. 10.1.1.0/24 is advertised from and used by site A while 10.1.2.0/24 is advertised from and used by site site B. Both sites advertise 10.1.0.0/16. Sites A and B are connected to each other, so if site A receives a packet for 10.1.2.1, it will forward it to site B. If site B should lose its internet connection, packets for 10.1.2.1 will follow the covering route via site A and still reach site B. Regardless of aggregation. This has always been true of any form of aggregation --this draft doesn't introduce any new risk in this area. When you aggregate at any level, ever, you always introduce the risk of suboptimal routes and/or routing black holes. Does this mean all routes advertised into the DFZ should be /24's, or host routes? BTW, I agree with Alvaro that the draft intends to leave open the option of how to implement this within an individual provider's network, so the provider could choose to check the entire AS Path before bounding a particular route. We had also removed (for simplicity) the don't bound community, but we could easily add it back in if providers want the capability to have a customer mark their routes to never be removed. Would that be useful? :-) Russ ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes
Alvaro, 10.1.0.0/16 AS path 12 5 4 2 10.1.1.0/24 AS path 12 1 The 12-1 path, 1 being a completely different origin AS than the covering route's origin from 2, is lost when 10.1.1.0/24 is aggregated into 10.1.0.0/16. The path is not aggregated. Instead, the /24 would be marked as BOUNDED; the draft explains what that means: = 3.3 Handling Marked Routes Within the AS Routes marked with the BOUNDED community MAY not be installed in the local RIB of routers within the AS. This optional step will reduce local RIB and forwarding table usage and volatility within the AS. So if I learn /24 from different peer then /16 arrives on given ASBR or such /24 arrives via different ASBR (both cases would result /24 to have different next hop then /16) such /24 would not be marked as BOUNDED correct ? If so I really fail why this filtering can not be done by inbound EBGP policy on such ASBR. Why do we need new draft and new communities ??? R. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes
Russ, Yes. Sorry, but it is always true that by removing information you always lose optimality (you increase stretch). Whether that removal is done at the edge or in the core, the result is always the same. There are two ironclad rules of routing: - Removing information decreases optimal routing. No. If you remove information which is redundant and when such removal will not result in even a single bit of sub-optimal routing what you wrote above is false ironclad rule. Also the critical piece is that the determination when and what should be removed must be 100% automated. There is no way where manual intervention would be required for any scheme to work right. And your proposal does require manual NOC intervention as you have already confirmed today. The proposal from Pedro however is automated, adjust itself to topology changes as well as removed only redundant information where such removal does not impact a single bit routing optimality. Rgs, R. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes
On Oct 3, 2012, at 10:21 AM, Russ White ru...@riw.us wrote: The problem as I see it is many of those that operate in the BGP/DFZ don't know what they are doing. ??? Then they shouldn't be using this technique. Or perhaps even running BGP. Protocols provide rope. It's choice whether you make good things or bad things with the rope provided. :-) Sure. But expecting them to do anything 'smart' has been a huge undertaking. Some providers (e.g.: Bellsouth/ATT) have been trying for 2+ years to fix their unnecessary aggregate leaks with no success. I'm not sure how to convince smaller folks to do the right thing if the big people can't sort it out. (even with the right hooks). - Jared ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes
How do you know that the overlapping route takes traffic through the same path? AS path != routing path and BGP is a distance-vector protocol. Your router has no reliable knowledge of the routing path more than 1 hop away. All that matters is that I draw the same traffic into my AS, where the more specifics still exist, so I can optimally route the traffic out of my AS --the same as I always have. You seem to be thinking that this would be done at the edge in some way --that the originating AS would be doing the suppression. That's not the way this is designed to work at all. The suppression is supposed to take place at least one hop away from the route origin, and only if I can be reasonably certain that my suppression of the longer route isn't going to change traffic patterns from my perspective. Even if you could know the routing path was the same, consider: ISP 88 10.1.0.0/16 via 2 3 10.1.1.0/24 via 2 3 (suppressed) ISP 99 10.1.0.0/16 via 4 12 62 16 2 3 10.1.1.0/24 via 4 8 9 5 3 (not suppressed) ISP 111 (customer of 88 99): 10.1.0.0/16 via 88 2 3 10.1.1.0/24 via 99 4 8 9 5 3 Best route was lost. But 111 can't safely suppress the /24 route because he has no knowledge of whether the /24 is reachable via 88 1 2 3. To the best of 111's knowledge, AS3 might look like this right now: So, I'm trying to guess how you have things connected, but it seems like what you're saying is that the longer prefix is suppressed, leaving a shorter prefix that loses to another peer's shorter prefix which doesn't actually contain the longer prefix. Further, the two AS' advertising the two shorter prefixes cannot be connected to one another. I actually don't see how this would work in normal routing, much less if you suppress the shorter --you're saying you have a situation where one AS has access to 10.1.0.0/16 and 10.1.1.0/24, and another has access to 10.1.0.0/16, but not 10.1.1.0/24. I'd like to see a network designed where this is true without data plane filters implemented. :-) Russ ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes
I'm not sure how to convince smaller folks to do the right thing if the big people can't sort it out. (even with the right hooks). You automate the process as much as possible, and let them sort out the problems that result from their messed up shorter prefix routes. :-) Russ ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
