Seen on a mailing list, some comments regarding local preference vs MED.
Unfortunately, the reason crazy-long prepends actually propagate so widely in the internet core is because most of those decisions to prefer your peer's customers are done using a relatively big and heavy hammer.
> IOW if your peer or customer has prepended 5 times or more, dont LOCAL_PREF or maybe even de-LOCAL_PREF it
LOCAL_PREF is, in my opinion, the wrong tool to use, but it's what most of the networks out there seem to have settled on, to the point of having published BGP communities to use for controlling the LOCAL_PREF setting on received routes: https://onestep.net/communities/
I've long practiced, and advocated for, the use of MEDs or tweaking origin codes as a better way to nudge traffic towards customers, peers, customers of peers, etc., because it still allows as-path to be a factor in nudging traffic away. Prepend inbound 3 times on routes learned from your transit provider, but not on your peers, listen to MEDs from your peers, and enable always-compare-med and deterministic-med to allow values to be compared across different pathways.
That way, someone trying to say "don't use this path" can do a simple triple-prepend, and see their traffic shift. In our current world of using LOCAL_PREF, however, the poor customer keeps prepending more and more, and never sees their traffic shift. In desperation, they prepend the maximum number of times allowed, hoping that maybe this will somehow do the trick...not understanding that no matter what they do in the prepend realm, so long as their upstreams are using the LOCAL_PREF hammer, their prepends will fall on deaf ears.
For the most part--if you think LOCAL_PREF is the right knob to use for moving traffic, it probably means you need to go back and rethink your traffic engineering approach.
