I’ve been in this exact predicament, where I’ve been A, receiving transit from B, and peering on an IX where C also appears (and who also provides transit to B). C have added a no-export to A community onto their routes advertised to the IX route servers to force traffic via B. It’s a commercial decision to have their customers buy more transit, plain and simple.
While we may not like it because it means we must pay more for transit, we can either accept it or find another transit provider. Regards, Christopher Hawker Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: William Herrin via NANOG <nanog@lists.nanog.org> Sent: Thursday, April 10, 2025 8:15:55 AM To: Matthew Petach <mpet...@netflight.com> Cc: na...@nanog.org <na...@nanog.org>; William Herrin <b...@herrin.us> Subject: [NANOG] Re: question about peering relationships On Wed, Apr 9, 2025 at 2:01 PM Matthew Petach <mpet...@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 b...@herrin.us https://bill.herrin.us/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VOD5FB7PDBQG2IH6VIEJZD3STCMW32A2/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/33JTWWQAG5YSLJYC4DML5OFOIS4V6VOL/
