Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP
The information below is for an old version of the document.
This is an older version of an Internet-Draft that was ultimately published as RFC 8338.
|Authors||Siva Sivabalan , Sami Boutros|
|Last updated||2017-05-05 (Latest revision 2017-01-05)|
|RFC stream||Internet Engineering Task Force (IETF)|
RTGDIR Last Call review by Patrice Brissette Has issues
|Additional resources||Mailing list discussion|
|Stream||WG state||Submitted to IESG for Publication|
|Document shepherd||Stewart Bryant|
|Shepherd write-up||Show Last changed 2017-04-04|
|IESG||IESG state||Expert Review|
|Responsible AD||Deborah Brungard|
|Send notices to||Stewart Bryant <email@example.com>|
INTERNET-DRAFT Siva Sivabalan(Ed.) Intended Status: Standard Track Cisco Systems Updates: RFC7385 Sami Boutros(Ed.) VMware Expires: July 9, 2017 January 5, 2017 Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP draft-ietf-pals-p2mp-pw-02.txt Abstract This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. This document updates RFC7385 by re-assigning reserved value 0xFF to be the wildcard transport tunnel type. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Sivabalan & Boutros Expires July 9, 2017 [Page 1] INTERNET DRAFT P2MP PW January 5, 2017 Copyright (c) 2017 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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Signaling P2MP PW . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 PW ingress to egress incompatibility issues . . . . . . . . 6 2.2 P2MP PW FEC . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Typed Wildcard FEC Format for new FEC . . . . . . . . . . . 10 2.4 Group ID usage . . . . . . . . . . . . . . . . . . . . . . . 11 2.5 Generic Label TLV . . . . . . . . . . . . . . . . . . . . . 11 3. LDP Capability Negotiation . . . . . . . . . . . . . . . . . . 11 4. P2MP PW Status . . . . . . . . . . . . . . . . . . . . . . . . 13 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 6 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . 13 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 7.1. FEC Type Name Space . . . . . . . . . . . . . . . . . . . . 13 7.2. LDP TLV Type . . . . . . . . . . . . . . . . . . . . . . . 14 7.3. mLDP Opaque Value Element TLV Type . . . . . . . . . . . . 14 7.4. Selective Tree Interface Parameter sub-TLV Type . . . . . . 14 7.5. WildCard PMSI tunnel type . . . . . . . . . . . . . . . . . 14 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Sivabalan & Boutros Expires July 9, 2017 [Page 2] INTERNET DRAFT P2MP PW January 5, 2017 1 Introduction A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential attributes of a unidirectional P2MP Telecommunications service such as P2MP ATM over PSN. A major difference between a Point-to-Point (P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is intended for bidirectional service whereas the latter is intended for both unidirectional, and optionally bidirectional service. Requirements for P2MP PW are described in [RFC7338]. P2MP PW can be constructed as either Single Segment (P2MP SS-PW) or Multi Segment (P2MP MS-PW) Pseudowires as mentioned in [RFC7338]. P2MP MS-PW is outside the scope of this document. A reference model or a P2MP PW is depicted in Figure 1 below. A transport LSP associated with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP TE tunnel established via RSVP-TE [RFC4875] or P2MP LSP established via mLDP [RFC6388]) spanning from the Root-PE to the Leaf-PE(s) of the P2MP SS-PW tree. For example, in Figure 1, PW1 can be associated with a P2MP TE tunnel or P2MP LSP setup using mLDP originating from PE1 and terminating at PE2, PE23 and PE4. |<--------------P2MP PW---------------->| Native | | Native Service | |<--PSN1->| |<--PSN2->| | Service (AC) V V V V V V (AC) | +-----+ +------+ +------+ | | | | | P1 |=========|T-PE2 |AC3 | +---+ | | | | .......PW1.........>|-------->|CE3| | |T-PE1|=========| . |=========| | | +---+ | | .......PW1........ | +------+ | | | . |=========| . | +------+ | | | . | | . |=========|T-PE3 |AC4 | +---+ +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| |CE1|------->|... | | |=========| | | +---+ +---+ | | . | +------+ +------+ | | | . | +------+ +------+ | | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ | | .......PW1..............PW1.........>|-------->|CE5| | | |=========| |=========| | | +---+ | +-----+ +------+ +------+ | Figure 1: P2MP PW Mechanisms for establishing P2P SS-PW using LDP are described in [RFC4447bis]. In this document, we specify a method of signaling P2MP PW using LDP. In particular, we define new FEC, TLVs, parameters, and status codes to facilitate LDP to signal and maintain P2MP PWs. Sivabalan & Boutros Expires July 9, 2017 [Page 3] INTERNET DRAFT P2MP PW January 5, 2017 As outlined in [RFC7338], even though the traffic flow from a Root-PE (R-PE) to Leaf-PE(s) (L-PEs) is P2MP in nature, it may be desirable for any L-PE to send unidirectional P2P traffic destined only to the R-PE. The proposed mechanism takes such option into consideration. The P2MP PW requires an MPLS LSP to carry the PW traffic, and the MPLS packets carrying the PW upstream label will be encapsulated according to the methods described in [RFC5332]. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. FEC: Forwarding Equivalence Class LDP: Label Distribution Protocol mLDP: Label Distribution Protocol for P2MP/MP2MP LSP LSP: Label Switching Path MS-PW: Multi-Segment Pseudowire P2P: Point to Point P2MP: Point to Multipoint PE: Provider Edge PSN: Packet Switched Network PW: Pseudowire SS-PW: Single-Segment Pseudowire S-PE: Switching Provider Edge Node of MS-PW TE: Traffic Engineering R-PE: Root-PE - ingress PE, PE initiating P2MP PW setup. L-PE: Leaf-PE - egress PE. 2. Signaling P2MP PW Sivabalan & Boutros Expires July 9, 2017 [Page 4] INTERNET DRAFT P2MP PW January 5, 2017 In order to advertise labels as well as exchange PW related LDP messages, PEs must establish LDP sessions among themselves using the Extended Discovery Mechanisms. A PE discovers other PEs that are to be connected via P2MP PWs either via manual configuration or autodiscovery [RFC6074]. R-PE and each L-PE MUST be configured with the same FEC as defined in the following section. P2MP PW requires that there is an active P2MP PSN LSP set up between R-PE and L-PE(s). Note that the procedure to set up the P2MP PSN LSP is different depending on the signaling protocol used (RSVP-TE or mLDP). In case of mLDP, a Leaf-PE can decide to join the P2MP LSP at any time; whereas in the case of RSVP-TE, the P2MP LSP is set up by the R-PE, generally at the initial service provisioning time. It should be noted that local policy can override any decision to join, add or prune existing or new L-PE(s) from the tree. In any case, the PW setup can ignore these differences, and simply assume that the P2MP PSN LSP is available when needed. P2MP PW signaling is initiated by the R-PE which sends a separate P2MP-PW LDP label mapping message to each of the the L-PE(s) belonging to that P2MP PW. This label mapping message will contain the following: 1. A FEC TLV containing P2MP PW Upstream FEC element that includes Transport LSP sub TLV. 2. An Interface Parameters TLV, as described in [RFC4447bis]. 3. A PW Grouping TLV, as described in [RFC4447bis]. 4. A label TLV for the upstream-assigned label used by R-PE for the traffic going from R-PE to L-PE(s). The R-PE imposes the upstream-assigned PW label on the outbound packets sent over the P2MP-PW, and using this label an L-PE identifies the inbound packets arriving over the P2MP PW. Additionally, the R-PE MAY send label mapping message(s) to one or more L-PE(s) to signal unidirectional P2P PW(s). The L-PE(s) can use such PW(s) to send traffic to the R-PE. This optional label mapping message will contain the following: 1. P2P PW Downstream FEC element. 2. A label TLV for the down-stream assigned label used by the corresponding L-PE to send traffic to the R-PE. The LDP liberal label retention mode is used, and per requirements specified in [RFC5036], the Label Request message MUST also be Sivabalan & Boutros Expires July 9, 2017 [Page 5] INTERNET DRAFT P2MP PW January 5, 2017 supported. The upstream-assigned label is allocated according to the rules in [RFC5331]. When an L-PE receives a PW Label Mapping Message, it MUST verify the associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP is not in place, and its type is LDP P2MP LSP, the L-PE MUST attempt to join the P2MP LSP associated with the P2MP PW. If the associated P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP LSP, the L-PE SHOULD wait till the P2MP transport LSP is signaled. If an L-PE fails to join the P2MP PSN LSP, that L-PE MUST not enable the PW, and MUST notify the user. In this case, a PW status message with status code of 0x00000008 (Local PSN-facing PW (ingress) Receive Fault) MUST also be sent to the R-PE. 2.1 PW ingress to egress incompatibility issues If an R-PE signals a PW with a pw type, CW mode, or interface parameters that a particular L-PE cannot accept, then the L-PE MUST not enable the PW, and notify the user. In this case, a PW status message with status code of 0x00000001 (Pseudowire Not Forwarding) MUST also be sent to the R-PE. Note that this procedure does not apply if the L-PE had not been provisioned with this particular P2MP PW. In this case according to the LDP liberal label retention rules, no action is taken. 2.2 P2MP PW FEC [RFC4447bis] specifies two types of LDP FEC elements called "PWid FEC Element" and "Generalized PWid FEC Element" used to signal P2P PWs. We define two new types of FEC elements called "P2MP PW Upstream FEC Element" and "P2P PW Downstream FEC Element". These FEC elements are associated with a mandatory upstream assigned label and an optional downstream assigned label respectively. A new FEC type for the P2MP PW Upstream FEC Element is pending IANA allocation and is encoded as follows: Sivabalan & Boutros Expires July 9, 2017 [Page 6] INTERNET DRAFT P2MP PW January 5, 2017 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP PW Up |C| PW Type | PW Info Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PMSI Tunnel typ| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + ~ Transport LSP ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: P2MP PW Upstream FEC Element * P2MP PW Up 8 bits representation for the P2MP PW Upstream FEC type. * PW Type: 15 bits representation of PW type, and the assigned values are assigned by IANA. * C bit: A value of 1 or 0 indicates whether control word is present or absent for the P2MP PW. * PW Info Length: Sum of the lengths of AGI, SAII, PMSI Tunnel info, and Optional Parameters field in octets. If this value is 0, then it references all PWs using the specified grouping ID. In this case, there are neither other FEC element fields (AGI, SAII, etc.) present, nor any Sivabalan & Boutros Expires July 9, 2017 [Page 7] INTERNET DRAFT P2MP PW January 5, 2017 interface parameters TLVs. Alternatively, we can use typed wildcard FEC described in section 3.3 to achieve the same or to have better filtering. * AGI: Attachment Group Identifier can be used to uniquely identify VPN or VPLS instance associated with the P2MP PW. This has the same format as the Generalized PWid FEC element [RFC4447bis]. * SAII: Source Attachment Individual Identifier is used to identify the root of the P2MP PW. The root is represented using AII type 2 format specified in [RFC5003]. Note that the SAII can be omitted by simply setting the length and type to zero. P2MP PW is identified by the Source Attachment Identifier (SAI). If the AGI is non-null, the SAI is the combination of the SAII and the AGI, if the AGI is null, the SAI is the SAII. * PMSI Tunnel Type and Transport LSP ID: A P2MP PW MUST be associated with a transport LSP which can be established using RSVP-TE or mLDP. * PMSI Tunnel Type: The PMSI tunnel type is defined in [RFC6514]. When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a P2MP FEC Element as defined in [RFC6388]. A new mLDP Opaque Value Element type for L2VPN-MCAST application needs to be allocated. * Transport LSP ID: This is the Tunnel Identifier which is defined in [RFC6514]. An R-PE sends Label Mapping Message as soon as the transport LSP ID associated with the P2MP PW is known (e.g., via configuration) regardless of the operational state of that transport LSP. Similarly, an R-PE does not withdraw the labels when the corresponding transport LSP goes down. Furthermore, an L-PE retains the P2MP PW labels regardless of the operational status of the transport LSP. Note that a given transport LSP can be associated with more than one P2MP PWs in which case P2MP PWs will be sharing the same R-PE and L- PE(s). An R-PE may also have many P2MP PWs with disjoint L-PE sets. Sivabalan & Boutros Expires July 9, 2017 [Page 8] INTERNET DRAFT P2MP PW January 5, 2017 In the case of LDP P2MP LSP, when an L-PE receives the Label Mapping Message, it can initiate the process of joining the P2MP LSP tree associated with the P2MP PW. In the case of RSVP-TE P2MP LSP, only the R-PE initiates the signaling of P2MP LSP. * Optional Parameters: The Optional Parameter field can contain some TLVs that are not part of the FEC, but are necessary for the operation of the PW. This proposed mechanism uses two such TLVs: Interface Parameters TLV, and Group ID TLV. The Interface Parameters TLV and Group ID TLV specified in [RFC4447bis] can also be used in conjunction with P2MP PW FEC in a label message. For Group ID TLV, the sender and receiver of these TLVs should follow the same rules and procedures specified in [RFC4447bis]. For Interface Parameters TLV, the procedure differs from the one specified in [RFC4447bis] due to specifics of P2MP connectivity. When the interface parameters are signaled by a R-PE, each L-PE must check if its configured value(s) is less than or equal to the threshold value provided by the R-PE (e.g. MTU size (Ethernet), max number of concatenated ATM cells, etc)). For other interface parameters like CEP/TDM Payload bytes (TDM), the value MUST exactly match the values signaled by the R-PE. Multicast traffic stream associated with a P2MP PW can be selective or inclusive. To support the former, this document defines a new optional Selective Tree Interface Parameter sub-TLV (type is pending IANA allocation) according to the format described in [RFC4447bis]. The value of the sub-TLV contains the source and the group for a given multicast tree as shown in Figure 3. Also, if a P2MP PW is associated with multiple selective trees, the corresponding label mapping message will carry more than one instance of this Sub-TLV. Furthermore, in the absence of this sub-TLV, the P2MP PW is associated with all multicast traffic stream originating from the root. +----------------------------------------- + | Sub-TLV Type (1 Octet) | +----------------------------------------- + | Length (1 Octet) | +----------------------------------------- + | Multicast Source Length (1 Octet) | +----------------------------------------- + | Multicast Source (variable length) | +----------------------------------------- + Sivabalan & Boutros Expires July 9, 2017 [Page 9] INTERNET DRAFT P2MP PW January 5, 2017 | Multicast Group Length (1 Octet) | +----------------------------------------- + | Multicast Group (variable length) | +----------------------------------------- + Figure 3: Selective Tree Interface Parameter Sub-TLV Value Note that since the LDP label mapping message is only sent by the R- PE to all the L-PEs, it is not possible to negotiate any interface parameters. The type of optional P2P PW Downstream FEC Element is pending IANA allocation, and is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2P PW Down |C| PW Type | PW Info Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: P2P PW Downstream FEC Element The definition of the fields in the P2P PW Downstream FEC Element is the same as those of P2MP PW Upstream FEC Element shown in Figure 2. 2.3 Typed Wildcard FEC Format for new FEC [RFC5918] defines the general notion of a "Typed Wildcard" FEC Element, and requires FEC designer to specify a typed wildcard FEC element for newly defined FEC element types. This document defines two new FEC elements, "P2MP PW Upstream" and "P2P PW Downstream" FEC element, and hence requires us to define their Typed Wildcard format. [RFC6667] defines Typed Wildcard FEC element format for other PW FEC Element types (PWid and Gen. PWid FEC Element) in section 2 as Sivabalan & Boutros Expires July 9, 2017 [Page 10] INTERNET DRAFT P2MP PW January 5, 2017 follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Typed Wcard=0x5|Type=PW FEC | Len = 3 |R| PW type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | PMSI Tun Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Typed Wildcard Format for P2MP PW FEC Elements [RFC6667] specifies that "Type" field can be either "PWid" (0x80) or "Generalized PWid" (0x81) FEC element type. This document reuses the existing typed wildcard format as specified in [RFC6667] and illustrated in Figure 5. We extend the definition of "Type" field to also include "P2MP PW Upstream" and "P2P PW Downstream" FEC element types, as well as add an additional field "PMSI Tun Type". We reserve PMSI tunnel Type 0xFF to mean "wildcard" transport tunnel type. This "wildcard" transport tunnel type can be used in a typed wildcard p2mp FEC for further filtering. This field only applies to Typed wildcard P2MP PW Upstream FEC and MUST be set to "wildcard" for "P2P PW Downstream FEC" typed wildcard element. 2.4 Group ID usage The Grouping TLV as defined in [RFC4447bis] contains a group ID capable of indicating an arbitrary group membership of a P2MP-PW. This group ID can be used in LDP "wild card" status, and withdraw label messages, as described in [RFC4447bis]. 2.5 Generic Label TLV As in the case of P2P PW signaling, P2MP PW labels are carried within Generic Label TLV contained in LDP Label Mapping Message. A Generic Label TLV is formatted and processed as per the rules and procedures specified in [RFC4447bis]. For a given P2MP PW, a single upstream- assigned label is allocated by the R-PE, and is advertised to all L- PEs using the Generic Label TLV in label mapping message containing the P2MP PW Upstream FEC element. The R-PE can also allocate a unique label for each L-PE from which it intends to receive P2P traffic. Such a label is advertised to the L- PE using Generic Label TLV and P2P PW Downstream FEC in label mapping message. 3. LDP Capability Negotiation Sivabalan & Boutros Expires July 9, 2017 [Page 11] INTERNET DRAFT P2MP PW January 5, 2017 The capability of supporting P2MP PW must be advertised to all LDP peers. This is achieved by using the methods in [RFC5561] and advertising the LDP "P2MP PW Capability" TLV. If an LDP peer supports the dynamic capability advertisement, this can be done by sending a new Capability message with the S bit set for the P2MP PW capability TLV. If the peer does not supports dynamic capability advertisement, then the P2MP PW Capability TLV MUST be included in the LDP Initialization message during the session establishment. An LSR having P2MP PW capability MUST recognize both P2MP PW Upstream FEC Element and P2P PW Downstream FEC Element in LDP label messages. In line with requirements listed in [RFC5561], the following TLV is defined to indicate the P2MP PW capability: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| P2MP PW Capability TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: LDP P2MP PW Capability TLV Note: TLV number pending IANA allocation. * U-bit: SHOULD be 1 (ignore if not understood). * F-bit: SHOULD be 0 (don't forward if not understood). * P2MP PW Capability TLV Code Point: The TLV type, which identifies a specific capability. The P2MP PW capability code point is requested in the IANA allocation section below. * S-bit: The State Bit indicates whether the sender is advertising or withdrawing the P2MP PW capability. The State bit is used as follows: 1 - The TLV is advertising the capability specified by the TLV Code Point. Sivabalan & Boutros Expires July 9, 2017 [Page 12] INTERNET DRAFT P2MP PW January 5, 2017 0 - The TLV is withdrawing the capability specified by the TLV Code Point. * Length: MUST be set to 2 (octet). 4. P2MP PW Status In order to support the proposed mechanism, a node MUST be capable of handling PW status. As such, PW status negotiation procedure described in [RFC4447bis] is not applicable to P2MP PW. A node MUST NOT claim to be P2MP PW capable by sending a LDP P2MP PW Capability TLV if it is not also capable of handling PW status. Once an L-PE successfully processes a Label Mapping Message for a P2MP PW, it MUST send appropriate PW status according to the procedure specified [RFC4447bis] to report the PW status. If no PW status notification is required, then no PW status notification is sent (for example if the P2MP PW is established and operational with a status code of Success (0x00000000), a PW status message is not necessary). A PW status message sent from an L-PE to R-PE MUST contain the P2P PW Downstream FEC to identify the PW. An R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP PW state. Such PW status message contains P2MP PW Upstream FEC to identify the PW. Connectivity status of the underlying P2MP LSP that P2MP PW is associated with, can be verified using LSP Ping and Traceroute procedures described in [RFC6425]. 5 Security Considerations The security measures described in [RFC4447bis] are adequate for the proposed mechanism. 6 Acknowledgment Authors would like thank Andre Pelletier and Parag Jain for their valuable suggestions. 7 IANA Considerations 7.1. FEC Type Name Space Sivabalan & Boutros Expires July 9, 2017 [Page 13] INTERNET DRAFT P2MP PW January 5, 2017 This document uses two new FEC element types, number 0x82 and 0x83 are suggested for assignment from the registry "FEC Type Name Space" for the Label Distribution Protocol (LDP RFC5036): Value Hex Name Reference ------- ----- ----------------------------- --------- 130 0x82 P2MP PW Upstream FEC Element RFCxxxx 131 0x83 P2P PW Downstream FEC Element RFCxxxx 7.2. LDP TLV Type This document uses a new LDP TLV types, IANA already maintains a registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The following values are suggested for assignment: TLV type Description: 0x0703 P2MP PW Capability TLV 7.3. mLDP Opaque Value Element TLV Type This document requires allocation of a new mLDP Opaque Value Element Type from "LDP MP Opaque Value Element basic type" name space defined in [RFC6388]. The following value is suggested for assignment: TLV type Description 0x3 L2VPN-MCAST application TLV 7.4. Selective Tree Interface Parameter sub-TLV Type This document requires allocation of a sub-TLV from the registry "Pseudowire Interface Parameters Sub-TLV Type" defined in [RFC4446]. The following value is suggested for assignment: TLV type Description 0x1b Selective Tree Interface Parameter. 7.5. WildCard PMSI tunnel type This document requests that IANA modify the following entry in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry within the "Border Gateway Protocol (BGP) Parameters" namespace previously assigned by RFC7385 as "reserved". Sivabalan & Boutros Expires July 9, 2017 [Page 14] INTERNET DRAFT P2MP PW January 5, 2017 Value Meaning Reference 0xFF wildcard transport tunnel type [This document] 8 References 8.1. Normative References [RFC2119] Bradner. S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [RFC4447bis] "Pseudowire Setup and Maintenance using the Label Distribution Protocol", Martini, L., et al., draft-ietf-pals- rfc4447bis-05.txt, July 2016. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC5003, September 2007. [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008. [RFC5332] T. Eckert, E. Rosen, Ed.,R. Aggarwal, Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. [RFC6388] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011. [RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs).", RFC 4875, May 2007. [RFC6514] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC6514, February 2012. [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009. [RFC5918] R. Asati, I. Minei, and B. Thomas, "LDP Typed Wildcard Forwarding Equivalence Class", RFC 5918, August 2010. Sivabalan & Boutros Expires July 9, 2017 [Page 15] INTERNET DRAFT P2MP PW January 5, 2017 [RFC6667] K. Raza, S. Boutros, and C. Pignataro, "LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements", RFC 6667, July 2012. 8.2. Informative References [RFC3985] Stewart Bryant, et al., "PWE3 Architecture", RFC3985 [RFC6074] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning, Auto- Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC6074, January 2011. [RFC7338] F. Jounay, et. al, "Requirements for Point to Multipoint Pseudowire", RFC7338, September 2014. [RFC6425] A. Farrel, S. Yasukawa, "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS)- Extensions to LSP Ping", RFC6425, November 2011. Contributors The following co-authors have also contributed to this document: Luca Martini Cisco Systems, Inc. Email: firstname.lastname@example.org Maciek Konstantynowicz Cisco Systems, Inc. e-mail: email@example.com Gianni Del Vecchio Swisscom Email: Gianni.DelVecchio@swisscom.com Thomas D. Nadeau Brocade Email: firstname.lastname@example.org Frederic Jounay Orange CH Email: Frederic.Jounay@salt.ch Philippe Niger Orange CH Email: email@example.com Sivabalan & Boutros Expires July 9, 2017 [Page 16] INTERNET DRAFT P2MP PW January 5, 2017 Yuji Kamite NTT Communications Corporation Email: firstname.lastname@example.org Lizhong Jin Email: email@example.com Martin Vigoureux Nokia Email: firstname.lastname@example.org Laurent Ciavaglia Nokia Email: email@example.com Simon Delord Telstra E-mail: firstname.lastname@example.org Kamran Raza Cisco Systems Email: email@example.com Authors' Addresses Siva Sivabalan Cisco Systems, Inc. Email: firstname.lastname@example.org Sami Boutros VMware Inc. Email: email@example.com Sivabalan & Boutros Expires July 9, 2017 [Page 17]