Networks ignoring prepends?

Wed Jan 24 09:36:04 UTC 2024

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 at rrel.me> wrote:

>
>
> > On Jan 22, 2024, at 6:53 PM, Jeff Behrns via NANOG <nanog at nanog.org>
> wrote:
> >
> >>> William Herrin <bill at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240124/01604b63/attachment.html>