nanog mailing list archives

[NANOG] Re: question about peering relationships


From: Christopher Hawker via NANOG <nanog () lists nanog org>
Date: Thu, 10 Apr 2025 00:21:04 +0000

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 <mpetach () netflight com>
Cc: nanog () nanog org <nanog () nanog org>; William Herrin <bill () herrin us>
Subject: [NANOG] Re: question about peering relationships

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/
_______________________________________________
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/

Current thread: