idnits 2.17.1 draft-rosen-l3vpn-mvpn-bidir-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2010) is 4937 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 (-05) exists of draft-rosen-l3vpn-mvpn-wildcards-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 IJsbrand Wijnands 5 Expires: April 19, 2011 Cisco Systems, Inc. 7 Arjen Boers 9 October 19, 2010 11 MVPN: Using Bidirectional P-Tunnels 13 draft-rosen-l3vpn-mvpn-bidir-02.txt 15 Abstract 17 The documents specifying multicast support for BGP/MPLS IP VPNs allow 18 customer multicast data to be transported through a service 19 provider's network through a set multicast tunnels. Such tunnels are 20 advertised by BGP in a BGP attribute known as the "Provider Multicast 21 Service Interface (PMSI) Tunnel Attribute". The base specifications 22 allow the PMSI Tunnel Attribute to advertise bidirectional multicast 23 distribution trees as "PMSI Tunnels"; however, those documents do not 24 provide all the necessary details for using those tunnels. These 25 details are provided in this document. This document also specifies 26 the procedures for assigning customer multicast flows to specific 27 bidirectional PMSI tunnels. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as 37 Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 Copyright and License Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1 Specification of requirements ......................... 3 68 2 Introduction .......................................... 4 69 3 Advertising Bidirectional P-tunnels ................... 5 70 3.1 BIDIR-PIM P-Tunnels ................................... 5 71 3.2 MP2MP LSPs ............................................ 6 72 3.2.1 Partial Mesh of MP2MP LSPs ............................ 6 73 3.2.2 Single MP2MP LSP without PE Distinguisher Labels ...... 7 74 3.2.3 Single MP2MP LSP with PE Distinguisher Labels ......... 8 75 3.2.4 Identifying a MP2MP LSP ............................... 8 76 4 Associating Received Packets with VRFs ................ 9 77 5 Data Transmission and Reception ....................... 9 78 5.1 Partial Mesh of MP2MP LSPs ............................ 9 79 5.1.1 Binding (C-S,C-G) to Bidirectional P-tunnels .......... 9 80 5.1.2 Binding (C-*,C-G) Flows from Unidirectional C-trees ... 10 81 5.1.3 Binding (C-*,C-G) Flows from Bidirectional C-trees .... 10 82 5.1.4 Binding (C-*,C-*) ..................................... 11 83 5.2 Single MP2MP LSP With PE Distinguisher Labels ......... 12 84 5.3 Single MP2MP LSP Without PE Distinguisher Labels ...... 13 85 5.4 BIDIR-PIM P-Tunnel .................................... 13 86 5.4.1 Single BIDIR-PIM P-Tunnel ............................. 13 87 5.4.2 Partial Mesh of BIDIR-PIM P-Tunnels ................... 14 88 6 IANA Considerations ................................... 14 89 7 Security Considerations ............................... 14 90 8 Acknowledgments ....................................... 14 91 9 Authors' Addresses .................................... 14 92 10 Normative References .................................. 15 93 11 Informative References ................................ 16 95 1. Specification of requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Introduction 103 The base documents for MVPN, [MVPN] and [MVPN-BGP], define a "PMSI 104 Tunnel Attribute" (PTA) that may be carried in the BGP "I-PMSI A-D 105 routes" and BGP "S-PMSI A-D routes" that are defined therein. The 106 base documents define the way that bidirectional P-tunnels are 107 identified in the PTA, and the way in which the identifier of a 108 bidirectional P-tunnel is encoded in the PTA. 110 However, those documents do not contain the full set of 111 specifications governing the use of the PTA to advertise 112 bidirectional P-Tunnels. These specifications are provided in this 113 document. 115 This document also specifies the procedures for assigning customer 116 multicast flows to specific bidirectional PMSI tunnels. 118 Two kinds of bidirectional P-tunnel are discussed in this document: 120 - Multicast distribution trees that are created through the use of 121 BIDIR-PIM [BIDIR-PIM]. 123 - Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs), 124 created by Label Distribution Protocol (LDP) Multipoint-to- 125 Multipoint extensions [mLDP]. 127 This document also specifies three methods of using MP2MP LSPs as 128 P-tunnels: 130 - Partial mesh of MP2MP LSPs. In this method, when a set of PEs 131 have multicast data to send and/or receive to/from each other, 132 each PE becomes the root of a MP2MP LSP. This method is 133 presented in [MVPN], section 11.2.3. The detailed specification 134 is provided in this document. 136 - Single MP2MP LSP with PE Distinguisher Labels. This method is 137 presented in [MVPN], section 11.2.2. The detailed specification 138 is provided in this document. 140 - Single MP2MP LSP without PE Distinguisher Labels. 142 In the following, we will sometimes speak of an S-PMSI A-D route 143 being "ignored". When we say the route is "ignored", we do not mean 144 that it's normal BGP processing is not done, but that the route is 145 not considered when determining which P-tunnel to use when sending 146 multicast data, and that the MPLS label values it conveys are not 147 used. We will generally use "ignore" in quotes to indicate this 148 meaning. 150 3. Advertising Bidirectional P-tunnels 152 In this specification, we consider the use of bidirectional P-tunnels 153 as advertised in the PTA of a BGP S-PMSI A-D route. 155 3.1. BIDIR-PIM P-Tunnels 157 A BIDIR-PIM P-tunnel may be advertised in the PTA of an Intra-AS 158 I-PMSI A-D route or in the PTA of an S-PMSI A-D route. 160 As is the case with other PIM-created P-tunnels, to transmit packets 161 on a BIDIR-PIM P-tunnel, one uses the GRE encapsulation as specified 162 in [MVPN] section 12. 164 Each BIDIR-PIM P-Tunnel is identified by a unique P-group address 165 [MVPN, section 3.1]. (The P-group address is called a "P-Multicast 166 Group" in [MVPN-BGP]). A BIDIR-PIM P-group address is always 167 associated with a unique "Rendezvous Point Address" (RPA). 169 Every PE that needs to join a particular BIDIR-PIM P-tunnel must be 170 able to determine the RPA that corresponds to the P-tunnel's P-group 171 address. PIM Join/Prune messages are sent along the path from the PE 172 to the RPA. Any P routers along that path must also be able to 173 determine the RPA, so that they too can send PIM Join/Prune messages 174 towards the RPA. The method of mapping a P-group address to an RPA 175 may be static configuration, or some automated means of RPA discovery 176 that is outside the scope of this specification. 178 If a BIDIR-PIM P-tunnel is to be used, it is RECOMMENDED that the 179 path from each PE in the tunnel to the RPA consist entirely of 180 point-to-point links. On a point-to-point link, there is no 181 ambiguity in determining which router is upstream towards a 182 particular RPA, so the BIDIR-PIM "Designated Forwarder Election" is 183 very quick and simple. Use of a BIDIR-PIM P-tunnel containing 184 multiaccess links is possible, but considerably more complex. 186 When a BGP A-D route's PTA specifies a BIDIR-PIM P-tunnel, the PE 187 Distinguisher Labels attribute SHOULD NOT be included; if it is 188 included, it MUST be ignored. The PE Distinguisher Labels attribute 189 is not needed because the "distinguished PE" for a particular packet 190 can be identified by placing its IP address in the IP source address 191 field of the GRE encapsulation used to send that packet on the 192 P-tunnel. 194 There are two different methods of using BIDIR-PIM P-Tunnels, the 195 "Single BIDIR-PIM P-Tunnel method", and the "Partial Mesh of 196 BIDIR-PIM P-Tunnels method". The choice of method is determined by 197 provisioning. 199 If the "Single BIDIR-PIM P-Tunnel" method is being used, all PEs in a 200 given MVPN MUST identify the same P-tunnel. The identity of this 201 P-tunnel is known by provisioning. For example, by using this 202 method, and identifying the tunnel in the PTA of the Intra-AS I-PMSI 203 A-D routes, one may use a BIDIR-PIM P-tunnel to instantiate an MI- 204 PMSI. 206 If the Partial Mesh of BIDIR-PIM P-Tunnels method is being used, the 207 PEs MUST identify different P-Tunnels (by advertising different P- 208 group addresses in their PTAs). If a particular P-group address is 209 advertised by a particular PE, then one of that PE's addresses MUST 210 be the RPA corresponding to that P-group. 212 For example, by using this method, and identifying the tunnel in the 213 PTA of an S-PMSI A-D route, one may implement the "Partitioned Sets 214 of PEs" method of supporting C-BIDIR, as discussed in section 11.2 of 215 [MVPN] and section 3.6 of [CONSID]. 217 3.2. MP2MP LSPs 219 An MP2MP LSP is identified by an "MP2MP FEC element" [mLDP]. The FEC 220 element contains the IP address of the "root", followed by an "opaque 221 value" that identifies the MP2MP LSP uniquely in the context of the 222 root's IP address. This opaque value may be configured or 223 autogenerated, and within an MVPN, there is no need for different 224 roots to use the same opaque value. 226 The method of using MP2MP LSPs (partial mesh, single with PE 227 Distinguisher Labels, single without PE Distinguisher Labels) is 228 determined by provisioning. It SHOULD be possible to configure this 229 on a per-MVPN basis. 231 3.2.1. Partial Mesh of MP2MP LSPs 233 A partial mesh of MP2MP LSPs is not useful for instantiating an 234 I-PMSI. The LSPs of the partial mesh are therefore only advertised 235 in the PTAs of S-PMSI A-D routes. 237 A partial mesh of MP2MP LSPs is useful for implementing the 238 "Partitioned Sets of PEs" method of supporting C-BIDIR, as discussed 239 in section 11.2 of [MVPN] and section 3.6 of [CONSID]. 241 Section 5.1 of this document specifies the procedures for 242 transmitting all kinds of customer data flows, whether unidirectional 243 or bidirectional, on a partial mesh of MP2MP LSPs. The sending and 244 receiving of PE-PE PIM control packets on a partial mesh of MP2MP 245 LSPs is outside the scope of this specification. 247 When this method is being used: 249 - Each PE that is participating in the mesh MUST advertise, in the 250 PTA of an S-PMSI A-D route, a MP2MP LSP of which it is the root. 251 (The LSP root address is part of the P-tunnel identifier field 252 carried in the PTA.) A PE MUST "participate in the mesh" if any 253 of the following conditions holds: 255 * The "Partitioned Sets of PEs" method of supporting C-BIDIR 256 traffic is being used, and the PE's route to the Rendezvous 257 Point Address (RPA) for one or more C-BIDIR groups is via a 258 VRF interface. 260 * The "Partitioned Sets of PEs" method is being used, it is 261 desired to transmit some or all of the customer 262 unidirectional multicast traffic (for the given MVPN) on the 263 same LSPs used for carrying C-BIDIR traffic, and the PE has 264 customer multicast traffic to transmit to other PEs. 266 There may be other conditions under which a PE needs to 267 participate in a partial mesh of MP2MP LSPs; these are outside 268 the scope of the current specification. 270 - The PE Distinguisher Labels Attribute [MVPN-BGP] MUST NOT be 271 included; if included, it MUST be ignored. 273 3.2.2. Single MP2MP LSP without PE Distinguisher Labels 275 When this method is being used: 277 - the MP2MP LSP can be advertised in the PTA of an Intra-AS I-PMSI 278 A-D route, or in the PTA of an S-PMSI A-D route. When advertised 279 in the PTA of an Intra-AS I-PMSI A-D route, the MP2MP LSP can be 280 used to instantiate an MI-PMSI. 282 - The LSP does not have to be advertised by its root. In fact, the 283 root of the LSP does not even need to be a PE router. 285 - The PE Distinguisher Labels Attribute MUST NOT be included, but 286 if included, it MUST be ignored. 288 - If two or more PEs of the same MVPN advertise a MP2MP LSP in 289 their Intra-AS I-PMSI A-D routes, they SHOULD advertise the same 290 MP2MP LSP. Any scenario in which they do not advertise the same 291 MP2MP LSP in their Intra-0I A-D routes is outside the scope of 292 this document. 294 This method cannot be used to support the "Partitioned Set of PEs" 295 method discussed in [MVPN] section 11.2 and [CONSID] section 3.6. 296 Also, this method is not compatible with the procedures of [MVPN] 297 section 9.1.1. 299 3.2.3. Single MP2MP LSP with PE Distinguisher Labels 301 In this method, the MP2MP LSP MUST be advertised in the PTA of an 302 Intra-AS I-PMSI A-D route or an S-PMSI A-D route originated by the 303 root of the LSP. That route MUST include a "PE Distinguisher Labels" 304 Attribute. Violation of these conditions MUST cause the route to be 305 ignored. 307 The PE at the root of the LSP SHOULD use the PE Distinguisher Labels 308 Attribute to bind an upstream-assigned MPLS label to the IP address 309 of some or all of the other PEs that attach to the same MVPN (as 310 determined by the RTs of the A-D route). That is, the PE at the root 311 of the P-tunnel assigns a distinct label to some or all of the other 312 PEs attaching to the same MVPN. 314 An MP2MP LSP with PE Distinguisher Labels can be used to instantiate 315 an MI-PMSI. In this case, the PE at the root MUST use the PE 316 Distinguisher Labels Attribute to bind an upstream-assigned MPLS 317 label to the IP address of each other PE that attaches to the same 318 MVPN. This set of PEs is learned via the reception of Intra-AS 319 I-PMSI A-D routes. 321 An MP2MP LSP with PE Distinguisher Labels can also be used to support 322 the "Partitioned Set of PEs" method discussed in [MVPN] section 11.2 323 and [CONSID] section 3.6. In this case, it is not necessary to bind 324 an upstream-assigned label to the IP address of a particular PE in 325 the MVPN unless that PE has advertised a unicast VPN-IP route to one 326 of the C-RPAs of that MVPN. 328 3.2.4. Identifying a MP2MP LSP 330 To identify a MP2MP LSP, the PTA of a BGP A-D route contains an MP2MP 331 FEC Element [mLDP] in its "Tunnel Identifier" field. This contains 332 the IP address of the root of the LSP, as well as an "Opaque Value" 333 which is unique at the root. The mLDP specification supports the use 334 of several different ways of constructing the tunnel identifiers. 335 This specification does not place any restrictions on the types of 336 tunnel identifier that might be used. However, a given 337 implementation might not support every possible type of tunnel 338 identifier. Future revisions of this specification will establish 339 one or two types of tunnel identifier as being "mandatory to 340 support". 342 4. Associating Received Packets with VRFs 344 When a packet is received from a bidirectional P-tunnel, the packet 345 is first associated one or more VRFs, and then processed in the 346 context of that VRF or VRFs. If the bidirectional P-tunnel was 347 advertised in the PTA of an A-D route that did not specify an MPLS 348 label, then all packets received from the P-tunnel are associated 349 with the same set of VRFs. If the bidirectional P-tunnel was 350 advertised in the PTA of an A-D route, and the PTA does specify an 351 MPLS label, then received packets will carry a label that must be 352 processed in order to determine the context. If the P-tunnel is a 353 MP2MP LSP, this label appears below the label that identifies the LSP 354 itself. 356 5. Data Transmission and Reception 358 5.1. Partial Mesh of MP2MP LSPs 360 5.1.1. Binding (C-S,C-G) to Bidirectional P-tunnels 362 When PE1 advertises an S-PMSI A-D route that binds a (C-S,C-G) flow 363 to a bidirectional P-tunnel, or when PE1 sends an S-PMSI Join message 364 that binds a (C-S,C-G) flow to a bidirectional P-tunnel, the 365 semantics are as follows. PE1 is stating that any (C-S,C-G) traffic 366 that it needs to transmit to other PEs will be transmitted on the 367 specified P-tunnel. Any other PE that needs to receive such traffic 368 from PE1 (i.e., any other PE that needs to receive (C-S,C-G) traffic 369 and which has selected PE1 as the upstream PE for C-S) MUST join that 370 P-tunnel. 372 If a PE has joined the P-tunnel, but does not need to receive the 373 (C-S,C-G) traffic, or if it needs to receive (C-S,C-G) traffic but 374 has not selected PE1 as the upstream PE for C-S, then the PE MUST 375 discard any such received traffic. 377 5.1.2. Binding (C-*,C-G) Flows from Unidirectional C-trees 379 When PE1 advertises an S-PMSI A-D route or sends an S-PMSI Join 380 message that binds (C-*,C-G) [MVPN-WILD] to a bidirectional P-tunnel, 381 where C-G is not a "Source-Specific Multicast" (SSM) group, and the 382 (C-*,C-G) traffic is traveling on a unidirectional shared C-tree, the 383 semantics are as follows. PE1 is stating that any traffic to C-G 384 that is traveling the shared C-tree and which PE1 needs to transmit 385 to other PEs will be transmitted on the specified P-tunnel. 387 Any other PE that needs to receive such traffic from PE1 (i.e., any 388 other PE that needs to receive (C-*,C-G) traffic and which has 389 selected PE1 as the upstream PE for the C-RP corresponding to the C-G 390 group) MUST join that P-tunnel. 392 If a PE has joined the P-tunnel, but does not need to receive the 393 (C-*,C-G) traffic, or if it needs to receive (C-*,C-G) traffic but 394 has not selected PE1 as the upstream PE for the C-RP that corresponds 395 to C-G, then the PE MUST discard any such received traffic. 397 5.1.3. Binding (C-*,C-G) Flows from Bidirectional C-trees 399 When PE1 advertises an S-PMSI A-D route or sends an S-PMSI Join 400 message that binds (C-*,C-G) to a bidirectional P-tunnel, where C-G 401 is not an SSM group, and the (C-*,C-G) traffic is traveling on a 402 bidirectional shared C-tree, the semantics are as follows: 404 - PE1 is stating that any traffic to C-G that it (PE1) needs to 405 send downstream will be sent on the specified P-tunnel 407 - Any other PE that is interested in receiving (C-*,C-G) traffic 408 MUST join the specified P-tunnel 410 - Any other PE, say PE2, that (a) has traffic to C-G to send 411 upstream and (b) has selected PE1 as its upstream PE for the 412 C-RPA corresponding to C-G, MUST join the specified P-tunnel, and 413 MUST send such traffic on the specified P-tunnel. 415 - If a PE, say PE3, has joined the specified P-tunnel, but does not 416 need to receive the (C-*,C-G) traffic, or has not selected PE1 as 417 the upstream PE for the C-RPA corresponding to C-G, then PE3 MUST 418 NOT send any (C-*,C-G) traffic on that P-tunnel, and MUST discard 419 any (C-*,C-G) traffic it received on that P-tunnel. 421 These procedures implement the "Partitioned Set of PEs" scheme 422 described in section 11.2 of [MVPN]. 424 The specification given so far requires an S-PMSI A-D route or an 425 S-PMSI Join message to be sent for each (C-*,C-G) that is using a 426 bidirectional C-tree. A more efficient method is given in the next 427 section. 429 5.1.4. Binding (C-*,C-*) 431 When PE1 advertises an S-PMSI A-D route or sends an S-PMSI Join 432 message that binds (C-*,C-*) to a specified bidirectional P-tunnel of 433 which PE1 is the root, the semantics are as that the bidirectional 434 P-tunnel is to be used to carry C-multicast traffic in the following 435 sets of cases: 437 1. If PE1 has (C-S,C-G) traffic that is traveling on a 438 source-specific C-tree, and PE1 needs to transmit that data to 439 one or more other PEs, and PE1 has not bound (C-S,C-G) or 440 (C-*,C-G) to a different P-tunnel, then the (C-S,C-G) traffic 441 is sent by PE1 on the specified bidirectional P-tunnel. 443 2. If PE1 has (C-*,C-G) traffic that is traveling on a 444 unidirectional shared C-tree, and PE1 needs to transmit that 445 data to one or more other PEs, and PE1 has not bound (C-*,C-G) 446 to a different P-tunnel, then the (C-*,C-G) traffic is sent by 447 PE1 on the specified bidirectional P-tunnel. 449 3. If PE1 has (C-*,C-G) traffic that is traveling on a 450 bidirectional shared C-tree, and PE1 needs to transmit that 451 data to one or more other PEs, and PE1 has not bound (C-*,C-G) 452 to a different P-tunnel, then the (C-*,C-G) traffic is sent by 453 PE1 on the specified bidirectional P-tunnel. 455 4. Consider some other PE, PE2, that has received the S-PMSI A-D 456 route or S-PMSI Join message from PE1. If PE2 has (C-*,C-G) 457 traffic that is traveling on a bidirectional shared C-tree, and 458 PE2 needs to transmit that traffic UPSTREAM, and PE2 has 459 selected PE1 as the upstream PE for the C-RPA corresponding to 460 C-G, and PE1 has not bound (C-*,C-G) to any other P-tunnel, 461 then the (C-*,C-G) traffic is sent by by PE2 on the specified 462 bidirectional P-tunnel. 464 5. If a PE receives traffic from a particular bidirectional 465 P-tunnel, and the traffic is traveling a unidirectional 466 (C-*,C-G) or (C-S,C-G) tree, and the root of the bidirectional 467 P-tunnel is not the PE's selected upstream PE for the (C-*,C-G) 468 or (C-S,C-G), the PE MUST discard the traffic. 470 6. If a PE receives traffic from a particular bidirectional 471 P-tunnel, and the traffic is traveling a bidirectional 472 (C-*,C-G) tree, and the PE's selected upstream PE for the C-RPA 473 corresponding to C-G is not the root of the bidirectional 474 P-tunnel, then the PE MUST discard the traffic. 476 With respect to traffic traveling a bidirectional C-tree, these 477 procedures implement, for S-PMSIs, the "partitioning" scheme 478 described in section 11.2 of [MVPN], without the need to send an 479 S-PMSI A-D route for each (C-*,C-G) that is using a bidirectional 480 C-tree. Each PE becomes the root of a bidirectional P-tunnel, and 481 binds the double wildcard selector to it. The bidirectional 482 P-tunnels serve as the "partitions". The bidirectional P-tunnel 483 rooted at PE1 becomes the default P-tunnel for all traffic that PE1 484 needs to send downstream to other PEs. It also becomes the default 485 P-tunnel for all traffic that others PEs need to send upstream, as 486 long as those other PEs have selected PE1 as the upstream PE for the 487 C-RPA corresponding to that traffic. 489 Note that other PEs SHOULD NOT join the specified bidirectional 490 P-tunnel unless they have a need to send or receive data over it. A 491 PE knows when it needs to receive data by virtue of having certain 492 multicast state in its C-PIM instance. With regard to multicast data 493 traveling on a bidirectional (C-*,C-G) tree, a PE may not know 494 whether it has to send data until such data actually arrives over a 495 VRF interface; the PE may be on a "sender-only" branch. However, the 496 PE in this case would have to know, through provisioning or some 497 automatic procedure such as "Bootstrap Routing Protocol for PIM" 498 (BSR) [BSR], the set of C-RPAs that are being used to support 499 (C-*,C-G) traffic. For each C-RPA, the PE could join the 500 bidirectional P-tunnel advertised by its selected upstream PE for 501 that C-RPA. Alternatively the PE could defer joining the P-tunnel 502 until it actually has data to send. 504 5.2. Single MP2MP LSP With PE Distinguisher Labels 506 The procedures for transmitting data on a single MP2MP LSP with PE 507 Distinguisher Labels differ from the procedures for transmitting data 508 on a partial mesh of MP2MP LSPs only in the following way. Let PE1 509 be the root of the P-tunnel. When a packet that is traveling on a 510 unidirectional C-tree is transmitted on the P-tunnel by a particular 511 PE, say PE2, PE2 must push on the packet's label stack the label that 512 PE1 assigned to PE2 via the procedure above. When a packet that is 513 traveling on a bidirectional C-tree is transmitted on the P-tunnel by 514 PE2, PE2 must push on the packet's label stack the label that PE1 515 assigned to PE3, where PE3 is the upstream PE that PE2 has selected 516 for the C-RPA corresponding to C-G. 518 For unidirectional flows, this allows the transmitter to be 519 identified, and for bidirectional flows, this allows the partition to 520 be identified. Packets received from the wrong upstream PE or from 521 the wrong partition MUST be discarded. (In effect, this is a case of 522 tunnel hierarchy, where the PE Distinguisher Labels represent a set 523 of MP2MP LSPs that are being tunneled through a single bidirectional 524 P-tunnel.) 526 If the PTA identifying the bidirectional P-tunnel contains an MPLS 527 label, then that label shall appear in the label stack immediately 528 preceding the label specified in the PE Distinguisher Labels 529 attribute. 531 5.3. Single MP2MP LSP Without PE Distinguisher Labels 533 No special rules are needed for this case; the general procedures 534 specified in [MVPN] and [MVPN-BGP] are used. 536 5.4. BIDIR-PIM P-Tunnel 538 Packets are transmitted using GRE encapsulation as described in 539 sections 12.1.1 and 12.2.1 of [MVPN]. 541 It is possible to implement the "Partitioned Sets of PEs" scheme 542 ([MVPN] section 11.2 and [CONSID] section 3.6) using either a single 543 BIDIR-PIM P-Tunnel or using a partial mesh of BIDIR-PIM P-Tunnels. 545 5.4.1. Single BIDIR-PIM P-Tunnel 547 In this method, the rules for transmitting packets of a given C-flow 548 on a BIDIR-PIM P-Tunnel are essentially the same as the rules given 549 in section 5.2, except that a particular "distinguished PE" is 550 identified not by the use of a PE Distinguisher Label, but by the use 551 of the IP Source Address field of the GRE header. For unidirectional 552 C-flows, the IP source address field of the GRE header identifies the 553 PE that transmitted the packet onto the P-tunnel. For bidirectional 554 C-flows, suppose that PE1 is transmitting a packet over the P-tunnel, 555 that the packet's C-group address is C-G, and that PE1 has selected 556 PE2 as the upstream PE corresponding to the C-RPA that corresponds to 557 C-G. Then when PE1 transmits the packet over the P-tunnel, the IP 558 source address field of the GRE header will contain the IP address of 559 PE2. 561 5.4.2. Partial Mesh of BIDIR-PIM P-Tunnels 563 In this method, the rules for for transmitting packets of a given 564 C-flow on a BIDIR-PIM P-Tunnel are essentially the same as the rules 565 given in section 5.1. 567 6. IANA Considerations 569 Both [MVPN] and [MVPN-BGP] discuss the use of the "PE Distinguisher 570 Labels" Attribute, but neither document has asked IANA to define a 571 codepoint for it. We now ask IANA to assign a codepoint for this 572 attribute, as an optional transitive attribute, referencing [MVPN], 573 [MVPN-BGP], and this document. 575 7. Security Considerations 577 There are no additional security considerations beyond those of 578 [MVPN] and [MVPN-BGP]. 580 8. Acknowledgments 582 The authors wish to thank Karthik Subramanian, Rajesh Sharma, and 583 Apoorva Karan for their input. We also thank Yakov Rekhter for his 584 valuable critique. 586 9. Authors' Addresses 588 Arjen Boers 589 E-mail: arjen@boers.com 591 Yiqun Cai 592 Cisco Systems, Inc. 593 170 Tasman Drive 594 San Jose, CA, 95134 595 E-mail: ycai@cisco.com 596 Eric C. Rosen 597 Cisco Systems, Inc. 598 1414 Massachusetts Avenue 599 Boxborough, MA, 01719 600 E-mail: erosen@cisco.com 602 IJsbrand Wijnands 603 Cisco Systems, Inc. 604 De kleetlaan 6a Diegem 1831 605 Belgium 606 E-mail: ice@cisco.com 608 10. Normative References 610 [BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley, 611 Kouvelas, Speakman, Vicisano, RFC 5015, October 2007 613 [mLDP] "Label Distribution Protocol Extensions for 614 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 615 Paths", Minei, Kompella, Wijnands, Thomas, 616 draft-ietf-mpls-ldp-p2mp-11.txt, October 2010 618 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., 619 draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 621 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 622 VPNs", Aggarwal, Rosen, Morin, Rekhter, 623 draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, September 2009 625 [MVPN-WILD] "MVPN: S-PMSI Wild Card Selectors", Cai, Rosen, Wijnands, 626 draft-rosen-l3vpn-mvpn-wildcards-01.txt, July 2010 628 [RFC2119] "Key words for use in RFCs to Indicate Requirement 629 Levels.", Bradner, March 1997 631 11. Informative References 633 [BSR] "Bootstrap Router (BSR) Mechanism for PIM", N. Bhaskar, et.al., 634 RFC 5059, January 2008 636 [CONSID] "Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN 637 Solution", Morin, Niven-Jenkins, Kamite, Zhang, Leymann, Bitar, 638 draft-ietf-l3vpn-mvpn-considerations-06.txt, February 2010