<?xml version="1.0" encoding="US-ASCII"?>
<!-- $Id: draft-wijnands-mpls-mldp-multi-topology-00.xml 2018-10-10 skraza $ --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-mpls-mldp-multi-topology-09" number="9658" ipr="trust200902" updates="7307">
  <?rfc toc="yes" ?>
  <?rfc compact="yes"?>
  <?rfc subcompact="no"?>
  <?rfc symrefs="yes"?>
  <?rfc sortrefs="yes" ?> consensus="true" updates="7307" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="Multi-Topology mLDP">mLDP mLDP">Multipoint LDP Extensions for Multi-Topology Routing</title>

    <seriesInfo name="RFC" value="9658"/>
    <author fullname="IJsbrand Wijnands" initials="IJ." surname="Wijnands">
      <organization>Individual</organization>
      <address>
        <postal>
          <street></street>
          <!-- Reorder these if your country does things differently -->
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <email> ice@braindump.be</email>
        <!-- uri and facsimile elements may also be added -->
        <email>ice@braindump.be</email>
      </address>
    </author>
    <author fullname="Mankamana Mishra" initials="M." surname="Mishra (Editor)"> surname="Mishra" role="editor">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>821 Alder Drive</street>
          <city>Milpitas</city>
          <code>95035</code>
          <region>CA</region>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>mankamis@cisco.com</email>
      </address>
    </author>
    <author fullname="Kamran Raza" initials="K." surname="Raza">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>2000 Innovation Drive</street>
          <city>Kanata</city>
          <code>K2K-3E8</code>
          <region>ON</region>
          <country>Canada</country>
        </postal>
        <email>skraza@cisco.com</email>
      </address>
    </author>
    <author initials='Z.' surname='Zhang' fullname='Zhaohui Zhang'> initials="Z." surname="Zhang" fullname="Zhaohui Zhang">
      <organization>Juniper Networks</organization>
      <address><postal>
      <address>
        <postal>
          <street>10 Technology Park Dr.</street>
          <city>Westford</city> <region></region>
	<code>MA  01886</code>
	<country>US</country>
          <region>MA</region>
          <code>01886</code>
          <country>United States of America</country>
        </postal>
      <email>zzhang@juniper.net</email></address>
        <email>zzhang@juniper.net</email>
      </address>
    </author>

    <author initials="A." surname="Gulko" fullname="Arkadiy Gulko">
      <organization>Edward
      <organization abbrev="Edward Jones">Edward Jones wealth management</organization> Wealth Management</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <code></code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>Arkadiy.gulko@edwardjones.com</email>
      </address>
    </author>
    <date day="20" month="May" month="September" year="2024"/>

   <area>Routing</area>
   <workgroup>MPLS Working Group</workgroup>
    <area>RTG</area>
    <workgroup>mpls</workgroup>

    <keyword>MPLS</keyword>
    <keyword>mLDP</keyword>
    <keyword>Multi-topology</keyword>

    <abstract>

      <t>
       Multi-Topology Routing (MTR) is a technology to enable that enables service
   differentiation within an IP network. The 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 the use of
