idnits 2.17.1 draft-ietf-bess-mvpn-bidir-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6514, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document updates RFC6625, but the header doesn't have an 'Updates:' line to match this. 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 (November 18, 2014) is 3447 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) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 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 (if approved) IJ. Wijnands 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: May 22, 2015 Y. Cai 7 Microsoft 8 A. Boers 10 November 18, 2014 12 MVPN: Using Bidirectional P-Tunnels 13 draft-ietf-bess-mvpn-bidir-00 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 and 6625 by 28 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 May 22, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . 10 76 1.2.4. PMSI Instantiation Methods . . . . . . . . . . . . . 11 77 2. The All BIDIR-PIM Wild Card . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . 15 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' . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . 20 95 3.2.2.1. Advertisement of PE 96 Distinguisher Labels . . . . . . . . . . . . . . 22 97 3.2.2.2. When an S-PMSI is a 'Match for 98 Transmission' . . . . . . . . . . . . . . . . . . 23 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' . . . . . . . . . . . . . . . . . . . 24 103 3.2.2.5. When an I-PMSI is a 'Match for 104 Reception' . . . . . . . . . . . . . . . . . . . 25 105 3.2.3. Unpartitioned . . . . . . . . . . . . . . . . . . . . 26 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' . . . . . . . . . . . . . . . . . . . 28 110 3.2.4. Minimal Feature Set for 111 Compliance . . . . . . . . . . . . . . . . . . . . . 29 112 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 113 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 114 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 115 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 116 7.1. Normative References . . . . . . . . . . . . . . . . . . 30 117 7.2. Informative References . . . . . . . . . . . . . . . . . 30 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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 LSP 162 An MPLS Label Switched Path. 164 o P2MP 166 Point-to-Multipoint. 168 o MP2MP 170 Multipoint-to-multipoint. 172 o Unidirectional 174 Adjective for a multicast distribution tree in which all traffic 175 travels downstream from the root of the tree. Traffic can enter a 176 unidirectional tree only at the root. A P2MP LSP is one type of 177 unidirectional tree. Multicast distribution trees set up by PIM- 178 SM [RFC4601] are also unidirectional trees. 179 Data traffic traveling along a unidirectional multicast 180 distribution tree is sometimes referred to in this document as 181 "unidirectional traffic". 183 o Bidirectional 185 Adjective for a multicast distribution tree in which traffic may 186 travel both upstream (towards the root) and downstream (away from 187 the root). Traffic may enter a bidirectional tree at any node. A 188 MP2MP LSP is one type of bidirectional tree. Multicast 189 distribution trees created by BIDIR-PIM [RFC5015] are also 190 bidirectional trees. 192 Data traffic traveling along a bidirectional multicast 193 distribution tree is sometimes referred to in this document as 194 "bidirectional traffic". 196 o P-tunnel 198 A tunnel through the network of one or more Service Providers 199 (SPs). In this document, the P-tunnels we speak of are are 200 instantiated as bidirectional multicast distribution trees. 202 o C-S 204 Multicast Source. A multicast source address, in the address 205 space of a customer network. 207 o C-G 209 Multicast Group. A multicast group address (destination address) 210 in the address space of a customer network. When used without 211 qualification, "C-G" may refer to either a unidirectional group 212 address or a bidirectional group address. 214 o C-G-BIDIR 216 A bidirectional multicast group address (i.e., a group address 217 whose IP multicast distribution tree is built by BIDIR-PIM). 219 o C-multicast flow or C-flow 221 A customer multicast flow. A C-flow travels through VPN customer 222 sites on a multicast distribution tree set up by the customer. 223 These trees may be unidirectional or bidirectional, depending upon 224 the multicast routing protocol used by the customer. A C-flow 225 travels between VPN customer sites by traveling through P-tunnels. 227 A C-flow from a particular customer source is identified by the 228 ordered pair (source address, group address), where each address 229 is in the customer's address space. The identifier of such a 230 C-flow is usually written as (C-S,C-G). 232 If a customer uses the "Any Source Multicast" (ASM) model, the 233 some or all of the customer's C-flows may be traveling along the 234 same "shared tree". In this case, we will speak of a "(C-*,C-G)" 235 flow to refer to a set of C-flows that travel along the same 236 shared tree in the customer sites. 238 o C-BIDIR flow or bidirectional C-flow 239 A C-flow that, in the VPN customer sites, travels along a 240 bidirectional multicast distribution tree. The term "C-BIDIR 241 flow" indicates that the customer's bidirectional tree has been 242 set up by BIDIR-PIM. 244 o RP 246 A "Rendezvous Point", as defined in [RFC4601]. 248 o C-RP 250 A Rendezvous Point whose address is in the customer's address 251 space. 253 o RPA 255 A "Rendezvous Point Address", as defined in [RFC5015]. 257 o C-RPA 259 An RPA in the customer's address space. 261 o P-RPA 263 An RPA in the Service Provider's address space 265 o Selective P-tunnel 267 A P-tunnel that is joined only by Provider Edge (PE) routers that 268 need to receive one or more of the C-flows that are traveling 269 through that P-tunnel. 271 o Inclusive P-tunnel 273 A P-tunnel that is joined by all PE routers that attach to sites 274 of a given MVPN. 276 o Intra-AS I-PMSI A-D route 278 Intra Autonomous System Inclusive Provider Multicast Service 279 Interface Auto-Discovery route. Carried in BGP Update messages, 280 these routes can be used to advertise the use of Inclusive 281 P-tunnels. See [RFC6514] section 4.1. 283 o S-PMSI A-D route 285 Selective Provider Multicast Service Interface Auto-Discovery 286 route. Carried in BGP Update messages, these routes are used to 287 advertise the fact that a particular C-flow or a particular set of 288 C-flows is bound to (i.e., is traveling through) a particular 289 P-tunnel. See [RFC6514] section 4.3. 291 o (C-S,C-G) S-PMSI A-D route 293 An S-PMSI A-D route whose NLRI ("Network Layer Reachability 294 Information") contains C-S in its "Multicast Source" field and C-G 295 in its "Multicast Group" field. 297 o (C-*,C-G) S-PMSI A-D route 299 An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its 300 "Multicast Source" field and C-G in its "Multicast Group" field. 301 See [RFC6625]. 303 o (C-*,C-G-BIDIR) S-PMSI A-D route 305 An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its 306 "Multicast Source" field and C-G-BIDIR in its "Multicast Group" 307 field. See [RFC6625]. 309 o (C-*,C-*) S-PMSI A-D route 311 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 312 "Multicast Source" field and the wildcard C-* in its "Multicast 313 Group" field. See [RFC6625]. 315 o (C-*,C-*) S-PMSI A-D route 317 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 318 "Multicast Source" field and the wildcard C-* in its "Multicast 319 Group" field. See [RFC6625]. 321 o (C-*,C-*-BIDIR) S-PMSI A-D route 323 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 324 "Multicast Source" field and the wildcard "C-*-BIDIR" in its 325 "Multicast Group" field. See Section 2 of this document. 327 o (C-S,C-*) S-PMSI A-D route 329 An S-PMSI A-D route whose NLRI contains C-S in its "Multicast 330 Source" field and the wildcard C-* in its "Multicast Group" field. 331 See [RFC6625]. 333 o Wildcard S-PMSI A-D route 334 A (C-*,C-G) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route, or 335 a (C-S,C-*) S-PMSI A-D route, or a (C-*,C-*-BIDIR) S-PMSI A-D 336 route. 338 o PTA 340 PMSI Tunnel attribute, a BGP attribute that identifies a P-tunnel. 341 See [RFC6514] section 8. 343 The terminology used for categorizing S-PMSI A-D routes will also be 344 used for categorizing the S-PMSIs advertised by those routes. E.g., 345 the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route will be known 346 as a "(C-*,C-G) S-PMSI". 348 Familiarity with multicast concepts and terminology [RFC4601] is also 349 presupposed. 351 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 352 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 353 document, when and only when appearing in all caps, are to be 354 interpreted as described in [RFC2119]. 356 1.2. Overview 358 The base documents for MVPN ([RFC6513], [RFC6514]) define a "PMSI 359 Tunnel attribute" (PTA). This is a BGP Path Attribute that may be 360 attached to the BGP "I-PMSI A-D routes" and "S-PMSI A-D routes" that 361 are defined in those documents. The base documents define the way in 362 which the identifier of a bidirectional P-tunnel is to be encoded in 363 the PTA. However, those documents do not contain the full set of 364 specifications governing the use bidirectional P-tunnels; rather, 365 those documents declare the full set of specifications for using 366 bidirectional P-tunnels to be outside their scope. Similarly, the 367 use of bidirectional P-tunnels advertised in wildcard S-PMSI A-D 368 routes is declared by [RFC6625] to be "out of scope." 370 This document provides the specifications governing the use of 371 bidirectional P-tunnels to provide MVPN support. This includes the 372 procedures for assigning C-flows to specific bidirectional P-tunnels, 373 for advertising the fact that a particular C-flow has been assigned 374 to a particular bidirectional P-tunnel, and for determining the 375 bidirectional P-tunnel on which a given C-flow may be expected. 377 The C-flows carried on bidirectional P-tunnels may themselves be 378 either unidirectional or bidirectional. Procedures are provided for 379 both cases. 381 This document does not specify any new data encapsulations for 382 bidirectional P-tunnels. Section 12 ("Encapsulations") of [RFC6513] 383 applies unchanged. 385 With regard to the procedures for using bidirectional P-tunnels to 386 instantiate PMSIs, if there is any conflict between the procedures 387 specified in this document and the procedures of [RFC6513], 388 [RFC6514], or [RFC6625], the procedures of this document take 389 precedence. 391 The use of bidirectional P-tunnels to support extranets [MVPN-XNET] 392 is outside the scope of this document. The use of bidirectional 393 P-tunnels as "segmented P-tunnels" (see [RFC6513] section 8 and 394 various sections of [RFC6514]) is also outside the scope of this 395 document. 397 1.2.1. Bidirectional P-tunnel Technologies 399 This document supports two different technologies for creating and 400 maintaining bidirectional P-tunnels: 402 o Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that 403 are created through the use of the Label Distribution Protocol 404 (LDP) Multipoint-to-Multipoint extensions [RFC6388]. 406 o Multicast distribution trees that are created through the use of 407 BIDIR-PIM [RFC5015]. 409 An implementation may be considered compliant with this document if 410 it provides either one of these tunneling technologies. Other 411 bidirectional tunnel technologies are outside the scope of this 412 document. 414 1.2.2. Reasons for Using Bidirectional P-tunnels 416 Bidirectional P-tunnels can be used to instantiate I-PMSIs and/or 417 S-PMSIs. 419 An SP may decide to use bidirectional P-tunnels to instantiate 420 certain I-PMSIs and/or S-PMSIs in order to provide its customers with 421 C-BIDIR support, using the "Partitioned Set of PEs" technique 422 discussed in [RFC6513] section 11.2 and [RFC6517] section 3.6. This 423 technique can be used whether the C-BIDIR flows are being carried on 424 an I-PMSI or an S-PMSI. 426 Even if an SP does not need to provide C-BIDIR support, it may still 427 decide to use bidirectional P-tunnels, in order to save state in the 428 network's transit nodes. For example, if an MVPN has n PEs attached 429 to sites with multicast sources, and there is an I-PMSI for that 430 MVPN, instantiating the I-PMSI with unidirectional P-tunnels (i.e., 431 with P2MP multicast distribution trees) requires n multicast 432 distribution trees, each one rooted at a different PE. If the I-PMSI 433 is instantiated by a bidirectional P-tunnel, a single multicast 434 distribution tree can be used. 436 An SP may decide to use bidirectional P-tunnels for either or both of 437 these reasons. Note that even if the reason for using bidirectional 438 P-tunnels is to provide C-BIDIR support, the same P-tunnels can also 439 be used to carry unidirectional C-flows, if that is the choice of the 440 SP. 442 These two reasons for using bidirectional P-tunnels may appear to be 443 somewhat in conflict with each other, since (as will be seen in 444 subsequent sections), the use of bidirectional P-tunnels for C-BIDIR 445 support may require multiple bidirectional P-tunnels per VPN. Each 446 such P-tunnel is associated with a particular "distinguished PE", and 447 can only carry those C-BIDIR flows whose C-RPAs are reachable through 448 its distinguished PE. However, on platforms that support MPLS 449 upstream-assigned labels [RFC5331], "PE Distinguisher Labels" can be 450 used to aggregate multiple bidirectional P-tunnels onto a single 451 "outer" bidirectional P-tunnel, thereby allowing one to provide 452 C-BIDIR support with minimal state at the transit nodes. 454 Since there are two fundamentally different reasons for using 455 bidirectional P-tunnels, and since many deployed router platforms do 456 not support upstream-assigned labels at the current time, this 457 document specifies several different methods of using bidirectional 458 P-tunnels to instantiate PMSIs. We refer to these as "PMSI 459 Instantiation Methods". The method or methods deployed by any 460 particular SP will depend upon that SP's goals and engineering 461 tradeoffs, and upon the set of platforms deployed by that SP. 463 The rules for using bidirectional P-tunnels in I-PMSI or S-PMSI A-D 464 routes are not exactly the same as the rules for using unidirectional 465 P-tunnels, and the rules are also different for the different PMSI 466 instantiation methods. Subsequent sections of this document specify 467 the rules in detail. 469 1.2.3. Knowledge of Group-to-RP and/or Group-to-RPA Mappings 471 If a VPN customer is making use of a particular "Any Source 472 Multicast" (ASM) group address, the PEs of that VPN generally need to 473 know the group-to-RP mappings that are used within the VPN. If a VPN 474 customer is making use of BIDIR-PIM group addresses, the PEs need to 475 know the group-to-RPA mappings that are used within the VPN. 476 Commonly, the PEs obtain this knowledge either through provisioning 477 or by participating in a dynamic "group-to-RP(A) mapping discovery 478 protocol" that runs within the VPN. However, the way in which this 479 knowledge is obtained is outside the scope of this document. 481 The PEs also need to be able to forward traffic towards the C-RPs 482 and/or C-RPAs, and to determine whether the next hop "interface" of 483 the route to a particular C-RP(A) is a VRF interface or a PMSI. This 484 is done by applying the procedures of [RFC6513] section 5.1. 486 1.2.4. PMSI Instantiation Methods 488 This document specifies three methods for using bidirectional 489 P-tunnels to instantiate PMSIs: the Flat Partitioned Method, the 490 Hierarchical Partitioned Method, and the Unpartitioned Method. 492 o Partitioned Methods 494 In the Partitioned Methods, a particular PMSI is instantiated by a 495 set of bidirectional P-tunnels. These P-tunnels may be aggregated 496 (as "inner" P-tunnels) into a single "outer" bidirectional 497 P-tunnel ("Hierarchical Partitioning"), or they may be 498 unaggregated ("Flat Partitioning"). Any PE that joins one of 499 these P-tunnels can transmit a packet on it, and the packet will 500 be received by all the other PEs that have joined the P-tunnel. 501 For each such P-tunnel (each "inner" P-tunnel, in the case of 502 Hierarchical Partitioning) there is one PE that is its 503 "distinguished PE". When a PE receives a packet from a given 504 P-tunnel, the PE can determine from the packet's encapsulation the 505 P-tunnel is has arrived on, and can thus infer the identity of the 506 distinguished PE associated with the packet. This association 507 plays an important role in the treatment of the packet, as 508 specified later on in this document. 510 The number of P-tunnels needed (the number of "inner" P-tunnels 511 needed, if Hierarchical Partitioning is used) depends upon a 512 number of factors that are described later in this document. 514 The Hierarchical Partitioned Method requires the use of upstream- 515 assigned MPLS labels ("PE Distinguisher Labels"), and requires the 516 use of the PE Distinguisher Labels attribute in BGP. The Flat 517 Partitioned Method requires neither of these. 519 The Partitioned Method (either flat or hierarchical) is a pre- 520 requisite for implementing the "Partitioned Sets of PEs" technique 521 of supporting C-BIDIR, as discussed in [RFC6513] section 11.2. 522 The Partitioned Method (either flat or hierarchical) is also a 523 pre-requisite for applying the "Discarding Packets from Wrong PE" 524 technique, discussed in [RFC6513] Section 9.1.1, to a PMSI that is 525 instantiated by a bidirectional P-tunnel. 527 The Flat Partitioned Method is a pre-requisite for implementing 528 the "Partial Mesh of MP2MP P-tunnels" technique for carrying 529 customer bidirectional (C-BIDIR) traffic, as discussed in 530 [RFC6513] Section 11.2.3. 532 The Hierarchical Partitioned Method is a pre-requisite for 533 implementing the "Using PE Distinguisher Labels" technique of 534 carrying customer bidirectional (C-BIDIR) traffic, as discussed in 535 [RFC6513] Section 11.2.2. 537 Note that a particular deployment may choose to use the 538 Partitioned Method for carrying the C-BIDIR traffic on 539 bidirectional P-tunnels, while carrying other traffic either on 540 unidirectional P-tunnels, or on bidirectional P-tunnels using the 541 Unpartitioned Method. Routers in a given deployment must be 542 provisioned to know which PMSI instantiation method to use for 543 which PMSIs. 545 There may be ways of implementing the Partitioned Method with 546 PMSIs that are instantiated by unidirectional P-tunnels. (See, 547 e.g., [MVPN-BIDIR-IR].) However, that is outside the scope of the 548 current document. 550 o Unpartitioned Method 552 In the Unpartitioned Method, a particular PMSI can be instantiated 553 by a single bidirectional P-tunnel. Any PE that joins the tunnel 554 can transmit a packet on it, and the packet will be received by 555 all the other PEs that have joined the tunnel. The receiving PEs 556 can determine the tunnel on which the packet was transmitted, but 557 they cannot determine which PE transmitted the packet, nor can 558 they associate the packet with any particular "distinguished PE". 560 When the Unpartitioned Method is used, this document does not 561 mandate that only one bidirectional P-tunnel be used to 562 instantiate each PMSI. It allows for the case where more than one 563 P-tunnel is used. In this case, the transmitting PEs will have a 564 choice of which such P-tunnel to use when transmitting, and the 565 receiving PEs must be prepared to receive from any of those 566 P-tunnels. The use of multiple P-tunnels in this case provides 567 additional robustness, but no additional functionality. 569 I-PMSIs may be instantiated by bidirectional P-tunnels using either 570 the Partitioned (either Flat or Hierarchical) or the Unpartitioned 571 Method. The method used for a given MVPN is determined by 572 provisioning. It SHOULD be possible to provision this on a per-MVPN 573 basis, but all the VRFs of a single MVPN MUST be provisioned to use 574 the same method for the given MVPN's I-PMSI. 576 If a bidirectional P-tunnel is used to instantiate an S-PMSI 577 (including the case of a (C-*,C-*) S-PMSI), either the Partitioned 578 Method (either Flat or Hierarchical) or the Unpartitioned Method may 579 be used. The method used by a given VRF used is determined by 580 provisioning. It SHOULD be possible to provision this on a per-MVPN 581 basis, but all the VRFs of a single MVPN MUST be provisioned to use 582 the same method for those of their S-PMSIs that are instantiated by 583 bidirectional P-tunnels. 585 If the Partitioned Method is used, all the VRFs of a single MVPN MUST 586 be provisioned to use the same variant of the Partitioned Method, 587 i.e., either they must all use the Flat Partitioned Method, or they 588 must all use the Hierarchical Partitioned Method. 590 It is valid to use the Unpartitioned Method to instantiate the 591 I-PMSIs, while using one of the Partitioned Methods to instantiate 592 the S-PMSIs. 594 It is valid to instantiate some S-PMSIs by unidirectional P-tunnels 595 and others by bidirectional P-tunnels. 597 The procedures for the use of bidirectional P-tunnels, specified in 598 subsequent sections of this document, depend on both the tunnel 599 technology and on the PMSI instantiation method. Note that this 600 document does not necessarily specify procedures for every possible 601 combination of tunnel technology and PMSI instantiation method. 603 2. The All BIDIR-PIM Wild Card 605 When an MVPN customer is using BIDIR-PIM, it is useful to be able to 606 advertise an S-PMSI A-D route whose semantics are: "by default, all 607 BIDIR-PIM C-multicast traffic (within a given VPN) that has not been 608 bound to any other P-tunnel is bound to the bidirectional P-tunnel 609 identified by the PTA of this route". This can be especially useful 610 if one is using a bidirectional P-tunnel to carry the C-BIDIR flows, 611 while using unidirectional P-tunnels to carry other C-flows. To do 612 this, it is necessary to have a way to encode a (C-*,C-*) wildcard 613 that is restricted to BIDIR-PIM C-groups. 615 We therefore define a special value of the group wildcard, whose 616 meaning is "all BIDIR-PIM groups". The "BIDIR-PIM groups wildcard" 617 is encoded as a group field whose length is 8 bits and whose value is 618 zero. That is, the "multicast group length" field contains the value 619 0x08, and the "multicast group" field is a single octet containing 620 the value 0x00. We will use the notation (C-*,C-*-BIDIR) to refer to 621 the "all BIDIR-PIM groups" wildcard. 623 3. Using Bidirectional P-Tunnels 625 A bidirectional P-tunnel may be advertised in the PTA of an Intra-AS 626 I-PMSI A-D route or in the PTA of an S-PMSI A-D route. The 627 advertisement of a bidirectional P-tunnel in the PTA of an Inter-AS 628 I-PMSI A-D route is outside the scope of this document. 630 3.1. Procedures Specific to the Tunneling Technology 632 This section discusses the procedures that are specific to a given 633 tunneling technology (BIDIR-PIM or MP2MP mLDP), but that are 634 independent of the method (Unpartitioned, Flat Partitioned, or 635 Hierarchical Partitioned) used to instantiate a PMSI. 637 3.1.1. BIDIR-PIM P-Tunnels 639 Each BIDIR-PIM P-Tunnel is identified by a unique P-group address 640 ([RFC6513], section 3.1). (The P-group address is called a 641 "P-Multicast Group" in [RFC6514]). Section 5 of [RFC6514] specifies 642 the way to identify a particular BIDIR-PIM P-tunnel in the PTA of an 643 I-PMSI or S-PMSI A-D route. 645 Ordinary BIDIR-PIM procedures are used to set up the BIDIR-PIM 646 P-tunnels. A BIDIR-PIM P-group address is always associated with a 647 unique "Rendezvous Point Address" (RPA) in the SP's address space. 648 We will refer to this as the "P-RPA". Every PE needing to join a 649 particular BIDIR-PIM P-tunnel must be able to determine the P-RPA 650 that corresponds to the P-tunnel's P-group address. To construct the 651 P-tunnel, PIM Join/Prune messages are sent along the path from the PE 652 to the P-RPA. Any P routers along that path must also be able to 653 determine the P-RPA, so that they too can send PIM Join/Prune 654 messages towards it. The method of mapping a P-group address to an 655 RPA may be static configuration, or some automated means of RPA 656 discovery that is outside the scope of this specification. 658 If a BIDIR-PIM P-tunnel is used to instantiate an I-PMSI or an 659 S-PMSI, it is RECOMMENDED that the path from each PE in the tunnel to 660 the RPA consist entirely of point-to-point links. On a point-to- 661 point link, there is no ambiguity in determining which router is 662 upstream towards a particular RPA, so the BIDIR-PIM "Designated 663 Forwarder Election" is very quick and simple. Use of a BIDIR-PIM 664 P-tunnel containing multiaccess links is possible, but considerably 665 more complex. 667 The use of BIDIR-PIM P-tunnels to support the Hierarchical 668 Partitioned Method is outside the scope of this document. 670 When the PTA of an Intra-AS I-PMSI A-D route or an S-PMSI A-D route 671 identifies a BIDIR-PIM tunnel, the originator of the route SHOULD NOT 672 include a PE Distinguisher Labels attribute. If it does, that 673 attribute MUST be ignored. When we say the attribute is "ignored", 674 we do not mean that its normal BGP processing is not done, but that 675 the attribute has no effect on the data plane. It MUST however be 676 treated by BGP as if it were an unsupported optional transitive 677 attribute. (PE Distinguisher Labels are used for the Hierarchical 678 Partitioning Method, but this document does not provide support for 679 the Hierarchical Partitioning Method with BIDIR-PIM P-tunnels.) 681 3.1.2. MP2MP LSPs 683 Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding 684 Equivalence Class) element" [RFC6388]. The FEC element contains the 685 IP address of the "root node", followed by an "opaque value" that 686 identifies the MP2MP LSP uniquely in the context of the root node's 687 IP address. This opaque value may be configured or autogenerated, 688 and within an MVPN, there is no need for different root nodes to use 689 the same opaque value. The mLDP specification supports the use of 690 several different ways of constructing the tunnel identifiers. The 691 current specification does not place any restriction on the type of 692 tunnel identifier that might be used. However, a given 693 implementation might not support every possible type of tunnel 694 identifier. 696 Section 5 of [RFC6514] specifies the way to identify a particular 697 MP2MP P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route. 699 Ordinary mLDP procedures for MP2MP LSPs are used to set up the MP2MP 700 LSP. 702 3.2. Procedures Specific to the PMSI Instantiation Method 704 When either the Flat Partitioned Method or the Hierarchical 705 Partitioned Method is used to implement the "Partitioned Sets of PEs" 706 method of supporting C-BIDIR, as discussed in section 11.2 of 707 [RFC6513] and section 3.6 of [RFC6517], a C-BIDIR flow MUST be 708 carried only on an I-PMSI or on a (C-*,C-G-BIDIR), (C-*,C-*-BIDIR), 709 or (C-*,C-*) S-PMSI. A PE MUST NOT originate any (C-S,C-G-BIDIR) 710 S-PMSI A-D routes. (Though it may of course originate (C-S,C-G) 711 S-PMSI A-D routes for C-G's that are not C-BIDIR groups.) Packets of 712 a C-BIDIR flow MUST NOT be carried on a (C-S,C-*) S-PMSI. 714 Section 3.2.1 and Section 3.2.2 specify additional details of the two 715 Partitioned Methods. 717 3.2.1. Flat Partitioning 719 The procedures of this section and its sub-sections apply when (and 720 only when) the Flat Partitioned Method is used. This method is 721 introduced in [RFC6513] Section 11.2.3, where it is called "Partial 722 Mesh of MP2MP P-tunnels". This method can be used with MP2MP LSPs or 723 with BIDIR-PIM P-tunnels. 725 When a PE originates an I-PMSI or S-PMSI A-D route whose PTA 726 specifies a bidirectional P-tunnel, the PE MUST be the root node of 727 the specified P-tunnel. It follows that two different PEs may not 728 advertise the same bidirectional P-tunnel. Any PE that receives a 729 packet from the P-tunnel can infer the identity of the P-tunnel from 730 the packet's encapsulation. Once the identity of the P-tunnel is 731 known, the root node of the P-tunnel is also known. The root node of 732 the P-tunnel on which the packet arrived is treated as the 733 "distinguished PE" for that packet. 735 If MP2MP LSPs are used, each P-tunnel MUST have have a distinct MP2MP 736 FEC (i.e., distinct combination of "root node" and "opaque value"). 737 The PE advertising the tunnel MUST be the same PE identified in the 738 "root node" field of the MP2MP FEC that is encoded in the PTA. 740 If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a 741 distinct P-group address. The PE advertising the tunnel will be 742 considered to be the root node of the tunnel. Note that this creates 743 a unique mapping from P-group address to "root node". 745 The Flat Partitioned Method does not use upstream-assigned labels in 746 the data plane, and hence does not use the BGP PE Distinguisher 747 Labels attribute. When this method is used, I-PMSI and/or S-PMSI A-D 748 routes SHOULD NOT contain a PE Distinguisher Labels attribute; if 749 such an attribute is present in a received I-PMSI or S-PMSI A-D 750 route, it MUST be ignored. (When we say the attribute is "ignored", 751 we do not mean that its normal BGP processing is not done, but that 752 the attribute has no effect on the data plane. It MUST however be 753 treated by BGP as if it were an unsupported optional transitive 754 attribute.) 756 When the Flat Partitioned Method is used to instantiate the I-PMSIs 757 of a given MVPN, every PE in that MVPN that originates an Intra-AS 758 I-PMSI A-D route MUST include a PTA that specifies a bidirectional 759 P-tunnel. If the intention is to carry C-BIDIR traffic on the 760 I-PMSI, a PE MUST originate an Intra-AS I-PMSI A-D route if one of 761 its VRF interfaces is the next hop interface on its best path to the 762 C-RPA of any bidirectional C-group of the MVPN. 764 When the Flat Partitioned Method is used to instantiate a (C-*,C-*) 765 S-PMSI, a (C-*,C-*-BIDIR) S-PMSI, or a (C-*,C-G-BIDIR) S-PMSI, a PE 766 that originates the corresponding S-PMSI A-D route MUST include in 767 that route a PTA specifying a bidirectional P-tunnel. Per the 768 procedures of [RFC6513] and [RFC6514], a PE will originate such an 769 S-PMSI A-D route only if one of the PE's VRF interfaces is the next 770 hop interface of the PE's best path to the C-RPA of a C-BIDIR group 771 that is to be carried on the specified S-PMSI. 773 PMSIs that are instantiated via the Flat Partitioned Method may carry 774 customer bidirectional traffic AND customer unidirectional traffic. 775 The rules of Section 3.2.1.1 and Section 3.2.1.2 determine when a 776 given customer multicast packet is a "match for transmission" to a 777 given PMSI. However, if the "Partitioned Set of PEs" method of 778 supporting C-BIDIR traffic is being used, the PEs must be provisioned 779 in such a way that packets from a C-BIDIR flow never match any PMSI 780 that is not instantiated by a bidirectional P-tunnel. (For example, 781 if the (C-*,C-*) S-PMSI were not instantiated by a bidirectional 782 P-tunnel, one could meet this requirement by carrying all C-BIDIR 783 traffic on a (C-*,C-*-BIDIR) S-PMSI.) 785 When a PE receives a customer multicast data packet from a 786 bidirectional P-tunnel, it associates that packet with a 787 "distinguished PE". The distinguished PE for a given packet is the 788 root node of the tunnel from which the packet is received. The rules 789 of Section 3.2.1.1 and Section 3.2.1.2 ensure that: 791 o If the received packet is part of a unidirectional C-flow, its 792 "distinguished PE" is the PE that transmitted the packet onto the 793 P-tunnel. 795 o If the received packet is part of a bidirectional C-flow, its 796 "distinguished PE" is not necessarily the PE that transmitted it, 797 but rather the transmitter's "upstream PE" for the C-RPA of the 798 bidirectional C-group. 800 The rules of Section 3.2.1.3 and Section 3.2.1.4 allow the receiving 801 PEs to determine the expected distinguished PE for each C-flow, and 802 ensure that a packet will be discarded if its distinguished PE is not 803 the expected distinguished PE for the C-flow to which the packet 804 belongs. This prevents duplication of data for both bidirectional 805 and unidirectional C-flows. 807 3.2.1.1. When an S-PMSI is a 'Match for Transmission' 809 Suppose a given PE, say PE1, needs to transmit multicast data packets 810 of a particular C-flow. [RFC6625] Section 3.1 gives a four-step 811 algorithm for determining the S-PMSI A-D route, if any, that 812 "matches" that C-flow for transmission. 814 If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged; 815 the remainder of this section applies only to C-BIDIR flows. If a 816 C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 817 are given below: 819 o If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's 820 route to the C-RPA is via a VRF interface, then: 822 * If there is a (C-*,C-G-BIDIR) S-PMSI A-D route currently 823 originated by PE1, then the C-flow matches that route. 825 * Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route 826 currently originated by PE1, then the C-flow matches that 827 route. 829 * Otherwise, if there is a (C-*,C-*) S-PMSI A-D route currently 830 originated by PE1, then the C-flow matches that route. 832 o If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some 833 other PE, say PE2, then: 835 * If there is an installed (C-*,C-G-BIDIR) S-PMSI A-D route 836 originated by PE2, then the C-flow matches that route. 838 * Otherwise, if there is an installed (C-*,C-*-BIDIR) S-PMSI A-D 839 route originated by PE2, then the C-flow matches that route. 841 * Otherwise, if there is an installed (C-*,C-*) S-PMSI A-D route 842 originated by PE2, then the C-flow matches that route. 844 If there is an S-PMSI A-D route that matches a given C-flow, and if 845 PE1 needs to transmit packets of that C-flow or other PEs, then it 846 MUST transmit those packets on the bidirectional P-tunnel identified 847 in the PTA of the matching S-PMSI A-D route. 849 3.2.1.2. When an I-PMSI is a 'Match for Transmission' 851 Suppose a given PE, say PE1, needs to transmit packets of a given 852 C-flow (of a given MVPN) to other PEs, but according to the 853 conditions of Section 3.2.1.1 and/or [RFC6625] section 3.1, that 854 C-flow does not match any S-PMSI A-D route. Then the packets of the 855 C-flow need to be transmitted on the MVPN's I-PMSI. 857 If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the 858 C-flow MUST be transmitted is the one identified in the PTA of the 859 Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. 861 If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the 862 rules applied by PE1 are: 864 o If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's 865 route to the C-RPA is via a VRF interface, then if there is an 866 I-PMSI A-D route currently originated by PE1, then the C-flow MUST 867 be transmitted on the P-tunnel identified in the PTA of that 868 I-PMSI A-D route. 870 o If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be some 871 other PE, say PE2, then if there is an installed I-PMSI A-D route 872 originated by PE2, the C-flow MUST be transmitted on the P-tunnel 873 identified in the PTA of that route. 875 If there is no I-PMSI A-D route meeting the above conditions, the 876 C-flow MUST NOT be transmitted. 878 3.2.1.3. When an S-PMSI is a 'Match for Reception' 880 Suppose a given PE, say PE1, needs to receive multicast data packets 881 of a particular C-flow. [RFC6625] Section 3.2 specifies procedures 882 for determining the S-PMSI A-D route, if any, that "matches" that 883 C-flow for reception. Those rules apply unchanged for C-flows that 884 are not BIDIR-PIM C-flows. The remainder of this section applies 885 only to C-BIDIR flows. 887 The rules of [RFC6625] Section 3.2.1 are not applicable to C-BIDIR 888 flows. The rules of [RFC6625] Section 3.2.2 are replaced by the 889 following rules. 891 Suppose PE1 needs to receive (C-*,C-G-BIDIR) traffic. Suppose also 892 that PE1 has determined that PE2 is the "upstream PE" [RFC6513] for 893 the C-RPA of C-G-BIDIR. Then: 895 o If PE1 has an installed (C-*,C-G-BIDIR) S-PMSI A-D route 896 originated by PE2, then (C-*,C-G-BIDIR) matches this route. 898 o Otherwise, if PE1 has an installed (C-*,C-*-BIDIR) route 899 originated by PE2, then (C-*,C-G-BIDIR) matches this route. 901 o Otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D route 902 originated by PE2, then (C-*,C-G-BIDIR) matches this route. 904 If there is an S-PMSI A-D route matching (C-*,C-G-BIDIR), according 905 to these rules, the root node of that P-tunnel is considered to be 906 the "distinguished PE" for that (C-*,C-G-BIDIR) flow. If a 907 (C-*,C-G-BIDIR) packet is received on a P-tunnel whose root node is 908 not the distinguished PE for the C-flow, the packet MUST be 909 discarded. 911 3.2.1.4. When an I-PMSI is a 'Match for Reception 913 Suppose a given PE, say PE1, needs to receive packets of a given 914 C-flow (of a given MVPN) from another PE, but according to the 915 conditions of Section 3.2.1.3 and/or [RFC6625] section 3.2, that 916 C-flow does not match any S-PMSI A-D route. Then the packets of the 917 C-flow need to be received on the MVPN's I-PMSI. 919 If the C-flow is not a BIDIR-PIM C-flow, the rules for determining 920 the P-tunnel on which packets of the C-flow are expected are given in 921 [RFC6513]. The remainder of this section applies only to C-BIDIR 922 flows. 924 Suppose that PE1 needs to receive (C-*,C-G-BIDIR) traffic from other 925 PEs. Suppose also that PE1 has determined that PE2 is the "upstream 926 PE" [RFC6513] for the C-RPA of C-G-BIDIR. Then PE1 considers PE2 to 927 be the "distinguished PE" for (C-*,C-G-BIDIR). If PE1 has an 928 installed Intra-AS I-PMSI A-D route originated by PE2, PE1 will 929 expect to receive packets of the C-flow from the tunnel specifies in 930 that route's PTA. (If all VRFs of the MVPN have been properly 931 provisioned to use the Flat Partitioned Method for the I-PMSI, the 932 PTA will specify a bidirectional P-tunnel.) 934 If a (C-*,C-G-BIDIR) packet is received on a P-tunnel other than the 935 expected one, packet MUST be discarded. 937 3.2.2. Hierarchical Partitioning 939 The procedures of this section and its sub-sections apply when (and 940 only when) the Hierarchical Partitioned Method is used. This method 941 is introduced in [RFC6513] Section 11.2.2. This document only 942 provides procedures for using this method when using MP2MP LSPs as 943 the P-tunnels. 945 The Hierarchical Partitioned Method provides the same functionality 946 as the Flat Partitioned Method, but requires a smaller amount of 947 state to be maintained in the core of the network. However, it 948 requires the use of upstream-assigned MPLS labels ("PE Distinguisher 949 Labels"), which are not necessarily supported by all hardware 950 platforms. The upstream-assigned labels are used to provide an LSP 951 hierarchy, in which an "outer" MP2MP LSP carries multiple "inner" 952 MP2MP LSPs. Transit routers along the path between PE routers then 953 only need to maintain state for the outer MP2MP LSP. 955 When this method is used to instantiate a particular PMSI, the 956 bidirectional P-tunnel advertised in the PTA of the corresponding 957 I-PMSI or S-PMSI A-D route is the "outer" P-tunnel. When a packet is 958 received from a P-tunnel, the PE that receives it can infer the 959 identity of the outer P-tunnel from the MPLS label that has risen to 960 the top of the packet's label stack. However, the packet's 961 "distinguished PE" is not necessarily the root node of the the outer 962 P-tunnel. Rather, the identity of the packet's distinguished PE is 963 inferred from the PE Distinguisher Label further down in the label 964 stack. (See [RFC6513] Section 12.3.) The PE Distinguisher Label may 965 be thought of as identifying an "inner" MP2MP LSP whose root is the 966 PE corresponding to that label. 968 In the context of a given MVPN, if it is desired to use the 969 Hierarchical Partitioned Method to instantiate an I-PMSI, a (C-*,C-*) 970 S-PMSI, or a (C-*,C-*-BIDIR) S-PMSI, the corresponding A-D routes 971 MUST be originated by some of the PEs that attach to that MVPN. The 972 PEs are REQUIRED to originate these routes are those that satisfy one 973 of the following conditions: 975 o There is a C-BIDIR group for which the best path from the PE to 976 the C-RPA of that C-group is via a VRF interface, or 978 o The PE might have to transmit unidirectional customer multicast 979 traffic on the PMSI identified in the route (of course this 980 condition does not apply to (C-*,C-*-BIDIR) or to (C-*,C-G-BIDIR) 981 S-PMSIs). 983 o The PE is the root node of the MP2MP LSP that is used to 984 instantiate the PMSI. 986 When the Hierarchical Partitioned method is used to instantiate a 987 (C-*,C-G-BIDIR) S-PMSI, the corresponding (C-*,C-G-BIDIR) S-PMSI 988 route MUST NOT be originated by a given PE unless either (a) that 989 PE's best path to the C-RPA for C-G-BIDIR is via a VRF interface, or 990 (b) the C-RPA is a C-address of the PE. Further, that PE MUST be the 991 root node of the MP2MP LSP identified in the PTA of the S-PMSI A-D 992 route. 994 If any VRF of a given MVPN uses this method to instantiate an S-PMSI 995 with a bidirectional P-tunnel, all VRFs of that MVPN must use this 996 method. 998 Suppose that for a given MVPN, the Hierarchical Partitioned Method is 999 used to instantiate the I-PMSI. In general, more than one of the PEs 1000 in the MVPN will originate an Intra-AS I-PMSI A-D route for that 1001 MVPN. This document allows the PTAs of those routes to all specify 1002 the same MP2MP LSP as the "outer tunnel". However, it does not 1003 require that those PTAs all specify the same MP2MP LSP as the outer 1004 tunnel. By having all the PEs specify the same outer tunnel for the 1005 I-PMSI, one can minimize the amount of state in the transit nodes. 1006 By allowing them to specify different outer tunnels, one uses more 1007 state, but may increase the robustness of the system. 1009 The considerations of the previous paragraph apply as well when the 1010 Hierarchical Partitioned Method is used to instantiate an S-PMSI. 1012 3.2.2.1. Advertisement of PE Distinguisher Labels 1014 A PE Distinguisher Label is an upstream-assigned MPLS label [RFC5331] 1015 that can be used, in the context of a MP2MP LSP, to denote a 1016 particular PE that either has joined or may in the future join that 1017 LSP. 1019 In order to use upstream-assigned MPLS labels in the context of an 1020 "outer" MP2MP LSP, there must be a convention that identifies a 1021 particular router as the router that is responsible for allocating 1022 the labels and for advertising the labels to the PEs that may join 1023 the MP2MP LSP. This document REQUIRES that the PE Distinguisher 1024 Labels used in the context of a given MP2MP LSP be allocated and 1025 advertised by the router that is the root node of the LSP. 1027 This convention accords with the rules of section 7 of [RFC5331]. 1028 Note that according to section 7 of [RFC5331], upstream-assigned 1029 labels are unique in the context of the IP address of the root node; 1030 if two MP2MP LSPs have the same root node IP address, the upstream- 1031 assigned labels used within the two LSPs come from the same label 1032 space. 1034 A PE Distinguisher Labels attribute SHOULD NOT be attached to an 1035 I-PMSI or S-PMSI A-D route unless that route also contains a PTA that 1036 specifies an MP2MP LSP. (While PE Distinguisher Labels could in 1037 theory also be used if the PTA specifies a BIDIR-PIM P-tunnel, such 1038 use is outside the scope of this document.) 1040 The PE Distinguisher Labels attribute specifies a set of bindings. Within a given PE Distinguisher Labels 1042 attribute, each such IP address MUST appear at most once, and each 1043 MPLS label MUST appear only once; otherwise the attribute is 1044 considered to be malformed. 1046 When a PE Distinguisher Labels attribute is included in a given 1047 I-PMSI or S-PMSI A-D route, it MUST assign a label to the IP address 1048 of each of the following PEs: 1050 o The root node of the MP2MP LSP identified in the PTA of the route, 1052 o Any PE that is possibly the ingress PE for a C-RPA of any C-BIDIR 1053 group. 1055 o Any PE that may need to transmit non-C-BIDIR traffic on the MP2MP 1056 LSP identified in the PTA of the route. 1058 One simple way to meet these requirements is to assign a PE 1059 Distinguisher label to every PE that has originated an Intra-AS 1060 I-PMSI A-D route. 1062 3.2.2.2. When an S-PMSI is a 'Match for Transmission' 1064 Suppose a given PE, say PE1, needs to transmit multicast data packets 1065 of a particular C-flow. [RFC6625] Section 3.1 gives a four-step 1066 algorithm for determining the S-PMSI A-D route, if any, that 1067 "matches" that C-flow for transmission. 1069 If the C-flow is not a BIDIR-PIM C-flow, these rules apply unchanged. 1070 If there is a matching S-PMSI A-D route, the P-tunnel on which the 1071 C-flow MUST be transmitted is the one identified in the PTA of the 1072 matching route. Each packet of the C-flow MUST carry the PE 1073 Distinguisher Label assigned by the root node of that P-tunnel to the 1074 IP address of PE1. See section 12.3 of [RFC6513] for encapsulation 1075 details. 1077 The remainder of this section applies only to C-BIDIR flows. If a 1078 C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 1079 are the same as the rules given in Section 3.2.1.1. 1081 If there is a matching S-PMSI A-D route, PE1 MUST transmit the C-flow 1082 on the P-tunnel identified in its PTA. In constructing the packet's 1083 MPLS label stack, it must use the PE Distinguisher Label that was 1084 assigned by the P-tunnel's root node to the IP address of "PE2", not 1085 the label assigned to the IP address of "PE1". (Section 3.2.1.1 1086 specifies the difference between PE1 and PE2.) See section 12.3 of 1087 [RFC6513] for encapsulation details. Note that the root of the 1088 P-tunnel might be a PE other than PE1 or PE2. 1090 3.2.2.3. When an I-PMSI is a 'Match for Transmission' 1092 Suppose a given PE, say PE1, needs to transmit packets of a given 1093 C-flow (of a given MVPN) to other PEs, but according to the 1094 conditions of Section 3.2.2.2 and/or [RFC6625] section 3.1, that 1095 C-flow does not match any S-PMSI A-D route. Then the packets of the 1096 C-flow need to be transmitted on the MVPN's I-PMSI. 1098 If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the 1099 C-flow MUST be transmitted is the one identified in the PTA of the 1100 Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. Each 1101 packet of the C-flow MUST carry the PE Distinguisher Label assigned 1102 by the root node of that P-tunnel to the IP address of PE1. 1104 If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the 1105 rules as applied by PE1 are the same as those given in 1106 Section 3.2.1.2. 1108 If there is a matching I-PMSI A-D route, PE1 MUST transmit the C-flow 1109 on the P-tunnel identified in its PTA. In constructing the packet's 1110 MPLS label stack, it must use the PE Distinguisher Label that was 1111 assigned by the P-tunnel's root node to the IP address of "PE2", not 1112 the label assigned to the IP address of "PE1". (Section 3.2.1.2 1113 specifies the difference between PE1 and PE2.) See section 12.3 of 1114 [RFC6513] for encapsulation details. Note that the root of the 1115 P-tunnel might be a PE other than PE1 or PE2. 1117 If, for a packet of a particular C-flow, there is no S-PMSI A-D route 1118 or I-PMSI A-D route that is a match for transmission, the packet MUST 1119 NOT be transmitted. 1121 3.2.2.4. When an S-PMSI is a 'Match for Reception' 1123 Suppose a given PE, say PE1, needs to receive multicast data packets 1124 of a particular C-flow. [RFC6625] Section 3.2 specifies procedures 1125 for determining the S-PMSI A-D route, if any, that "matches" that 1126 C-flow for reception. Those rules require that the matching S-PMSI 1127 A-D route has been originated by the upstream PE for the C-flow. The 1128 rules are modified in this section, as follows: 1130 Consider a particular C-flow. Suppose either: 1132 o the C-flow is unidirectional, and PE1 determines that its upstream 1133 PE is PE2, or 1135 o the C-flow is bidirectional, and PE1 determines that the upstream 1136 PE for its C-RPA is PE2 1138 Then the C-flow may match an installed S-PMSI A-D route that was not 1139 originated by PE2, as long as: 1141 1. the PTA of that A-D route identifies an MP2MP LSP, and 1143 2. there is an installed S-PMSI A-D route originated the root node 1144 of that LSP, or PE1 itself the root node of the LSP and there is 1145 a currently originated S-PMSI A-D route from PE1 whose PTA 1146 identifies that LSP, and 1148 3. the latter S-PMSI A-D route (the one identified in 2 just above) 1149 contains a PE Distinguisher Labels attribute that assigned an 1150 MPLS label to the IP address of PE2. 1152 However, a bidirectional C-flow never matches an S-PMSI A-D route 1153 whose NLRI contains (C-S,C-G). 1155 If a multicast data packet is received over a matching P-tunnel, but 1156 does not carry the value of the PE Distinguisher Label that has been 1157 assigned to the upstream PE for its C-flow, then the packet MUST be 1158 discarded. 1160 3.2.2.5. When an I-PMSI is a 'Match for Reception' 1162 If a PE needs to receive packets of a given C-flow (of a given MVPN) 1163 from another PE, and if, according to the conditions of 1164 Section 3.2.2.4, that C-flow does not match any S-PMSI A-D route, 1165 then the packets of the C-flow need to be received on the MVPN's 1166 I-PMSI. The P-tunnel on which the packets are expected to arrive is 1167 determined by the Intra-AS I-PMSI A-D route originated by the 1168 "distinguished PE" for the given C-flow. The PTA of that route 1169 specifies the "outer P-tunnel", and thus determines the top label 1170 that packets of that C-flow will be carrying when received. A PE 1171 that needs to receive packets of a given C-flow must determine the 1172 expected value of the second label for packets of that C-flow. This 1173 will be the value of a PE Distinguisher Label, taken from the PE 1174 Distinguisher Labels attribute of the Intra-AS I-PMSI A-D route of 1175 the root node of that outer tunnel. The expected value of the second 1176 label on received packets (corresponding to the "inner tunnel") of a 1177 given C-flow is determined according to the following rules. 1179 First, the "distinguished PE" for the C-flow is determined: 1181 o If the C-flow is not a BIDIR-PIM C-flow, the "distinguished PE" 1182 for the C-flow is its "upstream PE", as determined by the rules of 1183 [RFC6513]. 1185 o If the C-flow is a BIDIR-PIM C-flow, the "distinguished PE" for 1186 the C-flow is its "upstream PE" of the C-flow's C-RPA, as 1187 determined by the rules of [RFC6513]. 1189 The expected value of the second label is the value that the root PE 1190 of the outer tunnel has assigned, in the PE Distinguisher Labels 1191 attribute of its Intra-AS I-PMSI A-D route, to the IP address of the 1192 "distinguished PE". 1194 Packets addressed to C-G that arrive on other than the expected inner 1195 and outer P-tunnels (i.e., that arrive with unexpected values of the 1196 top two labels) MUST be discarded. 1198 3.2.3. Unpartitioned 1200 When a particular MVPN uses the Unpartitioned Method of instantiating 1201 an I-PMSI with a bidirectional P-tunnel, it MUST be the case that at 1202 least one VRF of that MVPN originates an Intra-AS I-PMSI A-D route 1203 that includes a PTA specifying a bidirectional P-tunnel. The 1204 conditions under which an Intra-AS I-PMSI A-D route must be 1205 originated from a given VRF are as specified in [RFC6514]. This 1206 document allows all but one of such routes to omit the PTA. However, 1207 each such route MAY contain a PTA. If the PTA is present, it MUST 1208 specify a bidirectional P-tunnel. As specified in [RFC6513] and 1209 [RFC6514], every PE that imports such an Intra-AS I-PMSI A-D route 1210 into one of its VRFs MUST, if the route has a PTA, join the P-tunnel 1211 specified in the route's PTA. 1213 Packets received on any of these P-tunnels are treated as having been 1214 received over the I-PMSI. The disposition of a received packet MUST 1215 NOT depend upon the particular P-tunnel over which it has been 1216 received. 1218 When a PE needs to transmit a packet on such an I-PMSI, then if that 1219 PE advertised a P-tunnel in the PTA of an Intra-AS I-PMSI A-D route 1220 that it originated, the PE SHOULD transmit the on that P-tunnel. 1221 However, any PE that transmits a packet on the I-PMSI MAY transmit it 1222 on any of the P-tunnels advertised in any of the currently installed 1223 Intra-AS I-PMSI A-D routes for its VPN. 1225 This allows a single bidirectional P-tunnel to be used to instantiate 1226 the I-PMSI, but also allows the use of multiple bidirectional 1227 P-tunnels. There may be a robustness advantage in having multiple 1228 P-tunnels available for use, but the number of P-tunnels used does 1229 not impact the functionality in any way. If there are, e.g., two 1230 P-tunnels available, these procedures allow each P-tunnel to be 1231 advertised by a single PE, but they also allow each P-tunnel to be 1232 advertised by multiple PEs. Note that the PE advertising a given 1233 P-tunnel does not have to be the root node of the tunnel. The root 1234 node might not even be a PE router, and might not originate any BGP 1235 routes at all. 1237 In the Unpartitioned Method, packets received on the I-PMSI cannot be 1238 associated with a distinguished PE, so duplicate detection using the 1239 techniques of [RFC6513] section 9.1.1 is not possible; the techniques 1240 of [RFC6513] 9.1.2 or 9.1.3 would have to be used instead. Support 1241 for C-BIDIR using the "Partitioned set of PEs" technique ([RFC6513] 1242 section 11.2 and [RFC6517] section 3.6) is not possible when the 1243 Unpartitioned Method is used. If it is desired to use that technique 1244 to support C-BIDIR, but also to use the Unpartitioned Method to 1245 instantiate the I-PMSI, then all the C-BIDIR traffic would have to be 1246 carried on an S-PMSI, where the S-PMSI is instantiated using one of 1247 the Partitioned Methods. 1249 When a PE, say PE1, needs to transmit multicast data packets of a 1250 particular C-flow to other PEs, and PE1 does not have an S-PMSI that 1251 is a "match for transmission for that C-flow (see Section 3.2.3.1), 1252 PE1 transmits the packets on one of the P-tunnel(s) that instantiates 1253 the I-PMSI. When a PE, say PE1, needs to receive multicast data 1254 packets of a particular C-flow from another PE, and PE1 does not have 1255 an S-PMSI that is a "match for reception for that C-flow (see 1256 Section 3.2.3.2), PE1 expects to receive the packets on any of the 1257 P-tunnel(s) that instantiates the I-PMSI. 1259 When a particular MVPN uses the Unpartitioned Method to instantiate a 1260 (C-*,C-*) S-PMSI or a (C-*,C-*-BIDIR) S-PMSI using a bidirectional 1261 P-tunnel, the same conditions apply as when an I-PMSI is instantiated 1262 via the Unpartitioned Method. The only difference is that a PE need 1263 not join a P-tunnel that instantiates the S-PMSI unless that PE needs 1264 to receive multicast packets on the S-PMSI. 1266 When a particular MVPN uses bidirectional P-tunnels to instantiate 1267 other S-PMSIs, different S-PMSI A-D routes that do not contain 1268 (C-*,C-*) or (C-*,C-*-BIDIR), originated by the same or by different 1269 PEs, MAY have PTAs that identify the same bidirectional tunnel, and 1270 they MAY have PTAs that do not identify the same bidirectional 1271 tunnel. 1273 While the Unpartitioned Method MAY be used to instantiate an S-PMSI 1274 to which one or more C-BIDIR flows are bound, it must be noted that 1275 the "Partitioned Set of PEs" method discussed in [RFC6513] section 1276 11.2 and [RFC6517] section 3.6 cannot be supported using the 1277 Unpartitioned Method. C-BIDIR support would have to be provided by 1278 the procedures of [RFC6513] section 11.1. 1280 3.2.3.1. When an S-PMSI is a 'Match for Transmission' 1282 Suppose a PE needs to transmit multicast data packets of a particular 1283 customer C-flow. [RFC6625] Section 3.1 gives a four-step algorithm 1284 for determining the S-PMSI A-D route, if any, that "matches" that 1285 C-flow for transmission. When referring to that section, please 1286 recall that BIDIR-PIM groups are also "Any Source Multicast" (ASM) 1287 groups. 1289 When bidirectional P-tunnels are used in the Unpartitioned Method, 1290 the same algorithm applies, with one modification, when the PTA of an 1291 S-PMSI A-D route identifies a bidirectional P-tunnel. One additional 1292 step is added to the algorithm. This new step occurs before the 1293 fourth step of the algorithm, and is as follows: 1295 o Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route 1296 currently originated by PE1, and if C-G is a BIDIR group, the 1297 C-flow matches that route. 1299 When the Unpartitioned Method is used, the PE SHOULD transmit the 1300 C-flow on the P-tunnel advertised in the in the matching S-PMSI A-D 1301 route, but it MAY transmit the C-flow on any P-tunnel that is 1302 advertised in the PTA of any installed S-PMSI A-D route that contains 1303 the same (C-S,C-G) as the matching S-PMSI A-D route. 1305 3.2.3.2. When an S-PMSI is a 'Match for Reception' 1307 Suppose a PE needs to receive multicast data packets of a particular 1308 customer C-flow. [RFC6625] Section 3.2 specifies the procedures for 1309 determining the S-PMSI A-D route, if any, that advertised the 1310 P-tunnel on which the PE should expect to receive that C-flow. 1312 When bidirectional P-tunnels are used in the Unpartitioned Method, 1313 the same procedures apply, with one modification. 1315 The last paragraph of Section 3.2.2 of [RFC6625] begins: 1317 "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from 1318 PE2, but PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, 1319 then (C-*,C-G) matches the (C-*,C-*) route if one of the following 1320 conditions holds:" 1322 This is changed to: 1324 "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from 1325 PE2, but C-G is a BIDIR group and PE1 has an installed 1326 (C-*,C-*-BIDIR) S-PMSI A-D route, then (C-*,C-G) matches that 1327 route. Otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D 1328 route from PE2, then (C-*,C-G) matches the (C-*,C-*) route if one 1329 of the following conditions holds:" 1331 When the Unpartitioned Method is used, the PE MUST join the P-tunnel 1332 that is advertised in the matching S-PMSI A-D route, and MUST also 1333 join the P-tunnels that are advertised in other installed S-PMSI A-D 1334 routes that contain the same (C-S,C-G) as the matching S-PMSI A-D 1335 route. 1337 3.2.4. Minimal Feature Set for Compliance 1339 A PE that does not provide C-BIDIR support using the "partitioned set 1340 of PEs" method may be deemed compliant to this specification if it 1341 supports the Unpartitioned Method, using either MP2MP LSPs or BIDIR- 1342 PIM multicast distribute trees as P-tunnels. 1344 A PE that does provide C-BIDIR support using the "partitioned set of 1345 PEs" method, MUST, at a minimum, be able to provide C-BIDIR support 1346 using the "Partial Mesh of MP2MP P-tunnels" variant of this method 1347 (see section 11.2 of [RFC6513]). An implementation will be deemed 1348 complaint to this minimum requirement if it can carry all of a VPN's 1349 C-BIDIR traffic on a (C-*,C-*-BIDIR) S-PMSI that is instantiated by a 1350 bidirectional P-tunnel, using the flat partitioned method. 1352 4. IANA Considerations 1354 This document has no actions for IANA. 1356 5. Security Considerations 1358 There are no additional security considerations beyond those of 1359 [RFC6513] and [RFC6514], or any that may apply to the particular 1360 protocol used to set up the bidirectional tunnels ([RFC5015], 1361 [RFC6388]). 1363 6. Acknowledgments 1365 The authors wish to thank Karthik Subramanian, Rajesh Sharma, and 1366 Apoorva Karan for their input. We also thank Yakov Rekhter for his 1367 valuable critique. 1369 Special thanks go to Jeffrey Zhang for his careful review, probing 1370 questions, and useful suggestions. 1372 7. References 1374 7.1. Normative References 1376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1377 Requirement Levels", BCP 14, RFC 2119, March 1997. 1379 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1380 Networks (VPNs)", RFC 4364, February 2006. 1382 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1383 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1384 Protocol Specification (Revised)", RFC 4601, August 2006. 1386 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1387 "Bidirectional Protocol Independent Multicast (BIDIR- 1388 PIM)", RFC 5015, October 2007. 1390 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1391 "Label Distribution Protocol Extensions for Point-to- 1392 Multipoint and Multipoint-to-Multipoint Label Switched 1393 Paths", RFC 6388, November 2011. 1395 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 1396 VPNs", RFC 6513, February 2012. 1398 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1399 Encodings and Procedures for Multicast in MPLS/BGP IP 1400 VPNs", RFC 6514, February 2012. 1402 [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, 1403 "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 1404 6625, May 2012. 1406 7.2. Informative References 1408 [MVPN-BIDIR-IR] 1409 Zhang, J., Rekhter, Y., and A. Dolganow, "Simulating 1410 'Partial Mesh of MP2MP P-Tunnels' with Ingress 1411 Replication", internet-draft draft-ietf-l3vpn-mvpn-bidir- 1412 ingress-replication-01, July 2014. 1414 [MVPN-XNET] 1415 Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP 1416 MPLS VPNs", internet-draft draft-ietf-l3vpn-mvpn-extranet- 1417 05, July 2014. 1419 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1420 Label Assignment and Context-Specific Label Space", RFC 1421 5331, August 2008. 1423 [RFC6517] Morin, T., Niven-Jenkins, B., Kamite, Y., Zhang, R., 1424 Leymann, N., and N. Bitar, "Mandatory Features in a Layer 1425 3 Multicast BGP/MPLS VPN Solution", RFC 6517, February 1426 2012. 1428 Authors' Addresses 1430 Eric C. Rosen 1431 Juniper Networks, Inc. 1432 10 Technology Park Drive 1433 Westford, Massachusetts 01886 1434 US 1436 Email: erosen@juniper.net 1438 IJsbrand Wijnands 1439 Cisco Systems, Inc. 1440 De kleetlaan 6a 1441 Diegem 1831 1442 BE 1444 Email: ice@cisco.com 1446 Yiqun Cai 1447 Microsoft 1448 1065 La Avenida 1449 Mountain View, CA 94043 1450 US 1452 Email: yiqunc@microsoft.com 1454 Arjen Boers 1456 Email: arjen@boers.com