MPLS Working Group

Internet Engineering Task Force (IETF)                      IJ. Wijnands
Internet-Draft
Request for Comments: 9658                                    Individual
Updates: 7307 (if approved)                                             M. Mishra (Editor)
Intended status: Mishra, Ed.
Category: Standards Track                                        K. Raza
Expires: 21 November 2024
ISSN: 2070-1721                                      Cisco Systems, Inc.
                                                                Z. Zhang
                                                        Juniper Networks
                                                                A. Gulko
                                                            Edward Jones wealth management
                                                             20 May
                                                          September 2024

               mLDP

          Multipoint LDP Extensions for Multi-Topology Routing
                 draft-ietf-mpls-mldp-multi-topology-09

Abstract

   Multi-Topology Routing (MTR) is a technology to enable that enables service
   differentiation within an IP network.  Flexible Algorithm (FA) is
   another mechanism of for creating a sub-topology within a topology using
   defined topology constraints and computation algorithm. algorithms.  In order to
   deploy mLDP (Multipoint label distribution protocol) Multipoint LDP (mLDP) in a network that supports MTR, FA, or
   other methods of signaling non-default IGP
   algorithms, Algorithms (IPAs), mLDP is
   required to become topology and algorithm aware.  This document
   specifies extensions to mLDP to support MTR, with an algorithm, in
   order for Multipoint LSPs(Label multipoint LSPs (Label Switched Paths) to follow a
   particular topology and algorithm.  It updates [RFC7307] RFC 7307 by allocating
   eight bits from a previously reserved field to be used as the IGP Algorithm (IPA) IPA
   field.

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 an Internet Standards Track document.

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

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 21 November 2024.
   https://www.rfc-editor.org/info/rfc9658.

Copyright Notice

   Copyright (c) 2024 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)
   (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.
   2.  Terminology
     2.1.  Abbreviations
     2.2.  Specification of Requirements . . . . . . . . . . . . . . . .   4
   4.  MT Scoped
   3.  MT-Scoped mLDP FECs . . . . . . . . . . . . . . . . . . . . .   4
     4.1.
     3.1.  MP FEC Extensions for MT  . . . . . . . . . . . . . . . .   5
       4.1.1.
       3.1.1.  MP FEC Element  . . . . . . . . . . . . . . . . . . .   5
       4.1.2.
       3.1.2.  MT IP Address Families  . . . . . . . . . . . . . . .   6
       4.1.3.
       3.1.3.  MT MP FEC Element . . . . . . . . . . . . . . . . . .   6
     4.2.
     3.2.  Topology IDs  . . . . . . . . . . . . . . . . . . . . . .   7
   5.
   4.  MT Multipoint Capability  . . . . . . . . . . . . . . . . . .   8
   6.
   5.  MT Applicability on FEC-based features  . . . . . . . . . . .   9
     6.1. FEC-Based Features
     5.1.  Typed Wildcard MP FEC Elements  . . . . . . . . . . . . .   9
     6.2.
     5.2.  End-of-LIB  . . . . . . . . . . . . . . . . . . . . . . .  10
   7.
   6.  Topology-Scoped Signaling and Forwarding  . . . . . . . . . .  10
     7.1.
     6.1.  Upstream LSR selection  . . . . . . . . . . . . . . . . .  10
     7.2. Selection
     6.2.  Downstream forwarding interface selection . . . . . . . .  10
   8. Forwarding Interface Selection
   7.  LSP Ping Extensions . . . . . . . . . . . . . . . . . . . . .  11
   9.  Implementation Status . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Cisco Systems . . . . . . . . . . . . . . . . . . . . . .  12
   10.
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   11.
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   12. Contributor . . . . . . . . . . . . . . . . . . . . . . . . .  13
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   14.
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     14.1.
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     14.2.
     10.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Contributors
   Acknowledgments
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Glossary

      FA - Flexible Algorithm
      FEC - Forwarding Equivalence Class

      IGP - Interior Gateway Protocol

      IPA - IGP Algorithm

      LDP - Label Distribution Protocol

      LSP - Label Switched Path

      mLDP - Multipoint LDP

      MP - Multipoint (P2MP or MP2MP)

      MP2MP - Multipoint-to-Multipoint

      MT - Multi-Topology

      MT-ID - Multi-Topology Identifier

      MTR - Multi-Topology Routing

      MVPN - Multicast over Virtual Private Network defined in section
      2.3 of [RFC6513]

      P2MP - Point-to-Multipoint

      PMSI - Provider Multicast Service Interfaces [RFC6513]

2.  Introduction

   Multi-Topology Routing (MTR) is a technology to enable that enables 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), called "Multi-Topologies"
   (or "MTs"), and computes/installs routes per topology.  OSPF
   extensions [RFC4915] (see [RFC4915]) and IS-IS extensions [RFC5120] (see [RFC5120])
   specify the MT extensions under respective IGPs.  To support IGP MT,
   similar LDP extensions [RFC7307] (see [RFC7307]) have been specified to make
   LDP MT-aware be MT aware and to be able to setup set up unicast Label Switched Paths
   (LSPs) along IGP MT routing paths.

   A more lightweight mechanism to define constraint-based topologies is
   the Flexible Algorithm (FA) [RFC9350]. (see [RFC9350]).  The FA can be seen as
   creating a sub-topology within a topology using defined topology
   constraints and computation algorithms.  This can be done within an
   MTR topology or the default Topology. topology.  An instance of such a sub-topology sub-
   topology is identified by a 1 octet 1-octet value (Flex-Algorithm) as
   documented in [RFC9350].  A flexible Algorithm  At the time of writing, an FA is a
   mechanism to create a sub-
   topology, but sub-topology; in the future, different
   algorithms might be defined for how to achieve that.  For that reason, this purpose.  Therefore, in the
   remainder of this document, we'll refer to this as the IGP Algorithm. "IGP
   Algorithm" or "IPA".  The IGP
   Algorithm (IPA) Field Section 4.1.2 Section 6.1 IPA field (see Sections 3.1.2 and 5.1) is
   an 8-bit identifier for the algorithm.  The permissible values are
   tracked in the IANA IGP "IGP Algorithm Types Types" registry [IANA-IGP-ALGO-TYPES].

   Throughout this document, the term Flexible Algorithm (FA) "Flexible Algorithm" (or "FA")
   shall denote the process of generating a sub-topology and signaling
   it through Interior Gateway Protocol (IGP). the IGP.  However, it is essential to note that the
   procedures outlined in this document are not exclusively applicable
   to Flexible Algorithm but the FA: they are extendable to any non-default algorithm as well.

   Multipoint LDP (mLDP)

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

2.  Terminology

2.1.  Abbreviations

   FA:  Flexible Algorithm

   FEC:  Forwarding Equivalence Class

   IGP:  Interior Gateway Protocol

   IPA:  IGP Algorithm).

3. Algorithm

   LDP:  Label Distribution Protocol

   LSP:  Label Switched Path

   mLDP:  Multipoint LDP

   MP:  Multipoint

   MP2MP:  Multipoint-to-Multipoint

   MT:  Multi-Topology

   MT-ID:  Multi-Topology Identifier

   MTR:  Multi-Topology Routing

   MVPN:  Multicast VPN in Section 2.3 of [RFC6513]

   P2MP  Point-to-Multipoint

   PMSI  Provider Multicast Service Interfaces [RFC6513]

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

3.  MT-Scoped mLDP FECs

   As defined in [RFC7307], an 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 encoding; this is
   so that LDP peers are able to setup set up 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, FEC so that different
   MT-ID values will result in unique MP-LSP MP LSP FEC elements.

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

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

4.1.

3.1.  MP FEC Extensions for MT

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

4.1.1.

3.1.1.  MP FEC Element

   Base

   The base mLDP specification [RFC6388] ([RFC6388]) defines the 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 the "Root Node Address" field encoding is defined according to
   the given "Address Family" field with its length (in octets)
   specified by the "AF Length" field.

   To extend MP FEC elements for MT, the {MT-ID, IPA} tuple is relevant
   in the context of the root address of the MP LSP.  This tuple
   determines the (sub)-topology (sub-)topology in which the root address needs to be
   resolved.  As the {MT-ID, IPA} tuple should be considered part of the
   mLDP FEC, it is most naturally encoded as part of the root address.

