Diff: rfc8919xml2.original.xml

	rfc8919xml2.original.xml	rfc8919.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version="1.0" encoding="utf-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
	<?rfc toc="yes"?>	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<?rfc tocompact="yes"?>
	<?rfc tocdepth="3"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
	<?rfc tocindent="yes"?>	category="std" consensus="true" docName="draft-ietf-isis-te-app-19"
	<?rfc symrefs="yes"?>	number="8919" ipr="trust200902" updates="" obsoletes="" xml:lang="en"
	<?rfc sortrefs="yes"?>	tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true"
	<?rfc comments="yes"?>	version="3">
	<?rfc inline="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc category="std" docName="draft-ietf-isis-te-app-19" ipr="trust200902"
	updates="">
	<front>	<front>

	<title abbrev="draft-ietf-isis-te-app">IS-IS Application-Specific Link
	Attributes</title>


		<title abbrev="IS-IS App-Specific Link Attributes">IS-IS Application-Specifi
		c Link
		Attributes</title>
		<seriesInfo name="RFC" value="8919"/>
	<author fullname="Les Ginsberg" initials="L" surname="Ginsberg">	<author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</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>United States of America</country>
	<country>USA</country>
	</postal>	</postal>


	<email>ginsberg@cisco.com</email>	<email>ginsberg@cisco.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Peter Psenak" initials="P" surname="Psenak">	<author fullname="Peter Psenak" initials="P" surname="Psenak">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>


	<address>	<address>
	<postal>	<postal>

	<street>Apollo Business Center Mlynske nivy 43</street>	<extaddr>Apollo Business Center</extaddr>
		<street>Mlynske nivy 43</street>
	<city>Bratislava</city>	<city>Bratislava</city>


	<code>821 09</code>	<code>821 09</code>


	<country>Slovakia</country>	<country>Slovakia</country>
	</postal>	</postal>


	<email>ppsenak@cisco.com</email>	<email>ppsenak@cisco.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Stefano Previdi" initials="S" surname="Previdi">	<author fullname="Stefano Previdi" initials="S" surname="Previdi">

	<organization>Huawei</organization>	<organization>Huawei Technologies</organization>

	<address>	<address>
	<postal>	<postal>
	<street/>	<street/>


	<country/>	<country/>
	</postal>	</postal>


	<email>stefano@previdi.net</email>	<email>stefano@previdi.net</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Wim Henderickx" initials="W" surname="Henderickx">	<author fullname="Wim Henderickx" initials="W" surname="Henderickx">
	<organization>Nokia</organization>	<organization>Nokia</organization>


	<address>	<address>
	<postal>	<postal>
	<street>Copernicuslaan 50</street>	<street>Copernicuslaan 50</street>


	<city>Antwerp</city>	<city>Antwerp</city>


	<code>2018 94089</code>	<code>2018 94089</code>


	<country>Belgium</country>	<country>Belgium</country>
	</postal>	</postal>


	<email>wim.henderickx@nokia.com</email>	<email>wim.henderickx@nokia.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="John Drake" initials="J" surname="Drake">	<author fullname="John Drake" initials="J" surname="Drake">
	<organization>Juniper Networks</organization>	<organization>Juniper Networks</organization>


	<address>	<address>
	<postal>	<postal>
	<street/>	<street/>


	<code/>	<code/>


	<country/>	<country/>
	</postal>	</postal>


	<email>jdrake@juniper.net</email>	<email>jdrake@juniper.net</email>
	</address>	</address>
	</author>	</author>

		<date year="2020" month="October" />
	<date year="2020"/>

	<area>Routing Area</area>	<area>Routing Area</area>


	<workgroup>Networking Working Group</workgroup>	<workgroup>Networking Working Group</workgroup>


	<keyword/>

	<abstract>	<abstract>

	<t>Existing traffic engineering related link attribute advertisements
		<t>Existing traffic-engineering-related link attribute advertisements
	have been defined and are used in RSVP-TE deployments. Since the	have been defined and are used in RSVP-TE deployments. Since the
	original RSVP-TE use case was defined, additional applications (e.g.,	original RSVP-TE use case was defined, additional applications (e.g.,

	Segment Routing Policy, Loop Free Alternate) that also make use of the	Segment Routing Policy and Loop-Free Alternates) that also make use of the
	link attribute advertisements have been defined . In cases where	link attribute advertisements have been defined. In cases where
	multiple applications wish to make use of these link attributes, the	multiple applications wish to make use of these link attributes, the
	current advertisements do not support application-specific values for a	current advertisements do not support application-specific values for a
	given attribute, nor do they support indication of which applications	given attribute, nor do they support indication of which applications
	are using the advertised value for a given link. This document	are using the advertised value for a given link. This document
	introduces new link attribute advertisements that address both of these	introduces new link attribute advertisements that address both of these
	shortcomings.</t>	shortcomings.</t>
	</abstract>	</abstract>


	<note title="Requirements Language">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP 14
	[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as
	shown here.</t>
	</note>
	</front>	</front>


	<middle>	<middle>

	<section title="Introduction">	<section numbered="true" toc="default">
		<name>Introduction</name>
	<t>Advertisement of link attributes by the	<t>Advertisement of link attributes by the

	Intermediate-System-to-Intermediate-System (IS-IS) protocol in support	Intermediate System to Intermediate System (IS-IS) protocol in support
	of traffic engineering (TE) was introduced by [RFC5305] and extended by	of traffic engineering (TE) was introduced by <xref target="RFC5305" forma
	[RFC5307], [RFC6119], [RFC7308], and [RFC8570]. Use of these extensions	t="default"/> and extended by
		<xref target="RFC5307" format="default"/>, <xref target="RFC6119"
		format="default"/>, <xref target="RFC7308" format="default"/>, and <xref t
		arget="RFC8570"/>. Use of these extensions
	has been associated with deployments supporting Traffic Engineering over	has been associated with deployments supporting Traffic Engineering over
	Multiprotocol Label Switching (MPLS) in the presence of the Resource	Multiprotocol Label Switching (MPLS) in the presence of the Resource

	Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE	Reservation Protocol (RSVP), more succinctly referred to as RSVP-TE
	<xref target="RFC3209"/>.</t>	<xref target="RFC3209" format="default"/>.</t>
		<t>For the purposes of this document, an application is a technology that
	<t>For the purposes of this document an application is a technology that	makes use of link attribute advertisements, examples of which are
	makes use of link attribute advertisements - examples of which are	listed in <xref target="LEGADV" format="default"/>.</t>
	listed in <xref target="LEGADV"/>.</t>	<t>In recent years, new applications that have use cases for many of the

	<t>In recent years new applications that have use cases for many of the
	link attributes historically used by RSVP-TE have been introduced. Such	link attributes historically used by RSVP-TE have been introduced. Such

	applications include Segment Routing Policy (SR Policy) <xref	applications include Segment Routing (SR) Policy <xref target="I-D.ietf-sp
	target="I-D.ietf-spring-segment-routing-policy"/> and Loop Free	ring-segment-routing-policy" format="default"/> and Loop-Free
	Alternates (LFA) <xref target="RFC5286"/>. This has introduced ambiguity	Alternates (LFAs) <xref target="RFC5286" format="default"/>. This has intr
		oduced ambiguity
	in that if a deployment includes a mix of RSVP-TE support and SR Policy	in that if a deployment includes a mix of RSVP-TE support and SR Policy

	support (for example) it is not possible to unambiguously indicate which	support, for example, it is not possible to unambiguously indicate which
	advertisements are to be used by RSVP-TE and which advertisements are to	advertisements are to be used by RSVP-TE and which advertisements are to

	be used by SR Policy. If the topologies are fully congruent this may not	be used by SR Policy. If the topologies are fully congruent, this may not
	be an issue, but any incongruence leads to ambiguity.</t>	be an issue, but any incongruence leads to ambiguity.</t>

		<t>An example of where this ambiguity causes a problem is a network where
	<t>An example where this ambiguity causes a problem is a network where
	RSVP-TE is enabled only on a subset of its links. A link attribute is	RSVP-TE is enabled only on a subset of its links. A link attribute is

	advertised for the purpose of another application (e.g. SR Policy) for a	advertised for the purpose of another application (e.g., SR Policy) for a
	link that is not enabled for RSVP-TE. As soon as the router that is an	link that is not enabled for RSVP-TE. As soon as the router that is an

	RSVP-TE head-end sees the link attribute being advertised for that link,	RSVP-TE head end sees the link attribute being advertised for that link,
	it assumes RSVP-TE is enabled on that link, even though it is not. If	it assumes RSVP-TE is enabled on that link, even though it is not. If

	such RSVP-TE head-end router tries to setup an RSVP-TE path via that	such an RSVP-TE head-end router tries to set up an RSVP-TE path via that
	link, it will result in a path setup failure.</t>	link, it will result in a path setup failure.</t>


	<t>An additional issue arises in cases where both applications are	<t>An additional issue arises in cases where both applications are
	supported on a link but the link attribute values associated with each	supported on a link but the link attribute values associated with each
	application differ. Current advertisements do not support advertising	application differ. Current advertisements do not support advertising
	application-specific values for the same attribute on a specific	application-specific values for the same attribute on a specific
	link.</t>	link.</t>


	<t>This document defines extensions that address these issues. Also, as	<t>This document defines extensions that address these issues. Also, as
	evolution of use cases for link attributes can be expected to continue	evolution of use cases for link attributes can be expected to continue
	in the years to come, this document defines a solution that is easily	in the years to come, this document defines a solution that is easily
	extensible to the introduction of new applications and new use	extensible to the introduction of new applications and new use
	cases.</t>	cases.</t>


		<section anchor="req-lang" numbered="true">
		<name>Requirements Language</name>
		<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</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 "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
		</section>
	</section>	</section>


	<section anchor="REQDIS" title="Requirements Discussion">	<section anchor="REQDIS" numbered="true" toc="default">
		<name>Requirements Discussion</name>
	<t>As stated previously, evolution of use cases for link attributes can	<t>As stated previously, evolution of use cases for link attributes can
	be expected to continue. Therefore, any discussion of existing use cases	be expected to continue. Therefore, any discussion of existing use cases
	is limited to requirements that are known at the time of this writing.	is limited to requirements that are known at the time of this writing.
	However, in order to determine the functionality required beyond what	However, in order to determine the functionality required beyond what
	already exists in IS-IS, it is only necessary to discuss use cases that	already exists in IS-IS, it is only necessary to discuss use cases that
	justify the key points identified in the introduction, which are:</t>	justify the key points identified in the introduction, which are:</t>

		<ol spacing="normal" type="1">
		<li>Support for indicating which applications are using the link
		attribute advertisements on a link</li>
		<li>Support for advertising application-specific values for the same
		attribute on a link</li>
		</ol>


	<t><list style="numbers">	<t><xref target="RFC7855" format="default"/> discusses use cases and requi
	<t>Support for indicating which applications are using the link	rements for Segment Routing
	attribute advertisements on a link</t>	(SR). Included among these use cases is SR Policy, which is defined in
		<xref target="I-D.ietf-spring-segment-routing-policy" format="default"/>.
	<t>Support for advertising application-specific values for the same	If both RSVP-TE
	attribute on a link</t>
	</list>[RFC7855] discusses use cases/requirements for Segment Routing
	(SR). Included among these use cases is SR Policy which is defined in
	<xref target="I-D.ietf-spring-segment-routing-policy"/>. If both RSVP-TE
	and SR Policy are deployed in a network, link attribute advertisements	and SR Policy are deployed in a network, link attribute advertisements

	can be used by one or both of these applications. As there is no	can be used by one or both of these applications.
	requirement for the link attributes advertised on a given link used by
	SR Policy to be identical to the link attributes advertised on that same	There is no requirement for the link attributes advertised on a given link
	link used by RSVP-TE, there is a clear requirement to indicate	used by SR Policy to be identical to the link attributes advertised on that
	independently which link attribute advertisements are to be used by each	same link used by RSVP-TE; thus, there is a clear requirement to indicate
	application.</t>	independently which link attribute advertisements are to be used by each
		application.</t>

	<t>As the number of applications that may wish to utilize link	<t>As the number of applications that may wish to utilize link
	attributes may grow in the future, an additional requirement is that the	attributes may grow in the future, an additional requirement is that the
	extensions defined allow the association of additional applications to	extensions defined allow the association of additional applications to
	link attributes without altering the format of the advertisements or	link attributes without altering the format of the advertisements or

	introducing new backwards compatibility issues.</t>	introducing new backwards-compatibility issues.</t>

	<t>Finally, there may still be many cases where a single attribute value	<t>Finally, there may still be many cases where a single attribute value
	can be shared among multiple applications, so the solution must minimize	can be shared among multiple applications, so the solution must minimize
	advertising duplicate link/attribute pairs whenever possible.</t>	advertising duplicate link/attribute pairs whenever possible.</t>
	</section>	</section>

		<section anchor="LEGADV" numbered="true" toc="default">
	<section anchor="LEGADV" title="Legacy Advertisements">	<name>Legacy Advertisements</name>
	<t>There are existing advertisements used in support of RSVP-TE. These	<t>Existing advertisements used in support of RSVP-TE include sub-TLVs for
	advertisements include sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223	TLVs 22, 23, 25, 141, 222, and 223
	and TLVs for Shared Risk Link Group (SRLG) advertisement.</t>	and TLVs for Shared Risk Link Group (SRLG) advertisement.</t>

		<t>Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141,
		222, and 223" registry.</t>
		<t>TLVs are defined in the "TLV Codepoints Registry".</t>
		<section anchor="LEGSUB" numbered="true" toc="default">
		<name>Legacy Sub-TLVs</name>


	<t>Sub-TLV values are defined in the Sub-TLVs for TLVs 22, 23, 25, 141,	<table anchor="legacysub" align="left">
	222, and 223 registry.</t>	<name>Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223</name>
		<thead>
	<t>TLVs are defined in the TLV Codepoints Registry.</t>	<tr>
		<th> Type </th>
		<th> Description </th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td> 3 </td>
		<td> Administrative group (color) </td>
		</tr>
		<tr>
		<td> 9 </td>
		<td> Maximum link bandwidth</td>
		</tr>
		<tr>


	<section anchor="LEGSUB" title="Legacy sub-TLVs">	<td> 10 </td>
	<t><figure>	<td> Maximum reservable link bandwidth </td>
	<artwork><![CDATA[Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223	</tr>
		<tr>
		<td> 11 </td>
		<td> Unreserved bandwidth </td>
		</tr>
		<tr>
		<td> 14 </td>
		<td> Extended Administrative Group </td>
		</tr>
		<tr>
		<td> 18 </td>
		<td> TE Default Metric </td>
		</tr>
		<tr>
		<td> 33 </td>
		<td> Unidirectional Link Delay </td>
		</tr>
		<tr>
		<td> 34 </td>
		<td> Min/Max Unidirectional Link Delay </td>
		</tr>
		<tr>
		<td> 35 </td>
		<td> Unidirectional Delay Variation </td>
		</tr>
		<tr>
		<td> 36 </td>
		<td> Unidirectional Link Loss </td>
		</tr>
		<tr>


	+-------------------------------------------+	<td> 37 </td>
	\| Type \| Description \|	<td> Unidirectional Residual Bandwidth </td>
	+-------------------------------------------+	</tr>
	\| 3 \| Administrative group (color) \|	<tr>
	+-------------------------------------------+	<td> 38 </td>
	\| 9 \| Maximum link bandwidth \|	<td> Unidirectional Available Bandwidth</td>
	+-------------------------------------------+	</tr>
	\| 10 \| Maximum reservable link bandwidth \|	<tr>
	+-------------------------------------------+	<td> 39 </td>
	\| 11 \| Unreserved bandwidth \|	<td> Unidirectional Utilized Bandwidth </td>
	+-------------------------------------------+	</tr>
	\| 14 \| Extended Administrative Group \|	</tbody>
	+-------------------------------------------+	</table>
	\| 18 \| TE Default Metric \|
	+-------------------------------------------+
	\| 33 \| Unidirectional Link Delay \|
	+-------------------------------------------+
	\| 34 \| Min/Max Unidirectional Link Delay \|
	+-------------------------------------------+
	\| 35 \| Unidirectional Delay Variation \|
	+-------------------------------------------+
	\| 36 \| Unidirectional Link Loss \|
	+-------------------------------------------+
	\| 37 \| Unidirectional Residual Bandwidth \|
	+-------------------------------------------+
	\| 38 \| Unidirectional Available Bandwidth \|
	+-------------------------------------------+
	\| 39 \| Unidirectional Utilized Bandwidth \|
	+-------------------------------------------+


	]]></artwork>
	</figure></t>
	</section>	</section>

		<section anchor="LEGSRLG" numbered="true" toc="default">


	<section anchor="LEGSRLG" title="Legacy SRLG Advertisements">	<name>Legacy SRLG Advertisements</name>
	<t><figure>
	<artwork><![CDATA[TLV 138 GMPLS-SRLG
	Supports links identified by IPv4 addresses and
	unnumbered links

	TLV 139 IPv6 SRLG
	Supports links identified by IPv6 addresses

	]]></artwork>
	</figure>Note that [RFC6119] prohibits the use of TLV 139 when it is
	possible to use TLV 138.</t>
	</section>
	</section>


	<section anchor="ASLA"	<dl newline="true">
	title="Advertising Application-Specific Link Attributes">	<dt>TLV 138 (GMPLS-SRLG):</dt>
	<t>Two new code points are defined in support of Application-Specific	<dd>Supports links identified by IPv4 addresses and
	Link Attribute (ASLA) Advertisements:</t>	unnumbered links.</dd>


	<t>1) ASLA sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 (defined in	<dt>TLV 139 (IPv6 SRLG):</dt>
	<xref target="ASLASUB"/> ).</t>	<dd> Supports links identified by IPv6 addresses.</dd>


	<t>2)Application-Specific Shared Risk Link Group (SRLG) TLV (defined in	</dl>
	<xref target="ASSRLGTLV"/>).</t>


	<t>In support of these new advertisements, an application identifier bit	<t>Note that <xref target="RFC6119" format="default"/> prohibits the
	mask is defined that identifies the application(s) associated with a	use of TLV 139 when it is possible to use TLV 138.</t>
	given advertisement (defined in <xref target="AIBM"/>).</t>	</section>
		</section>
		<section anchor="ASLA" numbered="true" toc="default">
		<name>Advertising Application-Specific Link Attributes</name>
		<t>Two new codepoints are defined to support Application-Specific
		Link Attribute (ASLA) advertisements:</t>
		<ol type="%d)">
		<li>Application-Specific Link Attributes sub-TLV for TLVs 22, 23, 25,
		141, 222, and 223 (defined in <xref target="ASLASUB"
		format="default"/>).</li>
		<li>Application-Specific Shared Risk Link Group (SRLG) TLV (defined in
		<xref target="ASSRLGTLV" format="default"/>).</li>
		</ol>


		<t>To support these new advertisements, an
		application identifier bit mask is defined to identify the application(s)
		associated with a given advertisement (defined in <xref target="AIBM"
		format="default"/>).</t>
	<t>In addition to supporting the advertisement of link attributes used	<t>In addition to supporting the advertisement of link attributes used
	by standardized applications, link attributes can also be advertised for	by standardized applications, link attributes can also be advertised for

	use by user defined applications. Such applications are not subject to	use by user-defined applications. Such applications are not subject to
	standardization and are outside the scope of this document.</t>	standardization and are outside the scope of this document.</t>


	<t>The following sections define the format of these new	<t>The following sections define the format of these new
	advertisements.</t>	advertisements.</t>

		<section anchor="AIBM" numbered="true" toc="default">
	<section anchor="AIBM" title="Application Identifier Bit Mask">	<name>Application Identifier Bit Mask</name>
	<t>Identification of the set of applications associated with link	<t>Identification of the set of applications associated with link
	attribute advertisements utilizes two bit masks. One bit mask is for	attribute advertisements utilizes two bit masks. One bit mask is for
	standard applications where the definition of each bit is defined in a	standard applications where the definition of each bit is defined in a

	new IANA controlled registry. A second bit mask is for non-standard	new IANA-controlled registry (see <xref target="IANA4"/>). A second
	User Defined Applications (UDAs).</t>	bit mask is for non-standard user-defined applications (UDAs).</t>

	<t>The encoding defined below is used by both the Application-Specific	<t>The encoding defined below is used by both the Application-Specific
	Link Attributes sub-TLV and the Application-Specific SRLG TLV.</t>	Link Attributes sub-TLV and the Application-Specific SRLG TLV.</t>


	<t><figure>	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork><![CDATA[ 0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+--+--+--+--+--+--+--+--+	+--+--+--+--+--+--+--+--+
	\| SABM Length + Flag \| 1 octet	\| SABM Length + Flag \| 1 octet
	+--+--+--+--+--+--+--+--+	+--+--+--+--+--+--+--+--+
	\| UDABM Length + Flag \| 1 octet	\| UDABM Length + Flag \| 1 octet
	+--+--+--+--+--+--+--+--+	+--+--+--+--+--+--+--+--+
	\| SABM ... 0 - 8 octets	\| SABM ... 0 - 8 octets
	+--+--+--+--+--+--+--+--+	+--+--+--+--+--+--+--+--+
	\| UDABM ... 0 - 8 octets	\| UDABM ... 0 - 8 octets
	+--+--+--+--+--+--+--+--+	+--+--+--+--+--+--+--+--+

		]]></artwork>


	SABM Length + Flag (1 octet)	<dl newline="false">
	Standard Application Identifier Bit Mask	<dt>SABM Length + Flag (1 octet):</dt>
	Length + Flag	<dd><t> Standard Application Identifier Bit Mask Length + Flag</t>


		<artwork>
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|L\| SABM Length \|	\|L\| SABM Length \|
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+

		</artwork>
		<dl>


	L-flag: Legacy Flag.	<dt>L-flag:</dt><dd>Legacy Flag.
	See Section 4.2 for a description of how	See <xref target="ASLASUB"/> for a description of how
	this flag is used.	this flag is used.</dd>

	SABM Length: Indicates the length in octets (0-8) of the
	Standard Application Identifier Bit Mask. The length SHOULD
	be the minimum required to send all bits that are set.


	UDABM Length + Flag (1 octet)	<dt>SABM Length:</dt><dd>Indicates the length in octets (0-8) of the
	User Defined Application Identifier Bit Mask	Standard Application Identifier Bit Mask. The length <bcp14>SHOULD</bcp14>
	Length + Flag	be the minimum required to send all bits that are set.</dd>
		</dl>
		</dd>


		<dt>UDABM Length + Flag (1 octet):</dt>
		<dd><t> User-Defined Application Identifier Bit Mask Length + Flag</t>
		<artwork>
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|R\| UDABM Length\|	\|R\| UDABM Length\|
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+

		</artwork>
		<dl>


	R: Reserved. SHOULD be transmitted as 0 and	<dt>R:</dt><dd> Reserved. <bcp14>SHOULD</bcp14> be transmitted as 0 and
	MUST be ignored on receipt	<bcp14>MUST</bcp14> be ignored on receipt.</dd>

	UDABM Length: Indicates the length in octets (0-8) of the
	User Defined Application Identifier Bit Mask. The length SHOULD
	be the minimum required to send all bits that are set.


	SABM (variable length)	<dt>UDABM Length:</dt><dd> Indicates the length in octets (0-8) of the
	Standard Application Identifier Bit Mask	User-Defined Application Identifier Bit Mask. The length <bcp14>SHOULD</bcp1
		4>
		be the minimum required to send all bits that are set.</dd>
		</dl>
		</dd>


	(SABM Length * 8) bits	<dt>SABM (variable length):</dt>
		<dd><t> Standard Application Identifier Bit Mask</t>


	This field is omitted if SABM Length is 0.	<t> (SABM Length * 8) bits</t>


		<t>This field is omitted if SABM Length is 0.</t>
		<artwork>
	0 1 2 3 4 5 6 7 ...	0 1 2 3 4 5 6 7 ...
	+-+-+-+-+-+-+-+-+...	+-+-+-+-+-+-+-+-+...
	\|R\|S\|F\| ...	\|R\|S\|F\| ...
	+-+-+-+-+-+-+-+-+...	+-+-+-+-+-+-+-+-+...

		</artwork>
		<dl>
		<dt> R-bit:</dt><dd>Set to specify RSVP-TE.</dd>


	R-bit: Set to specify RSVP-TE	<dt> S-bit:</dt><dd>Set to specify Segment Routing Policy.</dd>

	S-bit: Set to specify Segment Routing Policy

	F-bit: Set to specify Loop Free Alternate (LFA)
	(includes all LFA types)


	UDABM (variable length)	<dt> F-bit:</dt><dd>Set to specify Loop-Free Alternate (LFA)
	User Defined Application Identifier Bit Mask	(includes all LFA types).</dd>
		</dl>
		</dd>


	(UDABM Length * 8) bits	<dt>UDABM (variable length):</dt>
		<dd><t> User-Defined Application Identifier Bit Mask</t>


		<t>(UDABM Length * 8) bits</t>
		<artwork>
	0 1 2 3 4 5 6 7 ...	0 1 2 3 4 5 6 7 ...
	+-+-+-+-+-+-+-+-+...	+-+-+-+-+-+-+-+-+...
	\| ...	\| ...
	+-+-+-+-+-+-+-+-+...	+-+-+-+-+-+-+-+-+...

		</artwork>
	This field is omitted if UDABM Length is 0.	<t> This field is omitted if UDABM Length is 0.</t>
		</dd>
	]]></artwork>	</dl>
	</figure>NOTE: SABM/UDABM Length is arbitrarily limited to 8 octets	<aside>
	in order to insure that sufficient space is left to advertise link	<t>
	attributes without overrunning the maximum length of a sub-TLV.</t>	Note: SABM/UDABM Length is arbitrarily limited to 8 octets
		in order to ensure that sufficient space is left to advertise link
	<t>Standard Application Identifier Bits are defined/sent starting with	attributes without overrunning the maximum length of a sub-TLV.</t></asi
	Bit 0.</t>	de>
		<t>Standard Application Identifier Bits are defined and sent starting wi
	<t>User Defined Application Identifier Bits have no relationship to	th
		bit 0.</t>
		<t>User-Defined Application Identifier Bits have no relationship to
	Standard Application Identifier Bits and are not managed by IANA or	Standard Application Identifier Bits and are not managed by IANA or

	any other standards body. It is recommended that bits are used	any other standards body. It is recommended that bits be used
	starting with Bit 0 so as to minimize the number of octets required to	starting with bit 0 so as to minimize the number of octets required to
	advertise all UDAs.</t>	advertise all UDAs.</t>


	<t>In the case of both SABM and UDABM, the following rules apply:</t>	<t>For both SABM and UDABM, the following rules apply:</t>
		<ul spacing="normal">
	<t><list style="symbols">	<li>Undefined bits that are transmitted <bcp14>MUST</bcp14> be transmi
	<t>Undefined bits that are transmitted MUST be transmitted as 0	tted as 0
	and MUST be ignored on receipt</t>	and <bcp14>MUST</bcp14> be ignored on receipt.</li>
		<li>Bits that are not transmitted <bcp14>MUST</bcp14> be treated as if
	<t>Bits that are not transmitted MUST be treated as if they are	they are
	set to 0 on receipt.</t>	set to 0 on receipt.</li>
		<li>Bits that are not supported by an implementation <bcp14>MUST</bcp1
	<t>Bits that are not supported by an implementation MUST be	4> be
	ignored on receipt.</t>	ignored on receipt.</li>
	</list>.</t>	</ul>
	</section>	</section>

		<section anchor="ASLASUB" numbered="true" toc="default">
	<section anchor="ASLASUB"	<name>Application-Specific Link Attributes Sub-TLV</name>
	title="Application-Specific Link Attributes sub-TLV">
	<t>A new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 is defined	<t>A new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 is defined
	that supports specification of the applications and	that supports specification of the applications and
	application-specific attribute values.</t>	application-specific attribute values.</t>


	<t><figure>	<dl>
	<artwork><![CDATA[ Type: 16 (temporarily assigned by IANA)	<dt>Type:</dt><dd> 16</dd>
	Length: Variable (1 octet)	<dt>Length:</dt><dd> Variable (1 octet)</dd>
	Value:	<dt>Value:</dt>

	Application Identifier Bit Mask
	(as defined in Section 4.1)


	Link Attribute sub-sub-TLVs - format matches the	<dd>
	existing formats defined in [RFC5305], [RFC7308],	<ul empty="true">
	and [RFC8570]]]></artwork>	<li>Application Identifier Bit Mask
	</figure></t>	(as defined in <xref target="AIBM"/>)</li>


	<t>If the SABM or UDABM length in the Application Identifier Bit Mask	<li> Link Attribute sub-sub-TLVs -- format matches the
	is greater than 8, the entire sub-TLV MUST be ignored.</t>	existing formats defined in <xref target="RFC5305"/>, <xref target="RFC
		7308"/>,
		and <xref target="RFC8570"/></li>
		</ul>
		</dd>
		</dl>


		<t>If the SABM or UDABM Length in the Application Identifier Bit Mask
		is greater than 8, the entire sub-TLV <bcp14>MUST</bcp14> be ignored.</t
		>
	<t>When the L-flag is set in the Application Identifier Bit Mask, all	<t>When the L-flag is set in the Application Identifier Bit Mask, all

	of the applications specified in the bit mask MUST use the legacy	of the applications specified in the bit mask <bcp14>MUST</bcp14> use th e legacy
	advertisements for the corresponding link found in TLVs 22, 23, 25,	advertisements for the corresponding link found in TLVs 22, 23, 25,

	141, 222, and 223 or TLV 138 or TLV 139 as appropriate. Link attribute	141, 222, and 223, in TLV 138, or in TLV 139 as appropriate. Link attrib
	sub-sub-TLVs for the corresponding link attributes MUST NOT be	ute
	advertised for the set of applications specified in the Standard/User	sub-sub-TLVs for the corresponding link attributes <bcp14>MUST NOT</bcp1
	Application Identifier Bit Masks and all such advertisements MUST be	4> be
		advertised for the set of applications specified in the Standard or User
		-Defined
		Application Identifier Bit Masks, and all such advertisements <bcp14>MUS
		T</bcp14> be
	ignored on receipt.</t>	ignored on receipt.</t>

		<t>Multiple Application-Specific Link Attributes sub-TLVs for the same
	<t>Multiple Application-Specific Link Attribute sub-TLVs for the same	link <bcp14>MAY</bcp14> be advertised. When multiple sub-TLVs for the sa
	link MAY be advertised. When multiple sub-TLVs for the same link are	me link are
	advertised, they SHOULD advertise non-conflicting	advertised, they <bcp14>SHOULD</bcp14> advertise non-conflicting
	application/attribute pairs. A conflict exists when the same	application/attribute pairs. A conflict exists when the same
	application is associated with two different values for the same link	application is associated with two different values for the same link
	attribute for a given link. In cases where conflicting values for the	attribute for a given link. In cases where conflicting values for the

	same application/attribute/link are advertised the first advertisement	same application/attribute/link are advertised, the first advertisement
	received in the lowest numbered LSP SHOULD be used and subsequent	received in the lowest-numbered LSP <bcp14>SHOULD</bcp14> be used, and s
	advertisements of the same attribute SHOULD be ignored.</t>	ubsequent
		advertisements of the same attribute <bcp14>SHOULD</bcp14> be ignored.</
	<t>For a given application, the setting of the L-flag MUST be the same	t>
		<t>For a given application, the setting of the L-flag <bcp14>MUST</bcp14
		> be the same
	in all sub-TLVs for a given link. In cases where this constraint is	in all sub-TLVs for a given link. In cases where this constraint is

	violated, the L-flag MUST be considered set for this application.</t>	violated, the L-flag <bcp14>MUST</bcp14> be considered set for this
		application.</t>
	<t>If link attributes are advertised associated with zero length	<t>If link attributes are advertised associated with zero-length
	Application Identifier Bit Masks for both standard applications and	Application Identifier Bit Masks for both standard applications and

	user defined applications, then any Standard Application and/or any	user-defined applications, then any standard application and/or any
	User Defined Application is permitted to use that set of link	user-defined application is permitted to use that set of link
	attributes so long as there is not another set of attributes	attributes so long as there is not another set of attributes

	advertised on that same link that is associated with a non-zero length	advertised on that same link that is associated with a non-zero-length
	Application Identifier Bit Mask with a matching Application Identifier	Application Identifier Bit Mask with a matching Application Identifier
	Bit set.</t>	Bit set.</t>

		<t>IANA has created a new registry of sub-sub-TLVs to define the link
	<t>A new registry of sub-sub-TLVs is to be created by IANA that	attribute sub-sub-TLV codepoints (see <xref target="IANA3"/>). This
	defines the link attribute sub-sub-TLV code points. This document	document defines a sub-sub-TLV for each of the existing sub-TLVs
	defines a sub-sub-TLV for each of the existing sub-TLVs listed in	listed in <xref target="LEGSUB" format="default"/>, except as noted
	<xref target="LEGSUB"/> except as noted below. The format of the	below. The format of the sub-sub-TLVs matches the format of the
	sub-sub-TLVs matches the format of the corresponding legacy sub-TLV	corresponding legacy sub-TLV, and IANA has assigned the legacy sub-TLV
	and IANA is requested to assign the legacy sub-TLV identifier to the	identifier to the corresponding sub-sub-TLV.</t>
	corresponding sub-sub-TLV.</t>	<section anchor="SCMLB" numbered="true" toc="default">
		<name>Special Considerations for Maximum Link Bandwidth</name>
	<section anchor="SCMLB"	<t>Maximum link bandwidth is an application-independent attribute of
	title="Special Considerations for Maximum Link Bandwidth">
	<t>Maximum link bandwidth is an application independent attribute of
	the link. When advertised using the Application-Specific Link	the link. When advertised using the Application-Specific Link

	Attributes sub-TLV, multiple values for the same link MUST NOT be	Attributes sub-TLV, multiple values for the same link <bcp14>MUST NOT< /bcp14> be
	advertised. This can be accomplished most efficiently by having a	advertised. This can be accomplished most efficiently by having a
	single advertisement for a given link where the Application	single advertisement for a given link where the Application
	Identifier Bit Mask identifies all the applications that are making	Identifier Bit Mask identifies all the applications that are making
	use of the value for that link.</t>	use of the value for that link.</t>

	<t>It is also possible to advertise the same value for a given link	<t>It is also possible to advertise the same value for a given link
	multiple times with disjoint sets of applications specified in the	multiple times with disjoint sets of applications specified in the
	Application Identifier Bit Mask. This is less efficient but still	Application Identifier Bit Mask. This is less efficient but still
	valid.</t>	valid.</t>

		<t>It is also possible to advertise a single advertisement with
	<t>It is also possible to advertise a single advertisement with zero	zero-length SABM and UDABM so long as the constraints discussed in
	length SABM and UDABM so long as the constraints discussed in <xref	Sections <xref target="ASLASUB" format="counter"/> and <xref
	target="ASLASUB"/> and <xref target="DEPZERO"/> are acceptable.</t>	target="DEPZERO" format="counter"/> are acceptable.</t>
		<t>If different values for maximum link bandwidth for a given link
	<t>If different values for Maximum Link Bandwidth for a given link	are advertised, all values <bcp14>MUST</bcp14> be ignored.</t>
	are advertised, all values MUST be ignored.</t>
	</section>	</section>

		<section anchor="SCUB" numbered="true" toc="default">
	<section anchor="SCUB"	<name>Special Considerations for Reservable/Unreserved Bandwidth</name
	title="Special Considerations for Reservable/Unreserved Bandwid	>
	th">	<t>Maximum reservable link bandwidth and unreserved bandwidth are
	<t>Maximum Reservable Link Bandwidth and Unreserved Bandwidth are
	attributes specific to RSVP-TE. When advertised using the	attributes specific to RSVP-TE. When advertised using the
	Application-Specific Link Attributes sub-TLV, bits other than the	Application-Specific Link Attributes sub-TLV, bits other than the

	RSVP-TE (R-bit) MUST NOT be set in the Application Identifier Bit	RSVP-TE (R-bit) <bcp14>MUST NOT</bcp14> be set in the Application Iden
	Mask. If an advertisement of Maximum Reservable Link Bandwidth or	tifier Bit
	Unreserved Bandwidth is received with bits other than the RSVP-TE	Mask. If an advertisement of maximum reservable link bandwidth or
	bit set, the advertisement MUST be ignored.</t>	unreserved bandwidth is received with bits other than the RSVP-TE
		bit set, the advertisement <bcp14>MUST</bcp14> be ignored.</t>
	</section>	</section>

		<section anchor="EXTTE" numbered="true" toc="default">
	<section anchor="EXTTE" title="Considerations for Extended TE Metrics">	<name>Considerations for Extended TE Metrics</name>
	<t><xref target="RFC8570"/> defines a number of dynamic performance	<t><xref target="RFC8570" format="default"/> defines a number of dynam
		ic performance
	metrics associated with a link. It is conceivable that such metrics	metrics associated with a link. It is conceivable that such metrics
	could be measured specific to traffic associated with a specific	could be measured specific to traffic associated with a specific

	application. Therefore this document includes support for	application. Therefore, this document includes support for
	advertising these link attributes specific to a given application.	advertising these link attributes specific to a given application.

	However, in practice it may well be more practical to have these	However, in practice, it may well be more practical to have these
	metrics reflect the performance of all traffic on the link	metrics reflect the performance of all traffic on the link
	regardless of application. In such cases, advertisements for these	regardless of application. In such cases, advertisements for these
	attributes will be associated with all of the applications utilizing	attributes will be associated with all of the applications utilizing
	that link. This can be done either by explicitly specifying the	that link. This can be done either by explicitly specifying the
	applications in the Application Identifier Bit Mask or by using a	applications in the Application Identifier Bit Mask or by using a

	zero length Application Identifier Bit Mask.</t>	zero-length Application Identifier Bit Mask.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="ASSRLGTLV" numbered="true" toc="default">
	<section anchor="ASSRLGTLV" title="Application-Specific SRLG TLV">	<name>Application-Specific SRLG TLV</name>
	<t>A new TLV is defined to advertise application-specific SRLGs for a	<t>A new TLV is defined to advertise application-specific SRLGs for a

	given link. Although similar in functionality to TLV 138 [RFC5307] and	given link. Although similar in functionality to TLV 138 <xref
	TLV 139 [RFC6119], a single TLV provides support for IPv4, IPv6, and	target="RFC5307" format="default"/> and
	unnumbered identifiers for a link. Unlike TLVs 138/139, it utilizes	TLV 139 <xref target="RFC6119" format="default"/>, a single TLV provides
		support for IPv4, IPv6, and
		unnumbered identifiers for a link. Unlike TLVs 138 and 139, it utilizes
	sub-TLVs to encode the link identifiers in order to provide the	sub-TLVs to encode the link identifiers in order to provide the
	flexible formatting required to support multiple link identifier	flexible formatting required to support multiple link identifier
	types.</t>	types.</t>


	<t><figure>	<dl>
	<artwork><![CDATA[ Type: 238 (Temporarily assigned by IANA)	<dt>Type:</dt><dd> 238</dd>
	Length: Number of octets in the value field (1 octet)	<dt> Length:</dt><dd> Number of octets in the value field (1 octet)</dd>
	Value:	<dt>Value:</dt>
	Neighbor System-ID + pseudo-node ID (7 octets)
	Application Identifier Bit Mask
	(as defined in Section 4.1)
	Length of sub-TLVs (1 octet)
	Link Identifier sub-TLVs (variable)
	0 or more SRLG Values (Each value is 4 octets)


	The following Link Identifier sub-TLVs are defined.	<dd>
	The values chosen are intentionally matching the equivalent
	sub-TLVs from [RFC5305], [RFC5307], and [RFC6119].


	Type Description	<ul empty="true">
	4 Link Local/Remote Identifiers [RFC5307]	<li>Neighbor System-ID + pseudonode ID (7 octets)</li>
	6 IPv4 interface address [RFC5305]	<li> Application Identifier Bit Mask
	8 IPv4 neighbor address [RFC5305]	(as defined in <xref target="AIBM"/>)</li>
	12 IPv6 Interface Address [RFC6119]	<li> Length of sub-TLVs (1 octet)</li>
	13 IPv6 Neighbor Address [RFC6119]	<li> Link Identifier sub-TLVs (variable)</li>
	]]></artwork>	<li> 0 or more SRLG values (each value is 4 octets)</li>
	</figure>At least one set of link identifiers (IPv4, IPv6, or Link	</ul>
	Local/Remote) MUST be present. Multiple occurrences of the same	</dd>
	identifier type MUST NOT be present. TLVs that do not meet this	</dl>
	requirement MUST be ignored.</t>


	<t>Multiple TLVs for the same link MAY be advertised.</t>	<t> The following Link Identifier sub-TLVs are defined.
		The values chosen intentionally match the equivalent
		sub-TLVs from <xref target="RFC5305"/>, <xref target="RFC5307"/>, and <xref t
		arget="RFC6119"/>.</t>


		<table>
		<thead>
		<tr>

		<th> Type </th>
		<th>Description</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>4</td>
		<td>Link Local/Remote Identifiers <xref target="RFC5307"/></td>
		</tr>
		<tr>
		<td>6</td>
		<td> IPv4 interface address <xref target="RFC5305"/></td>
		</tr>
		<tr>
		<td>8</td>
		<td>IPv4 neighbor address <xref target="RFC5305"/></td>
		</tr>
		<tr>
		<td>12</td>
		<td> IPv6 Interface Address <xref target="RFC6119"/></td>
		</tr>
		<tr>
		<td>13</td>
		<td> IPv6 Neighbor Address <xref target="RFC6119"/></td>
		</tr>
		</tbody>
		</table>
		<t>At least one set of link identifiers (IPv4, IPv6, or Link
		Local/Remote) <bcp14>MUST</bcp14> be present. Multiple occurrences of th
		e same
		identifier type <bcp14>MUST NOT</bcp14> be present. TLVs that do not mee
		t this
		requirement <bcp14>MUST</bcp14> be ignored.</t>
		<t>Multiple TLVs for the same link <bcp14>MAY</bcp14> be advertised.</t>
	<t>When the L-flag is set in the Application Identifier Bit Mask, SRLG	<t>When the L-flag is set in the Application Identifier Bit Mask, SRLG

	values MUST NOT be included in the TLV. Any SRLG values that are	values <bcp14>MUST NOT</bcp14> be included in the TLV. Any SRLG values t
	advertised MUST be ignored. Based on the link identifiers advertised	hat are
	the corresponding legacy TLV (see <xref target="LEGSRLG"/>) can be	advertised <bcp14>MUST</bcp14> be ignored. Based on the link identifiers
	identified and the SRLG values advertised in the legacy TLV MUST be	advertised,
		the corresponding legacy TLV (see <xref target="LEGSRLG" format="default
		"/>) can be
		identified, and the SRLG values advertised in the legacy TLV <bcp14>MUST
		</bcp14> be
	used by the set of applications specified in the Application	used by the set of applications specified in the Application
	Identifier Bit Mask.</t>	Identifier Bit Mask.</t>

		<t>For a given application, the setting of the L-flag <bcp14>MUST</bcp14
	<t>For a given application, the setting of the L-flag MUST be the same	> be the same
	in all TLVs for a given link. In cases where this constraint is	in all TLVs for a given link. In cases where this constraint is

	violated, the L-flag MUST be considered set for this application.</t>	violated, the L-flag <bcp14>MUST</bcp14> be considered set for this appl ication.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="AAE" numbered="true" toc="default">
	<section anchor="AAE" title="Attribute Advertisements and Enablement">	<name>Attribute Advertisements and Enablement</name>
	<t>This document defines extensions to support the advertisement of	<t>This document defines extensions to support the advertisement of
	application-specific link attributes.</t>	application-specific link attributes.</t>


	<t>Whether the presence of link attribute advertisements for a given	<t>Whether the presence of link attribute advertisements for a given
	application indicates that the application is enabled on that link	application indicates that the application is enabled on that link
	depends upon the application. Similarly, whether the absence of link	depends upon the application. Similarly, whether the absence of link
	attribute advertisements indicates that the application is not enabled	attribute advertisements indicates that the application is not enabled
	depends upon the application.</t>	depends upon the application.</t>


	<t>In the case of RSVP-TE, the advertisement of application-specific	<t>In the case of RSVP-TE, the advertisement of application-specific
	link attributes implies that RSVP is enabled on that link. The absence	link attributes implies that RSVP is enabled on that link. The absence
	of RSVP-TE application-specific link attributes in combination with the	of RSVP-TE application-specific link attributes in combination with the
	absence of legacy advertisements implies that RSVP is not enabled on	absence of legacy advertisements implies that RSVP is not enabled on
	that link.</t>	that link.</t>

		<t>In the case of SR Policy, the advertisement of application-specific lin
	<t>In the case of SR Policy, advertisement of application-specific link	k
	attributes does not indicate enablement of SR Policy on that link. The	attributes does not indicate enablement of SR Policy on that link. The
	advertisements are only used to support constraints that may be applied	advertisements are only used to support constraints that may be applied
	when specifying an explicit path. SR Policy is implicitly enabled on all	when specifying an explicit path. SR Policy is implicitly enabled on all

	links that are part of the Segment Routing enabled topology independent	links that are part of the SR-enabled topology independent
	of the existence of link attribute advertisements.</t>	of the existence of link attribute advertisements.</t>

		<t>In the case of LFA, the advertisement of application-specific link
	<t>In the case of LFA, advertisement of application-specific link
	attributes does not indicate enablement of LFA on that link. Enablement	attributes does not indicate enablement of LFA on that link. Enablement
	is controlled by local configuration.</t>	is controlled by local configuration.</t>

		<t>In the future, if additional standard applications are defined to
	<t>If, in the future, additional standard applications are defined to	use this mechanism, the specification defining this use <bcp14>MUST</bcp14
	use this mechanism, the specification defining this use MUST define the	> define the
	relationship between application-specific link attribute advertisements	relationship between application-specific link attribute advertisements
	and enablement for that application.</t>	and enablement for that application.</t>


	<t>This document allows the advertisement of application-specific link	<t>This document allows the advertisement of application-specific link

	attributes with no application identifiers i.e., both the Standard	attributes with no application identifiers, i.e., both the Standard
	Application Identifier Bit Mask and the User Defined Application	Application Identifier Bit Mask and the User-Defined Application
	Identifier Bit Mask are not present (See Section 4.1). This supports the	Identifier Bit Mask are not present (see <xref target="AIBM"/>). This supp
		orts the
	use of the link attribute by any application. In the presence of an	use of the link attribute by any application. In the presence of an

	application where the advertisement of link attribute advertisements is	application where the advertisement of link attribute advertisements is us
	used to infer the enablement of an application on that link (e.g.,	ed to infer the enablement of an application on that link (e.g.,
	RSVP-TE), the absence of the application identifier leaves ambiguous	RSVP-TE), the absence of the application identifier leaves ambiguous
	whether that application is enabled on such a link. This needs to be	whether that application is enabled on such a link. This needs to be
	considered when making use of the "any application" encoding.</t>	considered when making use of the "any application" encoding.</t>
	</section>	</section>

		<section anchor="DEPCONS" numbered="true" toc="default">
	<section anchor="DEPCONS" title="Deployment Considerations">	<name>Deployment Considerations</name>
	<t>This section discuss deployment considerations associated with the	<t>This section discusses deployment considerations associated with the
	use of application-specific link attribute advertisements.</t>	use of application-specific link attribute advertisements.</t>

		<section anchor="DEPLEGACY" numbered="true" toc="default">
	<section anchor="DEPLEGACY" title="Use of Legacy Advertisements">	<name>Use of Legacy Advertisements</name>
	<t>Bit Identifiers for Standard Applications are defined in <xref	<t>Bit identifiers for standard applications are defined in <xref target
	target="AIBM"/>. All of the identifiers defined in this document are	="AIBM" format="default"/>. All of the identifiers defined in this document are
	associated with applications that were already deployed in some	associated with applications that were already deployed in some
	networks prior to the writing of this document. Therefore, such	networks prior to the writing of this document. Therefore, such
	applications have been deployed using the legacy advertisements. The	applications have been deployed using the legacy advertisements. The

	Standard Applications defined in this document may continue to use	standard applications defined in this document may continue to use
	legacy advertisements for a given link so long as at least one of the	legacy advertisements for a given link so long as at least one of the
	following conditions is true:</t>	following conditions is true:</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li>The application is RSVP-TE.</li>
	<t>The application is RSVP-TE</t>	<li>The application is SR Policy or LFA, and RSVP-TE is not deployed
		anywhere in the network.</li>
	<t>The application is SR Policy or LFA and RSVP-TE is not deployed	<li>The application is SR Policy or LFA, RSVP-TE is deployed in the
	anywhere in the network</t>

	<t>The application is SR Policy or LFA, RSVP-TE is deployed in the
	network, and both the set of links on which SR Policy and/or LFA	network, and both the set of links on which SR Policy and/or LFA
	advertisements are required and the attribute values used by SR	advertisements are required and the attribute values used by SR

	Policy and/or LFA on all such links is fully congruent with the	Policy and/or LFA on all such links are fully congruent with the
	links and attribute values used by RSVP-TE</t>	links and attribute values used by RSVP-TE.</li>
	</list></t>	</ul>

	<t>Under the conditions defined above, implementations that support	<t>Under the conditions defined above, implementations that support
	the extensions defined in this document have the choice of using	the extensions defined in this document have the choice of using
	legacy advertisements or application-specific advertisements in	legacy advertisements or application-specific advertisements in

	support of SR Policy and/or LFA. This will require implementations to	support of SR Policy and/or LFA.
	provide controls specifying which type of advertisements are to be
	sent/processed on receive for these applications. Further discussion	This will require implementations to
	of the associated issues can be found in <xref target="IBCMC"/>.</t>	provide controls specifying which types of advertisements are to be
		sent and processed on receipt for these applications. Further discussion
		of the associated issues can be found in <xref target="IBCMC"
		format="default"/>.</t>

	<t>New applications that future documents define to make use of the	<t>New applications that future documents define to make use of the

	advertisements defined in this document MUST NOT make use of legacy	advertisements defined in this document <bcp14>MUST NOT</bcp14> make use of legacy
	advertisements. This simplifies deployment of new applications by	advertisements. This simplifies deployment of new applications by
	eliminating the need to support multiple ways to advertise attributes	eliminating the need to support multiple ways to advertise attributes
	for the new applications.</t>	for the new applications.</t>
	</section>	</section>

		<section anchor="DEPZERO" numbered="true" toc="default">
	<section anchor="DEPZERO"	<name>Use of Zero-Length Application Identifier Bit Masks</name>
	title="Use of Zero Length Application Identifier Bit Masks">	<t>Link attribute advertisements associated with zero-length
	<t>Link attribute advertisements associated with zero length
	Application Identifier Bit Masks for both standard applications and	Application Identifier Bit Masks for both standard applications and

	user defined applications are usable by any application, subject to	user-defined applications are usable by any application, subject to
	the restrictions specified in <xref target="ASLASUB"/>. If support for	the restrictions specified in <xref target="ASLASUB" format="default"/>.
		If support for
	a new application is introduced on any node in a network in the	a new application is introduced on any node in a network in the
	presence of such advertisements, these advertisements are permitted to	presence of such advertisements, these advertisements are permitted to
	be used by the new application. If this is not what is intended, then	be used by the new application. If this is not what is intended, then

	existing advertisements MUST be readvertised with an explicit set of	existing advertisements <bcp14>MUST</bcp14> be readvertised with an expl icit set of
	applications specified before a new application is introduced.</t>	applications specified before a new application is introduced.</t>
	</section>	</section>

		<section anchor="IBCMC" numbered="true" toc="default">
	<section anchor="IBCMC"	<name>Interoperability, Backwards Compatibility, and Migration Concerns<
	title="Interoperability, Backwards Compatibility and Migration Co	/name>
	ncerns">
	<t>Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the	<t>Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the

	legacy advertisements listed in Section 3. Routers that do not support	legacy advertisements listed in <xref target="LEGADV"/>. Routers that do not support
	the extensions defined in this document will only process legacy	the extensions defined in this document will only process legacy
	advertisements and are likely to infer that RSVP-TE is enabled on the	advertisements and are likely to infer that RSVP-TE is enabled on the
	links for which legacy advertisements exist. It is expected that	links for which legacy advertisements exist. It is expected that
	deployments using the legacy advertisements will persist for a	deployments using the legacy advertisements will persist for a

	significant period of time. Therefore deployments using the extensions	significant period of time. Therefore, deployments using the extensions
	defined in this document in the presence of routers that do not	defined in this document in the presence of routers that do not
	support these extensions need to be able to interoperate with the use	support these extensions need to be able to interoperate with the use
	of legacy advertisements by the legacy routers. The following	of legacy advertisements by the legacy routers. The following

	sub-sections discuss interoperability and backwards compatibility	subsections discuss interoperability and backwards-compatibility
	concerns for a number of deployment scenarios.</t>	concerns for a number of deployment scenarios.</t>

		<section anchor="MACARSVP" numbered="true" toc="default">
	<section anchor="MACARSVP"	<name>Multiple Applications: Common Attributes with RSVP-TE</name>
	title="Multiple Applications: Common Attributes with RSVP-TE">
	<t>In cases where multiple applications are utilizing a given link,	<t>In cases where multiple applications are utilizing a given link,
	one of the applications is RSVP-TE, and all link attributes for a	one of the applications is RSVP-TE, and all link attributes for a
	given link are common to the set of applications utilizing that	given link are common to the set of applications utilizing that
	link, interoperability is achieved by using legacy advertisements	link, interoperability is achieved by using legacy advertisements

	and sending application-specific advertisements with L-flag set and	and sending application-specific advertisements with the L-flag set an d
	no link attribute values. This avoids duplication of link attribute	no link attribute values. This avoids duplication of link attribute
	advertisements.</t>	advertisements.</t>
	</section>	</section>

		<section anchor="MAALLNS" numbered="true" toc="default">
	<section anchor="MAALLNS"	<name>Multiple Applications: All Attributes Not Shared with RSVP-TE</n
	title="Multiple Applications: All Attributes Not Shared with RS	ame>
	VP-TE">
	<t>In cases where one or more applications other than RSVP-TE are	<t>In cases where one or more applications other than RSVP-TE are
	utilizing a given link and one or more link attribute values are not	utilizing a given link and one or more link attribute values are not
	shared with RSVP-TE, it is necessary to use application-specific	shared with RSVP-TE, it is necessary to use application-specific
	advertisements as defined in this document. Attributes for	advertisements as defined in this document. Attributes for

	applications other than RSVP-TE MUST be advertised using	applications other than RSVP-TE <bcp14>MUST</bcp14> be advertised usin g
	application-specific advertisements that have the L-flag clear. In	application-specific advertisements that have the L-flag clear. In
	cases where some link attributes are shared with RSVP-TE, this	cases where some link attributes are shared with RSVP-TE, this
	requires duplicate advertisements for those attributes.</t>	requires duplicate advertisements for those attributes.</t>


	<t>These guidelines apply to cases where RSVP-TE is not using any	<t>These guidelines apply to cases where RSVP-TE is not using any
	advertised attributes on a link and to cases where RSVP-TE is using	advertised attributes on a link and to cases where RSVP-TE is using
	some link attribute advertisements on the link but some link	some link attribute advertisements on the link but some link
	attributes cannot be shared with RSVP-TE.</t>	attributes cannot be shared with RSVP-TE.</t>
	</section>	</section>

		<section anchor="LEGACY" numbered="true" toc="default">
	<section anchor="LEGACY" title="Interoperability with Legacy Routers">	<name>Interoperability with Legacy Routers</name>
	<t>For the applications defined in this document, routers that do	<t>For the applications defined in this document, routers that do
	not support the extensions defined in this document will send and	not support the extensions defined in this document will send and
	receive only legacy link attribute advertisements. So long as there	receive only legacy link attribute advertisements. So long as there
	is any legacy router in the network that has any of the applications	is any legacy router in the network that has any of the applications

	enabled, all routers MUST continue to advertise link attributes	enabled, all routers <bcp14>MUST</bcp14> continue to advertise link at tributes
	using legacy advertisements. In addition, the link attribute values	using legacy advertisements. In addition, the link attribute values
	associated with the set of applications supported by legacy routers	associated with the set of applications supported by legacy routers
	(RSVP-TE, SR Policy, and/or LFA) are always shared since legacy	(RSVP-TE, SR Policy, and/or LFA) are always shared since legacy
	routers have no way of advertising or processing	routers have no way of advertising or processing
	application-specific values. Once all legacy routers have been	application-specific values. Once all legacy routers have been
	upgraded, migration from legacy advertisements to ASLA	upgraded, migration from legacy advertisements to ASLA
	advertisements can be achieved via the following steps:</t>	advertisements can be achieved via the following steps:</t>

		<ol type="%d)">


	<t>1)Send ASLA advertisements while continuing to advertise using	<li>Send ASLA advertisements while continuing to advertise using
	legacy (all advertisements are then duplicated). Receiving routers	legacy (all advertisements are then duplicated). Receiving routers

	continue to use legacy advertisements.</t>	continue to use legacy advertisements.</li>
		<li>Enable the use of the ASLA advertisements on all routers.</li>
	<t>2)Enable the use of the ASLA advertisements on all routers</t>	<li>Remove legacy advertisements.</li>
		</ol>
	<t>3)Remove legacy advertisements</t>

	<t>When the migration is complete, it then becomes possible to	<t>When the migration is complete, it then becomes possible to
	advertise incongruent values per application on a given link.</t>	advertise incongruent values per application on a given link.</t>


	<t>Note that the use of the L-flag is of no value in the	<t>Note that the use of the L-flag is of no value in the
	migration.</t>	migration.</t>


	<t>Documents defining new applications that make use of the	<t>Documents defining new applications that make use of the

	application-specific advertisements defined in this document MUST	application-specific advertisements defined in this document <bcp14>MU
	discuss interoperability and backwards compatibility issues that	ST</bcp14>
		discuss interoperability and backwards-compatibility issues that
	could occur in the presence of routers that do not support the new	could occur in the presence of routers that do not support the new
	application.</t>	application.</t>
	</section>	</section>


	<section anchor="APPRSVP"	<section anchor="APPRSVP" numbered="true" toc="default">
	title="Use of Application-Specific Advertisements for RSVP-TE">	<name>Use of Application-Specific Advertisements for RSVP-TE</name>
	<t>The extensions defined in this document support RSVP-TE as one of	<t>The extensions defined in this document include RSVP-TE as one of
	the supported applications. This allows that RSVP-TE could	the applications. It is therefore possible, in the future, for
	eventually utilize the application-specific advertisements. This can	implementations to migrate to the use of application-specific
	be done in the following step-wise manner:</t>	advertisements in support of RSVP-TE. This could
		be done in the following stepwise manner:</t>
	<t>1)Upgrade all routers to support the extensions in this	<ol type="%d)">
	document</t>	<li>Upgrade all routers to support the extensions in this
		document.</li>
	<t>2)Advertise all legacy link attributes using ASLA advertisements	<li>Advertise all legacy link attributes using ASLA advertisements
	with L-flag clear and R-bit set. At this point both legacy and	with the L-flag clear and R-bit set. At this point, both legacy and
	application-specific advertisements are being sent.</t>	application-specific advertisements are being sent.</li>
		<li>Remove legacy advertisements.</li>
	<t>3)Remove legacy advertisements</t>	</ol>
	</section>	</section>
	</section>	</section>
	</section>	</section>

		<section anchor="IANA" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">	<name>IANA Considerations</name>
	<t>This section lists the protocol code point changes introduced by this	<t>This section lists the protocol codepoint changes introduced by this
	document and the related IANA changes required.</t>	document and the related updates made by IANA.</t>
		<t>For the new registries defined under the "IS-IS TLV Codepoints" registr
	<t>For new registries defined under IS-IS TLV Codepoints Registry with	y
	registration procedure "Expert Review", guidance for designated experts	with the "Expert Review" registration procedure (see Sections <xref
	can be found in <xref target="RFC7370"/>.</t>	target="IANA3" format="counter"/> and
		<xref target="IANA5" format="counter"/>), guidance for designated experts
	<section anchor="IANA1"	can be found in <xref target="RFC7370" format="default"/>.</t>
	title="Application-Specific Link Attributes sub-TLV">	<section anchor="IANA1" numbered="true" toc="default">
	<t>This document defines a new sub-TLV in the Sub-TLVs for TLVs 22,	<name>Application-Specific Link Attributes Sub-TLV</name>
	23, 25, 141, 222, and 223 registry. See <xref target="ASLASUB"/></t>	<t>IANA has registered the new sub-TLV defined in
		<xref target="ASLASUB" format="default"/> in the "Sub-TLVs for TLVs
	<figure>	22, 23, 25, 141, 222, and 223" registry.</t>
	<artwork><![CDATA[	<table>
	Type Description 22 23 25 141 222 223	<thead>
	---- --------------------- ---- ---- ---- ---- ---- ----	<tr>
	16 Application-Specific y y y(s) y y y	<th>Type</th>
	Link Attributes	<th>Description</th>
	]]></artwork>	<th>22</th>
	</figure>	<th>23</th>
		<th>25</th>
		<th>141</th>
		<th>222</th>
		<th>223 </th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>16</td>
		<td>Application-Specific Link Attributes</td>
		<td>y</td>
		<td>y</td>
		<td>y(s)</td>
		<td>y</td>
		<td>y</td>
		<td>y</td>
		</tr>
		</tbody>
		</table>
	<t/>	<t/>
	</section>	</section>

		<section anchor="IANA2" numbered="true" toc="default">
		<name>Application-Specific SRLG TLV</name>
		<t>IANA has registered the new TLV defined in <xref target="ASSRLGTLV"
		format="default"/> in the IS-IS "TLV Codepoints
		Registry".
		</t>


	<section anchor="IANA2" title="Application-Specific SRLG TLV">	<table>
	<t>This document defines one new TLV in the IS-IS TLV Codepoints	<thead>
	Registry. See <xref target="ASSRLGTLV"/></t>	<tr>
		<th>Value</th>
		<th> Description</th>
		<th>IIH</th>
		<th>LSP</th>
		<th>SNP</th>
		<th>Purge</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td> 238 </td>
		<td> Application-Specific SRLG </td>
		<td> n </td>
		<td> y </td>
		<td> n </td>
		<td> n </td>
		</tr>
		</tbody>
		</table>


	<t><figure>
	<artwork><![CDATA[
	Type Description IIH LSP SNP Purge
	---- --------------------- --- --- --- -----
	238 Application-Specific n y n n
	SRLG
	]]></artwork>
	</figure></t>
	</section>	</section>

		<section anchor="IANA3" numbered="true" toc="default">
		<name>Sub-sub-TLV Codepoints for Application-Specific Link Attributes Re
		gistry</name>
		<t>IANA has created a new registry titled "Sub-sub-TLV Codepoints for
		Application-Specific Link Attributes" under the "IS-IS TLV
		Codepoints" registry to control the assignment of sub-sub-TLV
		codepoints for the Application-Specific Link Attributes sub-TLV
		defined in <xref target="IANA1" format="default"/>. The registration
		procedure is "Expert Review" as defined in <xref target="RFC8126"
		format="default"/>. The initial contents of this registry are as follows
		:
		</t>
		<table>
		<thead>
		<tr>
		<th>Type </th>
		<th>Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td> 0-2 </td>
		<td> Unassigned </td>
		<td/>
		</tr>
		<tr>
		<td> 3 </td>
		<td> Administrative group (color) </td>
		<td> <xref target="RFC5305"/> </td>
		</tr>
		<tr>
		<td> 4-8 </td>
		<td> Unassigned </td>
		<td/>
		</tr>
		<tr>
		<td> 9 </td>
		<td> Maximum link bandwidth</td>
		<td> <xref target="RFC5305"/> </td>
		</tr>
		<tr>
		<td> 10 </td>
		<td> Maximum reservable link bandwidth </td>
		<td> <xref target="RFC5305"/> </td>
		</tr>
		<tr>
		<td>11 </td>
		<td> Unreserved bandwidth </td>
		<td> <xref target="RFC5305"/> </td>
		</tr>
		<tr>
		<td> 12-13 </td>
		<td> Unassigned </td>
		<td/>
		</tr>
		<tr>
		<td>14 </td>
		<td> Extended Administrative Group </td>
		<td> <xref target="RFC7308"/></td>
		</tr>
		<tr>
		<td>15-17 </td>
		<td> Unassigned </td>
		<td/>
		</tr>
		<tr>
		<td>18 </td>
		<td> TE Default Metric </td>
		<td> <xref target="RFC5305"/></td>
		</tr>
		<tr>
		<td> 19-32 </td>
		<td> Unassigned </td>
		<td/>


	<section anchor="IANA3"	</tr>
	title="Application-Specific Link Attributes sub-sub-TLV Registry"	<tr>
	>	<td> 33 </td>
	<t>This document requests a new IANA registry under the IS-IS TLV	<td> Unidirectional Link Delay </td>
	Codepoints Registry be created to control the assignment of	<td> <xref target="RFC8570"/> </td>
	sub-sub-TLV codepoints for the Application-Specific Link Attributes	</tr>
	sub-TLV defined in <xref target="IANA1"/>. The suggested name of the	<tr>
	new registry is "sub-sub-TLV code points for application-specific link	<td> 34 </td>
	attributes". The registration procedure is "Expert Review" as defined	<td> Min/Max Unidirectional Link Delay </td>
	in <xref target="RFC8126"/>. The following assignments are made by	<td> <xref target="RFC8570"/> </td>
	this document:</t>	</tr>
		<tr>
		<td> 35 </td>
		<td> Unidirectional Delay Variation </td>
		<td> <xref target="RFC8570"/> </td>
		</tr>
		<tr>
		<td>36 </td>
		<td> Unidirectional Link Loss </td>
		<td> <xref target="RFC8570"/> </td>
		</tr>
		<tr>
		<td>37 </td>
		<td>Unidirectional Residual Bandwidth </td>
		<td> <xref target="RFC8570"/> </td>
		</tr>
		<tr>
		<td> 38 </td>
		<td>Unidirectional Available Bandwidth </td>
		<td><xref target="RFC8570"/> </td>
		</tr>
		<tr>
		<td>39 </td>
		<td>Unidirectional Utilized Bandwidth </td>
		<td><xref target="RFC8570"/></td>
		</tr>
		<tr>
		<td>40-255 </td>
		<td> Unassigned </td>
		<td/>
		</tr>
		</tbody>
		</table>


	<t><figure>	<t>IANA has also added the following notes to this registry:</t>
	<artwork><![CDATA[ Type Description Encod
	ing
	Reference
	0-2 Unassigned
	3 Administrative group (color) RFC5305
	4-8 Unassigned
	9 Maximum link bandwidth RFC5305
	10 Maximum reservable link bandwidth RFC5305
	11 Unreserved bandwidth RFC5305
	12-13 Unassigned
	14 Extended Administrative Group RFC7308
	15-17 Unassigned
	18 TE Default Metric RFC5305
	19-32 Unassigned
	33 Unidirectional Link Delay RFC8570
	34 Min/Max Unidirectional Link Delay RFC8570
	35 Unidirectional Delay Variation RFC8570
	36 Unidirectional Link Loss RFC8570
	37 Unidirectional Residual Bandwidth RFC8570
	38 Unidirectional Available Bandwidth RFC8570
	39 Unidirectional Utilized Bandwidth RFC8570
	40-255 Unassigned
	]]></artwork>
	</figure></t>


	<t>Note to IANA: For future codepoints, in cases where the document	<t indent="3">Note: For future codepoints, in cases where the document that defi
	that defines the encoding is different from the document that assigns	nes the
	the codepoint, the encoding reference MUST be to the document that	encoding is different from the document that assigns the codepoint, the
		encoding reference <bcp14>MUST</bcp14> be to the document that
	defines the encoding.</t>	defines the encoding.</t>

		<t indent="3">Note: If a link attribute can be advertised
	<t>Note to designated experts: If a link attribute can be advertised
	both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a	both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a
	sub-sub-TLV of the Application-Specific Link Attributes sub-TLV	sub-sub-TLV of the Application-Specific Link Attributes sub-TLV

	defined in this document, then the same numerical code should be	defined in RFC 8919, then the same numerical code should be
	assigned to the link attribute whenever possible.</t>	assigned to the link attribute whenever possible.</t>
	</section>	</section>

		<section anchor="IANA4" numbered="true" toc="default">
	<section anchor="IANA4"	<name>Link Attribute Application Identifiers Registry</name>
	title="Link Attribute Application Identifier Registry">	<t>IANA has created a new registry titled "Link Attribute
	<t>This document requests a new IANA registry be created, under the	Application Identifiers" under the "Interior Gateway Protocol (IGP) Para
	category of "Interior Gateway Protocol (IGP) Parameters", to control	meters" registry
	the assignment of Application Identifier Bits. The suggested name of	to control the assignment of Application Identifier Bits. The
	the new registry is "Link Attribute Applications". The registration	registration policy for this registry is "Expert Review" as defined in
	policy for this registry is "Expert Review" <xref target="RFC8126"/>.	<xref target="RFC8126" format="default"/>. Bit definitions
	Bit definitions SHOULD be assigned such that all bits in the lowest	<bcp14>SHOULD</bcp14> be assigned such that all bits in the lowest
	available octet are allocated before assigning bits in the next octet.	available octet are allocated before assigning bits in the next octet.
	This minimizes the number of octets that will need to be transmitted.	This minimizes the number of octets that will need to be transmitted.

	The following assignments are made by this document:</t>	The initial contents of this registry are as follows:
		</t>
		<table>
		<thead>
		<tr>
		<th>Bit # </th>
		<th>Name</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td> 0</td>
		<td> RSVP-TE (R-bit)</td>
		</tr>
		<tr>
		<td>1</td>
		<td> Segment Routing Policy (S-bit)</td>
		</tr>
		<tr>
		<td>2</td>
		<td> Loop-Free Alternate (F-bit)</td>
		</tr>
		<tr>
		<td>3-63</td>
		<td> Unassigned</td>
		</tr>
		</tbody>
		</table>


	<t><figure>
	<artwork><![CDATA[ Bit # Name
	0 RSVP-TE (R-bit)
	1 Segment Routing Policy (S-bit)
	2 Loop Free Alternate (F-bit)
	3-63 Unassigned
	]]></artwork>
	</figure></t>
	</section>	</section>

		<section anchor="IANA5" numbered="true" toc="default">
		<name>Sub-TLVs for TLV 238 Registry</name>
		<t>IANA has created a new registry titled "Sub-TLVs for TLV 238" under
		the "IS-IS TLV Codepoints" registry to control the assignment of
		sub-TLV types for the Application-Specific SRLG TLV. The registration
		procedure is "Expert Review" as defined in <xref target="RFC8126"
		format="default"/>. The initial contents of this registry are as follows
		:
		</t>
		<table>
		<thead>
		<tr>
		<th>Value</th>
		<th>Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0-3 </td>
		<td>Unassigned </td>
		<td/>


	<section anchor="IANA5" title="SRLG sub-TLVs">	</tr>
	<t>This document requests a new IANA registry be created under the	<tr>
	IS-IS TLV Codepoints Registry to control the assignment of sub-TLV	<td>4 </td>
	types for the application-specific SRLG TLV. The suggested name of the	<td> Link Local/Remote Identifiers </td>
	new registry is "Sub-TLVs for TLV 238". The registration procedure is	<td> <xref target="RFC5307"/> </td>
	"Expert Review" as defined in <xref target="RFC8126"/>. The following	</tr>
	assignments are made by this document:</t>	<tr>
		<td>5 </td>
		<td> Unassigned </td>
		<td/>


	<t><figure>	</tr>
	<artwork><![CDATA[ Value Description Encoding	<tr>
	Reference	<td>6 </td>
	---------------------------------------------------------	<td> IPv4 interface address </td>
	0-3 Unassigned	<td> <xref target="RFC5305"/> </td>
	4 Link Local/Remote Identifiers [RFC5307]	</tr>
	5 Unassigned	<tr>
	6 IPv4 interface address [RFC5305]	<td>7 </td>
	7 Unassigned	<td>Unassigned </td>
	8 IPv4 neighbor address [RFC5305]	<td/>
	9-11 Unassigned	</tr>
	12 IPv6 Interface Address [RFC6119]	<tr>
	13 IPv6 Neighbor Address [RFC6119]	<td>8 </td>
	14-255 Unassigned	<td> IPv4 neighbor address </td>
	]]></artwork>	<td> <xref target="RFC5305"/> </td>
	</figure>Note to IANA: For future codepoints, in cases where the	</tr>
	document that defines the encoding is different from the document that	<tr>
	assigns the codepoint, the encoding reference MUST be to the document	<td>9-11 </td>
	that defines the encoding.</t>	<td>Unassigned </td>
		<td/>

		</tr>
		<tr>
		<td>12 </td>
		<td> IPv6 Interface Address </td>
		<td> <xref target="RFC6119"/> </td>
		</tr>
		<tr>
		<td>13 </td>
		<td> IPv6 Neighbor Address </td>
		<td> <xref target="RFC6119"/> </td>
		</tr>
		<tr>
		<td>14-255 </td>
		<td> Unassigned </td>
		<td></td>

		</tr>
		</tbody>
		</table>

		<t>IANA has also added the following note to this registry:</t>

		<t indent="3">Note: For future codepoints, in cases where the document t
		hat
		defines the encoding is different from the document that assigns the
		codepoint, the encoding reference <bcp14>MUST</bcp14> be to the
		document that defines the encoding.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="Security" numbered="true" toc="default">
	<section anchor="Security" title="Security Considerations">	<name>Security Considerations</name>
	<t>Security concerns for IS-IS are addressed in <xref	<t>Security concerns for IS-IS are addressed in <xref target="ISO10589" fo
	target="ISO10589"/>, <xref target="RFC5304"/>, and <xref	rmat="default"/>, <xref target="RFC5304" format="default"/>, and <xref target="R
	target="RFC5310"/>. While IS-IS is deployed under a single	FC5310" format="default"/>. While IS-IS is deployed under a single
	administrative domain, there can be deployments where potential	administrative domain, there can be deployments where potential
	attackers have access to one or more networks in the IS-IS routing	attackers have access to one or more networks in the IS-IS routing
	domain. In these deployments, the stronger authentication mechanisms	domain. In these deployments, the stronger authentication mechanisms

	defined in the aforementioned documents SHOULD be used.</t>	defined in the aforementioned documents <bcp14>SHOULD</bcp14> be used.</t>

	<t>This document defines a new way to advertise link attributes.	<t>This document defines a new way to advertise link attributes.
	Tampering with the information defined in this document may have an	Tampering with the information defined in this document may have an

	effect on applications using it, including impacting Traffic Engineering	effect on applications using it, including impacting traffic engineering
	as discussed in <xref target="RFC8570"/>. As the advertisements defined	as discussed in <xref target="RFC8570" format="default"/>. As the advertis
		ements defined
	in this document limit the scope to specific applications, the impact of	in this document limit the scope to specific applications, the impact of
	tampering is similarly limited in scope.</t>	tampering is similarly limited in scope.</t>
	</section>	</section>


	<section anchor="Acknowledgements" title="Acknowledgements">
	<t>The authors would like to thank Eric Rosen and Acee Lindem for their
	careful review and content suggestions.</t>
	</section>
	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">
	<reference anchor="ISO10589">
	<front>
	<title>Intermediate system to Intermediate system intra-domain
	routeing information exchange protocol for use in conjunction with
	the protocol for providing the connectionless-mode Network Service
	(ISO 8473)</title>

	<author>
	<organization abbrev="ISO">International Organization for
	Standardization</organization>
	</author>


	<date month="Nov" year="2002"/>	<displayreference target="I-D.ietf-spring-segment-routing-policy" to="SEGMENT-RO
	</front>	UTING"/>

	<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
	</reference>

	<?rfc include="reference.RFC.2119"?>

	<?rfc include='reference.RFC.8126'?>

	<?rfc include='reference.RFC.5304'?>

	<?rfc include='reference.RFC.5305'?>

	<?rfc include='reference.RFC.5307'?>

	<?rfc include='reference.RFC.5310'?>

	<?rfc include='reference.RFC.6119'?>


	<?rfc include='reference.RFC.7308'?>	<references>
		<name>References</name>
		<references>
		<name>Normative References</name>


	<?rfc include='reference.RFC.7370'?>	<reference anchor="ISO10589">
		<front>
		<title>Information technology - Telecommunications and information
		exchange between systems - Intermediate System to Intermediate
		System intra-domain routing information exchange protocol for use
		in conjunction with the protocol for providing the
		connectionless-mode network service (ISO 8473)</title>
		<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
		<author>
		<organization abbrev="ISO">International Organization for
		Standardization</organization>
		</author>
		<date month="Nov" year="2002"/>
		</front>
		</reference>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8126.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5304.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5305.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5307.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5310.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7308.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7370.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8570.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>
		</references>
		<references>
		<name>Informative References</name>


	<?rfc include='reference.RFC.8570'?>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-spring-segment-routing-policy.xml"/>


	<?rfc include='reference.RFC.8174'?>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3209.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5286.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7855.xml"/>
		</references>
	</references>	</references>

		<section anchor="Acknowledgements" numbered="false" toc="default">
		<name>Acknowledgements</name>
		<t>The authors would like to thank <contact fullname="Eric Rosen"/> and
		<contact fullname="Acee Lindem"/> for their careful review and content
		suggestions.</t>
		</section>


	<references title="Informative References">
	<?rfc include="reference.I-D.ietf-spring-segment-routing-policy.xml"?>

	<?rfc include="reference.RFC.3209"?>

	<?rfc include="reference.RFC.5286"?>

	<?rfc include='reference.RFC.7855'?>

	<?rfc ?>
	</references>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 192 change blocks.
	625 lines changed or deleted	882 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/