Hi Jeffrey & Havard Thank you for the comments.
The goal of 3.1 was to graphically depict the how excess as-path prepending and how that could yield or exacerbate prefix hijacking impact downstream consumers of pretending as you stated with ripple effect where a desirable source origin AS becomes de-preferred or hijacked resulting in a route leak. We will also mention using BGP prefix origin validation RFC 6811 to mitigate prefix hijacking resulting in a route leak. The goal of 3.1 was also to shed light on the ripple effects to downstream providers consuming the prepends resulting in extremely long AS path exceeding the 255 max as-path. Also in 3.1 the goal was to depict the impact of “prepend to all” resulting in prefix hijacking due to de-prefer of origin AS route resulting in route leaks. We will make 3.1 more clear in depicting a route leak from prefix hijacking resulting from “prepend to all” excessive prepending. Also remove the 5+1 making it announce six. Many Thanks Gyan On Fri, Feb 18, 2022 at 11:13 AM Jeffrey Haas <[email protected]> wrote: > 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= > [email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/grow > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