4.1.2.

3.1.2.  MT IP Address Families

   [RFC7307] specifies new address families, named "MT IP" and "MT
   IPv6," to allow for the specification of an IP prefix within a
   topology scope.  In addition to using these address families for
   mLDP, 8 bits of the 16-bit Reserved field that was described in RFC
   7307 are utilized to encode the
   IGP Algorithm. IPA.  The resulting format of the
   data associated with these new Address Families address families 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     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 Data Format for MT IP Address Families Data Format

   Where:

      IPv4/IPv6

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

   IPA:  The IGP Algorithm.

   Reserved:  This 8-bit field MUST be zero on transmission and MUST be
      ignored on receipt.

4.1.3.

3.1.3.  MT MP FEC Element

   By

   When using the extended MT IP Address Family, "MT IP" address family, the resulting MT MP
   FEC element should be 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MP FEC type   |  AF (MT IP/ MT IPv6)          |    AF Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Root Node Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |      IPA      |        MT-ID                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Opaque Length              |       Opaque Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 3: Data Format for an IP MT-Scoped MP FEC Element Format

   In the context of this document, the applicable LDP FECs for MT mLDP
   ([RFC6388]) include:

   *  MP FEC Elements:

      -  P2MP (type 0x6)

      -  MP2MP-up (type 0x7)

      -  MP2MP-down (type 0x8)

   *  Typed Wildcard FEC Element (type 0x5 defined in [RFC5918] ) [RFC5918])

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

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

   [RFC6514] defines the PMSI tunnel attribute for MVPN, MVPN and specifies
   that
   that:

   *  when the Tunnel Type is set to mLDP P2MP LSP, the Tunnel
      Identifier is a P2MP FEC Element, and

   *  when the Tunnel Type is set to mLDP Multipoint-to-Multipoint (MP2MP) MP2MP LSP, the Tunnel
      Identifier is an MP2MP FEC Element.

   When the extension defined in this specification is in use, the "IP IP
   MT-Scoped MP FEC Element Format" form of the respective FEC elements MUST be
   used in these two cases.

4.2.

3.2.  Topology IDs

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

5. [RFC7307].

4.  MT Multipoint Capability

   The "MT Multipoint Capability" is a new LDP capability, defined in
   accordance with the LDP Capability definition guidelines outlined in
   [RFC5561].  An mLDP speaker advertises this capability to its peers
   to announce its support for MTR and the procedures specified in this
   document.  This capability MAY be sent either in an Initialization
   message at session establishment or dynamically during the session's
   lifetime via a Capability message, provided that the "Dynamic
   Announcement" capability from [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 Capability |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |
      +-+-+-+-+-+-+-+-+

         Figure 4: Data Format for the MT Multipoint Capability TLV Format

   Where:

      U-

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

   MT Multipoint Capability:  The TLV type.

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

   Length:  This field specifies the length of the TLV in octets.  The
      value of this field MUST be 1, as there is no Capability-specific
      data [[RFC5561]] [RFC5561] following the TLV.

      S-bit:

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

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

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

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

6. 6)

5.  MT Applicability on FEC-based features

6.1. FEC-Based Features

5.1.  Typed Wildcard MP FEC Elements

   [RFC5918] extends the base LDP and defines the Typed Wildcard FEC
   Element framework.  A 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, extensions defined in this document, document do not require any
   extension to procedures for support of the Typed Wildcard FEC Element support
   [RFC5918], and these procedures apply as-is as is to Multipoint MT FEC
   wildcarding.  Similar to the Typed Wildcard MT Prefix FEC Element, as
   defined in [RFC7307], the MT extensions allow the use of "MT IP" or
   "MT IPv6" in the Address Family "Address Family" field of the Typed Wildcard MP FEC
   element.  This is done in order to use wildcard operations for MP
   FECs in the context of a given (sub)-topology (sub-)topology as identified by the
   MT-ID and IPA field. fields.

   This document defines the 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.)
      |MT-ID (cont.)  |
      +-+-+-+-+-+-+-+-+

       Figure 5: Data Format for the Typed Wildcard MT MP FEC Element

   Where:

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

      MT ID: MP2MP-up, or MP2MP-
      down)

   MT-ID:  MPLS MT ID MT-ID

   IPA:  The IGP Algorithm

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

6.2.

5.2.  End-of-LIB

   [RFC5919] specifies extensions and procedures that allow an LDP
   speaker to signal its End-of-LIB (Label Information Base) for a given
   FEC type to a peer.  By leveraging the End-of-LIB message, LDP
   ensures that label distribution remains consistent and reliable, even
   during network disruptions or maintenance activities.  The MT
   extensions for MP FEC do not require any modifications to these
   procedures and apply as-is as they are to MT MP FEC elements.
   Consequently, an MT mLDP speaker MAY signal its convergence per
   (sub-)topology using the MT Typed Wildcard MP FEC element.

7.

6.  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 in order to implement MTR in an mLDP
   network, the selection procedures for an upstream LSR and a
   downstream forwarding interface need to be changed.

7.1.

6.1.  Upstream LSR selection Selection

   The procedures as described in RFC-6388 section-2.4.1.1 Section 2.4.1.1 of [RFC6388] depend on
   the best path to reach the root.  When the {MT-ID, IPA} tuple is
   signaled as part of the FEC, this the tuple is also 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 an LDP peer is
   selected following the procedures as defined in [RFC6388].

7.2.

6.2.  Downstream forwarding interface selection

   The Forwarding Interface Selection

   Section 2.4.1.2 of [RFC6388] describes the procedures as described in RFC-6388 section-2.4.1.2 describe for how a
   downstream forwarding interface is selected.  In these procedures,
   any interface leading to the downstream LDP neighbor can be
   considered as to be a 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.

7.  LSP Ping Extensions

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

   To support LSP ping for MT Multipoint MP LSPs, this document uses existing sub-types sub-
   types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack" defined in
   [RFC6425].  The LSP Ping ping 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 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 the same as defined for the P2MP/MP2MP LDP FEC
   Stack
   Sub-TLV sub-TLV in [RFC6425].  The only difference is that the Root "Root
   LSR
   address Address" field 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]

   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.
      Capability has been used from [RFC7307] and plan to update the
      value once IANA assigns new value.

   *  Description: The implementation has been done.

   *  Maturity Level: Product

   *  Contact: mankamis@cisco.com

10.

8.  Security Considerations

   This extension to mLDP does not introduce any new security
   considerations beyond that what is already applied to the base LDP
   specification [RFC5036], the LDP extensions for Multi-Topology
   specification [RFC7307] [RFC7307], the base mLDP specification [RFC6388], and
   the MPLS security framework specification [RFC5920].

11.

9.  IANA Considerations

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

    +-----+------------------+---------------+-------------------------+
    |Value|

     +========+===============+===========+=========================+
     | Value  | Description   | Reference | Notes/Registration Date |
    +-----+------------------+---------------+-------------------------+
     +========+===============+===========+=========================+
     | TBA 0x0510 | MT Multipoint | This document RFC 9658  |                         |
     |        | 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.
     +--------+---------------+-----------+-------------------------+

                    Table 1: MT Multipoint Capability

10.  References

14.1.

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

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

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <https://www.rfc-editor.org/info/rfc6513>.

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

10.2.  Informative References

   [IANA-IGP-ALGO-TYPES]
              IANA, "IGP Algorithm Types", <https://www.iana.org/assignments/
              igp-parameters/igp-parameters.xhtml#igp-algorithm-types>.
              <https://www.iana.org/assignments/igp-parameters>.

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

Contributors

   Anuj Budhiraja
   Cisco Systems

Acknowledgments

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

Authors' Addresses

   IJsbrand Wijnands
   Individual
   Email: ice@braindump.be

   Mankamana Mishra (editor)
   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 Wealth Management
   United States of America
   Email: Arkadiy.gulko@edwardjones.com