RFC 7716
Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures
RFC 7716 💖
Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures 🦋
Okay bestie, this one comes from the IETF 🌸 and it's a Standards Track document, so it's a real Internet standard, not just vibes. It was published in December 2015 🎀 under ISSN 2070-1721 ✨. The authors are Z. Zhang, L. Giuliano, E. Rosen (editor, at Juniper Networks, Inc.), K. Subramanian (at Cisco Systems, Inc.), and D. Pacella (at Verizon) 👑. The title block doesn't list anything it obsoletes or updates 💅.
Abstract ✨
Okay so, RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) can deploy to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers 🧚. Some of those procedures use BGP to pass VPN-specific multicast routing information around a backbone network 🌈. The lowkey iconic part is that with only a handful of fairly small changes, the very same BGP procedures can also distribute multicast routing information that isn't tied to any VPN at all 🫶. Multicast that lives outside the context of a VPN is called "Global Table Multicast", or sometimes just "Internet multicast" 🌍. This document explains exactly which modifications you need to use the BGP-MVPN procedures for Global Table Multicast 💜.
Status of This Memo ✨
This is an Internet Standards Track document 🎀.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💅. If you want more on Internet Standards, check out Section 2 of RFC 5741 🔥.
For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7716 🌸.
Copyright Notice 🦋
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 💖.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they stood on the publication date 📜. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 👀. Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🧾.
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Adapting MVPN Procedures to GTM . . . . . . . . . . . . . . . 5
2.1. Use of Route Distinguishers . . . . . . . . . . . . . . . 5
2.2. Use of Route Targets . . . . . . . . . . . . . . . . . . 6
2.3. UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 8
2.3.1. Routes of SAFI 1, 2, or 4 with MVPN ECs . . . . . . . 9
2.3.2. MVPN ECs on the Route to the Next Hop . . . . . . . . 9
2.3.3. Non-BGP Routes as the UMH-Eligible Routes . . . . . . 11
2.3.4. Why SFS Does Not Apply to GTM . . . . . . . . . . . . 11
2.4. Inclusive and Selective Tunnels . . . . . . . . . . . . . 13
2.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 13
2.5.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 14
2.7. Leaf A-D Routes . . . . . . . . . . . . . . . . . . . . . 14
2.8. Source Active A-D Routes . . . . . . . . . . . . . . . . 14
2.8.1. Finding the Originator of an SA A-D Route . . . . . . 14
2.8.2. Optional Additional Constraints on Distribution . . . 15
2.9. C-Multicast Source/Shared Tree Joins . . . . . . . . . . 16
3. Differences from Other MVPN-Like GTM Procedures . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Normative References . . . . . . . . . . . . . . . . . . 19
5.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 221. Introduction ✨
Okay bestie, so [RFC4364] is the spec that explains how a Service Provider (SP) can give Virtual Private Network (VPN) service to its customers 💅. In that setup, one or more Customer Edge (CE) routers hook up to a Provider Edge (PE) router. Each CE belongs to exactly one VPN, but CEs from several VPNs can plug into the same PE 🫶. CEs from the same VPN can also plug into different PEs. BGP carries the VPN-specific info between PEs, and each PE keeps its own separate Virtual Routing and Forwarding table (VRF) for every VPN it's attached to 🌸.
[RFC6513] and [RFC6514] level this up by extending the [RFC4364] procedures so the SP can offer multicast service to VPN customers 🦋. The customer's multicast routing protocol (e.g., PIM) swaps multicast routing info between a CE and a PE. The PE stores a customer's multicast routing info in the VRF for that customer's VPN. BGP spreads certain multicast-related control info among the PEs attached to a given VPN, and BGP can also be used to exchange the customer multicast routing info itself among the PEs 👑.
While this multicast architecture was originally made for VPNs, it can also be used (with a small number of modifications to the procedures) to distribute multicast routing info that isn't specific to VPNs. The purpose of this doc is to spec how BGP-MVPN procedures can be adapted to support non-VPN multicast ✨.
Multicast routing info that isn't VPN-specific lives in a router's "global table" instead of a VRF, so it's called "Global Table Multicast" (GTM) 💖. GTM is sometimes just called "Internet multicast", but we're avoiding that term because it implies the multicast streams are on the "public" Internet. GTM procedures can totally be used for public Internet multicast, but they also work for non-public streams, like content distribution streams that content providers send to paid subscribers 💜. For this doc, all that matters is that the multicast routing info is kept in a global table rather than a VRF 🎀.
This architecture does assume the network the streams travel over can be split into a "core network" and one or more non-core parts, which we'll call "attachment networks" 🧚. The multicast routing protocol in the attachment networks might not match the one in the core, so there's a "protocol boundary" between them. We'll use "Protocol Boundary Router" (PBR) for the core routers at that boundary, and "Attachment Router" (AR) for the routers that attach to the PBRs but aren't in the core.
This doc doesn't make any particular assumptions about the protocols that ARs and PBRs use to exchange unicast and multicast routing info with each other. For instance, multicast routing info could be exchanged between an AR and a PBR via PIM, IGMP, or even BGP. Multicast routing also depends on an exchange of routes that are used for looking up the path to the root of a multicast tree. That routing info could be exchanged between an AR and a PBR via IGP, via EBGP, or via IBGP [RFC6368]. Note that if IBGP is used, the "push" and "pop" procedures described in [RFC6368] are not necessary 🙈.
PBRs aren't necessarily "edge routers", in the sense of [RFC4364]. For example, they may both be Autonomous System Border Routers (ASBRs). As another example, an AR may be an "access router" attached to a PBR that is an OSPF Area Border Router (ABR). Many other deployment scenarios are possible. However, PBRs are always considered to be delimiting a "backbone" or "core" network. A multicast data stream from an AR is tunneled over the core network from an ingress PBR to one or more egress PBRs. Multicast routing info that a PBR learns from the ARs attached to it is stored in that PBR's global table. PBRs use BGP to distribute multicast routing and auto-discovery info among themselves, following the procedures of [RFC6513], [RFC6514], and other MVPN specifications, as modified in this document 🌈.
In general, PBRs follow the same BGP-MVPN procedures that PE routers follow, except these procedures are adapted to apply to the global table rather than to a VRF. Details are in the later sections of this document 💅.
By supporting GTM using the BGP procedures designed for MVPN, you get a single control plane that governs the use of both VPN and non-VPN multicast 🔥. Most of the features and characteristics of MVPN carry over automatically to GTM. These include scaling, aggregation, flexible choice of tunnel technology in the SP network, support for both segmented and non-segmented tunnels, ability to use wildcards to identify sets of multicast flows, support for the Any-Source Multicast (ASM), Source-Specific Multicast (SSM), and Bidirectional (bidir) multicast paradigms, support for both IPv4 and IPv6 multicast flows over either an IPv4 or IPv6 SP infrastructure, support for unsolicited flooded data (including support for Bootstrap Router (BSR) as an RP-to-group mapping protocol), etc. 👑
This document not only uses MVPN procedures for GTM but also, as far as possible, uses the same protocol elements, encodings, and formats. The BGP Updates for GTM thus use the same Subsequent Address Family Identifier (SAFI) and have the same Network Layer Reachability Information (NLRI) format as the BGP Updates for MVPN 🦋.
Details for supporting MVPN (either IPv4 or IPv6 MVPN traffic) over an IPv6 backbone network can be found in [RFC6515]. The procedures and encodings described therein are also applicable to GTM 🧚.
[RFC7524] extends [RFC6514] by providing procedures that allow tunnels through the core to be "segmented" at ABRs within the core. The ABR segmentation procedures are also applicable to GTM as defined in the current document. In general, the MVPN procedures of [RFC7524], adapted as specified in the current document, are applicable to GTM 💖.
[RFC7524] also defines a set of procedures for GTM. Those procedures are different from the procedures defined in the current document, and the two sets of procedures are not interoperable with each other. The two sets can co-exist in the same network, as long as they are not applied to the same multicast flows or to the same multicast group addresses. See Section 3 for more details 🎀.
Quick keyword check 🫶: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. Adapting MVPN Procedures to GTM
In general, PBRs support Global Table Multicast by using the procedures that PE routers use to support VPN multicast. For GTM, where [RFC6513] and [RFC6514] talk about the "PE-CE interface", you should read that as the interface between the AR and the PBR. For GTM, where [RFC6513] and [RFC6514] talk about the "backbone" network, you should read that as the part of the network that is delimited by the PBRs 💅.
A few adaptations to the procedures of [RFC6513] and [RFC6514] need to be made. Those adaptations are described in the following subsections 🌸.
2.1. Use of Route Distinguishers
The MVPN procedures require the use of BGP routes, defined in [RFC6514], that have a SAFI value of 5 ("MCAST-VPN"). We'll refer to these simply as "MCAST-VPN routes". [RFC6514] defines the Network Layer Reachability Information (NLRI) format for MCAST-VPN routes 🦋.
The NLRI field always begins with a "Route Type" octet, and, depending on the route type, may be followed by a Route Distinguisher (RD) field 🧚.
When a PBR originates an MCAST-VPN route in support of GTM, the RD field (for those route types where it is defined) of that route's NLRI MUST be set to zero (i.e., to 64 bits of zero). Since no VRF may have an RD of zero, this allows MCAST-VPN routes that are about GTM to be distinguished from MCAST-VPN routes that are about VPNs 💖.
2.2. Use of Route Targets 🎀
okay so the MVPN procedures require all MCAST-VPN routes to carry Route Targets (RTs) 💅 When a PE router gets an MCAST-VPN route, it only processes that route in the context of a particular VRF if and only if the route is carrying an RT that's configured as one of that VRF's "import RTs" ✨
there are two different kinds of RT used in MVPN 🦋
- one kind is carried only by these MCAST-VPN route types: C-multicast Shared Tree Joins, C-multicast Source Tree Joins, and Leaf auto-discovery routes (A-D routes). this RT tells you which PE router the originator picked as the "Upstream PE" or the "Upstream Multicast Hop" (UMH) for a particular (set of) multicast flow(s) 👑 per [RFC6514] and [RFC6515], this RT has to be an IPv4-address-specific or IPv6-address-specific Extended Community (EC), and its
Global Administratorfield identifies the Upstream PE or the UMH. ifGlobal Administratoridentifies the Upstream PE, thenLocal Administratoridentifies a particular VRF in that PE.
the GTM procedures in this document require this type of RT, in exactly the same situations where the MVPN specification [RFC6514] uses it 🌸 but there's one adaptation: the Local Administrator field of this kind of RT MUST always be set to zero, so it implicitly identifies the global table instead of a VRF. we'll call this kind of RT an "upstream-node-identifying RT" 💜
- the other kind is the conventional RT first specified in [RFC4364] 🧚 it doesn't necessarily identify a particular router by address. it's used to constrain the distribution of VPN routes and to make sure a given VPN route is processed in the context of a given VRF if and only if the route is carrying an RT that has been configured as one of that VRF's "import RTs" 💖
every VRF must be configured with at least one import RT, but there hasn't been any requirement to configure RTs for the global table of any router until now 🌈 as we said above, this document makes the use of upstream-node-identifying RTs mandatory for GTM. this document makes the use of non-upstream-node-identifying RTs OPTIONAL for GTM 🫶
the procedures for using RTs in GTM are the following:
- if the global table of a particular PBR is NOT configured with any import RTs, then a received MCAST-VPN route is processed in the context of the global table only if it is carrying no RTs, or if it is carrying an upstream-node-identifying RT whose
Global Administratorfield identifies that PBR 🍓 - the global table in each PBR MAY be configured with (a) a set of export RTs to be attached to MCAST-VPN routes that are originated to support GTM, and (b) a set of import RTs for GTM.
if the global table of a given PBR has been configured that way, the PBR will process a received MCAST-VPN route in the context of the global table if and only if the route carries an RT that is one of the global table's import RTs, or if the route carries an upstream-node-identifying RT whose Global Administrator field identifies the PBR ✨
if the global tables are configured with RTs, take care that those RTs are distinct from any RTs used to support MVPN. the one exception is when you actually want to create an "extranet" [MVPN-extranet], where some sources are reachable in global table context while others are reachable in VPN context 👀
the "RT Constraint" procedures of [RFC4684] MAY be used to constrain the distribution of MCAST-VPN routes (or other routes) that carry RTs configured as import RTs for GTM. (this includes the upstream-node-identifying RTs.) 🦋
N.B.: if the "RT Constraint" procedures of [RFC4684] are deployed, but the MCAST-VPN routes are not carrying RTs, then proper operation requires the "default behavior" specified for the MCAST-VPN address family in Section 3 ("Default Behavior") of [RTC_without_RTs]. 🙈
in [RFC6513], the UMH-eligible routes (see Section 5.1.1 of [RFC6513], "Eligible Routes for UMH Selection") are generally routes of SAFI 128 (Labeled VPN-IP routes) or 129 (VPN-IP multicast routes), and they're required to carry RTs. those RTs decide which VRFs import which routes 💅 but for GTM, when the UMH-eligible routes may be routes of SAFI 1, 2, or 4, the routes are NOT required to carry RTs. this document does NOT specify any new rules for deciding whether a SAFI 1, 2, or 4 route gets imported into the global table of any PBR. no new rules, no drama 🌸
2.3. UMH-Eligible Routes 💌
Section 5.1 of [RFC6513] defines the procedures a PE router uses to figure out the "C-root", the "Upstream Multicast Hop" (UMH), the "Upstream PE", and the "Upstream RD" of a given multicast flow. (in non-VPN multicast documents, the UMH of a multicast flow at a particular router is usually called the "RPF neighbor" for that flow 🧚) it also defines procedures for figuring out the "Source AS" of a particular flow. quick heads-up: in GTM, the "Upstream PE" is actually the "Upstream PBR" 👑
the definition of the C-root of a flow is the same for GTM as it is for MVPN ✨
for MVPN, to determine the UMH, Upstream PE, Upstream RD, and Source AS of a flow, you look up the C-root of the flow in a particular VRF, then find the "UMH-eligible" routes (see Section 5.1.1 of [RFC6513]) that "match" the C-root. from those, one is chosen as the "Selected UMH Route" 🎀
for GTM, the C-root is obviously looked up in the global table instead of a VRF. for MVPN, the UMH-eligible routes are routes of SAFI 128 or 129. for GTM, the UMH-eligible routes are routes of SAFI 1, SAFI 4, or SAFI 2. if the global table has imported routes of SAFI 2, then those are the UMH-eligible routes. otherwise, routes of SAFI 1 or SAFI 4 are the UMH-eligible routes. for UMH determination, if a SAFI 1 route and a SAFI 4 route contain the same IP prefix in their respective NLRI fields, the BGP best-path selection process considers the two routes comparable 🦋
[RFC6513] defines procedures for deciding which of the UMH-eligible routes that match a particular C-root becomes the Selected UMH Route. with one exception, these procedures also apply to GTM. the exception is this: Section 9.1.2 of [RFC6513] defines a method for choosing the Upstream PE called "Single Forwarder Selection" (SFS). this procedure MUST NOT be used for GTM (see Section 2.3.4 for an explanation of why the SFS procedure can't be applied to GTM) 🙅♀️💀
in GTM, the "Upstream RD" of a multicast flow is always considered to be zero, and it is NOT determined from the Selected UMH Route 🌈
the MVPN specifications require that, when BGP is used to distribute multicast routing information, the UMH-eligible routes MUST carry the VRF Route Import EC and the Source AS EC. to determine the Upstream PE and Source AS for a particular multicast flow, the Upstream PE and Source AS are determined, respectively, from the VRF Route Import EC and the Source AS EC of the Selected UMH Route for that flow. these ECs are usually attached to the UMH-eligible routes by the PEs that originate the routes 💖
in GTM, there are certain situations where it's allowed to leave out the VRF Route Import EC and/or the Source AS EC from the UMH-eligible routes 🫶 the following sub-sections spell out the different options for determining the Upstream PBR and the Source AS in GTM 🍓
the procedures in Section 2.3.1 MUST be implemented. the procedures in Sections 2.3.2 and 2.3.3 are OPTIONAL to implement. it should be noted that while the optional procedures may be useful in particular deployment scenarios, there is always the potential for interoperability problems when relying on OPTIONAL procedures 🌸
2.3.1. Routes of SAFI 1, 2, or 4 with MVPN ECs ✨
if the UMH-eligible routes have a SAFI of 1, 2, or 4, then they MAY carry the VRF Route Import EC and/or the Source AS EC. if the Selected UMH Route is a route of SAFI 1, 2, or 4 that carries the VRF Route Import EC, then the Upstream PBR is determined from that EC. similarly, if the Selected UMH Route is a route of SAFI 1, 2, or 4 that carries the Source AS EC, the Source AS is determined from that EC 💅
when this procedure is used, a PBR that distributes a UMH-eligible route to other PBRs is responsible for making sure the VRF Route Import and Source AS ECs are attached to it 🎀
if the selected UMH-eligible route has a SAFI of 1, 2, or 4 but is not carrying a VRF Route Import EC, then the Upstream PBR is determined as specified in Sections 2.3.2 or 2.3.3 🦋
if the selected UMH-eligible route has a SAFI of 1, 2, or 4 but is not carrying a Source AS EC, then the Source AS is considered to be the local AS 🧚
2.3.2. MVPN ECs on the Route to the Next Hop ✨
Okay so some service providers think it's kinda undesirable to have the PBRs slap the VRF Route Import EC on all the UMH-eligible routes 🙅♀️. And there might be deployments where the PBRs don't advertise the UMH-eligible routes at all 💀. This section gives you an alternative for those situations 🦋.
The procedures in this section are OPTIONAL. 💅
Here's the deal: each PBR MUST originate a BGP route of SAFI 1, 2, or 4 whose NLRI is an IP address of the PBR itself. 🌸 That route MUST carry a VRF Route Import EC that identifies the PBR. The address in the Global Administrator field of that EC MUST be the same address that shows up in the NLRI and in the Next Hop field of that route. It also MUST carry a Source AS EC identifying the AS of the PBR.
Whenever the PBR distributes a UMH-eligible route where it sets itself as the Next Hop, it MUST use that same IP address as the Next Hop of the UMH-eligible route, the same one it used in the route from the paragraph above. 🔥
When this procedure is in use and a PBR is figuring out the Selected UMH Route for a given multicast flow, the Selected UMH Route might not have a VRF Route Import EC. 🤔 If that happens, the PBR looks up the route to the Next Hop of the Selected UMH Route in the global table. If that route has a VRF Route Import EC, the PBR uses that EC to determine the Upstream PBR, just like the EC was attached to the Selected UMH Route. Main character energy, honestly 👑.
If recursive route resolution is needed to resolve the Next Hop, the Upstream PBR is determined from the first route with a VRF Route Import EC that gets encountered during that recursive process. (The recursive route resolution process itself is not modified by this document. 🙈)
The same procedure can be used to find the Source AS, except the Source AS EC gets used instead of the VRF Route Import EC. 🧚
Now, this one is important bestie 😭. This procedure only works in scenarios where it's known that the Next Hop of the UMH-eligible routes doesn't get changed by any router that takes part in distributing those routes. This procedure MUST NOT be used in any scenario where the Next Hop might change between the moment one PBR distributes the route and the moment another PBR receives it. The PBRs have no way to figure out on their own whether the procedure fits a particular deployment, so someone has to tell them through provisioning. 🍓
Some scenarios where this procedure can be used:
- All PBRs are in the same AS.
- The UMH-eligible routes are distributed among the PBRs by a Route Reflector (that does not change the Next Hop).
- The UMH-eligible routes are distributed from one AS to another through ASBRs that do not change the Next Hop.
If the procedures of this section get used in scenarios where they don't apply, GTM will not function correctly. 💀💔
2.3.3. Non-BGP Routes as the UMH-Eligible Routes 🦋
In particular deployment scenarios, there might be specific procedures that can be used, in those particular scenarios, to determine the Upstream PBR for a given multicast flow. 🌈
Say the PBRs neither put the VRF Route Import EC on the UMH-eligible routes, nor distribute BGP routes with their own addresses in the NLRI. It might still be possible, by using specific knowledge about the deployment, to determine the Upstream PBR for a given multicast flow. 🧠
For example, say it's known that all the PBRs are in the same OSPF area. Then it might be possible to figure out the Upstream PBR for a given multicast flow by looking at the link state database to see which router is attached to the flow's C-root. 🔍
Another example: say it's known that the set of PBRs is fully meshed via Traffic Engineering (TE) tunnels. When a PBR looks up the C-root of a particular multicast flow in its global table, it might find that the next-hop interface is a particular TE tunnel. If it can work out the identity of the router at the other end of that TE tunnel, it can deduce that this router is the Upstream PBR for that flow. Galaxy brain stuff 🌌.
This is not an exhaustive set of examples. Any procedure that correctly determines the Upstream PBR in a given deployment scenario MAY be used in that scenario. ✨
2.3.4. Why SFS Does Not Apply to GTM 🙅♀️
Let me show you why the SFS procedure can't be applied to GTM, okay? 🎀 Imagine some multicast source S is homed to both PBR1 and PBR2, and both PBRs export a route (of SAFI 1, 2, or 4) whose NLRI is a prefix matching the address of S. 😳 Both routes are going to be considered comparable by the BGP decision process. So a route reflector that receives both routes may choose to redistribute just one of them, the one the best-path algorithm picks. Different route reflectors might even pick different routes to redistribute. One route reflector could choose the route to S via PBR1 as the best path, while another picks the route to S via PBR2. The result? Some PBRs only receive the route to S via PBR1, and some only receive the route to S via PBR2. 💀 At that point, there's no way to make sure all PBRs choose the same route to S. Chaos, literally.
The SFS procedure does work in a VPN context, as long as this assumption holds: if S is homed to VRF-x in PE1 and to VRF-y in PE2, then VRF-x and VRF-y have been configured with different RDs. 🔑 In VPN context, the route to S is of SAFI 128 or 129, so it has an RD in its NLRI. That means the route to S via PE1 won't have the same NLRI as the route to S via PE2. So all PEs see both routes, and they can run a procedure that makes sure they all pick the same route to S. Iconic 👑.
So, to put it simply: the SFS procedure of [RFC6513] relies on the UMH-eligible routes being of SAFI 128 or 129, and it relies on certain VRFs being configured with distinct RDs. Since GTM doesn't meet those requirements, the procedure cannot be applied to GTM. 🫶
Someone might think the SFS procedure could work for GTM as long as the procedures defined in [ADD-PATH] get applied to the UMH-eligible routes. With the [ADD-PATH] procedures, BGP speakers can advertise more than one path to a given prefix. Usually [ADD-PATH] is used to report the n best paths, for some small value of n. 🤏 But that's not enough to support SFS, and this scenario shows why:
AS-X | AS-Y | AS-Z
| |
S--PBR1---ASBR1--|--ASBR2--|---ASBR5
| \______/ | |
| / \ | |
|--PBR2---ASBR3--|--ASBR4--|---ASBR6
| |In AS-X, PBR1 tells both ASBR1 and ASBR3 that it has a route to S. Similarly, PBR2 tells both ASBR1 and ASBR3 that it has a route to S. Using the procedures in [ADD-PATH], ASBR1 reports both routes to ASBR2, and ASBR3 reports both routes to ASBR4. Now AS-Y sees 4 paths to S. 😱 The AS-Z ASBRs each see eight paths (four via ASBR2 and four via ASBR4). To stop this explosion in the number of paths, a BGP speaker that uses [ADD-PATH] is usually considered to report only the n best paths. But then there's no guarantee the reported set of paths includes at least one path via PBR1 and at least one path via PBR2. Without that guarantee, the SFS procedure won't work. 🥲
2.4. Inclusive and Selective Tunnels 🌸
The MVPN specifications let multicast flows be carried on either Inclusive Tunnels or Selective Tunnels. When a flow goes out on an Inclusive Tunnel of a particular VPN, it gets sent to all PEs in that VPN. When it goes out on a Selective Tunnel of a particular VPN, it may only go to a subset of the PEs in that VPN. 🎯
This document allows the use of either Inclusive Tunnels or Selective Tunnels for GTM. 💖 However, any service provider choosing Inclusive Tunnels for GTM should think hard about whether sending a multicast flow to ALL its PBRs would cause scale problems. There are potentially many more PBRs for GTM than PEs for a particular VPN. If the set of PBRs is large and growing, but most multicast flows don't need to reach all the PBRs, using Selective Tunnels exclusively might be the better move 🧐.
2.5. I-PMSI A-D Routes ✨
2.5.1. Intra-AS I-PMSI A-D Routes 🩷
Per [RFC6514], there are certain conditions under which it is NOT required for a PE router implementing MVPN to originate one or more Intra-AS Inclusive Provider Multicast Service Interface (I-PMSI) A-D routes. These same conditions also apply to PBRs implementing GTM. 🙌
On top of that, a PBR implementing GTM is NOT required to originate an Intra-AS I-PMSI A-D route if both of the following conditions hold:
- The PBR is not using Inclusive Tunnels for GTM, and
- The distribution of the C-multicast Shared Tree Join and C-multicast Source Tree Join routes is done in such a manner that the Next Hop of those routes does not change.
Also check out the sections on RD and RT usage (Sections 2.1 and 2.2, respectively) 💜.
2.5.2. Inter-AS I-PMSI A-D Routes 🌈
There are no GTM-specific procedures for the origination, distribution, and processing of these routes. The only rules that apply are the ones in the sections on RD and RT usage (Sections 2.1 and 2.2). 🍓
2.6. S-PMSI A-D Routes 🦋
There are no GTM-specific procedures for the origination, distribution, and processing of these routes. Only the rules in the sections on RD and RT usage (Sections 2.1 and 2.2) apply. 🧚
2.7. Leaf A-D Routes 🌷
Same deal here 💅. There are no GTM-specific procedures for the origination, distribution, and processing of these routes, other than the ones in the sections on RD and RT usage (Sections 2.1 and 2.2).
2.8. Source Active A-D Routes 🔥
Please check the sections on RD and RT usage (Sections 2.1 and 2.2) for info that applies to the origination and distribution of Source Active A-D routes. 🎀 Additional procedures governing the use of Source Active A-D routes are given in the subsections of this section. 🫶
2.8.1. Finding the Originator of an SA A-D Route ✨
okay so, to do the stuff in [RFC6514] (like Section 13.2 of that doc 💅), an egress PE sometimes needs to figure out which ingress PE originally made a given Source Active A-D route 🔍. The [RFC6514] method for this quietly assumes that no two routes have the same RD unless the same PE originated them. But that assumption breaks in GTM, bestie 🙈, because every Source Active A-D route used for GTM has an RD of 0, and all the UMH-eligible routes also have an RD of 0. So GTM needs its own way to find the originator 💖
In GTM, the procedure for determining the originating PE of a Source Active A-D route goes like this:
- When a Source Active A-D route is originated, the originating PE MAY attach a VRF Route Import Extended Community to the route.
- When a Source Active A-D route is distributed by one BGP speaker to another, then:
- If the Source Active A-D route does not carry the VRF Route Import EC, the BGP speaker distributing the route MUST NOT change the route's Next Hop field.
- If the Source Active A-D route does carry the VRF Route Import EC, the BGP speaker distributing the route MAY change the route's Next Hop field to itself.
- When an egress PE needs to determine the originator of a Source Active A-D route, then:
- If the Source Active A-D route carries the VRF Route Import EC, the originating PE is the PE identified in the Global Administrator field of that EC.
- If the Source Active A-D route does not carry the VRF Route Import EC, the originating PE is the PE identified in the route's Next Hop field.
2.8.2. Optional Additional Constraints on Distribution 🦋
okay this one is giving efficiency 🧚 If some site has receivers for a particular ASM group G, then it is possible (by the procedures of [RFC6514]) that every PBR attached to a site with a source for group G will originate a Source Active A-D route whose NLRI identifies that source and group. These Source Active A-D routes may be distributed to every PBR. If only a relatively small number of PBRs are actually interested in traffic from group G, but there are many sources for group G, this could result in a large number of (S,G) Source Active A-D routes being installed in a large number of PBRs that have no need of them 😭
For GTM, it is possible to constrain the distribution of (S,G) Source Active A-D routes to just the PBRs that are interested in GTM traffic to group G. This can be done using the following OPTIONAL procedures:
- If a PBR originates a C-multicast Shared Tree Join whose NLRI contains
(RD=0,*,G), then it dynamically creates an import RT for its global table, where the Global Administrator field of the RT contains the group address G, and the Local Administrator field contains zero. (Note that an IPv6-address-specific RT would need to be used if the group address is an IPv6 address.) - When a PBR creates such an import RT, it uses "RT Constraint" procedures [RFC4684] to advertise its interest in routes that carry this RT.
- When a PBR originates a Source Active A-D route from its global table, it attaches the RT described above.
- When the C-multicast Shared Tree Join is withdrawn, so is the corresponding RT constrain route, and the corresponding RT is removed as an import RT of its global table.
These procedures let a PBR automatically filter out all Source Active A-D routes about multicast groups it has no interest in 🙌
This procedure does add overhead, since it means distributing additional "RT Constraint" routes. So it may not be cost-effective in every scenario, especially if the number of sources per ASM group is small. It may also result in increased join latency ⚠️
2.9. C-Multicast Source/Shared Tree Joins 🌈
Section 11.1.3 of [RFC6514] describes how to determine the IP-address-specific RT(s) that should be attached to a C-multicast route. First, the "Upstream PE", "Upstream RD", and "Source AS" (as defined in Section 5 of [RFC6513]) for the NLRI of the C-multicast route get determined. Then an IP-address-specific RT whose Global Administrator field carries the IP address of the Upstream PE gets attached to the C-multicast route. This procedure also applies to GTM, except that the "Upstream PE" is actually an "Upstream PBR" 💅
Section 11.1.3 of [RFC6514] also specifies that a second IP-address-specific RT be attached to the C-multicast route, if the Source AS of the NLRI of that route is different than the AS of the PE originating the route. The procedure for creating this RT can be summarized as:
- (a) Determine the Upstream PE, Upstream RD, and Source AS corresponding to the NLRI of the route.
- (b) Find the corresponding Inter-AS or Intra-AS I-PMSI A-D route based on (a).
- (c) Find the Next Hop of that A-D route.
- (d) Place the IP address of that Next Hop in the Global Administrator field of the RT.
However, for GTM, in scenarios where it is known a priori by a PBR that the Next Hop of the C-multicast Source/Shared Tree Joins does not change during the distribution of those routes, the second RT (the one based on the Next Hop of an I-PMSI A-D route) is not needed and should not be present. In other scenarios, the procedure of Section 11.1.3 of [RFC6514] (as modified by Sections 2.1 and 2.2 of this document) is applied by the PBRs 🫶
3. Differences from Other MVPN-Like GTM Procedures ✨
[RFC7524] also defines a procedure for GTM that is based on the BGP procedures that were developed for MVPN.
However, the GTM procedures of [RFC7524] are different than and are NOT interoperable with the procedures defined in this document 🙅♀️
The two sets of procedures can co-exist in the same network, as long as they are not applied to the same multicast flows or to the same ASM multicast group addresses.
Some of the major differences between the two sets of procedures are the following:
- The procedures for GTM described in [RFC7524] do not use C-multicast Shared Tree Joins or C-multicast Source Tree Joins at all. The procedures of this document use these C-multicast routes for GTM, setting the RD field of the NLRI to zero.
- The procedures for GTM described in [RFC7524] use Leaf A-D routes instead of C-multicast Shared/Source Tree Join routes. Leaf A-D routes used in that manner can be distinguished from Leaf A-D routes used as specified in [RFC6514] by means of the NLRI format; [RFC7524] defines a new NLRI format for Leaf A-D routes. Whether or not a given Leaf A-D route is being used according to the procedures described in [RFC7524] can be determined from its NLRI. (See Section 6.2.2 ("Leaf A-D Route for Global Table Multicast") of [RFC7524].)
- The Leaf A-D routes used by the current document contain an NLRI that is in the format defined in [RFC6514], NOT in the format as defined in [RFC7524]. The procedures assumed by this document for originating and processing Leaf A-D routes are as specified in [RFC6514], NOT as specified in [RFC7524].
- The current document uses an RD value of zero in the NLRI in order to indicate that a particular route is about a Global Table Multicast rather than a VPN multicast. No other semantics are inferred from the fact that RD is zero. [RFC7524] uses two different RD values in its GTM procedures, with semantic differences that depend upon the RD values.
- In order for both sets of procedures to co-exist in the same network, the PBRs MUST be provisioned so that for any given IP group address in the global table, all egress PBRs use the same set of procedures for that group address (i.e., for group G, either all egress PBRs use the GTM procedures of this document or all egress PBRs use the GTM procedures of [RFC7524]).
4. Security Considerations 🔒
The security considerations of this document are primarily the security considerations of the base protocols, as discussed in [RFC6514], [RFC4601], and [RFC5294].
The protocols and procedures described in this document make use of a type of route (routes with the "MCAST-VPN" BGP SAFI) that was originally designed for use in VPN contexts only. The protocols and procedures described in this document also make use of various BGP path attributes and extended communities (VRF Route Import Extended Community, Source AS Extended Community, and Route Target Extended Community) that were originally intended for use in VPN contexts. If these routes, attributes, and/or extended communities leak out into the wild, multicast data flows may be distributed in an unintended and/or unauthorized manner 💀
When VPNs are provisioned, each VRF is configured with import RTs and export RTs. These RTs constrain the distribution and the import of the VPN routes, making it difficult to cause a route to be distributed to and imported by a VRF that is not authorized to import that route. Additionally, VPN routes do not go into the "global table" with the "ordinary Internet routes" (i.e., non-VPN routes), and non-VPN routes do not impact the flow of multicast data within a VPN. In GTM, some of these protections against improper distribution/import of the routes is lost -- import of the routes is not restricted to VRFs, and the RT infrastructure that controls the distribution of routes among the VRFs is not present when routes are exported from and imported into global tables.
Internet Service Providers often make extensive use of BGP extended communities, sometimes adding, deleting, and/or modifying a route's extended communities as the route is distributed throughout the network. Care should be taken to avoid deleting or modifying the VRF Route Import Extended Community and Source AS Extended Community. Incorrect manipulation of these extended communities may result in multicast streams being lost or misrouted 😱
The procedures of this document require certain BGP routes to carry IP multicast group addresses. Generally, such group addresses are only valid within a certain scope. If a BGP route containing a group address is distributed outside the boundaries where the group address is meaningful, unauthorized distribution of multicast data flows may occur.
5. References 📚
5.1. Normative References
okay so these are the must-read docs the spec leans on, bestie 📚✨ you can't skip these 😭
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
[RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure
Addresses in BGP Updates for Multicast VPN", RFC 6515,
DOI 10.17487/RFC6515, February 2012,
<http://www.rfc-editor.org/info/rfc6515>.5.2. Informative References
these ones are the extra reading for when you want the deeper lore 🧚💜 some of them are still works in progress btw
[ADD-PATH] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", Work in
Progress, draft-ietf-idr-add-paths-12, November 2015.
[MVPN-extranet]
Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
Morin, "Extranet Multicast in BGP/IP MPLS VPNs", Work in
Progress, draft-ietf-bess-mvpn-extranet-04, November 2015.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <http://www.rfc-editor.org/info/rfc4684>.
[RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", RFC 5294,
DOI 10.17487/RFC5294, August 2008,
<http://www.rfc-editor.org/info/rfc5294>.
[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T.
Yamagata, "Internal BGP as the Provider/Customer Edge
Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 6368, DOI 10.17487/RFC6368, September 2011,
<http://www.rfc-editor.org/info/rfc6368>.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<http://www.rfc-editor.org/info/rfc7524>.
[RTC_without_RTs]
Rosen, E., Ed., Patel, K., Haas, J., and R. Raszuk, "Route
Target Constrained Distribution of Routes with no Route
Targets", Work in Progress, draft-ietf-idr-rtc-no-rt-04,
November 2015.Acknowledgments ✨
big thank-you hugs 🫶 to Rahul Aggarwal, Huajin Jeng, Hui Ni, Yakov Rekhter, and Samir Saad, who all gave ideas and comments. The authors and contributors literally couldn't have done it without them 💖
Contributors 🌸
these are the people who helped write the spec, and their details are right here 💌
Jason Schiller
Google
Suite 400
1818 Library Street
Reston, Virginia 20190
United States
Email: jschiller@google.com
Zhenbin Li
Huawei Technologies
Huawei Blvd., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Wei Meng
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: meng.wei2@zte.com.cn,vally.meng@gmail.com
Cui Wang
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: wang.cui1@zte.com.cn
Shunwan Zhuang
Huawei Technologies
Huawei Blvd., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.comAuthors' Addresses 💅
and finally, the authors, with their contact info so you can slide into their inboxes 🦋
Zhaohui Zhang
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts 01886
United States
Email: zzhang@juniper.net
Lenny Giuliano
Juniper Networks, Inc.
2251 Corporate Park Drive
Herndon, Virginia 20171
United States
Email: lenny@juniper.net
Eric C. Rosen (editor)
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts 01886
United States
Email: erosen@juniper.net
Karthik Subramanian
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134
United States
Email: kartsubr@cisco.com
Dante J. Pacella
Verizon
22001 Loudoun County Parkway
Ashburn, Virginia 95134
United States
Email: dante.j.pacella@verizonbusiness.com📦 where this page comes from
- ietf: rfc7716 2015-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms