[NANOG] Re: question about peering relationships

[Tom Beecher via NANOG <nanog () lists nanog org>]

> Can you provide a white paper that covers your proposed 'BGP Improvements'
> in more detail?  This could be a decent NANOG presentation too.  I have
> always been under the impression that you can't have peering, transit, and
> customer relationships with the same upstream and expect things to work,
> with or without local preference.  I know I am missing something in these
> conversations, and have not been able to glean a better understanding from
> this thread.  Hoping someone can point me to a white paper or good NANOG
> presentation.


Bill isn't proposing technical changes to BGP at all. He wants transit
providers to  ignore that they are a business , and also wants to ignore
the mechanisms provided by transit providers to handle traffic engineering
considerations that do arise.

Basically he wants a pony to solve problems that the rest of us have been
solving for decades.

On Thu, Apr 10, 2025 at 8:33 AM Kevin Burke via NANOG <nanog () lists nanog org>
wrote:

> On Wed, Apr 9, 2025 at 2:01 PM Matthew Petach <mpetach () netflight com>
> wrote:
> > I don't even know what you're on about here. No aspect of the BGP
> protocol is remotely non-deterministic. Even when you use it badly.
>
> Wondering if someone has a previous NANOG presentation or other white
> paper that covers multiple scenarios they can reference?
>
> > > Is it your assertion that ISPs should leave routing decisions purely
> > > to the default BGP path selection algorithm, with no hints, nudges, or
> fingers on the scale to steer traffic flows?
>
> > Absolutely not. My position is that like fabled "goto," use of local
> pref should be considered harmful. That doesn't exclude the use of BGP's
> > inbuilt tools like meds and prepends, nor does it exclude the use of
> optimizers capable of incorporating smart additional information into the
> > selection algorithm when multiple paths are available. Local pref is not
> smart. It's a blunt instrument that hurts..
>
> The routing table we are trying to manipulate is a rather blunt
> instrument.  Packets are routed on the destination prefix only.  BGP also
> does not tons of choices either especially when it has to use its limited
> tooling to affect the even more limited FIB.  These are the tools we have.
>
>
> D <- C <- B
>        ^-> A-^
>
> > If C accepts the peering route from A instead of the A customer route
> from B then C does not propagate A's route to D. Customer propagates to
> transit.
> > Peer does not. A has to make a choice between having C as a peer and
> having C as an indirect transit provider. He can't have both. But unless C
> plays games with localprefs,
> > A can trivially express his preference using prepends. And choices like
> this are what A signed on for when he decided to peer with C instead of
> buying transit.
>
> Can you provide a white paper that covers your proposed 'BGP Improvements'
> in more detail?  This could be a decent NANOG presentation too.  I have
> always been under the impression that you can't have peering, transit, and
> customer relationships with the same upstream and expect things to work,
> with or without local preference.  I know I am missing something in these
> conversations, and have not been able to glean a better understanding from
> this thread.  Hoping someone can point me to a white paper or good NANOG
> presentation.
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/5YVBVFKVCQOIEONWM22YQMXJVS5RBQZF/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/L2V24HZMMCI54VSRSPB2Q2E4VGBT4X5S/