INTERNET-DRAFT                                         Sami Boutros(Ed.)
Intended Status: Standard Track                                   VMware
Internet 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 Systems

Expires: May 16,
ISSN: 2070-1721                                            February 2018                                  November 12, 2017

   Signaling Root-Initiated Point-to-Multipoint Pseudowire using Using LDP
                     draft-ietf-pals-p2mp-pw-04.txt

Abstract

   This document specifies a mechanism to signal Point-to-Multipoint
   (P2MP) Pseudowires Pseudowire (PW) tree trees using LDP.  Such a mechanism is suitable
   for any Layer 2 VPN service requiring P2MP connectivity over an IP or
   MPLS enabled
   MPLS-enabled PSN.  A P2MP PW established via the proposed mechanism
   is root initiated.  This document updates RFC7385 RFC 7385 by re-assigning reassigning the
   reserved value 0xFF to be the wildcard transport tunnel type.

Status of this 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 an 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 of six months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other documents at any
   time.  It the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work available in progress."

   The list Section 2 of RFC 7841.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html
   https://www.rfc-editor.org/info/rfc8338.

Copyright and License Notice

   Copyright (c) 2017 2018 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 Contents

   1

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1  Terminology
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
   2.
   3.  Signaling P2MP PW . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1
     3.1.  PW ingress to egress incompatibility issues  . Ingress-to-Egress Incompatibility Issues . . . . . . .   6
     2.2
     3.2.  P2MP PW FEC . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.2.1
       3.2.1.  P2MP PW Upstream FEC Element  . . . . . . . . . . . . . .   6
       2.2.2
       3.2.2.  P2P PW Downstream FEC Element . . . . . . . . . . . . .  10
     2.3
     3.3.  Typed Wildcard FEC Format for new a New FEC . . . . . . . . . . . 10
     2.4  11
     3.4.  Group ID usage . . Usage  . . . . . . . . . . . . . . . . . . . . .  11
     2.5
     3.5.  Generic Label TLV . . . . . . . . . . . . . . . . . . . . .  11
   3.
   4.  LDP Capability Negotiation  . . . . . . . . . . . . . . . . . .  12
   4.
   5.  P2MP PW Status  . . . . . . . . . . . . . . . . . . . . . . . .  13
   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 13
   6 Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . .  13
   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  FEC Type Name Space . . . . . . . . . . . . . . . . . . . .  14
     7.2.  LDP TLV Type  . . . . . . . . . . . . . . . . . . . . . . .  14
     7.3.  mLDP Opaque Value Element TLV Type  . . . . . . . . . . . .  14
     7.4.  Selective Tree Interface Parameter sub-TLV Sub-TLV Type . . . . . .  14
     7.5. WildCard  Wildcard PMSI tunnel type . Tunnel Type . . . . . . . . . . . . . . . .  15
   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 16
   Contributors  17
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Contributors  . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  17

1  Introduction

   A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential
   attributes of a unidirectional P2MP Telecommunications
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  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
   both unidirectional, and optionally unidirectional and, optionally, bidirectional service.
   Requirements for P2MP PW PWs are described in [RFC7338].  P2MP PW PWs can
   be constructed as either Single Segment Pseudowires (P2MP SS-PW) SS-PWs) or Multi 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 Figure 1 below. 1.  A transport LSP Label Switched
   Path (LSP) associated with a P2MP SS-PW SHOULD be a P2MP MPLS LSP
   (i.e., P2MP TE Traffic Engineering (TE) tunnel established via RSVP-TE
   [RFC4875] or P2MP LSP established via mLDP Multipoint LDP (mLDP)
   [RFC6388]) spanning from the Root-PE Root PE (Provider Edge) to the Leaf-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, PE3 PE3, 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 document specify specifies a method of signaling P2MP PW
   using LDP.  In particular, this document defines a new FEC, Forwarding
   Equivalence Class (FEC), TLVs, parameters, and status codes to
   facilitate LDP to signal signaling and maintain maintaining P2MP PWs.

   As outlined in [RFC7338], even though the traffic flow from a Root-PE Root PE
   (R-PE) to Leaf-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.1

