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