idnits 2.17.1 draft-zzhang-l3vpn-mvpn-global-table-mcast-01.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 (October 18, 2013) is 3835 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) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-05) exists of draft-ietf-l3vpn-mvpn-extranet-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Jeffrey Zhang 3 Internet Draft Lenny Giuliano 4 Intended Status: Standards Track Juniper Networks, Inc. 5 Expires: April 18, 2014 6 Eric C. Rosen 7 Karthik Subramanian 8 Cisco Systems, Inc. 10 Dante J. Pacella 11 Verizon 13 Jason Schiller 14 Google 16 October 18, 2013 18 Global Table Multicast with BGP-MVPN Procedures 20 draft-zzhang-l3vpn-mvpn-global-table-mcast-01.txt 22 Abstract 24 RFC6513, RFC6514, and other RFCs describe protocols and procedures 25 which a Service Provider (SP) may deploy in order offer Multicast 26 Virtual Private Network (Multicast VPN or MVPN) service to its 27 customers. Some of these procedures use BGP to distribute VPN- 28 specific multicast routing information across a backbone network. 29 With a small number of relatively minor modifications, the very same 30 BGP procedures can also be used to distribute multicast routing 31 information that is not specific to any VPN. Multicast that is 32 outside the context of a VPN is known as "Global Table Multicast", or 33 sometimes simply as "Internet multicast". In this document, we 34 describe the modifications that are needed to use the MVPN BGP 35 procedures for Global Table Multicast. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt. 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 Copyright and License Notice 60 Copyright (c) 2013 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1 Introduction .......................................... 4 76 2 Adapting MVPN Procedures to GTM ....................... 6 77 2.1 Use of Route Distinguishers ........................... 7 78 2.2 Use of Route Targets .................................. 7 79 2.3 UMH-eligible Routes ................................... 9 80 2.3.1 Routes of SAFI 1, 2 or 4 with MVPN ECs ................ 11 81 2.3.2 MVPN ECs on the Route to the Next Hop ................. 11 82 2.3.3 Non-BGP Routes as the UMH-eligible Routes ............. 12 83 2.4 Inclusive and Selective Tunnels ....................... 13 84 2.5 I-PMSI A-D Routes ..................................... 13 85 2.5.1 Intra-AS I-PMSI A-D Routes ............................ 13 86 2.5.2 Inter-AS I-PMSI A-D Routes ............................ 14 87 2.6 S-PMSI A-D Routes ..................................... 14 88 2.7 Leaf A-D Routes ....................................... 14 89 2.8 Source Active A-D Routes .............................. 14 90 2.9 C-multicast Source/Shared Tree Joins .................. 15 91 3 Differences from other MVPN-like GTM Procedures ....... 16 92 4 IANA Considerations ................................... 17 93 5 Security Considerations ............................... 17 94 6 Acknowledgments ....................................... 18 95 7 Authors' Addresses .................................... 18 96 8 References ............................................ 19 97 8.1 Normative References .................................. 19 98 8.2 Informative References ................................ 19 100 1. Introduction 102 [RFC4364] specifies architecture, protocols, and procedures that a 103 Service Provider (SP) can use to provide Virtual Private Network 104 (VPN) service to its customers. In that architecture, one or more 105 Customer Edge (CE) routers attach to a Provider Edge (PE) router. 106 Each CE router belongs to a single VPN, but CE routers from several 107 VPNs may attach to the same PE router. In addition, CEs from the 108 same VPN may attach to different PEs. BGP is used to carry VPN- 109 specific information among the PEs. Each PE router maintains a 110 separate Virtual Routing and Forwarding table (VRF) for each VPN to 111 which it is attached. 113 [RFC6513] and [RFC6514] extend the procedures of [RFC4364] to allow 114 the SP to provide multicast service to its VPN customers. The 115 customer's multicast routing protocol (e.g., PIM) is used to exchange 116 multicast routing information between a CE and a PE. The PE stores a 117 given customer's multicast routing information in the VRF for that 118 customer's VPN. BGP is used to distribute certain multicast-related 119 control information among the PEs that attach to a given VPN, and BGP 120 may also be used to exchange the customer multicast routing 121 information itself among the PEs. 123 While this multicast architecture was originally developed for VPNs, 124 it can also be used (with a small number of modifications to the 125 procedures) to distribute multicast routing information that is not 126 specific to VPNs. The purpose of this document is to specify the way 127 in which BGP MVPN procedures can be adapted to support non-VPN 128 multicast. 130 Multicast routing information that is not specific to VPNs is stored 131 in a router's "global table", rather than in a VRF; hence it is known 132 as "Global Table Multicast" (GTM). GTM is sometimes more simply 133 called "Internet multicast". However, we will avoid that term 134 because it suggests that the multicast data streams are available on 135 the "public" Internet. The procedures for GTM can certainly be used 136 to support multicast on the public Internet, but they can also be 137 used to support multicast streams that are not public, e.g., content 138 distribution streams offered by content providers to paid 139 subscribers. For the purposes of this document, all that matters is 140 that the multicast routing information is maintained in a global 141 table rather than in a VRF. 143 This architecture does assume that the network over which the 144 multicast streams travel can be divided into a "core network" and one 145 or more non-core parts of the network, which we shall call 146 "attachment networks". The multicast routing protocol used in the 147 attachment networks may not be the same as the one used in the core, 148 so we consider there to be a "protocol boundary" between the core 149 network and the attachment networks. We will use the term "Protocol 150 Boundary Router" (PBR) to refer to the core routers that are at the 151 boundary. We will use the term "Attachment Router" (AR) to refer to 152 the routers that are not in the core but that attach to the PBRs. 154 This document does not make any particular set of assumptions about 155 the protocols that the ARs and the PBRs use to exchange unicast and 156 multicast routing information with each other. For instance, 157 multicast routing information could be exchanged between an AR and a 158 PBR via PIM, IGMP, or even BGP. Multicast routing also depends on an 159 exchange of routes that are used for looking up the path to the root 160 of a multicast tree. This routing information could be exchanged 161 between an AR and a PBR via IGP, via EBGP, or via IBGP ([RFC6368]). 162 Note that if IBGP is used, the [RFC6368] "push/pop procedures" are 163 not necessary. 165 The PBRs are not necessarily "edge" routers, in the sense of 166 [RFC4364]. For example, they may be both be Autonomous System Border 167 Routers (ASBR). As another example, an AR may be an "access router" 168 attached to a PBR that is an OSPF Area Border Router (ABR). Many 169 other deployment scenarios are possible. However, the PBRs are 170 always considered to be delimiting a "backbone" or "core" network. A 171 multicast data stream from an AR is tunneled over the core network 172 from an Ingress PBR to one or more Egress PBRs. Multicast routing 173 information that a PBR learns from the ARs attached to it is stored 174 in the PBR's global table. The PBRs use BGP to distribute multicast 175 routing and auto-discovery information among themselves. This is 176 done following the procedures of [RFC6513], [RFC6514], and other MVPN 177 specifications, as modified in this document. 179 In general, PBRs follow the same MVPN/BGP procedures that PE routers 180 follow, except that these procedures are adapted to be applicable to 181 the global table rather than to a VRF. Details are provided in 182 subsequent sections of this document. 184 By supporting GTM using the BGP procedures designed for MVPN, one 185 obtains a single control plane that governs the use of both VPN and 186 non-VPN multicast. Most of the features and characteristics of MVPN 187 carry over automatically to GTM. These include scaling, aggregation, 188 flexible choice of tunnel technology in the SP network, support for 189 both segmented and non-segmented tunnels, ability to use wildcards to 190 identify sets of multicast flows, support for the Any Source 191 Multicast (ASM), Single Source Multicast (SSM), and Bidirectional 192 (bidir) multicast paradigms, support for both IPv4 and IPv6 multicast 193 flows over either an IPv4 or IPv6 SP infrastructure, support for 194 unsolicited flooded data (including support for BSR as RP-to-group 195 mapping protocols), etc. 197 This document not only uses MVPN procedures for GTM, but also, 198 insofar as possible, uses the same protocol elements, encodings, and 199 formats. The BGP Updates for GTM thus use the same Subsequent 200 Address Family Identifier (SAFI), and have the same Network Layer 201 Reachability Information (NLRI) format, as the BGP Updates for MVPN. 203 The document [seamless-mcast] extends [RFC6514] by providing 204 procedures that allow tunnels through the core to be "segmented" at 205 ABRs within the core. The ABR segmentation procedures are also 206 applicable to GTM as defined in the current document. In general, 207 the MVPN procedures of [seamless-mcast], adapted as specified in the 208 current document, are applicable to GTM. 210 The document [seamless-mcast] also defines a set of procedures for 211 GTM. Those procedures are different from the procedures defined in 212 the current document, and the two sets of procedures are not 213 interoperable with each other. The two sets of procedures can co- 214 exist in the same network, as long as they are not applied to the 215 same multicast flows or to the same multicast group addresses. See 216 section 3 for more details. 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in [RFC2119]. 222 2. Adapting MVPN Procedures to GTM 224 In general, PBRs support Global Table Multicast by using the 225 procedures that PE routers use to support VPN multicast. For GTM, 226 where [RFC6513] and [RFC6514] talk about the "PE-CE interface", one 227 should interpret that to mean the interface between the AR and the 228 PBR. For GTM, where [RFC6513] and [RFC6514] talk about the 229 "backbone" network, one should interpret that to mean the part of the 230 network that is delimited by the PBRs. 232 A few adaptations to the procedures of [RFC6513] and [RFC6514] need 233 to be made. Those adaptations are described in the following sub- 234 sections. 236 2.1. Use of Route Distinguishers 238 The MVPN procedures require the use of BGP routes, defined in 239 [RFC6514], that have a SAFI value of 5 ("MCAST-VPN"). We refer to 240 these simply as "MCAST-VPN routes". [RFC6514] defines the Network 241 Layer Reachability Information (NLRI) format for MCAST-VPN routes. 242 The NLRI field always begins with a "Route Type" octet, and, 243 depending on the route type, may be followed by a "Route 244 Distinguisher" (RD) field. 246 When a PBR originates an MCAST-VPN route in support of GTM, the RD 247 field (for those routes types where it is defined) of that route's 248 NLRI MUST be set to zero (i.e., to 64 bits of zero). Since no VRF 249 may have an RD of zero, this allows "MCAST-VPN" routes that are 250 "about" GTM to be distinguished from MCAST-VPN routes that are about 251 VPNs. 253 2.2. Use of Route Targets 255 The MVPN procedures require all MCAST-VPN routes to carry Route 256 Targets (RTs). When a PE router receives an MCAST-VPN route, it 257 processes the route in the context of a particular VRF if and only if 258 the route is carrying an RT that is configured as one of that VRF's 259 "import RTs". 261 There are two different "kinds" of RT used in MVPN. 263 - One kind of RT is carried only by the following MCAST-VPN route 264 types: C-multicast Shared Tree Joins, C-multicast Source Tree 265 Joins, and Leaf A-D routes. This kind of RT identifies the PE 266 router that has been selected by the route's originator as the 267 "Upstream PE" or as the "Upstream Multicast Hop" (UMH) for a 268 particular (set of) multicast flow(s). Per [RFC6514] and 269 [RFC6515], this RT must be an IPv4-address-specific or 270 IPv6-address-specific Extended Community (EC), whose "Global 271 Administrator" field identifies the Upstream PE or the UMH. If 272 the Global Administrator field identifies the Upstream PE, the 273 "Local Administrator" field identifies a particular VRF in that 274 PE. 276 The GTM procedures of this document require the use of this type 277 of RT, in exactly the same situations where it is used in the 278 MVPN specification. However, one adaptation is necessary: the 279 "Local Administrator" field of this kind of RT MUST always be set 280 to zero, thus implicitly identifying the global table, rather 281 than identifying a VRF. We will refer to this kind of RT as a 282 "PBR-identifying RT". 284 - The other kind of RT is the conventional RT first specified in 285 [RFC4364]. It does not necessarily identify a particular router 286 by address, but is used to constrain the distribution of VPN 287 routes, and to ensure that a given VPN route is processed in the 288 context of a given VRF if and only if the route is carrying an RT 289 that has been configured as one of that VRF's "import RTs". 291 Whereas every VRF must be configured with at least one import RT, 292 there is heretofore no requirement to configure any RTs for the 293 global table of any router. As stated above, this document makes 294 the use of PBR-identifying RTs mandatory for GTM. This document 295 makes the use of non-PBR-identifying RTs OPTIONAL for GTM. 297 The procedures for the use of RTs in GTM are the following: 299 - If the global table of a particular PBR is NOT configured with 300 any import RTs, then a received MCAST-VPN route is processed in 301 the context of the global table only if it is carrying no RTs, or 302 if it is carrying a PBR-identifying RT whose Global Administrator 303 field identifies that PBR. 305 - The global table in each PBR MAY be configured with (a) a set of 306 export RTs to be attached to MCAST-VPN routes that are originated 307 to support GTM, and (b) with a set of import RTs for GTM. 309 If the global table of a given PBR has been so configured, the 310 PBR will process a received MCAST-VPN route in the context of the 311 global table if and only if the route carries an RT that is one 312 of the global table's import RTs, or if the route carries a PBR- 313 identifying RT whose global administrator field identifies the 314 PBR. 316 If the global tables are configured with RTs, care must be taken 317 to ensure that the RTs configured for the global table are 318 distinct from any RTs used in support of MVPN (except in the case 319 where it is actually intended to create an "extranet" 320 [MVPN-extranet] in which some sources are reachable in global 321 table context while others are reachable in VPN context.) 323 The "RT Constraint" procedures of [RFC4684] MAY be used to constrain 324 the distribution of MCAST-VPN routes (or other routes) that carry RTs 325 that have been configured as import RTs for GTM. (This includes the 326 PBR-identifying RTs.) 328 In [RFC6513], the UMH-eligible routes (see section 5.1 of [RFC6513], 329 "Eligible Routes for UMH Selection") are generally routes of SAFI 128 330 (Labeled VPN-IP routes) or 129 (VPN-IP multicast routes), and are 331 required to carry RTs. These RTs determine which VRFs import which 332 such routes. However, for GTM, when the UMH-eligible routes may be 333 routes of SAFI 1, 2, or 4, the routes are not required to carry RTs. 334 This document does NOT specify any new rules for determine whether a 335 SAFI 1, 2, or 4 route is to be imported into the global table of any 336 PBR. 338 2.3. UMH-eligible Routes 340 [RFC6513] section 5.1 defines procedures by which a PE router 341 determines the "C-root", the "Upstream Multicast Hop" (UMH), the 342 "Upstream PE", and the "Upstream RD" of a given multicast flow. (In 343 non-VPN multicast documents, the UMH of a multicast flow at a 344 particular router is generally known as the "RPF neighbor" for that 345 flow.) It also defines procedures for determining the "Source AS" of 346 a particular flow. Note that in GTM, the "Upstream PE" is actually 347 the "Upstream PBR". 349 The definition of the C-root of a flow is the same for GTM as for 350 MVPN. 352 For MVPN, to determine the UMH, Upstream PE, Upstream RD, and Source 353 AS of a flow, one looks up the C-root of the flow in a particular 354 VRF, and finds the "UMH-eligible" routes (see section 5.1.1 of 355 [RFC6513]) that "match" the C-root. From among these, one is chosen 356 as the "selected UMH route". 358 For GTM, the C-root is of course looked up in the global table, 359 rather than in a VRF. For MVPN, the UMH-eligible routes are routes 360 of SAFI 128 or 129. For GTM, the UMH-eligible routes are routes of 361 SAFI 1, SAFI 4, or SAFI 2. If the global table has imported routes 362 of SAFI 2, then these are the UMH-eligible routes. Otherwise, routes 363 of SAFI 1 or SAFI 4 are the UMH-eligible routes. For the purpose of 364 UMH determination, if a SAFI 1 route and a SAFI 4 route contain the 365 same IP prefix in their respective NLRI fields, then the two routes 366 are considered by the BGP bestpath selection process to be 367 comparable. 369 [RFC6513] defines procedures for determining which of the UMH- 370 eligible routes that match a particular C-root is to become the 371 "Selected UMH route". With one exception, these procedures are also 372 applicable to GTM. The one exception is the following. Section 373 9.1.2 of [RFC6513] defines a particular method of choosing the 374 Upstream PE, known as "Single Forwarder Selection" (SFS). This 375 procedure MUST NOT be used for GTM. 377 To see why the SFS procedure cannot be applied to GTM, consider the 378 following example scenario. Suppose some multicast source S is homed 379 to both PBR1 and PBR2, and suppose that both PBRs export a route (of 380 SAFI 1, 2, or 4) whose NLRI is a prefix matching the address of S. 381 These two routes will be considered comparable by the BGP decision 382 process. A route reflector receiving both routes may thus choose to 383 redistribute just one of the routes to S, the one chosen by the 384 bestpath algorithm. Different route reflectors may even choose 385 different routes to redistribute (i.e., one route reflector may 386 choose the route to S via PBR1 as the bestpath, while another chooses 387 the route to S via PBR2 as the bestpath). As a result, some PBRs may 388 receive only the route to S via PBR1 and some may receive only the 389 route to S via PBR2. In that case, it is impossible to ensure that 390 all PBRs will choose the same route to S. 392 The SFS procedure works in VPN context as along the following 393 assumption holds: if S is homed to VRF-x in PE1 and to VRF-y in PE2, 394 then VRF-x and VRF-y have been configured with different RDs. In VPN 395 context, the route to S is of SAFI 128 or 129, and thus has an RD in 396 its NLRI. So the route to S via PE1 will not have the same NLRI as 397 the route to S via PE2. As a result, all PEs will see both routes, 398 and the PEs can implement a procedure that ensures that they all pick 399 the same route to S. 401 That is, the SFS procedure of [RFC6513] relies on the UMH-eligible 402 routes being of SAFI 128 or 129, and relies on certain VRFs being 403 configured with distinct RDs. Thus the procedure cannot be applied 404 to GTM. 406 In GTM, the "Upstream RD" of a multicast flow is always considered to 407 be zero, and is NOT determined from the Selected UMH route. 409 The MVPN specifications require that when BGP is used for 410 distributing multicast routing information, the UMH-eligible routes 411 MUST carry the VRF Route Import EC and the Source AS EC. To 412 determine the Upstream PE and Source AS for a particular multicast 413 flow, the Upstream PE and Source AS are determined, respectively, 414 from the VRF Route Import EC and the Source AS EC of the Selected UMH 415 route for that flow. These ECs are generally attached to the UMH- 416 eligible routes by the PEs that originate the routes. 418 In GTM, there are certain situations in which it is allowable to omit 419 the VRF Route Import EC and/or the Source AS EC from the UMH-eligible 420 routes. The following sub-sections specify the various options for 421 determining the Upstream PBR and the Source AS in GTM. 423 The procedures in sections 2.3.1 and 2.3.2 MUST be implemented. The 424 procedures in sections 2.3.3 and 2.3.4 are OPTIONAL to implement. It 425 should be noted that while the optional procedures may be useful in 426 particular deployment scenarios, there is always the potential for 427 interoperability problems when relying on OPTIONAL procedures. 429 2.3.1. Routes of SAFI 1, 2 or 4 with MVPN ECs 431 If the UMH-eligible routes have a SAFI of 1, 2 or 4, then they MAY 432 carry the VRF Route Import EC and/or the Source AS EC. If the 433 selected UMH route is a route of SAFI 1, 2 or 4 that carries the VRF 434 Route Import EC, then the Upstream PBR is determined from that EC. 435 Similarly, if the selected UMH route is a route of SAFI 1, 2, or 4 436 route that carries the Source AS EC, the Source AS is determined from 437 that EC. 439 When the procedure of this section is used, a PBR that distributes a 440 UMH-eligible route to other PBRs is responsible for ensuring that the 441 VRF Route Import and Source AS ECs are attached to it. 443 If the selected UMH-eligible route has a SAFI of 1, 2 or 4, but is 444 not carrying a VRF Route Import EC, then the Upstream PBR is 445 determined as specified in section 2.3.2 or 2.3.3 below. 447 If the selected UMH-eligible route has a SAFI of 1, 2 or 4, but is 448 not carrying a Source AS EC, then the Source AS is considered to be 449 the local AS. 451 2.3.2. MVPN ECs on the Route to the Next Hop 453 Some service providers may consider it to be undesirable to have the 454 PBRs put the VRF Route Import EC on all the UMH-eligible routes. Or 455 there may be deployment scenarios in which the UMH-eligible routes 456 are not advertised by the PBRs at all. The procedures described in 457 this section provide an alternative that can be used under certain 458 circumstances. 460 The procedures of this section are OPTIONAL. 462 In this alternative procedure, each PBR MUST originate a BGP route of 463 SAFI 1, 2 or 4 to itself. This route MUST carry a VRF Route Import 464 EC that identifies the PBR. The address that appears in the Global 465 Administrator field of that EC MUST be the same address that appears 466 in the NLRI and in the Next Hop field of that route. This route MUST 467 also carry a Source AS EC identifying the AS of the PBR. 469 Whenever the PBR distributes a UMH-eligible route for which it sets 470 itself as next hop, it MUST use this same IP address as the Next Hop 471 of the UMH-eligible route that it used in the route discussed in the 472 prior paragraph. 474 When the procedure of his section is used, then when a PBR is 475 determining the Selected UMH Route for a given multicast flow, it may 476 find that the Selected UMH Route has no VRF Route Import EC. In this 477 case, the PBR will look up (in the global table) the route to the 478 Next Hop of the Selected UMH route. If the route to the Next Hop has 479 a VRF Route Import EC, that EC will be used to determine the Upstream 480 PBR, just as if the EC had been attached to the Selected UMH Route. 482 If recursive route resolution is required in order to resolve the 483 next hop, the Upstream PBR will be determined from the first route 484 with a VRF Route Import EC that is encountered during the recursive 485 route resolution process. (The recursive route resolution process 486 itself is not modified by this document.) 488 The same procedure can be applied to find the Source AS, except that 489 the Source AS EC is used instead of the VRF Route Import EC. 491 Note that this procedure is only applicable in scenarios where it is 492 known that the Next Hop of the UMH-eligible routes is not be changed 493 by any router that participates in the distribution of those routes; 494 this procedure MUST NOT be used in any scenario where the next hop 495 may be changed between the time one PBR distributes the route and 496 another PBR receives it. The PBRs have no way of determining 497 dynamically whether the procedure is applicable in a particular 498 deployment; this must be made known to the PBRs by provisioning. 500 Some scenarios in which this procedure can be used are: 502 - all PBRs are in the same AS, or 504 - the UMH-eligible routes are distributed among the PBRs by a Route 505 Reflector (that does not change the next hop), or 507 - the UMH-eligible routes are distributed from one AS to another 508 through ASBRs that do not change the next hop. 510 If the procedures of this section are used in scenarios where they 511 are not applicable, GTM will not function correctly. 513 2.3.3. Non-BGP Routes as the UMH-eligible Routes 515 In particular deployment scenarios, there may be specific procedures 516 that can be used, in those particular scenarios, to determine the 517 Upstream PBR for a given multicast flow. 519 Suppose the PBRs neither put the VRF Route Import EC on the UMH- 520 eligible routes, nor do they distribute BGP routes to themselves. It 521 may still be possible to determine the Upstream PBR for a given 522 multicast flow, using specific knowledge about the deployment. 524 For example, suppose it is known that all the PBRs are in the same 525 OSPF area. It may be possible to determine the Upstream PBR for a 526 given multicast flow by looking at the link state database to see 527 which router is attached to the flow's C-root. 529 As another example, suppose it is known that the set of PBRs is fully 530 meshed via Traffic Engineering (TE) tunnels. When a PBR looks up, in 531 its global table, the C-root of a particular multicast flow, it may 532 find that the next hop interface is a particular TE tunnel. If it 533 can determine the identify of the router at the other end of that TE 534 tunnel, it can deduce that that router is the Upstream PBR for that 535 flow. 537 This is not an exhaustive set of examples. Any procedure that 538 correctly determines the Upstream PBR in a given deployment scenario 539 MAY be used in that scenario. 541 2.4. Inclusive and Selective Tunnels 543 The MVPN specifications allow multicast flows to be carried on either 544 Inclusive Tunnels or on Selective Tunnels. When a flow is sent on an 545 Inclusive Tunnel of a particular VPN, it is sent to all PEs in that 546 VPN. When sent on a Selective Tunnel of a particular VPN, it may be 547 sent to only a subset of the PEs in that VPN. 549 This document allows the use of either Inclusive Tunnels or Selective 550 Tunnels for GTM. However, any service provider electing to use 551 Inclusive Tunnels for GTM should carefully consider whether sending a 552 multicast flow to ALL its PBRs would result in problems of scale. 553 There are potentially many more MBRs for GTM than PEs for a 554 particular VPN. If the set of PBRs is large and growing, but most 555 multicast flows do not need to go to all the PBRs, the exclusive use 556 of Selective Tunnels may be a better option. 558 2.5. I-PMSI A-D Routes 560 2.5.1. Intra-AS I-PMSI A-D Routes 562 Per [MVPN-BGP}, there are certain conditions under which is it NOT 563 required for a PE router implementing MVPN to originate one or more 564 Intra-AS I-PMSI A-D routes. These conditions apply as well to PBRs 565 implementing GTM. 567 In addition, a PBR implementing GTM is NOT required to originate an 568 Intra-AS I-PMSI A-D route if both of the following conditions hold: 570 - The PBR is not using Inclusive Tunnels for GTM, and 572 - The distribution of the C-multicast Shared Tree Join and C- 573 multicast Source Tree Join routes is done in such a manner that 574 the next hop of those routes does not change. 576 Please see also the sections on RD and RT usage. 578 2.5.2. Inter-AS I-PMSI A-D Routes 580 There are no GTM-specific procedures for the origination, 581 distribution, and processing of these routes, other than those 582 specified in the sections on RD and RT usage. 584 2.6. S-PMSI A-D Routes 586 There are no GTM-specific procedures for the origination, 587 distribution, and processing of these routes, other than those 588 specified in the sections on RD and RT usage. 590 2.7. Leaf A-D Routes 592 There are no GTM-specific procedures for the origination, 593 distribution, and processing of these routes, other than those 594 specified in the sections on RD and RT usage. 596 2.8. Source Active A-D Routes 598 There are no MANDATORY GTM-specific procedures for the origination, 599 distribution, and processing of these routes, other than those 600 specified in the sections on RD and RT usage. 602 However, this document defines an OPTIONAL procedure to allow 603 additional constraints on the distribution of the Source Active A-D 604 routes for GTM. If some site has receivers for a particular ASM 605 group G, then it is possible (by the procedures of [RFC6514]) that 606 every PBR attached to site with a source for group G will originate a 607 Source Active A-D route whose NLRI identifies that source and group. 608 These Source Active A-D routes may be distributed to every PBR. If 609 only a relatively small number of PBRs are actually interested in 610 traffic from group G, but there are many sources for group G, this 611 could result in a large number of (S,G) Source Active A-D routes 612 being installed in a large number of PBRs that have no need of them. 614 For GTM, it is possible to constrain the distribution of (S,G) Source 615 Active A-D routes to those PBRs that are interested in GTM traffic to 616 group G. This can be done using the following OPTIONAL procedures: 618 - If a PBR originates a C-multicast Shared Tree Join whose NLRI 619 contains (RD=0,*,G), then it dynamically creates an import RT for 620 its global table, where the Global Administrator field of the RT 621 contains the group address G, and the Local Administrator field 622 contains zero. (Note that an IPv6-address-specific RT would need 623 to be used if the group address is an IPv6 address.) 625 - When a PBR creates such an import RT, it uses "RT Constraint" 626 [RFC4684] procedures to advertise its interest in routes that 627 carry this RT. 629 - When a PBR originates a Source Active A-D route from its global 630 table, it attaches the RT described above. 632 - When the C-multicast Shared Tree Join is withdrawn, so is the 633 corresponding RT constrain route, and the corresponding RT is 634 removed as an import RT of its global table. 636 These procedures enable a PBR to automatically filter all Source 637 Active A-D routes that are about multicast groups in which the PBR 638 has no interest. 640 This procedure does introduce the overhead of distributing additional 641 "RT Constraint" routes, and therefore may not be cost-effective in 642 all scenarios, especially if the number of sources per ASM group is 643 small. This procedure may also result in increased join latency. 645 2.9. C-multicast Source/Shared Tree Joins 647 [RFC6514] section 11.1.3 has the following procedure for determining 648 the IP-address-specific RT that is attached to a C-multicast route: 649 (a) determine the upstream PE, RD, AS, (b) find the proper Inter-AS 650 or Intra-AS I-PMSI A-D route based on (a), (c) find the next hop of 651 that A-D route, (d) base the RT on that next hop. 653 However, for GTM, in environments where it is known a priori that 654 that the next hop of the C-multicast Source/Shared Tree Joins does 655 not change during the distribution of those routes, the proper 656 procedure for creating the IP-address-specific RT is to just put the 657 IP Address of the Upstream PBR in the Global Administrator field of 658 the RT. In other scenarios, the procedure of the previous paragraph 659 (as modified by this document's sections on "RD usage" and "RT 660 usage") is applied by the PBRs. 662 3. Differences from other MVPN-like GTM Procedures 664 The document [seamless-mcast] also defines a procedure for GTM that 665 is based on the BGP procedures that were developed for MVPN. 667 However, the GTM procedures of [seamless-mcast] are different than 668 and are NOT interoperable with the procedures defined in this 669 document. 671 The two sets of procedures can co-exist in the same network, as long 672 as they are not applied to the same multicast flows or to the same 673 ASM multicast group addresses. 675 Some of the major differences between the two sets of procedures are 676 the following; 678 - The [seamless-mcast] procedures for GTM do not use C-multicast 679 Shared Tree Joins or C-multicast Source Tree Joins at all. The 680 procedures of this document use these C-multicast routes for GTM, 681 setting the RD field of the NLRI to zero. 683 - The [seamless-mcast] procedures for GTM use Leaf A-D routes 684 instead of C-multicast Shared/Source Tree Join routes. Leaf A-D 685 routes used in that manner can be distinguished from Leaf A-D 686 routes used as specified in [RFC6514] by means of the NLRI 687 format; [seamless-mcast] defines a new NLRI format for Leaf A-D 688 routes. Whether a given Leaf A-D route is being used according 689 to the [seamless-mcast] procedures or not can be determined from 690 its NLRI. (See [seamless-mcast] section "Leaf A-D Route for 691 Global Table Multicast".) 693 - The Leaf A-D routes used by the current document contain an NLRI 694 that is in the format defined in [RFC6514], NOT in the format as 695 defined in [seamless-mcast]. The procedures assumed by this 696 document for originating and processing Leaf A-D routes are as 697 specified in [RFC6514], NOT as specified in [seamless-mcast]. 699 - The current document uses an RD value of zero in the NLRI in 700 order to indicate that a particular route is "about" a Global 701 Table Multicast, rather than a VPN multicast. No other semantics 702 are inferred from the fact that RD is zero. [seamless-mcast] 703 uses two different RD values in its GTM procedures, with semantic 704 differences that depend upon the RD values. 706 - In order for both sets of procedures to co-exist in the same 707 network, the PBRs MUST be provisioned so that for any given IP 708 group address in the global table, all egress PBRs use the same 709 set of procedures for that group address (i.e., for group G, 710 either all egress PBRs use the GTM procedures of this document or 711 all egress PBRs use the GTM procedures of [seamless-mcast]. 713 4. IANA Considerations 715 This document has no IANA considerations. 717 5. Security Considerations 719 The security considerations of this document are primarily the 720 security considerations of the base protocols, as discussed in 721 [RFC6514], [RFC4601], and [RFC5294]. 723 This document makes use of a BGP SAFI (MCAST-VPN routes) that was 724 originally designed for use in VPN contexts only. It also makes use 725 of various BGP path attributes and extended communities (VRF Route 726 Import Extended Community, Source AS Extended Community, Route Target 727 Extended Community) that were originally intended for use in VPN 728 contexts. If these routes and/or attributes leak out into "the 729 wild", multicast data flows may be distributed in an unintended 730 and/or unauthorized manner. 732 Internet providers often make extensive use of BGP communities (ie, 733 adding, deleting, modifying communities throughout a network). As 734 such, care should be taken to avoid deleting or modifying the VRF 735 Route Import Extended Community and Source AS Extended Community. 736 Incorrect manipulation of these ECs may result in multicast streams 737 being lost or misrouted. 739 The procedures of this document require certain BGP routes to carry 740 IP multicast group addresses. Generally such group addresses are 741 only valid within a certain scope. If a BGP route containing a group 742 address is distributed outside the boundaries where the group address 743 is meaningful, unauthorized distribution of multicast data flows may 744 occur. 746 6. Acknowledgments 748 The authors would like to thank Rahul Aggarwal, Huajin Jeng, Yakov 749 Rekhter, and Samir Saad for their contributions to this work. 751 7. Authors' Addresses 753 Lenny Giuliano 754 Juniper Networks 755 2251 Corporate Park Drive 756 Herndon, VA 20171 757 US 758 Email: lenny@juniper.net 760 Dante J. Pacella 761 Verizon 762 Verizon Communications 763 22001 Loudoun County Parkway 764 Ashburn, VA 20147 765 US 766 Email: dante.j.pacella@verizonbusiness.com 768 Eric C. Rosen 769 Cisco Systems, Inc. 770 1414 Massachusetts Avenue 771 Boxborough, MA, 01719 772 US 773 Email: erosen@cisco.com 775 Karthik Subramanian 776 Cisco Systems, Inc. 777 170 Tasman Drive 778 San Jose, CA, 95134 779 US 780 Email: kartsubr@cisco.com 781 Jeffrey Zhang 782 Juniper Networks 783 10 Technology Park Dr. 784 Westford, MA 01886 785 US 786 Email: zzhang@juniper.net 788 Jason Schiller 789 Google 790 1818 Library Street 791 Suite 400 792 Reston, VA 20190 793 US 794 Email: jschiller@google.com 796 8. References 798 8.1. Normative References 800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 801 Requirement Levels", BCP 14, RFC 2119, March 1997. 803 [RFC4364], Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 804 Networks", RFC 4364, February 2006. 806 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", 807 RFC 6513, February 2012. 809 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 810 Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 811 6514, February 2012. 813 [RFC6515] Aggarwal, R., and E. Rosen, "IPv4 and IPv6 Infrastructure 814 Addresses in BGP Updates for Multicast VPN", RFC 6515, February 2012. 816 8.2. Informative References 818 [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. 819 Yamagata, "Internal BGP as the Provider/Customer Edge Protocol for 820 BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 6368, September 821 2011. 823 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 824 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 825 Specification (Revised)", RFC 4601, August 2006. 827 [RFC4684] P. Marques, et. al., "Constrained Route Distribution for 828 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 829 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 830 November 2006. 832 [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol 833 Independent Multicast (PIM)", RFC 5294, August 2008. 835 [MVPN-extranet] Rekhter, Y. and E. Rosen (editors), "Extranet 836 Multicast in BGP/IP MPLS VPNs", draft-ietf-l3vpn-mvpn- 837 extranet-02.txt, August 2013 839 [seamless-mcast] Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, 840 I., Leymann, N., and S. Saad,"Inter-Area P2MP Segmented LSPs", draft- 841 ietf-mpls-seamless-mcast-07.txt, May 2013