2.  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 in RFC 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 Protocol for (for P2MP/MP2MP LSP

   LSP: Label Switching Path LSP)

   MS-PW:  Multi-Segment Pseudowire

   P2P: Point to Point

   P2MP: Point to Multipoint   Point-to-Multipoint

   P2P:    Point-to-Point

   PE:     Provider Edge

   PSN:    Packet Switched Network

   PW:     Pseudowire

   SS-PW: Single-Segment Pseudowire

   R-PE:   Root PE (ingress PE, PE initiating P2MP PW setup)

   S-PE:   Switching Provider Edge of MS-PW (of MS-PW)

   SS-PW:  Single-Segment Pseudowire

   TE:     Traffic Engineering

   R-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 exchange PW related PW-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
   in the following section.

   P2MP PW requires that there is be 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, a Leaf-PE Leaf 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, add add, or
   prune existing or new L-PE(s) L-PEs from the tree.  In any case, the PW setup
   can ignore these differences, differences and simply assume that the P2MP PSN LSP
   is available when needed.

   P2MP PW signaling is initiated by the R-PE R-PE, which sends a separate
   P2MP-PW
   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 a P2MP PW Upstream FEC element Element that includes
       a Transport LSP sub TLV. sub-TLV.

   2.  An Interface Parameters TLV, as described in [RFC4447bis]. [RFC8077].

   3.  A PW Grouping Group 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 the P2MP-PW, and P2MP PW; using this label label, an L-PE identifies
   the inbound packets arriving over the P2MP PW.

   Additionally, the R-PE MAY send label mapping message(s) messages to one or more L-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 optional label mapping
   message will contain the following:

   1.  A P2P PW Downstream FEC element. Element

   2.  A label TLV for the down-stream assigned downstream-assigned label used by the
       corresponding L-PE to send traffic to the R-PE. R-PE

   The LDP liberal label retention mode MUST be used, and used; 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 in place, 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, 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

3.1.  PW ingress to egress incompatibility issues Ingress-to-Egress Incompatibility Issues

   If an R-PE signals a PW with a pw type, CW PW Type, Control Word (CW) mode, or
   interface parameters that a particular L-PE cannot accept, then the
   L-PE MUST
   not NOT enable the PW, 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-PE had was not been
   provisioned with this particular P2MP PW.  In this case case, according to
   the LDP liberal label retention rules, no action is taken.

2.2

3.2.  P2MP PW FEC

   [RFC4447bis]

   [RFC8077] specifies two types of LDP FEC elements called used to signal P2P
   PWs: "PWid FEC Element" and "Generalized PWid FEC Element" used to signal P2P PWs. Element".  This
   document defines uses two new types of FEC elements called elements: "P2MP PW Upstream FEC Element" and
   "P2P PW Downstream FEC Element".  These FEC elements are associated
   with a mandatory upstream assigned upstream-assigned label and an optional downstream downstream-
   assigned label label, respectively.

2.2.1

3.2.1.  P2MP PW Upstream FEC Element

   A new

   The 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   |     Length    |         AGI Value             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       AGI Value (contd.)                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    AII Type   |     Length    |         SAII Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       SAII Value (contd.)                     ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |PMSI Tunnel typ| Typ|     Length    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      +                                                               +
      ~                   Transport LSP ID                            ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Optional Parameters                     |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: P2MP PW Upstream FEC Element

   *  P2MP PW Up:

   8 bits

      8-bit representation for the P2MP PW Upstream FEC type.

   *  PW Type:

   15 bits

      15-bit representation of PW type Type as specified in [RFC4447bis]. [RFC8077].

   *  C bit:

      A value of 1 or 0 indicates indicating whether a 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 group 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 in section 3.3, Section 2.3, can be used to
      achieve the same or to have better filtering.

   *  AGI:

      An Attachment Group Identifier can be used to uniquely identify a
      VPN or
   VPLS Virtual Private LAN Service (VPLS) instance associated with
      the P2MP PW.  This has the same format as the Generalized PWid FEC element [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 AII type Type 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 Tunnel info Info:

      The PMSI Tunnel info Info is the combination of the PMSI Tunnel Type, Length
      Length, and Transport LSP ID. ID fields.

      A P2MP PW MUST be associated with a transport LSP LSP, which can be
      established using RSVP-TE or mLDP.

   *  PMSI Tunnel Type:

      The PMSI tunnel type 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  The new mLDP Opaque
      Value Element type for the L2VPN-MCAST application as TLV (as
      specified in the IANA
   considerations Considerations section (Section 7)) MUST be
      used.

   *  Transport LSP ID:

      This is the Tunnel Identifier which that 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 P2MP PWs PW; in which case case, P2MP PWs will be sharing the same R-PE
      and L-
   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
      Parameters TLV, 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 by a an 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 interface parameters parameters, like CEP/TDM
      Payload bytes (TDM), Bytes, the value MUST exactly match the values signaled by
      the R-PE.

   Multicast

      A 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 IANA considerations Considerations 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 multicast tree
      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. sub-TLV.  Furthermore,
      in the absence of this sub-TLV, the P2MP PW is associated with all
      multicast traffic stream streams 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 LDP label mapping message is only sent by the R-
   PE
      R-PE to all the L-PEs, it is not possible to negotiate any
      interface parameters.

2.2.2

3.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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |P2P PWDown=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 FEC Element Element, shown in Figure 2.

2.3

3.3.  Typed Wildcard FEC Format for new a New FEC

   [RFC5918] defines the general notion of a "Typed Wildcard" Typed Wildcard FEC
   Element, and Element;
   it requires FEC designer designers to specify a typed wildcard Typed Wildcard FEC
   element Element for
   newly defined FEC element types.  This document defines uses two new FEC elements,
   elements: "P2MP PW Upstream" and "P2P PW Downstream" FEC
   element, and hence requires us to define Downstream".  Hence,
   definition of their Typed Wildcard format. format is required.

   [RFC6667] defines the Typed Wildcard FEC element Element format for other PW
   FEC Element types (PWid and Gen. Generalized PWid FEC Element) in section 2
   Section 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|   PW type Type   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    . . .      | 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) FEC element Element type.  This document
   reuses the existing typed wildcard Typed Wildcard format as specified in [RFC6667] and
   illustrated in Figure 5 and extends the definition of "Type" the Type field
   to also include "P2MP the P2MP PW Upstream" Upstream FEC Element and "P2P P2P PW Downstream"
   Downstream FEC element Element types.  This document adds an additional field
   called the "PMSI Tun Tunnel Type".  This document reserves PMSI tunnel Tunnel
   Type 0xFF to mean "wildcard" "wildcard transport tunnel type. type".  The PMSI tunnel Tunnel
   Type field only applies to the Typed
   wildcard Wildcard P2MP PW Upstream FEC
   Element and MUST be set to "wildcard" for "P2P PW Downstream FEC" FEC
   Element" typed wildcard element.

