idnits 2.17.1 draft-ietf-bess-mvpn-bidir-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (March 23, 2015) is 3322 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: September 24, 2015 Y. Cai 7 Microsoft 8 A. Boers 9 March 23, 2015 11 MVPN: Using Bidirectional P-Tunnels 12 draft-ietf-bess-mvpn-bidir-04 14 Abstract 16 A set of prior RFCs specify procedures for supporting multicast in 17 BGP/MPLS IP VPNs. These procedures allow customer multicast data to 18 travel across a service provider's backbone network through a set of 19 multicast tunnels. The tunnels are advertised in certain BGP 20 multicast "auto-discovery" routes, by means of a BGP attribute known 21 as the "Provider Multicast Service Interface (PMSI) Tunnel 22 attribute". Encodings have been defined that allow the PMSI Tunnel 23 attribute to identify bidirectional (multipoint-to-multipoint) 24 multicast distribution trees. However, the prior RFCs do not provide 25 all the necessary procedures for using bidirectional tunnels to 26 support multicast VPNs. This document updates RFCs 6513, 6514 and 27 6625 by specifying those procedures. In particular, it specifies the 28 procedures for assigning customer multicast flows (unidirectional or 29 bidirectional) to specific bidirectional tunnels in the provider 30 backbone, for advertising such assignments, and for determining which 31 flows have been assigned to which tunnels. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 24, 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1.2.1. Bidirectional P-tunnel 71 Technologies . . . . . . . . . . . . . . . . . . . . 9 72 1.2.2. Reasons for Using Bidirectional 73 P-tunnels . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 15 81 3.1.1. BIDIR-PIM P-Tunnels . . . . . . . . . . . . . . . . . 15 82 3.1.2. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . . 16 83 3.2. Procedures Specific to the PMSI 84 Instantiation Method . . . . . . . . . . . . . . . . . . 16 85 3.2.1. Flat Partitioning . . . . . . . . . . . . . . . . . . 17 86 3.2.1.1. When an S-PMSI is a 'Match for 87 Transmission' . . . . . . . . . . . . . . . . . . 19 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' . . . . . . . . . . . . . . . . . . . 20 92 3.2.1.4. When an I-PMSI is a 'Match for 93 Reception . . . . . . . . . . . . . . . . . . . . 21 94 3.2.2. Hierarchical Partitioning . . . . . . . . . . . . . . 22 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' . . . . . . . . . . . . . . . . . . 25 101 3.2.2.4. When an S-PMSI is a 'Match for 102 Reception' . . . . . . . . . . . . . . . . . . . 26 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' . . . . . . . . . . . . . . . . . . 29 108 3.2.3.2. When an S-PMSI is a 'Match for 109 Reception' . . . . . . . . . . . . . . . . . . . 30 110 3.2.4. Minimal Feature Set for 111 Compliance . . . . . . . . . . . . . . . . . . . . . 30 112 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 113 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31 114 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 115 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 116 7.1. Normative References . . . . . . . . . . . . . . . . . . 31 117 7.2. Informative References . . . . . . . . . . . . . . . . . 32 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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, then 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 243 A C-flow that, in the VPN customer sites, travels along a 244 bidirectional multicast distribution tree. The term "C-BIDIR 245 flow" indicates that the customer's bidirectional tree has been 246 set up by BIDIR-PIM. 248 o RP 250 A "Rendezvous Point", as defined in [RFC4601]. 252 o C-RP 254 A Rendezvous Point whose address is in the customer's address 255 space. 257 o RPA 259 A "Rendezvous Point Address", as defined in [RFC5015]. 261 o C-RPA 263 An RPA in the customer's address space. 265 o P-RPA 267 An RPA in the Service Provider's address space 269 o Selective P-tunnel 271 A P-tunnel that is joined only by Provider Edge (PE) routers that 272 need to receive one or more of the C-flows that are traveling 273 through that P-tunnel. 275 o Inclusive P-tunnel 277 A P-tunnel that is joined by all PE routers that attach to sites 278 of a given MVPN. 280 o PMSI 282 Provider Multicast Service Interface. A PMSI is a conceptual 283 overlay on a Service Provider backbone, allowing a PE in a given 284 MVPN to multicast to other PEs in the MVPN. PMSIs are 285 instantiated by P-tunnels. 287 o I-PMSI 288 Inclusive PMSI. Traffic multicast by a PE on an I-PMSI is 289 received by all other PEs in the MVPN. I-PMSIs are instantiated 290 by Inclusive P-tunnels. 292 o S-PMSI 294 Selective PMSI. Traffic multicast by a PE on an S-PMSI is 295 received by some (but not necessarily all) of the other PEs in the 296 MVPN. S-PMSIs are instantiated by Selective P-tunnels. 298 o Intra-AS I-PMSI A-D route 300 Intra Autonomous System Inclusive Provider Multicast Service 301 Interface Auto-Discovery route. Carried in BGP Update messages, 302 these routes can be used to advertise the use of Inclusive 303 P-tunnels. See [RFC6514] section 4.1. 305 o S-PMSI A-D route 307 Selective Provider Multicast Service Interface Auto-Discovery 308 route. Carried in BGP Update messages, these routes are used to 309 advertise the fact that a particular C-flow or a particular set of 310 C-flows is bound to (i.e., is traveling through) a particular 311 P-tunnel. See [RFC6514] section 4.3. 313 o (C-S,C-G) S-PMSI A-D route 315 An S-PMSI A-D route whose NLRI ("Network Layer Reachability 316 Information") contains C-S in its "Multicast Source" field and C-G 317 in its "Multicast Group" field. 319 o (C-*,C-G) S-PMSI A-D route 321 An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its 322 "Multicast Source" field and C-G in its "Multicast Group" field. 323 See [RFC6625]. 325 o (C-*,C-G-BIDIR) S-PMSI A-D route 327 An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its 328 "Multicast Source" field and C-G-BIDIR in its "Multicast Group" 329 field. See [RFC6625]. 331 o (C-*,C-*) S-PMSI A-D route 333 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 334 "Multicast Source" field and the wildcard C-* in its "Multicast 335 Group" field. See [RFC6625]. 337 o (C-*,C-*) S-PMSI A-D route 339 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 340 "Multicast Source" field and the wildcard C-* in its "Multicast 341 Group" field. See [RFC6625]. 343 o (C-*,C-*-BIDIR) S-PMSI A-D route 345 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 346 "Multicast Source" field and the wildcard "C-*-BIDIR" in its 347 "Multicast Group" field. See Section 2 of this document. 349 o (C-S,C-*) S-PMSI A-D route 351 An S-PMSI A-D route whose NLRI contains C-S in its "Multicast 352 Source" field and the wildcard C-* in its "Multicast Group" field. 353 See [RFC6625]. 355 o Wildcard S-PMSI A-D route 357 A (C-*,C-G) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route, or 358 a (C-S,C-*) S-PMSI A-D route, or a (C-*,C-*-BIDIR) S-PMSI A-D 359 route. 361 o PTA 363 PMSI Tunnel attribute, a BGP attribute that identifies a P-tunnel. 364 See [RFC6514] section 8. 366 The terminology used for categorizing S-PMSI A-D routes will also be 367 used for categorizing the S-PMSIs advertised by those routes. E.g., 368 the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route will be known 369 as a "(C-*,C-G) S-PMSI". 371 Familiarity with multicast concepts and terminology [RFC4601] is also 372 presupposed. 374 This specification uses the terms "match for transmission" and "match 375 for reception" as they are defined in [RFC6625]. When it is clear 376 from the context whether we are talking of transmission or reception, 377 we will sometimes talk simply of a C-flow "matching" an I-PMSI or 378 S-PMSI A-D route. 380 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 381 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 382 document, when and only when appearing in all caps, are to be 383 interpreted as described in [RFC2119]. 385 1.2. Overview 387 The base documents for MVPN ([RFC6513], [RFC6514]) define a "PMSI 388 Tunnel attribute" (PTA). This is a BGP Path Attribute that may be 389 attached to the BGP "I-PMSI A-D routes" and "S-PMSI A-D routes" that 390 are defined in those documents. The base documents define the way in 391 which the identifier of a bidirectional P-tunnel is to be encoded in 392 the PTA. However, those documents do not contain the full set of 393 specifications governing the use of bidirectional P-tunnels; rather, 394 those documents declare the full set of specifications for using 395 bidirectional P-tunnels to be outside their scope. Similarly, the 396 use of bidirectional P-tunnels advertised in wildcard S-PMSI A-D 397 routes is declared by [RFC6625] to be "out of scope." 399 This document provides the specifications governing the use of 400 bidirectional P-tunnels to provide MVPN support. This includes the 401 procedures for assigning C-flows to specific bidirectional P-tunnels, 402 for advertising the fact that a particular C-flow has been assigned 403 to a particular bidirectional P-tunnel, and for determining the 404 bidirectional P-tunnel on which a given C-flow may be expected. 406 The C-flows carried on bidirectional P-tunnels may themselves be 407 either unidirectional or bidirectional. Procedures are provided for 408 both cases. 410 This document does not specify any new data encapsulations for 411 bidirectional P-tunnels. Section 12 ("Encapsulations") of [RFC6513] 412 applies unchanged. 414 With regard to the procedures for using bidirectional P-tunnels to 415 instantiate PMSIs, if there is any conflict between the procedures 416 specified in this document and the procedures of [RFC6513], 417 [RFC6514], or [RFC6625], the procedures of this document take 418 precedence. 420 The use of bidirectional P-tunnels to support extranets [MVPN-XNET] 421 is outside the scope of this document. The use of bidirectional 422 P-tunnels as "segmented P-tunnels" (see [RFC6513] section 8 and 423 various sections of [RFC6514]) is also outside the scope of this 424 document. 426 1.2.1. Bidirectional P-tunnel Technologies 428 This document supports two different technologies for creating and 429 maintaining bidirectional P-tunnels: 431 o Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that 432 are created through the use of the Label Distribution Protocol 433 (LDP) Multipoint-to-Multipoint extensions [RFC6388]. 435 o Multicast distribution trees that are created through the use of 436 BIDIR-PIM [RFC5015]. 438 Other bidirectional tunnel technologies are outside the scope of this 439 document. 441 1.2.2. Reasons for Using Bidirectional P-tunnels 443 Bidirectional P-tunnels can be used to instantiate I-PMSIs and/or 444 S-PMSIs. 446 An SP may decide to use bidirectional P-tunnels to instantiate 447 certain I-PMSIs and/or S-PMSIs in order to provide its customers with 448 C-BIDIR support, using the "Partitioned Set of PEs" technique 449 discussed in [RFC6513] section 11.2 and [RFC6517] section 3.6. This 450 technique can be used whether the C-BIDIR flows are being carried on 451 an I-PMSI or an S-PMSI. 453 Even if an SP does not need to provide C-BIDIR support, it may still 454 decide to use bidirectional P-tunnels, in order to save state in the 455 network's transit nodes. For example, if an MVPN has n PEs attached 456 to sites with multicast sources, and there is an I-PMSI for that 457 MVPN, instantiating the I-PMSI with unidirectional P-tunnels (i.e., 458 with P2MP multicast distribution trees) requires n multicast 459 distribution trees, each one rooted at a different PE. If the I-PMSI 460 is instantiated by a bidirectional P-tunnel, a single multicast 461 distribution tree can be used, assuming appropriate support by the 462 provisioning system. 464 An SP may decide to use bidirectional P-tunnels for either or both of 465 these reasons. Note that even if the reason for using bidirectional 466 P-tunnels is to provide C-BIDIR support, the same P-tunnels can also 467 be used to carry unidirectional C-flows, if that is the choice of the 468 SP. 470 These two reasons for using bidirectional P-tunnels may appear to be 471 somewhat in conflict with each other, since (as will be seen in 472 subsequent sections), the use of bidirectional P-tunnels for C-BIDIR 473 support may require multiple bidirectional P-tunnels per VPN. Each 474 such P-tunnel is associated with a particular "distinguished PE", and 475 can only carry those C-BIDIR flows whose C-RPAs are reachable through 476 its distinguished PE. However, on platforms that support MPLS 477 upstream-assigned labels ([RFC5331]), "PE Distinguisher Labels" 478 ([RFC6513] Section 4 and [RFC6514] Section 8) can be used to 479 aggregate multiple bidirectional P-tunnels onto a single "outer" 480 bidirectional P-tunnel, thereby allowing one to provide C-BIDIR 481 support with minimal state at the transit nodes. 483 Since there are two fundamentally different reasons for using 484 bidirectional P-tunnels, and since many deployed router platforms do 485 not support upstream-assigned labels at the current time, this 486 document specifies several different methods of using bidirectional 487 P-tunnels to instantiate PMSIs. We refer to these as "PMSI 488 Instantiation Methods". The method or methods deployed by any 489 particular SP will depend upon that SP's goals and engineering 490 tradeoffs, and upon the set of platforms deployed by that SP. 492 The rules for using bidirectional P-tunnels in I-PMSI or S-PMSI A-D 493 routes are not exactly the same as the rules for using unidirectional 494 P-tunnels, and the rules are also different for the different PMSI 495 instantiation methods. Subsequent sections of this document specify 496 the rules in detail. 498 1.2.3. Knowledge of Group-to-RP and/or Group-to-RPA Mappings 500 If a VPN customer is making use of a particular "Any Source 501 Multicast" (ASM) group address, the PEs of that VPN generally need to 502 know the group-to-RP mappings that are used within the VPN. If a VPN 503 customer is making use of BIDIR-PIM group addresses, the PEs need to 504 know the group-to-RPA mappings that are used within the VPN. 505 Commonly, the PEs obtain this knowledge either through provisioning 506 or by participating in a dynamic "group-to-RP(A) mapping discovery 507 protocol" that runs within the VPN. However, the way in which this 508 knowledge is obtained is outside the scope of this document. 510 The PEs also need to be able to forward traffic towards the C-RPs 511 and/or C-RPAs, and to determine whether the next hop "interface" of 512 the route to a particular C-RP(A) is a VRF interface or a PMSI. This 513 is done by applying the procedures of [RFC6513] section 5.1. 515 1.2.4. PMSI Instantiation Methods 517 This document specifies three methods for using bidirectional 518 P-tunnels to instantiate PMSIs: the Flat Partitioned Method, the 519 Hierarchical Partitioned Method, and the Unpartitioned Method. 521 o Partitioned Methods 523 In the Partitioned Methods, a particular PMSI is instantiated by a 524 set of bidirectional P-tunnels. These P-tunnels may be aggregated 525 (as "inner" P-tunnels) into a single "outer" bidirectional 526 P-tunnel ("Hierarchical Partitioning"), or they may be 527 unaggregated ("Flat Partitioning"). Any PE that joins one of 528 these P-tunnels can transmit a packet on it, and the packet will 529 be received by all the other PEs that have joined the P-tunnel. 530 For each such P-tunnel (each "inner" P-tunnel, in the case of 531 Hierarchical Partitioning) there is one PE that is its 532 "distinguished PE". When a PE receives a packet from a given 533 P-tunnel, the PE can determine from the packet's encapsulation the 534 P-tunnel is has arrived on, and can thus infer the identity of the 535 distinguished PE associated with the packet. This association 536 plays an important role in the treatment of the packet, as 537 specified later on in this document. 539 The number of P-tunnels needed (the number of "inner" P-tunnels 540 needed, if Hierarchical Partitioning is used) depends upon a 541 number of factors that are described later in this document. 543 The Hierarchical Partitioned Method requires the use of upstream- 544 assigned MPLS labels ("PE Distinguisher Labels"), and requires the 545 use of the PE Distinguisher Labels attribute in BGP. The Flat 546 Partitioned Method requires neither of these. 548 The Partitioned Method (either flat or hierarchical) is a pre- 549 requisite for implementing the "Partitioned Sets of PEs" technique 550 of supporting C-BIDIR, as discussed in [RFC6513] section 11.2. 551 The Partitioned Method (either flat or hierarchical) is also a 552 pre-requisite for applying the "Discarding Packets from Wrong PE" 553 technique, discussed in [RFC6513] Section 9.1.1, to a PMSI that is 554 instantiated by a bidirectional P-tunnel. 556 The Flat Partitioned Method is a pre-requisite for implementing 557 the "Partial Mesh of MP2MP P-tunnels" technique for carrying 558 customer bidirectional (C-BIDIR) traffic, as discussed in 559 [RFC6513] Section 11.2.3. 561 The Hierarchical Partitioned Method is a pre-requisite for 562 implementing the "Using PE Distinguisher Labels" technique of 563 carrying customer bidirectional (C-BIDIR) traffic, as discussed in 564 [RFC6513] Section 11.2.2. 566 Note that a particular deployment may choose to use the 567 Partitioned Method for carrying the C-BIDIR traffic on 568 bidirectional P-tunnels, while carrying other traffic either on 569 unidirectional P-tunnels, or on bidirectional P-tunnels using the 570 Unpartitioned Method. Routers in a given deployment must be 571 provisioned to know which PMSI instantiation method to use for 572 which PMSIs. 574 There may be ways of implementing the Partitioned Method with 575 PMSIs that are instantiated by unidirectional P-tunnels. (See, 576 e.g., [MVPN-BIDIR-IR].) However, that is outside the scope of the 577 current document. 579 o Unpartitioned Method 581 In the Unpartitioned Method, a particular PMSI can be instantiated 582 by a single bidirectional P-tunnel. Any PE that joins the tunnel 583 can transmit a packet on it, and the packet will be received by 584 all the other PEs that have joined the tunnel. The receiving PEs 585 can determine the tunnel on which the packet was transmitted, but 586 they cannot determine which PE transmitted the packet, nor can 587 they associate the packet with any particular "distinguished PE". 589 When the Unpartitioned Method is used, this document does not 590 mandate that only one bidirectional P-tunnel be used to 591 instantiate each PMSI. It allows for the case where more than one 592 P-tunnel is used. In this case, the transmitting PEs will have a 593 choice of which such P-tunnel to use when transmitting, and the 594 receiving PEs must be prepared to receive from any of those 595 P-tunnels. The use of multiple P-tunnels in this case provides 596 additional robustness, but no additional functionality. 598 If bidirectional P-tunnels are being used to instantiate the PMSIs of 599 a given MVPN, one of these methods must be chosen for that MVPN. All 600 the PEs of that MVPN must be provisioned to know the method that is 601 being used for that MVPN. 603 I-PMSIs may be instantiated by bidirectional P-tunnels using either 604 the Partitioned (either Flat or Hierarchical) or the Unpartitioned 605 Method. The method used for a given MVPN is determined by 606 provisioning. It SHOULD be possible to provision this on a per-MVPN 607 basis, but all the VRFs of a single MVPN MUST be provisioned to use 608 the same method for the given MVPN's I-PMSI. 610 If a bidirectional P-tunnel is used to instantiate an S-PMSI 611 (including the case of a (C-*,C-*) S-PMSI), either the Partitioned 612 Method (either Flat or Hierarchical) or the Unpartitioned Method may 613 be used. The method used by a given VRF is determined by 614 provisioning. It is desirable to be able to provision this on a per- 615 MVPN basis. All the VRFs of a single MVPN MUST be provisioned to use 616 the same method for those of their S-PMSIs that are instantiated by 617 bidirectional P-tunnels. 619 If the Partitioned Method is used, all the VRFs of a single MVPN MUST 620 be provisioned to use the same variant of the Partitioned Method, 621 i.e., either they must all use the Flat Partitioned Method, or they 622 must all use the Hierarchical Partitioned Method. 624 It is valid to use the Unpartitioned Method to instantiate the 625 I-PMSIs, while using one of the Partitioned Methods to instantiate 626 the S-PMSIs. 628 It is valid to instantiate some S-PMSIs by unidirectional P-tunnels 629 and others by bidirectional P-tunnels. 631 The procedures for the use of bidirectional P-tunnels, specified in 632 subsequent sections of this document, depend on both the tunnel 633 technology and on the PMSI instantiation method. Note that this 634 document does not necessarily specify procedures for every possible 635 combination of tunnel technology and PMSI instantiation method. 637 2. The All BIDIR-PIM Wild Card 639 [RFC6514] specifies the method of encoding C-multicast source and 640 group addresses into the NLRI of certain BGP routes. [RFC6625] 641 extends that specification by allowing the source and/or group 642 address to be replaced by a wildcard. When an MVPN customer is using 643 BIDIR-PIM, it is useful to be able to advertise an S-PMSI A-D route 644 whose semantics are: "by default, all BIDIR-PIM C-multicast traffic 645 (within a given VPN) that has not been bound to any other P-tunnel is 646 bound to the bidirectional P-tunnel identified by the PTA of this 647 route". This can be especially useful if one is using a 648 bidirectional P-tunnel to carry the C-BIDIR flows, while using 649 unidirectional P-tunnels to carry other C-flows. To do this, it is 650 necessary to have a way to encode a (C-*,C-*) wildcard that is 651 restricted to BIDIR-PIM C-groups. 653 We therefore define a special value of the group wildcard, whose 654 meaning is "all BIDIR-PIM groups". The "BIDIR-PIM groups wildcard" 655 is encoded as a group field whose length is 8 bits and whose value is 656 zero. That is, the "multicast group length" field contains the value 657 0x08, and the "multicast group" field is a single octet containing 658 the value 0x00. (This encoding is distinct from the group wildcard 659 encoding defined in [RFC6625]). We will use the notation 660 (C-*,C-*-BIDIR) to refer to the "all BIDIR-PIM groups" wildcard. 662 3. Using Bidirectional P-Tunnels 664 A bidirectional P-tunnel may be advertised in the PTA of an Intra-AS 665 I-PMSI A-D route or in the PTA of an S-PMSI A-D route. The 666 advertisement of a bidirectional P-tunnel in the PTA of an Inter-AS 667 I-PMSI A-D route is outside the scope of this document. 669 3.1. Procedures Specific to the Tunneling Technology 671 This section discusses the procedures that are specific to a given 672 tunneling technology (BIDIR-PIM, or the MP2MP procedures of mLDP 673 ("Multipoint LDP")), but that are independent of the method 674 (Unpartitioned, Flat Partitioned, or Hierarchical Partitioned) used 675 to instantiate a PMSI. 677 3.1.1. BIDIR-PIM P-Tunnels 679 Each BIDIR-PIM P-Tunnel is identified by a unique P-group address 680 ([RFC6513], section 3.1). (The P-group address is called a 681 "P-Multicast Group" in [RFC6514]). Section 5 of [RFC6514] specifies 682 the way to identify a particular BIDIR-PIM P-tunnel in the PTA of an 683 I-PMSI or S-PMSI A-D route. 685 Ordinary BIDIR-PIM procedures are used to set up the BIDIR-PIM 686 P-tunnels. A BIDIR-PIM P-group address is always associated with a 687 unique "Rendezvous Point Address" (RPA) in the SP's address space. 688 We will refer to this as the "P-RPA". Every PE needing to join a 689 particular BIDIR-PIM P-tunnel must be able to determine the P-RPA 690 that corresponds to the P-tunnel's P-group address. To construct the 691 P-tunnel, PIM Join/Prune messages are sent along the path from the PE 692 to the P-RPA. Any P routers along that path must also be able to 693 determine the P-RPA, so that they too can send PIM Join/Prune 694 messages towards it. The method of mapping a P-group address to an 695 RPA may be static configuration, or some automated means of RPA 696 discovery that is outside the scope of this specification. 698 If a BIDIR-PIM P-tunnel is used to instantiate an I-PMSI or an 699 S-PMSI, it is RECOMMENDED that the path from each PE in the tunnel to 700 the RPA consist entirely of point-to-point links. On a point-to- 701 point link, there is no ambiguity in determining which router is 702 upstream towards a particular RPA, so the BIDIR-PIM "Designated 703 Forwarder Election" is very quick and simple. Use of a BIDIR-PIM 704 P-tunnel containing multiaccess links is possible, but considerably 705 more complex. 707 The use of BIDIR-PIM P-tunnels to support the Hierarchical 708 Partitioned Method is outside the scope of this document. 710 When the PTA of an Intra-AS I-PMSI A-D route or an S-PMSI A-D route 711 identifies a BIDIR-PIM tunnel, the originator of the route SHOULD NOT 712 include a PE Distinguisher Labels attribute. If it does, that 713 attribute MUST be ignored. When we say the attribute is "ignored", 714 we do not mean that its normal BGP processing is not done, but that 715 the attribute has no effect on the data plane. It MUST however be 716 treated by BGP as if it were an unsupported optional transitive 717 attribute. (PE Distinguisher Labels are used for the Hierarchical 718 Partitioning Method, but this document does not provide support for 719 the Hierarchical Partitioning Method with BIDIR-PIM P-tunnels.) 721 3.1.2. MP2MP LSPs 723 Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding 724 Equivalence Class) element" [RFC6388]. The FEC element contains the 725 IP address of the root node, followed by an opaque value that 726 identifies the MP2MP LSP uniquely in the context of the root node's 727 IP address. This opaque value may be configured or autogenerated; 728 there is no need for different root nodes to use the same opaque 729 value for a given MVPN. 731 The mLDP specification supports the use of several different ways of 732 constructing the tunnel identifiers. The current specification does 733 not place any restriction on the type or types of tunnel identifier 734 that is used in a given deployment. A given implementation is not 735 expected to be able to advertise (in the PTAs of I-PMSI or S-PMSI A-D 736 routes) tunnel identifiers of every possible type. However, an 737 implementation SHOULD be able to accept and properly process a PTA 738 that uses any legal type of tunnel identifier. 740 Section 5 of [RFC6514] specifies the way to identify a particular 741 MP2MP P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route. 743 Ordinary mLDP procedures for MP2MP LSPs are used to set up the MP2MP 744 LSP. 746 3.2. Procedures Specific to the PMSI Instantiation Method 748 When either the Flat Partitioned Method or the Hierarchical 749 Partitioned Method is used to implement the "Partitioned Sets of PEs" 750 method of supporting C-BIDIR, as discussed in section 11.2 of 751 [RFC6513] and section 3.6 of [RFC6517], a C-BIDIR flow MUST be 752 carried only on an I-PMSI or on a (C-*,C-G-BIDIR), (C-*,C-*-BIDIR), 753 or (C-*,C-*) S-PMSI. A PE MUST NOT originate any (C-S,C-G-BIDIR) 754 S-PMSI A-D routes. (Though it may of course originate (C-S,C-G) 755 S-PMSI A-D routes for C-G's that are not C-BIDIR groups.) Packets of 756 a C-BIDIR flow MUST NOT be carried on a (C-S,C-*) S-PMSI. 758 Section 3.2.1 and Section 3.2.2 specify additional details of the two 759 Partitioned Methods. 761 3.2.1. Flat Partitioning 763 The procedures of this section and its sub-sections apply when (and 764 only when) the Flat Partitioned Method is used. This method is 765 introduced in [RFC6513] Section 11.2.3, where it is called "Partial 766 Mesh of MP2MP P-tunnels". This method can be used with MP2MP LSPs or 767 with BIDIR-PIM P-tunnels. 769 When a PE originates an I-PMSI or S-PMSI A-D route whose PTA 770 specifies a bidirectional P-tunnel, the PE MUST be the root node of 771 the specified P-tunnel. 773 If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a 774 distinct P-group address. The PE advertising the tunnel will be 775 considered to be the root node of the tunnel. Note that this creates 776 a unique mapping from P-group address to root node. The assignment 777 of P-group addresses to MVPNs is by provisioning. 779 If MP2MP LSPs are used, each P-tunnel MUST have a distinct MP2MP FEC 780 (i.e., distinct combination of root node and opaque value). The PE 781 advertising the tunnel MUST be the same PE identified in the root 782 node field of the MP2MP FEC that is encoded in the PTA. 784 It follows that two different PEs may not advertise the same 785 bidirectional P-tunnel. Any PE that receives a packet from the 786 P-tunnel can infer the identity of the P-tunnel from the packet's 787 encapsulation. Once the identity of the P-tunnel is known, the root 788 node of the P-tunnel is also known. The root node of the P-tunnel on 789 which the packet arrived is treated as the "distinguished PE" for 790 that packet. 792 The Flat Partitioned Method does not use upstream-assigned labels in 793 the data plane, and hence does not use the BGP PE Distinguisher 794 Labels attribute. When this method is used, I-PMSI and/or S-PMSI A-D 795 routes SHOULD NOT contain a PE Distinguisher Labels attribute; if 796 such an attribute is present in a received I-PMSI or S-PMSI A-D 797 route, it MUST be ignored. (When we say the attribute is "ignored", 798 we do not mean that its normal BGP processing is not done, but that 799 the attribute has no effect on the data plane. It MUST however be 800 treated by BGP as if it were an unsupported optional transitive 801 attribute.) 803 When the Flat Partitioned Method is used to instantiate the I-PMSIs 804 of a given MVPN, every PE in that MVPN that originates an Intra-AS 805 I-PMSI A-D route MUST include a PTA that specifies a bidirectional 806 P-tunnel. If the intention is to carry C-BIDIR traffic on the 807 I-PMSI, a PE MUST originate an Intra-AS I-PMSI A-D route if one of 808 its VRF interfaces is the next hop interface on its best path to the 809 C-RPA of any bidirectional C-group of the MVPN. 811 When the Flat Partitioned Method is used to instantiate a (C-*,C-*) 812 S-PMSI, a (C-*,C-*-BIDIR) S-PMSI, or a (C-*,C-G-BIDIR) S-PMSI, a PE 813 that originates the corresponding S-PMSI A-D route MUST include in 814 that route a PTA specifying a bidirectional P-tunnel. Per the 815 procedures of [RFC6513] and [RFC6514], a PE will originate such an 816 S-PMSI A-D route only if one of the PE's VRF interfaces is the next 817 hop interface of the PE's best path to the C-RPA of a C-BIDIR group 818 that is to be carried on the specified S-PMSI. 820 PMSIs that are instantiated via the Flat Partitioned Method may carry 821 customer bidirectional traffic AND customer unidirectional traffic. 822 The rules of Section 3.2.1.1 and Section 3.2.1.2 determine when a 823 given customer multicast packet is a match for transmission to a 824 given PMSI. However, if the "Partitioned Set of PEs" method of 825 supporting C-BIDIR traffic is being used for a given MVPN, the PEs 826 must be provisioned in such a way that packets from a C-BIDIR flow of 827 that MVPN never match any PMSI that is not instantiated by a 828 bidirectional P-tunnel. (For example, if the given MVPN's (C-*,C-*) 829 S-PMSI were not instantiated by a bidirectional P-tunnel, one could 830 meet this requirement by carrying all C-BIDIR traffic of that MVPN on 831 a (C-*,C-*-BIDIR) S-PMSI.) 833 When a PE receives a customer multicast data packet from a 834 bidirectional P-tunnel, it associates that packet with a 835 "distinguished PE". The distinguished PE for a given packet is the 836 root node of the tunnel from which the packet is received. The rules 837 of Section 3.2.1.1 and Section 3.2.1.2 ensure that: 839 o If the received packet is part of a unidirectional C-flow, its 840 "distinguished PE" is the PE that transmitted the packet onto the 841 P-tunnel. 843 o If the received packet is part of a bidirectional C-flow, its 844 "distinguished PE" is not necessarily the PE that transmitted it, 845 but rather the transmitter's "upstream PE" for the C-RPA of the 846 bidirectional C-group. 848 The rules of Section 3.2.1.3 and Section 3.2.1.4 allow the receiving 849 PEs to determine the expected distinguished PE for each C-flow, and 850 ensure that a packet will be discarded if its distinguished PE is not 851 the expected distinguished PE for the C-flow to which the packet 852 belongs. This prevents duplication of data for both bidirectional 853 and unidirectional C-flows. 855 3.2.1.1. When an S-PMSI is a 'Match for Transmission' 857 Suppose a given PE, say PE1, needs to transmit multicast data packets 858 of a particular C-flow. [RFC6625] Section 3.1 gives a four-step 859 algorithm for determining the S-PMSI A-D route, if any, that matches 860 that C-flow for transmission. 862 If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged; 863 the remainder of this section applies only to C-BIDIR flows. If a 864 C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 865 are given below: 867 o If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's 868 route to the C-RPA is via a VRF interface, then: 870 * If there is a (C-*,C-G-BIDIR) S-PMSI A-D route currently 871 originated by PE1, then the C-flow matches that route. 873 * Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route 874 currently originated by PE1, then the C-flow matches that 875 route. 877 * Otherwise, if there is a (C-*,C-*) S-PMSI A-D route currently 878 originated by PE1, then the C-flow matches that route. 880 o If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some 881 other PE, say PE2, then: 883 * If there is an installed (C-*,C-G-BIDIR) S-PMSI A-D route 884 originated by PE2, then the C-flow matches that route. 886 * Otherwise, if there is an installed (C-*,C-*-BIDIR) S-PMSI A-D 887 route originated by PE2, then the C-flow matches that route. 889 * Otherwise, if there is an installed (C-*,C-*) S-PMSI A-D route 890 originated by PE2, then the C-flow matches that route. 892 If there is an S-PMSI A-D route that matches a given C-flow, and if 893 PE1 needs to transmit packets of that C-flow or other PEs, then it 894 MUST transmit those packets on the bidirectional P-tunnel identified 895 in the PTA of the matching S-PMSI A-D route. 897 3.2.1.2. When an I-PMSI is a 'Match for Transmission' 899 Suppose a given PE, say PE1, needs to transmit packets of a given 900 C-flow (of a given MVPN) to other PEs, but according to the 901 conditions of Section 3.2.1.1 and/or [RFC6625] section 3.1, that 902 C-flow does not match any S-PMSI A-D route. Then the packets of the 903 C-flow need to be transmitted on the MVPN's I-PMSI. 905 If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the 906 C-flow MUST be transmitted is the one identified in the PTA of the 907 Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. 909 If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the 910 rules applied by PE1 are: 912 o If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's 913 route to the C-RPA is via a VRF interface, then if there is an 914 I-PMSI A-D route currently originated by PE1, then the C-flow MUST 915 be transmitted on the P-tunnel identified in the PTA of that 916 I-PMSI A-D route. 918 o If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some 919 other PE, say PE2, then if there is an installed I-PMSI A-D route 920 originated by PE2, the C-flow MUST be transmitted on the P-tunnel 921 identified in the PTA of that route. 923 If there is no I-PMSI A-D route meeting the above conditions, the 924 C-flow MUST NOT be transmitted. 926 3.2.1.3. When an S-PMSI is a 'Match for Reception' 928 Suppose a given PE, say PE1, needs to receive multicast data packets 929 of a particular C-flow. [RFC6625] Section 3.2 specifies procedures 930 for determining the S-PMSI A-D route, if any, that matches that 931 C-flow for reception. Those rules apply unchanged for C-flows that 932 are not BIDIR-PIM C-flows. The remainder of this section applies 933 only to C-BIDIR flows. 935 The rules of [RFC6625] Section 3.2.1 are not applicable to C-BIDIR 936 flows. The rules of [RFC6625] Section 3.2.2 are replaced by the 937 following rules. 939 Suppose PE1 needs to receive (C-*,C-G-BIDIR) traffic. Suppose also 940 that PE1 has determined that PE2 is the "upstream PE" [RFC6513] for 941 the C-RPA of C-G-BIDIR. Then: 943 o If PE1 is not the same as PE2, and PE1 has an installed 944 (C-*,C-G-BIDIR) S-PMSI A-D route originated by PE2, then 945 (C-*,C-G-BIDIR) matches this route. 947 o Otherwise, if PE1 is the same as PE2, and PE1 has currently 948 originated a (C-*,C-G-BIDIR) S-PMSI A-D route, then 949 (C-*,C-G-BIDIR) matches this route. 951 o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed 952 (C-*,C-*-BIDIR) S-PMSI A-D route originated by PE2, then 953 (C-*,C-G-BIDIR) matches this route. 955 o Otherwise, if PE1 is the same as PE2, and PE1 has currently 956 originated a (C-*,C-*-BIDIR) S-PMSI A-D route, then 957 (C-*,C-G-BIDIR) matches this route. 959 o Otherwise, if PE1 is not the same as PE2, and PE1 has an installed 960 (C-*,C-*) S-PMSI A-D route originated by PE2, then (C-*,C-G-BIDIR) 961 matches this route. 963 o Otherwise, if PE1 is the same as PE2, and PE1 has currently 964 originated a (C-*,C-*) S-PMSI A-D route, then (C-*,C-G-BIDIR) 965 matches this route. 967 If there is an S-PMSI A-D route matching (C-*,C-G-BIDIR), according 968 to these rules, the root node of that P-tunnel is considered to be 969 the "distinguished PE" for that (C-*,C-G-BIDIR) flow. If a 970 (C-*,C-G-BIDIR) packet is received on a P-tunnel whose root node is 971 not the distinguished PE for the C-flow, the packet MUST be 972 discarded. 974 3.2.1.4. When an I-PMSI is a 'Match for Reception 976 Suppose a given PE, say PE1, needs to receive packets of a given 977 C-flow (of a given MVPN) from another PE, but according to the 978 conditions of Section 3.2.1.3 and/or [RFC6625] section 3.2, that 979 C-flow does not match any S-PMSI A-D route. Then the packets of the 980 C-flow need to be received on the MVPN's I-PMSI. 982 If the C-flow is not a BIDIR-PIM C-flow, the rules for determining 983 the P-tunnel on which packets of the C-flow are expected are given in 984 [RFC6513]. The remainder of this section applies only to C-BIDIR 985 flows. 987 Suppose that PE1 needs to receive (C-*,C-G-BIDIR) traffic from other 988 PEs. Suppose also that PE1 has determined that PE2 is the "upstream 989 PE" [RFC6513] for the C-RPA of C-G-BIDIR. Then PE1 considers PE2 to 990 be the "distinguished PE" for (C-*,C-G-BIDIR). If PE1 has an 991 installed Intra-AS I-PMSI A-D route originated by PE2, PE1 will 992 expect to receive packets of the C-flow from the tunnel specified in 993 that route's PTA. (If all VRFs of the MVPN have been properly 994 provisioned to use the Flat Partitioned Method for the I-PMSI, the 995 PTA will specify a bidirectional P-tunnel.) Note that if PE1 is the 996 same as PE2, then the relevant Intra-AS I-PMSI A-D route is the one 997 currently originated by PE1. 999 If a (C-*,C-G-BIDIR) packet is received on a P-tunnel other than the 1000 expected one, packet MUST be discarded. 1002 3.2.2. Hierarchical Partitioning 1004 The procedures of this section and its sub-sections apply when (and 1005 only when) the Hierarchical Partitioned Method is used. This method 1006 is introduced in [RFC6513] Section 11.2.2. This document only 1007 provides procedures for using this method when using MP2MP LSPs as 1008 the P-tunnels. 1010 The Hierarchical Partitioned Method provides the same functionality 1011 as the Flat Partitioned Method, but requires a smaller amount of 1012 state to be maintained in the core of the network. However, it 1013 requires the use of upstream-assigned MPLS labels ("PE Distinguisher 1014 Labels"), which are not necessarily supported by all hardware 1015 platforms. The upstream-assigned labels are used to provide an LSP 1016 hierarchy, in which an "outer" MP2MP LSP carries multiple "inner" 1017 MP2MP LSPs. Transit routers along the path between PE routers then 1018 only need to maintain state for the outer MP2MP LSP. 1020 When this method is used to instantiate a particular PMSI, the 1021 bidirectional P-tunnel advertised in the PTA of the corresponding 1022 I-PMSI or S-PMSI A-D route is the "outer" P-tunnel. When a packet is 1023 received from a P-tunnel, the PE that receives it can infer the 1024 identity of the outer P-tunnel from the MPLS label that has risen to 1025 the top of the packet's label stack. However, the packet's 1026 "distinguished PE" is not necessarily the root node of the the outer 1027 P-tunnel. Rather, the identity of the packet's distinguished PE is 1028 inferred from the PE Distinguisher Label further down in the label 1029 stack. (See [RFC6513] Section 12.3.) The PE Distinguisher Label may 1030 be thought of as identifying an "inner" MP2MP LSP whose root is the 1031 PE corresponding to that label. 1033 In the context of a given MVPN, if it is desired to use the 1034 Hierarchical Partitioned Method to instantiate an I-PMSI, a (C-*,C-*) 1035 S-PMSI, or a (C-*,C-*-BIDIR) S-PMSI, the corresponding A-D routes 1036 MUST be originated by some of the PEs that attach to that MVPN. The 1037 PEs that are REQUIRED to originate these routes are those that 1038 satisfy one of the following conditions: 1040 o There is a C-BIDIR group for which the best path from the PE to 1041 the C-RPA of that C-group is via a VRF interface, or 1043 o The PE might have to transmit unidirectional customer multicast 1044 traffic on the PMSI identified in the route (of course this 1045 condition does not apply to (C-*,C-*-BIDIR) or to (C-*,C-G-BIDIR) 1046 S-PMSIs). 1048 o The PE is the root node of the MP2MP LSP that is used to 1049 instantiate the PMSI. 1051 When the Hierarchical Partitioned method is used to instantiate a 1052 (C-*,C-G-BIDIR) S-PMSI, the corresponding (C-*,C-G-BIDIR) S-PMSI 1053 route MUST NOT be originated by a given PE unless either (a) that 1054 PE's best path to the C-RPA for C-G-BIDIR is via a VRF interface, or 1055 (b) the C-RPA is a C-address of the PE. Further, that PE MUST be the 1056 root node of the MP2MP LSP identified in the PTA of the S-PMSI A-D 1057 route. 1059 If any VRF of a given MVPN uses this method to instantiate an S-PMSI 1060 with a bidirectional P-tunnel, all VRFs of that MVPN must use this 1061 method. 1063 Suppose that for a given MVPN, the Hierarchical Partitioned Method is 1064 used to instantiate the I-PMSI. In general, more than one of the PEs 1065 in the MVPN will originate an Intra-AS I-PMSI A-D route for that 1066 MVPN. This document allows the PTAs of those routes to all specify 1067 the same MP2MP LSP as the "outer tunnel". However, it does not 1068 require that those PTAs all specify the same MP2MP LSP as the outer 1069 tunnel. By having all the PEs specify the same outer tunnel for the 1070 I-PMSI, one can minimize the amount of state in the transit nodes. 1071 By allowing them to specify different outer tunnels, one uses more 1072 state, but may increase the robustness of the system. 1074 The considerations of the previous paragraph apply as well when the 1075 Hierarchical Partitioned Method is used to instantiate an S-PMSI. 1077 3.2.2.1. Advertisement of PE Distinguisher Labels 1079 A PE Distinguisher Label is an upstream-assigned MPLS label [RFC5331] 1080 that can be used, in the context of a MP2MP LSP, to denote a 1081 particular PE that either has joined or may in the future join that 1082 LSP. 1084 In order to use upstream-assigned MPLS labels in the context of an 1085 "outer" MP2MP LSP, there must be a convention that identifies a 1086 particular router as the router that is responsible for allocating 1087 the labels and for advertising the labels to the PEs that may join 1088 the MP2MP LSP. This document REQUIRES that the PE Distinguisher 1089 Labels used in the context of a given MP2MP LSP be allocated and 1090 advertised by the router that is the root node of the LSP. 1092 This convention accords with the rules of section 7 of [RFC5331]. 1093 Note that according to section 7 of [RFC5331], upstream-assigned 1094 labels are unique in the context of the IP address of the root node; 1095 if two MP2MP LSPs have the same root node IP address, the upstream- 1096 assigned labels used within the two LSPs come from the same label 1097 space. 1099 This document assumes that the root node address of an MP2MP LSP is 1100 an IP address that is uniquely assigned to the node. The use of an 1101 "anycast address" as the root node address is outside the scope of 1102 this document. 1104 A PE Distinguisher Labels attribute SHOULD NOT be attached to an 1105 I-PMSI or S-PMSI A-D route unless that route also contains a PTA that 1106 specifies an MP2MP LSP. (While PE Distinguisher Labels could in 1107 theory also be used if the PTA specifies a BIDIR-PIM P-tunnel, such 1108 use is outside the scope of this document.) 1110 The PE Distinguisher Labels attribute specifies a set of bindings. Within a given PE Distinguisher Labels 1112 attribute, each such IP address MUST appear at most once, and each 1113 MPLS label MUST appear only once. Otherwise the attribute is 1114 considered to be malformed, and the "treat-as-withdraw" error- 1115 handling approach described in Section 2 of [BGP-ERROR] MUST be used. 1117 When a PE Distinguisher Labels attribute is included in a given 1118 I-PMSI or S-PMSI A-D route, it MUST assign a label to the IP address 1119 of each of the following PEs: 1121 o The root node of the MP2MP LSP identified in the PTA of the route, 1123 o Any PE that is possibly the ingress PE for a C-RPA of any C-BIDIR 1124 group. 1126 o Any PE that may need to transmit non-C-BIDIR traffic on the MP2MP 1127 LSP identified in the PTA of the route. 1129 One simple way to meet these requirements is to assign a PE 1130 Distinguisher label to every PE that has originated an Intra-AS 1131 I-PMSI A-D route. 1133 3.2.2.2. When an S-PMSI is a 'Match for Transmission' 1135 Suppose a given PE, say PE1, needs to transmit multicast data packets 1136 of a particular C-flow. [RFC6625] Section 3.1 gives a four-step 1137 algorithm for determining the S-PMSI A-D route, if any, that matches 1138 that C-flow for transmission. 1140 If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged. 1141 If there is a matching S-PMSI A-D route, the P-tunnel on which the 1142 C-flow MUST be transmitted is the one identified in the PTA of the 1143 matching route. Each packet of the C-flow MUST carry the PE 1144 Distinguisher Label assigned by the root node of that P-tunnel to the 1145 IP address of PE1. See section 12.3 of [RFC6513] for encapsulation 1146 details. 1148 The remainder of this section applies only to C-BIDIR flows. If a 1149 C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 1150 are the same as the rules given in Section 3.2.1.1. 1152 If there is a matching S-PMSI A-D route, PE1 MUST transmit the C-flow 1153 on the P-tunnel identified in its PTA. Suppose PE1 has determined 1154 that PE2 is the upstream PE for the C-RPA of the given C-flow. In 1155 constructing the packet's MPLS label stack, PE1 must use the PE 1156 Distinguisher Label that was assigned by the P-tunnel's root node to 1157 the IP address of "PE2", not the label assigned to the IP address of 1158 "PE1" (unless, of course, PE1 is the same as PE2). See section 12.3 1159 of [RFC6513] for encapsulation details. Note that the root of the 1160 P-tunnel might be a PE other than PE1 or PE2. 1162 3.2.2.3. When an I-PMSI is a 'Match for Transmission' 1164 Suppose a given PE, say PE1, needs to transmit packets of a given 1165 C-flow (of a given MVPN) to other PEs, but according to the 1166 conditions of Section 3.2.2.2 and/or [RFC6625] section 3.1, that 1167 C-flow does not match any S-PMSI A-D route. Then the packets of the 1168 C-flow need to be transmitted on the MVPN's I-PMSI. 1170 If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the 1171 C-flow MUST be transmitted is the one identified in the PTA of the 1172 Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. Each 1173 packet of the C-flow MUST carry the PE Distinguisher Label assigned 1174 by the root node of that P-tunnel to the IP address of PE1. 1176 If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the 1177 rules as applied by PE1 are the same as those given in 1178 Section 3.2.1.2. 1180 If there is a matching I-PMSI A-D route, PE1 MUST transmit the C-flow 1181 on the P-tunnel identified in its PTA. In constructing the packet's 1182 MPLS label stack, it must use the PE Distinguisher Label that was 1183 assigned by the P-tunnel's root node to the IP address of "PE2", not 1184 the label assigned to the IP address of "PE1" (unless, of course, PE1 1185 is the same as PE2). (Section 3.2.1.2 specifies the difference 1186 between PE1 and PE2.) See section 12.3 of [RFC6513] for 1187 encapsulation details. Note that the root of the P-tunnel might be a 1188 PE other than PE1 or PE2. 1190 If, for a packet of a particular C-flow, there is no S-PMSI A-D route 1191 or I-PMSI A-D route that is a match for transmission, the packet MUST 1192 NOT be transmitted. 1194 3.2.2.4. When an S-PMSI is a 'Match for Reception' 1196 Suppose a given PE, say PE1, needs to receive multicast data packets 1197 of a particular C-flow. [RFC6625] Section 3.2 specifies procedures 1198 for determining the S-PMSI A-D route, if any, that matches that 1199 C-flow for reception. Those rules require that the matching S-PMSI 1200 A-D route has been originated by the upstream PE for the C-flow. The 1201 rules are modified in this section, as follows: 1203 Consider a particular C-flow. Suppose either: 1205 o the C-flow is unidirectional, and PE1 determines that its upstream 1206 PE is PE2, or 1208 o the C-flow is bidirectional, and PE1 determines that the upstream 1209 PE for its C-RPA is PE2 1211 Then the C-flow may match an installed S-PMSI A-D route that was not 1212 originated by PE2, as long as: 1214 1. the PTA of that A-D route identifies an MP2MP LSP, and 1216 2. there is an installed S-PMSI A-D route originated by the root 1217 node of that LSP, or PE1 itself is the root node of the LSP and 1218 there is a currently originated S-PMSI A-D route from PE1 whose 1219 PTA identifies that LSP, and 1221 3. the latter S-PMSI A-D route (the one identified in 2 just above) 1222 contains a PE Distinguisher Labels attribute that assigned an 1223 MPLS label to the IP address of PE2. 1225 However, a bidirectional C-flow never matches an S-PMSI A-D route 1226 whose NLRI contains (C-S,C-G). 1228 If a multicast data packet is received over a matching P-tunnel, but 1229 does not carry the value of the PE Distinguisher Label that has been 1230 assigned to the upstream PE for its C-flow, then the packet MUST be 1231 discarded. 1233 3.2.2.5. When an I-PMSI is a 'Match for Reception' 1235 If a PE needs to receive packets of a given C-flow (of a given MVPN) 1236 from another PE, and if, according to the conditions of 1237 Section 3.2.2.4, that C-flow does not match any S-PMSI A-D route, 1238 then the packets of the C-flow need to be received on the MVPN's 1239 I-PMSI. The P-tunnel on which the packets are expected to arrive is 1240 determined by the Intra-AS I-PMSI A-D route originated by the 1241 "distinguished PE" for the given C-flow. The PTA of that route 1242 specifies the "outer P-tunnel", and thus determines the top label 1243 that packets of that C-flow will be carrying when received. A PE 1244 that needs to receive packets of a given C-flow must determine the 1245 expected value of the second label for packets of that C-flow. This 1246 will be the value of a PE Distinguisher Label, taken from the PE 1247 Distinguisher Labels attribute of the Intra-AS I-PMSI A-D route of 1248 the root node of that outer tunnel. The expected value of the second 1249 label on received packets (corresponding to the "inner tunnel") of a 1250 given C-flow is determined according to the following rules. 1252 First, the "distinguished PE" for the C-flow is determined: 1254 o If the C-flow is not a BIDIR-PIM C-flow, the "distinguished PE" 1255 for the C-flow is its "upstream PE", as determined by the rules of 1256 [RFC6513]. 1258 o If the C-flow is a BIDIR-PIM C-flow, the "distinguished PE" for 1259 the C-flow is its "upstream PE" of the C-flow's C-RPA, as 1260 determined by the rules of [RFC6513]. 1262 The expected value of the second label is the value that the root PE 1263 of the outer tunnel has assigned, in the PE Distinguisher Labels 1264 attribute of its Intra-AS I-PMSI A-D route, to the IP address of the 1265 "distinguished PE". 1267 Packets addressed to C-G that arrive on other than the expected inner 1268 and outer P-tunnels (i.e., that arrive with unexpected values of the 1269 top two labels) MUST be discarded. 1271 3.2.3. Unpartitioned 1273 When a particular MVPN uses the Unpartitioned Method of instantiating 1274 an I-PMSI with a bidirectional P-tunnel, it MUST be the case that at 1275 least one VRF of that MVPN originates an Intra-AS I-PMSI A-D route 1276 that includes a PTA specifying a bidirectional P-tunnel. The 1277 conditions under which an Intra-AS I-PMSI A-D route must be 1278 originated from a given VRF are as specified in [RFC6514]. This 1279 document allows all but one of such routes to omit the PTA. However, 1280 each such route MAY contain a PTA. If the PTA is present, it MUST 1281 specify a bidirectional P-tunnel. As specified in [RFC6513] and 1282 [RFC6514], every PE that imports such an Intra-AS I-PMSI A-D route 1283 into one of its VRFs MUST, if the route has a PTA, join the P-tunnel 1284 specified in the route's PTA. 1286 Packets received on any of these P-tunnels are treated as having been 1287 received over the I-PMSI. The disposition of a received packet MUST 1288 NOT depend upon the particular P-tunnel over which it has been 1289 received. 1291 When a PE needs to transmit a packet on such an I-PMSI, then if that 1292 PE advertised a P-tunnel in the PTA of an Intra-AS I-PMSI A-D route 1293 that it originated, the PE SHOULD transmit the on that P-tunnel. 1294 However, any PE that transmits a packet on the I-PMSI MAY transmit it 1295 on any of the P-tunnels advertised in any of the currently installed 1296 Intra-AS I-PMSI A-D routes for its VPN. 1298 This allows a single bidirectional P-tunnel to be used to instantiate 1299 the I-PMSI, but also allows the use of multiple bidirectional 1300 P-tunnels. There may be a robustness advantage in having multiple 1301 P-tunnels available for use, but the number of P-tunnels used does 1302 not impact the functionality in any way. If there are, e.g., two 1303 P-tunnels available, these procedures allow each P-tunnel to be 1304 advertised by a single PE, but they also allow each P-tunnel to be 1305 advertised by multiple PEs. Note that the PE advertising a given 1306 P-tunnel does not have to be the root node of the tunnel. The root 1307 node might not even be a PE router, and might not originate any BGP 1308 routes at all. 1310 In the Unpartitioned Method, packets received on the I-PMSI cannot be 1311 associated with a distinguished PE, so duplicate detection using the 1312 techniques of [RFC6513] section 9.1.1 is not possible; the techniques 1313 of [RFC6513] 9.1.2 or 9.1.3 would have to be used instead. Support 1314 for C-BIDIR using the "Partitioned set of PEs" technique ([RFC6513] 1315 section 11.2 and [RFC6517] section 3.6) is not possible when the 1316 Unpartitioned Method is used. If it is desired to use that technique 1317 to support C-BIDIR, but also to use the Unpartitioned Method to 1318 instantiate the I-PMSI, then all the C-BIDIR traffic would have to be 1319 carried on an S-PMSI, where the S-PMSI is instantiated using one of 1320 the Partitioned Methods. 1322 When a PE, say PE1, needs to transmit multicast data packets of a 1323 particular C-flow to other PEs, and PE1 does not have an S-PMSI that 1324 is a match for transmission for that C-flow (see Section 3.2.3.1), 1325 PE1 transmits the packets on one of the P-tunnel(s) that instantiates 1326 the I-PMSI. When a PE, say PE1, needs to receive multicast data 1327 packets of a particular C-flow from another PE, and PE1 does not have 1328 an S-PMSI that is a match for reception for that C-flow (see 1329 Section 3.2.3.2), PE1 expects to receive the packets on any of the 1330 P-tunnel(s) that instantiates the I-PMSI. 1332 When a particular MVPN uses the Unpartitioned Method to instantiate a 1333 (C-*,C-*) S-PMSI or a (C-*,C-*-BIDIR) S-PMSI using a bidirectional 1334 P-tunnel, the same conditions apply as when an I-PMSI is instantiated 1335 via the Unpartitioned Method. The only difference is that a PE need 1336 not join a P-tunnel that instantiates the S-PMSI unless that PE needs 1337 to receive multicast packets on the S-PMSI. 1339 When a particular MVPN uses bidirectional P-tunnels to instantiate 1340 other S-PMSIs, different S-PMSI A-D routes that do not contain 1341 (C-*,C-*) or (C-*,C-*-BIDIR), originated by the same or by different 1342 PEs, MAY have PTAs that identify the same bidirectional tunnel, and 1343 they MAY have PTAs that do not identify the same bidirectional 1344 tunnel. 1346 While the Unpartitioned Method MAY be used to instantiate an S-PMSI 1347 to which one or more C-BIDIR flows are bound, it must be noted that 1348 the "Partitioned Set of PEs" method discussed in [RFC6513] section 1349 11.2 and [RFC6517] section 3.6 cannot be supported using the 1350 Unpartitioned Method. C-BIDIR support would have to be provided by 1351 the procedures of [RFC6513] section 11.1. 1353 3.2.3.1. When an S-PMSI is a 'Match for Transmission' 1355 Suppose a PE needs to transmit multicast data packets of a particular 1356 customer C-flow. [RFC6625] Section 3.1 gives a four-step algorithm 1357 for determining the S-PMSI A-D route, if any, that matches that 1358 C-flow for transmission. When referring to that section, please 1359 recall that BIDIR-PIM groups are also "Any Source Multicast" (ASM) 1360 groups. 1362 When bidirectional P-tunnels are used in the Unpartitioned Method, 1363 the same algorithm applies, with one modification, when the PTA of an 1364 S-PMSI A-D route identifies a bidirectional P-tunnel. One additional 1365 step is added to the algorithm. This new step occurs before the 1366 fourth step of the algorithm, and is as follows: 1368 o Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route 1369 currently originated by PE1, and if C-G is a BIDIR group, the 1370 C-flow matches that route. 1372 When the Unpartitioned Method is used, the PE SHOULD transmit the 1373 C-flow on the P-tunnel advertised in the in the matching S-PMSI A-D 1374 route, but it MAY transmit the C-flow on any P-tunnel that is 1375 advertised in the PTA of any installed S-PMSI A-D route that contains 1376 the same (C-S,C-G) as the matching S-PMSI A-D route. 1378 3.2.3.2. When an S-PMSI is a 'Match for Reception' 1380 Suppose a PE needs to receive multicast data packets of a particular 1381 customer C-flow. [RFC6625] Section 3.2 specifies the procedures for 1382 determining the S-PMSI A-D route, if any, that advertised the 1383 P-tunnel on which the PE should expect to receive that C-flow. 1385 When bidirectional P-tunnels are used in the Unpartitioned Method, 1386 the same procedures apply, with one modification. 1388 The last paragraph of Section 3.2.2 of [RFC6625] begins: 1390 "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from 1391 PE2, but PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, 1392 then (C-*,C-G) matches the (C-*,C-*) route if one of the following 1393 conditions holds:" 1395 This is changed to: 1397 "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from 1398 PE2, but C-G is a BIDIR group and PE1 has an installed 1399 (C-*,C-*-BIDIR) S-PMSI A-D route, then (C-*,C-G) matches that 1400 route. Otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D 1401 route from PE2, then (C-*,C-G) matches the (C-*,C-*) route if one 1402 of the following conditions holds:" 1404 When the Unpartitioned Method is used, the PE MUST join the P-tunnel 1405 that is advertised in the matching S-PMSI A-D route, and MUST also 1406 join the P-tunnels that are advertised in other installed S-PMSI A-D 1407 routes that contain the same (C-S,C-G) as the matching S-PMSI A-D 1408 route. 1410 3.2.4. Minimal Feature Set for Compliance 1412 Implementation of bidirectional P-tunnels is OPTIONAL. If 1413 bidirectional P-tunnels are not implemented, the issue of compliance 1414 to this specification does not arise. However, for the case where 1415 bidirectional P-tunnels ARE implemented, this section specifies the 1416 minimal set of features that MUST be implemented in order to claim 1417 compliance to this specification. 1419 In order to be compliant with this specification, an implementation 1420 that provides bidirectional P-tunnels MUST support at least one of 1421 the two P-tunnel technologies mentioned in section Section 1.2.1. 1423 A PE that does not provide C-BIDIR support using the "partitioned set 1424 of PEs" method is deemed compliant to this specification if it 1425 supports the Unpartitioned Method, using either MP2MP LSPs or BIDIR- 1426 PIM multicast distribute trees as P-tunnels. 1428 A PE that does provide C-BIDIR support using the "partitioned set of 1429 PEs" method, MUST, at a minimum, be able to provide C-BIDIR support 1430 using the "Partial Mesh of MP2MP P-tunnels" variant of this method 1431 (see section 11.2 of [RFC6513]). An implementation will be deemed 1432 compliant to this minimum requirement if it can carry all of a VPN's 1433 C-BIDIR traffic on a (C-*,C-*-BIDIR) S-PMSI that is instantiated by a 1434 bidirectional P-tunnel, using the flat partitioned method. 1436 4. IANA Considerations 1438 This document has no actions for IANA. 1440 5. Security Considerations 1442 There are no additional security considerations beyond those of 1443 [RFC6513] and [RFC6514], or any that may apply to the particular 1444 protocol used to set up the bidirectional tunnels ([RFC5015], 1445 [RFC6388]). 1447 6. Acknowledgments 1449 The authors wish to thank Karthik Subramanian, Rajesh Sharma, and 1450 Apoorva Karan for their input. We also thank Yakov Rekhter for his 1451 valuable critique. 1453 Special thanks go to Jeffrey (Zhaohui) Zhang for his careful review, 1454 probing questions, and useful suggestions. 1456 7. References 1458 7.1. Normative References 1460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1461 Requirement Levels", BCP 14, RFC 2119, March 1997. 1463 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1464 Networks (VPNs)", RFC 4364, February 2006. 1466 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1467 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1468 Protocol Specification (Revised)", RFC 4601, August 2006. 1470 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1471 "Bidirectional Protocol Independent Multicast (BIDIR- 1472 PIM)", RFC 5015, October 2007. 1474 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1475 "Label Distribution Protocol Extensions for Point-to- 1476 Multipoint and Multipoint-to-Multipoint Label Switched 1477 Paths", RFC 6388, November 2011. 1479 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 1480 VPNs", RFC 6513, February 2012. 1482 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1483 Encodings and Procedures for Multicast in MPLS/BGP IP 1484 VPNs", RFC 6514, February 2012. 1486 [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, 1487 "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 1488 6625, May 2012. 1490 7.2. Informative References 1492 [BGP-ERROR] 1493 Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 1494 "Revised Error Handling for BGP UPDATE Messages", 1495 internet-draft draft-ietf-idr-error-handling-18, December 1496 2014. 1498 [MVPN-BIDIR-IR] 1499 Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating 1500 'Partial Mesh of MP2MP P-Tunnels' with Ingress 1501 Replication", internet-draft draft-ietf-l3vpn-mvpn-bidir- 1502 ingress-replication-01, July 2014. 1504 [MVPN-XNET] 1505 Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP 1506 MPLS VPNs", internet-draft draft-ietf-l3vpn-mvpn-extranet- 1507 05, July 2014. 1509 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1510 Label Assignment and Context-Specific Label Space", RFC 1511 5331, August 2008. 1513 [RFC6517] Morin, T., Niven-Jenkins, B., Kamite, Y., Zhang, R., 1514 Leymann, N., and N. Bitar, "Mandatory Features in a Layer 1515 3 Multicast BGP/MPLS VPN Solution", RFC 6517, February 1516 2012. 1518 Authors' Addresses 1520 Eric C. Rosen 1521 Juniper Networks, Inc. 1522 10 Technology Park Drive 1523 Westford, Massachusetts 01886 1524 US 1526 Email: erosen@juniper.net 1528 IJsbrand Wijnands 1529 Cisco Systems, Inc. 1530 De kleetlaan 6a 1531 Diegem 1831 1532 BE 1534 Email: ice@cisco.com 1536 Yiqun Cai 1537 Microsoft 1538 1065 La Avenida 1539 Mountain View, CA 94043 1540 US 1542 Email: yiqunc@microsoft.com 1544 Arjen Boers 1546 Email: arjen@boers.com