diff options
Diffstat (limited to 'doc/rfc/rfc7716.txt')
| -rw-r--r-- | doc/rfc/rfc7716.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc7716.txt b/doc/rfc/rfc7716.txt new file mode 100644 index 0000000..128474a --- /dev/null +++ b/doc/rfc/rfc7716.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Engineering Task Force (IETF) Z. Zhang +Request for Comments: 7716 L. Giuliano +Category: Standards Track E. Rosen, Ed. +ISSN: 2070-1721 Juniper Networks, Inc. + K. Subramanian + Cisco Systems, Inc. + D. Pacella + Verizon + December 2015 + + + Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures + +Abstract + + RFCs 6513, 6514, and others describe protocols and procedures that a + Service Provider (SP) may deploy in order to offer Multicast Virtual + Private Network (Multicast VPN or MVPN) service to its customers. + Some of these procedures use BGP to distribute VPN-specific multicast + routing information across a backbone network. With a small number + of relatively minor modifications, the same BGP procedures can also + be used to distribute multicast routing information that is not + specific to any VPN. Multicast that is outside the context of a VPN + is known as "Global Table Multicast", or sometimes simply as + "Internet multicast". In this document, we describe the + modifications that are needed to use the BGP-MVPN procedures for + Global Table Multicast. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7716. + + + + + + + + + + +Zhang, et al. Standards Track [Page 1] + +RFC 7716 Global Table Multicast December 2015 + + +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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided 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 . . . . . . . . . . . . . . . . . . . . . . . 22 + + + + + + + +Zhang, et al. Standards Track [Page 2] + +RFC 7716 Global Table Multicast December 2015 + + +1. Introduction + + [RFC4364] specifies architecture, protocols, and procedures that a + Service Provider (SP) can use to provide Virtual Private Network + (VPN) service to its customers. In that architecture, one or more + Customer Edge (CE) routers attach to a Provider Edge (PE) router. + Each CE router belongs to a single VPN, but CE routers from several + VPNs may attach to the same PE router. In addition, CEs from the + same VPN may attach to different PEs. BGP is used to carry VPN- + specific information among the PEs. Each PE router maintains a + separate Virtual Routing and Forwarding table (VRF) for each VPN to + which it is attached. + + [RFC6513] and [RFC6514] extend the procedures of [RFC4364] to allow + the SP to provide multicast service to its VPN customers. The + customer's multicast routing protocol (e.g., PIM) is used to exchange + multicast routing information between a CE and a PE. The PE stores a + given customer's multicast routing information in the VRF for that + customer's VPN. BGP is used to distribute certain multicast-related + control information among the PEs that attach to a given VPN, and BGP + may also be used to exchange the customer multicast routing + information itself among the PEs. + + While this multicast architecture was originally developed for VPNs, + it can also be used (with a small number of modifications to the + procedures) to distribute multicast routing information that is not + specific to VPNs. The purpose of this document is to specify the way + in which BGP-MVPN procedures can be adapted to support non-VPN + multicast. + + Multicast routing information that is not specific to VPNs is stored + in a router's "global table", rather than in a VRF; hence, it is + known as "Global Table Multicast" (GTM). GTM is sometimes more + simply called "Internet multicast". However, we will avoid that term + because it suggests that the multicast data streams are available on + the "public" Internet. The procedures for GTM can certainly be used + to support multicast on the public Internet, but they can also be + used to support multicast streams that are not public, e.g., content + distribution streams offered by content providers to paid + subscribers. For the purposes of this document, all that matters is + that the multicast routing information is maintained in a global + table rather than in a VRF. + + This architecture does assume that the network over which the + multicast streams travel can be divided into a "core network" and one + or more non-core parts of the network, which we shall call + "attachment networks". The multicast routing protocol used in the + attachment networks may not be the same as the one used in the core, + + + +Zhang, et al. Standards Track [Page 3] + +RFC 7716 Global Table Multicast December 2015 + + + so we consider there to be a "protocol boundary" between the core + network and the attachment networks. We will use the term "Protocol + Boundary Router" (PBR) to refer to the core routers that are at the + boundary. We will use the term "Attachment Router" (AR) to refer to + the routers that attach to the PBRs but are not in the core. + + This document does not make any particular set of assumptions about + the protocols that the ARs and the PBRs use to exchange unicast and + multicast routing information with each other. For instance, + multicast routing information 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. This routing information 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. + + The PBRs are not necessarily "edge routers", in the sense of + [RFC4364]. For example, they may be 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, the 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 + information that a PBR learns from the ARs attached to it is stored + in the PBR's global table. The PBRs use BGP to distribute multicast + routing and auto-discovery information among themselves. This is + done 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 that these procedures are adapted to be applicable to + the global table rather than to a VRF. Details are provided in + subsequent sections of this document. + + By supporting GTM using the BGP procedures designed for MVPN, one + obtains 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. + + + +Zhang, et al. Standards Track [Page 4] + +RFC 7716 Global Table Multicast December 2015 + + + This document not only uses MVPN procedures for GTM but also, insofar + 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 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 + multicast group addresses. See Section 3 for more details. + + 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", one + should interpret that to mean the interface between the AR and the + PBR. For GTM, where [RFC6513] and [RFC6514] talk about the + "backbone" network, one should interpret that to mean 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 sub- + sections. + +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 refer to + these simply as "MCAST-VPN routes". [RFC6514] defines the Network + Layer Reachability Information (NLRI) format for MCAST-VPN routes. + + + +Zhang, et al. Standards Track [Page 5] + +RFC 7716 Global Table Multicast December 2015 + + + 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 routes 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 + + The MVPN procedures require all MCAST-VPN routes to carry Route + Targets (RTs). When a PE router receives an MCAST-VPN route, it + processes the route in the context of a particular VRF if and only if + the route is carrying an RT that is configured as one of that VRF's + "import RTs". + + There are two different kinds of RT used in MVPN. + + o One kind of RT is carried only by the following MCAST-VPN route + types: C-multicast Shared Tree Joins, C-multicast Source Tree + Joins, and Leaf auto-discovery routes (A-D routes). This kind of + RT identifies the PE router that has been selected by the route's + originator as the "Upstream PE" or as the "Upstream Multicast Hop" + (UMH) for a particular (set of) multicast flow(s). Per [RFC6514] + and [RFC6515], this RT must be an IPv4-address-specific or IPv6- + address-specific Extended Community (EC), whose Global + Administrator field identifies the Upstream PE or the UMH. If the + Global Administrator field identifies the Upstream PE, the Local + Administrator field identifies a particular VRF in that PE. + + The GTM procedures of this document require the use of this type + of RT, in exactly the same situations where it is used in the MVPN + specification [RFC6514]. However, one adaptation is necessary: + the Local Administrator field of this kind of RT MUST always be + set to zero, thus implicitly identifying the global table rather + than identifying a VRF. We will refer to this kind of RT as an + "upstream-node-identifying RT". + + o The other kind of RT is the conventional RT first specified in + [RFC4364]. It does not necessarily identify a particular router + by address but is used to constrain the distribution of VPN routes + and to ensure that 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". + + + + + +Zhang, et al. Standards Track [Page 6] + +RFC 7716 Global Table Multicast December 2015 + + + Whereas every VRF must be configured with at least one import RT, + there has been no requirement to configure any RTs for the global + table of any router until now. As stated 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 the use of RTs in GTM are the following: + + o 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 + Administrator field identifies that PBR. + + o 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 so configured, 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, care must be taken + to ensure that the RTs configured for the global table are + distinct from any RTs used in support of MVPN (except in the case + where it is actually intended to create an "extranet" + [MVPN-extranet] in which 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 + that have been 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 are required to carry RTs. These RTs determine which VRFs import + + + +Zhang, et al. Standards Track [Page 7] + +RFC 7716 Global Table Multicast December 2015 + + + which such routes. However, 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 + determining whether a SAFI 1, 2, or 4 route is to be imported into + the global table of any PBR. + +2.3. UMH-Eligible Routes + + Section 5.1 of [RFC6513] defines procedures by which a PE router + determines 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 generally known as the "RPF neighbor" for that + flow.) It also defines procedures for determining the "Source AS" of + a particular flow. Note that 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 for + MVPN. + + For MVPN, to determine the UMH, Upstream PE, Upstream RD, and Source + AS of a flow, one looks up the C-root of the flow in a particular VRF + and finds the "UMH-eligible" routes (see Section 5.1.1 of [RFC6513]) + that "match" the C-root. From among these, one is chosen as the + "Selected UMH Route". + + For GTM, the C-root is, of course, looked up in the global table, + rather than in 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 these are the UMH-eligible routes. Otherwise, routes + of SAFI 1 or SAFI 4 are the UMH-eligible routes. For the purpose of + UMH determination, if a SAFI 1 route and a SAFI 4 route contain the + same IP prefix in their respective NLRI fields, then the two routes + are considered by the BGP best-path selection process to be + comparable. + + [RFC6513] defines procedures for determining which of the UMH- + eligible routes that match a particular C-root is to become the + Selected UMH Route. With one exception, these procedures are also + applicable to GTM. The one exception is the following. + Section 9.1.2 of [RFC6513] defines a particular method of choosing + the Upstream PE, known as "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 cannot be applied to GTM). + + In GTM, the "Upstream RD" of a multicast flow is always considered to + be zero and is NOT determined from the Selected UMH Route. + + + +Zhang, et al. Standards Track [Page 8] + +RFC 7716 Global Table Multicast December 2015 + + + The MVPN specifications require that when BGP is used for + distributing 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 generally attached to the UMH- + eligible routes by the PEs that originate the routes. + + In GTM, there are certain situations in which it is allowable to omit + the VRF Route Import EC and/or the Source AS EC from the UMH-eligible + routes. The following sub-sections specify the various 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 the procedure of this section is used, a PBR that distributes a + UMH-eligible route to other PBRs is responsible for ensuring that 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 + + Some service providers may consider it to be undesirable to have the + PBRs put the VRF Route Import EC on all the UMH-eligible routes. Or + there may be deployment scenarios in which the UMH-eligible routes + are not advertised by the PBRs at all. The procedures described in + + + +Zhang, et al. Standards Track [Page 9] + +RFC 7716 Global Table Multicast December 2015 + + + this section provide an alternative that can be used under certain + circumstances. + + The procedures in this section are OPTIONAL. + + In this alternative procedure, each PBR MUST originate a BGP route of + SAFI 1, 2, or 4 whose NLRI is an IP address of the PBR itself. This + route MUST carry a VRF Route Import EC that identifies the PBR. The + address that appears in the Global Administrator field of that EC + MUST be the same address that appears in the NLRI and in the Next Hop + field of that route. This route MUST also carry a Source AS EC + identifying the AS of the PBR. + + Whenever the PBR distributes a UMH-eligible route for which it sets + itself as Next Hop, it MUST use this same IP address as the Next Hop + of the UMH-eligible route that it used in the route discussed in the + prior paragraph. + + When the procedure in this section is used and when a PBR is + determining the Selected UMH Route for a given multicast flow, it may + find that the Selected UMH Route has no VRF Route Import EC. In this + case, the PBR will look up (in the global table) the route to the + Next Hop of the Selected UMH Route. If the route to the Next Hop has + a VRF Route Import EC, that EC will be used to determine the Upstream + PBR, just as if the EC had been attached to the Selected UMH Route. + + If recursive route resolution is required in order to resolve the + Next Hop, the Upstream PBR will be determined from the first route + with a VRF Route Import EC that is encountered during the recursive + route resolution process. (The recursive route resolution process + itself is not modified by this document.) + + The same procedure can be applied to find the Source AS, except that + the Source AS EC is used instead of the VRF Route Import EC. + + Note that this procedure is only applicable in scenarios where it is + known that the Next Hop of the UMH-eligible routes is not changed by + any router that participates in the distribution of those routes; + this procedure MUST NOT be used in any scenario where the Next Hop + may be changed between the time one PBR distributes the route and + another PBR receives it. The PBRs have no way of determining + dynamically whether the procedure is applicable in a particular + deployment; this must be made known to the PBRs by provisioning. + + Some scenarios in which this procedure can be used are: + + o All PBRs are in the same AS. + + + + +Zhang, et al. Standards Track [Page 10] + +RFC 7716 Global Table Multicast December 2015 + + + o The UMH-eligible routes are distributed among the PBRs by a Route + Reflector (that does not change the Next Hop). + + o 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 are used in scenarios where they + are not applicable, GTM will not function correctly. + +2.3.3. Non-BGP Routes as the UMH-Eligible Routes + + In particular deployment scenarios, there may be specific procedures + that can be used, in those particular scenarios, to determine the + Upstream PBR for a given multicast flow. + + Suppose 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 may still be possible, by using specific knowledge + about the deployment, to determine the Upstream PBR for a given + multicast flow. + + For example, suppose it is known that all the PBRs are in the same + OSPF area. It may be possible to determine 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. + + As another example, suppose it is known that the set of PBRs is fully + meshed via Traffic Engineering (TE) tunnels. When a PBR looks up, in + its global table, the C-root of a particular multicast flow, it may + find that the next-hop interface is a particular TE tunnel. If it + can determine the identity of the router at the other end of that TE + tunnel, it can deduce that the router is the Upstream PBR for that + flow. + + 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 + + To see why the SFS procedure cannot be applied to GTM, consider the + following example scenario. Suppose some multicast source S is homed + to both PBR1 and PBR2, and suppose that both PBRs export a route (of + SAFI 1, 2, or 4) whose NLRI is a prefix matching the address of S. + These two routes will be considered comparable by the BGP decision + process. A route reflector receiving both routes may thus choose to + redistribute just one of the routes to S, the one chosen by the best- + path algorithm. Different route reflectors may even choose different + + + +Zhang, et al. Standards Track [Page 11] + +RFC 7716 Global Table Multicast December 2015 + + + routes to redistribute (i.e., one route reflector may choose the + route to S via PBR1 as the best path, while another chooses the route + to S via PBR2 as the best path). As a result, some PBRs may receive + only the route to S via PBR1, and some may receive only the route to + S via PBR2. In that case, it is impossible to ensure that all PBRs + will choose the same route to S. + + The SFS procedure works in VPN context as long as the following + 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 and thus has an RD in + its NLRI. So the route to S via PE1 will not have the same NLRI as + the route to S via PE2. As a result, all PEs will see both routes, + and the PEs can implement a procedure that ensures that they all pick + the same route to S. + + That is, the SFS procedure of [RFC6513] relies on the UMH-eligible + routes being of SAFI 128 or 129 and relies on certain VRFs being + configured with distinct RDs. Thus, the procedure cannot be applied + to GTM. + + One might think that the SFS procedure could be applied to GTM as + long as the procedures defined in [ADD-PATH] are applied to the UMH- + eligible routes. Using the [ADD-PATH] procedures, the BGP speakers + could advertise more than one path to a given prefix. Typically, + [ADD-PATH] is used to report the n best paths, for some small value + of n. However, this is not sufficient to support SFS, as can be seen + by examining the following scenario: + + AS-X | AS-Y | AS-Z + | | + S--PBR1---ASBR1--|--ASBR2--|---ASBR5 + | \______/ | | + | / \ | | + |--PBR2---ASBR3--|--ASBR4--|---ASBR6 + | | + + In AS-X, PBR1 reports to both ASBR1 and ASBR3 that it has a route to + S. Similarly, PBR2 reports to 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 will each see eight paths (four + via ASBR2 and four via ASBR4). To avoid this explosion in the number + of paths, a BGP speaker that uses [ADD-PATH] is usually considered to + report only the n best paths. However, there is then no guarantee + that the reported set of paths will contain at least one path via + PBR1 and at least one path via PBR2. Without such a guarantee, the + SFS procedure will not work. + + + +Zhang, et al. Standards Track [Page 12] + +RFC 7716 Global Table Multicast December 2015 + + +2.4. Inclusive and Selective Tunnels + + The MVPN specifications allow multicast flows to be carried on either + Inclusive Tunnels or on Selective Tunnels. When a flow is sent on an + Inclusive Tunnel of a particular VPN, it is sent to all PEs in that + VPN. When sent on a Selective Tunnel of a particular VPN, it may be + sent to only 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 electing to use + Inclusive Tunnels for GTM should carefully consider whether sending a + multicast flow to ALL its PBRs would result in problems of scale. + 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 do not need to go to all the PBRs, the exclusive use + of Selective Tunnels may be a better option. + +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 conditions also apply to PBRs implementing GTM. + + In addition, a PBR implementing GTM is NOT required to originate an + Intra-AS I-PMSI A-D route if both of the following conditions hold: + + o The PBR is not using Inclusive Tunnels for GTM, and + + o 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. + + Please see also 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, other than those + specified in the sections on RD and RT usage (Sections 2.1 and 2.2). + + + + + + + + +Zhang, et al. Standards Track [Page 13] + +RFC 7716 Global Table Multicast December 2015 + + +2.6. S-PMSI A-D Routes + + There are no GTM-specific procedures for the origination, + distribution, and processing of these routes, other than those + specified in the sections on RD and RT usage (Sections 2.1 and 2.2). + +2.7. Leaf A-D Routes + + There are no GTM-specific procedures for the origination, + distribution, and processing of these routes, other than those + specified in the sections on RD and RT usage (Sections 2.1 and 2.2). + +2.8. Source Active A-D Routes + + Please see the sections on RD and RT usage (Sections 2.1 and 2.2) for + information 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 sub-sections of this + section. + +2.8.1. Finding the Originator of an SA A-D Route + + To carry out the procedures specified in [RFC6514] (e.g., in + Section 13.2 of that document), it is sometimes necessary for an + egress PE to determine the ingress PE that originated a given Source + Active A-D route. The procedure used in [RFC6514] to find the + originator of a Source Active A-D route assumes that no two routes + have the same RD unless they have been originated by the same PE. + However, this assumption is not valid in GTM, because each Source + Active A-D route used for GTM will have an RD of 0, and all the UMH- + eligible routes also have an RD of 0. So GTM requires a different + procedure for determining the originator of a Source Active A-D + route. + + In GTM, the procedure for determining the originating PE of a Source + Active A-D route is the following: + + o When a Source Active A-D route is originated, the originating PE + MAY attach a VRF Route Import Extended Community to the route. + + o 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. + + + + + +Zhang, et al. Standards Track [Page 14] + +RFC 7716 Global Table Multicast December 2015 + + + * 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. + + o 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 + + 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 those PBRs that are interested in GTM traffic to + group G. This can be done using the following OPTIONAL procedures: + + o 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.) + + o When a PBR creates such an import RT, it uses "RT Constraint" + procedures [RFC4684] to advertise its interest in routes that + carry this RT. + + o When a PBR originates a Source Active A-D route from its global + table, it attaches the RT described above. + + o 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. + + + +Zhang, et al. Standards Track [Page 15] + +RFC 7716 Global Table Multicast December 2015 + + + These procedures enable a PBR to automatically filter all Source + Active A-D routes that are about multicast groups in which the PBR + has no interest. + + This procedure does introduce the overhead of distributing additional + "RT Constraint" routes and therefore may not be cost-effective in all + scenarios, especially if the number of sources per ASM group is + small. This procedure 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. The "Upstream PE", "Upstream RD", and "Source AS" (as defined + in Section 5 of [RFC6513]) for the NLRI of the C-multicast route are + first determined. An IP-address-specific RT whose Global + Administrator field carries the IP address of the Upstream PE is then + 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 may 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. + + + +Zhang, et al. Standards Track [Page 16] + +RFC 7716 Global Table Multicast December 2015 + + + 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: + + o 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. + + o 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]). + + o 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]. + + o 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. + + o 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]). + + + + + + + +Zhang, et al. Standards Track [Page 17] + +RFC 7716 Global Table Multicast December 2015 + + +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. + + + + + + + +Zhang, et al. Standards Track [Page 18] + +RFC 7716 Global Table Multicast December 2015 + + +5. References + +5.1. Normative References + + [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 + + [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>. + + + + + + + + +Zhang, et al. Standards Track [Page 19] + +RFC 7716 Global Table Multicast December 2015 + + + [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 + + The authors and contributors would like to thank Rahul Aggarwal, + Huajin Jeng, Hui Ni, Yakov Rekhter, and Samir Saad for their ideas + and comments. + + + + + + + + + + + + + + + + +Zhang, et al. Standards Track [Page 20] + +RFC 7716 Global Table Multicast December 2015 + + +Contributors + + 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.com + + + + + + + + + +Zhang, et al. Standards Track [Page 21] + +RFC 7716 Global Table Multicast December 2015 + + +Authors' Addresses + + 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 + + + + + + +Zhang, et al. Standards Track [Page 22] + |