2.4 wildcard.

3.4.  Group ID usage Usage

   The Grouping PW Group ID TLV as defined in [RFC4447bis] [RFC8077] contains a group ID
   capable of indicating an arbitrary group membership of a P2MP-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 single upstream-
   assigned
   upstream-assigned label is allocated by the R-PE, R-PE and is advertised to
   all L-
   PEs L-PEs using the Generic Label TLV in label mapping message messages
   containing the P2MP PW Upstream FEC element. 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
   L-PE using the Generic Label TLV and P2P PW Downstream FEC Element in
   label mapping
   message.

3. messages.

4.  LDP Capability Negotiation

   The capability of supporting P2MP PW PWs MUST be advertised to all LDP
   peers.  This is achieved by using the methods in [RFC5561] to
   advertise the LDP "P2MP P2MP PW Capability" 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 Capability
   TLV.  If the peer does not supports support dynamic capability advertisement,
   then the P2MP PW Capability TLV MUST be included in the LDP
   Initialization message during the session establishment. An LSR  A 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   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 7: 6: LDP P2MP PW Capability TLV

   * U-bit:  U bit:

      SHOULD be 1 (ignore if not understood).

   * F-bit:  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  Note that
      the P2MP PW
   capability code point is requested Capability Code Point appears in the IANA allocation
      Considerations section
   below. (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 the P2MP
            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 negotiation procedure procedures
   described in [RFC4447bis] is [RFC8077] are not applicable to P2MP PW.  An LSR MUST
   NOT claim to be P2MP PW capable by sending a an 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 (for example example, if the P2MP PW is established and operational with
   a status code of Success (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
   associated with, with can be verified using LSP Ping ping and Traceroute traceroute
   procedures described in [RFC6425].

5

6.  Security Considerations

   In general general, the security measures described in [RFC4447bis] [RFC8077] are adequate
   for this protocol. However  However, 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 simple hash
   based
   hash-based authentication algorithm.

6 Acknowledgment

   Authors would like thank Andre Pelletier and Parag Jain for their
   valuable suggestions.

7

7.  IANA Considerations

7.1.  FEC Type Name Space

   This document uses two new FEC element types, number 0x82 and 0x83
   are suggested for assignment from 0x84, in the registry "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 Element       RFCxxxx
       131     0x83    [RFC8338] [RFC7358]
    132    0x84   P2P PW Downstream FEC Element      RFCxxxx   [RFC8338] [RFC7358]

7.2.  LDP TLV Type

   This document uses defines a new LDP TLV types, IANA already maintains a
   registry of name type in the "TLV TYPE NAME SPACE" defined by RFC5036. The Type Name Space"
   registry [RFC5036].  IANA has assigned the the following values are suggested for assignment: value:

   TLV type  Description: Type  Description
   --------  ----------------------
   0x0703    P2MP PW Capability TLV

7.3.  mLDP Opaque Value Element TLV Type

   This document requires allocation of

   IANA has assigned a new mLDP Opaque Value Element Type from in the "LDP MP
   Opaque Value Element basic type" name space defined
   in [RFC6388].

   The following value is suggested for assignment: registry [RFC6388] as follows:

           TLV type Type  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 Parameter sub-TLV Sub-TLV Type

   This document requires allocation of

   IANA has assigned a sub-TLV from the registry "Pseudowire Interface Parameters
   Sub-TLV Type" defined in [RFC4446].

   The following value is suggested for assignment:

         TLV type Registry" [RFC4446] as follows:

           TLV Type  Description
         0x1b
           --------  ----------------------------------
           0x1B      Selective Tree Interface Parameter. Parameter

7.5. WildCard  Wildcard PMSI tunnel type

   This document requests that Tunnel Type

   IANA modify the following has modified an entry in the "P-Multicast Service Interface
   Tunnel (PMSI Tunnel) Tunnel Types" registry within the "Border
   Gateway Protocol (BGP) Parameters"
   namespace registry [RFC7385].  Value 0xFF,
   which was previously assigned by RFC7385 marked as "Reserved", has been been updated as "reserved".
   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]
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8077]  Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
              Maintenance using Using the Label Distribution Protocol", Martini, L., et al., draft-ietf-pals-
   rfc4447bis-05.txt, July 2016. Protocol (LDP)",
              STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
              <https://www.rfc-editor.org/info/rfc8077>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007. 2007, <https://www.rfc-editor.org/info/rfc5036>.

   [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, September 2007.
              2007, <https://www.rfc-editor.org/info/rfc5003>.

   [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, August 2008. 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. 2008,
              <https://www.rfc-editor.org/info/rfc5332>.

   [RFC6388] I.  Wijnands, IJ., Ed., Minei, K. I., Ed., Kompella, I. Wijnands, K., and B.
              Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint Point-
              to-Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, DOI 10.17487/RFC6388, November
   2011. 2011,
              <https://www.rfc-editor.org/info/rfc6388>.

   [RFC4875] R.  Aggarwal, R., Ed., D. Papadimitriou, D., Ed., and S.
              Yasukawa, Ed., "Extensions to Resource Reservation
              Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint Point-to-
              Multipoint TE Label Switched Paths (LSPs).", (LSPs)", RFC 4875,
              DOI 10.17487/RFC4875, May 2007. 2007,
              <https://www.rfc-editor.org/info/rfc4875>.

   [RFC4446]  Martini, L., "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>.

   [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, RFC 6514, DOI 10.17487/RFC6514, February
   2012. 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

   [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal,  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561,
              DOI 10.17487/RFC5561, July 2009. 2009,
              <https://www.rfc-editor.org/info/rfc5561>.

   [RFC5918] R.  Asati, I. R., Minei, I., and B. Thomas, "LDP Typed Wildcard
   Forwarding "Label Distribution
              Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class", Class
              (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010. 2010,
              <https://www.rfc-editor.org/info/rfc5918>.

   [RFC6667] K.  Raza, S. K., Boutros, S., and C. Pignataro, "LDP Typed Wildcard
   FEC 'Typed
              Wildcard' Forwarding Equivalence Class (FEC) for PWid and
              Generalized PWid FEC Elements", RFC 6667,
              DOI 10.17487/RFC6667, July 2012. 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>.

   [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] Stewart  Bryant, et al., "PWE3 S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
              Edge-to-Edge (PWE3) Architecture", RFC3985 RFC 3985,
              DOI 10.17487/RFC3985, March 2005,
              <https://www.rfc-editor.org/info/rfc3985>.

   [RFC6074] E. Rosen,W. Luo,B. Davie,V. Radoaca  Rosen, 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, January 2011. 2011,
              <https://www.rfc-editor.org/info/rfc6074>.

   [RFC7338]   F.  Jounay, et. al, F., Ed., Kamite, Y., Ed., Heron, G., and M. Bocci,
              "Requirements and Framework for Point to Multipoint
   Pseudowire", RFC7338, Point-to-Multipoint
              Pseudowires over MPLS Packet Switched Networks", RFC 7338,
              DOI 10.17487/RFC7338, September 2014. 2014,
              <https://www.rfc-editor.org/info/rfc7338>.

   [RFC6425] A.  Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, S. A.,
              Yasukawa, S., and T. Nadeau, "Detecting Data Plane Data-Plane
              Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS)- MPLS - Extensions to LSP
              Ping", RFC6425, RFC 6425, DOI 10.17487/RFC6425, November 2011. 2011,
              <https://www.rfc-editor.org/info/rfc6425>.

Acknowledgments

   The authors would like thank Andre Pelletier and Parag Jain for their
   valuable suggestions.

Contributors

      The following co-authors have also people contributed substantially to the content of
      this document: 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
      Telstra
      E-mail:

      Email: simon.delord@gmail.com

      Kamran Raza
      Cisco Systems

      Email: skraza@cisco.com

Authors' Addresses

   Sami Boutros
      VMware (editor)
   VMware, Inc.

   Email: sboutros@vmware.com

   Siva Sivabalan (editor)
   Cisco Systems, Inc.

   Email: msiva@cisco.com