rfc9479.original.xml   rfc9479.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse <!DOCTYPE rfc [
nsus="true" docName="draft-ietf-lsr-rfc8919bis-04" indexInclude="true" ipr="trus <!ENTITY nbsp "&#160;">
t200902" obsoletes="8919" scripts="Common,Latin" sortRefs="true" submissionType= <!ENTITY zwsp "&#8203;">
"IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF
"
category="std" consensus="true" docName="draft-ietf-lsr-rfc8919bis-04" number="9
479"
ipr="trust200902" updates="" obsoletes="8919" sortRefs="true" symRefs="true" toc
Depth="3"
tocInclude="true" xml:lang="en">
<front> <front>
<title abbrev="IS-IS App-Specific Link Attributes">IS-IS Application-Specifi c Link Attributes</title> <title abbrev="IS-IS App-Specific Link Attributes">IS-IS Application-Specifi c Link Attributes</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lsr-rfc8919bis-04" strea m="IETF"/> <seriesInfo name="RFC" value="9479"/>
<author fullname="Les Ginsberg" initials="L" surname="Ginsberg"> <author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
<organization showOnFrontPage="true">Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <code/>
<country>United States of America</country> <country>United States of America</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 showOnFrontPage="true">Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <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 showOnFrontPage="true">Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal>
<street/>
<country/>
</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 showOnFrontPage="true">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 showOnFrontPage="true">Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal>
<street/>
<code/>
<country/>
</postal>
<email>jdrake@juniper.net</email> <email>jdrake@juniper.net</email>
</address> </address>
</author> </author>
<date year="2023"/> <date year="2023" month="October"/>
<area>Routing Area</area> <area>rtg</area>
<workgroup>Networking Working Group</workgroup> <workgroup>lsr</workgroup>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">Existing traffic-engineering-related <abstract>
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 and Loop-Free Alternates) 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 an 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 link attribute advertisements that address both of these
shortcomings.</t> shortcomings.</t>
<t indent="0" pn="section-abstract-2">This document obsoletes RFC 8919.</t > <t>This document obsoletes RFC 8919.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8919" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-re
quirements-language">Requirements Language</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-requirements-d
iscussion">Requirements Discussion</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-legacy-advertisements">Legacy Adve
rtisements</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-legacy-sub-tlvs">Legac
y Sub-TLVs</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-legacy-srlg-advertisem
ents">Legacy SRLG Advertisements</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-advertising-application-spe">Adver
tising Application-Specific Link Attributes</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-application-identifier
-bit-">Application Identifier Bit Mask</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-application-specific-l
ink-a">Application-Specific Link Attributes Sub-TLV</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.2.2">
<li pn="section-toc.1-1.4.2.2.2.1">
<t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derived
Content="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-special-co
nsiderations-for-">Special Considerations for Maximum Link Bandwidth</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derived
Content="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-special-co
nsiderations-for-r">Special Considerations for Reservable/Unreserved Bandwidth</
xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.3">
<t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derived
Content="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-considerat
ions-for-extended">Considerations for Extended TE Metrics</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-application-specific-s
rlg-t">Application-Specific SRLG TLV</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-attribute-advertisements-an">Attri
bute Advertisements and Enablement</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-deployment-considerations">Deploym
ent Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-use-of-legacy-advertis
ement">Use of Legacy Advertisements</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-use-of-zero-length-app
licat">Use of Zero-Length Application Identifier Bit Masks</xref></t>
</li>
<li pn="section-toc.1-1.6.2.3">
<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
"6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-interoperability-backw
ards-">Interoperability, Backwards Compatibility, and Migration Concerns</xref><
/t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.3.2">
<li pn="section-toc.1-1.6.2.3.2.1">
<t indent="0" pn="section-toc.1-1.6.2.3.2.1.1"><xref derived
Content="6.3.1" format="counter" sectionFormat="of" target="section-6.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-a
pplications-commo">Multiple Applications: Common Attributes with RSVP-TE</xref><
/t>
</li>
<li pn="section-toc.1-1.6.2.3.2.2">
<t indent="0" pn="section-toc.1-1.6.2.3.2.2.1"><xref derived
Content="6.3.2" format="counter" sectionFormat="of" target="section-6.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-a
pplications-all-a">Multiple Applications: All Attributes Not Shared with RSVP-TE
</xref></t>
</li>
<li pn="section-toc.1-1.6.2.3.2.3">
<t indent="0" pn="section-toc.1-1.6.2.3.2.3.1"><xref derived
Content="6.3.3" format="counter" sectionFormat="of" target="section-6.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-interopera
bility-with-legac">Interoperability with Legacy Routers</xref></t>
</li>
<li pn="section-toc.1-1.6.2.3.2.4">
<t indent="0" pn="section-toc.1-1.6.2.3.2.4.1"><xref derived
Content="6.3.4" format="counter" sectionFormat="of" target="section-6.3.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-app
lication-specific">Use of Application-Specific Advertisements for RSVP-TE</xref>
</t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-application-specific-l
ink-at">Application-Specific Link Attributes Sub-TLV</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-application-specific-s
rlg-tl">Application-Specific SRLG TLV</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
"7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-sub-sub-tlv-codepoints
-for-">Sub-sub-TLV Codepoints for Application-Specific Link Attributes Registry<
/xref></t>
</li>
<li pn="section-toc.1-1.7.2.4">
<t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent=
"7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-link-attribute-applica
tion-">Link Attribute Application Identifiers Registry</xref></t>
</li>
<li pn="section-toc.1-1.7.2.5">
<t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent=
"7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-sub-tlvs-for-tlv-238-r
egist">Sub-TLVs for TLV 238 Registry</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-normative-references"
>Normative References</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"9.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-informative-reference
s">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1"> <section>
<name slugifiedName="name-introduction">Introduction</name> <name>Introduction</name>
<t indent="0" pn="section-1-1"> NOTE: This document makes modest editorial <t>Advertisement of link attributes by the
changes to the content of RFC 8919 which it obsoletes. A detailed descript
ion
of the changes is provided in <xref target="changes-to-rfc8919" format="de
fault" sectionFormat="of" derivedContent="Section 9"/>.
This note was added for the benefit of IESG reviewers and SHOULD be
removed by the RFC Editor prior to publication.</t>
<t indent="0" pn="section-1-2">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 <xref target="RFC5305" forma of Traffic Engineering (TE) was introduced by <xref target="RFC5305"/> and
t="default" sectionFormat="of" derivedContent="RFC5305"/> and extended by extended by
<xref target="RFC5307" format="default" sectionFormat="of" derivedContent= <xref target="RFC5307"/>, <xref target="RFC6119"/>, <xref target="RFC7308"
"RFC5307"/>, <xref target="RFC6119" format="default" sectionFormat="of" derivedC />, and <xref target="RFC8570"/>. The use of these extensions
ontent="RFC6119"/>, <xref target="RFC7308" format="default" sectionFormat="of" d has been associated with deployments supporting TE over
erivedContent="RFC7308"/>, and <xref target="RFC8570" format="default" sectionFo
rmat="of" derivedContent="RFC8570"/>. Use of these extensions
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" format="default" sectionFormat="of" derivedContent= <xref target="RFC3209"/>.</t>
"RFC3209"/>.</t> <t>For the purposes of this document, an application is a technology that
<t indent="0" pn="section-1-3">For the purposes of this document, an appli
cation 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" sectionFormat="of" derive listed in <xref target="LEGADV"/>.</t>
dContent="Section 3"/>.</t> <t>In recent years, new applications that have use cases for many of the
<t indent="0" pn="section-1-4">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 (SR) Policy <xref target="RFC9256" fo applications include Segment Routing (SR) Policy <xref target="RFC9256"/>
rmat="default" sectionFormat="of" derivedContent="SEGMENT-ROUTING"/> and Loop-Fr and Loop-Free
ee Alternates (LFAs) <xref target="RFC5286"/>. This has introduced ambiguity
Alternates (LFAs) <xref target="RFC5286" format="default" sectionFormat="o
f" derivedContent="RFC5286"/>. This has introduced 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 indent="0" pn="section-1-5">An example of where this ambiguity causes a problem is a network where <t>An example of 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 that RSVP-TE is enabled on that link, even though it is not. If
such an RSVP-TE head-end router tries to set up 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 setup failure for the path.</t>
<t indent="0" pn="section-1-6">An additional issue arises in cases where b <t>An additional issue arises in cases where both applications are
oth 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 indent="0" pn="section-1-7">This document defines extensions that addre ss 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" removeInRFC="false" toc="includ <section anchor="req-lang">
e" pn="section-1.1"> <name>Requirements Language</name>
<name slugifiedName="name-requirements-language">Requirements Language</ <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
name> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
<t indent="0" pn="section-1.1-1"> "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU "<bcp14>SHOULD NOT</bcp14>",
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
OT RECOMMENDED</bcp14>", are to be interpreted as described in BCP&nbsp;14
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
be interpreted as when, they appear in all capitals, as shown here.</t>
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="REQDIS" numbered="true" toc="include" removeInRFC="false" p <section anchor="REQDIS">
n="section-2"> <name>Requirements Discussion</name>
<name slugifiedName="name-requirements-discussion">Requirements Discussion <t>As stated previously, evolution of use cases for link attributes can
</name>
<t indent="0" pn="section-2-1">As stated previously, evolution of use case
s 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" indent="adaptive" start="1" pn="section-2-2" <ol>
> <li>Support for indicating which applications are using the link
<li pn="section-2-2.1" derivedCounter="1.">Support for indicating which attribute advertisements on a link.</li>
applications are using the link <li>Support for advertising application-specific values for the same
attribute advertisements on a link</li> attribute on a link.</li>
<li pn="section-2-2.2" derivedCounter="2.">Support for advertising appli
cation-specific values for the same
attribute on a link</li>
</ol> </ol>
<t indent="0" pn="section-2-3"><xref target="RFC7855" format="default" sec <t><xref target="RFC7855"/> discusses use cases and requirements for SR. I
tionFormat="of" derivedContent="RFC7855"/> discusses use cases and requirements ncluded among these use cases is SR Policy, which is defined in
for Segment Routing <xref target="RFC9256"/>. If both RSVP-TE
(SR). Included among these use cases is SR Policy, which is defined in
<xref target="RFC9256" format="default" sectionFormat="of" derivedContent=
"SEGMENT-ROUTING"/>. 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. can be used by one or both of these applications.
There is no requirement for the link attributes advertised on a given link There is no requirement for the link attributes advertised on a given link
used by SR Policy to be identical to the link attributes advertised on that used by SR Policy to be identical to the link attributes advertised on that
same link used by RSVP-TE; thus, there is a clear requirement to indicate same link used by RSVP-TE; thus, there is a clear requirement to indicate
independently which link attribute advertisements are to be used by each independently which link attribute advertisements are to be used by each
application.</t> application.</t>
<t indent="0" pn="section-2-4">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 backwards-compatibility issues.</t>
<t indent="0" pn="section-2-5">Finally, there may still be many cases wher <t>Finally, there may still be many cases where a single attribute value
e 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="include" removeInRFC="false" p <section anchor="LEGADV">
n="section-3"> <name>Legacy Advertisements</name>
<name slugifiedName="name-legacy-advertisements">Legacy Advertisements</na <t>Existing advertisements used in support of RSVP-TE include sub-TLVs for
me> TLVs Advertising Neighbor Information and TLVs for Shared Risk Link Group
<t indent="0" pn="section-3-1">Existing advertisements used in support of (SRLG) advertisements.</t>
RSVP-TE include sub-TLVs for <t>Sub-TLV values are defined in the "IS-IS Sub-TLVs for TLVs Advertising
TLVs Advertising Neighbor Information and TLVs for Shared Risk Link Group Neighbor Information" registry.</t>
(SRLG) advertisement.</t> <t>TLVs are defined in the "IS-IS TLV Codepoints" registry.</t>
<t indent="0" pn="section-3-2">Sub-TLV values are defined in the "IS-IS su <section anchor="LEGSUB">
b-TLVs for TLVs Advertising Neighbor Information" registry.</t> <name>Legacy Sub-TLVs</name>
<t indent="0" pn="section-3-3">TLVs are defined in the "TLV Codepoints Reg <table anchor="legacysub">
istry".</t>
<section anchor="LEGSUB" numbered="true" toc="include" removeInRFC="false"
pn="section-3.1">
<name slugifiedName="name-legacy-sub-tlvs">Legacy Sub-TLVs</name>
<table anchor="legacysub" align="left" pn="table-1">
<name slugifiedName="name-sub-tlvs-for-tlvs-22-23-25-">Sub-TLVs for TL
Vs Advertising Neighbor Information</name>
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1"> Type </th> <th> Type </th>
<th align="left" colspan="1" rowspan="1"> Description </th> <th> Description </th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 3 </td> <td> 3 </td>
<td align="left" colspan="1" rowspan="1"> Administrative group (co <td> Administrative group (color) </td>
lor) </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 9 </td> <td> 9 </td>
<td align="left" colspan="1" rowspan="1"> Maximum link bandwidth</ <td> Maximum link bandwidth</td>
td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 10 </td> <td> 10 </td>
<td align="left" colspan="1" rowspan="1"> Maximum reservable link <td> Maximum reservable link bandwidth </td>
bandwidth </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 11 </td> <td> 11 </td>
<td align="left" colspan="1" rowspan="1"> Unreserved bandwidth </t <td> Unreserved bandwidth </td>
d>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 14 </td> <td> 14 </td>
<td align="left" colspan="1" rowspan="1"> Extended Administrative <td> Extended Administrative Group </td>
Group </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 18 </td> <td> 18 </td>
<td align="left" colspan="1" rowspan="1"> TE Default Metric </td> <td> TE Default metric </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 33 </td> <td> 33 </td>
<td align="left" colspan="1" rowspan="1"> Unidirectional Link Dela <td> Unidirectional Link Delay </td>
y </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 34 </td> <td> 34 </td>
<td align="left" colspan="1" rowspan="1"> Min/Max Unidirectional <td> Min/Max Unidirectional Link Delay </td>
Link Delay </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 35 </td> <td> 35 </td>
<td align="left" colspan="1" rowspan="1"> Unidirectional Delay Var <td> Unidirectional Delay Variation </td>
iation </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 36 </td> <td> 36 </td>
<td align="left" colspan="1" rowspan="1"> Unidirectional Link Loss <td> Unidirectional Link Loss </td>
</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 37 </td> <td> 37 </td>
<td align="left" colspan="1" rowspan="1"> Unidirectional Residual <td> Unidirectional Residual Bandwidth </td>
Bandwidth </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 38 </td> <td> 38 </td>
<td align="left" colspan="1" rowspan="1"> Unidirectional Available <td> Unidirectional Available Bandwidth</td>
Bandwidth</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 39 </td> <td> 39 </td>
<td align="left" colspan="1" rowspan="1"> Unidirectional Utilized <td> Unidirectional Utilized Bandwidth </td>
Bandwidth </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="LEGSRLG" numbered="true" toc="include" removeInRFC="false <section anchor="LEGSRLG">
" pn="section-3.2"> <name>Legacy SRLG Advertisements</name>
<name slugifiedName="name-legacy-srlg-advertisements">Legacy SRLG Advert <dl newline="true">
isements</name> <dt>TLV 138 (GMPLS-SRLG):</dt>
<dl newline="true" indent="3" spacing="normal" pn="section-3.2-1"> <dd>Supports links identified by IPv4 addresses and
<dt pn="section-3.2-1.1">TLV 138 (GMPLS-SRLG):</dt>
<dd pn="section-3.2-1.2">Supports links identified by IPv4 addresses a
nd
unnumbered links.</dd> unnumbered links.</dd>
<dt pn="section-3.2-1.3">TLV 139 (IPv6 SRLG):</dt> <dt>TLV 139 (IPv6 SRLG):</dt>
<dd pn="section-3.2-1.4"> Supports links identified by IPv6 addresses. <dd> Supports links identified by IPv6 addresses.</dd>
</dd>
</dl> </dl>
<t indent="0" pn="section-3.2-2">Note that <xref target="RFC6119" format ="default" sectionFormat="of" derivedContent="RFC6119"/> prohibits the <t>Note that <xref target="RFC6119"/> prohibits the
use of TLV 139 when it is possible to use TLV 138.</t> use of TLV 139 when it is possible to use TLV 138.</t>
</section> </section>
</section> </section>
<section anchor="ASLA" numbered="true" toc="include" removeInRFC="false" pn= <section anchor="ASLA">
"section-4"> <name>Advertising Application-Specific Link Attributes</name>
<name slugifiedName="name-advertising-application-spe">Advertising Applica <t>Two codepoints are defined to support Application-Specific
tion-Specific Link Attributes</name>
<t indent="0" pn="section-4-1">Two new codepoints are defined to support A
pplication-Specific
Link Attribute (ASLA) advertisements:</t> Link Attribute (ASLA) advertisements:</t>
<ol type="%d)" indent="adaptive" spacing="normal" start="1" pn="section-4- <ol>
2"> <li>Application-Specific Link Attributes sub-TLV for TLVs Advertising Neig
<li pn="section-4-2.1" derivedCounter="1)">Application-Specific Link Attri hbor Information (defined in <xref target="ASLASUB"/>).</li>
butes sub-TLV for TLVs Advertising Neighbor Information (defined in <xref target <li>Application-Specific SRLG TLV (defined in
="ASLASUB" format="default" sectionFormat="of" derivedContent="Section 4.2"/>).< <xref target="ASSRLGTLV"/>).</li>
/li>
<li pn="section-4-2.2" derivedCounter="2)">Application-Specific Shared R
isk Link Group (SRLG) TLV (defined in
<xref target="ASSRLGTLV" format="default" sectionFormat="of" derivedConten
t="Section 4.3"/>).</li>
</ol> </ol>
<t indent="0" pn="section-4-3">To support these new advertisements, an <t>To support these advertisements, an
application identifier bit mask is defined to identify the application(s) application identifier bit mask is defined to identify the application(s)
associated with a given advertisement (defined in <xref target="AIBM" form associated with a given advertisement (defined in <xref target="AIBM"/>).<
at="default" sectionFormat="of" derivedContent="Section 4.1"/>).</t> /t>
<t indent="0" pn="section-4-4">In addition to supporting the advertisement <t>In addition to supporting the advertisement of link attributes used
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 (UDAs). 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 indent="0" pn="section-4-5">The following sections define the format of these new <t>The following sections define the format of these
advertisements.</t> advertisements.</t>
<section anchor="AIBM" numbered="true" toc="include" removeInRFC="false" p <section anchor="AIBM">
n="section-4.1"> <name>Application Identifier Bit Mask</name>
<name slugifiedName="name-application-identifier-bit-">Application Ident <t>Identification of the set of applications associated with link
ifier Bit Mask</name>
<t indent="0" pn="section-4.1-1">Identification of the set of applicatio
ns 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 an
new IANA-controlled registry (see <xref target="IANA4" format="default" IANA-controlled registry (see <xref target="IANA4"/>). A second
sectionFormat="of" derivedContent="Section 7.4"/>). A second bit mask is for non-standard 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 indent="0" pn="section-4.1-2">The encoding defined below is used by b
oth 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>
<artwork name="" type="" align="left" alt="" pn="section-4.1-3"> <artwork name="" type="" alt="">
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> </artwork>
<dl newline="false" indent="3" spacing="normal" pn="section-4.1-4"> <dl newline="true">
<dt pn="section-4.1-4.1">SABM Length + Flag (1 octet):</dt> <dt>SABM Length + Flag (1 octet):</dt>
<dd pn="section-4.1-4.2"> <dd>
<t indent="0" pn="section-4.1-4.2.1"> Standard Application Identifie <t> Standard Application Identifier Bit Mask Length + Flag</t>
r Bit Mask Length + Flag</t> <artwork>
<artwork align="left" pn="section-4.1-4.2.2">
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|L| SABM Length | |L| SABM Length |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
</artwork> </artwork>
<dl indent="3" newline="false" spacing="normal" pn="section-4.1-4.2. <dl newline="true">
3"> <dt>L-flag:</dt>
<dt pn="section-4.1-4.2.3.1">L-flag:</dt> <dd>Legacy Flag.
<dd pn="section-4.1-4.2.3.2">Legacy Flag. See <xref target="ASLASUB"/> for a description of how
See <xref target="ASLASUB" format="default" sectionFormat="of" derivedConten
t="Section 4.2"/> for a description of how
this flag is used.</dd> this flag is used.</dd>
<dt pn="section-4.1-4.2.3.3">SABM Length:</dt> <dt>SABM Length:</dt>
<dd pn="section-4.1-4.2.3.4">Indicates the length in octets (0-8) <dd>This field indicates the length in octets (0-8) of the
of the
Standard Application Identifier Bit Mask. The length <bcp14>SHOULD</bcp14> Standard Application Identifier Bit Mask. The length <bcp14>SHOULD</bcp14>
be the minimum required to send all bits that are set.</dd> be the minimum required to send all bits that are set.</dd>
</dl> </dl>
</dd> </dd>
<dt pn="section-4.1-4.3">UDABM Length + Flag (1 octet):</dt> <dt>UDABM Length + Flag (1 octet):</dt>
<dd pn="section-4.1-4.4"> <dd>
<t indent="0" pn="section-4.1-4.4.1"> User-Defined Application Ident <t> User-Defined Application Identifier Bit Mask Length + Flag</t>
ifier Bit Mask Length + Flag</t> <artwork>
<artwork align="left" pn="section-4.1-4.4.2">
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|R| UDABM Length| |R| UDABM Length|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
</artwork> </artwork>
<dl indent="3" newline="false" spacing="normal" pn="section-4.1-4.4. <dl newline="true">
3"> <dt>R:</dt>
<dt pn="section-4.1-4.4.3.1">R:</dt> <dd> Reserved. <bcp14>SHOULD</bcp14> be transmitted as 0 and
<dd pn="section-4.1-4.4.3.2"> Reserved. <bcp14>SHOULD</bcp14> be t
ransmitted as 0 and
<bcp14>MUST</bcp14> be ignored on receipt.</dd> <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt pn="section-4.1-4.4.3.3">UDABM Length:</dt> <dt>UDABM Length:</dt>
<dd pn="section-4.1-4.4.3.4"> Indicates the length in octets (0-8) <dd> Indicates the length in octets (0-8) of the
of the
User-Defined Application Identifier Bit Mask. The length <bcp14>SHOULD</bcp1 4> User-Defined Application Identifier Bit Mask. The length <bcp14>SHOULD</bcp1 4>
be the minimum required to send all bits that are set.</dd> be the minimum required to send all bits that are set.</dd>
</dl> </dl>
</dd> </dd>
<dt pn="section-4.1-4.5">SABM (variable length):</dt> <dt>SABM (variable length):</dt>
<dd pn="section-4.1-4.6"> <dd>
<t indent="0" pn="section-4.1-4.6.1"> Standard Application Identifie <t> Standard Application Identifier Bit Mask</t>
r Bit Mask</t> <t> (SABM Length * 8) bits</t>
<t indent="0" pn="section-4.1-4.6.2"> (SABM Length * 8) bits</t> <t>This field is omitted if SABM Length is 0.</t>
<t indent="0" pn="section-4.1-4.6.3">This field is omitted if SABM L <artwork>
ength is 0.</t>
<artwork align="left" pn="section-4.1-4.6.4">
0 1 2 3 4 5 6 7 ... 0 1 2 3 4 5 6 7 ...
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
|R|S|F| ... |R|S|F| ...
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
</artwork> </artwork>
<dl indent="3" newline="false" spacing="normal" pn="section-4.1-4.6. <dl newline="true">
5"> <dt> R-bit:</dt>
<dt pn="section-4.1-4.6.5.1"> R-bit:</dt> <dd>Set to specify RSVP-TE.</dd>
<dd pn="section-4.1-4.6.5.2">Set to specify RSVP-TE.</dd> <dt> S-bit:</dt>
<dt pn="section-4.1-4.6.5.3"> S-bit:</dt> <dd>Set to specify SR Policy
<dd pn="section-4.1-4.6.5.4">Set to specify Segment Routing Policy (this is data plane independent).</dd>
(this is dataplane independent).</dd> <dt> F-bit:</dt>
<dt pn="section-4.1-4.6.5.5"> F-bit:</dt> <dd>Set to specify an LFA
<dd pn="section-4.1-4.6.5.6">Set to specify Loop-Free Alternate (L
FA)
(includes all LFA types).</dd> (includes all LFA types).</dd>
</dl> </dl>
</dd> </dd>
<dt pn="section-4.1-4.7">UDABM (variable length):</dt> <dt>UDABM (variable length):</dt>
<dd pn="section-4.1-4.8"> <dd>
<t indent="0" pn="section-4.1-4.8.1"> User-Defined Application Ident <t> User-Defined Application Identifier Bit Mask</t>
ifier Bit Mask</t> <t>(UDABM Length * 8) bits</t>
<t indent="0" pn="section-4.1-4.8.2">(UDABM Length * 8) bits</t> <artwork>
<artwork align="left" pn="section-4.1-4.8.3">
0 1 2 3 4 5 6 7 ... 0 1 2 3 4 5 6 7 ...
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
| ... | ...
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
</artwork> </artwork>
<t indent="0" pn="section-4.1-4.8.4"> This field is omitted if UDABM Length is 0.</t> <t> This field is omitted if UDABM Length is 0.</t>
</dd> </dd>
</dl> </dl>
<aside pn="section-4.1-5"> <aside>
<t indent="0" pn="section-4.1-5.1"> <t>
Note: SABM/UDABM Length is arbitrarily limited to 8 octets Note: SABM/UDABM Length is arbitrarily limited to 8 octets
in order to ensure that sufficient space is left to advertise link in order to ensure that sufficient space is left to advertise link
attributes without overrunning the maximum length of a sub-TLV.</t> attributes without overrunning the maximum length of a sub-TLV.</t>
</aside> </aside>
<t indent="0" pn="section-4.1-6">Standard Application Identifier Bits ar e defined and sent starting with <t>Standard Application Identifier Bits are defined and sent starting wi th
bit 0.</t> bit 0.</t>
<t indent="0" pn="section-4.1-7">User-Defined Application Identifier Bit s have no relationship to <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 be 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 indent="0" pn="section-4.1-8">For both SABM and UDABM, the following <t>For both the SABM and UDABM, the following rules apply:</t>
rules apply:</t> <ul>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4 <li>Undefined bits that are transmitted <bcp14>MUST</bcp14> be transmi
.1-9"> tted as 0
<li pn="section-4.1-9.1">Undefined bits that are transmitted <bcp14>MU
ST</bcp14> be transmitted as 0
and <bcp14>MUST</bcp14> be ignored on receipt.</li> and <bcp14>MUST</bcp14> be ignored on receipt.</li>
<li pn="section-4.1-9.2">Bits that are not transmitted <bcp14>MUST</bc p14> be treated as if they are <li>Bits that are not transmitted <bcp14>MUST</bcp14> be treated as if they are
set to 0 on receipt.</li> set to 0 on receipt.</li>
<li pn="section-4.1-9.3">Bits that are not supported by an implementat ion <bcp14>MUST</bcp14> be <li>Bits that are not supported by an implementation <bcp14>MUST</bcp1 4> be
ignored on receipt.</li> ignored on receipt.</li>
</ul> </ul>
</section> </section>
<section anchor="ASLASUB" numbered="true" toc="include" removeInRFC="false <section anchor="ASLASUB">
" pn="section-4.2"> <name>Application-Specific Link Attributes Sub-TLV</name>
<name slugifiedName="name-application-specific-link-a">Application-Speci <t>A sub-TLV for TLVs Advertising Neighbor Information is defined
fic Link Attributes Sub-TLV</name>
<t indent="0" pn="section-4.2-1">A new sub-TLV for TLVs Advertising Neig
hbor Information 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>
<dl indent="3" newline="false" spacing="normal" pn="section-4.2-2"> <dl newline="true">
<dt pn="section-4.2-2.1">Type:</dt> <dt>Type:</dt>
<dd pn="section-4.2-2.2"> 16</dd> <dd> 16</dd>
<dt pn="section-4.2-2.3">Length:</dt> <dt>Length:</dt>
<dd pn="section-4.2-2.4"> Variable (1 octet)</dd> <dd> Variable (1 octet)</dd>
<dt pn="section-4.2-2.5">Value:</dt> </dl>
<dd pn="section-4.2-2.6"> <dl newline="true">
<ul empty="true" bare="false" indent="3" spacing="normal" pn="sectio <dt>Value:</dt>
n-4.2-2.6.1"> <dd><t>Application Identifier Bit Mask
<li pn="section-4.2-2.6.1.1">Application Identifier Bit Mask (as defined in <xref target="AIBM"/>)</t>
(as defined in <xref target="AIBM" format="default" sectionFormat="of" <t>Link Attribute sub-sub-TLVs -- format matches the
derivedContent="Section 4.1"/>)</li> existing formats defined in <xref target="RFC5305"/>, <xref target="RFC
<li pn="section-4.2-2.6.1.2"> Link Attribute sub-sub-TLVs -- forma 7308"/>,
t matches the and <xref target="RFC8570"/></t>
existing formats defined in <xref target="RFC5305" format="default" sec
tionFormat="of" derivedContent="RFC5305"/>, <xref target="RFC7308" format="defau
lt" sectionFormat="of" derivedContent="RFC7308"/>,
and <xref target="RFC8570" format="default" sectionFormat="of" derivedCo
ntent="RFC8570"/></li>
</ul>
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-4.2-3">If the SABM or UDABM Length in the Appl ication Identifier Bit Mask <t>If the SABM Length or UDABM Length in the Application Identifier Bit Mask
is greater than 8, the entire sub-TLV <bcp14>MUST</bcp14> be ignored.</t > is greater than 8, the entire sub-TLV <bcp14>MUST</bcp14> be ignored.</t >
<t indent="0" pn="section-4.2-4">When SABM or UDABM Length is non-zero a <t>When the SABM Length or UDABM Length is non-zero and the L-flag is NO
nd the L-flag is NOT set, all T set, all
applications specified in the bit mask MUST use the link attribute advert applications specified in the bit mask <bcp14>MUST</bcp14> use the link a
isements in the sub-TLV.</t> ttribute advertisements in the sub-TLV.</t>
<t indent="0" pn="section-4.2-5">When the L-flag is set in the Applicati <t>When the L-flag is set in the Application Identifier Bit Mask, all
on Identifier Bit Mask, all
of the applications specified in the bit mask <bcp14>MUST</bcp14> use th e legacy of the applications specified in the bit mask <bcp14>MUST</bcp14> use th e legacy
advertisements for the corresponding link found in TLVs Advertising Neig hbor Information. Link attribute advertisements for the corresponding link found in TLVs Advertising Neig hbor Information. Link attribute
sub-sub-TLVs for the corresponding link attributes <bcp14>MUST NOT</bcp1 4> be sub-sub-TLVs for the corresponding link attributes <bcp14>MUST NOT</bcp1 4> be
advertised for the set of applications specified in the Standard or User advertised for the set of applications specified in the Standard Applica
-Defined tion Identifier Bit Mask or the User-Defined
Application Identifier Bit Masks, and all such sub-sub-TLVs <bcp14>MUST< Application Identifier Bit Mask, and all such sub-sub-TLVs <bcp14>MUST</
/bcp14> be bcp14> be
ignored on receipt.</t> ignored on receipt.</t>
<t indent="0" pn="section-4.2-6">Multiple Application-Specific Link Attr ibutes sub-TLVs for the same <t>Multiple Application-Specific Link Attributes sub-TLVs for the same
link <bcp14>MAY</bcp14> be advertised. When multiple sub-TLVs for the sa me link are link <bcp14>MAY</bcp14> be advertised. When multiple sub-TLVs for the sa me link are
advertised, they <bcp14>SHOULD</bcp14> 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 <bcp14>MUST</bcp14> be used, and sub sequent received in the lowest-numbered Link State Protocol Data Unit (LSP) <bcp 14>MUST</bcp14> be used, and subsequent
advertisements of the same attribute <bcp14>MUST</bcp14> be ignored.</t> advertisements of the same attribute <bcp14>MUST</bcp14> be ignored.</t>
<t indent="0" pn="section-4.2-7">For a given application, the setting of the L-flag <bcp14>MUST</bcp14> be the same <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 <bcp14>MUST</bcp14> be considered set for this violated, the L-flag <bcp14>MUST</bcp14> be considered set for this
application.</t> application.</t>
<t indent="0" pn="section-4.2-8">The end result of the set of rules defi <t>The end result of the set of rules defined above is that for a given
ned above is that for a given application either the attribute values advertised application either the attribute values advertised in ASLA sub-sub-TLVs are used
in ASLA sub-sub-TLVs are used or the attribute values advertised in Legacy sub- or the attribute values advertised in legacy sub-TLVs are used, but not both.</
TLVs are used, but not both.</t> t>
<t indent="0" pn="section-4.2-9">Link attributes <bcp14>MAY</bcp14> be ad <t>Link attributes <bcp14>MAY</bcp14> be advertised associated with
vertised associated with zero-length Application Identifier Bit Masks for both standard applicatio
zero-length Application Identifier Bit Masks for both standard applicatio ns and UDAs.
ns and user-defined applications. Such link attribute advertisements <bcp14>MUST</bcp14> be used by standar
Such link attribute advertisements <bcp14>MUST</bcp14> be used by standar d applications and/or
d applications and/or user defined UDAs when no link attribute advertisements with a non-zero-length Applica
applications when no link attribute advertisements with a non-zero-length tion Identifier
Application Identifier
Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise,
such link attribute advertisements <bcp14>MUST NOT</bcp14> be used.</t> such link attribute advertisements <bcp14>MUST NOT</bcp14> be used.</t>
<t indent="0" pn="section-4.2-10">IANA has created a new registry of sub <t>IANA has created a registry of sub-sub-TLVs to define the link
-sub-TLVs to define the link attribute sub-sub-TLV codepoints (see <xref target="IANA3"/>). This
attribute sub-sub-TLV codepoints (see <xref target="IANA3" format="defau
lt" sectionFormat="of" derivedContent="Section 7.3"/>). This
document defines a sub-sub-TLV for each of the existing sub-TLVs document defines a sub-sub-TLV for each of the existing sub-TLVs
listed in <xref target="LEGSUB" format="default" sectionFormat="of" deri vedContent="Section 3.1"/>, except as noted listed in <xref target="LEGSUB"/>, except as noted
below. The format of the sub-sub-TLVs matches the format of the below. The format of the sub-sub-TLVs matches the format of the
corresponding legacy sub-TLV, and IANA has assigned the legacy sub-TLV corresponding legacy sub-TLV, and IANA has assigned the legacy sub-TLV
identifier to the corresponding sub-sub-TLV.</t> identifier to the corresponding sub-sub-TLV.</t>
<section anchor="SCMLB" numbered="true" toc="include" removeInRFC="false <section anchor="SCMLB">
" pn="section-4.2.1"> <name>Special Considerations for Maximum Link Bandwidth</name>
<name slugifiedName="name-special-considerations-for-">Special Conside <t>Maximum link bandwidth is an application-independent attribute of
rations for Maximum Link Bandwidth</name>
<t indent="0" pn="section-4.2.1-1">Maximum link bandwidth is an applic
ation-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 <bcp14>MUST NOT< /bcp14> 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 indent="0" pn="section-4.2.1-2">It is also possible to advertise th e 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 indent="0" pn="section-4.2.1-3">It is also possible to advertise a single advertisement with <t>It is also possible to advertise a single advertisement with a
zero-length SABM and UDABM so long as the constraints discussed in zero-length SABM and UDABM so long as the constraints discussed in
Sections <xref target="ASLASUB" format="counter" sectionFormat="of" de Sections&nbsp;<xref target="ASLASUB" format="counter"/> and <xref targ
rivedContent="4.2"/> and <xref target="DEPZERO" format="counter" sectionFormat=" et="DEPZERO" format="counter"/> are satisfied.</t>
of" derivedContent="6.2"/> are acceptable.</t> <t>If different values for maximum link bandwidth for a given link
<t indent="0" pn="section-4.2.1-4">If different values for maximum lin
k bandwidth for a given link
are advertised, all values <bcp14>MUST</bcp14> be ignored.</t> are advertised, all values <bcp14>MUST</bcp14> be ignored.</t>
</section> </section>
<section anchor="SCUB" numbered="true" toc="include" removeInRFC="false" <section anchor="SCUB">
pn="section-4.2.2"> <name>Special Considerations for Reservable/Unreserved Bandwidth</name
<name slugifiedName="name-special-considerations-for-r">Special Consid >
erations for Reservable/Unreserved Bandwidth</name> <t>Maximum reservable link bandwidth and unreserved bandwidth are
<t indent="0" pn="section-4.2.2-1">Maximum reservable link bandwidth a
nd 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) <bcp14>MUST NOT</bcp14> be set in the Application Iden tifier Bit RSVP-TE bit (R-bit) <bcp14>MUST NOT</bcp14> be set in the Application Identifier Bit
Mask. If an advertisement of maximum reservable link bandwidth or Mask. If an advertisement of maximum reservable link bandwidth or
unreserved bandwidth is received with bits other than the RSVP-TE unreserved bandwidth is received with bits other than the R-bit
bit set, the advertisement <bcp14>MUST</bcp14> be ignored.</t> set, the advertisement <bcp14>MUST</bcp14> be ignored.</t>
</section> </section>
<section anchor="EXTTE" numbered="true" toc="include" removeInRFC="false <section anchor="EXTTE">
" pn="section-4.2.3"> <name>Considerations for Extended TE Metrics</name>
<name slugifiedName="name-considerations-for-extended">Considerations <t><xref target="RFC8570"/> defines a number of dynamic performance
for Extended TE Metrics</name>
<t indent="0" pn="section-4.2.3-1"><xref target="RFC8570" format="defa
ult" sectionFormat="of" derivedContent="RFC8570"/> defines a number of dynamic p
erformance
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 by either explicitly specifying the
applications in the Application Identifier Bit Mask or by using a applications in the Application Identifier Bit Mask or using a
zero-length Application Identifier Bit Mask. The use of zero-length Ap zero-length Application Identifier Bit Mask. The use of zero-length Ap
plication Identifier Bit Mask is further discussed in <xref target="DEPZERO" for plication Identifier Bit Masks is further discussed in <xref target="DEPZERO"/>.
mat="default" sectionFormat="of" derivedContent="Section 6.2"/>.</t> </t>
</section> </section>
</section> </section>
<section anchor="ASSRLGTLV" numbered="true" toc="include" removeInRFC="fal <section anchor="ASSRLGTLV">
se" pn="section-4.3"> <name>Application-Specific SRLG TLV</name>
<name slugifiedName="name-application-specific-srlg-t">Application-Speci <t>A TLV is defined to advertise application-specific SRLGs for a
fic SRLG TLV</name> given link. Although similar in functionality to TLV 138 <xref target="R
<t indent="0" pn="section-4.3-1">A new TLV is defined to advertise appli FC5307"/> and
cation-specific SRLGs for a TLV 139 <xref target="RFC6119"/>, this single TLV provides support for I
given link. Although similar in functionality to TLV 138 <xref target="R Pv4, IPv6, and
FC5307" format="default" sectionFormat="of" derivedContent="RFC5307"/> and
TLV 139 <xref target="RFC6119" format="default" sectionFormat="of" deriv
edContent="RFC6119"/>, a single TLV provides support for IPv4, IPv6, and
unnumbered identifiers for a link. Unlike TLVs 138 and 139, it utilizes 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>
<dl indent="3" newline="false" spacing="normal" pn="section-4.3-2"> <dl newline="true">
<dt pn="section-4.3-2.1">Type:</dt> <dt>Type:</dt>
<dd pn="section-4.3-2.2"> 238</dd> <dd> 238</dd>
<dt pn="section-4.3-2.3"> Length:</dt> <dt> Length:</dt>
<dd pn="section-4.3-2.4"> Number of octets in the value field (1 octet <dd> Number of octets in the value field (1 octet)</dd>
)</dd> </dl>
<dt pn="section-4.3-2.5">Value:</dt> <dl newline="true">
<dd pn="section-4.3-2.6"> <dt>Value:</dt>
<ul empty="true" bare="false" indent="3" spacing="normal" pn="sectio <dd><t>Neighbor System-ID + pseudonode ID (7 octets)</t>
n-4.3-2.6.1"> <t>Application Identifier Bit Mask
<li pn="section-4.3-2.6.1.1">Neighbor System-ID + pseudonode ID (7 (as defined in <xref target="AIBM"/>)</t>
octets)</li> <t>Length of sub-TLVs (1 octet)</t>
<li pn="section-4.3-2.6.1.2"> Application Identifier Bit Mask <t>Link Identifier sub-TLVs (variable)</t>
(as defined in <xref target="AIBM" format="default" sectionFormat="of" de <t>0 or more SRLG values (each value is 4 octets)</t>
rivedContent="Section 4.1"/>)</li>
<li pn="section-4.3-2.6.1.3"> Length of sub-TLVs (1 octet)</li>
<li pn="section-4.3-2.6.1.4"> Link Identifier sub-TLVs (variable)<
/li>
<li pn="section-4.3-2.6.1.5"> 0 or more SRLG values (each value is
4 octets)</li>
</ul>
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-4.3-3">If the SABM or UDABM Length in the Appl <t>If the SABM Length or UDABM Length in the Application Identifier Bit
ication Identifier Bit Mask Mask
is greater than 8, the entire sub-TLV <bcp14>MUST</bcp14> be ignored.</t is greater than 8, the entire sub-TLV <bcp14>MUST</bcp14> be ignored.</t
> <t indent="0" pn="section-4.3-4">When SABM or UDABM Length is non-zero >
and the L-flag is NOT set, all <t>When the SABM Length or UDABM Length is non-zero and the L-flag is NO
applications specified in the bit mask MUST use SRLG advertisements in th T set, all
e Application-Specific SRLG TLV.</t> applications specified in the bit mask <bcp14>MUST</bcp14> use SRLG adver
<t indent="0" pn="section-4.3-5"> The following Link Identifier sub-TLVs tisements in the Application-Specific SRLG TLV.</t>
are defined. <t> The following Link Identifier sub-TLVs are defined.
The values chosen intentionally match the equivalent The values chosen intentionally match the equivalent
sub-TLVs from <xref target="RFC5305" format="default" sectionFormat="of" deri sub-TLVs from <xref target="RFC5305"/>, <xref target="RFC5307"/>, and <xref t
vedContent="RFC5305"/>, <xref target="RFC5307" format="default" sectionFormat="o arget="RFC6119"/>.</t>
f" derivedContent="RFC5307"/>, and <xref target="RFC6119" format="default" secti <table>
onFormat="of" derivedContent="RFC6119"/>.</t>
<table align="center" pn="table-2">
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1"> Type </th> <th> Type </th>
<th align="left" colspan="1" rowspan="1">Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">4</td> <td>4</td>
<td align="left" colspan="1" rowspan="1">Link Local/Remote Identif <td>Link Local/Remote Identifiers <xref target="RFC5307"/></td>
iers <xref target="RFC5307" format="default" sectionFormat="of" derivedContent="
RFC5307"/></td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">6</td> <td>6</td>
<td align="left" colspan="1" rowspan="1"> IPv4 interface address <td> IPv4 interface address <xref target="RFC5305"/></td>
<xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC53
05"/></td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">8</td> <td>8</td>
<td align="left" colspan="1" rowspan="1">IPv4 neighbor address <xr <td>IPv4 neighbor address <xref target="RFC5305"/></td>
ef target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"
/></td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">12</td> <td>12</td>
<td align="left" colspan="1" rowspan="1"> IPv6 Interface Address < <td> IPv6 Interface Address <xref target="RFC6119"/></td>
xref target="RFC6119" format="default" sectionFormat="of" derivedContent="RFC611
9"/></td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">13</td> <td>13</td>
<td align="left" colspan="1" rowspan="1"> IPv6 Neighbor Address <x <td> IPv6 Neighbor Address <xref target="RFC6119"/></td>
ref target="RFC6119" format="default" sectionFormat="of" derivedContent="RFC6119
"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t indent="0" pn="section-4.3-7">At least one set of link identifiers (I Pv4, IPv6, or Link <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 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 identifier type <bcp14>MUST NOT</bcp14> be present. TLVs that do not mee t this
requirement <bcp14>MUST</bcp14> be ignored.</t> requirement <bcp14>MUST</bcp14> be ignored.</t>
<t indent="0" pn="section-4.3-8">Multiple TLVs for the same link <bcp14> <t>Multiple TLVs for the same link <bcp14>MAY</bcp14> be advertised.</t>
MAY</bcp14> be advertised.</t> <t>When the L-flag is set in the Application Identifier Bit Mask, SRLG
<t indent="0" pn="section-4.3-9">When the L-flag is set in the Applicati
on Identifier Bit Mask, SRLG
values <bcp14>MUST NOT</bcp14> be included in the TLV. Any SRLG values t hat are values <bcp14>MUST NOT</bcp14> be included in the TLV. Any SRLG values t hat are
advertised <bcp14>MUST</bcp14> be ignored. Based on the link identifiers advertised, advertised <bcp14>MUST</bcp14> be ignored. Based on the link identifiers advertised,
the corresponding legacy TLV (see <xref target="LEGSRLG" format="default " sectionFormat="of" derivedContent="Section 3.2"/>) can be the corresponding legacy TLV (see <xref target="LEGSRLG"/>) can be
identified, and the SRLG values advertised in the legacy TLV <bcp14>MUST </bcp14> 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 indent="0" pn="section-4.3-10">For a given application, the setting o f the L-flag <bcp14>MUST</bcp14> be the same <t>For a given application, the setting of the L-flag <bcp14>MUST</bcp14 > 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 <bcp14>MUST</bcp14> be considered set for this appl ication.</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="include" removeInRFC="false" pn=" <section anchor="AAE">
section-5"> <name>Attribute Advertisements and Enablement</name>
<name slugifiedName="name-attribute-advertisements-an">Attribute Advertise <t>This document defines extensions to support the advertisement of
ments and Enablement</name> ASLAs.</t>
<t indent="0" pn="section-5-1">This document defines extensions to support <t>Whether the presence of link attribute advertisements for a given
the advertisement of
application-specific link attributes.</t>
<t indent="0" pn="section-5-2">Whether the presence of link attribute adve
rtisements 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 indent="0" pn="section-5-3">In the case of RSVP-TE, the advertisement o <t>In the case of RSVP-TE, the advertisement of ASLAs
f application-specific 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 ASLAs 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 indent="0" pn="section-5-4">In the case of SR Policy, the advertisement <t>In the case of SR Policy, the advertisement of ASLAs
of application-specific link 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 SR-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 indent="0" pn="section-5-5">In the case of LFA, the advertisement of ap <t>In the case of LFA, the advertisement of ASLAs
plication-specific link 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 indent="0" pn="section-5-6">In the future, if additional standard appli cations are defined to <t>In the future, if additional standard applications are defined to
use this mechanism, the specification defining this use <bcp14>MUST</bcp14 > define the use this mechanism, the specification defining this use <bcp14>MUST</bcp14 > define the
relationship between application-specific link attribute advertisements relationship between ASLA advertisements
and enablement for that application.</t> and enablement for those applications.</t>
<t indent="0" pn="section-5-7">This document allows the advertisement of a <t>This document allows the advertisement of ASLAs
pplication-specific link with no application identifiers, i.e., neither the Standard
attributes with no application identifiers, i.e., both the Standard Application Identifier Bit Mask nor the User-Defined Application
Application Identifier Bit Mask and the User-Defined Application Identifier Bit Mask is present (see <xref target="AIBM"/>). This supports
Identifier Bit Mask are not present (see <xref target="AIBM" format="defau the
lt" sectionFormat="of" derivedContent="Section 4.1"/>). This supports 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 us ed to infer the enablement of an application on that link (e.g., application where the advertisement of link attributes is used to infer th e 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="include" removeInRFC="false" <section anchor="DEPCONS">
pn="section-6"> <name>Deployment Considerations</name>
<name slugifiedName="name-deployment-considerations">Deployment Considerat <t>This section discusses deployment considerations associated with the
ions</name> use of ASLA advertisements.</t>
<t indent="0" pn="section-6-1">This section discusses deployment considera <section anchor="DEPLEGACY">
tions associated with the <name>Use of Legacy Advertisements</name>
use of application-specific link attribute advertisements.</t> <t>Bit identifiers for standard applications are defined in <xref target
<section anchor="DEPLEGACY" numbered="true" toc="include" removeInRFC="fal ="AIBM"/>. All of the identifiers defined in this document are
se" pn="section-6.1">
<name slugifiedName="name-use-of-legacy-advertisement">Use of Legacy Adv
ertisements</name>
<t indent="0" pn="section-6.1-1">Bit identifiers for standard applicatio
ns are defined in <xref target="AIBM" format="default" sectionFormat="of" derive
dContent="Section 4.1"/>. 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" bare="false" empty="false" indent="3" pn="section-6 <ul>
.1-2"> <li>The application is RSVP-TE.</li>
<li pn="section-6.1-2.1">The application is RSVP-TE.</li> <li>The application is SR Policy or LFA, and RSVP-TE is not deployed
<li pn="section-6.1-2.2">The application is SR Policy or LFA, and RSVP
-TE is not deployed
anywhere in the network.</li> anywhere in the network.</li>
<li pn="section-6.1-2.3">The application is SR Policy or LFA, RSVP-TE is deployed in the <li>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 are 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.</li> links and attribute values used by RSVP-TE.</li>
</ul> </ul>
<t indent="0" pn="section-6.1-3">Under the conditions defined above, imp lementations 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. support of SR Policy and/or LFA.
This will require implementations to This will require implementations to
provide controls specifying which types of advertisements are to be provide controls specifying which types of advertisements are to be
sent and processed on receipt for these applications. Further discussion sent and processed on receipt for these applications. Further discussion
of the associated issues can be found in <xref target="IBCMC" format="de of the associated issues can be found in <xref target="IBCMC"/>.</t>
fault" sectionFormat="of" derivedContent="Section 6.3"/>.</t> <t>New applications that future documents define to make use of the
<t indent="0" pn="section-6.1-4">New applications that future documents
define to make use of the
advertisements defined in this document <bcp14>MUST NOT</bcp14> 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="include" removeInRFC="false <section anchor="DEPZERO">
" pn="section-6.2"> <name>Use of Zero-Length Application Identifier Bit Masks</name>
<name slugifiedName="name-use-of-zero-length-applicat">Use of Zero-Lengt <t>
h Application Identifier Bit Masks</name>
<t indent="0" pn="section-6.2-1">
Link attribute advertisements associated with zero-length Application Link attribute advertisements associated with zero-length Application
Identifier Bit Masks for both standard applications and user-defined Identifier Bit Masks for both standard applications and UDAs
applications are usable by any application, subject to the are usable by any application, subject to the
restrictions specified in <xref target="ASLASUB" format="default" secti restrictions specified in <xref target="ASLASUB"/>. If support for a ne
onFormat="of" derivedContent="Section 4.2"/>. If support for a new w
application is introduced on any node in a network in the presence application is introduced on any node in a network in the presence
of such advertisements, the new application will use these of such advertisements, the new application will use these
advertisements, when the aforementioned restrictions are met. If advertisements, when the aforementioned restrictions are met. If
this is not what is intended, then existing link attribute this is not what is intended, then existing link attribute
advertisements <bcp14>MUST</bcp14> be readvertised with an explicit advertisements <bcp14>MUST</bcp14> be readvertised with an explicit
set of applications specified before a new application is introduced.</ t> set of applications specified before a new application is introduced.</ t>
</section> </section>
<section anchor="IBCMC" numbered="true" toc="include" removeInRFC="false" <section anchor="IBCMC">
pn="section-6.3"> <name>Interoperability, Backwards Compatibility, and Migration Concerns<
<name slugifiedName="name-interoperability-backwards-">Interoperability, /name>
Backwards Compatibility, and Migration Concerns</name> <t>Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the
<t indent="0" pn="section-6.3-1">Existing deployments of RSVP-TE, SR Pol legacy advertisements listed in <xref target="LEGADV"/>. Routers that do
icy, and/or LFA utilize the not support
legacy advertisements listed in <xref target="LEGADV" format="default" s
ectionFormat="of" derivedContent="Section 3"/>. 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
subsections 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="include" removeInRFC="fa <section anchor="MACARSVP">
lse" pn="section-6.3.1"> <name>Multiple Applications: Common Attributes with RSVP-TE</name>
<name slugifiedName="name-multiple-applications-commo">Multiple Applic <t>In cases where multiple applications are utilizing a given link,
ations: Common Attributes with RSVP-TE</name>
<t indent="0" pn="section-6.3.1-1">In cases where multiple application
s 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 the L-flag set an d 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="include" removeInRFC="fal <section anchor="MAALLNS">
se" pn="section-6.3.2"> <name>Multiple Applications: All Attributes Not Shared with RSVP-TE</n
<name slugifiedName="name-multiple-applications-all-a">Multiple Applic ame>
ations: All Attributes Not Shared with RSVP-TE</name> <t>In cases where one or more applications other than RSVP-TE are
<t indent="0" pn="section-6.3.2-1">In cases where one or more applicat
ions 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 <bcp14>MUST</bcp14> be advertised usin g 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 indent="0" pn="section-6.3.2-2">These guidelines apply to cases whe re 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="include" removeInRFC="fals <section anchor="LEGACY">
e" pn="section-6.3.3"> <name>Interoperability with Legacy Routers</name>
<name slugifiedName="name-interoperability-with-legac">Interoperabilit <t>
y with Legacy Routers</name>
<t indent="0" pn="section-6.3.3-1">
For the standard applications defined in this document, For the standard applications defined in this document,
routers that do not routers that do not
support the extensions defined in this document will send and support the extensions defined in this document will send and
receive only legacy link attribute advertisements. In addition, receive only legacy link attribute advertisements. In addition,
the link attribute values associated with these applications the link attribute values associated with these applications
are always shared since legacy routers have no way of advertising or are always shared, since legacy routers have no way of advertising or
processing application-specific values. So long as there is any processing application-specific values. So long as there is any
legacy router in the network that has any of the standard legacy router in the network that has any of the standard
applications applications
defined in this document enabled, all routers <bcp14>MUST</bcp14> defined in this document enabled, all routers <bcp14>MUST</bcp14>
continue to advertise link attributes for these applications using continue to advertise link attributes for these applications using
only legacy advertisements. ASLA advertisements for these only legacy advertisements. ASLA advertisements for these
applications <bcp14>MUST NOT</bcp14> be sent. Once all legacy applications <bcp14>MUST NOT</bcp14> be sent. Once all legacy
routers have been upgraded, migration from legacy advertisements routers have been upgraded, migration from legacy advertisements
to ASLA advertisements can be achieved via the following steps: to ASLA advertisements can be achieved via the following steps:
</t> </t>
<ol type="%d)" indent="adaptive" spacing="normal" start="1" pn="sectio <ol>
n-6.3.3-2">
<li pn="section-6.3.3-2.1" derivedCounter="1)">Send ASLA advertisement <li>Send ASLA advertisements while continuing to advertise
s while continuing to advertise using legacy advertisements (all advertisements are then duplicated). Receiv
legacy (all advertisements are then duplicated). Receiving routers ing routers
continue to use legacy advertisements.</li> continue to use legacy advertisements.</li>
<li pn="section-6.3.3-2.2" derivedCounter="2)">Enable the use of the <li>Enable the use of the ASLA advertisements on all routers.</li>
ASLA advertisements on all routers.</li> <li>Remove legacy advertisements.</li>
<li pn="section-6.3.3-2.3" derivedCounter="3)">Remove legacy adverti
sements.</li>
</ol> </ol>
<t indent="0" pn="section-6.3.3-3">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 indent="0" pn="section-6.3.3-4">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 indent="0" pn="section-6.3.3-5">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 <bcp14>MU ST</bcp14> application-specific advertisements defined in this document <bcp14>MU ST</bcp14>
discuss interoperability and backwards-compatibility issues that 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" numbered="true" toc="include" removeInRFC="fal <section anchor="APPRSVP">
se" pn="section-6.3.4"> <name>Use of Application-Specific Advertisements for RSVP-TE</name>
<name slugifiedName="name-use-of-application-specific">Use of Applicat <t>The extensions defined in this document include RSVP-TE as one of
ion-Specific Advertisements for RSVP-TE</name>
<t indent="0" pn="section-6.3.4-1">The extensions defined in this docu
ment include RSVP-TE as one of
the applications. It is therefore possible, in the future, for the applications. It is therefore possible, in the future, for
implementations to migrate to the use of application-specific implementations to migrate to the use of application-specific
advertisements in support of RSVP-TE. This could advertisements in support of RSVP-TE. This could
be done in the following stepwise manner:</t> be done in the following stepwise manner:</t>
<ol type="%d)" indent="adaptive" spacing="normal" start="1" pn="sectio <ol>
n-6.3.4-2"> <li>Upgrade all routers to support the extensions in this
<li pn="section-6.3.4-2.1" derivedCounter="1)">Upgrade all routers to
support the extensions in this
document.</li> document.</li>
<li pn="section-6.3.4-2.2" derivedCounter="2)">Advertise all legacy <li>Advertise all legacy link attributes using ASLA advertisements
link attributes using ASLA advertisements with the L-flag clear and the R-bit set. At this point, both legacy an
with the L-flag clear and R-bit set. At this point, both legacy and d
application-specific advertisements are being sent.</li> application-specific advertisements are being sent.</li>
<li pn="section-6.3.4-2.3" derivedCounter="3)">Remove legacy adverti sements.</li> <li>Remove legacy advertisements.</li>
</ol> </ol>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn= <section anchor="IANA">
"section-7"> <name>IANA Considerations</name>
<name slugifiedName="name-iana-considerations">IANA Considerations</name> <t>This section lists the protocol codepoint changes introduced by this
<t indent="0" pn="section-7-1">This section lists the protocol codepoint c document and the related IANA updates.</t>
hanges introduced by this <t>For the registries defined under the "IS-IS TLV Codepoints" group of re
document and the related updates made by IANA.</t> gistries
<t indent="0" pn="section-7-2">For the new registries defined under the "I with a registration procedure of "Expert Review" (see Sections&nbsp;<xref
S-IS TLV Codepoints" registry target="IANA3" format="counter"/> and
with the "Expert Review" registration procedure (see Sections <xref target <xref target="IANA5" format="counter"/>), guidance for designated experts
="IANA3" format="counter" sectionFormat="of" derivedContent="7.3"/> and can be found in <xref target="RFC7370"/>.</t>
<xref target="IANA5" format="counter" sectionFormat="of" derivedContent="7 <t>Note that in all cases where the registry reference was to RFC 8919, th
.5"/>), guidance for designated experts e registry has been updated to refer to this document.</t>
can be found in <xref target="RFC7370" format="default" sectionFormat="of" <section anchor="IANA1">
derivedContent="RFC7370"/>.</t> <name>Application-Specific Link Attributes Sub-TLV</name>
<t indent="0" pn="section-7-3">Note that in all cases where the current re <t>IANA has registered the sub-TLV defined in
gistry reference is to RFC 8919 the registry should be updated to this document. <xref target="ASLASUB"/> in the "IS-IS Sub-TLVs for TLVs Advertising Nei
</t> ghbor Information" registry.</t>
<section anchor="IANA1" numbered="true" toc="include" removeInRFC="false" <table>
pn="section-7.1">
<name slugifiedName="name-application-specific-link-at">Application-Spec
ific Link Attributes Sub-TLV</name>
<t indent="0" pn="section-7.1-1">IANA has registered the new sub-TLV def
ined in
<xref target="ASLASUB" format="default" sectionFormat="of" derivedConten
t="Section 4.2"/> in the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Informati
on" registry.</t>
<table align="center" pn="table-3">
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Type</th> <th>Type</th>
<th align="left" colspan="1" rowspan="1">Description</th> <th>Description</th>
<th align="left" colspan="1" rowspan="1">22</th> <th>22</th>
<th align="left" colspan="1" rowspan="1">23</th> <th>23</th>
<th align="left" colspan="1" rowspan="1">25</th> <th>25</th>
<th align="left" colspan="1" rowspan="1">141</th> <th>141</th>
<th align="left" colspan="1" rowspan="1">222</th> <th>222</th>
<th align="left" colspan="1" rowspan="1">223 </th> <th>223 </th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">16</td> <td>16</td>
<td align="left" colspan="1" rowspan="1">Application-Specific Link <td>Application-Specific Link Attributes</td>
Attributes</td> <td>y</td>
<td align="left" colspan="1" rowspan="1">y</td> <td>y</td>
<td align="left" colspan="1" rowspan="1">y</td> <td>y(s)</td>
<td align="left" colspan="1" rowspan="1">y(s)</td> <td>y</td>
<td align="left" colspan="1" rowspan="1">y</td> <td>y</td>
<td align="left" colspan="1" rowspan="1">y</td> <td>y</td>
<td align="left" colspan="1" rowspan="1">y</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t indent="0" pn="section-7.1-3"/>
</section> </section>
<section anchor="IANA2" numbered="true" toc="include" removeInRFC="false" <section anchor="IANA2">
pn="section-7.2"> <name>Application-Specific SRLG TLV</name>
<name slugifiedName="name-application-specific-srlg-tl">Application-Spec <t>IANA has registered the TLV defined in <xref target="ASSRLGTLV"/> in
ific SRLG TLV</name> the "IS-IS Top-Level TLV Codepoints" registry.
<t indent="0" pn="section-7.2-1">IANA has registered the new TLV defined
in <xref target="ASSRLGTLV" format="default" sectionFormat="of" derivedContent=
"Section 4.3"/> in the "IS-IS Top-Level TLV Codepoints" registry.
</t> </t>
<table align="center" pn="table-4"> <table>
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Value</th> <th>Value</th>
<th align="left" colspan="1" rowspan="1"> Description</th> <th>Description</th>
<th align="left" colspan="1" rowspan="1">IIH</th> <th>IIH</th>
<th align="left" colspan="1" rowspan="1">LSP</th> <th>LSP</th>
<th align="left" colspan="1" rowspan="1">SNP</th> <th>SNP</th>
<th align="left" colspan="1" rowspan="1">Purge</th> <th>Purge</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 238 </td> <td> 238 </td>
<td align="left" colspan="1" rowspan="1"> Application-Specific SRL <td> Application-Specific SRLG </td>
G </td> <td> n </td>
<td align="left" colspan="1" rowspan="1"> n </td> <td> y </td>
<td align="left" colspan="1" rowspan="1"> y </td> <td> n </td>
<td align="left" colspan="1" rowspan="1"> n </td> <td> n </td>
<td align="left" colspan="1" rowspan="1"> n </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="IANA3" numbered="true" toc="include" removeInRFC="false" <section anchor="IANA3">
pn="section-7.3"> <name>IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attribu
<name slugifiedName="name-sub-sub-tlv-codepoints-for-">Sub-sub-TLV Codep tes Registry</name>
oints for Application-Specific Link Attributes Registry</name> <t>IANA has created a registry titled "IS-IS Sub-Sub-TLV Codepoints for
<t indent="0" pn="section-7.3-1">IANA has created a new registry titled
"IS-IS Sub-sub-TLV Codepoints for
Application-Specific Link Attributes" under the "IS-IS TLV Application-Specific Link Attributes" under the "IS-IS TLV
Codepoints" registry to control the assignment of sub-sub-TLV Codepoints" registry to control the assignment of sub-sub-TLV
codepoints for the Application-Specific Link Attributes sub-TLV codepoints for the Application-Specific Link Attributes sub-TLV
defined in <xref target="IANA1" format="default" sectionFormat="of" deri defined in <xref target="IANA1"/>. The registration
vedContent="Section 7.1"/>. The registration procedure is "Expert Review" as defined in <xref target="RFC8126"/>. The
procedure is "Expert Review" as defined in <xref target="RFC8126" format initial contents of this registry are as follows:
="default" sectionFormat="of" derivedContent="RFC8126"/>. The initial contents o
f this registry are as follows:
</t> </t>
<table align="center" pn="table-5"> <table>
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Type </th> <th>Type </th>
<th align="left" colspan="1" rowspan="1">Description</th> <th>Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 0-2 </td> <td> 0-2 </td>
<td align="left" colspan="1" rowspan="1"> Unassigned </td> <td> Unassigned </td>
<td align="left" colspan="1" rowspan="1"/> <td/>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 3 </td> <td> 3 </td>
<td align="left" colspan="1" rowspan="1"> Administrative group (co <td> Administrative group (color) </td>
lor) </td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC5305"/> </td>
<xref target="RFC5305" format="default" sectionFormat="of" deriv
edContent="RFC5305"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 4-8 </td> <td> 4-8 </td>
<td align="left" colspan="1" rowspan="1"> Unassigned </td> <td> Unassigned </td>
<td align="left" colspan="1" rowspan="1"/> <td/>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 9 </td> <td> 9 </td>
<td align="left" colspan="1" rowspan="1"> Maximum link bandwidth</ <td> Maximum link bandwidth</td>
td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC5305"/> </td>
<xref target="RFC5305" format="default" sectionFormat="of" deriv
edContent="RFC5305"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 10 </td> <td> 10 </td>
<td align="left" colspan="1" rowspan="1"> Maximum reservable link <td> Maximum reservable link bandwidth </td>
bandwidth </td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC5305"/> </td>
<xref target="RFC5305" format="default" sectionFormat="of" deriv
edContent="RFC5305"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">11 </td> <td>11 </td>
<td align="left" colspan="1" rowspan="1"> Unreserved bandwidth < <td> Unreserved bandwidth </td>
/td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC5305"/> </td>
<xref target="RFC5305" format="default" sectionFormat="of" deriv
edContent="RFC5305"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 12-13 </td> <td> 12-13 </td>
<td align="left" colspan="1" rowspan="1"> Unassigned </td> <td> Unassigned </td>
<td align="left" colspan="1" rowspan="1"/> <td/>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">14 </td> <td>14 </td>
<td align="left" colspan="1" rowspan="1"> Extended Administrative <td> Extended Administrative Group </td>
Group </td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC7308"/></td>
<xref target="RFC7308" format="default" sectionFormat="of" deriv
edContent="RFC7308"/></td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">15-17 </td> <td>15-17 </td>
<td align="left" colspan="1" rowspan="1"> Unassigned </td> <td> Unassigned </td>
<td align="left" colspan="1" rowspan="1"/> <td/>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">18 </td> <td>18 </td>
<td align="left" colspan="1" rowspan="1"> TE Default Metric </td> <td> TE Default metric </td>
<td align="left" colspan="1" rowspan="1"> <td>
<xref target="RFC5305" format="default" sectionFormat="of" deriv <xref target="RFC5305"/></td>
edContent="RFC5305"/></td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 19-32 </td> <td> 19-32 </td>
<td align="left" colspan="1" rowspan="1"> Unassigned </td> <td> Unassigned </td>
<td align="left" colspan="1" rowspan="1"/> <td/>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 33 </td> <td> 33 </td>
<td align="left" colspan="1" rowspan="1"> Unidirectional Link Dela <td> Unidirectional Link Delay </td>
y </td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC8570"/> </td>
<xref target="RFC8570" format="default" sectionFormat="of" deriv
edContent="RFC8570"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 34 </td> <td> 34 </td>
<td align="left" colspan="1" rowspan="1"> Min/Max Unidirectional L <td> Min/Max Unidirectional Link Delay </td>
ink Delay </td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC8570"/> </td>
<xref target="RFC8570" format="default" sectionFormat="of" deriv
edContent="RFC8570"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 35 </td> <td> 35 </td>
<td align="left" colspan="1" rowspan="1"> Unidirectional Delay Var <td> Unidirectional Delay Variation </td>
iation </td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC8570"/> </td>
<xref target="RFC8570" format="default" sectionFormat="of" deriv
edContent="RFC8570"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">36 </td> <td>36 </td>
<td align="left" colspan="1" rowspan="1"> Unidirectional Link Loss <td> Unidirectional Link Loss </td>
</td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC8570"/> </td>
<xref target="RFC8570" format="default" sectionFormat="of" deriv
edContent="RFC8570"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">37 </td> <td>37 </td>
<td align="left" colspan="1" rowspan="1">Unidirectional Residual B <td>Unidirectional Residual Bandwidth </td>
andwidth </td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC8570"/> </td>
<xref target="RFC8570" format="default" sectionFormat="of" deriv
edContent="RFC8570"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 38 </td> <td> 38 </td>
<td align="left" colspan="1" rowspan="1">Unidirectional Available <td>Unidirectional Available Bandwidth </td>
Bandwidth </td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC8570"/> </td>
<xref target="RFC8570" format="default" sectionFormat="of" deriv
edContent="RFC8570"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">39 </td> <td>39 </td>
<td align="left" colspan="1" rowspan="1">Unidirectional Utilized B <td>Unidirectional Utilized Bandwidth </td>
andwidth </td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC8570"/></td>
<xref target="RFC8570" format="default" sectionFormat="of" deriv
edContent="RFC8570"/></td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">40-255 </td> <td>40-255 </td>
<td align="left" colspan="1" rowspan="1"> Unassigned </td> <td> Unassigned </td>
<td align="left" colspan="1" rowspan="1"/> <td/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t indent="0" pn="section-7.3-3">IANA has also added the following notes <t>IANA has also added the following notes to this registry:</t>
to this registry:</t> <t indent="3">Note: For future codepoints, in cases where the document t
<t indent="3" pn="section-7.3-4">Note: For future codepoints, in cases w hat defines the
here the document that defines the
encoding is different from the document that assigns the codepoint, the encoding is different from the document that assigns the codepoint, the
encoding reference <bcp14>MUST</bcp14> be to the document that encoding reference <bcp14>MUST</bcp14> be to the document that
defines the encoding.</t> defines the encoding.</t>
<t indent="3" pn="section-7.3-5">Note: If a link attribute can be advert <t indent="3">Note: If a link attribute can be advertised
ised both as a sub-TLV of TLVs advertising neighbor information and as a
both as a sub-TLV of TLVs Advertising Neighbor Information 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 RFC 8919, then the same numerical code should be defined in RFC 9479, 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="include" removeInRFC="false" <section anchor="IANA4">
pn="section-7.4"> <name>Link Attribute Application Identifiers Registry</name>
<name slugifiedName="name-link-attribute-application-">Link Attribute Ap <t>IANA has created a registry titled "Link Attribute
plication Identifiers Registry</name> Application Identifiers" within the "Interior Gateway Protocol (IGP) Par
<t indent="0" pn="section-7.4-1">IANA has created a new registry titled ameters" group of registries
"Link Attribute
Application Identifiers" under the "Interior Gateway Protocol (IGP) Para
meters" registry
to control the assignment of Application Identifier Bits. The to control the assignment of Application Identifier Bits. The
registration policy for this registry is "Expert Review" as defined in registration policy for this registry is "Expert Review" as defined in
<xref target="RFC8126" format="default" sectionFormat="of" derivedConten t="RFC8126"/>. Bit definitions <xref target="RFC8126"/>. Bit definitions
<bcp14>SHOULD</bcp14> 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 initial contents of this registry are as follows: The initial contents of this registry are as follows:
</t> </t>
<table align="center" pn="table-6"> <table>
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Bit # </th> <th>Bit </th>
<th align="left" colspan="1" rowspan="1">Name</th> <th>Name</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1"> 0</td> <td> 0</td>
<td align="left" colspan="1" rowspan="1"> RSVP-TE (R-bit)</td> <td> RSVP-TE (R-bit)</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">1</td> <td>1</td>
<td align="left" colspan="1" rowspan="1"> Segment Routing Policy ( <td> Segment Routing Policy (S-bit)</td>
S-bit)</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">2</td> <td>2</td>
<td align="left" colspan="1" rowspan="1"> Loop-Free Alternate (F-b <td> Loop-Free Alternate (F-bit)</td>
it)</td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">3-63</td> <td>3-63</td>
<td align="left" colspan="1" rowspan="1"> Unassigned</td> <td> Unassigned</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="IANA5" numbered="true" toc="include" removeInRFC="false" <section anchor="IANA5">
pn="section-7.5"> <name>IS-IS Sub-TLVs for Application-Specific SRLG TLV</name>
<name slugifiedName="name-sub-tlvs-for-tlv-238-regist">Sub-TLVs for TLV <t>IANA has created a registry titled "IS-IS Sub-TLVs for Application-Sp
238 Registry</name> ecific SRLG TLV" under
<t indent="0" pn="section-7.5-1">IANA has created a new registry titled
"IS-IS Sub-TLVs for Application-Specific SLRG TLV" under
the "IS-IS TLV Codepoints" registry to control the assignment of the "IS-IS TLV Codepoints" registry to control the assignment of
sub-TLV types for the Application-Specific SRLG TLV. The registration sub-TLV types for the Application-Specific SRLG TLV (TLV 238). The regi
procedure is "Expert Review" as defined in <xref target="RFC8126" format stration
="default" sectionFormat="of" derivedContent="RFC8126"/>. The initial contents o procedure is "Expert Review" as defined in <xref target="RFC8126"/>. The
f this registry are as follows: initial contents of this registry are as follows:
</t> </t>
<table align="center" pn="table-7"> <table>
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Value</th> <th>Value</th>
<th align="left" colspan="1" rowspan="1">Description</th> <th>Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">0-3 </td> <td>0-3 </td>
<td align="left" colspan="1" rowspan="1">Unassigned </td> <td>Unassigned </td>
<td align="left" colspan="1" rowspan="1"/> <td/>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">4 </td> <td>4 </td>
<td align="left" colspan="1" rowspan="1"> Link Local/Remote Identi <td> Link Local/Remote Identifiers </td>
fiers </td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC5307"/> </td>
<xref target="RFC5307" format="default" sectionFormat="of" deriv
edContent="RFC5307"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">5 </td> <td>5 </td>
<td align="left" colspan="1" rowspan="1"> Unassigned </td> <td> Unassigned </td>
<td align="left" colspan="1" rowspan="1"/> <td/>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">6 </td> <td>6 </td>
<td align="left" colspan="1" rowspan="1"> IPv4 interface address < <td> IPv4 interface address </td>
/td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC5305"/> </td>
<xref target="RFC5305" format="default" sectionFormat="of" deriv
edContent="RFC5305"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">7 </td> <td>7 </td>
<td align="left" colspan="1" rowspan="1">Unassigned </td> <td>Unassigned </td>
<td align="left" colspan="1" rowspan="1"/> <td/>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">8 </td> <td>8 </td>
<td align="left" colspan="1" rowspan="1"> IPv4 neighbor address < <td> IPv4 neighbor address </td>
/td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC5305"/> </td>
<xref target="RFC5305" format="default" sectionFormat="of" deriv
edContent="RFC5305"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">9-11 </td> <td>9-11 </td>
<td align="left" colspan="1" rowspan="1">Unassigned </td> <td>Unassigned </td>
<td align="left" colspan="1" rowspan="1"/> <td/>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">12 </td> <td>12 </td>
<td align="left" colspan="1" rowspan="1"> IPv6 Interface Address < <td> IPv6 Interface Address </td>
/td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC6119"/> </td>
<xref target="RFC6119" format="default" sectionFormat="of" deriv
edContent="RFC6119"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">13 </td> <td>13 </td>
<td align="left" colspan="1" rowspan="1"> IPv6 Neighbor Address < <td> IPv6 Neighbor Address </td>
/td> <td>
<td align="left" colspan="1" rowspan="1"> <xref target="RFC6119"/> </td>
<xref target="RFC6119" format="default" sectionFormat="of" deriv
edContent="RFC6119"/> </td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">14-255 </td> <td>14-255 </td>
<td align="left" colspan="1" rowspan="1"> Unassigned </td> <td> Unassigned </td>
<td align="left" colspan="1" rowspan="1"/> <td/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t indent="0" pn="section-7.5-3">IANA has also added the following note <t>IANA has also added the following note to this registry:</t>
to this registry:</t> <t indent="3">Note: For future codepoints, in cases where the document t
<t indent="3" pn="section-7.5-4">Note: For future codepoints, in cases w hat
here the document that
defines the encoding is different from the document that assigns the defines the encoding is different from the document that assigns the
codepoint, the encoding reference <bcp14>MUST</bcp14> be to the codepoint, the encoding reference <bcp14>MUST</bcp14> be to the
document that defines the encoding.</t> document that defines the encoding.</t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="include" removeInRFC="false" <section anchor="Security">
pn="section-8"> <name>Security Considerations</name>
<name slugifiedName="name-security-considerations">Security Considerations <t>Security concerns for IS-IS are addressed in <xref target="ISO10589"/>,
</name> <xref target="RFC5304"/>, and <xref target="RFC5310"/>. While IS-IS is deployed
<t indent="0" pn="section-8-1">Security concerns for IS-IS are addressed i under a single
n <xref target="ISO10589" format="default" sectionFormat="of" derivedContent="IS
O10589"/>, <xref target="RFC5304" format="default" sectionFormat="of" derivedCon
tent="RFC5304"/>, and <xref target="RFC5310" format="default" sectionFormat="of"
derivedContent="RFC5310"/>. 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 <bcp14>SHOULD</bcp14> be used.</t> defined in the aforementioned documents <bcp14>SHOULD</bcp14> be used.</t>
<t indent="0" pn="section-8-2">This document defines a new way to advertis e link attributes. <t>This document defines an improved 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 TE
as discussed in <xref target="RFC8570" format="default" sectionFormat="of" as discussed in <xref target="RFC8570"/>. As the advertisements defined
derivedContent="RFC8570"/>. As the advertisements 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="changes-to-rfc8919" numbered="true" toc="include" removeInR <section anchor="changes-to-rfc8919">
FC="false" pn="section-9"> <name>Changes to RFC 8919</name>
<name slugifiedName="name-changes-to-rfc8919">Changes to RFC 8919</name> <t>Discussion within the LSR WG indicated that there was confusion regardi
<t indent="0" pn="section-9-1">Discussion within the LSR WG indicated that ng
there was confusion regarding the use of ASLA advertisements that had a zero-length SABM/UDABM.
the use of ASLA advertisements that had a zero length SABM/UDABM.
The discussion can be seen by searching the LSR WG mailing list archives The discussion can be seen by searching the LSR WG mailing list archives
for the thread "Proposed Errata for RFCs 8919/8920" starting on for the thread "Proposed Errata for RFCs 8919/8920" starting on
15 June 2021. </t> 15 June 2021.</t>
<t indent="0" pn="section-9-2">Changes to Sections 4.2, 4.3, and 6.2 have <t>Changes to Sections&nbsp;<xref target="ASLASUB" format="counter"/>, <xr
been introduced to clarify normative ef target="ASSRLGTLV" format="counter"/>, and <xref target="DEPZERO" format="cou
behavior in the presence of such advertisements. In particular, the text i nter"/> have been introduced to clarify normative
n RFC 8919 used the word "permitted", behavior in the presence of such advertisements. In particular, the text i
n <xref target="RFC8919"/> used the word "permitted",
suggesting that the use of such advertisements is "optional". Such an inte rpretation could lead to interoperability suggesting that the use of such advertisements is "optional". Such an inte rpretation could lead to interoperability
issues and is not what was intended.</t> issues and is not what was intended.</t>
<t indent="0" pn="section-9-3">The replacement text makes explicit the spe cific conditions when such <t>The replacement text makes explicit the specific conditions when such
advertisements <bcp14>MUST</bcp14> be used and the specific conditions und er which they <bcp14>MUST NOT</bcp14> advertisements <bcp14>MUST</bcp14> be used and the specific conditions und er which they <bcp14>MUST NOT</bcp14>
be used.</t> be used.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9256" to="SEGMENT-ROUTING"/> <references>
<references pn="section-10"> <name>References</name>
<name slugifiedName="name-references">References</name> <references>
<references pn="section-10.1"> <name>Normative References</name>
<name slugifiedName="name-normative-references">Normative References</na
me> <reference anchor="ISO10589" target="https://www.iso.org/standard/30932.
<reference anchor="ISO10589" quoteTitle="true" derivedAnchor="ISO10589"> html">
<front> <front>
<title>Information technology - Telecommunications and information e xchange between systems - Intermediate System to Intermediate System intra-domai n routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)</title> <title>Information technology - Telecommunications and information e xchange between systems - Intermediate System to Intermediate System intra-domai n 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> <author>
<organization abbrev="ISO" showOnFrontPage="true">International Or <organization abbrev="ISO">International Organization for Standard
ganization for Standardization</organization> ization</organization>
</author>
<date month="Nov" year="2002"/>
</front>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
</author>
<date year="1997" month="March"/>
<abstract>
<t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often ca
pitalized. This document defines these words as they should be interpreted in IE
TF documents. This document specifies an Internet Best Current Practices for th
e Internet Community, and requests discussion and suggestions for improvements.<
/t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC5304" target="https://www.rfc-editor.org/info/rfc5
304" quoteTitle="true" derivedAnchor="RFC5304">
<front>
<title>IS-IS Cryptographic Authentication</title>
<author initials="T." surname="Li" fullname="T. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Atkinson" fullname="R. Atkinson">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="October"/>
<abstract>
<t indent="0">This document describes the authentication of Interm
ediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using th
e Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as
found in RFC 2104. IS-IS is specified in International Standards Organization
(ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) descr
ibed in RFC 1195. The base specification includes an authentication mechanism t
hat allows for multiple authentication algorithms. The base specification only
specifies the algorithm for cleartext passwords. This document replaces RFC 356
7.</t>
<t indent="0">This document proposes an extension to that specific
ation that allows the use of the HMAC-MD5 authentication algorithm to be used in
conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5304"/>
<seriesInfo name="DOI" value="10.17487/RFC5304"/>
</reference>
<reference anchor="RFC5305" target="https://www.rfc-editor.org/info/rfc5
305" quoteTitle="true" derivedAnchor="RFC5305">
<front>
<title>IS-IS Extensions for Traffic Engineering</title>
<author initials="T." surname="Li" fullname="T. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Smit" fullname="H. Smit">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="October"/>
<abstract>
<t indent="0">This document describes extensions to the Intermedia
te System to Intermediate System (IS-IS) protocol to support Traffic Engineering
(TE). This document extends the IS-IS protocol by specifying new information t
hat an Intermediate System (router) can place in Link State Protocol Data Units
(LSP). This information describes additional details regarding the state of the
network that are useful for traffic engineering computations. [STANDARDS-TRACK
]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5305"/>
<seriesInfo name="DOI" value="10.17487/RFC5305"/>
</reference>
<reference anchor="RFC5307" target="https://www.rfc-editor.org/info/rfc5
307" quoteTitle="true" derivedAnchor="RFC5307">
<front>
<title>IS-IS Extensions in Support of Generalized Multi-Protocol Lab
el Switching (GMPLS)</title>
<author initials="K." surname="Kompella" fullname="K. Kompella" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="October"/>
<abstract>
<t indent="0">This document specifies encoding of extensions to th
e IS-IS routing protocol in support of Generalized Multi-Protocol Label Switchin
g (GMPLS). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5307"/>
<seriesInfo name="DOI" value="10.17487/RFC5307"/>
</reference>
<reference anchor="RFC5310" target="https://www.rfc-editor.org/info/rfc5
310" quoteTitle="true" derivedAnchor="RFC5310">
<front>
<title>IS-IS Generic Cryptographic Authentication</title>
<author initials="M." surname="Bhatia" fullname="M. Bhatia">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Manral" fullname="V. Manral">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Li" fullname="T. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Atkinson" fullname="R. Atkinson">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="White" fullname="R. White">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Fanto" fullname="M. Fanto">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="February"/>
<abstract>
<t indent="0">This document proposes an extension to Intermediate
System to Intermediate System (IS-IS) to allow the use of any cryptographic auth
entication algorithm in addition to the already-documented authentication scheme
s, described in the base specification and RFC 5304. IS-IS is specified in Inte
rnational Standards Organization (ISO) 10589, with extensions to support Interne
t Protocol version 4 (IPv4) described in RFC 1195.</t>
<t indent="0">Although this document has been written specifically
for using the Hashed Message Authentication Code (HMAC) construct along with th
e Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method
described in this document is generic and can be used to extend IS-IS to suppor
t any cryptographic hash function in the future. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5310"/>
<seriesInfo name="DOI" value="10.17487/RFC5310"/>
</reference>
<reference anchor="RFC6119" target="https://www.rfc-editor.org/info/rfc6
119" quoteTitle="true" derivedAnchor="RFC6119">
<front>
<title>IPv6 Traffic Engineering in IS-IS</title>
<author initials="J." surname="Harrison" fullname="J. Harrison">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Berger" fullname="J. Berger">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Bartlett" fullname="M. Bartlett">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="February"/>
<abstract>
<t indent="0">This document specifies a method for exchanging IPv6
traffic engineering information using the IS-IS routing protocol. This informa
tion enables routers in an IS-IS network to calculate traffic-engineered routes
using IPv6 addresses. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6119"/>
<seriesInfo name="DOI" value="10.17487/RFC6119"/>
</reference>
<reference anchor="RFC7308" target="https://www.rfc-editor.org/info/rfc7
308" quoteTitle="true" derivedAnchor="RFC7308">
<front>
<title>Extended Administrative Groups in MPLS Traffic Engineering (M
PLS-TE)</title>
<author initials="E." surname="Osborne" fullname="E. Osborne">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="July"/>
<abstract>
<t indent="0">MPLS Traffic Engineering (MPLS-TE) advertises 32 adm
inistrative groups (commonly referred to as "colors" or "link colors") using the
Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (R
FC 5329) and IS-IS (RFC 5305).</t>
<t indent="0">This document adds a sub-TLV to the IGP TE extension
s, "Extended Administrative Group". This sub-TLV provides for additional admini
strative groups (link colors) beyond the current limit of 32.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7308"/>
<seriesInfo name="DOI" value="10.17487/RFC7308"/>
</reference>
<reference anchor="RFC7370" target="https://www.rfc-editor.org/info/rfc7
370" quoteTitle="true" derivedAnchor="RFC7370">
<front>
<title>Updates to the IS-IS TLV Codepoints Registry</title>
<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="September"/>
<abstract>
<t indent="0">This document recommends some editorial changes to t
he IANA "IS-IS TLV Codepoints" registry to more accurately document the state of
the protocol. It also sets out new guidelines for Designated Experts to apply
when reviewing allocations from the registry.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7370"/>
<seriesInfo name="DOI" value="10.17487/RFC7370"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" quoteTitle="true" derivedAnchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="June"/>
<abstract>
<t indent="0">Many protocols make use of points of extensibility t
hat use constants to identify various protocol parameters. To ensure that the v
alues in these fields do not have conflicting uses and to promote interoperabili
ty, their allocations are often coordinated by a central record keeper. For IET
F protocols, that role is filled by the Internet Assigned Numbers Authority (IAN
A).</t>
<t indent="0">To make assignments in a given registry prudently, g
uidance describing the conditions under which new values should be assigned, as
well as when and how modifications to existing values can be made, is needed. T
his document defines a framework for the documentation of these guidelines by sp
ecification authors, in order to assure that the provided guidance for the IANA
Considerations is clear and addresses the various issues that are likely in the
operation of a registry.</t>
<t indent="0">This is the third edition of this document; it obsol
etes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8570" target="https://www.rfc-editor.org/info/rfc8
570" quoteTitle="true" derivedAnchor="RFC8570">
<front>
<title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
<author initials="L." surname="Ginsberg" fullname="L. Ginsberg" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Giacalone" fullname="S. Giacalone">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Ward" fullname="D. Ward">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Drake" fullname="J. Drake">
<organization showOnFrontPage="true"/>
</author>
<author initials="Q." surname="Wu" fullname="Q. Wu">
<organization showOnFrontPage="true"/>
</author> </author>
<date year="2019" month="March"/> <date month="November" year="2002"/>
<abstract>
<t indent="0">In certain networks, such as, but not limited to, fi
nancial information networks (e.g., stock market data providers), network-perfor
mance criteria (e.g., latency) are becoming as critical to data-path selection a
s other metrics.</t>
<t indent="0">This document describes extensions to IS-IS Traffic
Engineering Extensions (RFC 5305). These extensions provide a way to distribute
and collect network-performance information in a scalable fashion. The informat
ion distributed using IS-IS TE Metric Extensions can then be used to make path-s
election decisions based on network performance.</t>
<t indent="0">Note that this document only covers the mechanisms w
ith which network-performance information is distributed. The mechanisms for me
asuring network performance or acting on that information, once distributed, are
outside the scope of this document.</t>
<t indent="0">This document obsoletes RFC 7810.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8570"/> <seriesInfo name="ISO/IEC" value="10589:2002"/>
<seriesInfo name="DOI" value="10.17487/RFC8570"/> <refcontent>Second Edition</refcontent>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5307.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6119.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7308.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7370.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml"
/>
</references> </references>
<references pn="section-10.2"> <references>
<name slugifiedName="name-informative-references">Informative References <name>Informative References</name>
</name>
<reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"
209" quoteTitle="true" derivedAnchor="RFC3209"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title> />
<author initials="D." surname="Awduche" fullname="D. Awduche"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml"
<organization showOnFrontPage="true"/> />
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"
<author initials="L." surname="Berger" fullname="L. Berger"> />
<organization showOnFrontPage="true"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8919.xml"
</author> />
<author initials="D." surname="Gan" fullname="D. Gan">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Li" fullname="T. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="December"/>
<abstract>
<t indent="0">This document describes the use of RSVP (Resource Re
servation Protocol), including all the necessary extensions, to establish label-
switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow
along an LSP is completely identified by the label applied at the ingress node o
f the path, these paths may be treated as tunnels. A key application of LSP tun
nels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3209"/>
<seriesInfo name="DOI" value="10.17487/RFC3209"/>
</reference>
<reference anchor="RFC5286" target="https://www.rfc-editor.org/info/rfc5
286" quoteTitle="true" derivedAnchor="RFC5286">
<front>
<title>Basic Specification for IP Fast Reroute: Loop-Free Alternates
</title>
<author initials="A." surname="Atlas" fullname="A. Atlas" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Zinin" fullname="A. Zinin" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="September"/>
<abstract>
<t indent="0">This document describes the use of loop-free alterna
tes to provide local protection for unicast traffic in pure IP and MPLS/LDP netw
orks in the event of a single failure, whether link, node, or shared risk link g
roup (SRLG). The goal of this technology is to reduce the packet loss that happ
ens while routers converge after a topology change due to a failure. Rapid fail
ure repair is achieved through use of precalculated backup next-hops that are lo
op-free and safe to use until the distributed network convergence process comple
tes. This simple approach does not require any support from other routers. The e
xtent to which this goal can be met by this specification is dependent on the to
pology of the network. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5286"/>
<seriesInfo name="DOI" value="10.17487/RFC5286"/>
</reference>
<reference anchor="RFC7855" target="https://www.rfc-editor.org/info/rfc7
855" quoteTitle="true" derivedAnchor="RFC7855">
<front>
<title>Source Packet Routing in Networking (SPRING) Problem Statemen
t and Requirements</title>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Decraene" fullname="B. Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Litkowski" fullname="S. Litkowski">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Horneffer" fullname="M. Horneffer">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="May"/>
<abstract>
<t indent="0">The ability for a node to specify a forwarding path,
other than the normal shortest path, that a particular packet will traverse, be
nefits a number of network functions. Source-based routing mechanisms have prev
iously been specified for network protocols but have not seen widespread adoptio
n. In this context, the term "source" means "the point at which the explicit ro
ute is imposed"; therefore, it is not limited to the originator of the packet (i
.e., the node imposing the explicit route may be the ingress node of an operator
's network).</t>
<t indent="0">This document outlines various use cases, with their
requirements, that need to be taken into account by the Source Packet Routing i
n Networking (SPRING) architecture for unicast traffic. Multicast use cases and
requirements are out of scope for this document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7855"/>
<seriesInfo name="DOI" value="10.17487/RFC7855"/>
</reference>
<reference anchor="RFC9256" quoteTitle="true" derivedAnchor="SEGMENT-ROU
TING">
<front>
<title>Segment Routing Policy Architecture</title>
<author fullname="Clarence Filsfils">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author fullname="Ketan Talaulikar">
<organization showOnFrontPage="true">Cisco Systems</organization>
</author>
<author fullname="Daniel Voyer">
<organization showOnFrontPage="true">Bell Canada</organization>
</author>
<author fullname="Alex Bogdanov">
<organization showOnFrontPage="true">Google, Inc.</organization>
</author>
<author fullname="Paul Mattes">
<organization showOnFrontPage="true">Microsoft</organization>
</author>
</front>
<seriesInfo name="RFC" value="9256"/>
<seriesInfo name="DOI" value="10.17487/RFC9256"/>
</reference>
</references> </references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="include" removeInRF <section anchor="Acknowledgements" numbered="false">
C="false" pn="section-appendix.a"> <name>Acknowledgements</name>
<name slugifiedName="name-acknowledgements">Acknowledgements</name> <t>RFC 8919 included the following acknowledgements:</t>
<t indent="0" pn="section-appendix.a-1">RFC 8919 included the following ac <blockquote>
knowledgements:</t> <t><contact fullname="Eric Rosen"/> and <contact fullname="Acee Lindem"/>
<t indent="0" pn="section-appendix.a-2"> for their careful review and content
<contact fullname="Eric Rosen"/> and <contact fullname="Acee Lindem"/> for
their careful review and content
suggestions.</t> suggestions.</t>
<t indent="0" pn="section-appendix.a-3"> For the new version, the authors </blockquote>
would like to thank <t> For the new version (this document), the authors would like to thank
<contact fullname="Bruno Decraene"/>.</t> <contact fullname="Bruno Decraene"/>.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
<organization showOnFrontPage="true">Cisco Systems</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>United States of America</country>
</postal>
<email>ginsberg@cisco.com</email>
</address>
</author>
<author fullname="Peter Psenak" initials="P" surname="Psenak">
<organization showOnFrontPage="true">Cisco Systems</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>Slovakia</country>
</postal>
<email>ppsenak@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S" surname="Previdi">
<organization showOnFrontPage="true">Huawei Technologies</organization>
<address>
<postal>
<street/>
<country/>
</postal>
<email>stefano@previdi.net</email>
</address>
</author>
<author fullname="Wim Henderickx" initials="W" surname="Henderickx">
<organization showOnFrontPage="true">Nokia</organization>
<address>
<postal>
<street>Copernicuslaan 50</street>
<city>Antwerp</city>
<code>2018 94089</code>
<country>Belgium</country>
</postal>
<email>wim.henderickx@nokia.com</email>
</address>
</author>
<author fullname="John Drake" initials="J" surname="Drake">
<organization showOnFrontPage="true">Juniper Networks</organization>
<address>
<postal>
<street/>
<code/>
<country/>
</postal>
<email>jdrake@juniper.net</email>
</address>
</author>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 211 change blocks. 
1677 lines changed or deleted 687 lines changed or added

This html diff was produced by rfcdiff 1.48.