L3VPN Working Group Eric C. Rosen (Editor) Internet Draft IJsbrand Wijnands Intended Status: Proposed Standard Cisco Systems, Inc. Expires: July 7, 2013 Yiqun Cai Microsoft Arjen Boers January 7, 2013 MVPN: Using Bidirectional P-Tunnels draft-ietf-l3vpn-mvpn-bidir-04.txt Abstract The RFCs providing multicast support for BGP/MPLS IP VPNs allow customer multicast data to be travel across a service provider's backbone network through a set multicast tunnels. These tunnels are advertised by BGP in a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel Attribute". Encodings have been defined that allow the PMSI Tunnel Attribute to specify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary details for using bidirectional tunnels to support multicast VPNs. These details are provided in the current document. This document also specifies the procedures for assigning customer multicast flows to specific bidirectional tunnels in the provider backbone. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Rosen, et al. [Page 1] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Rosen, et al. [Page 2] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 Table of Contents 1 Introduction .......................................... 3 1.1 Terminology ........................................... 4 1.2 Overview .............................................. 6 1.2.1 Bidirectional P-tunnel Technologies ................... 7 1.2.2 PMSI Instantiation Methods ............................ 7 2 The All BIDIR-PIM Wild Card ........................... 9 3 Using Bidirectional P-Tunnels ......................... 9 3.1 Procedures Specific to the Tunneling Technology ....... 9 3.1.1 BIDIR-PIM P-Tunnels ................................... 9 3.1.2 MP2MP LSPs ............................................ 10 3.2 Procedures Specific to the PMSI Instantiation Method .. 11 3.2.1 Flat Partitioning ..................................... 11 3.2.1.1 When an S-PMSI is a 'Match for Transmission' .......... 12 3.2.1.2 When an S-PMSI is a 'Match for Reception' ............. 13 3.2.2 Hierarchical Partitioning ............................. 14 3.2.2.1 When an S-PMSI is a 'Match for Transmission' .......... 15 3.2.2.2 When an S-PMSI is a 'Match for Reception' ............. 16 3.2.3 Unpartitioned ......................................... 17 3.2.3.1 When an S-PMSI is a 'Match for Transmission' .......... 18 3.2.3.2 When an S-PMSI is a 'Match for Reception' ............. 18 4 IANA Considerations ................................... 19 5 Security Considerations ............................... 19 6 Acknowledgments ....................................... 19 7 Authors' Addresses .................................... 19 8 Normative References .................................. 20 9 Informative References ................................ 21 1. Introduction The RFCs that specify multicast support for BGP/MPLS IP VPNs ([MVPN], [MVPN-BGP]) allow customer multicast data to be transported across a service provider's network though a set of multicast tunnels. Such tunnels are advertised by BGP in a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel Attribute". Bidirectional multicast distribution trees are allowed by the base specifications, and those specifications describe how to encode the identifiers for bidirectional trees in the PMSI Tunnel attribute. However, those specifications do not provide all the necessary details for using bidirectional tunnels. These details are provided Rosen, et al. [Page 3] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 in this document. 1.1. Terminology This document uses terminology from [MVPN] and, in particular, uses the prefixes "C-" and "P-", as specified in Section 3.1 of [MVPN], to distinguish addresses in the "customer address space" from addresses in the "provider address space". The following terminology and acronyms are particularly important in this document: - MVPN Multicast Virtual Private Network -- a VPN [L3VPN] in which multicast service is offered. - VRF VPN Routing and Forwarding table [L3VPN]. - PE A Provider Edge router, as defined in [L3VPN]. - LSP An MPLS Label Switched Path. - MP2MP Multipoint-to-multipoint. - P-tunnel A tunnel through the network of one or more Service Providers (SPs). - C-S Multicast Source. A multicast source address, in the address space of a customer network. - C-G Multicast Group. A multicast group address (destination address) in the address space of a customer network. Rosen, et al. [Page 4] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 - C-multicast flow or C-flow A customer multicast flow. Each C-flow is identified by the ordered pair (source address, group address), where each address is in the customer's address space. The identifier of a particular C-flow is usually written as (C-S,C-G). - RP A "Rendezvous Point", as defined in [PIM]. - C-RP A Rendezvous Point whose address is in the customer's address space. - RPA A "Rendezvous Point Address", as defined in [BIDIR-PIM]. - C-RPA An RPA in the customer's address space. - P-RPA An RPA in the Service Provider's address space - Selective P-tunnel A P-tunnel that is joined only by Provider Edge (PE) routers that need to receive one or more of the C-flows that are traveling through that P-tunnel. - Inclusive P-tunnel A P-tunnel that is joined by all PE routers that attach to sites of a given MVPN. - Intra-AS I-PMSI A-D route Intra Autonomous System Inclusive Provider Multicast Service Interface Auto-Discovery route. Carried in BGP Update messages, these routes can be used to advertise the use of Inclusive P-tunnels. Rosen, et al. [Page 5] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 - S-PMSI A-D route Selective Provider Multicast Service Interface Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the fact that particular C-flows are bound to (i.e., are traveling through) particular P-tunnels. - PE Distinguisher Labels These are upstream-assigned MPLS labels that can be used, in the context of a MP2MP LSP, to denote a particular PE that can send to or receive from that LSP. By putting a PE Distinguisher label on a packet, before transmitting that packet on a MP2MP LSP, the transmitter indicates that the PE denoted by the label has a special relationship to the packet. - PE Distinguisher Labels Attribute A BGP path attribute, defined in [MVPN-BGP], that is used for advertising PE Distinguisher Labels, and binding each PE Distinguisher Label to a particular PE address.. The attribute is a set of bindings. We say that the NLRI ("Network Layer Reachability Information") of a BGP S-PMSI A-D route or Source Active A-D route contains (C-S,C-G) if its "Multicast Source" field contains C-S and its "Multicast Group" field contains C-G. If either or both of these fields is encoded as a wildcard, we will say that the NLRI contains (C-*,C-*) (both fields encoded as wildcard), (C-*,C-G) (multicast source field encoded as wildcard) or (C-S,C-*) (multicast group field encoded as wildcard). Familiarity with multicast concepts and terminology [PIM] is also presupposed. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, when appearing in all caps, are to be interpreted as described in [RFC2119]. 1.2. Overview The base documents for MVPN, [MVPN] and [MVPN-BGP], define a "PMSI Tunnel Attribute" (PTA) that may be carried in the BGP "I-PMSI A-D routes" and BGP "S-PMSI A-D routes" that are defined therein. The base documents define the way in which the identifier of a bidirectional P-tunnel is encoded in the PTA. However, those documents do not contain the full set of specifications governing the Rosen, et al. [Page 6] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 use of the PTA to advertise bidirectional P-tunnels; rather, those documents declare those specifications to be "out of scope." Similarly, the use of bidirectional P-tunnels advertised in S-PMSI A-D routes with wildcards is declared by [MVPN-WILDCARDS] to be "out of scope." This document provides the necessary specifications to allow the use of bidirectional P-tunnels, including the procedures for assigning customer multicast flows to specific bidirectional P- tunnels. This document does not specify any new data encapsulations for bidirectional P-tunnels. Section 12 of [MVPN] applies unchanged. 1.2.1. Bidirectional P-tunnel Technologies This document covers two different technologies for creating and maintaining bidirectional P-tunnels: - Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs), created by Label Distribution Protocol (LDP) Multipoint-to-Multipoint extensions [mLDP]. - Multicast distribution trees that are created through the use of BIDIR-PIM [BIDIR-PIM]. Other bidirectional tunnel technologies are outside the scope of this document. 1.2.2. PMSI Instantiation Methods This document specifies two methods for using bidirectional P-tunnels to instantiate PMSIs: - Partitioned Method In the Partitioned Method, a particular PMSI is instantiated by a set of bidirectional P-tunnels. These P-tunnels may be aggregated into a single "outer" bidirectional P-tunnel ("Hierarchical Partitioning"), or they may be unaggregated ("Flat Partitioning"). Any PE that joins one of these P-tunnels can transmit a packet on it, and the packet will be received by all the other PEs that have joined the P-tunnel. However, for each such P-tunnel (each "inner" P-tunnel, in the case of hierarchical partitioning) there is one PE that is the "distinguished PE" for that P-tunnel. Thus when a packet is received on a given P-tunnel, it can be associated with the P-tunnel's distinguished PE. This association plays an important role in the treatment of Rosen, et al. [Page 7] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 the packet, as specified later on in this document. As specified later in this document, the hierarchical partitioned method (but not the flat partitioned method) requires the use of upstream-assigned MPLS labels ("PE Distinguisher Labels"), and requires the use of the PE Distinguisher Labels attribute in BGP. - Unpartitioned Method In the Unpartitioned Method, a particular PMSI is instantiated by a single bidirectional P-tunnel. Any PE that joins the tunnel can transmit a packet on it, and the packet will be received by all the other PEs that have joined the tunnel. The receiving PEs know the tunnel on which the packet was transmitted, but they do not associate the packet with any particular "distinguished PE". If a bidirectional P-tunnel is used to instantiate an I-PMSI, the Unpartitioned Method MUST be used. If a bidirectional P-tunnel is used to instantiate an S-PMSI (including the case of a (C-*,C-*) S-PMSI), either the Partitioned Method or the Unpartitioned Method may be used. The method used by a given VRF used is determined by provisioning. It SHOULD be possible to provision this on a per-MVPN basis, but all the VRFs of a single MVPN MUST be provisioned to use the same method for all their S-PMSIs. If the partitioned method is used, all the VRFs of a single MVPN MUST be provisioned to use the same partitioned method, i.e., either they must all use the flat partitioned method, or they must all use the hierarchical partitioned method. It is valid to use the unpartitioned method to instantiate the I-PMSIs, while using one of the partitioned methods to instantiate the S-PMSIs. The procedures for the use of bidirectional P-tunnels, specified in subsequent sections of this document, depend on both the tunnel technology and on the PMSI instantiation method. Note that this document does not specify procedures for every possible combination of tunnel technology and PMSI instantiation method. Rosen, et al. [Page 8] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 2. The All BIDIR-PIM Wild Card When an MVPN customer is using BIDIR-PIM, it is useful to be able to advertise an S-PMSI A-D route whose semantics are: "by default, all BIDIR-PIM C-multicast traffic (within a given VPN) that has not been bound to any other P-tunnel is bound to the bidirectional P-tunnel identified by the PTA of this route". This can be especially useful if one is using a bidirectional P-tunnel to carry the C-BIDIR flows, while using unidirectional P-tunnels to carry other flows. To do this, it is necessary to have a way to encode a (C-*,C-*) wildcard that is restricted to BIDIR-PIM C-groups. We therefore define a special value of the group wildcard, whose meaning is "all BIDIR-PIM groups". The "BIDIR-PIM groups wildcard" is encoded as a group field whose length is 8 bits and whose value is zero. That is, the "multicast group length" field contains the value 0x08, and the "multicast group" field is a single octet containing the value 0x00. We will use the notation (C-*,C-BIDIR) to refer to the "all BIDIR-PIM groups" wildcard. 3. Using Bidirectional P-Tunnels A bidirectional P-tunnel may be advertised in the PTA of an Intra-AS I-PMSI A-D route or in the PTA of an S-PMSI A-D route. The advertisement of a bidirectional P-tunnel in the PTA of an Inter-AS I-PMSI A-D route is outside the scope of this document. 3.1. Procedures Specific to the Tunneling Technology This section discusses the procedures that are specific to a given tunneling technology (BIDIR-PIM or MP2MP mLDP), but that are independent of the method (unpartitioned, flat partitioned, or hierarchical partitioned) used to instantiate a PMSI. 3.1.1. BIDIR-PIM P-Tunnels Each BIDIR-PIM P-Tunnel is identified by a unique P-group address [MVPN, section 3.1]. (The P-group address is called a "P-Multicast Group" in [MVPN-BGP]). Section 5 of [MVPN-BGP] specifies the way to identify a particular BIDIR-PIM P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route. Ordinary BIDIR-PIM procedures are used to set up the BIDIR-PIM P- tunnels. A BIDIR-PIM P-group address is always associated with a unique "Rendezvous Point Address" (RPA) in the SP's address space. Rosen, et al. [Page 9] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 We will refer to this as the "P-RPA". Every PE needing to join a particular BIDIR-PIM P-tunnel must be able to determine the P-RPA that corresponds to the P-tunnel's P-group address. To construct the P-tunnel, PIM Join/Prune messages are sent along the path from the PE to the P-RPA. Any P routers along that path must also be able to determine the P-RPA, so that they too can send PIM Join/Prune messages towards it. The method of mapping a P-group address to an RPA may be static configuration, or some automated means of RPA discovery that is outside the scope of this specification. If a BIDIR-PIM P-tunnel is used to instantiate an I-PMSI or an S-PMSI, it is RECOMMENDED that the path from each PE in the tunnel to the RPA consist entirely of point-to-point links. On a point-to-point link, there is no ambiguity in determining which router is upstream towards a particular RPA, so the BIDIR-PIM "Designated Forwarder Election" is very quick and simple. Use of a BIDIR-PIM P-tunnel containing multiaccess links is possible, but considerably more complex. The use of BIDIR-PIM P-tunnels to support the hierarchical partitioned method is outside the scope of this document. When the PTA of an Intra-AS I-PMSI A-D route or an S-PMSI A-D route identifies a BIDIR-PIM tunnel, the route SHOULD NOT have a PE Distinguisher Labels attribute. If it does, that attribute MUST be ignored. (PE Distinguisher Labels are used for the hierarchical partitioning method, but this document does not provide support the hierarchical partitioning method with BIDIR-PIM P-tunnels.) 3.1.2. MP2MP LSPs Each MP2MP LSP is identified by a unique "MP2MP FEC (Forwarding Equivalence Class) element" [mLDP]. The FEC element contains the IP address of the "root node", followed by an "opaque value" that identifies the MP2MP LSP uniquely in the context of the root node's IP address. This opaque value may be configured or autogenerated, and within an MVPN, there is no need for different root nodes to use the same opaque value. The mLDP specification supports the use of several different ways of constructing the tunnel identifiers. The current specification does not place any restriction on the type of tunnel identifier that might be used. However, a given implementation might not support every possible type of tunnel identifier. Section 5 of [MVPN-BGP] specifies the way to identify a particular MP2MP P-tunnel in the PTA of an I-PMSI or S-PMSI A-D route. Rosen, et al. [Page 10] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 Ordinary mLDP procedures for MP2MP LSPs are used to set up the MP2MP LSP. 3.2. Procedures Specific to the PMSI Instantiation Method 3.2.1. Flat Partitioning This method is introduced in [MVPN] Section 11.2.3, where it is called "Partial Mesh of MP2MP P-tunnels". This method can be used with MP2MP LSPs or with BIDIR-PIM P-tunnels. It does not require the use of upstream-assigned labels, and does not use the PE Distinguisher Labels attribute. The flat partitioning method MUST NOT be used to instantiate an I-PMSI; it is only used to instantiate S-PMSIs. It may however be used to instantiate a (C-*,C-*) S-PMSI or a (C-*,C-BIDIR) S-PMSI. When the flat partitioning method is used, an S-PMSI A-D route SHOULD NOT contain a PE Distinguisher Labels attribute; if such an attribute is present in a received S-PMSI A-D route, it MUST be ignored. When the flat partitioning method is used to instantiate a (C-*,C-*) S-PMSI, a (C-*,C-BIDIR) S-PMSI, or a (C-*,C-G) S-PMSI where C-G is a BIDIR group, each of a "selected set" (see below) of PEs in a given MVPN MUST originate an S-PMSI A-D route with a PTA identifying a bidirectional P-tunnel. The PE originating the route MUST be the root node of the identified bidirectional P-tunnel. It follows that two different PEs may not advertise the same bidirectional P-tunnel. Any PE that receives a packet from the P-tunnel can infer the identity of the P-tunnel from the packet's encapsulation. Once the identity of the P-tunnel is known, the root node of the P-tunnel is also known. The root node of the P-tunnel on which the packet arrived is treated as the "distinguished PE" for that packet. If the received packet is part of a unidirectional C-flow, its "distinguished PE" is the PE that transmitted the packet onto the P-tunnel. If the packet is part of a bidirectional C-flow, its "distinguished PE" is not necessarily the PE that transmitted it, but rather the transmitter's "upstream PE" for the C-RPA of the bidirectional C-group. If BIDIR-PIM P-tunnels are used, each advertised P-tunnel MUST have a distinct P-group address. The PE advertising the tunnel will be considered to be the root node of the tunnel. Note that this creates a unique mapping from P-group address to "root node". If MP2MP LSPs are used, each P-tunnel MUST have have a distinct MP2MP Rosen, et al. [Page 11] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 FEC (i.e., distinct combination of "root node" and "opaque value"). The PE advertising the tunnel MUST be the same PE identified in the "root node" field of the MP2MP FEC that is encoded in the PTA. A PE is considered to be in the "selected set" if at least one of the following conditions hold: - The "Partitioned Sets of PEs" method of supporting C-BIDIR traffic is being used, and the PE's route to the Customer's Rendezvous Point Address (C-RPA) for one or more C-BIDIR groups is via a VRF interface. - The "Partitioned Sets of PEs" method of supporting C-BIDIR traffic is being used, it is desired to transmit some or all of the customer's unidirectional multicast traffic (for the given MVPN) on the same LSPs used for carrying C-BIDIR traffic, and the PE has customer multicast traffic to transmit to other PEs. There may be other conditions under which a PE is considered to be in the "selected set"; these are outside the scope of this document. When the flat partitioning method is used to implement the "Partitioned Sets of PEs" method of supporting C-BIDIR, as discussed in section 11.2 of [MVPN] and section 3.6 of [RFC6517], a C-BIDIR flow MUST be carried only on a (C-*,C-G), (C-*,C-BIDIR), or (C-*,C-*) S-PMSI. A PE MUST NOT originate a (C-S,C-G) S-PMSI A-D route for any C-G that is a C-BIDIR group. 3.2.1.1. When an S-PMSI is a 'Match for Transmission' Given the need for a PE, say PE1, to transmit multicast data packets of a particular C-flow, [MVPN-WILDCARDS] Section 3.1 gives a four- step algorithm for determining the S-PMSI A-D route, if any, that "matches" that C-flow for transmission. If the C-flow is not a BIDIR-PIM C-flow, these rules apply unchanged. If the C-flow is a BIDIR-PIM C-flow, the rules as applied by a particular PE, say PE1, are given below: - If the C-RPA for C-G is a C-address of PE1, or if PE1's route to the C-RPA is via a VRF interface, then: * if there is an S-PMSI A-D route, currently originated by PE1, whose NLRI contains (C-*,C-G) and whose PTA identifies a bidirectional P-tunnel, then the C-flow matches that route Rosen, et al. [Page 12] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 * otherwise, if there is an S-PMSI A-D route, currently originated by PE1, whose NLRI contains (C-*,C-BIDIR) and whose PTA identifies a bidirectional P-tunnel, then the C-flow matches that route * otherwise, if there is an S-PMSI A-D route, currently originated by PE1, whose NLRI contains (C-*,C-*) and whose PTA identifies a bidirectional P-tunnel, then the C-flow matches that route - If PE1 determines the upstream PE for C-G's C-RPA to be some other PE, say PE2, then the following rules apply: * if there is an installed S-PMSI A-D route, originated by PE2, whose NLRI contains (C-*,C-G) and whose PTA identifies a bidirectional P-tunnel, then the C-flow matches that route * otherwise, if there is an installed S-PMSI A-D route, originated by PE2, whose NLRI contains (C-*,C-BIDIR) and whose PTA identifies a bidirectional P-tunnel, then the C-flow matches that route * otherwise, if there is an S-PMSI A-D route, currently originated by PE2, whose NLRI contains (C-*,C-*) and whose PTA identifies a bidirectional P-tunnel, then the C-flow matches that route PE1 MUST transmit the C-flow on the P-tunnel identified in the PTA of the matching S-PMSI A-D route. 3.2.1.2. When an S-PMSI is a 'Match for Reception' Given the need for a PE to receive multicast data packets of a particular C-flow, [MVPN-WILDCARDS] Section 3.2 specifies procedures for determining the S-PMSI A-D route, if any, that "matches" that C-flow for reception. Those rules apply unchanged for C-flows that are not BIDIR-PIM C-flows. For BIDIR-PIM C-flows, the rules of [MVPN-WILDCARDS] Section 3.2.1 do not apply. The rules of [MVPN-WILDCARDS] Section 3.2.2 are replaced by the following rules. Suppose that a PE router (call it PE1) needs to receive (C-*,C-G) traffic, where C-G is a C-BIDIR group. Suppose also that PE1 has determined that PE2 is the "upstream PE" [MVPN] for the C-RPA of C-G. Rosen, et al. [Page 13] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 Then: - if PE1 has an installed S-PMSI A-D route originated by PE2, whose NLRI contains (C-*,C-G), then (C-*,C-G) matches this route. - otherwise, if PE1 has an installed (C-*,C-BIDIR) route from PE2, then (C-*,C-G) matches this route. - otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, then (C-*,C-G) matches this route. If a customer multicast data packet addressed to C-G is received on a P-tunnel that was not advertised in an S-PMSI A-D route matching (C-*,C-G), the packet MUST be discarded. 3.2.2. Hierarchical Partitioning This document provides support for this method only when MP2MP LSPs are being used as the P-tunnels. When this method is used, the bidirectional P-tunnel advertised in the PTA of an S-PMSI A-D route is the "outer" P-tunnel. A PE advertising a bidirectional P-tunnel in the PTA of an S-PMSI A-D route does not need to be the root of the P-tunnel. However, each P-tunnel MUST be advertised by its root, and the root MUST include a PE Distinguisher Labels attribute. This method is discussed in [MVPN], section 11.2.2. This method provides the same functionality as the flat partitioning method, but requires less state to be maintained in the core of the network. However, it requires the use of upstream-assigned MPLS labels ("PE Distinguisher Labels"), which are not necessarily supported by all platforms. The upstream-assigned labels are used to provide an LSP hierarchy, in which an "outer" MP2MP LSP carries multiple "inner" MP2MP LSPs. P routers only maintain state for the outer MP2MP LSP. In the hierarchical partitioned method, when a packet is received from a P-tunnel, the PE that receives it can infer the identity of the outer P-tunnel from the MPLS label that has risen to the top of the packet's label stack. However, the packet's "distinguished PE" is not necessarily the root node of the the outer P-tunnel. Rather, the identity of the packet's distinguished PE is inferred from the PE Distinguisher Label further down in the label stack. (See [MVPN] Section 12.3.) The PE Distinguisher Label may be thought of as identifying an "inner" MP2MP LSP whose root is the PE corresponding to that label. The hierarchical partitioned method MUST NOT be used to instantiate an I-PMSI; it is only used to instantiate S-PMSIs. It may however be Rosen, et al. [Page 14] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 used to instantiate a (C-*,C-*) S-PMSI or a (C-*,C-BIDIR) S-PMSI. When the hierarchical partitioned method is used to instantiate a (C-*,C-*) S-PMSI, a (C-*,C-BIDIR) S-PMSI, or a (C-*,C-G) S-PMSI where C-G is a BIDIR group, each of a "selected set" of PEs in a given MVPN MUST originate an S-PMSI A-D route with a PTA identifying the outer bidirectional P-tunnel. A PE is considered to be in the "selected set" if the "Partitioned Sets of PEs" method of supporting C-BIDIR traffic is being used, and the PE is provisioned to originate a (C-*,C-*) or (C-*,C-BIDIR) S-PMSI A-D route, and to use an MP2MP LSP to instantiate that S-PMSI. When the hierarchical partitioned method is used to instantiate an S-PMSI, it may be used to implement the "Partitioned Sets of PEs" method of supporting C-BIDIR, as discussed in section 11.2 of [MVPN] and section 3.6 of [RFC6517]. A C-BIDIR flow MUST be carried only on a (C-*,C-G), (C-*,C-BIDIR), or (C-*,C-*) S-PMSI. A PE MUST NOT originate a (C-S,C-G) S-PMSI A-D route for any C-G that is a C-BIDIR group. In addition, a PE, say PE1, that desires to transmit multicast data packets of a unidirectional C-flow on a MP2MP LSP MUST originate an S-PMSI A-D route with an NLRI matching the C-flow (according to the specification of [MVPN-WILDCARDS] Section 3.1). PE1 need not be the root node of the MP2MP LSP, but if it is not, the same LSP MUST have been advertised in the PTA of an S-PMSI A-D route originated by its root node, and the root node MUST include a PE Distinguisher Labels attribute that assigns a label to the IP address of PE1. If any VRF of a given MVPN uses this method when instantiating an S-PMSI with a bidirectional P-tunnel, all VRFs of that MVPN must use this method. 3.2.2.1. When an S-PMSI is a 'Match for Transmission' Given the need for a PE, say PE1, to transmit multicast data packets of a particular C-flow, [MVPN-WILDCARDS] Section 3.1 gives a four- step algorithm for determining the S-PMSI A-D route, if any, that "matches" that C-flow for transmission. If the C-flow is not a BIDIR-PIM C-flow, these rules apply unchanged. Once PE1 finds the matching S-PMSI (if any), PE1 may transmit a packet of that C-flow on the P-tunnel advertised in that route. The packet MUST carry the PE Distinguisher Label assigned by the root node of that P-tunnel to the IP address of PE1. If the C-flow is a BIDIR-PIM C-flow, the rules are given below. Rosen, et al. [Page 15] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 Assume PE1 determines that the upstream PE for C-G's C-RPA is PE2. - If there is an installed S-PMSI A-D route, or an S-PMSI A-D route originated by PE1 itself, whose NLRI contains (C-*,C-G) and whose PTA identifies a bidirectional P-tunnel, then the C-flow matches that route. - Otherwise, if there is an installed S-PMSI A-D route, or an S-PMSI A-D route currently originated by PE1 itself, whose NLRI contains (C-*,C-BIDIR) and whose PTA identifies a bidirectional P-tunnel, then the C-flow matches that route. - Otherwise, if there is an installed S-PMSI A-D route (or an S-PMSI A-D route currently originated by PE1 itself) whose NLRI contains (C-*,C-*) and whose PTA identifies a bidirectional P-tunnel, then the C-flow matches that route. PE1 MUST transmit the C-flow on the P-tunnel identified in the PTA of the matching S-PMSI A-D route. In constructing the packet's MPLS label stack, it must use the PE Distinguisher Label that was assigned by the P-tunnel's root node to the IP address of PE2. (Note: the PE Distinguisher Label is the one assigned to the address of PE2, not the one assigned to the address of PE1.) 3.2.2.2. When an S-PMSI is a 'Match for Reception' Given the need for a PE, say PE1, to receive multicast data packets of a particular C-flow, [MVPN-WILDCARDS] Section 3.2 specifies procedures for determining the S-PMSI A-D route, if any, that "matches" that C-flow for reception. Those rules require that the matching S-PMSI A-D route has been originated by the upstream PE for the C-flow. These rules are modified in this section, as follows. Consider a particular C-flow. Suppose either: - the C-flow is unidirectional, and PE1 determines that its upstream PE is PE2, or - the C-flow is bidirectional, and PE1 determines that the upstream PE for its C-RPA is PE2. Then the C-flow may match an installed S-PMSI A-D route that was not originated by PE2, as long as: Rosen, et al. [Page 16] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 1. the PTA of that A-D route identifies an MP2MP LSP, and 2. there is an installed S-PMSI A-D route originated the root node of that LSP, or PE1 itself the root node of the LSP and there is a currently originated S-PMSI A-D route from PE1 whose PTA identifies that LSP, and 3. the latter S-PMSI A-D route (the one identified in 2 just above) contains a PE Distinguisher Labels attribute that assigned an MPLS label to the IP address of PE2. However, a bidirectional C-flow never matches an S-PMSI A-D route whose NLRI contains (C-S,C-G). If a multicast data packet is received over a matching P-tunnel, but does not carry the value of the PE Distinguisher Label that has been assigned to the upstream PE for its C-flow, then the packet MUST be discarded. 3.2.3. Unpartitioned When a particular MVPN uses a bidirectional P-tunnel to instantiate an I-PMSI, every VRF of that MVPN that originates an Intra-AS I-PMSI A-D route MUST include a PTA with that route. All such PTAs MUST identify the same P-tunnel. The reception of an Intra-AS I-PMSI A-D route that does not meet these conditions signifies a configuration error; the route SHOULD be ignored and the error logged. The identity of this P-tunnel is known by provisioning. When a particular MVPN uses a bidirectional P-tunnel to instantiate a (C-*,C-*) S-PMSI, every VRF of that MVPN that originates an S-PMSI A-D route whose NLRI contains (C-*,C-*) must include a PTA with that route. All such PTAs MUST identify the same P-tunnel. The reception of a (C-*,C-*) S-PMSI A-D route that does not meet these conditions signifies a configuration error; the route SHOULD be ignored and the error logged. The identity of this P-tunnel is known by provisioning. (This requirement ensures that, given a particular packet, the algorithms of sections 3.2.2.1 and 3.2.2.2 will always choose a unique P-tunnel.) When a particular MVPN uses bidirectional P-tunnels to instantiate other S-PMSIs, different S-PMSI A-D routes that do not contain (C-*,C-*), originated by the same or by different PEs, MAY have PTAs that identify the same bidirectional tunnel, and they MAY have PTAs that do not identify the same bidirectional tunnel. When the Unpartitioned Method is used, the root node of the Rosen, et al. [Page 17] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 bidirectional P-tunnel does not need to be a PE router, and does not need to originate any BGP routes. While the Unpartitioned Method MAY be used to instantiate an S-PMSI to which one or more C-BIDIR flows are bound, it must be noted that the "Partitioned Set of PEs" method discussed in [MVPN] section 11.2 and [RFC6517] section 3.6 cannot be supported using the Unpartitioned Method. C-BIDIR support would have to be provided by the procedures of [MVPN] section 11.1. 3.2.3.1. When an S-PMSI is a 'Match for Transmission' Given the need for a PE to transmit multicast data packets of a particular customer C-flow, [MVPN-WILDCARDS] Section 3.1 gives a four-step algorithm for determining the S-PMSI A-D route, if any, that "matches" that C-flow for transmission. When referring to that section, please recall that BIDIR-PIM groups are also "Any Source Multicast" (ASM) groups. When bidirectional P-tunnels are used in the Unpartitioned Method, the same algorithm applies, with one modification, when the PTA of an S-PMSI A-D route identifies a bidirectional P-tunnel. One additional step is added to the algorithm. This new step occurs before the fourth step of the algorithm, and is as follows: - Otherwise, if there is an S-PMSI A-D route currently originated by PE1, whose NLRI contains (C-*,C-BIDIR), and if C-G is a BIDIR group, the (C-S,C-G) C-flow matches that route. 3.2.3.2. When an S-PMSI is a 'Match for Reception' Given the need for a PE to receive multicast data packets of a particular customer C-flow, [MVPN-WILDCARDS] Section 3.2 specifies the procedures for determining the S-PMSI A-D route, if any, that advertised the P-tunnel on which the PE should expect to receive that C-flow. When bidirectional P-tunnels are used in the Unpartitioned Method, the same procedures apply, with one modification. The last paragraph of Section 3.2.2 of [MVPN-WILDCARDS] begins: "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from PE2, but PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, then (C-*,C-G) matches the (C-*,C-*) route if one of the following conditions holds:" Rosen, et al. [Page 18] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 This is changed to: "If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from PE2, but C-G is a BIDIR group and PE1 has an installed (C-*,C-BIDIR) S-PMSI A-D route, then (C-*,C-G) matches that route. Otherwise, if PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, then (C-*,C-G) matches the (C-*,C-*) route if one of the following conditions holds:" 4. IANA Considerations This document has no actions for IANA. 5. Security Considerations There are no additional security considerations beyond those of [MVPN] and [MVPN-BGP], or any that may apply to the particular protocol used to set up the bidirectional tunnels ([BIDIR-PIM], [mLDP]). 6. Acknowledgments The authors wish to thank Karthik Subramanian, Rajesh Sharma, and Apoorva Karan for their input. We also thank Yakov Rekhter for his valuable critique. Special thanks go to Jeffrey Zhang for his careful review, probing questions, and useful suggestions. 7. Authors' Addresses Arjen Boers E-mail: arjen@boers.com Yiqun Cai Microsoft 1065 La Avenida Mountain View, CA 94043 E-mail: yiqunc@microsoft.com Rosen, et al. [Page 19] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 E-mail: erosen@cisco.com IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium E-mail: ice@cisco.com 8. Normative References [BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley, Kouvelas, Speakman, Vicisano, RFC 5015, October 2007 [L3VPN], "BGP/MPLS IP Virtual Private Networks", Rosen, Rekhter (editors), RFC 4364, February 2006 [mLDP] "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Wijnands, Minei, Kompella, Thomas, RFC 6388, November 2011 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., RFC 6513, February 2012 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Aggarwal, Rosen, Morin, Rekhter, RFC 6514, February 2012 [MVPN-WILDCARDS] "Wild Cards in Multicast VPN Auto-Discovery Routes", Rosen, Rekhter, Hendrickx, Qiu, RFC 6625, May 2012 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Fenner, Handley, Holbrook, Kouvelas, RFC 4601, August 2006 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, March 1997 Rosen, et al. [Page 20] Internet Draft draft-ietf-l3vpn-mvpn-bidir-04.txt January 2013 9. Informative References [RFC6517] "Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution", Morin, Niven-Jenkins, Kamite, Zhang, Leymann, Bitar, RFC 6517, February 2012 Rosen, et al. [Page 21]