The headache we see in section 4 is that the motivation for the section are a bit muddled. The document is largely written in a tone about "here's how prepending can be leveraged to influence which receiving ASes will select you routes" along with a bit of "warning, don't go too long".
Section 4 is partially written in the same tone. "Here are things you may do that can influence receiving ASes in picking routes differently". Loosely restating: - Community to try to influence things one or more hops away. - More specifics, which are VERY hard yanks on the covered traffic, but themselves have scoping issues that aren't discussed in good detail. E.g., you want a more specific to maybe go two hops away and then stop. - Origin, which works well and is a hard yank when you can use one of the three values appropriately vs. other candidates. - MED, which is single hop, and behavior-wise rather depends on how the receiving provider uses MEDs themselves. - And LOCAL_PREF, which is also a very hard yank, but only internally. The first items are attempts to influence a downstream. LOCAL_PREF can perversely be looked at as a way to influence downstreams because you're taking some of their options away. :-) It's possible to frame things as "a given AS may strongly apply policy in a way that bypasses the other attempts at transitive signaling". In a sense, noting this point is useful in notifying the reader that attempts to influence downstreams only work as well as the receiving AS is willing to let them influence things. LP is just one fo the tools in that policy toolbox. -- Jeff (we've blissfully avoided talking about AIGP) > On Aug 4, 2025, at 2:45 PM, David Farmer <[email protected]> > wrote: > > Reading this discussion, I propose the following; > > Move the use of Local-Prefrence to the last bullet of Section 4, "Best > Practice," and rewrite as follows > • If possible, the use of local-preference to locally override AS path > selection should be avoided. This can lead other networks to excessively > prepend their AS Paths to you in a futile attempt to influence your network. > Nevertheless, sometimes the use of local-preference is the only way to > achieve a desired traffic engineer policy. > Does this strike the right balance for folks? > > On Sat, Aug 2, 2025 at 4:50 AM Nick Hilliard <[email protected]> wrote: > Gert Doering wrote on 02/08/2025 10:29: > > I second this. This is all very well-intended, but usually just gets > > in the way at some point - so if ISP networks start working with LP, it > > inevitably results in sub-optimal paths later on (LP preferring a > > longer AS path through a private interconnect vs. a direct peering > > over an IXP is a classic example) - which needs manual interaction > > to fix. Given the amount of BGP expertise in operational networks is > > going down over time, doing anything that needs more BGP expertise in > > future should not be encouraged. > > Agreed, LP is convenient in tiny leaf networks, but it can easily cause > more trouble than it's worth on larger networks with any sort of > topology complication. I'd be very cautious about recommending it in a BCP. > > Nick > > _______________________________________________ > GROW mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > -- > =============================================== > David Farmer Email:[email protected] > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > GROW mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
