idnits 2.17.1 draft-ietf-bess-mvpn-global-table-mcast-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2015) is 3202 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-10 == Outdated reference: A later version (-07) exists of draft-ietf-bess-mvpn-extranet-02 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group Z. Zhang 3 Internet-Draft L. Giuliano 4 Intended status: Standards Track E. Rosen, Ed. 5 Expires: January 21, 2016 Juniper Networks, Inc. 6 K. Subramanian 7 Cisco Systems, Inc. 8 D. Pacella 9 Verizon 10 July 20, 2015 12 Global Table Multicast with BGP-MVPN Procedures 13 draft-ietf-bess-mvpn-global-table-mcast-02 15 Abstract 17 RFC6513, RFC6514, and other RFCs describe protocols and procedures 18 which a Service Provider (SP) may deploy in order offer Multicast 19 Virtual Private Network (Multicast VPN or MVPN) service to its 20 customers. Some of these procedures use BGP to distribute VPN- 21 specific multicast routing information across a backbone network. 22 With a small number of relatively minor modifications, the very same 23 BGP procedures can also be used to distribute multicast routing 24 information that is not specific to any VPN. Multicast that is 25 outside the context of a VPN is known as "Global Table Multicast", or 26 sometimes simply as "Internet multicast". In this document, we 27 describe the modifications that are needed to use the MVPN BGP 28 procedures for Global Table Multicast. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 21, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Adapting MVPN Procedures to GTM . . . . . . . . . . . . . . . 5 66 2.1. Use of Route Distinguishers . . . . . . . . . . . . . . . 5 67 2.2. Use of Route Targets . . . . . . . . . . . . . . . . . . 6 68 2.3. UMH-eligible Routes . . . . . . . . . . . . . . . . . . . 8 69 2.3.1. Routes of SAFI 1, 2 or 4 with MVPN ECs . . . . . . . 9 70 2.3.2. MVPN ECs on the Route to the Next Hop . . . . . . . . 10 71 2.3.3. Non-BGP Routes as the UMH-eligible Routes . . . . . . 11 72 2.3.4. Why SFS Does Not Apply to GTM . . . . . . . . . . . . 12 73 2.4. Inclusive and Selective Tunnels . . . . . . . . . . . . . 13 74 2.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 13 75 2.5.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13 76 2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 14 77 2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 14 78 2.7. Leaf A-D Routes . . . . . . . . . . . . . . . . . . . . . 14 79 2.8. Source Active A-D Routes . . . . . . . . . . . . . . . . 14 80 2.8.1. Finding the Originator of an SA A-D Route . . . . . . 14 81 2.8.2. Optional Additional Constraints on Distribution . . . 15 82 2.9. C-multicast Source/Shared Tree Joins . . . . . . . . . . 16 83 3. Differences from other MVPN-like GTM Procedures . . . . . . . 17 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 6. Additional Contributors . . . . . . . . . . . . . . . . . . . 18 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 90 8.2. Informative References . . . . . . . . . . . . . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 93 1. Introduction 95 [RFC4364] specifies architecture, protocols, and procedures that a 96 Service Provider (SP) can use to provide Virtual Private Network 97 (VPN) service to its customers. In that architecture, one or more 98 Customer Edge (CE) routers attach to a Provider Edge (PE) router. 99 Each CE router belongs to a single VPN, but CE routers from several 100 VPNs may attach to the same PE router. In addition, CEs from the 101 same VPN may attach to different PEs. BGP is used to carry VPN- 102 specific information among the PEs. Each PE router maintains a 103 separate Virtual Routing and Forwarding table (VRF) for each VPN to 104 which it is attached. 106 [RFC6513] and [RFC6514] extend the procedures of [RFC4364] to allow 107 the SP to provide multicast service to its VPN customers. The 108 customer's multicast routing protocol (e.g., PIM) is used to exchange 109 multicast routing information between a CE and a PE. The PE stores a 110 given customer's multicast routing information in the VRF for that 111 customer's VPN. BGP is used to distribute certain multicast-related 112 control information among the PEs that attach to a given VPN, and BGP 113 may also be used to exchange the customer multicast routing 114 information itself among the PEs. 116 While this multicast architecture was originally developed for VPNs, 117 it can also be used (with a small number of modifications to the 118 procedures) to distribute multicast routing information that is not 119 specific to VPNs. The purpose of this document is to specify the way 120 in which BGP MVPN procedures can be adapted to support non-VPN 121 multicast. 123 Multicast routing information that is not specific to VPNs is stored 124 in a router's "global table", rather than in a VRF; hence it is known 125 as "Global Table Multicast" (GTM). GTM is sometimes more simply 126 called "Internet multicast". However, we will avoid that term 127 because it suggests that the multicast data streams are available on 128 the "public" Internet. The procedures for GTM can certainly be used 129 to support multicast on the public Internet, but they can also be 130 used to support multicast streams that are not public, e.g., content 131 distribution streams offered by content providers to paid 132 subscribers. For the purposes of this document, all that matters is 133 that the multicast routing information is maintained in a global 134 table rather than in a VRF. 136 This architecture does assume that the network over which the 137 multicast streams travel can be divided into a "core network" and one 138 or more non-core parts of the network, which we shall call 139 "attachment networks". The multicast routing protocol used in the 140 attachment networks may not be the same as the one used in the core, 141 so we consider there to be a "protocol boundary" between the core 142 network and the attachment networks. We will use the term "Protocol 143 Boundary Router" (PBR) to refer to the core routers that are at the 144 boundary. We will use the term "Attachment Router" (AR) to refer to 145 the routers that are not in the core but that attach to the PBRs. 147 This document does not make any particular set of assumptions about 148 the protocols that the ARs and the PBRs use to exchange unicast and 149 multicast routing information with each other. For instance, 150 multicast routing information could be exchanged between an AR and a 151 PBR via PIM, IGMP, or even BGP. Multicast routing also depends on an 152 exchange of routes that are used for looking up the path to the root 153 of a multicast tree. This routing information could be exchanged 154 between an AR and a PBR via IGP, via EBGP, or via IBGP ([RFC6368]). 155 Note that if IBGP is used, the [RFC6368] "push/pop procedures" are 156 not necessary. 158 The PBRs are not necessarily "edge" routers, in the sense of 159 [RFC4364]. For example, they may be both be Autonomous System Border 160 Routers (ASBR). As another example, an AR may be an "access router" 161 attached to a PBR that is an OSPF Area Border Router (ABR). Many 162 other deployment scenarios are possible. However, the PBRs are 163 always considered to be delimiting a "backbone" or "core" network. A 164 multicast data stream from an AR is tunneled over the core network 165 from an Ingress PBR to one or more Egress PBRs. Multicast routing 166 information that a PBR learns from the ARs attached to it is stored 167 in the PBR's global table. The PBRs use BGP to distribute multicast 168 routing and auto-discovery information among themselves. This is 169 done following the procedures of [RFC6513], [RFC6514], and other MVPN 170 specifications, as modified in this document. 172 In general, PBRs follow the same MVPN/BGP procedures that PE routers 173 follow, except that these procedures are adapted to be applicable to 174 the global table rather than to a VRF. Details are provided in 175 subsequent sections of this document. 177 By supporting GTM using the BGP procedures designed for MVPN, one 178 obtains a single control plane that governs the use of both VPN and 179 non-VPN multicast. Most of the features and characteristics of MVPN 180 carry over automatically to GTM. These include scaling, aggregation, 181 flexible choice of tunnel technology in the SP network, support for 182 both segmented and non-segmented tunnels, ability to use wildcards to 183 identify sets of multicast flows, support for the Any Source 184 Multicast (ASM), Single Source Multicast (SSM), and Bidirectional 185 (bidir) multicast paradigms, support for both IPv4 and IPv6 multicast 186 flows over either an IPv4 or IPv6 SP infrastructure, support for 187 unsolicited flooded data (including support for BSR as RP-to-group 188 mapping protocols), etc. 190 This document not only uses MVPN procedures for GTM, but also, 191 insofar as possible, uses the same protocol elements, encodings, and 192 formats. The BGP Updates for GTM thus use the same Subsequent 193 Address Family Identifier (SAFI), and have the same Network Layer 194 Reachability Information (NLRI) format, as the BGP Updates for MVPN. 196 Details for supporting MVPN (either IPv4 or IPv6 MVPN traffic) over 197 an IPv6 backbone network can be found in [RFC6515]. The procedures 198 and encodings described therein are also applicable to GTM. 200 The document [RFC7524] extends [RFC6514] by providing procedures that 201 allow tunnels through the core to be "segmented" at ABRs within the 202 core. The ABR segmentation procedures are also applicable to GTM as 203 defined in the current document. In general, the MVPN procedures of 204 [RFC7524], adapted as specified in the current document, are 205 applicable to GTM. 207 The document [RFC7524] also defines a set of procedures for GTM. 208 Those procedures are different from the procedures defined in the 209 current document, and the two sets of procedures are not 210 interoperable with each other. The two sets of procedures can co- 211 exist in the same network, as long as they are not applied to the 212 same multicast flows or to the same multicast group addresses. See 213 Section 3 for more details. 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in [RFC2119]. 219 2. Adapting MVPN Procedures to GTM 221 In general, PBRs support Global Table Multicast by using the 222 procedures that PE routers use to support VPN multicast. For GTM, 223 where [RFC6513] and [RFC6514] talk about the "PE-CE interface", one 224 should interpret that to mean the interface between the AR and the 225 PBR. For GTM, where [RFC6513] and [RFC6514] talk about the 226 "backbone" network, one should interpret that to mean the part of the 227 network that is delimited by the PBRs. 229 A few adaptations to the procedures of [RFC6513] and [RFC6514] need 230 to be made. Those adaptations are described in the following sub- 231 sections. 233 2.1. Use of Route Distinguishers 235 The MVPN procedures require the use of BGP routes, defined in 236 [RFC6514], that have a SAFI value of 5 ("MCAST-VPN"). We refer to 237 these simply as "MCAST-VPN routes". [RFC6514] defines the Network 238 Layer Reachability Information (NLRI) format for MCAST-VPN routes. 239 The NLRI field always begins with a "Route Type" octet, and, 240 depending on the route type, may be followed by a "Route 241 Distinguisher" (RD) field. 243 When a PBR originates an MCAST-VPN route in support of GTM, the RD 244 field (for those routes types where it is defined) of that route's 245 NLRI MUST be set to zero (i.e., to 64 bits of zero). Since no VRF 246 may have an RD of zero, this allows "MCAST-VPN" routes that are 247 "about" GTM to be distinguished from MCAST-VPN routes that are about 248 VPNs. 250 2.2. Use of Route Targets 252 The MVPN procedures require all MCAST-VPN routes to carry Route 253 Targets (RTs). When a PE router receives an MCAST-VPN route, it 254 processes the route in the context of a particular VRF if and only if 255 the route is carrying an RT that is configured as one of that VRF's 256 "import RTs". 258 There are two different "kinds" of RT used in MVPN. 260 o One kind of RT is carried only by the following MCAST-VPN route 261 types: C-multicast Shared Tree Joins, C-multicast Source Tree 262 Joins, and Leaf A-D routes. This kind of RT identifies the PE 263 router that has been selected by the route's originator as the 264 "Upstream PE" or as the "Upstream Multicast Hop" (UMH) for a 265 particular (set of) multicast flow(s). Per [RFC6514] and 266 [RFC6515], this RT must be an IPv4-address-specific or IPv6- 267 address-specific Extended Community (EC), whose "Global 268 Administrator" field identifies the Upstream PE or the UMH. If 269 the Global Administrator field identifies the Upstream PE, the 270 "Local Administrator" field identifies a particular VRF in that 271 PE. 273 The GTM procedures of this document require the use of this type 274 of RT, in exactly the same situations where it is used in the MVPN 275 specification. However, one adaptation is necessary: the "Local 276 Administrator" field of this kind of RT MUST always be set to 277 zero, thus implicitly identifying the global table, rather than 278 identifying a VRF. We will refer to this kind of RT as an 279 "upstream-node-identifying RT". 281 o The other kind of RT is the conventional RT first specified in 282 [RFC4364]. It does not necessarily identify a particular router 283 by address, but is used to constrain the distribution of VPN 284 routes, and to ensure that a given VPN route is processed in the 285 context of a given VRF if and only if the route is carrying an RT 286 that has been configured as one of that VRF's "import RTs". 288 Whereas every VRF must be configured with at least one import RT, 289 there is heretofore no requirement to configure any RTs for the 290 global table of any router. As stated above, this document makes 291 the use of upstream-node-identifying RTs mandatory for GTM. This 292 document makes the use of non-upstream-node-identifying RTs 293 OPTIONAL for GTM. 295 The procedures for the use of RTs in GTM are the following: 297 o If the global table of a particular PBR is NOT configured with any 298 import RTs, then a received MCAST-VPN route is processed in the 299 context of the global table only if it is carrying no RTs, or if 300 it is carrying an upstream-node-identifying RT whose Global 301 Administrator field identifies that PBR. 303 o The global table in each PBR MAY be configured with (a) a set of 304 export RTs to be attached to MCAST-VPN routes that are originated 305 to support GTM, and (b) with a set of import RTs for GTM. 307 If the global table of a given PBR has been so configured, the PBR 308 will process a received MCAST-VPN route in the context of the 309 global table if and only if the route carries an RT that is one of 310 the global table's import RTs, or if the route carries an 311 upstream-node-identifying RT whose global administrator field 312 identifies the PBR. 314 If the global tables are configured with RTs, care must be taken 315 to ensure that the RTs configured for the global table are 316 distinct from any RTs used in support of MVPN (except in the case 317 where it is actually intended to create an "extranet" 318 [MVPN-extranet] in which some sources are reachable in global 319 table context while others are reachable in VPN context.) 321 The "RT Constraint" procedures of [RFC4684] MAY be used to constrain 322 the distribution of MCAST-VPN routes (or other routes) that carry RTs 323 that have been configured as import RTs for GTM. (This includes the 324 upstream-node-identifying RTs.) 326 N.B.: If the "RT Constraint" procedures of [RFC4684] are deployed, 327 but the MCAST-VPN routes are not carrying RTs, then proper 328 operation requires the "default behavior" specified for the 329 MCAST-VPN address family in Section 3 ("Default Behavior") of 330 [RTC_without_RTs]. 332 In [RFC6513], the UMH-eligible routes (see section 5.1 of [RFC6513], 333 "Eligible Routes for UMH Selection") are generally routes of SAFI 128 334 (Labeled VPN-IP routes) or 129 (VPN-IP multicast routes), and are 335 required to carry RTs. These RTs determine which VRFs import which 336 such routes. However, for GTM, when the UMH-eligible routes may be 337 routes of SAFI 1, 2, or 4, the routes are not required to carry RTs. 338 This document does NOT specify any new rules for determining whether 339 a SAFI 1, 2, or 4 route is to be imported into the global table of 340 any PBR. 342 2.3. UMH-eligible Routes 344 [RFC6513] section 5.1 defines procedures by which a PE router 345 determines the "C-root", the "Upstream Multicast Hop" (UMH), the 346 "Upstream PE", and the "Upstream RD" of a given multicast flow. (In 347 non-VPN multicast documents, the UMH of a multicast flow at a 348 particular router is generally known as the "RPF neighbor" for that 349 flow.) It also defines procedures for determining the "Source AS" of 350 a particular flow. Note that in GTM, the "Upstream PE" is actually 351 the "Upstream PBR". 353 The definition of the C-root of a flow is the same for GTM as for 354 MVPN. 356 For MVPN, to determine the UMH, Upstream PE, Upstream RD, and Source 357 AS of a flow, one looks up the C-root of the flow in a particular 358 VRF, and finds the "UMH-eligible" routes (see section 5.1.1 of 359 [RFC6513]) that "match" the C-root. From among these, one is chosen 360 as the "selected UMH route". 362 For GTM, the C-root is of course looked up in the global table, 363 rather than in a VRF. For MVPN, the UMH-eligible routes are routes 364 of SAFI 128 or 129. For GTM, the UMH-eligible routes are routes of 365 SAFI 1, SAFI 4, or SAFI 2. If the global table has imported routes 366 of SAFI 2, then these are the UMH-eligible routes. Otherwise, routes 367 of SAFI 1 or SAFI 4 are the UMH-eligible routes. For the purpose of 368 UMH determination, if a SAFI 1 route and a SAFI 4 route contain the 369 same IP prefix in their respective NLRI fields, then the two routes 370 are considered by the BGP bestpath selection process to be 371 comparable. 373 [RFC6513] defines procedures for determining which of the UMH- 374 eligible routes that match a particular C-root is to become the 375 "Selected UMH route". With one exception, these procedures are also 376 applicable to GTM. The one exception is the following. 377 Section 9.1.2 of [RFC6513] defines a particular method of choosing 378 the Upstream PE, known as "Single Forwarder Selection" (SFS). This 379 procedure MUST NOT be used for GTM (see Section 2.3.4 for an 380 explanation of why the SFS procedure cannot be applied to GTM). 382 In GTM, the "Upstream RD" of a multicast flow is always considered to 383 be zero, and is NOT determined from the Selected UMH route. 385 The MVPN specifications require that when BGP is used for 386 distributing multicast routing information, the UMH-eligible routes 387 MUST carry the VRF Route Import EC and the Source AS EC. To 388 determine the Upstream PE and Source AS for a particular multicast 389 flow, the Upstream PE and Source AS are determined, respectively, 390 from the VRF Route Import EC and the Source AS EC of the Selected UMH 391 route for that flow. These ECs are generally attached to the UMH- 392 eligible routes by the PEs that originate the routes. 394 In GTM, there are certain situations in which it is allowable to omit 395 the VRF Route Import EC and/or the Source AS EC from the UMH-eligible 396 routes. The following sub-sections specify the various options for 397 determining the Upstream PBR and the Source AS in GTM. 399 The procedures in Section 2.3.1 MUST be implemented. The procedures 400 in Section 2.3.2 and Section 2.3.3 are OPTIONAL to implement. It 401 should be noted that while the optional procedures may be useful in 402 particular deployment scenarios, there is always the potential for 403 interoperability problems when relying on OPTIONAL procedures. 405 2.3.1. Routes of SAFI 1, 2 or 4 with MVPN ECs 407 If the UMH-eligible routes have a SAFI of 1, 2 or 4, then they MAY 408 carry the VRF Route Import EC and/or the Source AS EC. If the 409 selected UMH route is a route of SAFI 1, 2 or 4 that carries the VRF 410 Route Import EC, then the Upstream PBR is determined from that EC. 411 Similarly, if the selected UMH route is a route of SAFI 1, 2, or 4 412 route that carries the Source AS EC, the Source AS is determined from 413 that EC. 415 When the procedure of this section is used, a PBR that distributes a 416 UMH-eligible route to other PBRs is responsible for ensuring that the 417 VRF Route Import and Source AS ECs are attached to it. 419 If the selected UMH-eligible route has a SAFI of 1, 2 or 4, but is 420 not carrying a VRF Route Import EC, then the Upstream PBR is 421 determined as specified in Section 2.3.2 or Section 2.3.3 below. 423 If the selected UMH-eligible route has a SAFI of 1, 2 or 4, but is 424 not carrying a Source AS EC, then the Source AS is considered to be 425 the local AS. 427 2.3.2. MVPN ECs on the Route to the Next Hop 429 Some service providers may consider it to be undesirable to have the 430 PBRs put the VRF Route Import EC on all the UMH-eligible routes. Or 431 there may be deployment scenarios in which the UMH-eligible routes 432 are not advertised by the PBRs at all. The procedures described in 433 this section provide an alternative that can be used under certain 434 circumstances. 436 The procedures of this section are OPTIONAL. 438 In this alternative procedure, each PBR MUST originate a BGP route of 439 SAFI 1, 2 or 4 whose NLRI is an IP address of the PBR itself. This 440 route MUST carry a VRF Route Import EC that identifies the PBR. The 441 address that appears in the Global Administrator field of that EC 442 MUST be the same address that appears in the NLRI and in the Next Hop 443 field of that route. This route MUST also carry a Source AS EC 444 identifying the AS of the PBR. 446 Whenever the PBR distributes a UMH-eligible route for which it sets 447 itself as next hop, it MUST use this same IP address as the Next Hop 448 of the UMH-eligible route that it used in the route discussed in the 449 prior paragraph. 451 When the procedure of his section is used, then when a PBR is 452 determining the Selected UMH Route for a given multicast flow, it may 453 find that the Selected UMH Route has no VRF Route Import EC. In this 454 case, the PBR will look up (in the global table) the route to the 455 Next Hop of the Selected UMH route. If the route to the Next Hop has 456 a VRF Route Import EC, that EC will be used to determine the Upstream 457 PBR, just as if the EC had been attached to the Selected UMH Route. 459 If recursive route resolution is required in order to resolve the 460 next hop, the Upstream PBR will be determined from the first route 461 with a VRF Route Import EC that is encountered during the recursive 462 route resolution process. (The recursive route resolution process 463 itself is not modified by this document.) 465 The same procedure can be applied to find the Source AS, except that 466 the Source AS EC is used instead of the VRF Route Import EC. 468 Note that this procedure is only applicable in scenarios where it is 469 known that the Next Hop of the UMH-eligible routes is not be changed 470 by any router that participates in the distribution of those routes; 471 this procedure MUST NOT be used in any scenario where the next hop 472 may be changed between the time one PBR distributes the route and 473 another PBR receives it. The PBRs have no way of determining 474 dynamically whether the procedure is applicable in a particular 475 deployment; this must be made known to the PBRs by provisioning. 477 Some scenarios in which this procedure can be used are: 479 o all PBRs are in the same AS, or 481 o the UMH-eligible routes are distributed among the PBRs by a Route 482 Reflector (that does not change the next hop), or 484 o the UMH-eligible routes are distributed from one AS to another 485 through ASBRs that do not change the next hop. 487 If the procedures of this section are used in scenarios where they 488 are not applicable, GTM will not function correctly. 490 2.3.3. Non-BGP Routes as the UMH-eligible Routes 492 In particular deployment scenarios, there may be specific procedures 493 that can be used, in those particular scenarios, to determine the 494 Upstream PBR for a given multicast flow. 496 Suppose the PBRs neither put the VRF Route Import EC on the UMH- 497 eligible routes, nor do they distribute BGP routes to themselves. It 498 may still be possible to determine the Upstream PBR for a given 499 multicast flow, using specific knowledge about the deployment. 501 For example, suppose it is known that all the PBRs are in the same 502 OSPF area. It may be possible to determine the Upstream PBR for a 503 given multicast flow by looking at the link state database to see 504 which router is attached to the flow's C-root. 506 As another example, suppose it is known that the set of PBRs is fully 507 meshed via Traffic Engineering (TE) tunnels. When a PBR looks up, in 508 its global table, the C-root of a particular multicast flow, it may 509 find that the next hop interface is a particular TE tunnel. If it 510 can determine the identify of the router at the other end of that TE 511 tunnel, it can deduce that that router is the Upstream PBR for that 512 flow. 514 This is not an exhaustive set of examples. Any procedure that 515 correctly determines the Upstream PBR in a given deployment scenario 516 MAY be used in that scenario. 518 2.3.4. Why SFS Does Not Apply to GTM 520 To see why the SFS procedure cannot be applied to GTM, consider the 521 following example scenario. Suppose some multicast source S is homed 522 to both PBR1 and PBR2, and suppose that both PBRs export a route (of 523 SAFI 1, 2, or 4) whose NLRI is a prefix matching the address of S. 524 These two routes will be considered comparable by the BGP decision 525 process. A route reflector receiving both routes may thus choose to 526 redistribute just one of the routes to S, the one chosen by the 527 bestpath algorithm. Different route reflectors may even choose 528 different routes to redistribute (i.e., one route reflector may 529 choose the route to S via PBR1 as the bestpath, while another chooses 530 the route to S via PBR2 as the bestpath). As a result, some PBRs may 531 receive only the route to S via PBR1 and some may receive only the 532 route to S via PBR2. In that case, it is impossible to ensure that 533 all PBRs will choose the same route to S. 535 The SFS procedure works in VPN context as along the following 536 assumption holds: if S is homed to VRF-x in PE1 and to VRF-y in PE2, 537 then VRF-x and VRF-y have been configured with different RDs. In VPN 538 context, the route to S is of SAFI 128 or 129, and thus has an RD in 539 its NLRI. So the route to S via PE1 will not have the same NLRI as 540 the route to S via PE2. As a result, all PEs will see both routes, 541 and the PEs can implement a procedure that ensures that they all pick 542 the same route to S. 544 That is, the SFS procedure of [RFC6513] relies on the UMH-eligible 545 routes being of SAFI 128 or 129, and relies on certain VRFs being 546 configured with distinct RDs. Thus the procedure cannot be applied 547 to GTM. 549 One might think that the SFS procedure could be applied to GTM as 550 long as the procedures defined in [ADD-PATH] are applied to the UMH- 551 eligible routes. Using the [ADD-PATH] procedures, the BGP speakers 552 could advertise more than one path to a given prefix. Typically 553 [ADD-PATH] is used to report the n best paths, for some small value 554 of n. However, this is not sufficient to support SFS, as can be seen 555 by examining the following scenario. 557 AS-X | AS-Y | AS-Z 558 | | 559 S--PBR1---ASBR1--|--ASBR2--|---ASBR5 560 | \______/ | | 561 | / \ | | 562 |--PBR2---ASBR3--|--ASBR4--|---ASBR6 563 | | 565 In AS-X, PBR1 reports to both ASBR1 and ASBR3 that it has a route to 566 S. Similarly, PBR2 reports to both ASBR1 and ASBR3 that it has a 567 route to S. Using [ADD-PATH], ASBR1 reports both routes to ASBR2, 568 and ASBR3 reports both routes to ASBR4. Now AS-Y sees 4 paths to S. 569 The AS-Z ASBRs will each see eight paths (four via ASBR2 and four via 570 ASBR4). To avoid this explosion in the number of paths, a BGP 571 speaker that uses [ADD-PATH] is usually considered to report only the 572 n best paths. However, there is then no guarantee that the reported 573 set of paths will contain at least one path via PBR1 and at least one 574 path via PBR2. Without such a guarantee, the SFS procedure will not 575 work. 577 2.4. Inclusive and Selective Tunnels 579 The MVPN specifications allow multicast flows to be carried on either 580 Inclusive Tunnels or on Selective Tunnels. When a flow is sent on an 581 Inclusive Tunnel of a particular VPN, it is sent to all PEs in that 582 VPN. When sent on a Selective Tunnel of a particular VPN, it may be 583 sent to only a subset of the PEs in that VPN. 585 This document allows the use of either Inclusive Tunnels or Selective 586 Tunnels for GTM. However, any service provider electing to use 587 Inclusive Tunnels for GTM should carefully consider whether sending a 588 multicast flow to ALL its PBRs would result in problems of scale. 589 There are potentially many more MBRs for GTM than PEs for a 590 particular VPN. If the set of PBRs is large and growing, but most 591 multicast flows do not need to go to all the PBRs, the exclusive use 592 of Selective Tunnels may be a better option. 594 2.5. I-PMSI A-D Routes 596 2.5.1. Intra-AS I-PMSI A-D Routes 598 Per [MVPN-BGP}, there are certain conditions under which is it NOT 599 required for a PE router implementing MVPN to originate one or more 600 Intra-AS I-PMSI A-D routes. These conditions apply as well to PBRs 601 implementing GTM. 603 In addition, a PBR implementing GTM is NOT required to originate an 604 Intra-AS I-PMSI A-D route if both of the following conditions hold: 606 o The PBR is not using Inclusive Tunnels for GTM, and 608 o The distribution of the C-multicast Shared Tree Join and 609 C-multicast Source Tree Join routes is done in such a manner that 610 the next hop of those routes does not change. 612 Please see also the sections on RD and RT usage (Sections 2.1 and 2.2 613 respectively). 615 2.5.2. Inter-AS I-PMSI A-D Routes 617 There are no GTM-specific procedures for the origination, 618 distribution, and processing of these routes, other than those 619 specified in the sections on RD and RT usage. 621 2.6. S-PMSI A-D Routes 623 There are no GTM-specific procedures for the origination, 624 distribution, and processing of these routes, other than those 625 specified in the sections on RD and RT usage. 627 2.7. Leaf A-D Routes 629 There are no GTM-specific procedures for the origination, 630 distribution, and processing of these routes, other than those 631 specified in the sections on RD and RT usage. 633 2.8. Source Active A-D Routes 635 Please see the sections on RD and RT usage for information applies to 636 the origination and distribution of Source Active A-D routes. 637 Additional procedures governing the use of Source Active A-D routes 638 are given in the sub-sections of this section. 640 2.8.1. Finding the Originator of an SA A-D Route 642 To carry out the procedures specified in [RFC6514] (e.g., in 643 Section 13.2 of that document), it is sometimes necessary for an 644 egress PE to determine the ingress PE that originated a given Source 645 Active A-D route. The procedure used in [RFC6514] to find the 646 originator of a Source Active A-D route assumes that no two routes 647 have the same RD unless they have been originated by the same PE. 648 However, this assumption is not valid in GTM, because each Source 649 Active A-D route used for GTM will have an RD of 0, and all the UMH- 650 eligible routes also have an RD of 0. So GTM requires a different 651 procedure for determining the originator of a Source Active A-D 652 route. 654 In GTM, the procedure for determining the originating PE of a Source 655 Active A-D route is the following: 657 o When a Source Active A-D route is originated, the originating PE 658 MAY attach a VRF Route Import Extended Community to the route. 660 o When a Source Active A-D route is distributed by one BGP speaker 661 to another, then 663 * if the Source Active A-D route does not carry the VRF Route 664 Import EC, the BGP speaker distributing the route MUST NOT 665 change the route's next hop field; 667 * if the Source Active A-D route does carry the VRF Route Import 668 EC, the BGP speaker distributing the route MAY change the 669 route's next hop field to itself. 671 o When an egress PE needs to determine the originator of a Source 672 Active A-D route, then 674 * if the Source Active A-D route carries the VRF Route Import EC, 675 the originating PE is the PE identified in the Global 676 Administrator field of that EC; 678 * if the Source Active A-D route does not carry the VRF Route 679 Import EC, the originating PE is the PE identified in the 680 route's next hop field. 682 2.8.2. Optional Additional Constraints on Distribution 684 If some site has receivers for a particular ASM group G, then it is 685 possible (by the procedures of [RFC6514]) that every PBR attached to 686 a site with a source for group G will originate a Source Active A-D 687 route whose NLRI identifies that source and group. These Source 688 Active A-D routes may be distributed to every PBR. If only a 689 relatively small number of PBRs are actually interested in traffic 690 from group G, but there are many sources for group G, this could 691 result in a large number of (S,G) Source Active A-D routes being 692 installed in a large number of PBRs that have no need of them. 694 For GTM, it is possible to constrain the distribution of (S,G) Source 695 Active A-D routes to those PBRs that are interested in GTM traffic to 696 group G. This can be done using the following OPTIONAL procedures: 698 o If a PBR originates a C-multicast Shared Tree Join whose NLRI 699 contains (RD=0,*,G), then it dynamically creates an import RT for 700 its global table, where the Global Administrator field of the RT 701 contains the group address G, and the Local Administrator field 702 contains zero. (Note that an IPv6-address-specific RT would need 703 to be used if the group address is an IPv6 address.) 705 o When a PBR creates such an import RT, it uses "RT Constraint" 706 [RFC4684] procedures to advertise its interest in routes that 707 carry this RT. 709 o When a PBR originates a Source Active A-D route from its global 710 table, it attaches the RT described above. 712 o When the C-multicast Shared Tree Join is withdrawn, so is the 713 corresponding RT constrain route, and the corresponding RT is 714 removed as an import RT of its global table. 716 These procedures enable a PBR to automatically filter all Source 717 Active A-D routes that are about multicast groups in which the PBR 718 has no interest. 720 This procedure does introduce the overhead of distributing additional 721 "RT Constraint" routes, and therefore may not be cost-effective in 722 all scenarios, especially if the number of sources per ASM group is 723 small. This procedure may also result in increased join latency. 725 2.9. C-multicast Source/Shared Tree Joins 727 Section 11.1.3 of [RFC6514] describes how to determine the IP- 728 address-specific RT(s) that should be attached to a C-multicast 729 route. The "upstream PE", "upstream RD", and "source AS" (as defined 730 in Section 5 of [RFC6513]) for the NLRI of the C-multicast route are 731 first determined. An IP-address-specific RT whose "global 732 administrator" field carries the IP address of the upstream PE is 733 then attached to the C-multicast route. This procedure applies as 734 well to GTM, except that the "upstream PE" is actually an "upstream 735 PBR". 737 Section 11.1.3 of [RFC6514] also specifies that a second IP-address 738 specific RT be attached to the C-multicast route, if the source AS of 739 the NLRI of that route is different than the AS of the PE originating 740 the route. The procedure for creating this RT may be summarized as: 742 (a) determine the upstream PE, upstream RD,and source AS 743 corresponding to the NLRI of the route; 745 (b) find the corresponding Inter-AS or Intra-AS I-PMSI A-D route 746 based on (a); 748 (c) find the next hop of that A-D route; 750 (d) place the IP address of that next hop in the global 751 administrator field of the RT. 753 However, for GTM, in scenarios where it is known a priori by a PBR 754 that the next hop of the C-multicast Source/Shared Tree Joins does 755 not change during the distribution of those routes, the second RT 756 (the one based on the next hop of an I-PMSI A-D route) is not needed, 757 and should not be present. In other scenarios, the procedure of 758 section 11.1.3 of [RFC6513] (as modified by this document's sections 759 on "RD usage" and "RT usage") is applied by the PBRs. 761 3. Differences from other MVPN-like GTM Procedures 763 The document [RFC7524] also defines a procedure for GTM that is based 764 on the BGP procedures that were developed for MVPN. 766 However, the GTM procedures of [RFC7524] are different than and are 767 NOT interoperable with the procedures defined in this document. 769 The two sets of procedures can co-exist in the same network, as long 770 as they are not applied to the same multicast flows or to the same 771 ASM multicast group addresses. 773 Some of the major differences between the two sets of procedures are 774 the following: 776 o The [RFC7524] procedures for GTM do not use C-multicast Shared 777 Tree Joins or C-multicast Source Tree Joins at all. The 778 procedures of this document use these C-multicast routes for GTM, 779 setting the RD field of the NLRI to zero. 781 o The [RFC7524] procedures for GTM use Leaf A-D routes instead of 782 C-multicast Shared/Source Tree Join routes. Leaf A-D routes used 783 in that manner can be distinguished from Leaf A-D routes used as 784 specified in [RFC6514] by means of the NLRI format; [RFC7524] 785 defines a new NLRI format for Leaf A-D routes. Whether a given 786 Leaf A-D route is being used according to the [RFC7524] procedures 787 or not can be determined from its NLRI. (See [RFC7524] section 788 "Leaf A-D Route for Global Table Multicast".) 790 o The Leaf A-D routes used by the current document contain an NLRI 791 that is in the format defined in [RFC6514], NOT in the format as 792 defined in [RFC7524]. The procedures assumed by this document for 793 originating and processing Leaf A-D routes are as specified in 794 [RFC6514], NOT as specified in [RFC7524]. 796 o The current document uses an RD value of zero in the NLRI in order 797 to indicate that a particular route is "about" a Global 798 Table Multicast, rather than a VPN multicast. No other semantics 799 are inferred from the fact that RD is zero. [RFC7524] uses two 800 different RD values in its GTM procedures, with semantic 801 differences that depend upon the RD values. 803 o In order for both sets of procedures to co-exist in the same 804 network, the PBRs MUST be provisioned so that for any given IP 805 group address in the global table, all egress PBRs use the same 806 set of procedures for that group address (i.e., for group G, 807 either all egress PBRs use the GTM procedures of this document or 808 all egress PBRs use the GTM procedures of [RFC7524]. 810 4. IANA Considerations 812 This document has no IANA considerations. 814 5. Security Considerations 816 The security considerations of this document are primarily the 817 security considerations of the base protocols, as discussed in 818 [RFC6514], [RFC4601], and [RFC5294]. 820 This document makes use of a BGP SAFI (MCAST-VPN routes) that was 821 originally designed for use in VPN contexts only. It also makes use 822 of various BGP path attributes and extended communities (VRF Route 823 Import Extended Community, Source AS Extended Community, Route Target 824 Extended Community) that were originally intended for use in VPN 825 contexts. If these routes and/or attributes leak out into "the 826 wild", multicast data flows may be distributed in an unintended and/ 827 or unauthorized manner. 829 Internet providers often make extensive use of BGP communities (ie, 830 adding, deleting, modifying communities throughout a network). As 831 such, care should be taken to avoid deleting or modifying the VRF 832 Route Import Extended Community and Source AS Extended Community. 833 Incorrect manipulation of these ECs may result in multicast streams 834 being lost or misrouted. 836 The procedures of this document require certain BGP routes to carry 837 IP multicast group addresses. Generally such group addresses are 838 only valid within a certain scope. If a BGP route containing a group 839 address is distributed outside the boundaries where the group address 840 is meaningful, unauthorized distribution of multicast data flows may 841 occur. 843 6. Additional Contributors 844 Jason Schiller 845 Google 846 Suite 400 847 1818 Library Street 848 Reston, Virginia 20190 849 United States 850 Email: jschiller@google.com 852 Zhenbin Li 853 Huawei Technologies 854 Huawei Bld., No.156 Beiqing Rd. 855 Beijing 100095 856 China 857 Email: lizhenbin@huawei.com 859 Wei Meng 860 ZTE Corporation 861 No.50 Software Avenue, Yuhuatai District 862 Nanjing 863 China 864 Email: meng.wei2@zte.com.cn,vally.meng@gmail.com 866 Cui Wang 867 ZTE Corporation 868 No.50 Software Avenue, Yuhuatai District 869 Nanjing 870 China 871 Email: wang.cui1@zte.com.cn 873 Shunwan Zhuang 874 Huawei Technologies 875 Huawei Bld., No.156 Beiqing Rd. 876 Beijing 100095 877 China 878 Email: zhuangshunwan@huawei.com 880 7. Acknowledgments 882 The authors and contributors would like to thank Rahul Aggarwal, 883 Huajin Jeng, Hui Ni, Yakov Rekhter, and Samir Saad for their ideas 884 and comments. 886 8. References 887 8.1. Normative References 889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 890 Requirement Levels", BCP 14, RFC 2119, March 1997. 892 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 893 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 894 2006, . 896 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 897 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 898 2012, . 900 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 901 Encodings and Procedures for Multicast in MPLS/BGP IP 902 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 903 . 905 [RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure 906 Addresses in BGP Updates for Multicast VPN", RFC 6515, 907 DOI 10.17487/RFC6515, February 2012, 908 . 910 8.2. Informative References 912 [ADD-PATH] 913 Walton, D., Retana, A., Chen, E., and J. Scudder, 914 "Advertisement of Multiple Paths in BGP", internet-draft 915 draft-ietf-idr-add-paths-10, October 2014. 917 [MVPN-extranet] 918 Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T. 919 Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet- 920 draft draft-ietf-bess-mvpn-extranet-02, May 2015. 922 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 923 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 924 Protocol Specification (Revised)", RFC 4601, August 2006. 926 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 927 R., Patel, K., and J. Guichard, "Constrained Route 928 Distribution for Border Gateway Protocol/MultiProtocol 929 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 930 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 931 November 2006, . 933 [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol 934 Independent Multicast (PIM)", RFC 5294, 935 DOI 10.17487/RFC5294, August 2008, 936 . 938 [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. 939 Yamagata, "Internal BGP as the Provider/Customer Edge 940 Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", 941 RFC 6368, DOI 10.17487/RFC6368, September 2011, 942 . 944 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 945 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 946 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 947 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 948 . 950 [RTC_without_RTs] 951 Rosen, E., Ed., Patel, K., Haas, J., and R. Raszuk, "Route 952 Target Constrained Distribution of Routes with no Route 953 Targets", internet-draft draft-ietf-idr-rtc-no-rt-01, June 954 2015. 956 Authors' Addresses 958 Zhaohui Zhang 959 Juniper Networks, Inc. 960 10 Technology Park Drive 961 Westford, Massachusetts 01886 962 US 964 Email: zzhang@juniper.net 966 Lenny Giuliano 967 Juniper Networks, Inc. 968 2251 Corporate Park Drive 969 Herndon, Virginia 20171 970 US 972 Email: lenny@juniper.net 973 Eric C. Rosen (editor) 974 Juniper Networks, Inc. 975 10 Technology Park Drive 976 Westford, Massachusetts 01886 977 US 979 Email: erosen@juniper.net 981 Karthik Subramanian 982 Cisco Systems, Inc. 983 170 Tasman Drive 984 San Jose, CA 95134 985 US 987 Email: kartsubr@cisco.com 989 Dante J. Pacella 990 Verizon 991 22001 Loudoun County Parkway 992 Ashburn, Virginia 95134 993 US 995 Email: dante.j.pacella@verizonbusiness.com