I support Hávard's observations. I'd also like to comment that the notation of "prepends 5" meaning "5 + 1" is a bit confusing for all of the examples. Consider instead just saying what the announced as-path length is. Operators prepend 5 because their intent is "announce 6". :-)
Rather than try to cast the (very contrived) scenario as a form of route leaking, I'd suggest the authors focus on the impact of downstream consumers of the prepending. In particular, the example here simply notes that the receiving AS had a desire to use one path, but the upstream providers in executing their own motivations caused them to not have such a preferable path by default. Sadly, too bad for this downstream operator. The more hops away you are from a given bit of reachability, the less your opinion tends to matter over what the announcements look like. It's likely time for them to form a business relationship with the announcing AS or one of their immediate service provider ASes. (And thus, reinforcing business motivations that push the AS diameter of the Internet to remain small...) -- Jeff > On Feb 18, 2022, at 7:28 AM, Havard Eidnes <he=40uninett...@dmarc.ietf.org> > wrote: > > Hi, > > here are a few comments about section 3.1 in the draft: > > Other than the missing comma in the list of routers/ASes, near > the end there is talk about a route leak. However, I don't think > what's stated here as a route leak is what's commonly understood > to be a route leak. > > I think a route leak is commonly understood to be when a route is > announced to a neighbor in violation of the (intended) routing > policy, i.e. a route leak can be the result of an erroneously > implemented intended routing policy. I can't see how that's the > case here, because no routing policy has been expressed for "I". > This probably means that "I" re-advertises all routes it > receives, from any edge on any other edge, and therefore by > definition can't have a "route leak". > > It's another matter that the traffic pattern from B to J in the > stated scenario involves a change to a path which traverses I. > > If we instead of "thinking BGP" in the drawing in 3.1, suppose we > think "RIP with max metric 64" instead. Of course when you > adjust metrics on any interface in the topology, traffic flows > will shift around. I can't quite understand when we do the > similar thing in BGP it's such a big problem? > > Admittedly, by prepending outgoing route announcements towards a > given peer, you only affect "one end of the link", and there's a > fair chance that asymmetric traffic patterns will result if > that's the only thing which is done. But... Is that a problem? > > I think the problem desribed in section 3.1 could do with a bit > clearer description of why this is problematical. > > Regards, > > - Håvard > > _______________________________________________ > 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
