Question about mutual transit and complex BGP peering
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? 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)? Thank you. Sriram Kotikalapudi Sriram, US NIST
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-... 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
participants (2)
-
Matthew Petach
-
Sriram, Kotikalapudi (Fed)