INTERNET-DRAFT Sami Boutros(Ed.) Intended Status: Standard Track VMwareInternet Engineering Task Force (IETF) S. Boutros, Ed. Request for Comments: 8338 VMWare Updates:RFC7385 Siva Sivabalan(Ed.)7385 S. Sivabalan, Ed. Category: Standards Track Cisco SystemsExpires: May 16,ISSN: 2070-1721 March 2018November 12, 2017Signaling Root-Initiated Point-to-Multipoint PseudowireusingUsing LDPdraft-ietf-pals-p2mp-pw-04.txtAbstract This document specifies a mechanism to signal Point-to-Multipoint (P2MP)PseudowiresPseudowire (PW)treetrees using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP orMPLS enabledMPLS-enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. This document updatesRFC7385RFC 7385 byre-assigningreassigning the reserved value 0xFF to be the wildcard transport tunnel type. Status ofthisThis Memo ThisInternet-Draftissubmitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product 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(IETF). It represents the consensus ofsix monthsthe IETF community. It has received public review andmay be updated, replaced, or obsoletedhas been approved for publication byother documents at any time. Itthe Internet Engineering Steering Group (IESG). Further information on Internet Standards isinappropriate to use Internet-Drafts as reference material or to cite them other than as "workavailable inprogress." The listSection 2 of RFC 7841. Information about the currentInternet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The liststatus ofInternet-Draft Shadow Directories canthis document, any errata, and how to provide feedback on it may beaccessedobtained athttp://www.ietf.org/shadow.htmlhttps://www.rfc-editor.org/info/rfc8338. Copyrightand LicenseNotice Copyright (c)20172018 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)(https://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 Contents11. Introduction . . . . . . . . . . . . . . . . . . . . . . . .. 3 1.12 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 42. Signaling P2MP PW2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . .4 2.1 PW ingress to egress incompatibility issues. . . . . . . .6 2.2 P2MP PW FEC. . . . . . . . . 4 3. Signaling P2MP PW . . . . . . . . . . . . . . .6 2.2.1 P2MP PW Upstream FEC Element. . . . . . . 5 3.1. PW Ingress-to-Egress Incompatibility Issues . . . . . . . 62.2.2 P2P3.2. P2MP PWDownstreamFECElement. . . . . . . . . . . . .10 2.3 Typed Wildcard FEC Format for new FEC. . . . . . . . . . 6 3.2.1. P2MP PW Upstream FEC Element .10 2.4 Group ID usage. . . . . . . . . . . 7 3.2.2. P2P PW Downstream FEC Element . . . . . . . . . . . . 112.5 Generic Label TLV3.3. Typed Wildcard FEC Format for a New FEC . . . . . . . . . 11 3.4. Group ID Usage . . . . . . . . . . . . .11 3. LDP Capability Negotiation. . . . . . . . 12 3.5. Generic Label TLV . . . . . . . . . .12 4. P2MP PW Status. . . . . . . . . . 12 4. LDP Capability Negotiation . . . . . . . . . . . . . .13 5 Security Considerations. . . 12 5. P2MP PW Status . . . . . . . . . . . . . . . . .13 6 Acknowledgment. . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . .13 714 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . ..14 7.1. FEC Type Name Space . . . . . . . . . . . . . . . . . . .. 1415 7.2. LDP TLV Type . . . . . . . . . . . . . . . . . . . . . .. 1415 7.3. mLDP Opaque Value Element TLV Type . . . . . . . . . . .. 1415 7.4. Selective Tree Interface Parametersub-TLVSub-TLV Type . . . . .. 1415 7.5.WildCardWildcard PMSItunnel type .Tunnel Type . . . . . . . . . . . . . . . . 1588. References . . . . . . . . . . . . . . . . . . . . . . . . .. 1516 8.1. Normative References . . . . . . . . . . . . . . . . . .. 1516 8.2. Informative References . . . . . . . . . . . . . . . . . 17 Acknowledgments .16 Contributors. . . . . . . . . . . . . . . . . . . . . . . . 18 Contributors . . .16 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses .17 1. . . . . . . . . . . . . . . . . . . . . . 19 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 bothunidirectional, and optionallyunidirectional and, optionally, bidirectional service. Requirements for P2MPPWPWs are described in [RFC7338]. P2MPPWPWs can be constructed as either Single Segment Pseudowires (P2MPSS-PW)SS-PWs) orMulti Segment (P2MP MS-PW)Multi-Segment Pseudowires (P2MP MS-PWs) as mentioned in [RFC7338]. P2MP MS-PW is outside the scope of this document. A reference model or a P2MP PW is depicted in Figure1 below.1. A transportLSPLabel Switched Path (LSP) associated with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MPTETraffic Engineering (TE) tunnel established via RSVP-TE [RFC4875] or P2MP LSP established viamLDPMultipoint LDP (mLDP) [RFC6388]) spanning from theRoot-PERoot PE (Provider Edge) to theLeaf-PE(s)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,PE3PE3, 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 a P2P SS-PW using LDP are described in[RFC4447bis].[RFC8077]. This documentspecifyspecifies a method of signaling P2MP PW using LDP. In particular, this document defines a newFEC,Forwarding Equivalence Class (FEC), TLVs, parameters, and status codes to facilitate LDPto signalsignaling andmaintainmaintaining P2MP PWs. As outlined in [RFC7338], even though the traffic flow from aRoot-PERoot PE (R-PE) toLeaf-PE(s)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 an 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.12. Terminology 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described inRFC 2119 [RFC2119].BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. Abbreviations AGI: Attachment Group Identifier CE: Customer Edge FEC: Forwarding Equivalence Class L-PE: Leaf PE (egress PE) LDP: Label Distribution Protocol LSP: Label Switched Path mLDP: Multipoint Label Distribution Protocolfor(for P2MP/MP2MPLSP LSP: Label Switching PathLSP) MS-PW: Multi-Segment PseudowireP2P: Point to PointP2MP:Point to MultipointPoint-to-Multipoint P2P: Point-to-Point PE: Provider Edge PSN: Packet Switched Network PW: PseudowireSS-PW: Single-Segment PseudowireR-PE: Root PE (ingress PE, PE initiating P2MP PW setup) S-PE: Switching Provider Edgeof MS-PW(of MS-PW) SS-PW: Single-Segment Pseudowire TE: Traffic EngineeringR-PE: Root-PE - ingress PE, PE initiating P2MP PW setup. L-PE: Leaf-PE - egress PE. 2.3. Signaling P2MP PW In order to advertise labels as well as exchangePW relatedPW-related LDP messages, PEs must establish LDP sessions among themselves. A PE discovers other PEs that are to be connected via P2MP PWs either via manual configuration or autodiscovery [RFC6074]. An R-PE and each L-PE MUST be configured with the same FEC as defined inthe following section.Section 3.2. P2MP PW requires that thereisbe an active P2MP PSN LSP set up between an 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 the case of mLDP, aLeaf-PELeaf PE can decide to join the P2MP LSP at any time. 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,addadd, or prune existing or newL-PE(s)L-PEs from the tree. In any case, the PW setup can ignore thesedifferences,differences and simply assume that the P2MP PSN LSP is available when needed. P2MP PW signaling is initiated by theR-PER-PE, which sends a separateP2MP-PWP2MP PW LDPlabel mapping messageLabel Mapping Message to each of thetheL-PE(s) belonging to that P2MP PW. Thislabel mapping messageLabel Mapping Message will contain the following: 1. A FEC TLV containing a P2MP PW Upstream FECelementElement that includes a Transport LSPsub TLV.sub-TLV. 2. An Interface Parameters TLV, as described in[RFC4447bis].[RFC8077]. 3. A PWGroupingGroup ID TLV, as described in[RFC4447bis].[RFC8077]. 4. A label TLV for the upstream-assigned label used by an R-PE for the traffic going from the R-PE to L-PE(s). The R-PE imposes the upstream-assigned PW label on the outbound packets sent over theP2MP-PW, andP2MP PW; using thislabellabel, an L-PE identifies the inbound packets arriving over the P2MP PW. Additionally, the R-PE MAY sendlabel mapping message(s)Label Mapping Messages to one or moreL-PE(s)L-PEs to signal a unidirectional P2P PW(s). The L-PE(s) can use such a PW(s) to send traffic to the R-PE. This optionallabel mapping messageLabel Mapping Message will contain the following: 1. A P2P PW Downstream FECelement.Element 2. A label TLV for thedown-stream assigneddownstream-assigned label used by the corresponding L-PE to send traffic to theR-PE.R-PE The LDP liberal label retention mode MUST beused, andused; per requirements specified in [RFC5036], the Label Request message MUST also be 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 inplace,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 thePW,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.13.1. PWingress to egress incompatibility issuesIngress-to-Egress Incompatibility Issues If an R-PE signals a PW with apw type, CWPW Type, Control Word (CW) mode, or interface parameters that a particular L-PE cannot accept, then the L-PE MUSTnotNOT enable thePW,PW and should 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-PEhadwas notbeenprovisioned with this particular P2MP PW. In thiscasecase, according to the LDP liberal label retention rules, no action is taken.2.23.2. P2MP PW FEC[RFC4447bis][RFC8077] specifies two types of LDP FEC elementscalledused to signal P2P PWs: "PWid FEC Element" and "Generalized PWid FECElement" used to signal P2P PWs.Element". This documentdefinesuses twonew types ofFECelements calledelements: "P2MP PW Upstream FEC Element" and "P2P PW Downstream FEC Element". These FEC elements are associated with a mandatoryupstream assignedupstream-assigned label and an optionaldownstreamdownstream- assignedlabellabel, respectively.2.2.13.2.1. P2MP PW Upstream FEC ElementA newThe FEC type for the P2MP PW Upstream FEC Element 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P2MP PW Up=0x82|C| PW Type | PW Info Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | AGI Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | SAII Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PMSI Tunneltyp|Typ|PMSI TT Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + ~ Transport LSP ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: P2MP PW Upstream FEC Element * P2MP PW Up:8 bits8-bit representation for the P2MP PW Upstream FEC type. *PW Type: 15 bits representation of PW type as specified in [RFC4447bis]. *C bit: A value of 1 or 0indicatesindicating whether a control word is present or absent for the P2MP PW. * PWInfo Length: Sum of the lengthsType: 15-bit representation ofAGI, SAII,PW Type as specified in [RFC8077]. * PW Info Length: Sum of the AGI Length, SAII Length, PMSI Tunnelinfo,Type Length, and Optional Parametersfieldfields in octets. If this value is 0, then it references all PWs using the specifiedgroupinggroup ID. In this case, there are neither other FEC element fields(AGI, SAII,(AGI Type, SAII Value, etc.) present, nor any interface parameters TLVs. Alternatively, typed wildcard FEC described insection 3.3,Section 2.3, can be used to achieve the same or to have better filtering. * AGI: An Attachment Group Identifier TLV can be used to uniquely identify a VPN orVPLSVirtual Private LAN Service (VPLS) instance associated with the P2MP PW. This has the same format as the Generalized PWid FECelement [RFC4447bis].Element [RFC8077]. *SAII:SAII Value: A Source Attachment Individual Identifier is used to identify the root of the P2MP PW. The root is represented using AIItypeType 2 format specified in [RFC5003]. Note that the SAII can be omitted by simply setting the length and type to zero. The 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 TunnelinfoInfo: The PMSI TunnelinfoInfo is the combination of the PMSI Tunnel Type, PMSI Tunnel Type Length (shown in the figure as PMSI TT Length), and Transport LSPID.ID fields. A P2MP PW MUST be associated with a transportLSPLSP, which can be established using RSVP-TE or mLDP. * PMSI Tunnel Type: The PMSItunnel typeTunnel 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].AThe new mLDP Opaque Value Element type for the L2VPN-MCAST applicationasTLV (as specified in the IANAconsiderationsConsiderations section (Section 7)) MUST be used. * Transport LSP ID: This is the Tunnel Identifierwhichthat is defined in [RFC6514]. An R-PE sends a 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 P2MPPWsPW; in whichcasecase, P2MP PWs will be sharing the same R-PE andL- PE(s).L-PE(s). An R-PE may also have many P2MP PWs with disjoint L-PE sets. 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: the Interface ParametersTLV,TLV and the PW Group ID TLV. The Interface Parameters TLV and PW Group ID TLV specified in[RFC4447bis][RFC8077] can also be used in conjunction with P2MP PW FEC in a label message. For the PW Group ID TLV, the sender and receiver of these TLVs should follow the same rules and procedures specified in[RFC4447bis].[RFC8077]. For the Interface Parameters TLV, the procedure differs from the one specified in[RFC4447bis][RFC8077] due to specifics of P2MP connectivity. When the interface parameters are signaled byaan 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.(e.g., MTU size (Ethernet), max number of concatenated ATM cells,etc)).etc.). For other interfaceparametersparameters, like CEP/TDM Payloadbytes (TDM),Bytes, the value MUST exactly match the values signaled by the R-PE.MulticastA 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, as described in the IANAconsiderationsConsiderations section (Section 7) and according to the format described in[RFC4447bis].[RFC8077]. The value of the sub-TLV contains the source and the group for a given multicasttreetree, as shown in Figure 3. Also, if a P2MP PW is associated with multiple selective trees, the correspondinglabel mapping messageLabel Mapping Message will carry more than one instance of thisSub-TLV.sub-TLV. Furthermore, in the absence of this sub-TLV, the P2MP PW is associated with all multicast trafficstreamstreams originating from the root.+----------------------------------------- ++-----------------------------------------+ | Sub-TLV Type (1 Octet) |+----------------------------------------- ++-----------------------------------------+ | Length (1 Octet) |+----------------------------------------- ++-----------------------------------------+ | Multicast Source Length (1 Octet) |+----------------------------------------- ++-----------------------------------------+ | Multicast Source (variable length) |+----------------------------------------- ++-----------------------------------------+ | Multicast Group Length (1 Octet) |+----------------------------------------- ++-----------------------------------------+ | Multicast Group (variable length) |+----------------------------------------- ++-----------------------------------------+ Figure 3: Selective Tree Interface Parameter Sub-TLV Value Note that since the LDPlabel mapping messageLabel Mapping Message is only sent by theR- PER-PE to all the L-PEs, it is not possible to negotiate any interface parameters.2.2.23.2.2. P2P PW Downstream FEC Element The optional P2P PW Downstream FEC Element 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P2PPWDown=0x83|C|PWDown=0x84|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 FECElementElement, shown in Figure 2.2.33.3. Typed Wildcard FEC Format fornewa New FEC [RFC5918] defines the general notion of a"Typed Wildcard"Typed Wildcard FECElement, andElement; it requires FECdesignerdesigners to specify atyped wildcardTyped Wildcard FECelementElement for newly defined FEC element types. This documentdefinesuses twonewFECelements,elements: "P2MP PW Upstream" and "P2P PWDownstream" FEC element, and hence requires us to defineDownstream". Hence, definition of their Typed Wildcardformat.format is required. [RFC6667] defines the Typed Wildcard FECelementElement format for other PW FEC Element types (PWid andGen.Generalized PWid FEC Element) insection 2Section 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Typed Wcard=0x5|Type=PW FEC | Len = 3 |R| PWtypeType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | PMSI Tun Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Typed Wildcard Format for P2MP PW FEC Elements [RFC6667] specifies that"Type"the Type field can be either the "PWid" (0x80) or "Generalized PWid" (0x81) FECelementElement type. This document reuses the existingtyped wildcardTyped Wildcard formatasspecified in [RFC6667] and illustrated in Figure 5 and extends the definition of"Type"the Type field to also include"P2MPthe P2MP PWUpstream"Upstream FEC Element and"P2PP2P PWDownstream"Downstream FECelementElement types. This document adds an additional field called the "PMSITunTunnel Type". This document reserves PMSItunnelTunnel Type 0xFF to mean"wildcard""wildcard transport tunneltype.type". The PMSItunnelTunnel Type field only applies to the TypedwildcardWildcard P2MP PW Upstream FEC Element and MUST be set to "wildcard" for "P2P PW DownstreamFEC"FEC Element" typedwildcard element. 2.4wildcard. 3.4. Group IDusageUsage TheGroupingPW Group ID TLV as defined in[RFC4447bis][RFC8077] contains a group ID capable of indicating an arbitrary group membership of aP2MP-PW.P2MP PW. This group ID can be used in LDP"wild card" status,"wildcard" status and withdraw label messages, as described in[RFC4447bis]. 2.5[RFC8077]. 3.5. Generic Label TLV As in the case of P2P PW signaling, P2MP PW labels are carried within the Generic Label TLV contained in the LDP Label Mapping Message. A Generic Label TLV is formatted and processed as per the rules and procedures specified in[RFC4447bis].[RFC8077]. For a given P2MP PW, a singleupstream- assignedupstream-assigned label is allocated by theR-PE,R-PE and is advertised to allL- PEsL-PEs using the Generic Label TLV inlabel mapping messageLabel Mapping Messages containing the P2MP PW Upstream FECelement.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 theL- PEL-PE using the Generic Label TLV and P2P PW Downstream FEC Element inlabel mapping message. 3.Label Mapping Messages. 4. LDP Capability Negotiation The capability of supporting P2MPPWPWs MUST be advertised to all LDP peers. This is achieved by using the methods in [RFC5561] to advertise the LDP"P2MPP2MP PWCapability"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 PWcapabilityCapability TLV. If the peer does notsupportssupport dynamic capability advertisement, then the P2MP PW Capability TLV MUST be included in the LDP Initialization message duringthesession establishment.An LSRA Label Switched Router (LSR) having P2MP PW capability MUST recognize both the 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure7:6: LDP P2MP PW Capability TLV *U-bit:U bit: The Unknown bit [RFC5036] SHOULD be 1 (ignore if not understood). *F-bit:F bit: The Forward unknown bit [RFC5036] SHOULD be 0 (don't forward if not understood). * P2MP PW Capability TLV Code Point: The TLV type, which identifies a specific capability.TheNote that the P2MP PWcapability code point is requestedCapability Code Point appears in the IANAallocationConsiderations sectionbelow.(Section 7). *S-bit: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 P2MP PW Capability TLV Code Point. 0 - The TLV is withdrawing the capability specified by theTLV CodeP2MP PW Capability TLV Code Point. * Length: MUST be set to 2 (octet).4.5. P2MP PW Status In order to support the proposed mechanism, an LSR MUST be capable of handling PW status. As such, the PW status negotiationprocedureprocedures described in[RFC4447bis] is[RFC8077] are not applicable to P2MP PW. An LSR MUST NOT claim to be P2MP PW capable by sendingaan 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][RFC8077] to report the PW status. If no PW status notification is required, then no PW status notification is sent (forexampleexample, if the P2MP PW is established and operational with a status code ofSuccess (0x00000000),0x00000000 (Success), a PW status message is not necessary). A PW status message sent from an L-PE to an R-PE MUST contain the P2P PW Downstream FEC Element 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 a PW status message contains a P2MP PW Upstream FEC Element to identify the PW. Connectivity status of the underlying P2MP LSP that the P2MP PW is associatedwith,with can be verified using LSPPingping andTraceroutetraceroute procedures described in [RFC6425].56. Security Considerations Ingeneralgeneral, the security measures described in[RFC4447bis][RFC8077] are adequate for this protocol.HoweverHowever, the use of MD5 as the method of securing an LDP control plane is no longer considered adequately secure. Implementations should be written in such a way that they can migrate to a more secure cryptographic hash function when the next authentication method to be used in the LDP might not be a simplehash basedhash-based authentication algorithm.6 Acknowledgment Authors would like thank Andre Pelletier and Parag Jain for their valuable suggestions. 77. IANA Considerations 7.1. FEC Type Name Space This document uses twonewFEC element types,number0x82 and0x83 are suggested for assignment from0x84, in theregistry "FEC"Forwarding Equivalence Class (FEC) Type Name Space" registry for the Label Distribution Protocol(LDP RFC5036):(LDP) [RFC5036]. IANA has added this document as a reference for the following entries: Value Hex Name Reference------------- ----- ---------------------------------------------------------- 130 0x82 P2MP PW Upstream FEC ElementRFCxxxx 131 0x83[RFC8338] [RFC7358] 132 0x84 P2P PW Downstream FEC ElementRFCxxxx[RFC8338] [RFC7358] 7.2. LDP TLV Type This documentusesdefines a new LDP TLVtypes, IANA already maintains a registry of nametype in the "TLVTYPE NAME SPACE" defined by RFC5036. TheType Name Space" registry [RFC5036]. IANA has assigned the followingvalues are suggested for assignment:value: TLVtype Description:Type Description -------- ---------------------- 0x0703 P2MP PW Capability TLV 7.3. mLDP Opaque Value Element TLV TypeThis document requires allocation ofIANA has assigned a new mLDP Opaque Value Element Typefromin the "LDP MP Opaque Value Element basic type"name space defined in [RFC6388]. The following value is suggested for assignment:registry [RFC6388] as follows: TLVtypeType Description ------- --------------------------- 13 L2VPN-MCAST application TLV Length: 4 Value: A 32-bit integer, unique in the context of the root, as identified by the root's address. 7.4. Selective Tree Interface Parametersub-TLVSub-TLV TypeThis document requires allocation ofIANA has assigned a sub-TLV from theregistry"Pseudowire Interface Parameters Sub-TLVType" defined in [RFC4446]. The following value is suggested for assignment: TLVtype Registry" [RFC4446] as follows: TLV Type Description0x1b-------- ---------------------------------- 0x1B Selective Tree InterfaceParameter.Parameter 7.5.WildCardWildcard PMSItunnel type This document requests thatTunnel Type IANAmodify the followinghas modified an entry in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry within the "Border Gateway Protocol (BGP) Parameters"namespaceregistry [RFC7385]. Value 0xFF, which was previouslyassigned by RFC7385marked as"reserved"."Reserved", has been updated as follows: Value Meaning Reference ----- ------------------------------ --------- 0xFF wildcard transport tunnel type[This document] 8[RFC8338] 8. References 8.1. Normative References [RFC2119]Bradner. S,Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119,March, 1997. [RFC4447bis] "Pseudowire Setup and Maintenance using the Label Distribution Protocol",DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4446] Martini, L.,et al., draft-ietf-pals- rfc4447bis-05.txt, July 2016. [RFC5036] Andersson, L., Minei, I.,"IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <https://www.rfc-editor.org/info/rfc4446>. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., andB. Thomas, "LDP Specification",S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC5036, October 2007.4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>. [RFC5003]C.Metz,L.C., Martini,F.L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation",RFC5003,RFC 5003, DOI 10.17487/RFC5003, September2007.2007, <https://www.rfc-editor.org/info/rfc5003>. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>. [RFC5331]R.Aggarwal,Y.R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August2008.2008, <https://www.rfc-editor.org/info/rfc5331>. [RFC5332]T.Eckert,E.T., Rosen,Ed.,R.E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, DOI 10.17487/RFC5332, August 2008, <https://www.rfc-editor.org/info/rfc5332>. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, <https://www.rfc-editor.org/info/rfc5561>. [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, DOI 10.17487/RFC5918, August2008.2010, <https://www.rfc-editor.org/info/rfc5918>. [RFC6388]I.Wijnands, IJ., Ed., Minei,K.I., Ed., Kompella,I. Wijnands,K., and B. Thomas, "Label Distribution Protocol Extensions forPoint-to-MultipointPoint- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November2011. [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.2011, <https://www.rfc-editor.org/info/rfc6388>. [RFC6514]R.Aggarwal,E.R., Rosen,T.E., Morin, T., and 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",RFC5561, July 2009. [RFC5918] R. Asati, I. Minei, and B. Thomas, "LDP Typed Wildcard Forwarding Equivalence Class", RFC 5918, August 2010.6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>. [RFC6667]K.Raza,S.K., Boutros, S., and C. Pignataro, "LDPTyped Wildcard FEC'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements", RFC 6667, DOI 10.17487/RFC6667, July2012.2012, <https://www.rfc-editor.org/info/rfc6667>. [RFC7385] Andersson, L. and G. Swallow, "IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points", RFC 7385, DOI 10.17487/RFC7385, October 2014, <https://www.rfc-editor.org/info/rfc7385>. [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <https://www.rfc-editor.org/info/rfc8077>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 8.2. Informative References [RFC3985]StewartBryant,et al., "PWE3S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture",RFC3985RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>. [RFC6074]E. Rosen,W. Luo,B. Davie,V. RadoacaRosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning,Auto- Discovery,Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)",RFC6074,RFC 6074, DOI 10.17487/RFC6074, January2011. [RFC7338] F. Jounay, et. al, "Requirements for Point to Multipoint Pseudowire", RFC7338, September 2014.2011, <https://www.rfc-editor.org/info/rfc6074>. [RFC6425]A.Saxena, S., Ed., Swallow, G., Ali, Z., Farrel,S.A., Yasukawa, S., and T. Nadeau, "DetectingData PlaneData-Plane Failures in Point-to-MultipointMultiprotocol Label Switching (MPLS)-MPLS - Extensions to LSP Ping",RFC6425,RFC 6425, DOI 10.17487/RFC6425, November2011.2011, <https://www.rfc-editor.org/info/rfc6425>. [RFC7338] Jounay, F., Ed., Kamite, Y., Ed., Heron, G., and M. Bocci, "Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks", RFC 7338, DOI 10.17487/RFC7338, September 2014, <https://www.rfc-editor.org/info/rfc7338>. [RFC7358] Raza, K., Boutros, S., Martini, L., and N. Leymann, "Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)", RFC 7358, DOI 10.17487/RFC7358, October 2014, <https://www.rfc-editor.org/info/rfc7358>. Acknowledgments The authors would like thank Andre Pelletier and Parag Jain for their valuable suggestions. Contributors The followingco-authors have alsopeople contributed substantially to the content of thisdocument:document and should be considered coauthors: Luca Martini Cisco Systems, Inc. Email: lmartini@cisco.com Maciek Konstantynowicz Cisco Systems, Inc.e-mail:Email: maciek@cisco.com Gianni Del Vecchio Swisscom Email: Gianni.DelVecchio@swisscom.com Thomas D. Nadeau Brocade Email: tnadeau@lucidvision.com Frederic Jounay Orange CH Email: Frederic.Jounay@salt.ch Philippe Niger Orange CH Email: philippe.niger@orange.com Yuji Kamite NTT Communications Corporation Email: y.kamite@ntt.com Lizhong Jin Email: lizho.jin@gmail.com Martin Vigoureux Nokia Email: martin.vigoureux@nokia.com Laurent Ciavaglia Nokia Email: laurent.ciavaglia@nokia.com Simon Delord TelstraE-mail:Email: simon.delord@gmail.com Kamran Raza Cisco Systems Email: skraza@cisco.com Authors' Addresses Sami BoutrosVMware(editor) VMware, Inc. Email: sboutros@vmware.com Siva Sivabalan (editor) Cisco Systems, Inc. Email: msiva@cisco.com