mLDP Extensions for Multi-Topology Routing
draft-wijnands-mpls-mldp-multi-topology-02

Document Type Active Internet-Draft (individual)
Authors IJsbrand Wijnands  , Syed Raza  , Mankamana Mishra  , Anuj Budhiraja  , Zhaohui Zhang  , Arkadiy Gulko 
Last updated 2021-06-29
Replaces draft-iwijnand-mpls-mldp-multi-topology
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
MPLS Working Group                                          IJ. Wijnands
Internet-Draft                                                Individual
Intended status: Standards Track                                 K. Raza
Expires: December 31, 2021                                     M. Mishra
                                                            A. Budhiraja
                                                     Cisco Systems, Inc.
                                                                Z. Zhang
                                                        Juniper Networks
                                                                A. Gulko
                                          Edward Jones wealth management
                                                           June 29, 2021

               mLDP Extensions for Multi-Topology Routing
               draft-wijnands-mpls-mldp-multi-topology-02

Abstract

   Multi-Topology Routing (MTR) is a technology to enable service
   differentiation within an IP network.  Flexible Algorithm (FA) is
   another mechanism of creating a sub-topology within a topology using
   defined topology constraints and computation algorithm.  In order to
   deploy mLDP in a network that supports MTR and/or FA, mLDP is
   required to become topology and FA aware.  This document specifies
   extensions to mLDP to support MTR with FA such that when building a
   Multi-Point LSPs it can follow a particular topology and algorithm.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on December 31, 2021.

Wijnands, et al.        Expires December 31, 2021               [Page 1]
Internet-Draft             Multi-Topology mLDP                 June 2021

Copyright Notice

   Copyright (c) 2021 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
   (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.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Specification of Requirements . . . . . . . . . . . . . . . .   4
   4.  MT Scoped mLDP FECs . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  MP FEC Extensions for MT  . . . . . . . . . . . . . . . .   4
       4.1.1.  MP FEC Element  . . . . . . . . . . . . . . . . . . .   5
       4.1.2.  MT IP Address Families  . . . . . . . . . . . . . . .   5
       4.1.3.  MT MP FEC Element . . . . . . . . . . . . . . . . . .   6
     4.2.  Topology IDs  . . . . . . . . . . . . . . . . . . . . . .   7
   5.  MT Multipoint Capability  . . . . . . . . . . . . . . . . . .   7
   6.  MT Applicability on FEC-based features  . . . . . . . . . . .   8
     6.1.  Typed Wildcard MP FEC Elements  . . . . . . . . . . . . .   8
     6.2.  End-of-LIB  . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Topology-Scoped Signaling and Forwarding  . . . . . . . . . .  10
     7.1.  Upstream LSR selection  . . . . . . . . . . . . . . . . .  10
     7.2.  Downstream forwarding interface selection . . . . . . . .  10
   8.  LSP Ping Extensions . . . . . . . . . . . . . . . . . . . . .  10
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     12.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Glossary

      MT - Multi-Topology

      MT-ID - Multi-Topology Identifier

Wijnands, et al.        Expires December 31, 2021               [Page 2]
Internet-Draft             Multi-Topology mLDP                 June 2021

      MTR - Multi-Topology Routing

      IGP - Interior Gateway Protocol

      MP - Multipoint (P2MP or MP2MP)

      LDP - Label Distribution Protocol

      mLDP - Multipoint LDP

      P2MP - Point-to-Multipoint

      MP2MP - Multipoint-to-Multipoint

      FEC - Forwarding Equivalence Class

      LSP - Label Switched Path

      FA - Flexible Algorithm

      IPA - IGP Algorithm

2.  Introduction

   Multi-Topology Routing (MTR) is a technology to enable service
   differentiation within an IP network.  IGP protocols (OSPF and IS-IS)
   and LDP have already been extended to support MTR.  To support MTR,
   an IGP maintains independent IP topologies, termed as "Multi-
   Topologies" (MT), and computes/installs routes per topology.  OSPF
   extensions [RFC4915] and ISIS extensions [RFC5120] specify the MT
   extensions under respective IGPs.  To support IGP MT, similar LDP
   extensions [RFC7307] have been specified to make LDP MT-aware and be
   able to setup unicast Label Switched Paths (LSPs) along IGP MT
   routing paths.

   A more light weight mechanism to define constraint-based topologies
   is Flexible Algorithm (FA) [I-D.hegdeppsenak-isis-sr-flex-algo].  FA
   can be seen as creating a sub-topology within a topology using
   defined topology constraints and computation algorithm.  This can be
   done within a MTR topology or just the default Topology.  An instance
   of such a sub-topology is identified by a 1 octet value as documented
   in [I-D.hegdeppsenak-isis-sr-flex-algo]).  Flexible Algorithm is a
   mechanism to create a sub-topology, but in the future different
   algorithms might be defined on how to achieve that.  For that reason,
   in the remainder of this document we'll refer to this as the IGP
   Algorithm (IPA).

