idnits 2.17.1 draft-rosen-l3vpn-mvpn-extranet-04.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 (February 6, 2012) is 4461 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 normative reference: RFC 4601 (ref. 'PIM') (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Yiqun Cai 3 Internet Draft Eric C. Rosen (Editor) 4 Intended Status: Proposed Standard Rajesh Sharma 5 Expires: August 6, 2012 IJsbrand Wijnands 6 Cisco Systems, Inc. 8 February 6, 2012 10 MVPN: Extranets, Anycast-Sources, 'Hub & Spoke', with PIM Control Plane 12 draft-rosen-l3vpn-mvpn-extranet-04.txt 14 Abstract 16 This document provides the specification for using the PIM control 17 plane of to provide Multicast Virtual Private Network support for 18 extranets, for anycast sources, and for "hub and spoke" 19 configurations. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Copyright and License Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Specification of requirements ......................... 3 60 2 Introduction .......................................... 3 61 3 Extranets using PIM as the MVPN Control Plane ......... 3 62 3.1 Default PMSI .......................................... 4 63 3.2 Red method ............................................ 4 64 3.2.1 Control Plane RPF Check ............................... 5 65 3.2.2 Data Plane RPF Check .................................. 5 66 3.3 Blue method ........................................... 5 67 3.4 Binding Specific Extranet C-Flows to S-PMSIs .......... 6 68 3.5 Two VRFs on One PE .................................... 7 69 4 Supporting Anycast Sources with PIM Control Plane ..... 7 70 5 Hub and Spoke MVPNs ................................... 8 71 5.1 Unicast Hub and Spoke VPNs ............................ 8 72 5.2 Multicast Hub and Spoke VPNs .......................... 10 73 6 IANA Considerations ................................... 13 74 7 Security Considerations ............................... 13 75 8 Acknowledgments ....................................... 13 76 9 Authors' Addresses .................................... 13 77 10 Normative References .................................. 14 78 1. Specification of requirements 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Introduction 86 This document extends the PIM control plane of [MVPN] to provide 87 support for the following features: 89 - MVPN Extranets 91 In an MVPN "extranet", the transmitter of a multicast traffic 92 flow is in a different VPN than the receivers. Additional 93 procedures are defined to determine how the traffic is associated 94 with a particular MI-PMSI [MVPN]or MS-PMSI [MVPN_MSPMSI], and how 95 the RPF checks are done. 97 - Support for Anycast Sources 99 - Support for "Hub and Spoke" VPNs 101 3. Extranets using PIM as the MVPN Control Plane 103 Suppose there are two VPNs. VPN1 consists of a set of VRFs, each of 104 which has been configured with RT1 as it export and import Route 105 Target. VPN2 consists of a set of VRFs, each of which has been 106 configured with RT2 as it export and import Route Target. For 107 convenience, we will use the term "blue" instead of "RT1" and the 108 term "red" instead of "RT2". Thus we will call VPN1 the "blue VPN" 109 and VPN2 the "red VPN". Similarly, the blue VPN consists of a number 110 of "blue sites" containing "blue systems"; these sites are attached 111 to PEs via VRF interfaces that are associated with "blue VRFs". 113 We want to create an MVPN extranet in which blue receivers can join 114 multicast groups whose sources and/or RPs are red. 116 The first step is to ensure that the blue VRFs (or the subset of blue 117 VRFs whose attached sites are allowed to receive multicasts from red 118 sources) import routes to the red sources. This is done as follows: 120 - The red VRFs are configured so that the subset of red routes that 121 are to be part of the extranet are exported with a seconds RT 122 value (call it RT3), as well as with RT2. For convenience, we 123 will call RT3 "violet". 125 - The blue VRFs are configured so that they import violet routes as 126 well as blue routes. 128 There are two different methods of providing the extranets, which 129 will shall call the "red method" and the "blue method". (Remember 130 that the red VPN contains the transmitter, and the blue VPN contains 131 the receivers.) 133 This document assumes that in the case of non-SSM extranet multicast 134 groups, the mapping between a group address and an RP is 135 pre-configured in the PEs. 137 This document does not provide support for bidirectional C-trees in 138 extranets. 140 3.1. Default PMSI 142 Some of the procedures subsequently specified in this section are 143 largely independent of whether PIM is used with (a) an MI-PMSI or (b) 144 with an MS-PMSI that has been bound to the double wildcard. We will 145 use the term "default PMSI" as a general term to mean either (a) or 146 (b), depending upon which technique is actually being used in a given 147 network. 149 3.2. Red method 151 In the "red method", extranet multicasts are carried by default in 152 the default PMSI of the red VPN, which we will of course call the 153 "red PMSI". 155 To use this method, blue VRFs must be configured to import "red" 156 I-PMSI A-D routes and red S-PMSI A-D routes. If MI-PMSIs are being 157 used, the blue VRFs must immediately join the P-tunnels specified in 158 the red I-PMSI A-D routes. If MS-PMSIs are being used, a blue VRF 159 need not join the MS-PMSI P-tunnel rooted at a particular PE unless a 160 PIM Join needs to be sent to that PE. 162 The PIM C-instance associated with a blue VRF will treat the red and 163 blue default PMSIs as two different PIM interfaces. 165 The blue VRFs must also be configured to "associate" violet unicast 166 routes with the red default PMSI. What this means is that the red 167 default PMSI will be considered to be the RPF interface for the 168 violet unicast routes. The RPF interface for the blue unicast routes 169 remains, as usual, the blue default PMSI. 171 All that remains to be specified is how the control plane and data 172 plane RPF checks are done. Apart from these MVPN-specific procedures 173 for the RPF check, ordinary PIM procedures are used. 175 3.2.1. Control Plane RPF Check 177 Suppose a PE receives a PIM Join(S,G) from a CE, over a VRF interface 178 that is associated with a blue VRF. The PE does the RPF check for S 179 by looking up S in the blue VRF. If the route matching S is a blue 180 route (i.e., carries the blue RT but not the violet RT), then a Join 181 is sent over the blue default PMSI. However, if the route matching S 182 is a violet route (i.e., carries the violet RT), a Join is sent over 183 the red default PMSI. 185 If the PE receives a PIM Join(*,G) from a CE, the RPF check is done 186 against the address of the corresponding RP; otherwise the procedure 187 is the same. 189 3.2.2. Data Plane RPF Check 191 Suppose a red default PMSI has been associated with a blue VRF, as 192 specified above, and an (S,G) multicast data packet is received from 193 the red default PMSI. Then S is looked up in the (blue) VRF. If it 194 matches a violet route, the packet is forwarded normally. However, 195 if it matches a blue route, the packet is discarded as having failed 196 the RPF check. 198 This prevents the blue sites from receiving packets from red 199 transmitters, except in the case where routes to the red receivers 200 have been explicitly imported into the blue VRF. 202 3.3. Blue method 204 In the "blue method", extranet multicasts are carried by default in 205 the default PMSI of the blue VPN. 207 In the blue method, the red VRFs must be configured to import "blue" 208 I-PMSI and S-PMSI A-D routes. If MI-PMSIs are being used the 209 P-tunnels specified therein must be joined immediately. If MS-PMSIs 210 are being used, the P-tunnels need not be joined unless and until it 211 is necessary to send a PIM Join to the root of the P-tunnel. 213 The PIM C-instance associated with a red VRF will treat the red 214 default PMSI and the blue default PMSI as two different PIM 215 interfaces. 217 PIM Joins from blue receivers are then received at the red VRF over 218 the blue PMSI, whereas PIM Joins from red receivers are received at 219 the red VRF over the red PMSI. As a result, PIM may add one or the 220 other or both PMSIs to a particular multicast tree's olist. 222 In this method, the blue VRFs are associated with only one default 223 PMSI, so the RPF check for both blue and violet sources (and RPs) 224 always resolves to that PMSI. Hence the special RPF check procedures 225 of the red method are not necessary. However, a PE with a red VRF 226 may need to transmit multicast traffic on more than one MI-PMSI. 228 Note that since the data plane RPF check of section 3.2.2 is not 229 needed, one does not really need a "violet" RT value. Rather, one 230 may simply configure certain routes from the red VRF to be exported 231 with both the red and the blue RTs. 233 3.4. Binding Specific Extranet C-Flows to S-PMSIs 235 If the procedure of [MVPN] section 7.4.2 is used, the S-PMSI Join 236 message MUST be sent on whatever default PMSI or default PMSIs are 237 used to carry the C-flow identified in the message. 239 If the procedure of [MVPN]section 7.4.1 is used, then procedures 240 differ slightly depending upon whether the red method or the blue 241 method is in use. 243 If the red method is in use, and if a C-flow whose target source is 244 exported from a red VRF is bound to an S-PMSI, then the S-PMSI A-D 245 route that specifies the binding must carry both the red RT and the 246 violet RT. Blue VRFs must be configured to import the violet S-PMSI 247 A-D routes. 249 If the blue method is in use, and if a C-flow whose target source is 250 exported from a red VRF is bound to an S-PMSI, then the S-PMSI A-D 251 route that specifies the binding: 253 - must carry the red RT if the C-flow has any receivers on the red 254 default PMSI, and 256 - must carry the blue RT if the C-flow has any receivers on the 257 blue default PMSI. 259 3.5. Two VRFs on One PE 261 It is possible that a red VRF and a blue VRF will exist on the same 262 PE. Then by the above procedures, one of these VRFs will need to 263 join a PMSI that it can use for sending control packets to and 264 receiving data packets from the other. However, the protocol used to 265 construct the P-tunnels instantiating the PMSI may not provide a 266 mechanism by which a given PE can join a P-tunnel of which it is the 267 root. In this case, the PE implementation MUST support a local 268 function whereby a given VRF, say VRF1, can "join" a P-tunnel whose 269 root is another VRF, say VRF2, on the same PE. The PE MUST also 270 support a local function whereby packets can be transmitted from one 271 VRF to another just as if the VRFs had been on separate PEs. 273 4. Supporting Anycast Sources with PIM Control Plane 275 Suppose that some customer site contains router C-R1 and some other 276 customer site in the same VPN contains router C-R2. And that each 277 sends a PIM Join(C-S,C-G) messages towards C-S. Ordinarily, the 278 result will be to create a single C-tree whose root is C-S and whose 279 leaves include C-R1 and C-R2. 281 However, in some deployment scenarios, C-S may be an anycast address 282 that belongs to two or more different sources, say C-S1 and C-S2. 283 Let's suppose that these two sources attach to the VPN backbone 284 through two different PEs, and let's further suppose that C-S1 is 285 "close" to C-R1, and C-S2 is "close" to C-R2. Then even though both 286 C-R1 and C-R2 send Join(S,G) messages, what is really desired is to 287 create two C-trees, one rooted at C-S1 (with C-R1 as a leaf) and one 288 rooted at C-S2 (with C-R2 as a leaf). 290 If the data traffic traveling along both C-trees is carried on a 291 single MI-PMSI, it is important that a (C-S,C-G) data packet is 292 forwarded towards C-R1 only if the packet is actually traveling on 293 the C-tree rooted at C-S1, and not on the C-tree rooted as C-S2. 295 To ensure this, if a particular MVPN is providing anycast service, 296 its PEs MUST use the procedure described in section 9.1.1 of [MVPN], 297 and MUST NOT use the procedures described in sections 9.1.2 and 9.1.3 298 of [MVPN]. 300 This also enables the use of C-RPs that have anycast addresses. 302 Furthermore, if anycast source support is provided for a particular 303 multicast group C-G, all PEs MUST execute the procedure described in 304 section 4.2.1 of [PIM], and MUST act as if SwitchToSPTDesired(S,G) 305 (defined in [PIM] section 4.2.1) is true when the first (S,G) packet 306 (from any PE) is received. (This procedure MUST be executed by each 307 PE even if the PE is not the "last hop" of the C-tree.) This will 308 ensure that each PE receives and forwards (C-S,C-G) traffic from the 309 appropriate source C-tree, even if PE has received only Join(C-*,C-G) 310 messages but not Join(C-S,C-G) messages from its directly attached 311 CEs. 313 5. Hub and Spoke MVPNs 315 The Layer 3 Virtual Private Network (L3VPN) technology of [RFC4364] 316 generally provides an "any-to-any" network service, where any system 317 at one site of a VPN can send traffic to and receive traffic from a 318 system at any other site. Or more precisely, nothing in the 319 procedures governing the distribution of routing information in the 320 VPN prevents any-to-any communication. 322 In some deployments, however, it has been convenient to distinguish 323 between two kinds of VPN site, the "hub site" and the "spoke sites". 324 In this section, we first describe how the "hub and spoke" 325 configuration affects the distribution of unicast routing. We then 326 specify a means of providing multicast VPN service in the hub and 327 spoke configuration. 329 5.1. Unicast Hub and Spoke VPNs 331 In a unicast hub and spoke VPN: 333 - any system in a hub site can send traffic to and receive traffic 334 from any other system in a hub site; 336 - any system in a hub site can send traffic to and receive traffic 337 from any system in a spoke site; 339 - any system in a spoke site can send traffic to and receive 340 traffic from any system in a hub site; 342 - a system in one spoke site cannot send traffic to and cannot 343 receive traffic from a system in a different spoke site. 345 Using the technology of [RFC4364], it is possible to create this sort 346 of "hub and spoke" VPN by suitable restricting the flow of routing 347 information among the sites. One way to construct a hub and spoke 348 VPN is as follows: 350 - Within a given VPN, every site is denoted as either a hub site or 351 a spoke site. 353 - On a given PE, every spoke site is attached to a distinct VRF 354 (i.e., all interfaces of that VRF lead to the same spoke site). 355 We will call these "Spoke VRFs". 357 - On a given PE, any number of hub sites can be attached to a 358 single "Hub VRF". 360 - Each Hub VRF is configured with an export-RT that we shall call 361 "Hub_Route", and with a pair of import-RTs, one of which is 362 "Hub_Route", and the other of which we shall call "Spoke_Route". 363 (Of course, each hub and spoke VPN has its unique Hub_Route RT 364 and its unique Spoke_Route RT.) 366 - Each Spoke VRF is configured with export-RT "Spoke_Route" and 367 import-RT "Hub_Route". 369 With this configuration, the Spoke VRFs will contain only routes to 370 systems at hub sites, whereas the Hub VRFs will contain routes to 371 systems at both hub and spoke sites. Even if two spoke sites attach 372 to the same PE, they cannot communicate directly, because they are 373 associated with different VRFs, and their respective VRFs do not 374 import each others' routes. (There are implementation techniques 375 that can eliminate the need to configure a separate VRF for each 376 spoke site on a PE, but these are out of scope of this document.) 378 There are several different variations on this theme. For example, 379 in a particular VPN, spoke-to-spoke communication may be allowed, but 380 only if the spoke-to-spoke traffic first enters a hub site. Some 381 system at the hub site would be responsible for "turning the traffic 382 around", i.e., sending it back to VPN backbone for delivery to the 383 target spoke site. This can be useful if the "turnaround system" at 384 the hub site performs some sort of inspection of the spoke-to-spoke 385 traffic and then applies authorization policies of some sort. To 386 provide this sort of Hub and Spoke VPN: 388 - The total set of routes exported by the Hub VRFs must include 389 routes that "summarize" all the routes exported by the Spoke 390 VRFs. For example, one or more Hub VRFs may export a default 391 route. In the Hub VRFs, each of these summary routes will have 392 one of the VRF interfaces as its next hop interface. 394 - When such a summary route is exported as a VPN-IP route, it MUST 395 be advertised with a label for which the Next Hop Label 396 Forwarding Entry (see section 3.10 of [RFC3031]) specifies on of 397 the VRF interfaces as the next hop interface. 399 In this scenario, if a PE receives traffic from a spoke site, and the 400 IP destination address of that traffic is a system in another spoke 401 site, the traffic will be tunneled to a PE that attaches to a hub, 402 and then sent over one of the Hub VRF's "VRF interfaces", i.e., sent 403 to a Hub CE router. The Hub PE, when it receives the tunneled 404 packet, does not look up the packet's IP destination address in the 405 Hub VRF, but rather forwards based on the MPLS label. If the Hub CE 406 decides (possibly after inspecting the packet and authorizing the 407 transmission) to "turn the packet around", sending it back to the PE, 408 the PE will look up the IP destination address in the Hub VRF, find 409 that it matches one of the routes imported from a spoke VRF, and 410 tunnel the packet to the PE attaches to the corresponding spoke site. 412 Note that setting up a hub and spoke VPN is just a matter of proper 413 configuration. There are no protocol differences between a Hub and 414 Spoke VPN and any other kind of RFC 4364 VPN. 416 5.2. Multicast Hub and Spoke VPNs 418 Sometimes it is necessary to support multicast service over a Hub and 419 Spoke VPN. In this scenario, it is generally desired to provide an 420 MVPN service with the following properties: 422 - A receiver at a hub site may receive multicast traffic from a 423 transmitter at a spoke site (including the case where the RP is 424 at a spoke site) 426 - A receiver at a spoke site may receive multicast traffic from a 427 transmitter at a hub site (including the case where the RP is at 428 a hub site) 430 - A receiver at a spoke site must not be allowed to join a shared 431 tree (i.e., a (C-*,C-G) tree whose root (i.e., the RP) is at a 432 different spoke site. 434 - A receiver at a spoke site must not be allowed to receive 435 multicast traffic from a transmitter at a different spoke site, 436 except possibly in the case where the traffic traverses a hub 437 site on its path from one spoke site to the other. 439 This type of MVPN service can be provided by using a variation of the 440 "PIM over MS-PMSI" model described in [MVPN_MSPMSI]. In this model, 441 each PE advertises an MS-PMSI for each VRF. If these advertisements 442 are made using BGP S-PMSI A-D routes, the A-D route originating at a 443 Hub VRF carries the "Hub_Route" RT; an A-D route originating at a 444 spoke VRF carries the "Spoke_Route" RT. That is, the S-PMSI A-D 445 routes originating at a given VRF carry the same RT as the unicast 446 routes originating at that VRF. 448 To support Hub and Spoke functionality, the MS-PMSIs originating at 449 the spoke VRFs may all specify the same P-tunnel identifier. 450 Similarly, the MS-PMSIs originating at the hub VRFs may all specify 451 the same P-tunnel identifier, but this must be a different P-tunnel 452 identifier than the one specified for the MS-PMSIs originating from 453 the spoke VRFs. In this case, it is convenient to speak of the Hub 454 and Spoke infrastructure as consisting of two MS-PMSIs, a 455 "spoke-rooted" MS-PMSI and a "hub-rooted" MS-PMSI. 457 As discussed in [MVPN_MSPMSI], it is possible to instantiate an 458 MS-PMSI as a set of PIM-SM trees. This means of instantiation can be 459 useful in Hub and Spoke scenarios when GRE/PIM tunneling is used. In 460 this case, for a given VPN, there MAY be a single sparse mode group 461 address associated with the MS-PMSIs rooted at the spoke VRFs, and a 462 second sparse mode group address associated with the MS-PMSIs rooted 463 at the hub VRFs. The result is the creation of two distinct sets of 464 P-tunnels for the VPN, one set used to carry data traffic fromspoke 465 sites to hub sites (and PIM control traffic in the opposite 466 direction), and the other set used to carry data traffic from hub 467 sites to spoke sites (and PIM control traffic in the opposite 468 direction). 470 Suppose that a spoke VRF and a hub VRF are on the same PE, and that 471 an MS-PMSI advertisement exported by one of those VRFs is imported by 472 the other. The PE implementation MUST support a local function 473 whereby the importing VRF can "join" the MS-PMSI exported by the 474 other VRF, and MUST support a local function whereby packets 475 transmitted from one VRF onto the MS-PMSI are received by the other 476 VRF (if and only if the latter VRF has joined the MS-PMSI exported by 477 the former). 479 Since spoke VRFs do not import each others' S-PMSI A-D routes, and do 480 not import each other's unicast routes, and since there is no 481 MI-PMSI, there is no way for a C-Join to be transmitted directly from 482 one spoke VRF to another. If a CE at a spoke site sends a Join(S,G) 483 to its PE, the PE will forward it on the hub-rooted MS-PMSI 484 advertised by the hub site that is the BGP next hop for S; no spoke 485 VRF can receive PIM control packets on that MS-PMSI. 487 In this scheme, each hub VRF joins two MS-PMSIs, the one spoke-rooted 488 MS-PMSI and the hub-rooted MS-PMSI. Normal PIM procedures would see 489 these as two PIM interfaces. If a hub VRF at PE1 receives a 490 Join(S,G) from the hub-rooted MS-PMSI, where S is at a spoke site, 491 normal PIM/MVPN procedures would cause PE1 to send a Join(S,G) over 492 the spoke-rooted PMSI towards a PE that attaches to S's site. If 493 these procedures are followed, a receiver at a spoke site could get 494 multicast data from a different spoke site; the data would get 495 "turned around" at a PE that attaches to a hub site. Since this 496 violates the requirements as stated above, a PE providing Hub and 497 Spoke MVPN service MUST NOT send a Join message on one MS-PMSI as a 498 result of having received a Join message over another. 500 Note that this does not completely prevent a receiver in a spoke site 501 from being able to receive multicast data from a transmitter in a 502 different spoke site. This can happen in the following situation: 504 - A receiver R1 at a hub site, Site1, joins a (C-*,C-G) tree, 506 - The RP for (C-*,C-G) is at a different hub site, Site2, 508 - A system S1 at a spoke site, Site3, transmits multicast traffic 509 to group C-G. 511 In this situation, the PE attached to Site 2 may need to turn the 512 (S1,G) data around and transmit it on the hub-rooted PMSI, so that R1 513 can receive it. This also allows spoke sites to receive it. 514 However, turnaround at a PE is never a desirable traffic pattern, and 515 implementations are NOT required to support it. An alternative 516 procedure which enables R1 to receive the (S1,G) traffic is for the 517 PE at Site3 to generate a BGP Source Active A-D route, carrying the 518 "spoke route" RT, when it receives a Join(S1,G) on the spoke-rooted 519 MS-PMSI. This route would be withdrawn when the PE no longer has the 520 corresponding (S1,G) state. The PE attached to Site1 will see this 521 SA route, and if it has (*,G) state, will then generate (S1,G) state 522 and expect to receive (S1,G) traffic from the spoke-rooted MS-PMSI. 524 Another situation in which a receiver in a spoke site may be able to 525 receive multicast data from a transmitter in a different spoke site 526 is the following: 528 - A receiver R1 at a spoke site, Site1, joins a (C-*,C-G) tree, 530 - The RP for (C-*,C-G) is at a hub site 532 - A system S2 at a different spoke site, Site2, transmits multicast 533 traffic to group C-G, 535 - The hub site containing the RP is multiply connected to the SP 536 backbone, 538 - The best path from R1 to the RP enters the RP's hub site via a 539 particular PE-CE link, link1, 541 - The best path from S2 to the RP enters the RP's hub site via a 542 different PE-CE link, link2. 544 In this case, it is possible for multicast data traffic to travel 545 from S2 to link1 to the RP to link2 to R1. In some situations, a SP 546 and its customer may wish to explicitly set up this scenario in order 547 to allow spoke sites to receive selected multicast traffic from other 548 spoke sites. 550 The procedures described in this section are compatible with the 551 procedures of section 4. 553 6. IANA Considerations 555 This document does not specify any actions for IANA. 557 7. Security Considerations 559 There are no additional security considerations beyond those of 560 [MVPN] and [MVPN-BGP]. 562 8. Acknowledgments 564 The authors wish to thank DP Ayyadevara, Rayen Mohanty, Maria 565 Napierala, and Karthik Subramanian. 567 9. Authors' Addresses 569 Yiqun Cai 570 Cisco Systems, Inc. 571 170 Tasman Drive 572 San Jose, CA, 95134 573 E-mail: ycai@cisco.com 575 Eric C. Rosen 576 Cisco Systems, Inc. 577 1414 Massachusetts Avenue 578 Boxborough, MA, 01719 579 E-mail: erosen@cisco.com 580 Rajesh Sharma 581 Cisco Systems, Inc. 582 170 Tasman Drive 583 San Jose, CA, 95134 584 E-mail: rajshr@cisco.com 586 IJsbrand Wijnands 587 Cisco Systems, Inc. 588 De kleetlaan 6a Diegem 1831 589 Belgium 590 E-mail: ice@cisco.com 592 10. Normative References 594 [MVPN_MSPMSI] "MVPN: Optimized Use of PIM via MS-PMSIs", Cai, Rosen, 595 Wijnands, draft-rosen-l3vpn-mvpn-mspmsi-10.txt, February 2012 597 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., 598 draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 600 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP 601 IP VPNs", Rahul Aggarwal, Eric Rosen, Thomas Morin, Yakhov Rekhter, 602 draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, September 2009 604 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): 605 Protocol Specification (Revised)", Fenner, Handley, Holbrook, 606 Kouvelas, RFC 4601, August 2006 608 [RFC2119] "Key words for use in RFCs to Indicate Requirement 609 Levels.", Bradner, March 1997 611 [RFC3031] "MPLS Architecture", Rosen, Viswanathan, Callon, January 612 2001 614 [RFC4364] "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 2006