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&nbsp;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/