Wijnands, et al.        Expires December 31, 2021               [Page 3]
Internet-Draft             Multi-Topology mLDP                 June 2021

   Multipoint LDP (mLDP) refers to extensions in LDP to setup multi-
   point LSPs (point-to-multipoint (P2MP) or multipoint-to-multipoint
   (MP2MP)), by means of set of extensions and procedures defined in
   [RFC6388].  In order to deploy mLDP in a network that supports MTR
   and FA, mLDP is required to become topology and algorithm aware.
   This document specifies extensions to mLDP to support MTR/IPA such
   that when building a Multi-Point LSPs it can follow a particular
   topology and alogirthm.  This means that the identifier for the
   particular Topology to be used by mLDP have to become a two tuple
   (MTR Topology Id, IGP Algorithm).

3.  Specification of Requirements

   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 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS.  Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

4.  MT Scoped mLDP FECs

   As defined in [RFC7307], MPLS Multi-Topology Identifier (MT-ID) is an
   identifier that is used to associate an LSP with a certain MTR
   topology.  In the context of MP LSPs, this identifier is part of the
   mLDP FEC encoding so that LDP peers are able to setup an MP LSP via
   their own defined MTR policy.  In order to avoid conflicting MTR
   policies for the same mLDP FEC, the MT-ID needs to be a part of the
   FEC, so that different MT-ID values will result in unique MP-LSP FEC
   elements.

   The same applies to the IPA.  The IPA needs to be encoded as part of
   the mLDP FEC to create unique MP-LSPs and at the same time is used to
   signal to mLDP (hop-by-hop) which Algorithm needs to be used to
   create the MP-LSP.

   Since the MT-ID and IPA are part of the FEC, they apply to all the
   LDP messages that potentially include an mLDP FEC element.

4.1.  MP FEC Extensions for MT

   Following subsections propose the extensions to bind an mLDP FEC to a
   topology.  The mLDP MT extensions reuse some of the extensions
   specified in [RFC7307].

Wijnands, et al.        Expires December 31, 2021               [Page 4]
Internet-Draft             Multi-Topology mLDP                 June 2021

4.1.1.  MP FEC Element

   Base mLDP specification [RFC6388] defines MP FEC Element 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MP FEC type   |       Address Family          |    AF Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Root Node Address                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Opaque Length              |       Opaque Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 1: MP FEC Element Format [RFC6388]

   Where "Root Node Address" encoding is as defined for given "Address
   Family", and whose length (in octets) is specified by the "AF Length"
   field.

   To extend MP FEC elements for MT, the {MT-ID, IPA} is a tuple that is
   relevant in the context of the root address of the MP LSP.  The {MT-
   ID, IPA} tuple determines in which (sub)-topology the root address
   needs to be resolved.  Since the {MT-ID, IPA} tuple should be
   considered part of the mLDP FEC, the most natural place to encode
   this tuple is as part of the root address.  While encoding it, we
   also propose to use "MT IP" Address Families as described in
   following sub section.

