On Wed, Oct 03, 2012 at 01:29:19PM +0000, Alvaro Retana (aretana) wrote: > >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.
I suspect my use of aggregated (implicit) conflicts with your use (explicit/policy). A recurring nightmare from working on RFC 4271 for me, perhaps. RFC 4271, sec 9.1.4: : If a BGP speaker receives overlapping routes, the Decision Process : MUST consider both routes based on the configured acceptance policy. : If both a less and a more specific route are accepted, then the : Decision Process MUST install, in Loc-RIB, either both the less and : the more specific routes or aggregate the two routes and install, in : Loc-RIB, the aggregated route, provided that both routes have the : same value of the NEXT_HOP attribute. : : If a BGP speaker chooses to aggregate, then it SHOULD either include : all ASes used to form the aggregate in an AS_SET, or add the : ATOMIC_AGGREGATE attribute to the route. This attribute is now : primarily informational. [...] No one that I'm aware of implements ATOMIC_AGGREGATE in this way. As I pointed out many times during the standardization of 4271, your 3.4 above is effectively the same thing at a black-box perspective. Effectively, your bounded marking is largely what we should be doing for ATOMIC_AGGREGATE. The primary difference, and part of what I was alluding to, is that if no path information is being lost, bounding is largely safe. The partitioned AS case unfortunately is still not fully covered, but it's better. > 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.. I believe I already agreed with this point. The primary difference is whether the operator is aware of whether it's safe to do this or not. When such a process is automated, that operator safety net is removed. It's also problematic in the sense that the party it may cause problems for is several hops removed. If you're a stubby enough AS, the loss of a more specific may deny you reachability to the network. -- Jeff _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