MTR/IPAs such that, when building multipoint Label Switched Paths) to Paths (LSPs), it can follow a
particular topology and algorithm. It
 This document updates <xref target="RFC7307"/> RFC 7307 by allocating
   eight bits from a previously reserved field to be used as the  IGP Algorithm (IPA) "IPA" field.
      </t>
    </abstract>
  </front>
  <middle>

    <section title="Glossary">
      <t>
	<list style="empty">
	  <t> FA        - Flexible Algorithm </t>
	  <t> FEC       - Forwarding Equivalence Class </t>
	  <t> IGP       - Interior Gateway Protocol </t>
	  <t> IPA       - IGP Algorithm </t>
	  <t> LDP       - Label Distribution Protocol </t>
	  <t> LSP       - Label Switched Path </t>
	  <t> mLDP      - Multipoint LDP </t>
	  <t> MP        - Multipoint (P2MP or MP2MP) </t>
	  <t> MP2MP     - Multipoint-to-Multipoint </t>
	  <t> MT        - Multi-Topology </t>
	  <t> MT-ID     - Multi-Topology Identifier </t>
	  <t> MTR       - Multi-Topology Routing </t>
	  <t> MVPN      - Multicast over Virtual Private Network defined in section 2.3 of <xref target="RFC6513"/> </t>
	  <t> P2MP      - Point-to-Multipoint </t>
	  <t> PMSI      - Provider Multicast Service Interfaces <xref target="RFC6513"/> </t>

	</list>
      </t>
    </section>

    <section title="Introduction">
      <t>
	Multi-Topology numbered="true" toc="default">
      <name>Introduction</name>
      <t>Multi-Topology Routing (MTR) is a technology to enable that enables service differentiation within an IP network. IGP protocols (OSPF IGPs (e.g., OSPF and IS-IS) and LDP have already been extended to support MTR. To support MTR, an IGP maintains independent distinct IP topologies, termed topologies referred to as "Multi-Topologies" (MT), (or "MTs"), and computes and computes/installs installs routes per specific to each topology. OSPF extensions (see <xref target="RFC4915"/> target="RFC4915" format="default"/>) and IS-IS extensions (see <xref target="RFC5120"/> target="RFC5120" format="default"/>) specify the MT extensions under respective IGPs.  To support IGP MT, similar LDP extensions (see <xref target="RFC7307"/> target="RFC7307" format="default"/>) 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.
      </t>
      <t>

<!--[rfced] We had a few questions about the following text:

Original:
A flexible Algorithm is a mechanism to create a sub- topology, but in
the future, different algorithms might be defined for how to achieve
that. For that reason, in the remainder of this document, we'll refer
to this as the IGP Algorithm.

a) Please review that our rephrase does not change your intent.

Current:
At the time of writing, an FA is a mechanism to create a sub-topology;
in the future, different algorithms might be defined for this purpose.
Therefore, in the remainder of this document, we'll refer to
this as the "IGP Algorithm" or "IPA".

b) How may we further edit to clarify "this" to the reader?  Is it the
FA?  Is it anything that can create a sub-topology?

c) Is an FA the only mechanism to create a sub-topology at the time of
writing?  If so, perhaps an update to state this clearly would help
the reader.

d) Later in the text, we see:

   Throughout this document, the term Flexible Algorithm (FA)
   shall denote the process of generating a sub-topology and signaling
   it through Interior Gateway Protocol (IGP).

Is this at all confusing or redundant with the "Original" text at the
top of this question?  In the "Original" at the top of this query, it
sounds as if the term IPA is going to be used instead of FA.  Now we
are getting info on what FA means....(This probably depends on your
responses to the previous parts of this question.)  Please review and
consider if a more thorough rewrite would be helpful to the reader.

-->

	 A more lightweight mechanism to define constraint-based topologies is
	 the Flexible Algorithm (FA) (see <xref target="RFC9350"/>. target="RFC9350" format="default"/>).

The FA can be seen as is
   another mechanism for 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 is
   identified by a 1 octet 1-octet value (Flex-Algorithm) as documented in
   <xref target="RFC9350"/>. A flexible Algorithm target="RFC9350" format="default"/>.  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 "IPA"
   field (see Sections <xref target="MT_IP_AFI"/> target="MT_IP_AFI" format="counter"/> and <xref target="Typed_Wildcard_Fec"/> target="Typed_Wildcard_Fec" format="counter"/>) is an 8-bit identifier for the algorithm.
   The permissible values are tracked in the IANA IGP "IGP Algorithm Types Types"
   registry <xref target="IANA-IGP-ALGO-TYPES"/>. target="IANA-IGP-ALGO-TYPES" format="default"/>.
      </t>
      <t>
   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.
</t>
<t>
	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)), (MP2MP) LSPs) by means of a set of extensions and procedures defined in <xref target="RFC6388"/>. target="RFC6388" format="default"/>. 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/IPAs such that 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, IGP Algorithm). IPA}.
      </t>
    </section>
    <section title="Specification numbered="true" toc="default">

      <name>Terminology</name>
    <section numbered="true" toc="default">
      <name>Abbreviations</name>
      <dl>
         <dt>FA:</dt><dd>Flexible Algorithm</dd>
         <dt>FEC:</dt><dd>Forwarding Equivalence Class</dd>
         <dt>IGP:</dt><dd>Interior Gateway Protocol</dd>
         <dt>IPA:</dt><dd>IGP Algorithm</dd>
         <dt>LDP:</dt><dd>Label Distribution Protocol</dd>
         <dt>LSP:</dt><dd>Label Switched Path</dd>
         <dt>mLDP:</dt><dd>Multipoint LDP</dd>
         <dt>MP:</dt><dd>Multipoint</dd>
         <dt>MP2MP:</dt><dd>Multipoint-to-Multipoint</dd>
         <dt>MT:</dt><dd>Multi-Topology</dd>
         <dt>MT-ID:</dt><dd>Multi-Topology Identifier</dd>
         <dt>MTR:</dt><dd>Multi-Topology Routing</dd>
         <dt>MVPN:</dt><dd>Multicast VPN in <xref target="RFC6513" sectionFormat="of" section="2.3"/></dd>
         <dt>P2MP</dt><dd>Point-to-Multipoint</dd>
         <dt>PMSI</dt><dd>Provider Multicast Service Interfaces <xref target="RFC6513" format="default"/></dd>
      </dl>
    </section>

    <section numbered="true" toc="default">
      <name>Specification of Requirements"> Requirements</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
    </section>
    </section>
    <section title="MT Scoped numbered="true" toc="default">
      <name>MT-Scoped mLDP FECs">
      <t>
	As FECs</name>
      <t>As defined in <xref target="RFC7307"/>, target="RFC7307" format="default"/>, 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, so FEC.  This ensures that different MT-ID values
will result in unique MP-LSP FEC elements.
      </t>
      <t>
	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.
      </t>
      <t>
	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.
      </t>
      <section title="MP anchor="mp-fec-ext-mt" numbered="true" toc="default">
        <name>MP FEC Extensions for MT" anchor="mp-fec-ext-mt"> MT</name>
        <t>
	  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 <xref target="RFC7307"/>. target="RFC7307" format="default"/>.
        </t>
        <section title="MP numbered="true" toc="default">
          <name>MP FEC Element"> Element</name>
          <t>
	    Base
	    The base mLDP specification <xref target="RFC6388"/> (<xref target="RFC6388" format="default"/>) defines the MP FEC Element as follows:
          </t>

          <figure title="MP anchor="mp-fec">
            <name>MP FEC Element Format [RFC6388]" anchor="mp-fec">
	    <artwork> Format</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	    </artwork>
]]></artwork>
          </figure>
          <t>
	    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.

          </t>
          <t>

	    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.

          </t>
        </section>
        <section anchor="MT_IP_AFI" title="MT numbered="true" toc="default">
          <name>MT IP Address Families"> Families</name>
          <t>
	    <xref target="RFC7307"/> target="RFC7307" format="default"/> 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 "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:

          </t>

          <figure title="Modified anchor="mt-afi">
            <name>Modified Data Format for MT IP Address Families Data Format" anchor="mt-afi">
	    <artwork> Families</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	    </artwork>
]]></artwork>
          </figure>

	  <t> Where:
	  <list style="empty">
	    <t> IPv4/IPv6 Address: An

          <t>Where:</t>
          <dl>
	    <dt>IPv4 Address and IPv6 Address:</dt>
	    <dd>An IP address corresponding to the "MT IP" and "MT IPv6" address families respectively. </t>
	    <t> IPA: The families, respectively.</dd>

            <dt>IPA:</dt>
	    <dd>The IGP Algorithm.</t>
	    <t> Reserved: This Algorithm.</dd>

            <dt>Reserved:</dt>
	    <dd>This 8-bit field MUST <bcp14>MUST</bcp14> be zero on transmission and MUST <bcp14>MUST</bcp14> be ignored on receipt. </t>
	  </list>
	  </t> receipt.</dd>
          </dl>
        </section>
        <section title="MT numbered="true" toc="default">

          <name>MT MP FEC Element"> Element</name>
          <t>
	    By
	    When using the extended MT IP Address Family, "MT IP" address family, the resulting MT MT-Scoped MP
	    FEC element should be encoded as follows:
          </t>

          <figure title="IP anchor="mt-mp-fec">
            <name>Data Format for an IP MT-Scoped MP FEC Element Format" anchor="mt-mp-fec">
	    <artwork> Element</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	    </artwork>
]]></artwork>
          </figure>
          <t>
	    In the context of this document, the applicable LDP FECs for MT mLDP (<xref target="RFC6388"/>) target="RFC6388" format="default"/>)
	    include:
          </t>
	  <t>
	    <list style="symbols">
	      <t> MP
          <ul spacing="normal">
            <li>
              <t>MP FEC Elements:
	      <list style="symbols">
		<t> P2MP (type 0x6)
              </t>
		<t> MP2MP-up
              <ul spacing="normal">
                <li>
                  <t>P2MP (type 0x7) </t>
		<t> MP2MP-down 0x6)</t>
                </li>
                <li>
                  <t>MP2MP-up (type 0x8) </t>
	      </list>
	      </t>
	      <t> Typed 0x7)</t>
                </li>
                <li>
                  <t>MP2MP-down (type 0x8)</t>
                </li>
              </ul>
            </li>
            <li>
              <t>Typed Wildcard FEC Element (type 0x5 defined in <xref target="RFC5918"/> ) </t>
	    </list>
	  </t> target="RFC5918" format="default"/>)</t>
            </li>
          </ul>
          <t>
	    In the case of "Typed the Typed Wildcard FEC Element", Element, the FEC Element type
	    MUST
	    <bcp14>MUST</bcp14> be one of the MP FECs listed above.
          </t>
          <t>
	    This specification allows the use of Topology-scoped topology-scoped mLDP FECs in
	    LDP label labels and notification messages, as applicable.
          </t>
          <t>
	    <xref target="RFC6514"/> target="RFC6514" format="default"/> defines the PMSI tunnel
	    attribute for MVPN, MVPN and specifies
   that when that:</t>
	    <ul>
	      <li>when the Tunnel Type is set
	    to mLDP P2MP LSP, the Tunnel Identifier is a P2MP FEC Element, and when and</li>
	    <li>when the Tunnel Type is set to mLDP Multipoint-to-Multipoint (MP2MP) MP2MP LSP, the Tunnel Identifier is an MP2MP FEC Element. Element.</li></ul> <t> 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 <bcp14>MUST</bcp14> be used in these two cases.
          </t>
        </section>
      </section>
      <section title="Topology IDs"> numbered="true" toc="default">
        <name>Topology IDs</name>
        <t>
	  This document assumes the same definitions and procedures associated
	  with MPLS MT-ID as specified in <xref target="RFC7307"/> specification. target="RFC7307" format="default"/>.
        </t>
      </section>
    </section>
    <section title="MT numbered="true" toc="default">
      <name>MT Multipoint Capability"> Capability</name>
      <t>
	The "MT Multipoint Capability" Multipoint" capability is a new LDP capability, defined in
	accordance with the LDP Capability capability definition guidelines outlined in
	<xref target="RFC5561"/>. target="RFC5561" format="default"/>. 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
	<bcp14>MAY</bcp14> 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 <xref target="RFC5561"/> target="RFC5561" format="default"/> has been
	successfully negotiated with the peer.
      </t>
      <t>
	The format of this capability is as follows:
      </t>
      <figure title="MT anchor="mt-mp-cap">
        <name>Data Format for the MT Multipoint Capability TLV Format" anchor="mt-mp-cap">
	<artwork> TLV</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    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    |
   +-+-+-+-+-+-+-+-+
	</artwork>
]]></artwork>
      </figure>

      <t> Where:
      <list style="empty">
	<t> U- and F-bits: MUST

      <t>Where:</t>
      <dl>
        <dt>U and F bits:</dt>
	<dd><bcp14>MUST</bcp14> be 1 and 0, respectively, as per Section 3 of
	LDP Capabilities <xref target="RFC5561"/>. </t>

	<t> MT
	target="RFC5561" sectionFormat="of" section="3"/>.</dd>

        <dt>MT Multipoint Capability: Capability:</dt>
	<dd>The TLV type. </t>

	<t> Length: The length (in octets) of TLV. The value of this field
	MUST be 1 as there is no Capability-specific data <xref target="RFC5561"/>
	that follows in the TLV.
	Length: This type.</dd>

	<dt>Length:</dt><dd>This field specifies the length of the TLV in
	octets. The value of this field MUST <bcp14>MUST</bcp14> be 1, as there
	is no Capability-specific capability-specific data [<xref target="RFC5561"/>] <xref target="RFC5561"
	format="default"/> following the TLV.

	</t>

	<t> S-bit: Set TLV.</dd>

        <dt>S bit:</dt>
	<dd>Set to 1 to announce and 0 to withdraw the capability (as per
	<xref target="RFC5561"/>. </t>
      </list>
      </t> target="RFC5561" format="default"/>).</dd>
      </dl>

      <t>
	An mLDP speaker that has successfully advertised and negotiated the "MT
	Multipoint" capability MUST <bcp14>MUST</bcp14> support the following:
      </t>
      <t>
      <list style="numbers">
	<t> Topology-scoped
      <ol spacing="normal" type="1">
	<li>
          <t>Topology-scoped mLDP FECs in LDP messages (<xref target="mp-fec-ext-mt"/>) </t>
	<t> Topology-scoped target="mp-fec-ext-mt" format="default"/>)</t>
        </li>
        <li>
          <t>Topology-scoped mLDP forwarding setup (<xref target="mt-fwd"/>) </t>
      </list>
      </t> target="mt-fwd" format="default"/>)</t>
        </li>
      </ol>
    </section>
    <section title="MT numbered="true" toc="default">
      <name>MT Applicability on FEC-based features"> FEC-Based Features</name>
      <section anchor="Typed_Wildcard_Fec" title="Typed numbered="true" toc="default">
        <name>Typed Wildcard MP FEC Elements"> Elements</name>
        <t>
	  <xref target="RFC5918"/> target="RFC5918" format="default"/> 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.
        </t>

        <t>
	 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 <xref target="RFC5918"/>,
	 target="RFC5918" format="default"/>, 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 <xref target="RFC7307"/>, target="RFC7307" format="default"/>,
	 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 "MT-ID" and
IPA field. "IPA" fields.
	</t>
        <t>
	  This document defines the following format and encoding for a Typed
	  Wildcard MP FEC element:
        </t>
        <figure title="Typed anchor="mt-mp-wc-fec">
          <name>Data Format for the Typed Wildcard MT MP FEC Element" anchor="mt-mp-wc-fec">
	  <artwork> Element</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    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.)  |
   +-+-+-+-+-+-+-+-+
	  </artwork>
]]></artwork>
        </figure>

	<t> Where:
	<list style="empty">
	  <t> Type: One
        <t>Where:</t>
        <dl>
           <dt>Type:</dt><dd>One of the MP FEC Element type types (P2MP, MP2MPup, MP2MP-down). </t>
	  <t> MT ID: MPLS MT ID </t>
	  <t> IPA: The MP2MP-up, or MP2MP-down)</dd>
           <dt>MT-ID:</dt><dd>MPLS MT-ID</dd>
           <dt>IPA:</dt><dd>The IGP Algorithm</t>
	</list>
	</t> Algorithm</dd>
        </dl>
        <t>
	  The defined format allows an LSR a Label Switching Router (LSR) to perform wildcard MP FEC
	  operations under the scope of a (sub-)topology.
        </t>
      </section>
      <section title="End-of-LIB"> numbered="true" toc="default">
        <name>End-of-LIB</name>
        <t>
	  <xref target="RFC5919"/> target="RFC5919" format="default"/> 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 <bcp14>MAY</bcp14> signal its convergence per
	  (sub-)topology using the MT Typed Wildcard MP FEC element.
        </t>
      </section>
    </section>
    <section title="Topology-Scoped anchor="mt-fwd" numbered="true" toc="default">
      <name>Topology-Scoped Signaling and Forwarding" anchor="mt-fwd"> Forwarding</name>
      <t>
	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.
      </t>
      <section title="Upstream numbered="true" toc="default">
        <name>Upstream LSR selection"> Selection</name>
        <t>
	  The procedures as described in RFC-6388 section-2.4.1.1 <xref section="2.4.1.1" sectionFormat="of" target="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 <xref target="RFC6388"/>. target="RFC6388" format="default"/>.
        </t>
      </section>
      <section title="Downstream forwarding interface selection"> numbered="true" toc="default">
        <name>Downstream Forwarding Interface Selection</name>
        <t>
	  The
	  <xref target="RFC6388" sectionFormat="of" section="2.4.1.2"/> 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
	  <xref target="RFC6388"/> target="RFC6388" format="default"/> apply.
        </t>
      </section>
    </section>
    <section title="LSP numbered="true" toc="default">
      <name>LSP Ping Extensions"> Extensions</name>
      <t>
	<xref target="RFC6425"/> target="RFC6425" format="default"/> defines procedures to detect data plane failures in
	Multipoint
	multipoint MPLS LSPs. Section 3.1.2 of <xref target="RFC6425"/> target="RFC6425" sectionFormat="of" section="3.1.2"/> 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 Echo Request message <xref target="RFC8029"/>. target="RFC8029" format="default"/>.
      </t>
      <t>
	To support LSP ping for MT Multipoint MP LSPs, this document uses
	existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack"
	defined in <xref target="RFC6425"/>. target="RFC6425" format="default"/>. 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:
      </t>

      <figure title="Multipoint anchor="mt-fec-lspv">
        <name>Multipoint LDP FEC Stack Sub-TLV Format for MT" anchor="mt-fec-lspv">
	<artwork> MT</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 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 ...      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
~                                                               ~
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	</artwork>
]]></artwork>
      </figure>
      <t>
	The rules and procedures of using this new sub-TLV in an MPLS echo request Echo
	Request message are the same as defined for the P2MP/MP2MP LDP FEC Stack Sub-TLV
	sub-TLV in <xref target="RFC6425"/>. target="RFC6425" format="default"/>. The only
	difference is that the Root "Root LSR address Address" field is now (sub-)topology scoped.
      </t>
    </section>

    <section title="Implementation Status">
<t>
[Note to the RFC Editor - remove this section before publication, as well as remove the reference to
<xref target="RFC7942"/>
</t>

<t>
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
<xref target="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.
</t>

<t>
According to
<xref target="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".
</t>

<section title="Cisco Systems">
<t>The feature has been implemented on IOS-XR.</t>
<t>
<list style="symbols">
<t>Organization: Cisco Systems</t>
<t>
Implementation: Cisco systems IOS-XR has an implementation. Capability has been used from <xref target="RFC7307"/> and plan to update the value once IANA assigns new value.
</t>
<t>Description: The implementation has been done.</t>
<t>Maturity Level: Product</t>
<t>Contact: mankamis@cisco.com</t>
</list>
</t>
</section>

	    </section>

    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
	This extension to mLDP does not introduce any new security
	considerations beyond that what is already applied to the base LDP
	specification <xref target="RFC5036"/>, target="RFC5036" format="default"/>, the LDP
	extensions for Multi-Topology specification <xref target="RFC7307"/> target="RFC7307"
	format="default"/>, the base mLDP specification <xref target="RFC6388"/>, target="RFC6388"
	format="default"/>, and the MPLS security framework specification <xref target="RFC5920"/>. target="RFC5920"
	format="default"/>.
      </t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
	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.
      </t>

      <figure title="IANA Code Point"

<table anchor="iana">
	<artwork>

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

	</artwork>
      </figure> Capability</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
      <th>Notes/Registration Date</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0x0510</td>
      <td>MT Multipoint Capability</td>
      <td>RFC 9658</td>
      <td></td>
    </tr>
  </tbody>
</table>
</section>
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4915.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7307.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6388.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6425.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9350.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5918.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5919.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5920.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5561.xml"/>

        <reference anchor="IANA-IGP-ALGO-TYPES" target="https://www.iana.org/assignments/igp-parameters">
          <front>
            <title>IGP Algorithm Types</title>
            <author>
	      <organization>IANA</organization>
	    </author>
           </front>
        </reference>

      </references>
    </references>

        <section title="Contributor">
	    <t>
		    Anuj Budhiraja
		    Cisco systems
		    </t> numbered="false" toc="default">
	  <name>Contributors</name>
	  <contact fullname="Anuj Budhiraja">
	    <organization>Cisco Systems</organization></contact>
    </section>

    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
	The authors would like to acknowledge Eric Rosen <contact fullname="Eric Rosen"/> for his input on
	this specification.
      </t>
    </section>

  </middle>

  <back>

    <references title="Normative References">
      &rfc2119;
      <?rfc include="reference.RFC.4915"?>
      <?rfc include="reference.RFC.5120"?>
      <?rfc include="reference.RFC.7307"?>
      <?rfc include="reference.RFC.6388"?>
      <?rfc include="reference.RFC.8029"?>
      <?rfc include="reference.RFC.6425"?>
      <?rfc include="reference.RFC.9350"?>
      <?rfc include="reference.RFC.7942"?>
      <?rfc include="reference.RFC.6514"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.6513"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.5036"?>
      <?rfc include="reference.RFC.5918"?>
      <?rfc include="reference.RFC.5919"?>
      <?rfc include="reference.RFC.5920"?>
      <?rfc include="reference.RFC.5561"?>
              <reference anchor="IANA-IGP-ALGO-TYPES"
       target="https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types">
          <front>
            <title>IGP

<!-- [rfced] Throughout the text, we had the following
     questions/comments about abbreviations.

a) Do the following create redundancies upon expansion?

i) "MTR topology": Expanded this would be "Multi-Topology Routing
topology".

Original:
This can be done within an MTR topology or the default Topology.

Original:
...used to associate an LSP with a certain MTR topology

Original:
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).

ii) "Multipoint MPLS LSPs": When expanded this is "Multipoint
Multiprotocol Label Switching Label Switching Path".

Original:
   [RFC6425] defines procedures to detect data plane failures in
   Multipoint MPLS LSPs.
-->

<!-- [rfced] We had the following questions related to terminology use
     throughout the document.

c) Please let us know if/how the following terms may be updated for consistency.

FEC Element vs. FEC element

MT Prefix FEC Element vs. MP FEC element vs. MT Typed Wildcard MP FEC element

Flex-Alogorithm vs. Flexible Algorithm Types</title>
            <author/>
            <date/>
          </front>
        </reference>
    </references>

-->

  </back>
</rfc>