All,

> But that ship seems to have sailed.

The problem is well known and it consists of two orthogonal aspects: 

#1  - Ability to signal the preference of which return path to choose by arbitrary remote ASN

#2 - Actually applying this preference by remote ASN. 

For #1 I have proposed some time back a new set of well known wide communities defined in section 2.2.4 of this draft: 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-registered-wide-bgp-communities-02#section-2.2.4

Perhaps one day this will surface such that operators will be able to signal their preference without extending AS-PATH or trashing the table with more specifics. 

For #2 it is quite likely that the economical aspect plays a role here. So it could be that accepting such a preference may not be for free. But before that happens BGP for obvious reasons should be secured and updates should be signed. And we all know how fast that is going to happen. 

Kind regards,
Robert



On Wed, Jan 24, 2024 at 5:38 AM Darrel Lewis <d@rrel.me> wrote:


> On Jan 22, 2024, at 6:53 PM, Jeff Behrns via NANOG <nanog@nanog.org> wrote:
>
>>> William Herrin <bill@herrin.us> wrote:
> Until they tamper with it using localpref, BGP's default behavior with prepends does exactly the right thing, at least in my situation.
>
> I feel your pain Bill, but from a slightly different angle.  For years the large CDNs have been disregarding prepends.  When a source AS disregards BGP best path selection rules, it sets off a chain reaction of silliness not attributable to the transit AS's.  At the terminus of that chain are destination / eyeball AS's now compelled to do undesirable things out of necessity such as:
>  1) Advertise specifics towards select peers - i.e. inconsistent edge routing policy & littering global table
>  2) Continuing to prepending a ridiculous amount anyway
> Gotta wonder how things would be if everyone just abided by the rules.
>

One might argue that the global routing system should allow for sites to signal their ingress traffic engineering preferences to remote sites in ways other than bloating the global routing table.  But that ship seems to have sailed.

Regards,

-Darrel