rfc9658xml2.original.xml   rfc9658.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!-- $Id: draft-wijnands-mpls-mldp-multi-topology-00.xml 2018-10-10 skraza $ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY nbsp "&#160;">
.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<rfc category="std" docName="draft-ietf-mpls-mldp-multi-topology-09" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
ipr="trust200902" updates="7307"> tf-mpls-mldp-multi-topology-09" number="9658" ipr="trust200902" consensus="true"
<?rfc toc="yes" ?> updates="7307" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="tru
<?rfc compact="yes"?> e" symRefs="true" sortRefs="true" version="3">
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<front> <front>
<title abbrev="Multi-Topology mLDP">Multipoint LDP Extensions for Multi-Topo logy Routing</title>
<title abbrev="Multi-Topology mLDP">mLDP Extensions for Multi-Topology Routi <seriesInfo name="RFC" value="9658"/>
ng</title>
<author fullname="IJsbrand Wijnands" initials="IJ." surname="Wijnands"> <author fullname="IJsbrand Wijnands" initials="IJ." surname="Wijnands">
<organization>Individual</organization> <organization>Individual</organization>
<address> <address>
<postal> <email>ice@braindump.be</email>
<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 -->
</address> </address>
</author> </author>
<author fullname="Mankamana Mishra" initials="M." surname="Mishra" role="edi
<author fullname="Mankamana Mishra" initials="M." surname="Mishra (Edito tor">
r)">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>821 Alder Drive</street> <street>821 Alder Drive</street>
<city>Milpitas</city> <city>Milpitas</city>
<code>95035</code> <code>95035</code>
<region>CA</region> <region>CA</region>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>mankamis@cisco.com</email> <email>mankamis@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Kamran Raza" initials="K." surname="Raza"> <author fullname="Kamran Raza" initials="K." surname="Raza">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>2000 Innovation Drive</street> <street>2000 Innovation Drive</street>
<city>Kanata</city> <city>Kanata</city>
<code>K2K-3E8</code> <code>K2K-3E8</code>
<region>ON</region> <region>ON</region>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>skraza@cisco.com</email> <email>skraza@cisco.com</email>
</address> </address>
</author> </author>
<author initials='Z.' surname='Zhang' fullname='Zhaohui Zhang'> <author initials="Z." surname="Zhang" fullname="Zhaohui Zhang">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address><postal> <address>
<street>10 Technology Park Dr.</street> <postal>
<city>Westford</city> <region></region> <street>10 Technology Park Dr.</street>
<code>MA 01886</code> <city>Westford</city>
<country>US</country> <region>MA</region>
</postal> <code>01886</code>
<email>zzhang@juniper.net</email></address> <country>United States of America</country>
</postal>
<email>zzhang@juniper.net</email>
</address>
</author> </author>
<author initials="A." surname="Gulko" fullname="Arkadiy Gulko"> <author initials="A." surname="Gulko" fullname="Arkadiy Gulko">
<organization>Edward Jones wealth management</organization> <organization abbrev="Edward Jones">Edward Jones Wealth Management</organi zation>
<address> <address>
<postal> <postal>
<street></street> <country>United States of America</country>
<city></city>
<code></code>
<country>USA</country>
</postal> </postal>
<email>Arkadiy.gulko@edwardjones.com</email> <email>Arkadiy.gulko@edwardjones.com</email>
</address> </address>
</author> </author>
<date month="October" year="2024"/>
<area>RTG</area>
<workgroup>mpls</workgroup>
<date day="20" month="May" year="2024"/> <keyword>MPLS</keyword>
<keyword>mLDP</keyword>
<keyword>Multi-topology</keyword>
<area>Routing</area> <abstract>
<workgroup>MPLS Working Group</workgroup>
<keyword>MPLS</keyword>
<keyword>mLDP</keyword>
<keyword>Multi-topology</keyword>
<abstract> <t>
<t> Multi-Topology Routing (MTR) is a technology that enables service
Multi-Topology Routing (MTR) is a technology to enable service differentiation within an IP network. The Flexible Algorithm (FA) is
differentiation within an IP network. Flexible Algorithm (FA) is another mechanism for creating a sub-topology within a topology using
another mechanism of creating a sub-topology within a topology using defined topology constraints and computation algorithms. In order to
defined topology constraints and computation algorithm. In order to deploy Multipoint LDP (mLDP) in a network
deploy mLDP (Multipoint label distribution protocol) in a network
that supports MTR, FA, or other methods of signaling non-default that supports MTR, FA, or other methods of signaling non-default
IGP algorithms, mLDP is required to become topology and IGP Algorithms (IPAs), mLDP is required to become topology and
algorithm aware. This document specifies extensions to mLDP to support MTR, algorithm aware. This document specifies extensions to mLDP to support the u
with an algorithm, in order for Multipoint LSPs(Label Switched Paths) to foll se of
ow MTR/IPAs such that, when building multipoint Label Switched Paths (LSPs), the LS
a particular topology and algorithm. It updates <xref target="RFC7307"/> by a Ps can follow a
llocating particular topology and algorithm.
eight bits from a previously reserved field to be used as the IGP Algorithm This document updates RFC 7307 by allocating
(IPA) field. eight bits from a previously reserved field to be used as the "IPA" field.
</t> </t>
</abstract>
</abstract>
</front> </front>
<middle> <middle>
<section title="Glossary"> <section numbered="true" toc="default">
<t> <name>Introduction</name>
<list style="empty"> <t>Multi-Topology Routing (MTR) is a technology that enables service diffe
<t> FA - Flexible Algorithm </t> rentiation within an IP network. IGPs (e.g., OSPF and IS-IS) and LDP have alread
<t> FEC - Forwarding Equivalence Class </t> y been extended to support MTR. To support MTR, an IGP maintains distinct IP top
<t> IGP - Interior Gateway Protocol </t> ologies referred to as "Multi-Topologies" (or "MTs"), and computes and installs
<t> IPA - IGP Algorithm </t> routes specific to each topology. OSPF extensions (see <xref target="RFC4915" fo
<t> LDP - Label Distribution Protocol </t> rmat="default"/>) and IS-IS extensions (see <xref target="RFC5120" format="defau
<t> LSP - Label Switched Path </t> lt"/>) specify the MT extensions under respective IGPs. To support IGP MT, simi
<t> mLDP - Multipoint LDP </t> lar LDP extensions (see <xref target="RFC7307" format="default"/>) have been spe
<t> MP - Multipoint (P2MP or MP2MP) </t> cified to make LDP be MT aware and to be able to set up unicast Label Switched P
<t> MP2MP - Multipoint-to-Multipoint </t> aths (LSPs) along IGP MT routing paths.
<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 secti
on 2.3 of <xref target="RFC6513"/> </t>
<t> P2MP - Point-to-Multipoint </t>
<t> PMSI - Provider Multicast Service Interfaces <xref target="RFC
6513"/> </t>
</list>
</t>
</section>
<section title="Introduction">
<t>
Multi-Topology Routing (MTR) is a technology to enable service differenti
ation 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 to
pologies, termed as "Multi-Topologies" (MT), and computes/installs routes per to
pology. OSPF extensions <xref target="RFC4915"/> and IS-IS extensions <xref targ
et="RFC5120"/> specify the MT extensions under respective IGPs. To support IGP M
T, similar LDP extensions <xref target="RFC7307"/> have been specified to make L
DP MT-aware and be able to setup unicast Label Switched Paths (LSPs) along IGP M
T routing paths.
</t> </t>
<t> <t>
A more lightweight mechanism to define constraint-based topologies is A more lightweight mechanism to define constraint-based topologies is
the Flexible Algorithm (FA) <xref target="RFC9350"/>. FA can be seen as creat the Flexible Algorithm (FA) (see <xref target="RFC9350" format="default"
ing 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. An instance of such a sub-topology is
identified by a 1 octet value (Flex-Algorithm) as documented in
<xref target="RFC9350"/>. 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. The IGP Algorithm (IPA)
Field <xref target="MT_IP_AFI"/> <xref target="Typed_Wildcard_Fec"/> is an 8-
bit identifier for the algorithm.
The permissible values are tracked in the IANA IGP Algorithm Types
registry <xref target="IANA-IGP-ALGO-TYPES"/>.
</t>
<t>
Throughout this document, the term Flexible Algorithm (FA) shall denote the p
rocess of generating a sub-topology and signaling it through Interior Gateway Pr
otocol (IGP). However, it is essential to note that the procedures outlined in t
his document are not exclusively applicable to Flexible Algorithm but are extend
able to any non-default algorithm as well.
</t>
The FA 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. An instance of such a sub-topology is
identified by a 1-octet value (Flexible Algorithm) as documented in
<xref target="RFC9350" format="default"/>. 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". The "IPA"
field (see Sections <xref target="MT_IP_AFI" format="counter"/> and <xref tar
get="Typed_Wildcard_Fec" format="counter"/>) is an 8-bit identifier for the algo
rithm.
The permissible values are tracked in the "IGP Algorithm Types"
registry <xref target="IANA-IGP-ALGO-TYPES" format="default"/>.
</t>
<t> <t>
Multipoint LDP (mLDP) refers to extensions in LDP to setup multi-point LS Throughout this document, the term "Flexible Algorithm" (or "FA") shall denot
Ps (point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP)), by means of e the process of generating a sub-topology and signaling it through the IGP. How
a set of extensions and procedures defined in <xref target="RFC6388"/>. In orde ever, it is essential to note that the procedures outlined in this document are
r to deploy mLDP in a network that supports MTR and FA, mLDP is required to beco not exclusively applicable to the FA: they are extendable to any non-default alg
me topology and algorithm aware. This document specifies extensions to mLDP to s orithm as well.
upport MTR/IGP Algorithm such that when building a Multi-Point LSPs it can follo </t>
w a particular topology and algorithm. This means that the identifier for the pa <t>
rticular topology to be used by mLDP have to become a 2-tuple (MTR Topology Id, "Multipoint LDP" (or "mLDP") refers to extensions in LDP to set up multipoint LS
IGP Algorithm). Ps (i.e., point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) LSPs) b
y means of a set of extensions and procedures defined in <xref target="RFC6388"
format="default"/>. In order to deploy mLDP in a network that supports MTR and t
he FA, mLDP is required to become topology and algorithm aware. This document sp
ecifies extensions to mLDP to support the use of
MTR/IPAs such that, when building multipoint LSPs, it can follow a
particular topology and algorithm. Therefore, the identifier for the particular
topology to be used by mLDP has to become a 2-tuple {MTR Topology Id, IPA}.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Specification of Requirements"> <name>Terminology</name>
<t> <section numbered="true" toc="default">
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <name>Abbreviations</name>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <dl>
"MAY", and "OPTIONAL" in this document are to be interpreted as <dt>FA:</dt><dd>Flexible Algorithm</dd>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when <dt>FEC:</dt><dd>Forwarding Equivalence Class</dd>
, and only when, they <dt>IGP:</dt><dd>Interior Gateway Protocol</dd>
appear in all capitals, as shown here. <dt>IPA:</dt><dd>IGP Algorithm</dd>
</t> <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="R
FC6513" format="default"/></dd>
</dl>
</section> </section>
<section title="MT Scoped mLDP FECs"> <section numbered="true" toc="default">
<t> <name>Specification of Requirements</name>
As defined in <xref target="RFC7307"/>, MPLS Multi-Topology Identifier (M <t>
T-ID) is an identifier that is used to associate an LSP with a certain MTR topol The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
ogy. In the context of MP LSPs, this identifier is part of the mLDP FEC encoding "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
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 nee "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
ds to be a part of the FEC, so that different MT-ID values will result in unique "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
MP-LSP FEC elements. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in 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 numbered="true" toc="default">
<name>MT-Scoped mLDP FECs</name>
<t>As defined in <xref target="RFC7307" format="default"/>, an MPLS Multi-
Topology Identifier (MT-ID) is used to associate an LSP with a certain MTR topol
ogy. In the context of MP LSPs, this identifier is part of the mLDP FEC encoding
; this is so that LDP peers are able to set up an MP LSP via their own defined M
TR policy. In order to avoid conflicting MTR policies for the same mLDP FEC, th
e
MT-ID needs to be a part of the FEC. This ensures that different MT-ID values
will result in unique MP-LSP FEC elements.
</t> </t>
<t> <t>
The same applies to the IGP Algorithm. The IGP Algorithm needs to be enco ded as part of the mLDP FEC to create unique MP-LSPs. The IGP Algorithm is also used to signal to mLDP (hop-by-hop) which Algorithm needs to be used to create t he MP-LSP. The same applies to the IPA. The IPA needs to be encoded as part of the m LDP FEC to create unique MP LSPs. The IPA is also used to signal to the mLDP (ho p-by-hop) which algorithm needs to be used to create the MP LSP.
</t> </t>
<t> <t>
Since the MT-ID and IGP Algorithm are part of the FEC, they apply to all the LDP messages that potentially include an mLDP FEC element. Since the MT-ID and IPA are part of the FEC, they apply to all the LDP me ssages that potentially include an mLDP FEC element.
</t> </t>
<section anchor="mp-fec-ext-mt" numbered="true" toc="default">
<section title="MP FEC Extensions for MT" anchor="mp-fec-ext-mt"> <name>MP FEC Extensions for MT</name>
<t> <t>
The following subsections define the extensions to bind an mLDP FEC to The following subsections define the extensions to bind an mLDP FEC to
a topology. These mLDP MT extensions reuse some of the extensions a topology. These mLDP MT extensions reuse some of the extensions
specified in <xref target="RFC7307"/>. specified in <xref target="RFC7307" format="default"/>.
</t> </t>
<section numbered="true" toc="default">
<section title="MP FEC Element"> <name>MP FEC Element</name>
<t> <t>
Base mLDP specification <xref target="RFC6388"/> defines MP FEC Eleme The base mLDP specification (<xref target="RFC6388" format="default"/
nt as follows: >) defines the MP FEC element as follows:
</t> </t>
<figure title="MP FEC Element Format [RFC6388]" anchor="mp-fec">
<artwork>
<figure anchor="mp-fec">
<name>MP FEC Element Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | MP FEC type | Address Family | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address | | Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value | | Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></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.
</artwork> </t>
</figure> <t>
<t>
Where the "Root Node Address" encoding is defined according to the gi
ven "Address
Family" 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 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 context of the root address of the MP LSP. This tuple determines the
(sub)-topology in which the root address needs to be resolved. As the {MT-ID, (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 IPA} tuple should be considered part of the mLDP FEC, it is most naturally
encoded as part of the root address. encoded as part of the root address.
</t> </t>
</section> </section>
<section anchor="MT_IP_AFI" numbered="true" toc="default">
<section anchor="MT_IP_AFI" title="MT IP Address Families"> <name>MT IP Address Families</name>
<t> <t>
<xref target="RFC7307"/> specifies new address families, named "MT IP <xref target="RFC7307" format="default"/> specifies new address famil
" and "MT IPv6," to ies, named "MT IP" and "MT IPv6," to
allow for the specification of an IP prefix within a topology scope. In addition 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 to using these address families for mLDP, 8 bits of the 16-bit "Reserved" field
are utilized to encode the IGP Algorithm. The resulting format that was described in RFC 7307
of the data associated with these new Address Families is as follows: are utilized to encode the IPA. The resulting format
of the data associated with these new address families is as follows:
</t>
<figure title="Modified MT IP Address Families Data Format" anchor="mt- </t>
afi">
<artwork>
<figure anchor="mt-afi">
<name>Modified Format for MT IP Address Families</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID | | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | | IPv6 Address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID | | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</artwork> <t>Where:</t>
</figure> <dl>
<dt>IPv4 Address and IPv6 Address:</dt>
<t> Where: <dd>An IP address corresponding to the "MT IP" and "MT IPv6" address
<list style="empty"> families, respectively.</dd>
<t> IPv4/IPv6 Address: An IP address corresponding to "MT IP"
and "MT IPv6" address families respectively. </t>
<t> IPA: The IGP Algorithm.</t>
<t> Reserved: This 8-bit field MUST be zero on transmission and MUST
be ignored on receipt. </t>
</list>
</t>
</section> <dt>IPA:</dt>
<dd>The IGP Algorithm.</dd>
<section title="MT MP FEC Element"> <dt>Reserved:</dt>
<t> <dd>This 8-bit field <bcp14>MUST</bcp14> be zero on transmission and
By using the extended MT IP Address Family, the resulting MT MP FEC e <bcp14>MUST</bcp14> be ignored on receipt.</dd>
lement </dl>
should be encoded as follows: </section>
<section numbered="true" toc="default">
</t> <name>MT MP FEC Element</name>
<t>
When using the extended "MT IP" address family, the resulting MT-Scop
ed MP
FEC element should be encoded as follows:
</t>
<figure title="IP MT-Scoped MP FEC Element Format" anchor="mt-mp-fec"> <figure anchor="mt-mp-fec">
<artwork> <name>Format for an IP MT-Scoped MP FEC Element</name>
0 1 2 3 <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 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 | | MP FEC type | AF (MT IP/ MT IPv6) | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address | | Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID | | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value | | Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</artwork> </figure>
</figure> <t>
In the context of this document, the applicable LDP FECs for MT mLDP
<t> (<xref target="RFC6388" format="default"/>)
In the context of this document, the applicable LDP FECs for MT mLDP
(<xref target="RFC6388"/>)
include: include:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t> MP FEC Elements: <t>MP FEC elements:
<list style="symbols"> </t>
<t> P2MP (type 0x6) </t> <ul spacing="normal">
<t> MP2MP-up (type 0x7) </t> <li>
<t> MP2MP-down (type 0x8) </t> <t>P2MP (type 0x6)</t>
</list> </li>
</t> <li>
<t> Typed Wildcard FEC Element (type 0x5 defined in <xref target="R <t>MP2MP-up (type 0x7)</t>
FC5918"/> ) </t> </li>
</list> <li>
</t> <t>MP2MP-down (type 0x8)</t>
</li>
<t> </ul>
In case of "Typed Wildcard FEC Element", the FEC Element type </li>
MUST be one of the MP FECs listed above. <li>
</t> <t>Typed Wildcard FEC Element (type 0x5 defined in <xref target="R
FC5918" format="default"/>)</t>
<t> </li>
This specification allows the use of Topology-scoped mLDP FECs in </ul>
LDP label and notification messages, as applicable. <t>
</t> In the case of the Typed Wildcard FEC Element, the FEC element type
<bcp14>MUST</bcp14> be one of the MP FECs listed above.
<t> </t>
<xref target="RFC6514"/> defines the PMSI tunnel attribute f <t>
or MVPN, and specifies This specification allows the use of topology-scoped mLDP FECs in
that when the Tunnel Type is set to mLDP P2MP LSP, the Tunnel LDP labels and notification messages, as applicable.
Identifier is a P2MP FEC Element, and when the Tunnel Type is set to </t>
mLDP Multipoint-to-Multipoint (MP2MP) LSP, the Tunnel Identifier is <t>
an MP2MP FEC Element. When the extension defined in this <xref target="RFC6514" format="default"/> defines the PMSI tunnel
specification is in use, the "IP MT-Scoped MP FEC Element Format" attribute for MVPN and specifies that:</t>
form of the respective FEC elements MUST be used in these two cases. <ul>
<li>when the Tunnel Type is set
</t> to mLDP P2MP LSP, the Tunnel Identifier is a P2MP FEC element, and</l
i>
</section> <li>when the Tunnel Type is set to mLDP MP2MP LSP, the Tunnel Identif
ier is an MP2MP FEC element.</li></ul> <t> When
the extension defined in this specification is in use, the IP
MT-Scoped MP FEC element form of the respective FEC
elements <bcp14>MUST</bcp14> be used in these two cases.
</t>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Topology IDs"> <name>Topology IDs</name>
<t> <t>
This document assumes the same definitions and procedures associated This document assumes the same definitions and procedures associated
with MPLS MT-ID as specified in <xref target="RFC7307"/> specification. with MPLS MT-ID as specified in <xref target="RFC7307" format="default"
</t> />.
</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="MT Multipoint Capability"> <name>MT Multipoint Capability</name>
<t> <t>
The "MT Multipoint" capability is a new LDP capability, defined in
The "MT Multipoint Capability" is a new LDP capability, defined in accord accordance with the LDP capability definition guidelines outlined in
ance <xref target="RFC5561" format="default"/>. An mLDP speaker advertises
with the LDP Capability definition guidelines outlined in <xref target="RFC5561" this capability to its peers to announce its support for MTR and the
/>. An mLDP procedures specified in this document. This capability
speaker advertises this capability to its peers to announce its support for MTR <bcp14>MAY</bcp14> be sent either in an Initialization message at
and the procedures specified in this document. This capability MAY be sent session establishment or dynamically during the session's lifetime via
either in an Initialization message at session establishment or dynamically a Capability message, provided that the "Dynamic Announcement"
during the session's lifetime via a Capability message, provided that capability from <xref target="RFC5561" format="default"/> has been
the "Dynamic Announcement" capability from <xref target="RFC5561"/> has been successfully negotiated with the peer.
successfully negotiated with the peer.
</t> </t>
<t> <t>
The format of this capability is as follows: The format of this capability is as follows:
</t> </t>
<figure anchor="mt-mp-cap">
<figure title="MT Multipoint Capability TLV Format" anchor="mt-mp-cap"> <name>Format for the MT Multipoint Capability TLV</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | |U|F| MT Multipoint Capability | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<t> Where: <t>Where:</t>
<list style="empty"> <dl>
<t> U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of <dt>U and F bits:</dt>
LDP Capabilities <xref target="RFC5561"/>. </t> <dd><bcp14>MUST</bcp14> be 1 and 0, respectively, as per <xref
target="RFC5561" sectionFormat="of" section="3"/>.</dd>
<t> MT Multipoint Capability: TLV type. </t>
<t> Length: The length (in octets) of TLV. The value of this field <dt>MT Multipoint Capability:</dt>
MUST be 1 as there is no Capability-specific data <xref target="RFC5561"/ <dd>The TLV type.</dd>
>
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 [<xref t
arget="RFC5561"/>]
following the TLV.
</t> <dt>Length:</dt><dd>This field specifies the length of the TLV in
octets. The value of this field <bcp14>MUST</bcp14> be 1, as there
is no capability-specific data <xref target="RFC5561"
format="default"/> following the TLV.</dd>
<t> S-bit: Set to 1 to announce and 0 to withdraw the capability (as <dt>S bit:</dt>
per <xref target="RFC5561"/>. </t> <dd>Set to 1 to announce and 0 to withdraw the capability (as per
</list> <xref target="RFC5561" format="default"/>).</dd>
</t> </dl>
<t> <t>
An mLDP speaker that has successfully advertised and negotiated "MT An mLDP speaker that has successfully advertised and negotiated the "MT
Multipoint" capability MUST support the following: Multipoint" capability <bcp14>MUST</bcp14> support the following:
</t>
<t>
<list style="numbers">
<t> Topology-scoped mLDP FECs in LDP messages (<xref target="mp-fec-ext-m
t"/>) </t>
<t> Topology-scoped mLDP forwarding setup (<xref target="mt-fwd"/>) </t>
</list>
</t> </t>
<ol spacing="normal" type="1">
<li>
<t>Topology-scoped mLDP FECs in LDP messages (<xref target="mp-fec-ext
-mt" format="default"/>)</t>
</li>
<li>
<t>Topology-scoped mLDP forwarding setup (<xref target="mt-fwd" format
="default"/>)</t>
</li>
</ol>
</section> </section>
<section numbered="true" toc="default">
<section title="MT Applicability on FEC-based features"> <name>MT Applicability on FEC-Based Features</name>
<section anchor="Typed_Wildcard_Fec" numbered="true" toc="default">
<section anchor="Typed_Wildcard_Fec" title="Typed Wildcard MP FEC Elements <name>Typed Wildcard MP FEC Elements</name>
"> <t>
<xref target="RFC5918" format="default"/> extends the base LDP and defi
<t> nes the Typed Wildcard FEC Element
<xref target="RFC5918"/> extends base LDP and defines Typed Wildcard FE framework. A Typed Wildcard FEC Element can be used in any LDP message
C Element
framework. Typed Wildcard FEC element can be used in any LDP message
to specify a wildcard operation for a given type of FEC. to specify a wildcard operation for a given type of FEC.
</t> </t>
<t>
The MT extensions, defined in this document, do not require any extensio
n to
procedures for Typed Wildcard FEC Element support <xref target="RFC5918"/>, and
these
procedures apply as-is to Multipoint MT FEC wildcarding. Similar to Typed
Wildcard MT Prefix FEC Element, as defined in <xref target="RFC7307"/>, the MT e
xtensions
allow the use of "MT IP" or "MT IPv6" in the 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 as identified by the MT-ID and
IPA field.
<t>
The MT extensions defined in this document do not require any
extension to procedures for support of the Typed Wildcard FEC Element <x
ref
target="RFC5918" format="default"/>, and these procedures apply as is
to Multipoint MT FEC wildcarding. Similar to the Typed Wildcard MT Prefi
x
FEC element, as defined in <xref target="RFC7307" format="default"/>,
the MT extensions allow the use of "MT IP" or "MT IPv6" in the
"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 as identified by the "MT-ID" and "IPA" fields.
</t> </t>
<t>
<t>
This document defines the following format and encoding for a Typed This document defines the following format and encoding for a Typed
Wildcard MP FEC element: Wildcard MP FEC Element:
</t> </t>
<figure anchor="mt-mp-wc-fec">
<figure title="Typed Wildcard MT MP FEC Element" anchor="mt-mp-wc-fec"> <name>Format for the Typed Wildcard MT MP FEC Element</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 ..| |Typed Wcard (5)| Type = MP FEC | Len = 6 | AF = MT IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... or MT IPv6 | Reserved | IPA | MT-ID | |... or MT IPv6 | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MT ID (contd.) | |MT-ID (cont.) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<t>Where:</t>
<t> Where: <dl>
<list style="empty"> <dt>Type:</dt><dd>One of the MP FEC element types (P2MP, MP2MP-up, or
<t> Type: One of MP FEC Element type (P2MP, MP2MPup, MP2MP-down). </t> MP2MP-down)</dd>
<t> MT ID: MPLS MT ID </t> <dt>MT-ID:</dt><dd>MPLS MT-ID</dd>
<t> IPA: The IGP Algorithm</t> <dt>IPA:</dt><dd>The IGP Algorithm</dd>
</list> </dl>
</t> <t>
The defined format allows a Label Switching Router (LSR) to perform wil
<t> dcard MP FEC
The defined format allows an LSR to perform wildcard MP FEC
operations under the scope of a (sub-)topology. operations under the scope of a (sub-)topology.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="End-of-LIB"> <name>End-of-LIB</name>
<t> <t>
<xref target="RFC5919"/> specifies extensions and procedures that allow <xref target="RFC5919" format="default"/> specifies extensions and
an LDP speaker procedures that allow an LDP speaker to signal its End-of-LIB (Label In
to signal its End-of-LIB for a given FEC type to a peer. By leveraging formation Base) for a
the End-of-LIB message, LDP ensures that label distribution remains given FEC type to a peer. By leveraging the End-of-LIB message, LDP
consistent and reliable, even during network disruptions or maintenance ensures that label distribution remains consistent and reliable,
activities. The MT extensions for MP FEC do not require any modifications even during network disruptions or maintenance activities. The MT
to these procedures and apply as-is to MT MP FEC elements. Consequently, an extensions for MP FEC do not require any modifications to these
MT mLDP speaker MAY signal its convergence per (sub-)topology using procedures and apply as they are to MT MP FEC elements. Consequently, a
the MT Typed Wildcard MP FEC element. n
MT mLDP speaker <bcp14>MAY</bcp14> signal its convergence per
</t> (sub-)topology using the MT Typed Wildcard MP FEC Element.
</t>
</section> </section>
</section> </section>
<section anchor="mt-fwd" numbered="true" toc="default">
<section title="Topology-Scoped Signaling and Forwarding" anchor="mt-fwd"> <name>Topology-Scoped Signaling and Forwarding</name>
<t> <t>
Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need to support 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 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 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 to have specific label forwarding tables per topology, and each MP
LSP will have its own unique local label in the table. However, In LSP will have its own unique local label in the table. However, in
order to implement MTR in an mLDP network, the selection procedures order to implement MTR in an mLDP network, the selection procedures
for upstream LSR and downstream forwarding interface need to be for an upstream LSR and a downstream forwarding interface need to be
changed. changed.
</t> </t>
<section numbered="true" toc="default">
<section title="Upstream LSR selection"> <name>Upstream LSR Selection</name>
<t> <t>
The procedures as described in RFC-6388 section-2.4.1.1 depend on The procedures described in <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 signale d as part the best path to reach the root. When the {MT-ID, IPA} tuple is signale d as part
of the FEC, this tuple is used to select the (sub-)topology that must b e of the FEC, the tuple is also used to select the (sub-)topology that mu st be
used to find the best path to the root address. Using the next-hop 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 from this best path, an LDP peer is selected following the procedures
as defined in <xref target="RFC6388"/>. defined in <xref target="RFC6388" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Downstream forwarding interface selection"> <name>Downstream Forwarding Interface Selection</name>
<t> <t>
The procedures as described in RFC-6388 section-2.4.1.2 describe how <xref target="RFC6388" sectionFormat="of" section="2.4.1.2"/> describes
the procedures for how
a downstream forwarding interface is selected. In these procedures, a downstream forwarding interface is selected. In these procedures,
any interface leading to the downstream LDP neighbor can be any interface leading to the downstream LDP neighbor can be
considered as candidate forwarding interface. When the {MT-ID, IPA} tup le is part considered 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 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 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 mLDP FEC element. Besides this restriction, the other procedures in
<xref target="RFC6388"/> apply. <xref target="RFC6388" format="default"/> apply.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="LSP Ping Extensions"> <name>LSP Ping Extensions</name>
<t> <t>
<xref target="RFC6425"/> defines procedures to detect data plane failures <xref target="RFC6425" format="default"/> defines procedures to detect da
in ta plane failures in
Multipoint MPLS LSPs. Section 3.1.2 of <xref target="RFC6425"/> defines n multipoint MPLS LSPs. <xref target="RFC6425" sectionFormat="of" section="
ew Sub- 3.1.2"/> defines new sub-types and sub-TLVs for Multipoint LDP FECs to be sent i
Types and Sub-TLVs for Multipoint LDP FECs to be sent in "Target FEC n the "Target FEC
Stack" TLV of an MPLS echo request message <xref target="RFC8029"/>. Stack" TLV of an MPLS Echo Request message <xref target="RFC8029" format=
"default"/>.
</t> </t>
<t> <t>
To support LSP ping for MT Multipoint LSPs, this document uses To support LSP ping for MT MP LSPs, this document uses
existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack" existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack"
defined in <xref target="RFC6425"/>. The LSP Ping extension is to specify "MT IP" defined in <xref target="RFC6425" format="default"/>. The LSP ping extens ion is to specify "MT IP"
or "MT IPv6" in the "Address Family" field, set the "Address Length" 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 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 with additional {MT-ID, IPA} information as an extension to the "Root LSR
Address" field. The resultant format of sub-tlv is as follows: Address" field. The resultant format of sub-TLV is as follows:
</t> </t>
<figure title="Multipoint LDP FEC Stack Sub-TLV Format for MT" anchor="mt- <figure anchor="mt-fec-lspv">
fec-lspv"> <name>Multipoint LDP FEC Stack Sub-TLV Format for MT</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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| | |Address Family (MT IP/MT IPv6) | Address Length| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Root LSR Address (Cont.) ~ ~ Root LSR Address (Cont.) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID | | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... | | Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The rules and procedures of using this new sub-TLV in an MPLS echo The rules and procedures of using this new sub-TLV in an MPLS Echo
request Request message are the same as defined for the P2MP/MP2MP LDP FEC Stack
message are the same as defined for P2MP/MP2MP LDP FEC Stack Sub-TLV in <xref ta sub-TLV in <xref target="RFC6425" format="default"/>. The only
rget="RFC6425"/>. The only difference is that the Root LSR address is now difference is that the "Root LSR Address" field is now (sub-)topology sco
(sub-)topology scoped. ped.
</t> </t>
</section> </section>
<section title="Implementation Status"> <section numbered="true" toc="default">
<t> <name>Security Considerations</name>
[Note to the RFC Editor - remove this section before publication, as well as rem
ove 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 bas
ed on a proposal described in
<xref target="RFC7942"/>
. The description of implementations in this section is intended to assist the I
ETF in its decision processes in progressing drafts to RFCs. Please note that th
e listing of any individual implementation here does not imply endorsement by th
e IETF. Furthermore, no effort has been spent to verify the information presente
d 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 feature
s. 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 d
ocuments that have the benefit of running code, which may serve as evidence of v
aluable experimentation and feedback that have made the implemented protocols mo
re 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 assign
s 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">
<t> <t>
This extension to mLDP does not introduce any new security This extension to mLDP does not introduce any new security
considerations beyond that already applied to the base LDP considerations beyond what is already applied to the base LDP
specification <xref target="RFC5036"/>, LDP extensions for Multi-Topology specification <xref target="RFC5036" format="default"/>, the LDP
specification <xref target="RFC7307"/> base mLDP specification <xref target="RF extensions for Multi-Topology specification <xref target="RFC7307"
C6388"/>, and MPLS format="default"/>, the base mLDP specification <xref target="RFC6388"
security framework <xref target="RFC5920"/>. format="default"/>, and the MPLS security framework specification <xref t
arget="RFC5920"
format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<t>
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.
</t>
<figure title="IANA Code Point" anchor="iana">
<artwork>
+-----+------------------+---------------+-------------------------+
|Value| Description | Reference | Notes/Registration Date |
+-----+------------------+---------------+-------------------------+
| TBA | MT Multipoint | This document | |
| | Capability | | |
+-----+------------------+---------------+-------------------------+
</artwork>
</figure>
</section>
<section title="Contributor">
<t>
Anuj Budhiraja
Cisco systems
</t>
</section>
<section title="Acknowledgments">
<t> <t>
The authors would like to acknowledge Eric Rosen for his input on This document defines a new LDP capability parameter TLV called the "MT M
this specification. ultipoint Capability". IANA has assigned the value 0x0510 from the
"TLV Type Name Space" registry in the "Label Distribution Protocol (LDP)
Parameters" group as the new code point.
</t> </t>
</section>
<table anchor="iana">
<name>MT Multipoint 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> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
915.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
120.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
307.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
388.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
029.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
425.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
350.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
514.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
513.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
036.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
918.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
919.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
920.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
561.xml"/>
<references title="Normative References"> <reference anchor="IANA-IGP-ALGO-TYPES" target="https://www.iana.org/ass
&rfc2119; ignments/igp-parameters">
<?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.xh
tml#igp-algorithm-types">
<front> <front>
<title>IGP Algorithm Types</title> <title>IGP Algorithm Types</title>
<author/> <author>
<date/> <organization>IANA</organization>
</front> </author>
</front>
</reference> </reference>
</references>
</references> </references>
</back> <section numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Anuj Budhiraja">
<organization>Cisco Systems</organization></contact>
</section>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The authors would like to acknowledge <contact fullname="Eric Rosen"/> fo
r his input on
this specification.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 105 change blocks. 
569 lines changed or deleted 523 lines changed or added

This html diff was produced by rfcdiff 1.48.