idnits 2.17.1 draft-ietf-l3vpn-mvpn-bidir-08.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (June 2, 2014) is 3609 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (ref. 'PIM') (Obsoleted by RFC 7761) == Outdated reference: A later version (-01) exists of draft-ietf-l3vpn-mvpn-bidir-ingress-replication-00 == Outdated reference: A later version (-05) exists of draft-ietf-l3vpn-mvpn-extranet-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Eric C. Rosen (Editor) 3 Internet Draft IJsbrand Wijnands 4 Intended Status: Standards Track Cisco Systems, Inc. 5 Expires: December 2, 2014 6 Updates: 6513,6625 Yiqun Cai 7 Microsoft 9 Arjen Boers 11 June 2, 2014 13 MVPN: Using Bidirectional P-Tunnels 15 draft-ietf-l3vpn-mvpn-bidir-08.txt 17 Abstract 19 A set of prior RFCs specify procedures for supporting multicast in 20 BGP/MPLS IP VPNs. These procedures allow customer multicast data to 21 travel across a service provider's backbone network through a set of 22 multicast tunnels. The tunnels are advertised in certain BGP 23 multicast "auto-discovery" routes, by means of a BGP attribute known 24 as the "Provider Multicast Service Interface (PMSI) Tunnel 25 attribute". Encodings have been defined that allow the PMSI Tunnel 26 attribute to identify bidirectional (multipoint-to-multipoint) 27 multicast distribution trees. However, the prior RFCs do not provide 28 all the necessary procedures for using bidirectional tunnels to 29 support multicast VPNs. This document updates RFCs 6513 and 6625 by 30 specifying those procedures. In particular, it specifies the 31 procedures for assigning customer multicast flows (unidirectional or 32 bidirectional) to specific bidirectional tunnels in the provider 33 backbone, for advertising such assignments, and for determining which 34 flows have been assigned to which tunnels. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as 44 Internet-Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 Copyright and License Notice 59 Copyright (c) 2014 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1 Introduction .......................................... 4 75 1.1 Terminology ........................................... 4 76 1.2 Overview .............................................. 9 77 1.2.1 Bidirectional P-tunnel Technologies ................... 10 78 1.2.2 Reasons for Using Bidirectional P-tunnels ............. 10 79 1.2.3 Knowledge of Group-to-RP and/or Group-to-RPA Mappings . 11 80 1.2.4 PMSI Instantiation Methods ............................ 12 81 2 The All BIDIR-PIM Wild Card ........................... 14 82 3 Using Bidirectional P-Tunnels ......................... 15 83 3.1 Procedures Specific to the Tunneling Technology ....... 15 84 3.1.1 BIDIR-PIM P-Tunnels ................................... 15 85 3.1.2 MP2MP LSPs ............................................ 16 86 3.2 Procedures Specific to the PMSI Instantiation Method .. 16 87 3.2.1 Flat Partitioning ..................................... 17 88 3.2.1.1 When an S-PMSI is a 'Match for Transmission' .......... 18 89 3.2.1.2 When an I-PMSI is a 'Match for Transmission' .......... 19 90 3.2.1.3 When an S-PMSI is a 'Match for Reception' ............. 20 91 3.2.1.4 When an I-PMSI is a 'Match for Reception .............. 21 92 3.2.2 Hierarchical Partitioning ............................. 21 93 3.2.2.1 Advertisement of PE Distinguisher Labels .............. 23 94 3.2.2.2 When an S-PMSI is a 'Match for Transmission' .......... 24 95 3.2.2.3 When an I-PMSI is a 'Match for Transmission' .......... 25 96 3.2.2.4 When an S-PMSI is a 'Match for Reception' ............. 25 97 3.2.2.5 When an I-PMSI is a 'Match for Reception' ............. 26 98 3.2.3 Unpartitioned ......................................... 27 99 3.2.3.1 When an S-PMSI is a 'Match for Transmission' .......... 29 100 3.2.3.2 When an S-PMSI is a 'Match for Reception' ............. 29 101 3.2.4 Minimal Feature Set for Compliance .................... 30 102 4 IANA Considerations ................................... 30 103 5 Security Considerations ............................... 30 104 6 Acknowledgments ....................................... 31 105 7 Authors' Addresses .................................... 31 106 8 Normative References .................................. 32 107 9 Informative References ................................ 32 109 1. Introduction 111 The RFCs that specify multicast support for BGP/MPLS IP VPNs ([MVPN], 112 [MVPN-BGP], [MVPN-WILDCARDS]) allow customer multicast data to be 113 transported across a service provider's network though a set of 114 multicast tunnels. These tunnels are advertised in BGP multicast 115 "auto-discovery" (A-D) routes, by means of a BGP attribute known as 116 the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. 117 The base specifications allow the use of bidirectional 118 (multipoint-to-multipoint) multicast distribution trees, and describe 119 how to encode the identifiers for bidirectional trees into the PMSI 120 Tunnel attribute. However, those specifications do not provide all 121 the necessary detailed procedures for using bidirectional tunnels; 122 the full specification of these procedures was considered to be 123 outside the scope of those documents. The purpose of this document 124 is to provide all the necessary procedures for using bidirectional 125 trees in a service provider's network to carry the multicast data of 126 VPN customers. 128 1.1. Terminology 130 This document uses terminology from [MVPN] and, in particular, uses 131 the prefixes "C-" and "P-", as specified in Section 3.1 of [MVPN], to 132 distinguish addresses in the "customer address space" from addresses 133 in the "provider address space". The following terminology and 134 acronyms are particularly important in this document: 136 - MVPN 138 Multicast Virtual Private Network -- a VPN [L3VPN] in which 139 multicast service is offered. 141 - VRF 143 VPN Routing and Forwarding table [L3VPN]. 145 - PE 147 A Provider Edge router, as defined in [L3VPN]. 149 - LSP 151 An MPLS Label Switched Path. 153 - P2MP Point-to-Multipoint. 155 - MP2MP 157 Multipoint-to-multipoint. 159 - Unidirectional 161 Adjective for a multicast distribution tree in which all traffic 162 travels downstream from the root of the tree. Traffic can enter 163 a unidirectional tree only at the root. A P2MP LSP is one type 164 of unidirectional tree. Multicast distribution trees set up by 165 PIM-SM [PIM] are also unidirectional trees. 167 Data traffic traveling along a unidirectional multicast 168 distribution tree is sometimes referred to in this document as 169 "unidirectional traffic". 171 - Bidirectional 173 Adjective for a multicast distribution tree in which traffic may 174 travel both upstream (towards the root) and downstream (away from 175 the root). Traffic may enter a bidirectional tree at any node. 176 A MP2MP LSP is one type of bidirectional tree. Multicast 177 distribution trees created by BIDIR-PIM [BIDIR-PIM] are also 178 bidirectional trees. 180 Data traffic traveling along a bidirectional multicast 181 distribution tree is sometimes referred to in this document as 182 "bidirectional traffic". 184 - P-tunnel 186 A tunnel through the network of one or more Service Providers 187 (SPs). In this document, the P-tunnels we speak of are are 188 instantiated as bidirectional multicast distribution trees. 190 - C-S 192 Multicast Source. A multicast source address, in the address 193 space of a customer network. 195 - C-G 197 Multicast Group. A multicast group address (destination address) 198 in the address space of a customer network. When used without 199 qualification, "C-G" may refer to either a unidirectional group 200 address or a bidirectional group address. 202 - C-G-BIDIR 204 A bidirectional multicast group address (i.e., a group address 205 whose IP multicast distribution tree is built by BIDIR-PIM). 207 - C-multicast flow or C-flow 209 A customer multicast flow. A C-flow travels through VPN customer 210 sites on a multicast distribution tree set up by the customer. 211 These trees may be unidirectional or bidirectional, depending 212 upon the multicast routing protocol used by the customer. A 213 C-flow travels between VPN customer sites by traveling through 214 P-tunnels. 216 A C-flow from a particular customer source is identified by the 217 ordered pair (source address, group address), where each address 218 is in the customer's address space. The identifier of such a 219 C-flow is usually written as (C-S,C-G). 221 If a customer uses the "Any Source Multicast" (ASM) model, the 222 some or all of the customer's C-flows may be traveling along the 223 same "shared tree". In this case, we will speak of a "(C-*,C-G)" 224 flow to refer to a set of C-flows that travel along the same 225 shared tree in the customer sites. 227 - C-BIDIR flow or bidirectional C-flow 229 A C-flow that, in the VPN customer sites, travels along a 230 bidirectional multicast distribution tree. The term "C-BIDIR 231 flow" indicates that the customer's bidirectional tree has been 232 set up by BIDIR-PIM. 234 - RP 236 A "Rendezvous Point", as defined in [PIM]. 238 - C-RP 240 A Rendezvous Point whose address is in the customer's address 241 space. 243 - RPA 245 A "Rendezvous Point Address", as defined in [BIDIR-PIM]. 247 - C-RPA 249 An RPA in the customer's address space. 251 - P-RPA 253 An RPA in the Service Provider's address space 255 - Selective P-tunnel 257 A P-tunnel that is joined only by Provider Edge (PE) routers that 258 need to receive one or more of the C-flows that are traveling 259 through that P-tunnel. 261 - Inclusive P-tunnel 263 A P-tunnel that is joined by all PE routers that attach to sites 264 of a given MVPN. 266 - Intra-AS I-PMSI A-D route 268 Intra Autonomous System Inclusive Provider Multicast Service 269 Interface Auto-Discovery route. Carried in BGP Update messages, 270 these routes can be used to advertise the use of Inclusive 271 P-tunnels. See [MVPN-BGP] section 4.1. 273 - S-PMSI A-D route 275 Selective Provider Multicast Service Interface Auto-Discovery 276 route. Carried in BGP Update messages, these routes are used to 277 advertise the fact that a particular C-flow or a particular set 278 of C-flows is bound to (i.e., is traveling through) a particular 279 P-tunnel. See [MVPN-BGP] section 4.3. 281 - (C-S,C-G) S-PMSI A-D route 283 An S-PMSI A-D route whose NLRI ("Network Layer Reachability 284 Information") contains C-S in its "Multicast Source" field and 285 C-G in its "Multicast Group" field. 287 - (C-*,C-G) S-PMSI A-D route 289 An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its 290 "Multicast Source" field and C-G in its "Multicast Group" field. 291 See [MVPN-WILDCARDS]. 293 - (C-*,C-G-BIDIR) S-PMSI A-D route 295 An S-PMSI A-D route whose NLRI contains the wildcard (C-*) in its 296 "Multicast Source" field and C-G-BIDIR in its "Multicast Group" 297 field. See [MVPN-WILDCARDS]. 299 - (C-*,C-*) S-PMSI A-D route 301 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 302 "Multicast Source" field and the wildcard C-* in its "Multicast 303 Group" field. See [MVPN-WILDCARDS]. 305 - (C-*,C-*) S-PMSI A-D route 307 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 308 "Multicast Source" field and the wildcard C-* in its "Multicast 309 Group" field. See [MVPN-WILDCARDS]. 311 - (C-*,C-*-BIDIR) S-PMSI A-D route 313 An S-PMSI A-D route whose NLRI contains the wildcard C-* in its 314 "Multicast Source" field and the wildcard "C-*-BIDIR" in its 315 "Multicast Group" field. See section 2 of this document. 317 - (C-S,C-*) S-PMSI A-D route 319 An S-PMSI A-D route whose NLRI contains C-S in its "Multicast 320 Source" field and the wildcard C-* in its "Multicast Group" 321 field. See [MVPN-WILDCARDS]. 323 - Wildcard S-PMSI A-D route 325 A (C-*,C-G) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route, or 326 a (C-S,C-*) S-PMSI A-D route, or a (C-*,C-*-BIDIR) S-PMSI A-D 327 route. 329 - PTA 331 PMSI Tunnel attribute, a BGP attribute that identifies a 332 P-tunnel. See [MVPN-BGP] section 8. 334 The terminology used for categorizing S-PMSI A-D routes will also be 335 used for categorizing the S-PMSIs advertised by those routes. E.g., 336 the S-PMSI advertised by a (C-*,C-G) S-PMSI A-D route will be known 337 as a "(C-*,C-G) S-PMSI". 339 Familiarity with multicast concepts and terminology [PIM] is also 340 presupposed. 342 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 343 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 344 document, when and only when appearing in all caps, are to be 345 interpreted as described in [RFC2119]. 347 1.2. Overview 349 The base documents for MVPN ([MVPN], [MVPN-BGP]) define a "PMSI 350 Tunnel attribute" (PTA). This is a BGP Path Attribute that may be 351 attached to the BGP "I-PMSI A-D routes" and "S-PMSI A-D routes" that 352 are defined in those documents. The base documents define the way in 353 which the identifier of a bidirectional P-tunnel is to be encoded in 354 the PTA. However, those documents do not contain the full set of 355 specifications governing the use bidirectional P-tunnels; rather, 356 those documents declare the full set of specifications for using 357 bidirectional P-tunnels to be outside their scope. Similarly, the 358 use of bidirectional P-tunnels advertised in wildcard S-PMSI A-D 359 routes is declared by [MVPN-WILDCARDS] to be "out of scope." 361 This document provides the specifications governing the use of 362 bidirectional P-tunnels to provide MVPN support. This includes the 363 procedures for assigning C-flows to specific bidirectional P-tunnels, 364 for advertising the fact that a particular C-flow has been assigned 365 to a particular bidirectional P-tunnel, and for determining the 366 bidirectional P-tunnel on which a given C-flow may be expected. 368 The C-flows carried on bidirectional P-tunnels may themselves be 369 either unidirectional or bidirectional. Procedures are provided for 370 both cases. 372 This document does not specify any new data encapsulations for 373 bidirectional P-tunnels. Section 12 ("Encapsulations") of [MVPN] 374 applies unchanged. 376 With regard to the procedures for using bidirectional P-tunnels to 377 instantiate PMSIs, if there is any conflict between the procedures 378 specified in this document and the procedures of [MVPN], [MVPN-BGP], 379 or [MVPN-WILDCARDS], the procedures of this document take precedence. 381 The use of bidirectional P-tunnels to support extranets [MVPN-XNET] 382 is outside the scope of this document. The use of bidirectional 383 P-tunnels as "segmented P-tunnels" (see [MVPN] section 8 and various 384 sections of [MVPN-BGP]) is also outside the scope of this doucment. 386 1.2.1. Bidirectional P-tunnel Technologies 388 This document supports two different technologies for creating and 389 maintaining bidirectional P-tunnels: 391 - Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs) that 392 are created through the use of the Label Distribution Protocol 393 (LDP) Multipoint-to-Multipoint extensions [mLDP]. 395 - Multicast distribution trees that are created through the use of 396 BIDIR-PIM [BIDIR-PIM]. 398 An implementation may be considered compliant with this document if 399 it provides either one of these tunneling technologies. Other 400 bidirectional tunnel technologies are outside the scope of this 401 document. 403 1.2.2. Reasons for Using Bidirectional P-tunnels 405 Bidirectional P-tunnels can be used to instantiate I-PMSIs and/or 406 S-PMSIs. 408 An SP may decide to use bidirectional P-tunnels to instantiate 409 certain I-PMSIs and/or S-PMSIs in order to provide its customers with 410 C-BIDIR support, using the "Partitioned Set of PEs" technique 411 discussed in [MVPN] section 11.2 and [RFC6517] section 3.6. This 412 technique can be used whether the C-BIDIR flows are being carried on 413 an I-PMSI or an S-PMSI. 415 Even if an SP does not need to provide C-BIDIR support, it may still 416 decide to use bidirectional P-tunnels, in order to save state in the 417 network's transit nodes. For example, if an MVPN has n PEs attached 418 to sites with multicast sources, and there is an I-PMSI for that 419 MVPN, instantiating the I-PMSI with unidirectional P-tunnels (i.e., 420 with P2MP multicast distribution trees) requires n multicast 421 distribution trees, each one rooted at a different PE. If the I-PMSI 422 is instantiated by a bidirectional P-tunnel, a single multicast 423 distribution tree can be used. 425 An SP may decide to use bidirectional P-tunnels for either or both of 426 these reasons. Note that even if the reason for using bidirectional 427 P-tunnels is to provide C-BIDIR support, the same P-tunnels can also 428 be used to carry unidirectional C-flows, if that is the choice of the 429 SP. 431 These two reasons for using bidirectional P-tunnels may appear to be 432 somewhat in conflict with each other, since (as will be seen in 433 subsequent sections), the use of bidirectional P-tunnels for C-BIDIR 434 support may require multiple bidirectional P-tunnels per VPN. Each 435 such P-tunnel is associated with a particular "distinguished PE", and 436 can only carry those C-BIDIR flows whose C-RPAs are reachable through 437 its distinguished PE. However, on platforms that support MPLS 438 upstream-assigned labels [RFC5331], "PE Distinguisher Labels" can be 439 used to aggregate multiple bidirectional P-tunnels onto a single 440 "outer" bidirectional P-tunnel, thereby allowing one to provide 441 C-BIDIR support with minimal state at the transmit nodes. 443 Since there are two fundamentally different reasons for using 444 bidirectional P-tunnels, and since many deployed router platforms do 445 not support upstream-assigned labels at the current time, this 446 document specifies several different methods of using bidirectional 447 P-tunnels to instantiate PMSIs. We refer to these as "PMSI 448 Instantiation Methods". The method or methods deployed by any 449 particular SP will depend upon that SP's goals and engineering 450 tradeoffs, and upon the set of platforms deployed by that SP. 452 The rules for using bidirectional P-tunnels in I-PMSI or S-PMSI A-D 453 routes are not exactly the same as the rules for using unidirectional 454 P-tunnels, and the rules are also different for the different PMSI 455 instantiation methods. Subsequent sections of this document specify 456 the rules in detail. 458 1.2.3. Knowledge of Group-to-RP and/or Group-to-RPA Mappings 460 If a VPN customer is making use of a particular "Any Source 461 Multicast" (ASM) group address, the PEs of that VPN generally need to 462 know the group-to-RP mappings that are used within the VPN. If a VPN 463 customer is making use of BIDIR-PIM group addresses, the PEs need to 464 know the group-to-RPA mappings that are used within the VPN. 465 Commonly, the PEs obtain this knowledge either through provisioning 466 or by participating in a dynamic "group-to-RP(A) mapping discovery 467 protocol" that runs within the VPN. However, the way in which this 468 knowledge is obtained is outside the scope of this document. 470 The PEs also need to be able to forward traffic towards the C-RPs 471 and/or C-RPAs, and to determine whether the next hop "interface" of 472 the route to a particular C-RP(A) is a VRF interface or a PMSI. This 473 is done by applying the procedures of [MVPN] section 5.1. 475 1.2.4. PMSI Instantiation Methods 477 This document specifies three methods for using bidirectional 478 P-tunnels to instantiate PMSIs: the Flat Partitioned Method, the 479 Hierarchical Partitioned Method, and the Unpartitioned Method. 481 - Partitioned Methods 483 In the Partitioned Methods, a particular PMSI is instantiated by 484 a set of bidirectional P-tunnels. These P-tunnels may be 485 aggregated (as "inner" P-tunnels) into a single "outer" 486 bidirectional P-tunnel ("Hierarchical Partitioning"), or they may 487 be unaggregated ("Flat Partitioning"). Any PE that joins one of 488 these P-tunnels can transmit a packet on it, and the packet will 489 be received by all the other PEs that have joined the P-tunnel. 490 For each such P-tunnel (each "inner" P-tunnel, in the case of 491 Hierarchical Partitioning) there is one PE that is its 492 "distinguished PE". When a PE receives a packet from a given 493 P-tunnel, the PE can determine from the packet's encapsulation 494 the P-tunnel is has arrived on, and can thus infer the identity 495 of the distinguished PE associated with the packet. This 496 association plays an important role in the treatment of the 497 packet, as specified later on in this document. 499 The number of P-tunnels needed (the number of "inner" P-tunnels 500 needed, if Hierarchical Partitioning is used) depends upon a 501 number of factors that are described later in this document. 503 The Hierarchical Partitioned Method requires the use of 504 upstream-assigned MPLS labels ("PE Distinguisher Labels"), and 505 requires the use of the PE Distinguisher Labels attribute in BGP. 506 The Flat Partitioned Method requires neither of these. 508 The Partitioned Method (either flat or hierarchical) is a 509 pre-requisite for implementing the "Partitioned Sets of PEs" 510 technique of supporting C-BIDIR, as discussed in [MVPN] section 511 11.2. The Partitioned Method (either flat or hierarchical) is 512 also a pre-requisite for applying the "Discarding Packets from 513 Wrong PE" technique, discussed in [MVPN] Section 9.1.1, to a PMSI 514 that is instantiated by a bidirectional P-tunnel. 516 The Flat Partitioned Method is a pre-requisite for implementing 517 the "Partial Mesh of MP2MP P-tunnels" technique for carrying 518 customer bidirectional (C-BIDIR) traffic, as discussed in [MVPN] 519 Section 11.2.3. 521 The Hierarchical Partitioned Method is a pre-requisite for 522 implementing the "Using PE Distinguisher Labels" technique of 523 carrying customer bidirectional (C-BIDIR) traffic, as discussed 524 in [MVPN] Section 11.2.2. 526 Note that a particular deployment may choose to use the 527 Partitioned Method for carrying the C-BIDIR traffic on 528 bidirectional P-tunnels, while carrying other traffic either on 529 unidirectional P-tunnels, or on bidirectional P-tunnels using the 530 Unpartitioned Method. Routers in a given deployment must be 531 provisioned to know which PMSI instantiation method to use for 532 which PMSIs. 534 There may be ways of implementing the Partitioned Method with 535 PMSIs that are instantiated by unidirectional P-tunnels. (See, 536 e.g., [MVPN-BIDIR-IR].) However, that is outside the scope of 537 the current document. 539 - Unpartitioned Method 541 In the Unpartitioned Method, a particular PMSI can be 542 instantiated by a single bidirectional P-tunnel. Any PE that 543 joins the tunnel can transmit a packet on it, and the packet will 544 be received by all the other PEs that have joined the tunnel. 545 The receiving PEs can determine the tunnel on which the packet 546 was transmitted, but they cannot determine which PE transmitted 547 the packet, nor can they associate the packet with any particular 548 "distinguished PE". 550 When the Unpartitioned Method is used, this document does not 551 mandate that only one bidirectional P-tunnel be used to 552 instantiate each PMSI. It allows for the case where more than 553 one P-tunnel is used. In this case, the transmitting PEs will 554 have a choice of which such P-tunnel to use when transmitting, 555 and the receiving PEs must be prepared to receive from any of 556 those P-tunnels. The use of multiple P-tunnels in this case 557 provides additional robustness, but no additional functionality. 559 I-PMSIs may be instantiated by bidirectional P-tunnels using either 560 the Partitioned (either Flat or Hierarchical) or the Unpartitioned 561 Method. The method used for a given MVPN is determined by 562 provisioning. It SHOULD be possible to provision this on a per-MVPN 563 basis, but all the VRFs of a single MVPN MUST be provisioned to use 564 the same method for the given MVPN's I-PMSI. 566 If a bidirectional P-tunnel is used to instantiate an S-PMSI 567 (including the case of a (C-*,C-*) S-PMSI), either the Partitioned 568 Method (either Flat or Hierarchical) or the Unpartitioned Method may 569 be used. The method used by a given VRF used is determined by 570 provisioning. It SHOULD be possible to provision this on a per-MVPN 571 basis, but all the VRFs of a single MVPN MUST be provisioned to use 572 the same method for those of their S-PMSIs that are instantiated by 573 bidirectional P-tunnels. 575 If the Partitioned Method is used, all the VRFs of a single MVPN MUST 576 be provisioned to use the same variant of the Partitioned Method, 577 i.e., either they must all use the Flat Partitioned Method, or they 578 must all use the Hierarchical Partitioned Method. 580 It is valid to use the Unpartitioned Method to instantiate the 581 I-PMSIs, while using one of the Partitioned Methods to instantiate 582 the S-PMSIs. 584 It is valid to instantiate some S-PMSIs by unidirectional P-tunnels 585 and others by bidirectional P-tunnels. 587 The procedures for the use of bidirectional P-tunnels, specified in 588 subsequent sections of this document, depend on both the tunnel 589 technology and on the PMSI instantiation method. Note that this 590 document does not necessarily specify procedures for every possible 591 combination of tunnel technology and PMSI instantiation method. 593 2. The All BIDIR-PIM Wild Card 595 When an MVPN customer is using BIDIR-PIM, it is useful to be able to 596 advertise an S-PMSI A-D route whose semantics are: "by default, all 597 BIDIR-PIM C-multicast traffic (within a given VPN) that has not been 598 bound to any other P-tunnel is bound to the bidirectional P-tunnel 599 identified by the PTA of this route". This can be especially useful 600 if one is using a bidirectional P-tunnel to carry the C-BIDIR flows, 601 while using unidirectional P-tunnels to carry other C-flows. To do 602 this, it is necessary to have a way to encode a (C-*,C-*) wildcard 603 that is restricted to BIDIR-PIM C-groups. 605 We therefore define a special value of the group wildcard, whose 606 meaning is "all BIDIR-PIM groups". The "BIDIR-PIM groups wildcard" 607 is encoded as a group field whose length is 8 bits and whose value is 608 zero. That is, the "multicast group length" field contains the value 609 0x08, and the "multicast group" field is a single octet containing 610 the value 0x00. We will use the notation (C-*,C-*-BIDIR) to refer to 611 the "all BIDIR-PIM groups" wildcard. 613 3. Using Bidirectional P-Tunnels 615 A bidirectional P-tunnel may be advertised in the PTA of an Intra-AS 616 I-PMSI A-D route or in the PTA of an S-PMSI A-D route. The 617 advertisement of a bidirectional P-tunnel in the PTA of an Inter-AS 618 I-PMSI A-D route is outside the scope of this document. 620 3.1. Procedures Specific to the Tunneling Technology 622 This section discusses the procedures that are specific to a given 623 tunneling technology (BIDIR-PIM or MP2MP mLDP), but that are 624 independent of the method (Unpartitioned, Flat Partitioned, or 625 Hierarchical Partitioned) used to instantiate a PMSI. 627 3.1.1. BIDIR-PIM P-Tunnels 629 Each BIDIR-PIM P-Tunnel is identified by a unique P-group address 630 [MVPN, section 3.1]. (The P-group address is called a "P-Multicast 631 Group" in [MVPN-BGP]). Section 5 of [MVPN-BGP] specifies the way to 632 identify a particular BIDIR-PIM P-tunnel in the PTA of an I-PMSI or 633 S-PMSI A-D route. 635 Ordinary BIDIR-PIM procedures are used to set up the BIDIR-PIM 636 P-tunnels. A BIDIR-PIM P-group address is always associated with a 637 unique "Rendezvous Point Address" (RPA) in the SP's address space. 638 We will refer to this as the "P-RPA". Every PE needing to join a 639 particular BIDIR-PIM P-tunnel must be able to determine the P-RPA 640 that corresponds to the P-tunnel's P-group address. To construct the 641 P-tunnel, PIM Join/Prune messages are sent along the path from the PE 642 to the P-RPA. Any P routers along that path must also be able to 643 determine the P-RPA, so that they too can send PIM Join/Prune 644 messages towards it. The method of mapping a P-group address to an 645 RPA may be static configuration, or some automated means of RPA 646 discovery that is outside the scope of this specification. 648 If a BIDIR-PIM P-tunnel is used to instantiate an I-PMSI or an 649 S-PMSI, it is RECOMMENDED that the path from each PE in the tunnel to 650 the RPA consist entirely of point-to-point links. On a 651 point-to-point link, there is no ambiguity in determining which 652 router is upstream towards a particular RPA, so the BIDIR-PIM 653 "Designated Forwarder Election" is very quick and simple. Use of a 654 BIDIR-PIM P-tunnel containing multiaccess links is possible, but 655 considerably more complex. 657 The use of BIDIR-PIM P-tunnels to support the Hierarchical 658 Partitioned Method is outside the scope of this document. 660 When the PTA of an Intra-AS I-PMSI A-D route or an S-PMSI A-D route 661 identifies a BIDIR-PIM tunnel, the originator of the route SHOULD NOT 662 include a PE Distinguisher Labels attribute. If it does, that 663 attribute MUST be ignored. When we say the attribute is "ignored", 664 we do not mean that its normal BGP processing is not done, but that 665 the attribute has no effect on the data plane. It MUST however be 666 treated by BGP as if it were an unsupported optional transitive 667 attribute. (PE Distinguisher Labels are used for the Hierarchical 668 Partitioning Method, but this document does not provide support for 669 the Hierarchical Partitioning Method with BIDIR-PIM P-tunnels.) 671 3.1.2. MP2MP LSPs 673 Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding 674 Equivalence Class) element" [mLDP]. The FEC element contains the IP 675 address of the "root node", followed by an "opaque value" that 676 identifies the MP2MP LSP uniquely in the context of the root node's 677 IP address. This opaque value may be configured or autogenerated, 678 and within an MVPN, there is no need for different root nodes to use 679 the same opaque value. The mLDP specification supports the use of 680 several different ways of constructing the tunnel identifiers. The 681 current specification does not place any restriction on the type of 682 tunnel identifier that might be used. However, a given 683 implementation might not support every possible type of tunnel 684 identifier. 686 Section 5 of [MVPN-BGP] specifies the way to identify a particular 687 MP2MP P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route. 689 Ordinary mLDP procedures for MP2MP LSPs are used to set up the MP2MP 690 LSP. 692 3.2. Procedures Specific to the PMSI Instantiation Method 694 When either the Flat Partitioned Method or the Hierarchical 695 Partitioned Method is used to implement the "Partitioned Sets of PEs" 696 method of supporting C-BIDIR, as discussed in section 11.2 of [MVPN] 697 and section 3.6 of [RFC6517], a C-BIDIR flow MUST be carried only on 698 an I-PMSI or on a (C-*,C-G-BIDIR), (C-*,C-*-BIDIR), or (C-*,C-*) 699 S-PMSI. A PE MUST NOT originate any (C-S,C-G-BIDIR) S-PMSI A-D 700 routes. (Though it may of course originate (C-S,C-G) S-PMSI A-D 701 routes for C-G's that are not C-BIDIR groups.) Packets of a C-BIDIR 702 flow MUST NOT be carried on a (C-S,C-*) S-PMSI. 704 Sections 3.2.1 and 3.2.2 specify additional details of the two 705 Partitioned Methods. 707 3.2.1. Flat Partitioning 709 The procedures of this section and its sub-sections apply when (and 710 only when) the Flat Partitioned Method is used. This method is 711 introduced in [MVPN] Section 11.2.3, where it is called "Partial Mesh 712 of MP2MP P-tunnels". This method can be used with MP2MP LSPs or with 713 BIDIR-PIM P-tunnels. 715 When a PE originates an I-PMSI or S-PMSI A-D route whose PTA 716 specifies a bidirectional P-tunnel, the PE MUST be the root node of 717 the specified P-tunnel. It follows that two different PEs may not 718 advertise the same bidirectional P-tunnel. Any PE that receives a 719 packet from the P-tunnel can infer the identity of the P-tunnel from 720 the packet's encapsulation. Once the identity of the P-tunnel is 721 known, the root node of the P-tunnel is also known. The root node of 722 the P-tunnel on which the packet arrived is treated as the 723 "distinguished PE" for that packet. 725 If MP2MP LSPs are used, each P-tunnel MUST have have a distinct MP2MP 726 FEC (i.e., distinct combination of "root node" and "opaque value"). 727 The PE advertising the tunnel MUST be the same PE identified in the 728 "root node" field of the MP2MP FEC that is encoded in the PTA. 730 If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a 731 distinct P-group address. The PE advertising the tunnel will be 732 considered to be the root node of the tunnel. Note that this creates 733 a unique mapping from P-group address to "root node". 735 The Flat Partitioned Method does not use upstream-assigned labels in 736 the data plane, and hence does not use the BGP PE Distinguisher 737 Labels attribute. When this method is used, I-PMSI and/or S-PMSI A-D 738 routes SHOULD NOT contain a PE Distinguisher Labels attribute; if 739 such an attribute is present in a received I-PMSI or S-PMSI A-D 740 route, it MUST be ignored. (When we say the attribute is "ignored", 741 we do not mean that its normal BGP processing is not done, but that 742 the attribute has no effect on the data plane. It MUST however be 743 treated by BGP as if it were an unsupported optional transitive 744 attribute.) 746 When the Flat Partitioned Method is used to instantiate the I-PMSIs 747 of a given MVPN, every PE in that MVPN that originates an Intra-AS 748 I-PMSI A-D route MUST include a PTA that specifies a bidirectional 749 P-tunnel. If the intention is to carry C-BIDIR traffic on the 750 I-PMSI, a PE MUST originate an Intra-AS I-PMSI A-D route if one of 751 its VRF interfaces is the next hop interface on its best path to the 752 C-RPA of any bidirectional C-group of the MVPN. 754 When the Flat Partitioned Method is used to instantiate a (C-*,C-*) 755 S-PMSI, a (C-*,C-*-BIDIR) S-PMSI, or a (C-*,C-G-BIDIR) S-PMSI, a PE 756 that originates the corresponding S-PMSI A-D route MUST include in 757 that route a PTA specifying a bidirectional P-tunnel. Per the 758 procedures of [MVPN] and [MVPN-BGP], a PE will originate such an 759 S-PMSI A-D route only if one of the PE's VRF interfaces is the next 760 hop interface of the PE's best path to the C-RPA of a C-BIDIR group 761 that is to be carried on the specified S-PMSI. 763 PMSIs that are instantiated via the Flat Partitioned Method may carry 764 customer bidirectional traffic AND customer unidirectional traffic. 765 The rules of sections 3.2.1.1 and 3.2.1.2 determine when a given 766 customer multicast packet is a "match for transmission" to a given 767 PMSI. However, if the "Partitioned Set of PEs" method of supporting 768 C-BIDIR traffic is being used, the PEs must be provisioned in such a 769 way that packets from a C-BIDIR flow never match any PMSI that is not 770 instantiated by a bidirectional P-tunnel. (For example, if the 771 (C-*,C-*) S-PMSI were not instantiated by a bidirectional P-tunnel, 772 one could meet this requirement by carrying all C-BIDIR traffic on a 773 (C-*,C-*-BIDIR) S-PMSI.) 775 When a PE receives a customer multicast data packet from a 776 bidirectional P-tunnel, it associates that packet with a 777 "distinguished PE". The distinguished PE for a given packet is the 778 root node of the tunnel from which the packet is received. The rules 779 of section 3.2.1.1 and 3.2.1.2 ensure that: 781 - If the received packet is part of a unidirectional C-flow, its 782 "distinguished PE" is the PE that transmitted the packet onto the 783 P-tunnel. 785 - If the received packet is part of a bidirectional C-flow, its 786 "distinguished PE" is not necessarily the PE that transmitted it, 787 but rather the transmitter's "upstream PE" for the C-RPA of the 788 bidirectional C-group. 790 The rules of sections 3.2.1.3 and 3.2.1.4 allow the receiving PEs to 791 determine the expected distinguished PE for each C-flow, and ensure 792 that a packet will be discarded if its distinguished PE is not the 793 expected distinguished PE for the C-flow to which the packet belongs. 794 This prevents duplication of data for both bidirectional and 795 unidirectional C-flows. 797 3.2.1.1. When an S-PMSI is a 'Match for Transmission' 799 Suppose a given PE, say PE1, needs to transmit multicast data packets 800 of a particular C-flow. [MVPN-WILDCARDS] Section 3.1 gives a 801 four-step algorithm for determining the S-PMSI A-D route, if any, 802 that "matches" that C-flow for transmission. 804 If the C-flow is not a BIDIR-PIM C-flow, those rules apply unchanged; 805 the remainder of this section applies only to C-BIDIR flows. If a 806 C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 807 are given below: 809 - If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's 810 route to the C-RPA is via a VRF interface, then: 812 * If there is a (C-*,C-G-BIDIR) S-PMSI A-D route currently 813 originated by PE1, then the C-flow matches that route. 815 * Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route 816 currently originated by PE1, then the C-flow matches that 817 route. 819 * Otherwise, if there is a (C-*,C-*) S-PMSI A-D route currently 820 originated by PE1, then the C-flow matches that route. 822 - If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be 823 some other PE, say PE2, then: 825 * If there is an installed (C-*,C-G-BIDIR) S-PMSI A-D route 826 originated by PE2, then the C-flow matches that route. 828 * Otherwise, if there is an installed (C-*,C-*-BIDIR) S-PMSI 829 A-D route originated by PE2, then the C-flow matches that 830 route. 832 * Otherwise, if there is an installed (C-*,C-*) S-PMSI A-D 833 route originated by PE2, then the C-flow matches that route. 835 If there is an S-PMSI A-D route that matches a given C-flow, and if 836 PE1 needs to transmit packets of that C-flow or other PEs, then it 837 MUST transmit those packets on the bidirectional P-tunnel identified 838 in the PTA of the matching S-PMSI A-D route. 840 3.2.1.2. When an I-PMSI is a 'Match for Transmission' 842 Suppose a given PE, say PE1, needs to transmit packets of a given 843 C-flow (of a given MVPN) to other PEs, but according to the 844 conditions of section 3.2.1.1 and/or [MVPN-WILDCARDS] section 3.1, 845 that C-flow does not match any S-PMSI A-D route. Then the packets of 846 the C-flow need to be transmitted on the MVPN's I-PMSI. 848 If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the 849 C-flow MUST be transmitted is the one identified in the PTA of the 850 Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. 852 If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the 853 rules applied by PE1 are: 855 - If the C-RPA for C-G-BIDIR is a C-address of PE1, or if PE1's 856 route to the C-RPA is via a VRF interface, then if there is an 857 I-PMSI A-D route currently originated by PE1, then the C-flow 858 MUST be transmitted on the P-tunnel identified in the PTA of that 859 I-PMSI A-D route. 861 - If PE1 determines the upstream PE for C-G-BIDIR's C-RPA to be 862 some other PE, say PE2, then if there is an installed I-PMSI A-D 863 route originated by PE2, the C-flow MUST be transmitted on the 864 P-tunnel identified in the PTA of that route. 866 If there is no I-PMSI A-D route meeting the above conditions, the 867 C-flow MUST NOT be transmitted. 869 3.2.1.3. When an S-PMSI is a 'Match for Reception' 871 Suppose a given PE, say PE1, needs to receive multicast data packets 872 of a particular C-flow. [MVPN-WILDCARDS] Section 3.2 specifies 873 procedures for determining the S-PMSI A-D route, if any, that 874 "matches" that C-flow for reception. Those rules apply unchanged for 875 C-flows that are not BIDIR-PIM C-flows. The remainder of this 876 section applies only to C-BIDIR flows. 878 The rules of [MVPN-WILDCARDS] Section 3.2.1 are not applicable to 879 C-BIDIR flows. The rules of [MVPN-WILDCARDS] Section 3.2.2 are 880 replaced by the following rules. 882 Suppose PE1 needs to receive (C-*,C-G-BIDIR) traffic. Suppose also 883 that PE1 has determined that PE2 is the "upstream PE" [MVPN] for the 884 C-RPA of C-G-BIDIR. Then: 886 - If PE1 has an installed (C-*,C-G-BIDIR) S-PMSI A-D route 887 originated by PE2, then (C-*,C-G-BIDIR) matches this route. 889 - Otherwise, if PE1 has an installed (C-*,C-*-BIDIR) route 890 originated by PE2, then (C-*,C-G-BIDIR) matches this route. 892 - Otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D route 893 originated by PE2, then (C-*,C-G-BIDIR) matches this route. 895 If there is an S-PMSI A-D route matching (C-*,C-G-BIDIR), according 896 to these rules, the root node of that P-tunnel is considered to be 897 the "distinguished PE" for that (C-*,C-G-BIDIR) flow. If a 898 (C-*,C-G-BIDIR) packet is received on a P-tunnel whose root node is 899 not the distinguished PE for the C-flow, the packet MUST be 900 discarded. 902 3.2.1.4. When an I-PMSI is a 'Match for Reception 904 Suppose a given PE, say PE1, needs to receive packets of a given 905 C-flow (of a given MVPN) from another PE, but according to the 906 conditions of Section 3.2.1.3 and/or [MVPN-WILDCARDS] section 3.2, 907 that C-flow does not match any S-PMSI A-D route. Then the packets of 908 the C-flow need to be received on the MVPN's I-PMSI. 910 If the C-flow is not a BIDIR-PIM C-flow, the rules for determining 911 the P-tunnel on which packets of the C-flow are expected are given in 912 [MVPN]. The remainder of this section applies only to C-BIDIR flows. 914 Suppose that PE1 needs to receive (C-*,C-G-BIDIR) traffic from other 915 PEs. Suppose also that PE1 has determined that PE2 is the "upstream 916 PE" [MVPN] for the C-RPA of C-G-BIDIR. Then PE1 considers PE2 to be 917 the "distinguished PE" for (C-*,C-G-BIDIR). If PE1 has an installed 918 Intra-AS I-PMSI A-D route originated by PE2, PE1 will expect to 919 receive packets of the C-flow from the tunnel specifies in that 920 route's PTA. (If all VRFs of the MVPN have been properly provisioned 921 to use the Flat Partitioned Method for the I-PMSI, the PTA will 922 specify a bidirectional P-tunnel.) 924 If a (C-*,C-G-BIDIR) packet is received on a P-tunnel other than the 925 expected one, packet MUST be discarded. 927 3.2.2. Hierarchical Partitioning 929 The procedures of this section and its sub-sections apply when (and 930 only when) the Hierarchical Partitioned Method is used. This method 931 is introduced in [MVPN] Section 11.2.2. This document only provides 932 procedures for using this method when using MP2MP LSPs as the 933 P-tunnels. 935 The Hierarchical Partitioned Method provides the same functionality 936 as the Flat Partitioned Method, but requires a smaller amount of 937 state to be maintained in the core of the network. However, it 938 requires the use of upstream-assigned MPLS labels ("PE Distinguisher 939 Labels"), which are not necessarily supported by all hardware 940 platforms. The upstream-assigned labels are used to provide an LSP 941 hierarchy, in which an "outer" MP2MP LSP carries multiple "inner" 942 MP2MP LSPs. Transit routers along the path between PE routers then 943 only need to maintain state for the outer MP2MP LSP. 945 When this method is used to instantiate a particular PMSI, the 946 bidirectional P-tunnel advertised in the PTA of the corresponding 947 I-PMSI or S-PMSI A-D route is the "outer" P-tunnel. When a packet is 948 received from a P-tunnel, the PE that receives it can infer the 949 identity of the outer P-tunnel from the MPLS label that has risen to 950 the top of the packet's label stack. However, the packet's 951 "distinguished PE" is not necessarily the root node of the the outer 952 P-tunnel. Rather, the identity of the packet's distinguished PE is 953 inferred from the PE Distinguisher Label further down in the label 954 stack. (See [MVPN] Section 12.3.) The PE Distinguisher Label may be 955 thought of as identifying an "inner" MP2MP LSP whose root is the PE 956 corresponding to that label. 958 In the context of a given MVPN, if it is desired to use the 959 Hierarchical Partitioned Method to instantiate an I-PMSI, a (C-*,C-*) 960 S-PMSI, or a (C-*,C-*-BIDIR) S-PMSI, the corresponding A-D routes 961 MUST be originated by some of the PEs that attach to that MVPN. The 962 PEs are REQUIRED to originate these routes are those that satisfy one 963 of the following conditions: 965 - There is a C-BIDIR group for which the best path from the PE to 966 the C-RPA of that C-group is via a VRF interface, or 968 - The PE might have to transmit unidirectional customer multicast 969 traffic on the PMSI identified in the route (of course this 970 condition does not apply to (C-*,C-*-BIDIR) or to (C-*,C-G-BIDIR) 971 S-PMSIs). 973 - The PE is the root node of the MP2MP LSP that is used to 974 instantiate the PMSI. 976 When the Hierarchical Partitioned method is used to instantiate a 977 (C-*,C-G-BIDIR) S-PMSI, the corresponding (C-*,C-G-BIDIR) S-PMSI 978 route MUST NOT be originated by a given PE unless either (a) that 979 PE's best path to the C-RPA for C-G-BIDIR is via a VRF interface, or 980 (b) the C-RPA is a C-address of the PE. Further, that PE MUST be the 981 root node of the MP2MP LSP identified in the PTA of the S-PMSI A-D 982 route. 984 If any VRF of a given MVPN uses this method to instantiate an S-PMSI 985 with a bidirectional P-tunnel, all VRFs of that MVPN must use this 986 method. 988 Suppose that for a given MVPN, the Hierarchical Partitioned Method is 989 used to instantiate the I-PMSI. In general, more than one of the PEs 990 in the MVPN will originate an Intra-AS I-PMSI A-D route for that 991 MVPN. This document allows the PTAs of those routes to all specify 992 the same MP2MP LSP as the "outer tunnel". However, it does not 993 require that those PTAs all specify the same MP2MP LSP as the outer 994 tunnel. By having all the PEs specify the same outer tunnel for the 995 I-PMSI, one can minimize the amount of state in the transit nodes. 996 By allowing them to specify different outer tunnels, one uses more 997 state, but may increase the robustness of the system. 999 The considerations of the previous paragraph apply as well when the 1000 Hierarchical Partitioned Method is used to instantiate an S-PMSI. 1002 3.2.2.1. Advertisement of PE Distinguisher Labels 1004 A PE Distinguisher Label is an upstream-assigned MPLS label [RFC5331] 1005 that can be used, in the context of a MP2MP LSP, to denote a 1006 particular PE that either has joined or may in the future join that 1007 LSP. 1009 In order to use upstream-assigned MPLS labels in the context of an 1010 "outer" MP2MP LSP, there must be a convention that identifies a 1011 particular router as the router that is responsible for allocating 1012 the labels and for advertising the labels to the PEs that may join 1013 the MP2MP LSP. This document REQUIRES that the PE Distinguisher 1014 Labels used in the context of a given MP2MP LSP be allocated and 1015 advertised by the router that is the root node of the LSP. 1017 This convention accords with the rules of section 7 of [RFC5331]. 1018 Note that according to section 7 of [RFC5331], upstream-assigned 1019 labels are unique in the context of the IP address of the root node; 1020 if two MP2MP LSPs have the same root node IP address, the upstream- 1021 assigned labels used within the two LSPs come from the same label 1022 space. 1024 A PE Distinguisher Labels attribute SHOULD NOT be attached to an 1025 I-PMSI or S-PMSI A-D route unless that route also contains a PTA that 1026 specifies an MP2MP LSP. (While PE Distinguisher Labels could in 1027 theory also be used if the PTA specifies a BIDIR-PIM P-tunnel, such 1028 use is outside the scope of this document.) 1030 The PE Distinguisher Labels attribute specifies a set of bindings. Within a given PE Distinguisher Labels 1032 attribute, each such IP address MUST appear at most once, and each 1033 MPLS label MUST appear only once; otherwise the attribute is 1034 considered to be malformed. 1036 When a PE Distinguisher Labels attribute is included in a given 1037 I-PMSI or S-PMSI A-D route, it MUST assign a label to the IP address 1038 of each of the following PEs: 1040 - The root node of the MP2MP LSP identified in the PTA of the 1041 route, 1043 - Any PE that is possibly the ingress PE for a C-RPA of any C-BIDIR 1044 group. 1046 - Any PE that may need to transmit non-C-BIDIR traffic on the MP2MP 1047 LSP identified in the PTA of the route. 1049 One simple way to meet these requirements is to assign a PE 1050 Distinguisher label to every PE that has originated an Intra-AS 1051 I-PMSI A-D route. 1053 3.2.2.2. When an S-PMSI is a 'Match for Transmission' 1055 Suppose a given PE, say PE1, needs to transmit multicast data packets 1056 of a particular C-flow. [MVPN-WILDCARDS] Section 3.1 gives a four- 1057 step algorithm for determining the S-PMSI A-D route, if any, that 1058 "matches" that C-flow for transmission. 1060 If the C-flow is not a BIDIR-PIM C-flow, these rules apply unchanged. 1061 If there is a matching S-PMSI A-D route, the P-tunnel on which the 1062 C-flow MUST be transmitted is the one identified in the PTA of the 1063 matching route. Each packet of the C-flow MUST carry the PE 1064 Distinguisher Label assigned by the root node of that P-tunnel to the 1065 IP address of PE1. See section 12.3 of [MVPN] for encapsulation 1066 details. 1068 The remainder of this section applies only to C-BIDIR flows. If a 1069 C-BIDIR flow has group address C-G-BIDIR, the rules applied by PE1 1070 are the same as the rules given in section 3.2.1.1. 1072 If there is a matching S-PMSI A-D route, PE1 MUST transmit the C-flow 1073 on the P-tunnel identified in its PTA. In constructing the packet's 1074 MPLS label stack, it must use the PE Distinguisher Label that was 1075 assigned by the P-tunnel's root node to the IP address of "PE2", not 1076 the label assigned to the IP address of "PE1". (Section 3.2.1.1 1077 specifies the difference between PE1 and PE2.) See section 12.3 of 1078 [MVPN] for encapsulation details. Note that the root of the P-tunnel 1079 might be a PE other than PE1 or PE2. 1081 3.2.2.3. When an I-PMSI is a 'Match for Transmission' 1083 Suppose a given PE, say PE1, needs to transmit packets of a given 1084 C-flow (of a given MVPN) to other PEs, but according to the 1085 conditions of section 3.2.3.1 and/or [MVPN-WILDCARDS] section 3.1, 1086 that C-flow does not match any S-PMSI A-D route. Then the packets of 1087 the C-flow need to be transmitted on the MVPN's I-PMSI. 1089 If the C-flow is not a BIDIR-PIM C-flow, the P-tunnel on which the 1090 C-flow MUST be transmitted is the one identified in the PTA of the 1091 Intra-AS I-PMSI A-D route originated by PE1 for the given MVPN. Each 1092 packet of the C-flow MUST carry the PE Distinguisher Label assigned 1093 by the root node of that P-tunnel to the IP address of PE1. 1095 If the C-flow is a BIDIR-PIM C-flow with group address C-G-BIDIR, the 1096 rules as applied by PE1 are the same as those given in section 1097 3.2.1.2. 1099 Note that if a matching I-PMSI A-D route is found, the PTA of that 1100 route will have a non-zero MPLS label. This label must be pushed on 1101 each packet of the C-flow before that packet is transmitted through 1102 the P-tunnel identified in the PTA. 1104 If, for a packet of a particular C-flow, there is no S-PMSI A-D route 1105 or I-PMSI A-D route that is a match for transmission, the packet MUST 1106 NOT be transmitted. 1108 3.2.2.4. When an S-PMSI is a 'Match for Reception' 1110 Suppose a given PE, say PE1, needs to receive multicast data packets 1111 of a particular C-flow. [MVPN-WILDCARDS] Section 3.2 specifies 1112 procedures for determining the S-PMSI A-D route, if any, that 1113 "matches" that C-flow for reception. Those rules require that the 1114 matching S-PMSI A-D route has been originated by the upstream PE for 1115 the C-flow. The rules are modified in this section, as follows. 1117 Consider a particular C-flow. Suppose either: 1119 - the C-flow is unidirectional, and PE1 determines that its 1120 upstream PE is PE2, or 1122 - the C-flow is bidirectional, and PE1 determines that the upstream 1123 PE for its C-RPA is PE2. 1125 Then the C-flow may match an installed S-PMSI A-D route that was not 1126 originated by PE2, as long as: 1128 1. the PTA of that A-D route identifies an MP2MP LSP, and 1130 2. there is an installed S-PMSI A-D route originated the root node 1131 of that LSP, or PE1 itself the root node of the LSP and there 1132 is a currently originated S-PMSI A-D route from PE1 whose PTA 1133 identifies that LSP, and 1135 3. the latter S-PMSI A-D route (the one identified in 2 just 1136 above) contains a PE Distinguisher Labels attribute that 1137 assigned an MPLS label to the IP address of PE2. 1139 However, a bidirectional C-flow never matches an S-PMSI A-D route 1140 whose NLRI contains (C-S,C-G). 1142 If a multicast data packet is received over a matching P-tunnel, but 1143 does not carry the value of the PE Distinguisher Label that has been 1144 assigned to the upstream PE for its C-flow, then the packet MUST be 1145 discarded. 1147 3.2.2.5. When an I-PMSI is a 'Match for Reception' 1149 If a PE needs to receive packets of a given C-flow (of a given MVPN) 1150 from another PE, and if, according to the conditions of section 1151 3.2.3.3, that C-flow does not match any S-PMSI A-D route, then the 1152 packets of the C-flow need to be received on the MVPN's I-PMSI. The 1153 P-tunnel on which the packets are expected to arrive is determined by 1154 the Intra-AS I-PMSI A-D route originated by the "distinguished PE" 1155 for the given C-flow. The PTA of that route specifies the "outer 1156 P-tunnel", and thus determines the top label that packets of that 1157 C-flow will be carrying when received. A PE that needs to receive 1158 packets of a given C-flow must determine the expected value of the 1159 second label for packets of that C-flow. This will be the value of a 1160 PE Distinguisher Label, taken from the PE Distinguisher Labels 1161 attribute of the Intra-AS I-PMSI A-D route of the root node of that 1162 outer tunnel. The expected value of the second label on received 1163 packets (corresponding to the "inner tunnel") of a given C-flow is 1164 determined according to the following rules. 1166 First, the "distinguished PE" for the C-flow is determined: 1168 - If the C-flow is not a BIDIR-PIM C-flow, the "distinguished PE" 1169 for the C-flow is its "upstream PE", as determined by the rules 1170 of [MVPN]. 1172 - If the C-flow is a BIDIR-PIM C-flow, the "distinguished PE" for 1173 the C-flow is its "upstream PE" of the C-flow's C-RPA, as 1174 determined by the rules of [MVPN]. 1176 The expected value of the second label is the value that the root PE 1177 of the outer tunnel has assigned, in the PE Distinguisher Labels 1178 attribute of its Intra-AS I-PMSI A-D route, to the IP address of the 1179 "distinguished PE". 1181 Packets addresses to C-G that arrive on other than the expected inner 1182 and outer P-tunnels (i.e., that arrive with unexpected values of the 1183 top two labels) MUST be discarded. 1185 3.2.3. Unpartitioned 1187 When a particular MVPN uses the Unpartitioned Method of instantiating 1188 an I-PMSI with a bidirectional P-tunnel, it MUST be the case that at 1189 least one VRF of that MVPN originates an Intra-AS I-PMSI A-D route 1190 that includes a PTA specifying a bidirectional P-tunnel. The 1191 conditions under which an Intra-AS I-PMSI A-D route must be 1192 originated from a given VRF are as specified in [MVPN-BGP]. This 1193 document allows all but one of such routes to omit the PTA. However, 1194 each such route MAY contain a PTA. If the PTA is present, it MUST 1195 specify a bidirectional P-tunnel. As specified in [MVPN] and 1196 [MVPN-BGP], every PE that imports such an Intra-AS I-PMSI A-D route 1197 into one of its VRFs MUST, if the route has a PTA, join the P-tunnel 1198 specified in the route's PTA. 1200 Packets received on any of these P-tunnels are treated as having been 1201 received over the I-PMSI. The disposition of a received packet MUST 1202 NOT depend upon the particular P-tunnel over which it has been 1203 received. 1205 When a PE needs to transmit a packet on such an I-PMSI, then if that 1206 PE advertised a P-tunnel in the PTA of an Intra-AS I-PMSI A-D route 1207 that it originated, the PE SHOULD transmit the on that P-tunnel. 1208 However, any PE that transmits a packet on the I-PMSI MAY transmit it 1209 on any of the P-tunnels advertised in any of the currently installed 1210 Intra-AS I-PMSI A-D routes for its VPN. 1212 This allows a single bidirectional P-tunnel to be used to instantiate 1213 the I-PMSI, but also allows the use of multiple bidirectional 1214 P-tunnels. There may be a robustness advantage in having multiple 1215 P-tunnels available for use, but the number of P-tunnels used does 1216 not impact the functionality in any way. If there are, e.g., two 1217 P-tunnels available, these procedures allow each P-tunnel to be 1218 advertised by a single PE, but they also allow each P-tunnel to be 1219 advertised by multiple PEs. Note that the PE advertising a given 1220 P-tunnel does not have to be the root node of the tunnel. The root 1221 node might not even be a PE router, and might not originate any BGP 1222 routes at all. 1224 In the Unpartitioned Method, packets received on the I-PMSI cannot be 1225 associated with a distinguished PE, so duplicate detection using the 1226 techniques of [MVPN] section 9.1.1 is not possible; the techniques of 1227 [MVPN] 9.1.2 or 9.1.3 would have to be used instead. Support for 1228 C-BIDIR using the "Partitioned set of PEs" technique ([MVPN] section 1229 11.2 and [RFC6517] section 3.6) is not possible when the 1230 Unpartitioned Method is used. If it is desired to use that technique 1231 to support C-BIDIR, but also to use the Unpartitioned Method to 1232 instantiate the I-PMSI, then all the C-BIDIR traffic would have to be 1233 carried on an S-PMSI, where the S-PMSI is instantiated using one of 1234 the Partitioned Methods. 1236 When a PE, say PE1, needs to transmit multicast data packets of a 1237 particular C-flow to other PEs, and PE1 does not have an S-PMSI that 1238 is a "match for transmission for that C-flow (see section 3.2.3.1), 1239 PE1 transmits the packets on one of the P-tunnel(s) that instantiates 1240 the I-PMSI. When a PE, say PE1, needs to receive multicast data 1241 packets of a particular C-flow from another PE, and PE1 does not have 1242 an S-PMSI that is a "match for reception for that C-flow (see section 1243 3.2.3.2), PE1 expects to receive the packets on any of the 1244 P-tunnel(s) that instantiates the I-PMSI. 1246 When a particular MVPN uses the Unpartitioned Method to instantiate a 1247 (C-*,C-*) S-PMSI or a (C-*,C-*-BIDIR) S-PMSI using a bidirectional 1248 P-tunnel, the same conditions apply as when an I-PMSI is instantiated 1249 via the Unpartitioned Method. The only difference is that a PE need 1250 not join a P-tunnel that instantiates the S-PMSI unless that PE needs 1251 to receive multicast packets on the S-PMSI. 1253 When a particular MVPN uses bidirectional P-tunnels to instantiate 1254 other S-PMSIs, different S-PMSI A-D routes that do not contain 1255 (C-*,C-*) or (C-*,C-*-BIDIR), originated by the same or by different 1256 PEs, MAY have PTAs that identify the same bidirectional tunnel, and 1257 they MAY have PTAs that do not identify the same bidirectional 1258 tunnel. 1260 While the Unpartitioned Method MAY be used to instantiate an S-PMSI 1261 to which one or more C-BIDIR flows are bound, it must be noted that 1262 the "Partitioned Set of PEs" method discussed in [MVPN] section 11.2 1263 and [RFC6517] section 3.6 cannot be supported using the Unpartitioned 1264 Method. C-BIDIR support would have to be provided by the procedures 1265 of [MVPN] section 11.1. 1267 3.2.3.1. When an S-PMSI is a 'Match for Transmission' 1269 Suppose a PE needs to transmit multicast data packets of a particular 1270 customer C-flow. [MVPN-WILDCARDS] Section 3.1 gives a four-step 1271 algorithm for determining the S-PMSI A-D route, if any, that 1272 "matches" that C-flow for transmission. When referring to that 1273 section, please recall that BIDIR-PIM groups are also "Any Source 1274 Multicast" (ASM) groups. 1276 When bidirectional P-tunnels are used in the Unpartitioned Method, 1277 the same algorithm applies, with one modification, when the PTA of an 1278 S-PMSI A-D route identifies a bidirectional P-tunnel. One additional 1279 step is added to the algorithm. This new step occurs before the 1280 fourth step of the algorithm, and is as follows: 1282 - Otherwise, if there is a (C-*,C-*-BIDIR) S-PMSI A-D route 1283 currently originated by PE1, and if C-G is a BIDIR group, the 1284 C-flow matches that route. 1286 When the Unpartitioned Method is used, the PE SHOULD transmit the 1287 C-flow on the P-tunnel advertised in the in the matching S-PMSI A-D 1288 route, but it MAY transmit the C-flow on any P-tunnel that is 1289 advertised in the PTA of any installed S-PMSI A-D route that contains 1290 the same (C-S,C-G) as the matching S-PMSI A-D route. 1292 3.2.3.2. When an S-PMSI is a 'Match for Reception' 1294 Suppose a PE needs to receive multicast data packets of a particular 1295 customer C-flow. [MVPN-WILDCARDS] Section 3.2 specifies the 1296 procedures for determining the S-PMSI A-D route, if any, that 1297 advertised the P-tunnel on which the PE should expect to receive that 1298 C-flow. 1300 When bidirectional P-tunnels are used in the Unpartitioned Method, 1301 the same procedures apply, with one modification. 1303 The last paragraph of Section 3.2.2 of [MVPN-WILDCARDS] begins: 1305 "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from 1306 PE2, but PE1 has an installed (C-*,C-*) S-PMSI A-D route from 1307 PE2, then (C-*,C-G) matches the (C-*,C-*) route if one of the 1308 following conditions holds:" 1310 This is changed to: 1312 "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from 1313 PE2, but C-G is a BIDIR group and PE1 has an installed 1314 (C-*,C-*-BIDIR) S-PMSI A-D route, then (C-*,C-G) matches that 1315 route. Otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D 1316 route from PE2, then (C-*,C-G) matches the (C-*,C-*) route if one 1317 of the following conditions holds:" 1319 When the Unpartitioned Method is used, the PE MUST join the P-tunnel 1320 that is advertised in the matching S-PMSI A-D route, and MUST also 1321 join the P-tunnels that are advertised in other installed S-PMSI A-D 1322 routes that contain the same (C-S,C-G) as the matching S-PMSI A-D 1323 route. 1325 3.2.4. Minimal Feature Set for Compliance 1327 A PE that does not provide C-BIDIR support using the "partitioned set 1328 of PEs" method may be deemed compliant to this specification if it 1329 supports the Unpartitioned Method, using either MP2MP LSPs or 1330 BIDIR-PIM multicast distribute trees as P-tunnels. 1332 A PE that does provide C-BIDIR support using the "partitioned set of 1333 PEs" method, MUST, at a minimum, be able to provide C-BIDIR support 1334 using the "Partial Mesh of MP2MP P-tunnels" variant of this method 1335 (see section 11.2 of [MVPN]). An implementation will be deemed 1336 complaint to this minimum requirement if it can carry all of a VPN's 1337 C-BIDIR traffic on a (C-*,C-*-BIDIR) S-PMSI that is instantiated by a 1338 bidirectional P-tunnel, using the flat partitioned method. 1340 4. IANA Considerations 1342 This document has no actions for IANA. 1344 5. Security Considerations 1346 There are no additional security considerations beyond those of 1347 [MVPN] and [MVPN-BGP], or any that may apply to the particular 1348 protocol used to set up the bidirectional tunnels ([BIDIR-PIM], 1349 [mLDP]). 1351 6. Acknowledgments 1353 The authors wish to thank Karthik Subramanian, Rajesh Sharma, and 1354 Apoorva Karan for their input. We also thank Yakov Rekhter for his 1355 valuable critique. 1357 Special thanks go to Jeffrey Zhang for his careful review, probing 1358 questions, and useful suggestions. 1360 7. Authors' Addresses 1362 Arjen Boers 1363 E-mail: arjen@boers.com 1365 Yiqun Cai 1366 Microsoft 1367 1065 La Avenida 1368 Mountain View, CA 94043 1369 E-mail: yiqunc@microsoft.com 1371 Eric C. Rosen 1372 Cisco Systems, Inc. 1373 1414 Massachusetts Avenue 1374 Boxborough, MA, 01719 1375 E-mail: erosen@cisco.com 1377 IJsbrand Wijnands 1378 Cisco Systems, Inc. 1379 De kleetlaan 6a Diegem 1831 1380 Belgium 1381 E-mail: ice@cisco.com 1383 8. Normative References 1385 [BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley, 1386 Kouvelas, Speakman, Vicisano, RFC 5015, October 2007 1388 [L3VPN], "BGP/MPLS IP Virtual Private Networks", Rosen, Rekhter 1389 (editors), RFC 4364, February 2006 1391 [mLDP] "Label Distribution Protocol Extensions for 1392 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 1393 Paths", Wijnands, Minei, Kompella, Thomas, RFC 6388, November 2011 1395 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., RFC 1396 6513, February 2012 1398 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 1399 VPNs", Aggarwal, Rosen, Morin, Rekhter, RFC 6514, February 2012 1401 [MVPN-WILDCARDS] "Wild Cards in Multicast VPN Auto-Discovery Routes", 1402 Rosen, Rekhter, Hendrickx, Qiu, RFC 6625, May 2012 1404 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1405 Protocol Specification (Revised)", Fenner, Handley, Holbrook, 1406 Kouvelas, RFC 4601, August 2006 1408 [RFC2119] "Key words for use in RFCs to Indicate Requirement 1409 Levels.", Bradner, March 1997 1411 9. Informative References 1413 [RFC5331] "MPLS Upstream Label Assignment and Context-Specific Label 1414 Space", Aggarwal, Rekhter, Rosen, RFC 5331, August 2008 1416 [RFC6517] "Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN 1417 Solution", Morin, Niven-Jenkins, Kamite, Zhang, Leymann, Bitar, RFC 1418 6517, February 2012 1420 [MVPN-BIDIR-IR] "Simulating 'Partial Mesh of MP2MP P-Tunnels' with 1421 Ingress Replication", Zhang, Rekhter, Dolganow, draft-ietf-l3vpn- 1422 mvpn-bidir-ingress-replication-00.txt, February 2014 1424 [MVPN-XNET] "Extranet Multicast in BGP/IP MPLS VPNs", Rekhter, Rosen 1425 (editors), draft-ietf-l3vpn-mvpn-extranet-04.txt, March 2014