On Wed, Apr 9, 2025 at 2:01 PM Matthew Petach <mpetach@netflight.com> wrote:
If I sell connectivity to a customer, the customer is likely to want some level of assurance that their traffic will indeed deterministically pass across that link,
Well that would be your first mistake. Your BGP customer wants their packets to go where *they* tell them to go, not where you feel like sending them. As do their downstream BGP customers who don't have the luxury of calling you up and threatening to withhold payment.
I would be an unhappy customer if I discovered that my network provider believed that Heisenberg and Schrodinger were the patron saints of packet flows[0];
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.
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.. Anyway, the chief issue with Sriram's scenario comes when you add AS D, the transit provider for AS C: 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. Regards, Bill Herrin Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/