4.1.2.  MT IP Address Families

   [RFC7307] has specified new address families, named "MT IP" and "MT
   IPv6", to allow specification of an IP prefix within a topology
   scope.  In addition to using this address family for mLDP, we also
   use 8 bits of the 16 bits Reserved field to encode the IGP Algorithm
   (IPA) Registry.  The resulting format of the data associated with
   these new Address Families is as follows:

Wijnands, et al.        Expires December 31, 2021               [Page 5]
Internet-Draft             Multi-Topology mLDP                 June 2021

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv4 Address                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |      IPA      |        MT-ID                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv6 Address                              |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |      IPA      |        MT-ID                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 2: Modified MT IP Address Families Data Format

   Where:

      IPv4/IPv6 Address: An IP address corresponding to "MT IP" and "MT
      IPv6" address families respectively.

      IPA: The IGP Algorithm, values are from the IGP Algorithm
      registry.

      Reserved: This 8-bit field MUST be zero.  If a message is received
      that includes a MT address family where the 8 bit Reserved value
      is not zero, the message must be discarded.

4.1.3.  MT MP FEC Element

   By using extended MT IP Address Family, the resultant MT MP FEC
   element is to be encoded as follows:

Wijnands, et al.        Expires December 31, 2021               [Page 6]
Internet-Draft             Multi-Topology mLDP                 June 2021

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MP FEC type   |  AF (MT IP/ MT IPv6)          |    AF Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Root Node Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |      IPA      |        MT-ID                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Opaque Length              |       Opaque Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: IP MT-Scoped MP FEC Element Format

   In the context of this document, the applicable LDP FECs for MT mLDP
   include:

   o  MP FEC Elements:

      *  P2MP (type 0x6)

      *  MP2MP-up (type 0x7)

      *  MP2MP-down (type 0x8)

   o  Typed Wildcard FEC Element (type 0x5)

   In case of "Typed Wildcard FEC Element", the sub FEC Element type
   MUST be one of the MP FECs listed above.

   This specification allows the use of Topology-scoped mLDP FECs in LDP
   label and notification messages, as applicable.

4.2.  Topology IDs

   This document assumes the same definitions and procedures associated
   with MPLS MT-ID as defined in [RFC7307] specification.

5.  MT Multipoint Capability

   "MT Multipoint Capability" is a new LDP capability, defined in
   accordance with LDP Capability definition guidelines [RFC5561], that
   is to be advertised to its peers by an mLDP speaker to announce its
   capability to support MTR and the procedures specified in this
   document.  This capability MAY be sent either in an Initialization

