mLDP Extensions for Multi-Topology Routing
draft-ietf-mpls-mldp-multi-topology-05

MPLS Working Group                                          IJ. Wijnands
Internet-Draft                                                Individual
Intended status: Standards Track                      M. Mishra (Editor)
Expires: 20 October 2024                                         K. Raza
                                                     Cisco Systems, Inc.
                                                                Z. Zhang
                                                        Juniper Networks
                                                                A. Gulko
                                          Edward Jones wealth management
                                                           18 April 2024

               mLDP Extensions for Multi-Topology Routing
                 draft-ietf-mpls-mldp-multi-topology-05

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 (Multipoint label distribution protocol) 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 Multipoint LSPs(Label Switched
   Paths) 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 20 October 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Wijnands, et al.         Expires 20 October 2024                [Page 1]
Internet-Draft             Multi-Topology mLDP                April 2024

   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised 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  . . . . . . . . . . . . . . . . . . .   4
       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  . . . . . . . . . . . . . . . . . .   8
   6.  MT Applicability on FEC-based features  . . . . . . . . . . .   9
     6.1.  Typed Wildcard MP FEC Elements  . . . . . . . . . . . . .   9
     6.2.  End-of-LIB  . . . . . . . . . . . . . . . . . . . . . . .  10
   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.  Implementation Status . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Cisco Systems . . . . . . . . . . . . . . . . . . . . . .  12
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   12. Contributor . . . . . . . . . . . . . . . . . . . . . . . . .  13
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     14.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Glossary

      MT - Multi-Topology

      MT-ID - Multi-Topology Identifier

      MTR - Multi-Topology Routing

      IGP - Interior Gateway Protocol

Wijnands, et al.         Expires 20 October 2024                [Page 2]
Internet-Draft             Multi-Topology mLDP                April 2024

      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 the Flexible Algorithm (FA) [RFC9350].  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
   the default Topology.  An instance of such a sub-topology is
   identified by a 1 octet value as documented in [RFC9350]).  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).

   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

Wijnands, et al.         Expires 20 October 2024                [Page 3]
Internet-Draft             Multi-Topology mLDP                April 2024

   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 2-tuple (MTR
   Topology Id, IGP Algorithm).

3.  Specification of Requirements

   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 BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

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

4.1.1.  MP FEC Element

   Base mLDP specification [RFC6388] defines MP FEC Element as follows:

Wijnands, et al.         Expires 20 October 2024                [Page 4]
Internet-Draft             Multi-Topology mLDP                April 2024

       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 20 October 2024                [Page 5]
Internet-Draft             Multi-Topology mLDP                April 2024

       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 on transmission and
      ignored on receipt.

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 20 October 2024                [Page 6]
Internet-Draft             Multi-Topology mLDP                April 2024

      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:

   *  MP FEC Elements:

      -  P2MP (type 0x6)

      -  MP2MP-up (type 0x7)

      -  MP2MP-down (type 0x8)

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

   [RFC6514] defines the PMSI tunnel attribute for MVPN.  When the
   Tunnel Type is set to mLDP P2MP LSP, the Tunnel Identifier is a P2MP
   FEC Element.  When the Tunnel Type is set to mLDP Multipoint-to-
   Multipoint (MP2MP) LSP, the Tunnel Identifier is an MP2MP FEC
   Element.  For deploying mLDP in a network that supports MTR and FA,
   New MT MP FEC element SHOULD be used as the Tunnel Identifier.

4.2.  Topology IDs

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

Wijnands, et al.         Expires 20 October 2024                [Page 7]
Internet-Draft             Multi-Topology mLDP                April 2024

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
   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)

Wijnands, et al.         Expires 20 October 2024                [Page 8]
Internet-Draft             Multi-Topology mLDP                April 2024

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

Wijnands, et al.         Expires 20 October 2024                [Page 9]
Internet-Draft             Multi-Topology mLDP                April 2024

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.

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 to 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 [RFC8029].

Wijnands, et al.         Expires 20 October 2024               [Page 10]
Internet-Draft             Multi-Topology mLDP                April 2024

   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:

      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.  Implementation Status

   [Note to the RFC Editor - remove this section before publication, as
   well as remove the reference to [RFC7942]

Wijnands, et al.         Expires 20 October 2024               [Page 11]
Internet-Draft             Multi-Topology mLDP                April 2024

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942] .
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC7942] , "this will allow reviewers and working
   groups to assign due consideration to documents that have the benefit
   of running code, which may serve as evidence of valuable
   experimentation and feedback that have made the implemented protocols
   more mature.  It is up to the individual working groups to use this
   information as they see fit".

9.1.  Cisco Systems

   The feature has been implemented on IOS-XR.

   *  Organization: Cisco Systems

   *  Implementation: Cisco systems IOS-XR has an implementation

   *  Description: The implementation has been done.

   *  Maturity Level: Product

   *  Contact: mankamis@cisco.com

10.  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].

11.  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 20 October 2024               [Page 12]
Internet-Draft             Multi-Topology mLDP                April 2024

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

                       Figure 7: IANA Code Point

12.  Contributor

   Anuj Budhiraja Cisco systems

13.  Acknowledgments

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

14.  References

14.1.  Normative References

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

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

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

Wijnands, et al.         Expires 20 October 2024               [Page 13]
Internet-Draft             Multi-Topology mLDP                April 2024

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

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

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

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
              Switched (MPLS) Data-Plane Failures", RFC 8029,
              DOI 10.17487/RFC8029, March 2017,
              <https://www.rfc-editor.org/info/rfc8029>.

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

   [RFC9350]  Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
              and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
              DOI 10.17487/RFC9350, February 2023,
              <https://www.rfc-editor.org/info/rfc9350>.

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

Wijnands, et al.         Expires 20 October 2024               [Page 14]
Internet-Draft             Multi-Topology mLDP                April 2024

   [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

   Mankamana Mishra
   Cisco Systems, Inc.
   821 Alder Drive
   Milpitas, CA 95035
   United States of America
   Email: mankamis@cisco.com

   Kamran Raza
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata ON K2K-3E8
   Canada
   Email: skraza@cisco.com

   Zhaohui Zhang
   Juniper Networks
   10 Technology Park Dr.
   Westford,  MA 01886
   United States of America
   Email: zzhang@juniper.net

   Arkadiy Gulko
   Edward Jones wealth management
   United States of America

Wijnands, et al.         Expires 20 October 2024               [Page 15]
Internet-Draft             Multi-Topology mLDP                April 2024

   Email: Arkadiy.gulko@edwardjones.com

Wijnands, et al.         Expires 20 October 2024               [Page 16]