idnits 2.17.1 draft-ietf-bess-mvpn-bidir-03.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC6513, updated by this document, for RFC5378 checks: 2005-06-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2015) is 3347 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 (Obsoleted by RFC 7761) == Outdated reference: A later version (-19) exists of draft-ietf-idr-error-handling-18 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group E. Rosen 3 Internet-Draft Juniper Networks, Inc. 4 Updates: 6513,6514,6625 (if approved) IJ. Wijnands 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: August 23, 2015 Y. Cai 7 Microsoft 8 A. Boers 10 February 19, 2015 12 MVPN: Using Bidirectional P-Tunnels 13 draft-ietf-bess-mvpn-bidir-03 15 Abstract 17 A set of prior RFCs specify procedures for supporting multicast in 18 BGP/MPLS IP VPNs. These procedures allow customer multicast data to 19 travel across a service provider's backbone network through a set of 20 multicast tunnels. The tunnels are advertised in certain BGP 21 multicast "auto-discovery" routes, by means of a BGP attribute known 22 as the "Provider Multicast Service Interface (PMSI) Tunnel 23 attribute". Encodings have been defined that allow the PMSI Tunnel 24 attribute to identify bidirectional (multipoint-to-multipoint) 25 multicast distribution trees. However, the prior RFCs do not provide 26 all the necessary procedures for using bidirectional tunnels to 27 support multicast VPNs. This document updates RFCs 6513, 6514 and 28 6625 by specifying those procedures. In particular, it specifies the 29 procedures for assigning customer multicast flows (unidirectional or 30 bidirectional) to specific bidirectional tunnels in the provider 31 backbone, for advertising such assignments, and for determining which 32 flows have been assigned to which tunnels. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 23, 2015. 50 Copyright Notice 52 Copyright (c) 2015 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1.2.1. Bidirectional P-tunnel 71 Technologies . . . . . . . . . . . . . . . . . . . . 9 72 1.2.2. Reasons for Using Bidirectional 73 P-tunnels . . . . . . . . . . . . . . . . . . . . . . 9 74 1.2.3. Knowledge of Group-to-RP and/or 75 Group-to-RPA Mappings . . . . . . . . . . . . . . . . 11 76 1.2.4. PMSI Instantiation Methods . . . . . . . . . . . . . 11 77 2. The All BIDIR-PIM Wild Card . . . . . . . . . . . . . . . . . 14 78 3. Using Bidirectional P-Tunnels . . . . . . . . . . . . . . . . 14 79 3.1. Procedures Specific to the 80 Tunneling Technology . . . . . . . . . . . . . . . . . . 14 81 3.1.1. BIDIR-PIM P-Tunnels . . . . . . . . . . . . . . . . . 14 82 3.1.2. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . . 15 83 3.2. Procedures Specific to the PMSI 84 Instantiation Method . . . . . . . . . . . . . . . . . . 16 85 3.2.1. Flat Partitioning . . . . . . . . . . . . . . . . . . 16 86 3.2.1.1. When an S-PMSI is a 'Match for 87 Transmission' . . . . . . . . . . . . . . . . . . 18 88 3.2.1.2. When an I-PMSI is a 'Match for 89 Transmission' . . . . . . . . . . . . . . . . . . 19 90 3.2.1.3. When an S-PMSI is a 'Match for 91 Reception' . . . . . . . . . . . . . . . . . . . 19 92 3.2.1.4. When an I-PMSI is a 'Match for 93 Reception . . . . . . . . . . . . . . . . . . . . 20 94 3.2.2. Hierarchical Partitioning . . . . . . . . . . . . . . 21 95 3.2.2.1. Advertisement of PE 96 Distinguisher Labels . . . . . . . . . . . . . . 23 97 3.2.2.2. When an S-PMSI is a 'Match for 98 Transmission' . . . . . . . . . . . . . . . . . . 24 99 3.2.2.3. When an I-PMSI is a 'Match for 100 Transmission' . . . . . . . . . . . . . . . . . . 24 101 3.2.2.4. When an S-PMSI is a 'Match for 102 Reception' . . . . . . . . . . . . . . . . . . . 25 103 3.2.2.5. When an I-PMSI is a 'Match for 104 Reception' . . . . . . . . . . . . . . . . . . . 26 105 3.2.3. Unpartitioned . . . . . . . . . . . . . . . . . . . . 27 106 3.2.3.1. When an S-PMSI is a 'Match for 107 Transmission' . . . . . . . . . . . . . . . . . . 28 108 3.2.3.2. When an S-PMSI is a 'Match for 109 Reception' . . . . . . . . . . . . . . . . . . . 29 110 3.2.4. Minimal Feature Set for 111 Compliance . . . . . . . . . . . . . . . . . . . . . 30 112 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 113 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 114 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 115 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 116 7.1. Normative References . . . . . . . . . . . . . . . . . . 31 117 7.2. Informative References . . . . . . . . . . . . . . . . . 31 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 120 1. Introduction 122 The RFCs that specify multicast support for BGP/MPLS IP VPNs 123 ([RFC6513], [RFC6514], [RFC6625]) allow customer multicast data to be 124 transported across a service provider's network though a set of 125 multicast tunnels. These tunnels are advertised in BGP multicast 126 "auto-discovery" (A-D) routes, by means of a BGP attribute known as 127 the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. 128 The base specifications allow the use of bidirectional (multipoint- 129 to-multipoint) multicast distribution trees, and describe how to 130 encode the identifiers for bidirectional trees into the PMSI Tunnel 131 attribute. However, those specifications do not provide all the 132 necessary detailed procedures for using bidirectional tunnels; the 133 full specification of these procedures was considered to be outside 134 the scope of those documents. The purpose of this document is to 135 provide all the necessary procedures for using bidirectional trees in 136 a service provider's network to carry the multicast data of VPN 137 customers. 139 1.1. Terminology 141 This document uses terminology from [RFC6513] and, in particular, 142 uses the prefixes "C-" and "P-", as specified in Section 3.1 of 143 [RFC6513], to distinguish addresses in the "customer address space" 144 from addresses in the "provider address space". The following 145 terminology and acronyms are particularly important in this document: 147 o MVPN 149 Multicast Virtual Private Network -- a VPN [RFC4364] in which 150 multicast service is offered. 152 o VRF 154 VPN Routing and Forwarding table [RFC4364]. 156 o PE 158 A Provider Edge router, as defined in [RFC4364]. 160 o SP 162 Service Provider. 164 o LSP 166 An MPLS Label Switched Path. 168 o P2MP 170 Point-to-Multipoint. 172 o MP2MP 174 Multipoint-to-multipoint. 176 o Unidirectional 178 Adjective for a multicast distribution tree in which all traffic 179 travels downstream from the root of the tree. Traffic can enter a 180 unidirectional tree only at the root. A P2MP LSP is one type of 181 unidirectional tree. Multicast distribution trees set up by PIM- 182 SM [RFC4601] are also unidirectional trees. 183 Data traffic traveling along a unidirectional multicast 184 distribution tree is sometimes referred to in this document as 185 "unidirectional traffic". 187 o Bidirectional 189 Adjective for a multicast distribution tree in which traffic may 190 travel both upstream (towards the root) and downstream (away from 191 the root). Traffic may enter a bidirectional tree at any node. A 192 MP2MP LSP is one type of bidirectional tree. Multicast 193 distribution trees created by BIDIR-PIM [RFC5015] are also 194 bidirectional trees. 196 Data traffic traveling along a bidirectional multicast 197 distribution tree is sometimes referred to in this document as 198 "bidirectional traffic". 200 o P-tunnel 202 A tunnel through the network of one or more Service Providers 203 (SPs). In this document, the P-tunnels we speak of are are 204 instantiated as bidirectional multicast distribution trees. 206 o C-S 208 Multicast Source. A multicast source address, in the address 209 space of a customer network. 211 o C-G 213 Multicast Group. A multicast group address (destination address) 214 in the address space of a customer network. When used without 215 qualification, "C-G" may refer to either a unidirectional group 216 address or a bidirectional group address. 218 o C-G-BIDIR 220 A bidirectional multicast group address (i.e., a group address 221 whose IP multicast distribution tree is built by BIDIR-PIM). 223 o C-multicast flow or C-flow 225 A customer multicast flow. A C-flow travels through VPN customer 226 sites on a multicast distribution tree set up by the customer. 227 These trees may be unidirectional or bidirectional, depending upon 228 the multicast routing protocol used by the customer. A C-flow 229 travels between VPN customer sites by traveling through P-tunnels. 231 A C-flow from a particular customer source is identified by the 232 ordered pair (source address, group address), where each address 233 is in the customer's address space. The identifier of such a 234 C-flow is usually written as (C-S,C-G). 236 If a customer uses the "Any Source Multicast" (ASM) model, the 237 some or all of the customer's C-flows may be traveling along the 238 same "shared tree". In this case, we will speak of a "(C-*,C-G)" 239 flow to refer to a set of C-flows that travel along the same 240 shared tree in the customer sites. 242 o C-BIDIR flow or bidirectional C-flow 244 A C-flow that, in the VPN customer sites, travels along a 245 bidirectional multicast distribution tree. The term "C-BIDIR 246 flow" indicates that the customer's bidirectional tree has been 247 set up by BIDIR-PIM. 249 o RP 251 A "Rendezvous Point", as defined in [RFC4601]. 253 o C-RP 255 A Rendezvous Point whose address is in the customer's address 256 space. 258 o RPA 260 A "Rendezvous Point Address", as defined in [RFC5015]. 262 o C-RPA 264 An RPA in the customer's address space. 266 o P-RPA 268 An RPA in the Service Provider's address space 270 o Selective P-tunnel 272 A P-tunnel that is joined only by Provider Edge (PE) routers that 273 need to receive one or more of the C-flows that are traveling 274 through that P-tunnel. 276 o Inclusive P-tunnel 278 A P-tunnel that is joined by all PE routers that attach to sites 279 of a given MVPN. 281 o Intra-AS I-PMSI A-D route 283 Intra Autonomous System Inclusive Provider Multicast Service 284 Interface Auto-Discovery route. Carried in BGP Update messages, 285 these routes can be used to advertise the use of Inclusive 286 P-tunnels. See [RFC6514] section 4.1. 288 o S-PMSI A-D route 290 Selective Provider Multicast Service Interface Auto-Discovery 291 route. Carried in BGP Update messages, these routes are used to 292 advertise the fact that a particular C-flow or a particular set of 293 C-flows is bound to (i.e., is traveling through) a particular 294 P-tunnel. See [RFC6514] section 4.3. 296 o (C-S,C-G) S-PMSI A-D route 298 An S-PMSI A-D route whose NLRI ("Network Layer Reachability 299 Information") contains C-S in its "Multicast Source" field and C-G 300 in its "Multicast Group" field. 302 o (C-*,C-G) S-PMSI A-D route 304 An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its 305 "Multicast Source" field and C-G in its "Multicast Group" field. 306 See [RFC6625]. 308 o (C-*,C-G-BIDIR) S-PMSI A-D route 310 An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its 311 "Multicast Source" field and C-G-BIDIR in its "Multicast Group" 312 field. See [RFC6625]. 314 o (C-*,C-*) S-PMSI A-D route 316 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 317 "Multicast Source" field and the wildcard C-* in its "Multicast 318 Group" field. See [RFC6625]. 320 o (C-*,C-*) S-PMSI A-D route 322 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 323 "Multicast Source" field and the wildcard C-* in its "Multicast 324 Group" field. See [RFC6625]. 326 o (C-*,C-*-BIDIR) S-PMSI A-D route 328 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 329 "Multicast Source" field and the wildcard "C-*-BIDIR" in its 330 "Multicast Group" field. See Section 2 of this document. 332 o (C-S,C-*) S-PMSI A-D route 333 An S-PMSI A-D route whose NLRI contains C-S in its "Multicast 334 Source" field and the wildcard C-* in its "Multicast Group" field. 335 See [RFC6625]. 337 o Wildcard S-PMSI A-D route 339 A (C-*,C-G) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route, or 340 a (C-S,C-*) S-PMSI A-D route, or a (C-*,C-*-BIDIR) S-PMSI A-D 341 route. 343 o PTA 345 PMSI Tunnel attribute, a BGP attribute that identifies a P-tunnel. 346 See [RFC6514] section 8. 348 The terminology used for categorizing S-PMSI A-D routes will also be 349 used for categorizing the S-PMSIs advertised by those routes. E.g., 350 the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route will be known 351 as a "(C-*,C-G) S-PMSI". 353 Familiarity with multicast concepts and terminology [RFC4601] is also 354 presupposed. 356 This specification uses the terms "match for transmission" and "match 357 for reception" as they are defined in [RFC6625]. When it is clear 358 from the context whether we are talking of transmission or reception, 359 we will sometimes talk simply of a C-flow "matching" an I-PMSI or 360 S-PMSI A-D route. 362 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 363 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 364 document, when and only when appearing in all caps, are to be 365 interpreted as described in [RFC2119]. 367 1.2. Overview 369 The base documents for MVPN ([RFC6513], [RFC6514]) define a "PMSI 370 Tunnel attribute" (PTA). This is a BGP Path Attribute that may be 371 attached to the BGP "I-PMSI A-D routes" and "S-PMSI A-D routes" that 372 are defined in those documents. The base documents define the way in 373 which the identifier of a bidirectional P-tunnel is to be encoded in 374 the PTA. However, those documents do not contain the full set of 375 specifications governing the use bidirectional P-tunnels; rather, 376 those documents declare the full set of specifications for using 377 bidirectional P-tunnels to be outside their scope. Similarly, the 378 use of bidirectional P-tunnels advertised in wildcard S-PMSI A-D 379 routes is declared by [RFC6625] to be "out of scope." 380 This document provides the specifications governing the use of 381 bidirectional P-tunnels to provide MVPN support. This includes the 382 procedures for assigning C-flows to specific bidirectional P-tunnels, 383 for advertising the fact that a particular C-flow has been assigned 384 to a particular bidirectional P-tunnel, and for determining the 385 bidirectional P-tunnel on which a given C-flow may be expected. 387 The C-flows carried on bidirectional P-tunnels may themselves be 388 either unidirectional or bidirectional. Procedures are provided for 389 both cases. 391 This document does not specify any new data encapsulations for 392 bidirectional P-tunnels. Section 12 ("Encapsulations") of [RFC6513] 393 applies unchanged. 395 With regard to the procedures for using bidirectional P-tunnels to 396 instantiate PMSIs, if there is any conflict between the procedures 397 specified in this document and the procedures of [RFC6513], 398 [RFC6514], or [RFC6625], the procedures of this document take 399 precedence. 401 The use of bidirectional P-tunnels to support extranets [MVPN-XNET] 402 is outside the scope of this document. The use of bidirectional 403 P-tunnels as "segmented P-tunnels" (see [RFC6513] section 8 and 404 various sections of [RFC6514]) is also outside the scope of this 405 document. 407 1.2.1. Bidirectional P-tunnel Technologies 409 This document supports two different technologies for creating and 410 maintaining bidirectional P-tunnels: 412 o Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that 413 are created through the use of the Label Distribution Protocol 414 (LDP) Multipoint-to-Multipoint extensions [RFC6388]. 416 o Multicast distribution trees that are created through the use of 417 BIDIR-PIM [RFC5015]. 419 Other bidirectional tunnel technologies are outside the scope of this 420 document. 422 1.2.2. Reasons for Using Bidirectional P-tunnels 424 Bidirectional P-tunnels can be used to instantiate I-PMSIs and/or 425 S-PMSIs. 427 An SP may decide to use bidirectional P-tunnels to instantiate 428 certain I-PMSIs and/or S-PMSIs in order to provide its customers with 429 C-BIDIR support, using the "Partitioned Set of PEs" technique 430 discussed in [RFC6513] section 11.2 and [RFC6517] section 3.6. This 431 technique can be used whether the C-BIDIR flows are being carried on 432 an I-PMSI or an S-PMSI. 434 Even if an SP does not need to provide C-BIDIR support, it may still 435 decide to use bidirectional P-tunnels, in order to save state in the 436 network's transit nodes. For example, if an MVPN has n PEs attached 437 to sites with multicast sources, and there is an I-PMSI for that 438 MVPN, instantiating the I-PMSI with unidirectional P-tunnels (i.e., 439 with P2MP multicast distribution trees) requires n multicast 440 distribution trees, each one rooted at a different PE. If the I-PMSI 441 is instantiated by a bidirectional P-tunnel, a single multicast 442 distribution tree can be used, assuming appropriate support by the 443 provisioning system. 445 An SP may decide to use bidirectional P-tunnels for either or both of 446 these reasons. Note that even if the reason for using bidirectional 447 P-tunnels is to provide C-BIDIR support, the same P-tunnels can also 448 be used to carry unidirectional C-flows, if that is the choice of the 449 SP. 451 These two reasons for using bidirectional P-tunnels may appear to be 452 somewhat in conflict with each other, since (as will be seen in 453 subsequent sections), the use of bidirectional P-tunnels for C-BIDIR 454 support may require multiple bidirectional P-tunnels per VPN. Each 455 such P-tunnel is associated with a particular "distinguished PE", and 456 can only carry those C-BIDIR flows whose C-RPAs are reachable through 457 its distinguished PE. However, on platforms that support MPLS 458 upstream-assigned labels [RFC5331], "PE Distinguisher Labels" can be 459 used to aggregate multiple bidirectional P-tunnels onto a single 460 "outer" bidirectional P-tunnel, thereby allowing one to provide 461 C-BIDIR support with minimal state at the transit nodes. 463 Since there are two fundamentally different reasons for using 464 bidirectional P-tunnels, and since many deployed router platforms do 465 not support upstream-assigned labels at the current time, this 466 document specifies several different methods of using bidirectional 467 P-tunnels to instantiate PMSIs. We refer to these as "PMSI 468 Instantiation Methods". The method or methods deployed by any 469 particular SP will depend upon that SP's goals and engineering 470 tradeoffs, and upon the set of platforms deployed by that SP. 472 The rules for using bidirectional P-tunnels in I-PMSI or S-PMSI A-D 473 routes are not exactly the same as the rules for using unidirectional 474 P-tunnels, and the rules are also different for the different PMSI 475 instantiation methods. Subsequent sections of this document specify 476 the rules in detail. 478 1.2.3. Knowledge of Group-to-RP and/or Group-to-RPA Mappings 480 If a VPN customer is making use of a particular "Any Source 481 Multicast" (ASM) group address, the PEs of that VPN generally need to 482 know the group-to-RP mappings that are used within the VPN. If a VPN 483 customer is making use of BIDIR-PIM group addresses, the PEs need to 484 know the group-to-RPA mappings that are used within the VPN. 485 Commonly, the PEs obtain this knowledge either through provisioning 486 or by participating in a dynamic "group-to-RP(A) mapping discovery 487 protocol" that runs within the VPN. However, the way in which this 488 knowledge is obtained is outside the scope of this document. 490 The PEs also need to be able to forward traffic towards the C-RPs 491 and/or C-RPAs, and to determine whether the next hop "interface" of 492 the route to a particular C-RP(A) is a VRF interface or a PMSI. This 493 is done by applying the procedures of [RFC6513] section 5.1. 495 1.2.4. PMSI Instantiation Methods 497 This document specifies three methods for using bidirectional 498 P-tunnels to instantiate PMSIs: the Flat Partitioned Method, the 499 Hierarchical Partitioned Method, and the Unpartitioned Method. 501 o Partitioned Methods 503 In the Partitioned Methods, a particular PMSI is instantiated by a 504 set of bidirectional P-tunnels. These P-tunnels may be aggregated 505 (as "inner" P-tunnels) into a single "outer" bidirectional 506 P-tunnel ("Hierarchical Partitioning"), or they may be 507 unaggregated ("Flat Partitioning"). Any PE that joins one of 508 these P-tunnels can transmit a packet on it, and the packet will 509 be received by all the other PEs that have joined the P-tunnel. 510 For each such P-tunnel (each "inner" P-tunnel, in the case of 511 Hierarchical Partitioning) there is one PE that is its 512 "distinguished PE". When a PE receives a packet from a given 513 P-tunnel, the PE can determine from the packet's encapsulation the 514 P-tunnel is has arrived on, and can thus infer the identity of the 515 distinguished PE associated with the packet. This association 516 plays an important role in the treatment of the packet, as 517 specified later on in this document. 519 The number of P-tunnels needed (the number of "inner" P-tunnels 520 needed, if Hierarchical Partitioning is used) depends upon a 521 number of factors that are described later in this document. 523 The Hierarchical Partitioned Method requires the use of upstream- 524 assigned MPLS labels ("PE Distinguisher Labels"), and requires the 525 use of the PE Distinguisher Labels attribute in BGP. The Flat 526 Partitioned Method requires neither of these. 528 The Partitioned Method (either flat or hierarchical) is a pre- 529 requisite for implementing the "Partitioned Sets of PEs" technique 530 of supporting C-BIDIR, as discussed in [RFC6513] section 11.2. 531 The Partitioned Method (either flat or hierarchical) is also a 532 pre-requisite for applying the "Discarding Packets from Wrong PE" 533 technique, discussed in [RFC6513] Section 9.1.1, to a PMSI that is 534 instantiated by a bidirectional P-tunnel. 536 The Flat Partitioned Method is a pre-requisite for implementing 537 the "Partial Mesh of MP2MP P-tunnels" technique for carrying 538 customer bidirectional (C-BIDIR) traffic, as discussed in 539 [RFC6513] Section 11.2.3. 541 The Hierarchical Partitioned Method is a pre-requisite for 542 implementing the "Using PE Distinguisher Labels" technique of 543 carrying customer bidirectional (C-BIDIR) traffic, as discussed in 544 [RFC6513] Section 11.2.2. 546 Note that a particular deployment may choose to use the 547 Partitioned Method for carrying the C-BIDIR traffic on 548 bidirectional P-tunnels, while carrying other traffic either on 549 unidirectional P-tunnels, or on bidirectional P-tunnels using the 550 Unpartitioned Method. Routers in a given deployment must be 551 provisioned to know which PMSI instantiation method to use for 552 which PMSIs. 554 There may be ways of implementing the Partitioned Method with 555 PMSIs that are instantiated by unidirectional P-tunnels. (See, 556 e.g., [MVPN-BIDIR-IR].) However, that is outside the scope of the 557 current document. 559 o Unpartitioned Method 561 In the Unpartitioned Method, a particular PMSI can be instantiated 562 by a single bidirectional P-tunnel. Any PE that joins the tunnel 563 can transmit a packet on it, and the packet will be received by 564 all the other PEs that have joined the tunnel. The receiving PEs 565 can determine the tunnel on which the packet was transmitted, but 566 they cannot determine which PE transmitted the packet, nor can 567 they associate the packet with any particular "distinguished PE". 569 When the Unpartitioned Method is used, this document does not 570 mandate that only one bidirectional P-tunnel be used to 571 instantiate each PMSI. It allows for the case where more than one 572 P-tunnel is used. In this case, the transmitting PEs will have a 573 choice of which such P-tunnel to use when transmitting, and the 574 receiving PEs must be prepared to receive from any of those 575 P-tunnels. The use of multiple P-tunnels in this case provides 576 additional robustness, but no additional functionality. 578 If a bidirectional P-tunnels are being used to instantiate the PMSIs 579 of a given MVPN, one of these methods must be chosen for that MVPN. 580 All the PEs of that MVPN must be provisioned to know the method that 581 is being used for that MVPN. 583 I-PMSIs may be instantiated by bidirectional P-tunnels using either 584 the Partitioned (either Flat or Hierarchical) or the Unpartitioned 585 Method. The method used for a given MVPN is determined by 586 provisioning. It SHOULD be possible to provision this on a per-MVPN 587 basis, but all the VRFs of a single MVPN MUST be provisioned to use 588 the same method for the given MVPN's I-PMSI. 590 If a bidirectional P-tunnel is used to instantiate an S-PMSI 591 (including the case of a (C-*,C-*) S-PMSI), either the Partitioned 592 Method (either Flat or Hierarchical) or the Unpartitioned Method may 593 be used. The method used by a given VRF used is determined by 594 provisioning. It SHOULD be possible to provision this on a per-MVPN 595 basis, but all the VRFs of a single MVPN MUST be provisioned to use 596 the same method for those of their S-PMSIs that are instantiated by 597 bidirectional P-tunnels. 599 If the Partitioned Method is used, all the VRFs of a single MVPN MUST 600 be provisioned to use the same variant of the Partitioned Method, 601 i.e., either they must all use the Flat Partitioned Method, or they 602 must all use the Hierarchical Partitioned Method. 604 It is valid to use the Unpartitioned Method to instantiate the 605 I-PMSIs, while using one of the Partitioned Methods to instantiate 606 the S-PMSIs. 608 It is valid to instantiate some S-PMSIs by unidirectional P-tunnels 609 and others by bidirectional P-tunnels. 611 The procedures for the use of bidirectional P-tunnels, specified in 612 subsequent sections of this document, depend on both the tunnel 613 technology and on the PMSI instantiation method. Note that this 614 document does not necessarily specify procedures for every possible 615 combination of tunnel technology and PMSI instantiation method. 617 2. The All BIDIR-PIM Wild Card 619 When an MVPN customer is using BIDIR-PIM, it is useful to be able to 620 advertise an S-PMSI A-D route whose semantics are: "by default, all 621 BIDIR-PIM C-multicast traffic (within a given VPN) that has not been 622 bound to any other P-tunnel is bound to the bidirectional P-tunnel 623 identified by the PTA of this route". This can be especially useful 624 if one is using a bidirectional P-tunnel to carry the C-BIDIR flows, 625 while using unidirectional P-tunnels to carry other C-flows. To do 626 this, it is necessary to have a way to encode a (C-*,C-*) wildcard 627 that is restricted to BIDIR-PIM C-groups. 629 We therefore define a special value of the group wildcard, whose 630 meaning is "all BIDIR-PIM groups". The "BIDIR-PIM groups wildcard" 631 is encoded as a group field whose length is 8 bits and whose value is 632 zero. That is, the "multicast group length" field contains the value 633 0x08, and the "multicast group" field is a single octet containing 634 the value 0x00. We will use the notation (C-*,C-*-BIDIR) to refer to 635 the "all BIDIR-PIM groups" wildcard. 637 3. Using Bidirectional P-Tunnels 639 A bidirectional P-tunnel may be advertised in the PTA of an Intra-AS 640 I-PMSI A-D route or in the PTA of an S-PMSI A-D route. The 641 advertisement of a bidirectional P-tunnel in the PTA of an Inter-AS 642 I-PMSI A-D route is outside the scope of this document. 644 3.1. Procedures Specific to the Tunneling Technology 646 This section discusses the procedures that are specific to a given 647 tunneling technology (BIDIR-PIM or MP2MP mLDP), but that are 648 independent of the method (Unpartitioned, Flat Partitioned, or 649 Hierarchical Partitioned) used to instantiate a PMSI. 651 3.1.1. BIDIR-PIM P-Tunnels 653 Each BIDIR-PIM P-Tunnel is identified by a unique P-group address 654 ([RFC6513], section 3.1). (The P-group address is called a 655 "P-Multicast Group" in [RFC6514]). Section 5 of [RFC6514] specifies 656 the way to identify a particular BIDIR-PIM P-tunnel in the PTA of an 657 I-PMSI or S-PMSI A-D route. 659 Ordinary BIDIR-PIM procedures are used to set up the BIDIR-PIM 660 P-tunnels. A BIDIR-PIM P-group address is always associated with a 661 unique "Rendezvous Point Address" (RPA) in the SP's address space. 662 We will refer to this as the "P-RPA". Every PE needing to join a 663 particular BIDIR-PIM P-tunnel must be able to determine the P-RPA 664 that corresponds to the P-tunnel's P-group address. To construct the 665 P-tunnel, PIM Join/Prune messages are sent along the path from the PE 666 to the P-RPA. Any P routers along that path must also be able to 667 determine the P-RPA, so that they too can send PIM Join/Prune 668 messages towards it. The method of mapping a P-group address to an 669 RPA may be static configuration, or some automated means of RPA 670 discovery that is outside the scope of this specification. 672 If a BIDIR-PIM P-tunnel is used to instantiate an I-PMSI or an 673 S-PMSI, it is RECOMMENDED that the path from each PE in the tunnel to 674 the RPA consist entirely of point-to-point links. On a point-to- 675 point link, there is no ambiguity in determining which router is 676 upstream towards a particular RPA, so the BIDIR-PIM "Designated 677 Forwarder Election" is very quick and simple. Use of a BIDIR-PIM 678 P-tunnel containing multiaccess links is possible, but considerably 679 more complex. 681 The use of BIDIR-PIM P-tunnels to support the Hierarchical 682 Partitioned Method is outside the scope of this document. 684 When the PTA of an Intra-AS I-PMSI A-D route or an S-PMSI A-D route 685 identifies a BIDIR-PIM tunnel, the originator of the route SHOULD NOT 686 include a PE Distinguisher Labels attribute. If it does, that 687 attribute MUST be ignored. When we say the attribute is "ignored", 688 we do not mean that its normal BGP processing is not done, but that 689 the attribute has no effect on the data plane. It MUST however be 690 treated by BGP as if it were an unsupported optional transitive 691 attribute. (PE Distinguisher Labels are used for the Hierarchical 692 Partitioning Method, but this document does not provide support for 693 the Hierarchical Partitioning Method with BIDIR-PIM P-tunnels.) 695 3.1.2. MP2MP LSPs 697 Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding 698 Equivalence Class) element" [RFC6388]. The FEC element contains the 699 IP address of the root node, followed by an opaque value that 700 identifies the MP2MP LSP uniquely in the context of the root node's 701 IP address. This opaque value may be configured or autogenerated; 702 there is no need for different root nodes to use the same opaque 703 value for a given MVPN. 705 The mLDP specification supports the use of several different ways of 706 constructing the tunnel identifiers. The current specification does 707 not place any restriction on the type or types of tunnel identifier 708 that is used in a given deployment. A given implementation is not 709 expected to be able to advertise (in the PTAs of I-PMSI or S-PMSI A-D 710 routes) tunnel identifiers of every possible type. However, an 711 implementation SHOULD be able to accept and properly process a PTA 712 that uses any legal type of tunnel identifier. 714 Section 5 of [RFC6514] specifies the way to identify a particular 715 MP2MP P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route. 717 Ordinary mLDP procedures for MP2MP LSPs are used to set up the MP2MP 718 LSP. 720 3.2. Procedures Specific to the PMSI Instantiation Method 722 When either the Flat Partitioned Method or the Hierarchical 723 Partitioned Method is used to implement the "Partitioned Sets of PEs" 724 method of supporting C-BIDIR, as discussed in section 11.2 of 725 [RFC6513] and section 3.6 of [RFC6517], a C-BIDIR flow MUST be 726 carried only on an I-PMSI or on a (C-*,C-G-BIDIR), (C-*,C-*-BIDIR), 727 or (C-*,C-*) S-PMSI. A PE MUST NOT originate any (C-S,C-G-BIDIR) 728 S-PMSI A-D routes. (Though it may of course originate (C-S,C-G) 729 S-PMSI A-D routes for C-G's that are not C-BIDIR groups.) Packets of 730 a C-BIDIR flow MUST NOT be carried on a (C-S,C-*) S-PMSI. 732 Section 3.2.1 and Section 3.2.2 specify additional details of the two 733 Partitioned Methods. 735 3.2.1. Flat Partitioning 737 The procedures of this section and its sub-sections apply when (and 738 only when) the Flat Partitioned Method is used. This method is 739 introduced in [RFC6513] Section 11.2.3, where it is called "Partial 740 Mesh of MP2MP P-tunnels". This method can be used with MP2MP LSPs or 741 with BIDIR-PIM P-tunnels. 743 When a PE originates an I-PMSI or S-PMSI A-D route whose PTA 744 specifies a bidirectional P-tunnel, the PE MUST be the root node of 745 the specified P-tunnel. 747 If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a 748 distinct P-group address. The PE advertising the tunnel will be 749 considered to be the root node of the tunnel. Note that this creates 750 a unique mapping from P-group address to root node. The assignment 751 of P-group addresses to MVPNs is by provisioning. 753 If MP2MP LSPs are used, each P-tunnel MUST have a distinct MP2MP FEC 754 (i.e., distinct combination of root node and opaque value). The PE 755 advertising the tunnel MUST be the same PE identified in the root 756 node field of the MP2MP FEC that is encoded in the PTA. 758 It follows that two different PEs may not advertise the same 759 bidirectional P-tunnel. Any PE that receives a packet from the 760 P-tunnel can infer the identity of the P-tunnel from the packet's 761 encapsulation. Once the identity of the P-tunnel is known, the root 762 node of the P-tunnel is also known. The root node of the P-tunnel on 763 which the packet arrived is treated as the "distinguished PE" for 764 that packet. 766 The Flat Partitioned Method does not use upstream-assigned labels in 767 the data plane, and hence does not use the BGP PE Distinguisher 768 Labels attribute. When this method is used, I-PMSI and/or S-PMSI A-D 769 routes SHOULD NOT contain a PE Distinguisher Labels attribute; if 770 such an attribute is present in a received I-PMSI or S-PMSI A-D 771 route, it MUST be ignored. (When we say the attribute is "ignored", 772 we do not mean that its normal BGP processing is not done, but that 773 the attribute has no effect on the data plane. It MUST however be 774 treated by BGP as if it were an unsupported optional transitive 775 attribute.) 777 When the Flat Partitioned Method is used to instantiate the I-PMSIs 778 of a given MVPN, every PE in that MVPN that originates an Intra-AS 779 I-PMSI A-D route MUST include a PTA that specifies a bidirectional 780 P-tunnel. If the intention is to carry C-BIDIR traffic on the 781 I-PMSI, a PE MUST originate an Intra-AS I-PMSI A-D route if one of 782 its VRF interfaces is the next hop interface on its best path to the 783 C-RPA of any bidirectional C-group of the MVPN. 785 When the Flat Partitioned Method is used to instantiate a (C-*,C-*) 786 S-PMSI, a (C-*,C-*-BIDIR) S-PMSI, or a (C-*,C-G-BIDIR) S-PMSI, a PE 787 that originates the corresponding S-PMSI A-D route MUST include in 788 that route a PTA specifying a bidirectional P-tunnel. Per the 789 procedures of [RFC6513] and [RFC6514], a PE will originate such an 790 S-PMSI A-D route only if one of the PE's VRF interfaces is the next 791 hop interface of the PE's best path to the C-RPA of a C-BIDIR group 792 that is to be carried on the specified S-PMSI. 794 PMSIs that are instantiated via the Flat Partitioned Method may carry 795 customer bidirectional traffic AND customer unidirectional traffic. 796 The rules of Section 3.2.1.1 and Section 3.2.1.2 determine when a 797 given customer multicast packet is a match for transmission to a 798 given PMSI. However, if the "Partitioned Set of PEs" method of 799 supporting C-BIDIR traffic is being used for a given MVPN, the PEs 800 must be provisioned in such a way that packets from a C-BIDIR flow of 801 that MVPN never match any PMSI that is not instantiated by a 802 bidirectional P-tunnel. (For example, if the given MVPN's (C-*,C-*) 803 S-PMSI were not instantiated by a bidirectional P-tunnel, one could 804 meet this requirement by carrying all C-BIDIR traffic of that MVPN on 805 a (C-*,C-*-BIDIR) S-PMSI.) 807 When a PE receives a customer multicast data packet from a 808 bidirectional P-tunnel, it associates that packet with a 809 "distinguished PE". The distinguished PE for a given packet is the 810 root node of the tunnel from which the packet is received. The rules 811 of Section 3.2.1.1 and Section 3.2.1.2 ensure that: 813 o If the received packet is part of a unidirectional C-flow, its 814 "distinguished PE" is the PE that transmitted the packet onto the 815 P-tunnel. 817 o If the received packet is part of a bidirectional C-flow, its 818 "distinguished PE" is not necessarily the PE that transmitted it, 819 but rather the transmitter's "upstream PE" for the C-RPA of the 820 bidirectional C-group. 822 The rules of Section 3.2.1.3 and Section 3.2.1.4 allow the receiving 823 PEs to determine the expected distinguished PE for each C-flow, and 824 ensure that a packet will be discarded if its distinguished PE is not 825 the expected distinguished PE for the C-flow to which the packet 826 belongs. This prevents duplication of data for both bidirectional 827 and unidirectional C-flows. 829 3.2.1.1. When an S-PMSI is a 'Match for Transmission' 831 Suppose a given PE, say PE1, needs to transmit multicast data packets 832 of a particular C-flow. [RFC6625] Section 3.1 gives a four-step 833 algorithm for determining the S-PMSI A-D route, if any, that matches 834 that C-flow for transmission. 836 If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged; 837 the remainder of this section applies only to C-BIDIR flows. If a 838 C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 839 are given below: 841 o If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's 842 route to the C-RPA is via a VRF interface, then: 844 * If there is a (C-*,C-G-BIDIR) S-PMSI A-D route currently 845 originated by PE1, then the C-flow matches that route. 847 * Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route 848 currently originated by PE1, then the C-flow matches that 849 route. 851 * Otherwise, if there is a (C-*,C-*) S-PMSI A-D route currently 852 originated by PE1, then the C-flow matches that route. 854 o If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some 855 other PE, say PE2, then: 857 * If there is an installed (C-*,C-G-BIDIR) S-PMSI A-D route 858 originated by PE2, then the C-flow matches that route. 860 * Otherwise, if there is an installed (C-*,C-*-BIDIR) S-PMSI A-D 861 route originated by PE2, then the C-flow matches that route. 863 * Otherwise, if there is an installed (C-*,C-*) S-PMSI A-D route 864 originated by PE2, then the C-flow matches that route. 866 If there is an S-PMSI A-D route that matches a given C-flow, and if 867 PE1 needs to transmit packets of that C-flow or other PEs, then it 868 MUST transmit those packets on the bidirectional P-tunnel identified 869 in the PTA of the matching S-PMSI A-D route. 871 3.2.1.2. When an I-PMSI is a 'Match for Transmission' 873 Suppose a given PE, say PE1, needs to transmit packets of a given 874 C-flow (of a given MVPN) to other PEs, but according to the 875 conditions of Section 3.2.1.1 and/or [RFC6625] section 3.1, that 876 C-flow does not match any S-PMSI A-D route. Then the packets of the 877 C-flow need to be transmitted on the MVPN's I-PMSI. 879 If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the 880 C-flow MUST be transmitted is the one identified in the PTA of the 881 Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. 883 If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the 884 rules applied by PE1 are: 886 o If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's 887 route to the C-RPA is via a VRF interface, then if there is an 888 I-PMSI A-D route currently originated by PE1, then the C-flow MUST 889 be transmitted on the P-tunnel identified in the PTA of that 890 I-PMSI A-D route. 892 o If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some 893 other PE, say PE2, then if there is an installed I-PMSI A-D route 894 originated by PE2, the C-flow MUST be transmitted on the P-tunnel 895 identified in the PTA of that route. 897 If there is no I-PMSI A-D route meeting the above conditions, the 898 C-flow MUST NOT be transmitted. 900 3.2.1.3. When an S-PMSI is a 'Match for Reception' 902 Suppose a given PE, say PE1, needs to receive multicast data packets 903 of a particular C-flow. [RFC6625] Section 3.2 specifies procedures 904 for determining the S-PMSI A-D route, if any, that matches that 905 C-flow for reception. Those rules apply unchanged for C-flows that 906 are not BIDIR-PIM C-flows. The remainder of this section applies 907 only to C-BIDIR flows. 909 The rules of [RFC6625] Section 3.2.1 are not applicable to C-BIDIR 910 flows. The rules of [RFC6625] Section 3.2.2 are replaced by the 911 following rules. 913 Suppose PE1 needs to receive (C-*,C-G-BIDIR) traffic. Suppose also 914 that PE1 has determined that PE2 is the "upstream PE" [RFC6513] for 915 the C-RPA of C-G-BIDIR. Then: 917 o If PE1 is not the same as PE2, and PE1 has an installed 918 (C-*,C-G-BIDIR) S-PMSI A-D route originated by PE2, then 919 (C-*,C-G-BIDIR) matches this route. 921 o Otherwise, if PE1 is the same as PE2, and PE1 has currently 922 originated a (C-*,C-G-BIDIR) S-PMSI A-D route, then 923 (C-*,C-G-BIDIR) matches this route. 925 o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed 926 (C-*,C-*-BIDIR) S-PMSI A-D route originated by PE2, then 927 (C-*,C-G-BIDIR) matches this route. 929 o Otherwise, if PE1 is the same as PE2, and PE1 has currently 930 originated a (C-*,C-*-BIDIR) S-PMSI A-D route, then 931 (C-*,C-G-BIDIR) matches this route. 933 o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed 934 (C-*,C-*) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR) 935 matches this route. 937 o Otherwise, if PE1 is the same as PE2, and PE1 has currently 938 originated a (C-*,C-*) S-PMSI A-D route, then (C-*,C-G-BIDIR) 939 matches this route. 941 If there is an S-PMSI A-D route matching (C-*,C-G-BIDIR), according 942 to these rules, the root node of that P-tunnel is considered to be 943 the "distinguished PE" for that (C-*,C-G-BIDIR) flow. If a 944 (C-*,C-G-BIDIR) packet is received on a P-tunnel whose root node is 945 not the distinguished PE for the C-flow, the packet MUST be 946 discarded. 948 3.2.1.4. When an I-PMSI is a 'Match for Reception 950 Suppose a given PE, say PE1, needs to receive packets of a given 951 C-flow (of a given MVPN) from another PE, but according to the 952 conditions of Section 3.2.1.3 and/or [RFC6625] section 3.2, that 953 C-flow does not match any S-PMSI A-D route. Then the packets of the 954 C-flow need to be received on the MVPN's I-PMSI. 956 If the C-flow is not a BIDIR-PIM C-flow, the rules for determining 957 the P-tunnel on which packets of the C-flow are expected are given in 958 [RFC6513]. The remainder of this section applies only to C-BIDIR 959 flows. 961 Suppose that PE1 needs to receive (C-*,C-G-BIDIR) traffic from other 962 PEs. Suppose also that PE1 has determined that PE2 is the "upstream 963 PE" [RFC6513] for the C-RPA of C-G-BIDIR. Then PE1 considers PE2 to 964 be the "distinguished PE" for (C-*,C-G-BIDIR). If PE1 has an 965 installed Intra-AS I-PMSI A-D route originated by PE2, PE1 will 966 expect to receive packets of the C-flow from the tunnel specified in 967 that route's PTA. (If all VRFs of the MVPN have been properly 968 provisioned to use the Flat Partitioned Method for the I-PMSI, the 969 PTA will specify a bidirectional P-tunnel.) Note that if PE1 is the 970 same as PE2, then the relevant Intra-AS I-PMSI A-D route is the one 971 currently originated by PE1. 973 If a (C-*,C-G-BIDIR) packet is received on a P-tunnel other than the 974 expected one, packet MUST be discarded. 976 3.2.2. Hierarchical Partitioning 978 The procedures of this section and its sub-sections apply when (and 979 only when) the Hierarchical Partitioned Method is used. This method 980 is introduced in [RFC6513] Section 11.2.2. This document only 981 provides procedures for using this method when using MP2MP LSPs as 982 the P-tunnels. 984 The Hierarchical Partitioned Method provides the same functionality 985 as the Flat Partitioned Method, but requires a smaller amount of 986 state to be maintained in the core of the network. However, it 987 requires the use of upstream-assigned MPLS labels ("PE Distinguisher 988 Labels"), which are not necessarily supported by all hardware 989 platforms. The upstream-assigned labels are used to provide an LSP 990 hierarchy, in which an "outer" MP2MP LSP carries multiple "inner" 991 MP2MP LSPs. Transit routers along the path between PE routers then 992 only need to maintain state for the outer MP2MP LSP. 994 When this method is used to instantiate a particular PMSI, the 995 bidirectional P-tunnel advertised in the PTA of the corresponding 996 I-PMSI or S-PMSI A-D route is the "outer" P-tunnel. When a packet is 997 received from a P-tunnel, the PE that receives it can infer the 998 identity of the outer P-tunnel from the MPLS label that has risen to 999 the top of the packet's label stack. However, the packet's 1000 "distinguished PE" is not necessarily the root node of the the outer 1001 P-tunnel. Rather, the identity of the packet's distinguished PE is 1002 inferred from the PE Distinguisher Label further down in the label 1003 stack. (See [RFC6513] Section 12.3.) The PE Distinguisher Label may 1004 be thought of as identifying an "inner" MP2MP LSP whose root is the 1005 PE corresponding to that label. 1007 In the context of a given MVPN, if it is desired to use the 1008 Hierarchical Partitioned Method to instantiate an I-PMSI, a (C-*,C-*) 1009 S-PMSI, or a (C-*,C-*-BIDIR) S-PMSI, the corresponding A-D routes 1010 MUST be originated by some of the PEs that attach to that MVPN. The 1011 PEs are REQUIRED to originate these routes are those that satisfy one 1012 of the following conditions: 1014 o There is a C-BIDIR group for which the best path from the PE to 1015 the C-RPA of that C-group is via a VRF interface, or 1017 o The PE might have to transmit unidirectional customer multicast 1018 traffic on the PMSI identified in the route (of course this 1019 condition does not apply to (C-*,C-*-BIDIR) or to (C-*,C-G-BIDIR) 1020 S-PMSIs). 1022 o The PE is the root node of the MP2MP LSP that is used to 1023 instantiate the PMSI. 1025 When the Hierarchical Partitioned method is used to instantiate a 1026 (C-*,C-G-BIDIR) S-PMSI, the corresponding (C-*,C-G-BIDIR) S-PMSI 1027 route MUST NOT be originated by a given PE unless either (a) that 1028 PE's best path to the C-RPA for C-G-BIDIR is via a VRF interface, or 1029 (b) the C-RPA is a C-address of the PE. Further, that PE MUST be the 1030 root node of the MP2MP LSP identified in the PTA of the S-PMSI A-D 1031 route. 1033 If any VRF of a given MVPN uses this method to instantiate an S-PMSI 1034 with a bidirectional P-tunnel, all VRFs of that MVPN must use this 1035 method. 1037 Suppose that for a given MVPN, the Hierarchical Partitioned Method is 1038 used to instantiate the I-PMSI. In general, more than one of the PEs 1039 in the MVPN will originate an Intra-AS I-PMSI A-D route for that 1040 MVPN. This document allows the PTAs of those routes to all specify 1041 the same MP2MP LSP as the "outer tunnel". However, it does not 1042 require that those PTAs all specify the same MP2MP LSP as the outer 1043 tunnel. By having all the PEs specify the same outer tunnel for the 1044 I-PMSI, one can minimize the amount of state in the transit nodes. 1045 By allowing them to specify different outer tunnels, one uses more 1046 state, but may increase the robustness of the system. 1048 The considerations of the previous paragraph apply as well when the 1049 Hierarchical Partitioned Method is used to instantiate an S-PMSI. 1051 3.2.2.1. Advertisement of PE Distinguisher Labels 1053 A PE Distinguisher Label is an upstream-assigned MPLS label [RFC5331] 1054 that can be used, in the context of a MP2MP LSP, to denote a 1055 particular PE that either has joined or may in the future join that 1056 LSP. 1058 In order to use upstream-assigned MPLS labels in the context of an 1059 "outer" MP2MP LSP, there must be a convention that identifies a 1060 particular router as the router that is responsible for allocating 1061 the labels and for advertising the labels to the PEs that may join 1062 the MP2MP LSP. This document REQUIRES that the PE Distinguisher 1063 Labels used in the context of a given MP2MP LSP be allocated and 1064 advertised by the router that is the root node of the LSP. 1066 This convention accords with the rules of section 7 of [RFC5331]. 1067 Note that according to section 7 of [RFC5331], upstream-assigned 1068 labels are unique in the context of the IP address of the root node; 1069 if two MP2MP LSPs have the same root node IP address, the upstream- 1070 assigned labels used within the two LSPs come from the same label 1071 space. 1073 This document assumes that the root node address of an MP2MP LSP an 1074 IP address that is uniquely assigned to the node. The use of an 1075 "anycast address" as the root node address is outside the scope of 1076 this document. 1078 A PE Distinguisher Labels attribute SHOULD NOT be attached to an 1079 I-PMSI or S-PMSI A-D route unless that route also contains a PTA that 1080 specifies an MP2MP LSP. (While PE Distinguisher Labels could in 1081 theory also be used if the PTA specifies a BIDIR-PIM P-tunnel, such 1082 use is outside the scope of this document.) 1084 The PE Distinguisher Labels attribute specifies a set of bindings. Within a given PE Distinguisher Labels 1086 attribute, each such IP address MUST appear at most once, and each 1087 MPLS label MUST appear only once. Otherwise the attribute is 1088 considered to be malformed, and the "treat-as-withdraw" error- 1089 handling approach described in Section 2 of [BGP-ERROR] MUST be used. 1091 When a PE Distinguisher Labels attribute is included in a given 1092 I-PMSI or S-PMSI A-D route, it MUST assign a label to the IP address 1093 of each of the following PEs: 1095 o The root node of the MP2MP LSP identified in the PTA of the route, 1096 o Any PE that is possibly the ingress PE for a C-RPA of any C-BIDIR 1097 group. 1099 o Any PE that may need to transmit non-C-BIDIR traffic on the MP2MP 1100 LSP identified in the PTA of the route. 1102 One simple way to meet these requirements is to assign a PE 1103 Distinguisher label to every PE that has originated an Intra-AS 1104 I-PMSI A-D route. 1106 3.2.2.2. When an S-PMSI is a 'Match for Transmission' 1108 Suppose a given PE, say PE1, needs to transmit multicast data packets 1109 of a particular C-flow. [RFC6625] Section 3.1 gives a four-step 1110 algorithm for determining the S-PMSI A-D route, if any, that matches 1111 that C-flow for transmission. 1113 If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged. 1114 If there is a matching S-PMSI A-D route, the P-tunnel on which the 1115 C-flow MUST be transmitted is the one identified in the PTA of the 1116 matching route. Each packet of the C-flow MUST carry the PE 1117 Distinguisher Label assigned by the root node of that P-tunnel to the 1118 IP address of PE1. See section 12.3 of [RFC6513] for encapsulation 1119 details. 1121 The remainder of this section applies only to C-BIDIR flows. If a 1122 C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 1123 are the same as the rules given in Section 3.2.1.1. 1125 If there is a matching S-PMSI A-D route, PE1 MUST transmit the C-flow 1126 on the P-tunnel identified in its PTA. Suppose PE1 has determined 1127 that PE2 is the upstream PE for the C-RPA of the given C-flow. In 1128 constructing the packet's MPLS label stack, PE1 must use the PE 1129 Distinguisher Label that was assigned by the P-tunnel's root node to 1130 the IP address of "PE2", not the label assigned to the IP address of 1131 "PE1" (unless, of course, PE1 is the same as PE2). See section 12.3 1132 of [RFC6513] for encapsulation details. Note that the root of the 1133 P-tunnel might be a PE other than PE1 or PE2. 1135 3.2.2.3. When an I-PMSI is a 'Match for Transmission' 1137 Suppose a given PE, say PE1, needs to transmit packets of a given 1138 C-flow (of a given MVPN) to other PEs, but according to the 1139 conditions of Section 3.2.2.2 and/or [RFC6625] section 3.1, that 1140 C-flow does not match any S-PMSI A-D route. Then the packets of the 1141 C-flow need to be transmitted on the MVPN's I-PMSI. 1143 If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the 1144 C-flow MUST be transmitted is the one identified in the PTA of the 1145 Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. Each 1146 packet of the C-flow MUST carry the PE Distinguisher Label assigned 1147 by the root node of that P-tunnel to the IP address of PE1. 1149 If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the 1150 rules as applied by PE1 are the same as those given in 1151 Section 3.2.1.2. 1153 If there is a matching I-PMSI A-D route, PE1 MUST transmit the C-flow 1154 on the P-tunnel identified in its PTA. In constructing the packet's 1155 MPLS label stack, it must use the PE Distinguisher Label that was 1156 assigned by the P-tunnel's root node to the IP address of "PE2", not 1157 the label assigned to the IP address of "PE1" (unless, of course, PE1 1158 is the same as PE2). (Section 3.2.1.2 specifies the difference 1159 between PE1 and PE2.) See section 12.3 of [RFC6513] for 1160 encapsulation details. Note that the root of the P-tunnel might be a 1161 PE other than PE1 or PE2. 1163 If, for a packet of a particular C-flow, there is no S-PMSI A-D route 1164 or I-PMSI A-D route that is a match for transmission, the packet MUST 1165 NOT be transmitted. 1167 3.2.2.4. When an S-PMSI is a 'Match for Reception' 1169 Suppose a given PE, say PE1, needs to receive multicast data packets 1170 of a particular C-flow. [RFC6625] Section 3.2 specifies procedures 1171 for determining the S-PMSI A-D route, if any, that matches that 1172 C-flow for reception. Those rules require that the matching S-PMSI 1173 A-D route has been originated by the upstream PE for the C-flow. The 1174 rules are modified in this section, as follows: 1176 Consider a particular C-flow. Suppose either: 1178 o the C-flow is unidirectional, and PE1 determines that its upstream 1179 PE is PE2, or 1181 o the C-flow is bidirectional, and PE1 determines that the upstream 1182 PE for its C-RPA is PE2 1184 Then the C-flow may match an installed S-PMSI A-D route that was not 1185 originated by PE2, as long as: 1187 1. the PTA of that A-D route identifies an MP2MP LSP, and 1189 2. there is an installed S-PMSI A-D route originated by the root 1190 node of that LSP, or PE1 itself is the root node of the LSP and 1191 there is a currently originated S-PMSI A-D route from PE1 whose 1192 PTA identifies that LSP, and 1194 3. the latter S-PMSI A-D route (the one identified in 2 just above) 1195 contains a PE Distinguisher Labels attribute that assigned an 1196 MPLS label to the IP address of PE2. 1198 However, a bidirectional C-flow never matches an S-PMSI A-D route 1199 whose NLRI contains (C-S,C-G). 1201 If a multicast data packet is received over a matching P-tunnel, but 1202 does not carry the value of the PE Distinguisher Label that has been 1203 assigned to the upstream PE for its C-flow, then the packet MUST be 1204 discarded. 1206 3.2.2.5. When an I-PMSI is a 'Match for Reception' 1208 If a PE needs to receive packets of a given C-flow (of a given MVPN) 1209 from another PE, and if, according to the conditions of 1210 Section 3.2.2.4, that C-flow does not match any S-PMSI A-D route, 1211 then the packets of the C-flow need to be received on the MVPN's 1212 I-PMSI. The P-tunnel on which the packets are expected to arrive is 1213 determined by the Intra-AS I-PMSI A-D route originated by the 1214 "distinguished PE" for the given C-flow. The PTA of that route 1215 specifies the "outer P-tunnel", and thus determines the top label 1216 that packets of that C-flow will be carrying when received. A PE 1217 that needs to receive packets of a given C-flow must determine the 1218 expected value of the second label for packets of that C-flow. This 1219 will be the value of a PE Distinguisher Label, taken from the PE 1220 Distinguisher Labels attribute of the Intra-AS I-PMSI A-D route of 1221 the root node of that outer tunnel. The expected value of the second 1222 label on received packets (corresponding to the "inner tunnel") of a 1223 given C-flow is determined according to the following rules. 1225 First, the "distinguished PE" for the C-flow is determined: 1227 o If the C-flow is not a BIDIR-PIM C-flow, the "distinguished PE" 1228 for the C-flow is its "upstream PE", as determined by the rules of 1229 [RFC6513]. 1231 o If the C-flow is a BIDIR-PIM C-flow, the "distinguished PE" for 1232 the C-flow is its "upstream PE" of the C-flow's C-RPA, as 1233 determined by the rules of [RFC6513]. 1235 The expected value of the second label is the value that the root PE 1236 of the outer tunnel has assigned, in the PE Distinguisher Labels 1237 attribute of its Intra-AS I-PMSI A-D route, to the IP address of the 1238 "distinguished PE". 1240 Packets addressed to C-G that arrive on other than the expected inner 1241 and outer P-tunnels (i.e., that arrive with unexpected values of the 1242 top two labels) MUST be discarded. 1244 3.2.3. Unpartitioned 1246 When a particular MVPN uses the Unpartitioned Method of instantiating 1247 an I-PMSI with a bidirectional P-tunnel, it MUST be the case that at 1248 least one VRF of that MVPN originates an Intra-AS I-PMSI A-D route 1249 that includes a PTA specifying a bidirectional P-tunnel. The 1250 conditions under which an Intra-AS I-PMSI A-D route must be 1251 originated from a given VRF are as specified in [RFC6514]. This 1252 document allows all but one of such routes to omit the PTA. However, 1253 each such route MAY contain a PTA. If the PTA is present, it MUST 1254 specify a bidirectional P-tunnel. As specified in [RFC6513] and 1255 [RFC6514], every PE that imports such an Intra-AS I-PMSI A-D route 1256 into one of its VRFs MUST, if the route has a PTA, join the P-tunnel 1257 specified in the route's PTA. 1259 Packets received on any of these P-tunnels are treated as having been 1260 received over the I-PMSI. The disposition of a received packet MUST 1261 NOT depend upon the particular P-tunnel over which it has been 1262 received. 1264 When a PE needs to transmit a packet on such an I-PMSI, then if that 1265 PE advertised a P-tunnel in the PTA of an Intra-AS I-PMSI A-D route 1266 that it originated, the PE SHOULD transmit the on that P-tunnel. 1267 However, any PE that transmits a packet on the I-PMSI MAY transmit it 1268 on any of the P-tunnels advertised in any of the currently installed 1269 Intra-AS I-PMSI A-D routes for its VPN. 1271 This allows a single bidirectional P-tunnel to be used to instantiate 1272 the I-PMSI, but also allows the use of multiple bidirectional 1273 P-tunnels. There may be a robustness advantage in having multiple 1274 P-tunnels available for use, but the number of P-tunnels used does 1275 not impact the functionality in any way. If there are, e.g., two 1276 P-tunnels available, these procedures allow each P-tunnel to be 1277 advertised by a single PE, but they also allow each P-tunnel to be 1278 advertised by multiple PEs. Note that the PE advertising a given 1279 P-tunnel does not have to be the root node of the tunnel. The root 1280 node might not even be a PE router, and might not originate any BGP 1281 routes at all. 1283 In the Unpartitioned Method, packets received on the I-PMSI cannot be 1284 associated with a distinguished PE, so duplicate detection using the 1285 techniques of [RFC6513] section 9.1.1 is not possible; the techniques 1286 of [RFC6513] 9.1.2 or 9.1.3 would have to be used instead. Support 1287 for C-BIDIR using the "Partitioned set of PEs" technique ([RFC6513] 1288 section 11.2 and [RFC6517] section 3.6) is not possible when the 1289 Unpartitioned Method is used. If it is desired to use that technique 1290 to support C-BIDIR, but also to use the Unpartitioned Method to 1291 instantiate the I-PMSI, then all the C-BIDIR traffic would have to be 1292 carried on an S-PMSI, where the S-PMSI is instantiated using one of 1293 the Partitioned Methods. 1295 When a PE, say PE1, needs to transmit multicast data packets of a 1296 particular C-flow to other PEs, and PE1 does not have an S-PMSI that 1297 is a match for transmission for that C-flow (see Section 3.2.3.1), 1298 PE1 transmits the packets on one of the P-tunnel(s) that instantiates 1299 the I-PMSI. When a PE, say PE1, needs to receive multicast data 1300 packets of a particular C-flow from another PE, and PE1 does not have 1301 an S-PMSI that is a match for reception for that C-flow (see 1302 Section 3.2.3.2), PE1 expects to receive the packets on any of the 1303 P-tunnel(s) that instantiates the I-PMSI. 1305 When a particular MVPN uses the Unpartitioned Method to instantiate a 1306 (C-*,C-*) S-PMSI or a (C-*,C-*-BIDIR) S-PMSI using a bidirectional 1307 P-tunnel, the same conditions apply as when an I-PMSI is instantiated 1308 via the Unpartitioned Method. The only difference is that a PE need 1309 not join a P-tunnel that instantiates the S-PMSI unless that PE needs 1310 to receive multicast packets on the S-PMSI. 1312 When a particular MVPN uses bidirectional P-tunnels to instantiate 1313 other S-PMSIs, different S-PMSI A-D routes that do not contain 1314 (C-*,C-*) or (C-*,C-*-BIDIR), originated by the same or by different 1315 PEs, MAY have PTAs that identify the same bidirectional tunnel, and 1316 they MAY have PTAs that do not identify the same bidirectional 1317 tunnel. 1319 While the Unpartitioned Method MAY be used to instantiate an S-PMSI 1320 to which one or more C-BIDIR flows are bound, it must be noted that 1321 the "Partitioned Set of PEs" method discussed in [RFC6513] section 1322 11.2 and [RFC6517] section 3.6 cannot be supported using the 1323 Unpartitioned Method. C-BIDIR support would have to be provided by 1324 the procedures of [RFC6513] section 11.1. 1326 3.2.3.1. When an S-PMSI is a 'Match for Transmission' 1328 Suppose a PE needs to transmit multicast data packets of a particular 1329 customer C-flow. [RFC6625] Section 3.1 gives a four-step algorithm 1330 for determining the S-PMSI A-D route, if any, that matches that 1331 C-flow for transmission. When referring to that section, please 1332 recall that BIDIR-PIM groups are also "Any Source Multicast" (ASM) 1333 groups. 1335 When bidirectional P-tunnels are used in the Unpartitioned Method, 1336 the same algorithm applies, with one modification, when the PTA of an 1337 S-PMSI A-D route identifies a bidirectional P-tunnel. One additional 1338 step is added to the algorithm. This new step occurs before the 1339 fourth step of the algorithm, and is as follows: 1341 o Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route 1342 currently originated by PE1, and if C-G is a BIDIR group, the 1343 C-flow matches that route. 1345 When the Unpartitioned Method is used, the PE SHOULD transmit the 1346 C-flow on the P-tunnel advertised in the in the matching S-PMSI A-D 1347 route, but it MAY transmit the C-flow on any P-tunnel that is 1348 advertised in the PTA of any installed S-PMSI A-D route that contains 1349 the same (C-S,C-G) as the matching S-PMSI A-D route. 1351 3.2.3.2. When an S-PMSI is a 'Match for Reception' 1353 Suppose a PE needs to receive multicast data packets of a particular 1354 customer C-flow. [RFC6625] Section 3.2 specifies the procedures for 1355 determining the S-PMSI A-D route, if any, that advertised the 1356 P-tunnel on which the PE should expect to receive that C-flow. 1358 When bidirectional P-tunnels are used in the Unpartitioned Method, 1359 the same procedures apply, with one modification. 1361 The last paragraph of Section 3.2.2 of [RFC6625] begins: 1363 "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from 1364 PE2, but PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, 1365 then (C-*,C-G) matches the (C-*,C-*) route if one of the following 1366 conditions holds:" 1368 This is changed to: 1370 "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from 1371 PE2, but C-G is a BIDIR group and PE1 has an installed 1372 (C-*,C-*-BIDIR) S-PMSI A-D route, then (C-*,C-G) matches that 1373 route. Otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D 1374 route from PE2, then (C-*,C-G) matches the (C-*,C-*) route if one 1375 of the following conditions holds:" 1377 When the Unpartitioned Method is used, the PE MUST join the P-tunnel 1378 that is advertised in the matching S-PMSI A-D route, and MUST also 1379 join the P-tunnels that are advertised in other installed S-PMSI A-D 1380 routes that contain the same (C-S,C-G) as the matching S-PMSI A-D 1381 route. 1383 3.2.4. Minimal Feature Set for Compliance 1385 Implementation of bidirectional P-tunnels is OPTIONAL. If 1386 bidirectional P-tunnels are not implemented, the issue of compliance 1387 to this specification does not arise. However, for the case where 1388 bidirectional P-tunnels ARE implemented, this section specifies the 1389 minimal set of features that MUST be implemented in order to claim 1390 compliance to this specification. 1392 In order to be compliant with this specification, an implementation 1393 that provides bidirectional P-tunnels MUST support one or both of the 1394 two P-tunnel technologies mentioned in section Section 1.2.1. 1396 A PE that does not provide C-BIDIR support using the "partitioned set 1397 of PEs" method may be deemed compliant to this specification if it 1398 supports the Unpartitioned Method, using either MP2MP LSPs or BIDIR- 1399 PIM multicast distribute trees as P-tunnels. 1401 A PE that does provide C-BIDIR support using the "partitioned set of 1402 PEs" method, MUST, at a minimum, be able to provide C-BIDIR support 1403 using the "Partial Mesh of MP2MP P-tunnels" variant of this method 1404 (see section 11.2 of [RFC6513]). An implementation will be deemed 1405 compliant to this minimum requirement if it can carry all of a VPN's 1406 C-BIDIR traffic on a (C-*,C-*-BIDIR) S-PMSI that is instantiated by a 1407 bidirectional P-tunnel, using the flat partitioned method. 1409 4. IANA Considerations 1411 This document has no actions for IANA. 1413 5. Security Considerations 1415 There are no additional security considerations beyond those of 1416 [RFC6513] and [RFC6514], or any that may apply to the particular 1417 protocol used to set up the bidirectional tunnels ([RFC5015], 1418 [RFC6388]). 1420 6. Acknowledgments 1422 The authors wish to thank Karthik Subramanian, Rajesh Sharma, and 1423 Apoorva Karan for their input. We also thank Yakov Rekhter for his 1424 valuable critique. 1426 Special thanks go to Jeffrey (Zhaohui) Zhang for his careful review, 1427 probing questions, and useful suggestions. 1429 7. References 1431 7.1. Normative References 1433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1434 Requirement Levels", BCP 14, RFC 2119, March 1997. 1436 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1437 Networks (VPNs)", RFC 4364, February 2006. 1439 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1440 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1441 Protocol Specification (Revised)", RFC 4601, August 2006. 1443 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1444 "Bidirectional Protocol Independent Multicast (BIDIR- 1445 PIM)", RFC 5015, October 2007. 1447 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1448 "Label Distribution Protocol Extensions for Point-to- 1449 Multipoint and Multipoint-to-Multipoint Label Switched 1450 Paths", RFC 6388, November 2011. 1452 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 1453 VPNs", RFC 6513, February 2012. 1455 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1456 Encodings and Procedures for Multicast in MPLS/BGP IP 1457 VPNs", RFC 6514, February 2012. 1459 [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, 1460 "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 1461 6625, May 2012. 1463 7.2. Informative References 1465 [BGP-ERROR] 1466 Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 1467 "Revised Error Handling for BGP UPDATE Messages", 1468 internet-draft draft-ietf-idr-error-handling-18, December 1469 2014. 1471 [MVPN-BIDIR-IR] 1472 Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating 1473 'Partial Mesh of MP2MP P-Tunnels' with Ingress 1474 Replication", internet-draft draft-ietf-l3vpn-mvpn-bidir- 1475 ingress-replication-01, July 2014. 1477 [MVPN-XNET] 1478 Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP 1479 MPLS VPNs", internet-draft draft-ietf-l3vpn-mvpn-extranet- 1480 05, July 2014. 1482 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1483 Label Assignment and Context-Specific Label Space", RFC 1484 5331, August 2008. 1486 [RFC6517] Morin, T., Niven-Jenkins, B., Kamite, Y., Zhang, R., 1487 Leymann, N., and N. Bitar, "Mandatory Features in a Layer 1488 3 Multicast BGP/MPLS VPN Solution", RFC 6517, February 1489 2012. 1491 Authors' Addresses 1493 Eric C. Rosen 1494 Juniper Networks, Inc. 1495 10 Technology Park Drive 1496 Westford, Massachusetts 01886 1497 US 1499 Email: erosen@juniper.net 1501 IJsbrand Wijnands 1502 Cisco Systems, Inc. 1503 De kleetlaan 6a 1504 Diegem 1831 1505 BE 1507 Email: ice@cisco.com 1509 Yiqun Cai 1510 Microsoft 1511 1065 La Avenida 1512 Mountain View, CA 94043 1513 US 1515 Email: yiqunc@microsoft.com 1517 Arjen Boers 1519 Email: arjen@boers.com