[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" <[email protected]> wrote: >On Tue, Oct 2, 2012 at 5:20 PM, Russ White <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