Wijnands, et al.        Expires December 31, 2021               [Page 7]
Internet-Draft             Multi-Topology mLDP                 June 2021

   message at the session establishment time, or in a Capability message
   dynamically during the lifetime of a session (only if "Dynamic
   Announcement" capability [RFC5561] has been successfully negotiated
   with the peer).

   The format of this capability is 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |U|F|  MT Multipoint Cap.(IANA) |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |
      +-+-+-+-+-+-+-+-+

               Figure 4: MT Multipoint Capability TLV Format

   Where:

      U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of
      LDP Capabilities [RFC5561].

      MT Multipoint Capaility: TLV type (IANA assigned).

      Length: The length (in octets) of TLV.  The value of this field
      MUST be 1 as there is no Capability-specific data [RFC5561] that
      follows in the TLV.

      S-bit: Set to 1 to announce and 0 to withdraw the capability (as
      per [RFC5561].

   An mLDP speaker that has successfully advertised and negotiated "MT
   Multipoint" capability MUST support the following:

   1.  Topology-scoped mLDP FECs in LDP messages (Section 4.1)

   2.  Topology-scoped mLDP forwarding setup (Section 7)

6.  MT Applicability on FEC-based features

6.1.  Typed Wildcard MP FEC Elements

   [RFC5918] extends base LDP and defines Typed Wildcard FEC Element
   framework.  Typed Wildcard FEC element can be used in any LDP message
   to specify a wildcard operation for a given type of FEC.

   The MT extensions proposed in document do not require any extension
   in procedures for Typed Wildcard FEC Element support [RFC5918], and

Wijnands, et al.        Expires December 31, 2021               [Page 8]
Internet-Draft             Multi-Topology mLDP                 June 2021

   these procedures apply as-is to Multipoint MT FEC wildcarding.  Like
   Typed Wildcard MT Prefix FEC Element, as defined in [RFC7307], the MT
   extensions allow use of "MT IP" or "MT IPv6" in the Address Family
   field of the Typed Wildcard MP FEC element in order to use wildcard
   operations for MP FECs in the context of a given (sub)-topology as
   identified by the MT-ID and IPA field.

   This document proposes following format and encoding for a Typed
   Wildcard MP FEC element:

       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 (5)| Type = MP FEC |   Len = 6     |  AF = MT IP ..|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |... or MT IPv6 |    Reserved   |      IPA      |     MT-ID     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |MT ID (contd.) |
      +-+-+-+-+-+-+-+-+

                Figure 5: Typed Wildcard MT MP FEC Element

   Where:

      Type: One of MP FEC Element type (P2MP, MP2MPup, MP2MP-down).

      MT ID: MPLS MT ID

      IPA: The IGP Algorithm, values are from the IGP Algorithm
      registry.

   The proposed format allows an LSR to perform wildcard MP FEC
   operations under the scope of a (sub-)topology.

6.2.  End-of-LIB

   [RFC5919] specifies extensions and procedures that allows an LDP
   speaker to signal its End-of-LIB (i.e. convergence) for a given FEC
   type towards a peer.  MT extensions for MP FEC do not require any
   change in these procedures and they apply as-is to MT MP FEC
   elements.  This means that an MT mLDP speaker MAY signal its
   convergence per (sub-)topology using MT Typed Wildcard MP FEC
   element.

Wijnands, et al.        Expires December 31, 2021               [Page 9]
Internet-Draft             Multi-Topology mLDP                 June 2021

7.  Topology-Scoped Signaling and Forwarding

   Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need
   to support the concept of multiple (sub-)topology forwarding tables
   in mLDP.  Each MP LSP will be unique due to the tuple being part of
   the FEC.  There is also no need to have specific label forwarding
   tables per topology, and each MP LSP will have its own unique local
   label in the table.  However, In order to implement MTR in an mLDP
   network, the selection procedures for upstream LSR and downstream
   forwarding interface need be changed.

7.1.  Upstream LSR selection

   The procedures as described in RFC-6388 section-2.4.1.1 depend on the
   best path to reach the root.  When the {MT-ID, IPA} tuple is signaled
   as part of the FEC, this tuple is used to select the (sub-)topology
   that must be used to find the best path to the root address.  Using
   the next-hop from this best path, a LDP peer is selected following
   the procedures as defined in [RFC6388].

7.2.  Downstream forwarding interface selection

   The procedures as described in RFC-6388 section-2.4.1.2 describe how
   a downstream forwarding interface is selected.  In these procedures,
   any interface leading to the downstream LDP neighbor can be
   considered as candidate forwarding interface.  When the {MT-ID, IPA}
   tuple is part of the FEC, this is no longer true.  An interface must
   only be selected if it is part of the same (sub-)topology that was
   signaled in the mLDP FEC element.  Besides this restriction, the
   other procedures in [RFC6388] apply.

8.  LSP Ping Extensions

   [RFC6425] defines procedures to detect data plane failures in
   Multipoint MPLS LSPs.  Section 3.1.2 of [RFC6425] defines new Sub-
   Types and Sub-TLVs for Multipoint LDP FECs to be sent in "Target FEC
   Stack" TLV of an MPLS echo request message [RFC4379].

   To support LSP ping for MT Multipoint LSPs, this document uses
   existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack"
   defined in [RFC6425].  The proposed extension is to specify "MT IP"
   or "MT IPv6" in the "Address Family" field, set the "Address Length"
   field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV
   with additional {MT-ID, IPA} information as an extension to the "Root
   LSR Address" field.  The resultant format of sub-tlv is as follows:

Wijnands, et al.        Expires December 31, 2021              [Page 10]
Internet-Draft             Multi-Topology mLDP                 June 2021

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Address Family (MT IP/MT IPv6) | Address Length|               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      ~                   Root LSR Address (Cont.)                    ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |      IPA      |        MT-ID                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Opaque Length          |         Opaque Value ...      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      ~                                                               ~
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 6: Multipoint LDP FEC Stack Sub-TLV Format for MT

   The rules and procedures of using this new sub-TLV in an MPLS echo
   request message are same as defined for P2MP/MP2MP LDP FEC Stack Sub-
   TLV in [RFC6425] with only difference being that Root LSR address is
   now (sub-)topology scoped.

9.  Security Considerations

   This extension to mLDP does not introduce any new security
   considerations beyond that already apply to the base LDP
   specification [RFC5036], base mLDP specification [RFC6388], and MPLS
   security framework [RFC5920].

10.  IANA Considerations

   This document defines a new LDP capability parameter TLV.  IANA is
   requested to assign the lowest available value after 0x0500 from "TLV
   Type Name Space" in the "Label Distribution Protocol (LDP)
   Parameters" registry within "Label Distribution Protocol (LDP) Name
   Spaces" as the new code point for the LDP TLV code point.

Wijnands, et al.        Expires December 31, 2021              [Page 11]
Internet-Draft             Multi-Topology mLDP                 June 2021

    +-----+------------------+---------------+-------------------------+
    |Value| Description      | Reference     | Notes/Registration Date |
    +-----+------------------+---------------+-------------------------+
    | TBA | MT Multipoint    | This document |                         |
    |     | Capability       |               |                         |
    +-----+------------------+---------------+-------------------------+

                         Figure 7: IANA Code Point

11.  Acknowledgments

   The authors would like to acknowledge Eric Rosen for his input on
   this specification.

12.  References

12.1.  Normative References

   [I-D.hegdeppsenak-isis-sr-flex-algo]
              Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS
              Segment Routing Flexible Algorithm", draft-hegdeppsenak-
              isis-sr-flex-algo-02 (work in progress), February 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              DOI 10.17487/RFC4379, February 2006,
              <https://www.rfc-editor.org/info/rfc4379>.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, DOI 10.17487/RFC4915, June 2007,
              <https://www.rfc-editor.org/info/rfc4915>.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.

Wijnands, et al.        Expires December 31, 2021              [Page 12]
Internet-Draft             Multi-Topology mLDP                 June 2021

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

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

   [RFC7307]  Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
              King, "LDP Extensions for Multi-Topology", RFC 7307,
              DOI 10.17487/RFC7307, July 2014,
              <https://www.rfc-editor.org/info/rfc7307>.

12.2.  Informative References

   [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>.

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

   [RFC5919]  Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
              "Signaling LDP Label Advertisement Completion", RFC 5919,
              DOI 10.17487/RFC5919, August 2010,
              <https://www.rfc-editor.org/info/rfc5919>.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
              <https://www.rfc-editor.org/info/rfc5920>.

Authors' Addresses

   IJsbrand Wijnands
   Individual

   Email:  ice@braindump.be

Wijnands, et al.        Expires December 31, 2021              [Page 13]
Internet-Draft             Multi-Topology mLDP                 June 2021

   Kamran Raza
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, ON  K2K-3E8
   Canada

   Email: skraza@cisco.com

   Mankamana Mishra
   Cisco Systems, Inc.
   821 Alder Drive
   Milpitas, CA  95035
   USA

   Email: mankamis@cisco.com

   Anuj Budhiraja
   Cisco Systems, Inc.
   821 Alder Drive
   Milpitas, CA  95035
   USA

   Email: abudhira@cisco.com

   Zhaohui Zhang
   Juniper Networks
   10 Technology Park Dr.
   Westford  MA  01886
   US

   Email: zzhang@juniper.net

   Arkadiy Gulko
   Edward Jones wealth management
   USA

   Email: Arkadiy.gulko@edwardjones.com

Wijnands, et al.        Expires December 31, 2021              [Page 14]