> > 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 <[email protected]> wrote: > > On Wed, Apr 9, 2025 at 2:01 PM Matthew Petach <[email protected]> > 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/[email protected]/message/5YVBVFKVCQOIEONWM22YQMXJVS5RBQZF/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/L2V24HZMMCI54VSRSPB2Q2E4VGBT4X5S/
