Re: Question about mutual transit and complex BGP peering

[Matthew Petach <mpetach () netflight com>]

On Mon, Apr 22, 2024 at 7:35 AM Sriram, Kotikalapudi (Fed) via NANOG <
nanog () nanog org> wrote:

> Requesting responses to the following questions. Would be helpful in some
> IETF work in progress.
>
> Q1: Consider an AS peering relationship that is complex (or hybrid)
> meaning, for example, provider-to-customer (P2C) for one set of prefixes
> and lateral peers (i.e., transit-free peer-to-peer (P2P)) for another set
> of prefixes.  Are these diverse relationships usually segregated, i.e., P2C
> on one BGP session and P2P on another?  How often they might co-exist
> within one single BGP session?
Every time I've been in relationships like this, the fundamental answer is
always "follow the money".

If there's dollars flowing relative to the "provider-to-customer"
relationship, but no dollars flowing along the "peer-to-peer" relationship,
you need a solid way to determine which bits are taking the zero-dollar
pathway, and which bits are taking the non-zero-dollar pathway.

Whatever means are available to positively distinguish the traffic on an
unambiguous basis that both networks agree on is what determines the setup.

In many cases, separate physical ports with separate BGP sessions (and
sometimes even separate VRFs) is the only way that both parties fully trust
all the right bits
are being accounted for in each case.

In other relationships, flow data is considered adequate to determine how
much traffic is zero dollar, and how much traffic is non-zero dollar.  In
that case, it can be a single BGP session, single port.



> Q2: Consider an AS peering relationship that is mutual transit (i.e., P2C
> relationship in each direction for all prefixes).  Is this supported within
> one single BGP session?  How often the ASes might setup two separate BGP
> sessions between them -- one for P2C in one direction (AS A to AS B) and
> the other for P2C in the opposite direction (AS B to AS A)?

This is just a variant of a normal peer-to-peer relationship, most likely
with a traffic ratio involved.
In most of these situations, as long as the traffic is within the defined
ratio, accounting for the
bits isn't worth it; sending a bill from A to B for $X, and a different
bill from B to A for $+$Y where $Y is
generally much smaller than $X is more headache than it's worth.
And once the ratio goes outside of the prescribed range, you're not really
mutual transit anymore, you're provider to customer,
and the only wrinkle is which one considers themselves the provider, and
which considers themselves the customer.
Witness Level 3 versus Comcast versus Netflix from years ago:
https://arstechnica.com/tech-policy/2010/12/comcastlevel3/
https://publicknowledge.org/netflix-cdn-v-the-cable-guys-or-comcast-v-level-3-part-deux-peering-payback/

Again--when everything is within ratio, and pipes aren't full, no need for
separate ports or separate BGP
sessions.

Once things start to fill up, though, then things get ugly.  That's when
different sessions come into play,
with some traffic being shunted to congested sessions, while the two sides
battle it out.

It still comes down to the same fundamental rule, though--follow the
money.   ^_^;

Thanks!

Matt




> Thank you.
>
> Sriram
> Kotikalapudi Sriram, US NIST