<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 31, 2022 at 3:16 PM Joe Maimon <<a href="mailto:jmaimon@jmaimon.com">jmaimon@jmaimon.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
Joe Provo wrote:<br>
> On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:<br>
>> :) probably the longest prepend in the world.<br>
>><br>
>> A thought though, is it breaking any standard or best practice procedures?<br>
><br>
> That said, prepending pretty much anything more than your current view<br>
> of the Internet's diameter in ASNs is useless in practice. Cascading<br>
> effects are considered in<br>
> <a href="https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/</a><br>
> where a decent low number (5) is propsed.<br>
><br>
> Chers,<br>
><br>
> Joe<br>
>   <br>
<br>
So is there a good way to signal along with a BGP route that the <br>
originator of the route wants you to know that this route has very high <br>
suckage factor and even if you normally prefer your peers customers <br>
whatever, you should perhaps think twice about that for this route, <br>
cause its really last resort.<br>
<br>
Because as-path is an overloaded multimeaning traffic influencing hammer <br>
that has imprecise and frequently undesirable results. And if that were <br>
not the case, than discussions of its relative size compared to internet <br>
diameter would be much more relevant.<br>
<br>
Joe<br>
<br></blockquote><div><br></div><div>Unfortunately, the reason crazy-long prepends actually propagate so </div><div>widely in the internet core is because most of those decisions to prefer </div><div>your peer's customers are done using a relatively big and heavy hammer.</div><div><br></div><div>LOCAL_PREF is, in my opinion, the wrong tool to use, but it's what most </div><div>of the networks out there seem to have settled on, to the point of having</div><div>published BGP communities to use for controlling the LOCAL_PREF setting </div><div>on received routes: <a href="https://onestep.net/communities/">https://onestep.net/communities/</a></div><div><br></div><div>I've long practiced, and advocated for, the use of MEDs or tweaking origin </div><div>codes as a better way to nudge traffic towards customers, peers, customers </div><div>of peers, etc., because it still allows as-path to be a factor in nudging traffic </div><div>away.   Prepend inbound 3 times on routes learned from your transit provider, </div><div>but not on your peers, listen to MEDs from your peers, and enable always-compare-med</div><div>and deterministic-med to allow values to be compared across different pathways.</div><div><br></div><div>That way, someone trying to say "don't use this path" can do a simple triple-prepend, </div><div>and see their traffic shift.  In our current world of using LOCAL_PREF, however, the </div><div>poor customer keeps prepending more and more, and never sees their traffic shift. </div><div>In desperation, they prepend the maximum number of times allowed, hoping that </div><div>maybe this will somehow do the trick...not understanding that no matter what they </div><div>do in the prepend realm, so long as their upstreams are using the LOCAL_PREF </div><div>hammer, their prepends will fall on deaf ears.</div><div><br></div><div>For the most part--if you think LOCAL_PREF is the right knob to use for moving </div><div>traffic, it probably means you need to go back and rethink your traffic engineering </div><div>approach.   ^_^;</div><div><br></div><div>Matt</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div></div></div>