nanog mailing list archives

[NANOG] Re: question about peering relationships


From: Matthew Petach via NANOG <nanog () lists nanog org>
Date: Wed, 9 Apr 2025 10:16:56 -0700

On Wed, Apr 9, 2025 at 8:31 AM William Herrin via NANOG <
nanog () lists nanog org> wrote:

On Mon, Apr 7, 2025 at 8:10 AM Elmar K. Bins via NANOG
<nanog () lists nanog org> wrote:
nanog () lists nanog org (Sriram, Kotikalapudi (Fed) via NANOG) wrote:
Does the following ever happen in reality? Do you think it is strange
and unlikely?
The lateral (i.e., non-transit) peer of an AS is also the transit
provider of the AS's transit provider.  Example: AS A has AS B as a transit
provider and AS C as a lateral peer, and AS C is a transit provider of AS B.

Yes, and it's very often a mess traffic-engineering wise...

Hi Elmar,

Would you mind discussing this further and offering examples of some
of the traffic engineering challenges?


[...description of default BGP behaviour elided...]


Now, if one of the networks is playing local pref games, which they
shouldn't be doing, then they may misroute packets the long way around
the planet. But that's their fault for playing local pref games.


Bill--can you clarify why you feel setting localpref values for peers
differently from customers
is something ISPs "shouldn't be doing?"

If I'm an ISP (call me ASN Ishmael....er, ASN A), and I have a customer,
ASN B, who has a
customer, ASN C.  I also have a peer, D, that provides service to their
customer, ASN C.

I hear ASN C's prefixes with equal AS-PATH length from ASN D and ASN B;
default BGP
behaviour looks for tie breakers further down the decision pathway.

However, if I send the traffic through ASN D, as a peer, I make no revenue
from carrying
that traffic.  If I send the traffic via ASN B, however, I earn revenue for
passing the traffic
along the customer, assume 95th percentile billed, link.

Is it your assertion that as an ISP, as a provider of services to my
customers, I should leave
it up to tie-breaking heuristics further and further down the BGP decision
tree as to whether
I can earn money by carrying traffic or not?
Or do you perhaps see some wisdom in preferring to send traffic through my
customer's links
when possible, so that revenue can be earned to keep the company afloat,
rather than passing
it for free through a (probably competitor's) peering link, who then hands
it to the destination?
If peer ASN D is also a competitor of mine, if I let BGP toss the coin for
me, there's a good chance
in doing so I've taken money out of my bank account, and handed it to my
competitor.

To paraphrase Randy Bush, "I highly encourage my competition to follow your
advice."   ;)



Regards,
Bill Herrin


Thanks!

Matt

PS--yes, I know the alternative is to put filter lists on your peering
sessions that actively drop any
ASNs that happen to be within your downstream customer cone, rather than
messing with localprefs.
However, that increases the fragility of your connectivity mesh, because if
ASN C's link to ASN B drops,
you're now black-holing them; they can reach the rest of the internet via
ASN D, but they can't reach you,
because you're filtering out their announcements at your peering edge.
Whups.  Maybe localprefs aren't
such an evil thing after all...  ^_^;
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/Q3Q3MJCJTYHYAUGO737JLNV4A6UI45O7/

Current thread: