<?xmlversion="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 rfcSYSTEM "rfc2629.dtd"[ <!ENTITYrfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <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-TopologymLDP">mLDPmLDP">Multipoint LDP Extensions for Multi-Topology Routing</title> <!-- [rfced] Please note that the title of the document has been updated as follows: Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review. Original: mLDP Extensions for Multi-Topology Routing Current: Multipoint LDP Extensions for Multi-Topology Routing --> <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> <authorinitials='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> <!--[rfced] Arkadiy: is it okay to abbreviate your affiliation in the header (the full organization title would appear in the Authors' Addresses section)? It looks like this was handled differently in RFCs 9272 and 9350, and with the capping scheme used, we wondered if this suggestion would fit your intent? Original: A. Gulko Edward Jones wealth management Current: A. Gulko Edward Jones --> <author initials="A." surname="Gulko" fullname="Arkadiy Gulko"><organization>Edward<organization abbrev="Edward Jones">Edward Joneswealth 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> <dateday="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> <!--[rfced] Regarding the following text (from the Abstract and Intro, respectively): Original: Flexible Algorithm (FA) is another mechanism of creating a sub-topology within a topology using defined topology constraints and computation algorithm. and FA can be seen as creating a sub-topology within a topology using defined topology constraints and computation algorithms. a) We will update to use the definite article "the" before FA. Please let us know any objections. b) Is it redundant use of "topology" to say (paraphrasing): creating a sub-topology within a topology using topology constraints? Maybe this could be rephrased? c) Should the document be updated to use the same sentence in both of these places? --> <!--[rfced] We had a few questions regarding the following text (please read them all before taking action): Original: This document specifies extensions to mLDP to support MTR, with an algorithm, in order for Mulipoint LSPs(Label Switched Paths) to follow a particular topology and algorithm. a) The placement of "with an algorithm" might cause the reader pause. Can this sentence be rephrased? b) Is it redundant to "support with an algorithm" and later "to follow an algorithm"? Again, perhaps a rephrase? c) There is a similar sentence in the Introduction. Should this text (and any other that is repeated between Abstract and Intro) be made more uniform? Current: This document specifies extensions to mLDP to support the use of MTR/IPA such that when building multipoint LSPs, it can follow a particular topology and algorithm. --> <t> Multi-Topology Routing (MTR) is a technologyto enablethat enables service differentiation within an IP network. Flexible Algorithm (FA) is another mechanismoffor creating a sub-topology within a topology using defined topology constraints and computationalgorithm.algorithms. In order to deploymLDP (Multipoint label distribution protocol)Multipoint LDP (mLDP) in a network that supports MTR, FA, or other methods of signaling non-default IGPalgorithms,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 forMultipoint LSPs(Labelmultipoint LSPs (Label Switched Paths) to follow a particular topology and algorithm. It updates<xref target="RFC7307"/>RFC 7307 by allocating eight bits from a previously reserved field to be used as theIGP Algorithm (IPA)IPA field. </t> </abstract> </front> <middle> <sectiontitle="Glossary"> <t> <list style="empty"> <t> FA - Flexible Algorithm </t> <t> FEC - Forwarding Equivalence Class </t>numbered="true" toc="default"> <name>Introduction</name> <t> <!--[rfced] Please consider clarifying the slash with "and", "or", or "and/or" for the ease of the reader in the following sentences: Original: To support MTR, an IGP- Interior Gateway Protocol </t> <t> IPA -maintains independent IP topologies, termed as "Multi- Topologies" (MT), and computes/installs routes per topology. --> <!--[rfced] How does this parenthetical relate to the sentence? Are these examples? The only ones? Original: IGPAlgorithm </t> <t>protocols (OSPF and IS-IS) and LDP- Label Distribution Protocol </t> <t> LSP - Label Switched Path </t> <t> mLDP - Multipointhave already been extended to support MTR. Perhaps: IGPs (e.g., OSPF and IS-IS) and 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>have already been extended to support MTR. Perhaps: IGPs (i.e., OSPF and IS-IS) and LDP have already been extended to support MTR. Perhaps: OSPF, IS-IS, and LDP have already been extended to support MTR. --> Multi-Topology Routing (MTR) is a technologyto enablethat enables service differentiation within an IP network. IGP protocols (OSPF and IS-IS) and LDP have already been extended to support MTR. To support MTR, an IGP maintains independent IP topologies,termed ascalled "Multi-Topologies"(MT),(or "MTs"), and computes/installs routes per topology. OSPF extensions (see <xreftarget="RFC4915"/>target="RFC4915" format="default"/>) and IS-IS extensions (see <xreftarget="RFC5120"/>target="RFC5120" format="default"/>) specify the MT extensions under respective IGPs. To support IGP MT, similar LDP extensions (see <xreftarget="RFC7307"/>target="RFC7307" format="default"/>) have been specified to make LDPMT-awarebe MT aware and to be able tosetupset 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 <xreftarget="RFC9350"/>.target="RFC9350" format="default"/>). The FA can be seen as creating a sub-topology within a topology using defined topology constraints and computation algorithms. This can be done within an MTR topology or the defaultTopology.topology. An instance of such a sub-topology is identified by a1 octet1-octet value (Flex-Algorithm) as documented in <xreftarget="RFC9350"/>. A flexible Algorithmtarget="RFC9350" format="default"/>. At the time of writing, an FA is a mechanism to create asub- topology, butsub-topology; in the future, different algorithms might be defined forhow to achieve that. For that reason,this purpose. Therefore, in the remainder of this document, we'll refer to this as theIGP Algorithm."IGP Algorithm" or "IPA". TheIGP Algorithm (IPA) FieldIPA field (see Sections <xreftarget="MT_IP_AFI"/>target="MT_IP_AFI" format="counter"/> and <xreftarget="Typed_Wildcard_Fec"/>target="Typed_Wildcard_Fec" format="counter"/>) is an 8-bit identifier for the algorithm. The permissible values are tracked in theIANA IGP"IGP AlgorithmTypesTypes" registry <xreftarget="IANA-IGP-ALGO-TYPES"/>.target="IANA-IGP-ALGO-TYPES" format="default"/>. </t> <t> Throughout this document, the termFlexible Algorithm (FA)"Flexible Algorithm" (or "FA") shall denote the process of generating a sub-topology and signaling it throughInterior Gateway Protocol (IGP).the IGP. However, it is essential to note that the procedures outlined in this document are not exclusively applicable toFlexible Algorithm butthe FA: they are extendable to any non-default algorithm as well. </t> <t> <!--[rfced] We had a few questions regarding the following text: a) We see sentences that are similar in the Abstract and Intro. May we update both to the suggested text below (note - the abstract would have any first use abbreviations expanded)? Original 1 (from the Abstract): This document specifies extensions to mLDP to support MTR, with an algorithm, in order for MultipointLDP (mLDP)LSPs(Label Switched Paths) to follow a particular topology and algorithm. Original 2 (from the Intro): This document specifies extensions to mLDP to support MTR/IGP Algorithm such that when building a Multi-Point LSPs it can follow a particular topology and algorithm. Perhaps: This document specifies extensions to mLDP to support MTR and the IPA so that Multipoint LSPs can follow a particular topology and algorithm. b) Depending on the answer to the query above (this may become moot): In the following, to what does "it" refer? Please note that we have made other edits to this text already. Original: This document specifies extensions to mLDP to support MTR/IGP Algorithm such that when building a Multi-Point LSPs, it can follow a particular topology and algorithm. Current: This document specifies extensions to mLDP to support the use of MTR/IPA such that when building multipoint LSPs, it can follow a particular topology and algorithm. --> "Multipoint LDP" (or "mLDP") refers to extensions in LDP tosetup multi-pointset 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 <xreftarget="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 supportMTR/IGP Algorithmthe use of MTR/IPA such that when buildinga Multi-Point LSPsmultipoint LSPs, it can follow a particular topology and algorithm.This means thatTherefore, the identifier for the particular topology to be used by mLDPhavehas to become a 2-tuple(MTR{MTR Topology Id,IGP Algorithm).IPA}. </t> </section> <sectiontitle="Specificationnumbered="true" toc="default"> <!--[rfced] In the list of abbreviations, we see some citations as pointers to more information (for 2 entries). Would you like to add citations for other items in the list (e.g., FA [RFC9350])? Or would you like to remove the citations as they are used when the abbreviation is introduced in the body of the document? --> <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 ofRequirements">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 inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section> <sectiontitle="MT Scopednumbered="true" toc="default"> <name>MT-Scoped mLDPFECs">FECs</name> <t> <!--[rfced] In the following text, it seems like "in order to" and "so that" make this sentence tough to get through. May we update as follows for the ease of the reader? Original: In order to avoid conflicting MTR policies for the same mLDP FEC, the MT-ID needs to be a part of the FEC, so that different MT-ID values will result in unique MP-LSP FEC elements. Perhaps: In order to avoid conflicting MTR policies for the same mLDP FEC, the 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. --> As defined in <xreftarget="RFC7307"/>,target="RFC7307" format="default"/>, an MPLS Multi-Topology Identifier (MT-ID) isan identifier that isused to associate an LSP with a certain MTR topology. In the context of MP LSPs, this identifier is part of the mLDP FECencodingencoding; this is so that LDP peers are able tosetupset 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 theFEC,FEC so that different MT-ID values will result in uniqueMP-LSPMP LSP FEC elements. </t> <t> The same applies to theIGP Algorithm.IPA. TheIGP AlgorithmIPA needs to be encoded as part of the mLDP FEC to create uniqueMP-LSPs.MP LSPs. TheIGP AlgorithmIPA is also used to signal to the mLDP (hop-by-hop) whichAlgorithmalgorithm needs to be used to create theMP-LSP.MP LSP. </t> <t> Since the MT-ID andIGP AlgorithmIPA are part of the FEC, they apply to all the LDP messages that potentially include an mLDP FEC element. </t> <sectiontitle="MPanchor="mp-fec-ext-mt" numbered="true" toc="default"> <name>MP FEC Extensions forMT" 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 <xreftarget="RFC7307"/>.target="RFC7307" format="default"/>. </t> <sectiontitle="MPnumbered="true" toc="default"> <name>MP FECElement">Element</name> <t>BaseThe base mLDP specification<xref target="RFC6388"/>(<xref target="RFC6388" format="default"/>) defines the MP FEC Element as follows: </t> <figuretitle="MPanchor="mp-fec"> <name>MP FEC ElementFormat [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="MTnumbered="true" toc="default"> <name>MT IP AddressFamilies">Families</name> <t> <xreftarget="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 field that was described in RFC 7307 are utilized to encode theIGP Algorithm.IPA. The resulting format of the data associated with these newAddress Familiesaddress families is as follows: </t> <figuretitle="Modifiedanchor="mt-afi"> <name>Modified Data Format for MT IP AddressFamilies 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" addressfamilies respectively. </t> <t> IPA: Thefamilies, respectively.</dd> <dt>IPA:</dt> <dd>The IGPAlgorithm.</t> <t> Reserved: ThisAlgorithm.</dd> <dt>Reserved:</dt> <dd>This 8-bit fieldMUST<bcp14>MUST</bcp14> be zero on transmission andMUST<bcp14>MUST</bcp14> be ignored onreceipt. </t> </list> </t>receipt.</dd> </dl> </section> <sectiontitle="MTnumbered="true" toc="default"> <!--[rfced] Should this update be made to the text introducing Figure 3 to more closely match the title of the figure? Original: By using the extended MT IP Address Family, the resulting MT MP FECElement"> <t> Byelement should be encoded as follows: Perhaps: When using the extended MT IP Address Family, the resulting MT-Scoped MP FEC element should be encoded as follows: --> <name>MT MP FEC Element</name> <t> When using the extended "MT IP" address family, the resulting MT MP FEC element should be encoded as follows: </t> <figuretitle="IPanchor="mt-mp-fec"> <name>Data Format for an IP MT-Scoped MP FECElement 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 (<xreftarget="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 (type0x7) </t> <t> MP2MP-down0x6)</t> </li> <li> <t>MP2MP-up (type0x8) </t> </list> </t> <t> Typed0x7)</t> </li> <li> <t>MP2MP-down (type 0x8)</t> </li> </ul> </li> <li> <t>Typed Wildcard FEC Element (type 0x5 defined in <xreftarget="RFC5918"/> ) </t> </list> </t>target="RFC5918" format="default"/>)</t> </li> </ul> <t> In the case of"Typedthe Typed Wildcard FECElement",Element, the FEC Element typeMUST<bcp14>MUST</bcp14> be one of the MP FECs listed above. </t> <t> This specification allows the use ofTopology-scopedtopology-scoped mLDP FECs in LDPlabellabels and notification messages, as applicable. </t> <t> <xreftarget="RFC6514"/>target="RFC6514" format="default"/> defines the PMSI tunnel attribute forMVPN,MVPN and specifiesthat whenthat:</t> <ul> <li>when the Tunnel Type is set to mLDP P2MP LSP, the Tunnel Identifier is a P2MP FEC Element,and whenand</li> <li>when the Tunnel Type is set to mLDPMultipoint-to-Multipoint (MP2MP)MP2MP LSP, the Tunnel Identifier is an MP2MP FECElement.Element.</li></ul> <t> When the extension defined in this specification is in use, the"IPIP MT-Scoped MP FEC ElementFormat"form of the respective FEC elementsMUST<bcp14>MUST</bcp14> be used in these two cases. </t> </section> </section> <sectiontitle="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 <xreftarget="RFC7307"/> specification.target="RFC7307" format="default"/>. </t> </section> </section> <sectiontitle="MTnumbered="true" toc="default"> <name>MT MultipointCapability">Capability</name> <t> The "MT Multipoint Capability" is a new LDP capability, defined in accordance with the LDP Capability definition guidelines outlined in <xreftarget="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 capabilityMAY<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 <xreftarget="RFC5561"/>target="RFC5561" format="default"/> has been successfully negotiated with the peer. </t> <t> The format of this capability is as follows: </t> <figuretitle="MTanchor="mt-mp-cap"> <name>Data Format for the MT Multipoint CapabilityTLV 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:<!--[rfced] The description of Figure 4 contains two entries for "Length". May we update as suggested below? Original: Length: The length (in octets) of TLV. The value of this field MUST be 1 as there is no Capability-specific data [RFC5561] that follows in the TLV. Length: This field specifies the length of the TLV in octets. The value of this field MUST be 1, as there is no Capability-specific data [[RFC5561]] [RFC5561] following the TLV. Perhaps: Length: This field specifies the length of the TLV in octets. The value of this field MUST be 1, as there is no Capability-specific data [RFC5561] following the TLV. --> <t>Where:</t> <dl> <dt>U and F bits:</dt> <dd><bcp14>MUST</bcp14> be 1 and 0, respectively, as perSection 3 of LDP Capabilities<xreftarget="RFC5561"/>. </t> <t> MTtarget="RFC5561" sectionFormat="of" section="3"/>.</dd> <dt>MT MultipointCapability:Capability:</dt> <dd>The TLVtype. </t> <t> Length: Thetype.</dd> <dt>Length:</dt> <dd>The length (in octets) of the TLV. The value of this fieldMUST<bcp14>MUST</bcp14> be 1 as there is no Capability-specific data <xreftarget="RFC5561"/>target="RFC5561" format="default"/> that follows in theTLV. Length: ThisTLV.</dd> <dt>Length:</dt><dd>This field specifies the length of the TLV in octets. The value of this fieldMUST<bcp14>MUST</bcp14> be 1, as there is no Capability-specific data[<xref target="RFC5561"/>]<xref target="RFC5561" format="default"/> following theTLV. </t> <t> S-bit: SetTLV.</dd> <dt>S bit:</dt> <dd>Set to 1 to announce and 0 to withdraw the capability (as per <xreftarget="RFC5561"/>. </t> </list> </t>target="RFC5561" format="default"/>).</dd> </dl> <t> An mLDP speaker that has successfully advertised and negotiated the "MT Multipoint" capabilityMUST<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 (<xreftarget="mp-fec-ext-mt"/>) </t> <t> Topology-scopedtarget="mp-fec-ext-mt" format="default"/>)</t> </li> <li> <t>Topology-scoped mLDP forwarding setup (<xreftarget="mt-fwd"/>) </t> </list> </t>target="mt-fwd" format="default"/>)</t> </li> </ol> </section> <sectiontitle="MTnumbered="true" toc="default"> <name>MT Applicability onFEC-based features">FEC-Based Features</name> <section anchor="Typed_Wildcard_Fec"title="Typednumbered="true" toc="default"> <name>Typed Wildcard MP FECElements">Elements</name> <t> <xreftarget="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><!--[rfced] May we update the use of "defined in this document" to clarify the subject of this sentence? Original: The MT extensions, defined in this document, do not require any extension to procedures for Typed Wildcard FEC Element support [RFC5918],... Perhaps A (there may be other MT extensions outside the doc that are not included): The MT extensions defined in this document do not require any extension to procedures for Typed Wildcard FEC Element support [RFC5918],... Perhaps B (this document addresses all existing MT extensions): MT extensions, which are defined in this document, do not require any extension to procedures for Typed Wildcard FEC Element support [RFC5918],... --> <t> The MT extensions defined in this document do not require any extension to procedures for support of the Typed Wildcard FEC Element <xreftarget="RFC5918"/>,target="RFC5918" format="default"/>, and these procedures applyas-isas is to Multipoint MT FEC wildcarding. Similar to the Typed Wildcard MT Prefix FEC Element, as defined in <xreftarget="RFC7307"/>,target="RFC7307" format="default"/>, the MT extensions allow the use of "MT IP" or "MT IPv6" in theAddress Family"Address Family" field of the Typed Wildcard MP FEC element. This is done in order to use wildcard operations for MP FECs in the context of a given(sub)-topology(sub-)topology as identified by the MT-ID and IPAfield.fields. </t> <t> This document defines the following format and encoding for a Typed Wildcard MP FEC element: </t> <figuretitle="Typedanchor="mt-mp-wc-fec"> <name>Data Format for the Typed Wildcard MT MP FECElement" 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 Elementtypetypes (P2MP,MP2MPup, MP2MP-down). </t> <t> MT ID: MPLS MT ID </t> <t> IPA: TheMP2MP-up, or MP2MP-down)</dd> <dt>MT-ID:</dt><dd>MPLS MT-ID</dd> <dt>IPA:</dt><dd>The IGPAlgorithm</t> </list> </t>Algorithm</dd> </dl> <t> The defined format allowsan LSRa Label Switching Router (LSR) to perform wildcard MP FEC operations under the scope of a (sub-)topology. </t> </section> <sectiontitle="End-of-LIB">numbered="true" toc="default"> <name>End-of-LIB</name> <t> <xreftarget="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 applyas-isas they are to MT MP FEC elements. Consequently, an MT mLDP speakerMAY<bcp14>MAY</bcp14> signal its convergence per (sub-)topology using the MT Typed Wildcard MP FEC element. </t> </section> </section> <sectiontitle="Topology-Scopedanchor="mt-fwd" numbered="true" toc="default"> <name>Topology-Scoped Signaling andForwarding" 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,Inin 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> <sectiontitle="Upstreamnumbered="true" toc="default"> <name>Upstream LSRselection">Selection</name> <t> The proceduresasdescribed inRFC-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,thisthe 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,aan LDP peer is selected following the proceduresasdefined in <xreftarget="RFC6388"/>.target="RFC6388" format="default"/>. </t> </section> <sectiontitle="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 proceduresas described in RFC-6388 section-2.4.1.2 describefor how a downstream forwarding interface is selected. In these procedures, any interface leading to the downstream LDP neighbor can be consideredasto 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 <xreftarget="RFC6388"/>target="RFC6388" format="default"/> apply. </t> </section> </section> <sectiontitle="LSPnumbered="true" toc="default"> <name>LSP PingExtensions">Extensions</name> <t> <xreftarget="RFC6425"/>target="RFC6425" format="default"/> defines procedures to detect data plane failures inMultipointmultipoint MPLS LSPs.Section 3.1.2 of<xreftarget="RFC6425"/>target="RFC6425" sectionFormat="of" section="3.1.2"/> defines newSub- Typessub-types andSub-TLVssub-TLVs for Multipoint LDP FECs to be sent in the "Target FEC Stack" TLV of an MPLS echo request message <xreftarget="RFC8029"/>.target="RFC8029" format="default"/>. </t> <t> To support LSP ping for MTMultipointMP LSPs, this document uses existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack" defined in <xreftarget="RFC6425"/>.target="RFC6425" format="default"/>. The LSPPingping 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 ofsub-tlvsub-TLV is as follows: </t> <figuretitle="Multipointanchor="mt-fec-lspv"> <name>Multipoint LDP FEC Stack Sub-TLV Format forMT" 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 message are the same as defined for the P2MP/MP2MP LDP FEC StackSub-TLVsub-TLV in <xreftarget="RFC6425"/>.target="RFC6425" format="default"/>. The only difference is that theRoot"Root LSRaddressAddress" field is now (sub-)topology scoped. </t> </section> <sectiontitle="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 beyondthatwhat is already applied to the base LDP specification <xreftarget="RFC5036"/>,target="RFC5036" format="default"/>, the LDP extensions for Multi-Topology specification <xreftarget="RFC7307"/>target="RFC7307" format="default"/>, the base mLDP specification <xreftarget="RFC6388"/>,target="RFC6388" format="default"/>, and the MPLS security framework specification <xreftarget="RFC5920"/>.target="RFC5920" format="default"/>. </t> </section> <sectiontitle="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t> This document defines a new LDP capability parameterTLV.TLV called the "MT Multipoint Capability". IANAis requested to assignhas assigned thelowest availablevalueafter 0x05000x0510 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 codepoint for the LDP TLV codepoint. </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> <sectiontitle="Contributor"> <t> Anuj Budhiraja Cisco systems </t>numbered="false" toc="default"> <name>Contributors</name> <contact fullname="Anuj Budhiraja"> <organization>Cisco Systems</organization></contact> </section> <sectiontitle="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgments</name> <t> The authors would like to acknowledgeEric 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. iii) "IGP protocols": could we just make this "IGPs" as used elsewhere in the document? Original: IGP protocols (OSPF and IS-IS) and LDP have already been extended to support MTR. b) We have expanded these abbreviations as follows. Please let us know any objections and/or if you would like to add these abbreviations to the list of abbreviations in the Terminology section. LIB - Label Information Base LSR - Label Switching Router c) After its introduction, we have switched to using IPA in lieu of IGP AlgorithmTypes</title> <author/> <date/> </front> </reference> </references>to match the guidance at https://www.rfc-editor.org/styleguide/part2/#exp_abbrev. Please let us know any objections. --> <!-- [rfced] We had the following questions related to terminology use throughout the document. a) We have updated to use the form on the right. Please review and let us know any objections. Multipoint LSP vs. multipoint LSP Algorithm vs. algorithm (when written without a name) LSP Ping extension vs. LSP ping extension Sub-TLV and sub-tlv vs. sub-TLV Sub-Type vs. sub-type MP-LSP vs. MP LSP MT Multipoint vs. MT MP b) We *will* update to use the form on the right for the following, unless we hear objection. MPLS echo request message vs. MPLS Echo Request message (to match Initialization and Capability message) 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 d) We have removed hyphenation from bit names for consistency within the document and the series. Please let us know any objections. e) Please review our work on the term "Address Family". We tried to use initial caps and double quotes followed by field when we thought the direct field name was being used and lowercase without quotes when referring to the general concept. Please review our updates to ensure we've retained your intended meaning. In general, may we follow this pattern for all field names? "Field Name" field This would prompt changes to the version on the right (for some examples): IGP Algorithm (IPA) Field or IPA field becomes "IPA" field Reserved field becomes "Reserved" field f) In general, how should capability names appear? Please review for capitalization of the word "capability" as well as quotation. We see: "MT Multipoint Capability" LDP Capability vs. LDP capability "Dynamic Announcement" capability --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </back> </rfc>