rfc9492.original.xml   rfc9492.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
nsus="true" docName="draft-ietf-lsr-rfc8920bis-06" indexInclude="true" ipr="trus <!DOCTYPE rfc [
t200902" obsoletes="8920" scripts="Common,Latin" sortRefs="true" submissionType= <!ENTITY nbsp "&#160;">
"IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <!ENTITY zwsp "&#8203;">
<!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-rfc8920bis-06" number="9492" ipr="trust200902"
updates="" obsoletes="8920" sortRefs="true" symRefs="true" tocDepth="3"
tocInclude="true" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reus e-16" rel="prev"/> <link href="https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reus e-16" rel="prev"/>
<link href="https://dx.doi.org/10.17487/rfc8920" rel="alternate"/> <link href="https://dx.doi.org/10.17487/rfc8920" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/>
<front> <front>
<title abbrev="OSPF App-Specific Link Attributes">OSPF Application-Specific <title abbrev="OSPF App-Specific Link Attributes">OSPF
Link Attributes</title> Application-Specific Link Attributes</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lsr-rfc8920bis-06" strea <seriesInfo name="RFC" value="9492"/>
m="IETF"/>
<author fullname="Peter Psenak" initials="P." role="editor" surname="Psenak" > <author fullname="Peter Psenak" initials="P." role="editor" surname="Psenak" >
<organization showOnFrontPage="true">Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>Slovakia</country> <country>Slovakia</country>
</postal> </postal>
<email>ppsenak@cisco.com</email> <email>ppsenak@cisco.com</email>
</address> </address>
</author> </author>
<author initials="L." surname="Ginsberg" fullname="Les Ginsberg"> <author initials="L." surname="Ginsberg" fullname="Les Ginsberg">
<organization showOnFrontPage="true">Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<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 initials="W." surname="Henderickx" fullname="Wim Henderickx"> <author initials="W." surname="Henderickx" fullname="Wim 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>
<country>Belgium</country> <country>Belgium</country>
<code>2018 94089</code> <code>2018 94089</code>
</postal> </postal>
<email>wim.henderickx@nokia.com</email> <email>wim.henderickx@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura"> <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization showOnFrontPage="true">Nvidia</organization> <organization>Nvidia</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>jefftant.ietf@gmail.com</email> <email>jefftant.ietf@gmail.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> <postal>
<street/>
<city/>
<region/>
<code/>
<country>United States of America</country> <country>United States of America</country>
</postal> </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>rtg</area>
<workgroup>LSR 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.
original RSVP-TE use case was defined, additional applications (e.g., Since the
Segment Routing Policy and Loop-Free Alternates) that also make use of the original RSVP-TE use case was defined, additional applications such as
Segment Routing (SR) Policy and Loop-Free Alternates (LFAs) that also make u
se of the
link attribute advertisements have been defined. In link attribute advertisements have been defined. In
cases where multiple applications wish to make use of these link cases where multiple applications wish to make use of these link
attributes, the current advertisements do not support application-specific v alues for a given attribute, nor do they support indication attributes, the current advertisements do not support application-specific v alues for a given attribute, nor do they support indication
of which applications are using the advertised value for a given of which applications are using the advertised value for a given
link. This document introduces new link attribute advertisements in OSPFv2 link. This document introduces link attribute advertisements in OSPFv2
and OSPFv3 that address both of these shortcomings.</t> and OSPFv3 that address both of these shortcomings.</t>
<t indent="0" pn="section-abstract-2">This document obsoletes RFC 8920.</t > <t>This document obsoletes RFC 8920.</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/rfc8920" 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-existing-advertisement-of-l">Exist
ing Advertisement of Link Attributes</xref></t>
</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-advertisement-of-link-attri">Adver
tisement of 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-ospfv2-extended-link-o
paque">OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA</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-advertisement-of-applicatio">Adver
tisement of Application-Specific Values</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-reused-te-link-attributes">Reused
TE Link Attributes</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-shared-risk-link-group
-srlg">Shared Risk Link Group (SRLG)</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-extended-metrics">Exte
nded Metrics</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-administrative-group">
Administrative Group</xref></t>
</li>
<li pn="section-toc.1-1.6.2.4">
<t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent=
"6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-traffic-engineering-me
tric">Traffic Engineering Metric</xref></t>
</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-maximum-link-bandwidth">Maximum Li
nk Bandwidth</xref></t>
</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-considerations-for-extended">Consi
derations for Extended TE Metrics</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-local-interface-ipv6-addres">Local
Interface IPv6 Address Sub-TLV</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-remote-interface-ipv6-addre">Rem
ote Interface IPv6 Address Sub-TLV</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-attribute-advertisements-an">Att
ribute Advertisements and Enablement</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-deployment-considerations">Deplo
yment Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.3.1">
<t indent="0" pn="section-toc.1-1.12.3.1.1"><xref derivedContent
="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-use-of-legacy-rsvp-
te-lsa-a">Use of Legacy RSVP-TE LSA Advertisements</xref></t>
</li>
<li pn="section-toc.1-1.12.3.2">
<t indent="0" pn="section-toc.1-1.12.3.2.1"><xref derivedContent
="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-interoperability-ba
ckwards-">Interoperability, Backwards Compatibility, and Migration Concerns</xre
f></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.12.3.2.2">
<li pn="section-toc.1-1.12.3.2.2.1">
<t indent="0" pn="section-toc.1-1.12.3.2.2.1.1"><xref derive
dContent="12.3.1" format="counter" sectionFormat="of" target="section-12.3.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-multipl
e-applications-commo">Multiple Applications: Common Attributes with RSVP-TE</xr
ef></t>
</li>
<li pn="section-toc.1-1.12.3.2.2.2">
<t indent="0" pn="section-toc.1-1.12.2.3.2.2.1"><xref derive
dContent="12.3.2" format="counter" sectionFormat="of" target="section-12.3.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-multipl
e-applications-some-">Multiple Applications: Some Attributes Not Shared with RSV
P-TE</xref></t>
</li>
<li pn="section-toc.1-1.12.3.2.2.3">
<t indent="0" pn="section-toc.1-1.12.3.2.2.3.1"><xref derive
dContent="12.3.3" format="counter" sectionFormat="of" target="section-12.3.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-interop
erability-with-legac">Interoperability with Legacy Routers</xref></t>
</li>
<li pn="section-toc.1-1.12.3.2.2.4">
<t indent="0" pn="section-toc.1-1.12.3.2.2.4.1"><xref derive
dContent="12.3.4" format="counter" sectionFormat="of" target="section-12.3.4"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-
application-specific">Use of Application-Specific Advertisements for RSVP-TE</xr
ef></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.14.2">
<li pn="section-toc.1-1.14.2.1">
<t indent="0" pn="section-toc.1-1.14.2.1.1"><xref derivedContent
="14.1" format="counter" sectionFormat="of" target="section-14.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-ospfv2">OSPFv2</xre
f></t>
</li>
<li pn="section-toc.1-1.14.2.2">
<t indent="0" pn="section-toc.1-1.14.2.2.1"><xref derivedContent
="14.2" format="counter" sectionFormat="of" target="section-14.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-ospfv3">OSPFv3</xre
f></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" fo
rmat="counter" sectionFormat="of" target="section-16"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.15.2">
<li pn="section-toc.1-1.15.2.1">
<t indent="0" pn="section-toc.1-1.15.2.1.1"><xref derivedContent
="15.1" format="counter" sectionFormat="of" target="section-16.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.15.2.2">
<t indent="0" pn="section-toc.1-1.15.2.2.1"><xref derivedContent
="15.2" format="counter" sectionFormat="of" target="section-16.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
f></t>
</li>
<li pn="section-toc.1-1.18">
<t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><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 OSPFv2 <xref target="RFC2328"/>
changes to the content of RFC 8920 which it obsoletes. A detailed descript and OSPFv3 <xref target="RFC5340"/> protocols in support of traffic engineering
ion (TE) was
of the changes is provided in <xref target="changes-to-rfc8920" format="de introduced by <xref target="RFC3630"/> and <xref target="RFC5329"/>, resp
fault" sectionFormat="of" derivedContent="Section 15"/>. This note was added ectively. It has been extended
for the benefit of IESG reviewers and SHOULD be removed by the RFC Editor by <xref target="RFC4203"/>, <xref target="RFC7308"/>, and <xref target="
prior to publication.</t> RFC7471"/>. Use
<t indent="0" pn="section-1-2">Advertisement of link attributes by the OSP
Fv2 <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="R
FC2328"/> and OSPFv3 <xref target="RFC5340" format="default" sectionFormat="of"
derivedContent="RFC5340"/> protocols in support of traffic engineering (TE) was
introduced by <xref target="RFC3630" format="default" sectionFormat="of"
derivedContent="RFC3630"/> and <xref target="RFC5329" format="default" sectionFo
rmat="of" derivedContent="RFC5329"/>, respectively. It has been extended
by <xref target="RFC4203" format="default" sectionFormat="of" derivedCont
ent="RFC4203"/>, <xref target="RFC7308" format="default" sectionFormat="of" deri
vedContent="RFC7308"/>, and <xref target="RFC7471" format="default" sectionForma
t="of" derivedContent="RFC7471"/>. Use
of these extensions has been associated with deployments supporting of these extensions has been associated with deployments supporting
Traffic Engineering over Multiprotocol Label Switching (MPLS) in the TE over Multiprotocol Label Switching (MPLS) in the
presence of the Resource Reservation Protocol (RSVP), more succinctly presence of the Resource Reservation Protocol (RSVP), more succinctly
referred to as RSVP-TE <xref target="RFC3209" format="default" sectionFor referred to as RSVP-TE <xref target="RFC3209"/>.</t>
mat="of" derivedContent="RFC3209"/>.</t> <t>For the purposes of this document, an application is a technology
<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 that makes use of link attribute advertisements, examples of which are
listed in <xref target="ADVAPPVAL" format="default" sectionFormat="of" de listed in <xref target="ADVAPPVAL"/>.</t>
rivedContent="Section 5"/>.</t> <t>In recent years, new applications have been introduced that have use
<t indent="0" pn="section-1-4">In recent years, new applications have been
introduced that have use
cases for many of the link attributes historically used by RSVP-TE. cases for many of the link attributes historically used by RSVP-TE.
Such applications include Segment Routing (SR) Policy <xref target="RFC92 Such applications include SR Policy <xref target="RFC9256"/> and
56" format="default" sectionFormat="of" derivedContent="SEGMENT-ROUTING"/> and LFAs <xref target="RFC5286"/>. This has introduced ambiguity in that if a
Loop-Free Alternates (LFAs) <xref target="RFC5286" format="default" secti
onFormat="of" derivedContent="RFC5286"/>. This has introduced ambiguity in that
if a
deployment includes a mix of RSVP-TE support and SR Policy support, for deployment includes a mix of RSVP-TE support and SR Policy support, for
example, it is not possible to unambiguously indicate which example, it is not possible to unambiguously indicate which
advertisements are to be used by RSVP-TE and which advertisements are 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 to be used by SR Policy. If the topologies are fully congruent, this
may not be an issue, but any incongruence leads to ambiguity.</t> may not 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 <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 where RSVP-TE is enabled only on a subset of its links. A link
attribute is advertised for the purpose of another application (e.g., attribute is 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 SR Policy) for a 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 router that is an RSVP-TE head end sees the link attribute being
advertised for that link, it assumes RSVP-TE is enabled on that link, advertised for that link, it assumes RSVP-TE is enabled on that link,
even though it is not. If such an RSVP-TE head-end router tries to set even though it is not. If such an RSVP-TE head-end router tries to set
up an RSVP-TE path via that link, it will result in the path setup up an RSVP-TE path via that link, it will result in a setup failure for t
failure.</t> he 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, <t>This document defines extensions that address these issues. Also,
as evolution of use cases for link attributes can be expected to as evolution of use cases for link attributes can be expected to
continue in the years to come, this document defines a solution that continue in the years to come, this document defines a solution that
is easily extensible for the introduction of new applications and new is easily extensible for the introduction of new applications and new
use cases.</t> use cases.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.1 <section>
"> <name>Requirements Language</name>
<name slugifiedName="name-requirements-language">Requirements Language</ <t>
name> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<t indent="0" pn="section-1.1-1">The key words "<bcp14>MUST</bcp14>", "< IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bc NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
p14>SHALL NOT</bcp14>", RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</b "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
cp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and be interpreted as
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as describe described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
d in when, and only when, they appear in all capitals, as shown here.
BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedCon </t>
tent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" deri
vedContent="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 OSPF, it is only necessary to discuss use cases that already exists in OSPF, 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 derivedCounter="1.">Support for indicating which applications are us
<li pn="section-2-2.1" derivedCounter="1.">Support for indicating which ing the link
applications are using the link attribute advertisements on a link.</li>
attribute advertisements on a link</li> <li derivedCounter="2.">Support for advertising application-specific val
<li pn="section-2-2.2" derivedCounter="2.">Support for advertising appli ues for the same
cation-specific values for the same attribute on a link.</li>
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.
tionFormat="of" derivedContent="RFC7855"/> discusses use cases and requirements Included 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. There is no can be used by one or both of these applications. There is no
requirement for the link attributes advertised on a given link used by requirement for the link attributes advertised on a given link used by
SR Policy to be identical to the link attributes advertised on that same 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 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="LEG_ADV" numbered="true" toc="include" removeInRFC="false" <section anchor="LEG_ADV">
pn="section-3"> <name>Existing Advertisement of Link Attributes</name>
<name slugifiedName="name-existing-advertisement-of-l">Existing Advertisem <t>There are existing advertisements used in support of RSVP-TE. These
ent of Link Attributes</name>
<t indent="0" pn="section-3-1">There are existing advertisements used in s
upport of RSVP-TE. These
advertisements are carried in the OSPFv2 TE Opaque Link State advertisements are carried in the OSPFv2 TE Opaque Link State
Advertisement (LSA) <xref target="RFC3630" format="default" sectionFormat Advertisement (LSA) <xref target="RFC3630"/> and
="of" derivedContent="RFC3630"/> and OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329"/>. Additional RSVP-TE lin
OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329" format="default" sectionF k attributes have been
ormat="of" derivedContent="RFC5329"/>. Additional RSVP-TE link attributes have b defined by <xref target="RFC4203"/>, <xref target="RFC7308"/>, and <xref
een target="RFC7471"/>.</t>
defined by <xref target="RFC4203" format="default" sectionFormat="of" der <t>Extended Link Opaque LSAs as defined in <xref target="RFC7684"/> for OS
ivedContent="RFC4203"/>, <xref target="RFC7308" format="default" sectionFormat=" PFv2 and
of" derivedContent="RFC7308"/>, and <xref target="RFC7471" format="default" sect E-Router-LSAs <xref target="RFC8362"/> for OSPFv3 are used to advertise link
ionFormat="of" derivedContent="RFC7471"/>.</t> attributes that are used by applications other than RSVP-TE or GMPLS <xref tar
<t indent="0" pn="section-3-2">Extended Link Opaque LSAs as defined in <xr get="RFC4203"/>.
ef target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"
/> for OSPFv2 and
E-Router-LSAs <xref target="RFC8362" format="default" sectionFormat="of" deriv
edContent="RFC8362"/> for OSPFv3 are used to advertise link
attributes that are used by applications other than RSVP-TE or GMPLS <xref tar
get="RFC4203" format="default" sectionFormat="of" derivedContent="RFC4203"/>.
These LSAs were defined as generic containers for distribution of the extended link attributes.</t> These LSAs were defined as generic containers for distribution of the extended link attributes.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4"> <section>
<name slugifiedName="name-advertisement-of-link-attri">Advertisement of Li <name>Advertisement of Link Attributes</name>
nk Attributes</name> <t>This section outlines the solution for advertising link attributes
<t indent="0" pn="section-4-1">This section outlines the solution for adve
rtising link attributes
originally defined for RSVP-TE or GMPLS when they are used for other applicat ions.</t> originally defined for RSVP-TE or GMPLS when they are used for other applicat ions.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.1 <section>
"> <name>OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA</name>
<name slugifiedName="name-ospfv2-extended-link-opaque">OSPFv2 Extended L <t>The following are the advantages of Extended Link Opaque LSAs as defi
ink Opaque LSA and OSPFv3 E-Router-LSA</name> ned in <xref target="RFC7684"/>
<t indent="0" pn="section-4.1-1">The following are the advantages of Ext for OSPFv2 and E-Router-LSAs <xref target="RFC8362"/> for OSPFv3 with respect
ended Link Opaque LSAs as defined in <xref target="RFC7684" format="default" sec
tionFormat="of" derivedContent="RFC7684"/>
for OSPFv2 and E-Router-LSAs <xref target="RFC8362" format="default" sectionF
ormat="of" derivedContent="RFC8362"/> for OSPFv3 with respect
to the advertisement of link attributes originally defined for RSVP-TE when u sed in packet to the advertisement of link attributes originally defined for RSVP-TE when u sed in packet
networks and in GMPLS: networks and in GMPLS:
</t> </t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4. <ol>
1-2"> <li derivedCounter="1.">Advertisement of the link attributes does not
<li pn="section-4.1-2.1" derivedCounter="1.">Advertisement of the link make the link part of the RSVP-TE topology.
attributes does not make the link part of the RSVP-TE topology. It avoids any conflicts and is fully compatible with <xref target="RFC3630
It avoids any conflicts and is fully compatible with <xref target="RFC3630 "/> and
" format="default" sectionFormat="of" derivedContent="RFC3630"/> and <xref target="RFC5329"/>.</li>
<xref target="RFC5329" format="default" sectionFormat="of" derivedContent= <li derivedCounter="2.">The OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area
"RFC5329"/>.</li> -TE-LSA remain
<li pn="section-4.1-2.2" derivedCounter="2.">The OSPFv2 TE Opaque LSA truly opaque to OSPFv2 and OSPFv3 as originally defined in <xref targe
and OSPFv3 Intra-Area-TE-LSA remain t="RFC3630"/> and <xref target="RFC5329"/>, respectively. Their contents are not
truly opaque to OSPFv2 and OSPFv3 as originally defined in <xref targe inspected
t="RFC3630" format="default" sectionFormat="of" derivedContent="RFC3630"/> and <
xref target="RFC5329" format="default" sectionFormat="of" derivedContent="RFC532
9"/>, respectively. Their contents are not inspected
by OSPF, which instead acts as a pure transport.</li> by OSPF, which instead acts as a pure transport.</li>
<li pn="section-4.1-2.3" derivedCounter="3.">There is a clear distinct ion between link attributes used by RSVP-TE and <li derivedCounter="3.">There is a clear distinction between link attr ibutes used by RSVP-TE and
link attributes used by other OSPFv2 or OSPFv3 applications.</li> link attributes used by other OSPFv2 or OSPFv3 applications.</li>
<li pn="section-4.1-2.4" derivedCounter="4.">All link attributes that <li derivedCounter="4.">All link attributes that are used by other app
are used by other applications are advertised in the Extended Link Opaque LSA in lications are advertised in the Extended Link Opaque LSA in OSPFv2 <xref target=
OSPFv2 <xref target="RFC7684" format="default" sectionFormat="of" derivedConten "RFC7684"/> or the OSPFv3
t="RFC7684"/> or the OSPFv3 E-Router-LSA <xref target="RFC8362"/> in OSPFv3.</li>
E-Router-LSA <xref target="RFC8362" format="default" sectionFormat="of" d
erivedContent="RFC8362"/> in OSPFv3.</li>
</ol> </ol>
<t indent="0" pn="section-4.1-3">The disadvantage of this approach is th at in rare cases, the same link attribute is <t>The disadvantage of this approach is that in rare cases, the same lin k attribute is
advertised in both the TE Opaque and Extended Link Attribute LSAs in OSPFv2 or advertised in both the TE Opaque and Extended Link Attribute LSAs in OSPFv2 or
the Intra-Area-TE-LSA and E-Router-LSA in OSPFv3.</t> the Intra-Area-TE-LSA and E-Router-LSA in OSPFv3.</t>
<t indent="0" pn="section-4.1-4">The Extended Link Opaque LSA <xref targ <t>The Extended Link Opaque LSA <xref target="RFC7684"/> and E-Router-LS
et="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/> and A
E-Router-LSA <xref target="RFC8362"/> are used to advertise any link attributes used
<xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RF
C8362"/> are used to advertise any link attributes used
for non-RSVP-TE applications in OSPFv2 or OSPFv3, respectively, including tho se that have for non-RSVP-TE applications in OSPFv2 or OSPFv3, respectively, including tho se that have
been originally defined for RSVP-TE applications (see <xref target="REUSED_AT been originally defined for RSVP-TE applications (see <xref target="REUSED_AT
TR" format="default" sectionFormat="of" derivedContent="Section 6"/>).</t> TR"/>).</t>
<t indent="0" pn="section-4.1-5">TE link attributes used for RSVP-TE/GMP <t>TE link attributes used for RSVP-TE/GMPLS continue to use the OSPFv2
LS continue to use the OSPFv2 TE Opaque LSA TE Opaque LSA
<xref target="RFC3630" format="default" sectionFormat="of" derivedContent="RF <xref target="RFC3630"/> and OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329"/
C3630"/> and OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329" format="default" se >.</t>
ctionFormat="of" derivedContent="RFC5329"/>.</t> <t>The format of the link attribute TLVs that have been defined for
<t indent="0" pn="section-4.1-6">The format of the link attribute TLVs t
hat have been defined for
RSVP-TE applications will be kept unchanged even when they are used RSVP-TE applications will be kept unchanged even when they are used
for non-RSVP-TE applications. Unique codepoints are allocated for for non-RSVP-TE applications. Unique codepoints are allocated for
these link attribute TLVs from the "OSPFv2 Extended Link TLV Sub-TLVs" these link attribute TLVs from the "OSPFv2 Extended Link TLV Sub-TLVs"
registry <xref target="RFC7684" format="default" sectionFormat="of" deri registry <xref target="RFC7684"/> and from the
vedContent="RFC7684"/> and from the "OSPFv3 Extended-LSA Sub-TLVs" registry <xref target="RFC8362"/>, as spe
"OSPFv3 Extended-LSA Sub-TLVs" registry <xref target="RFC8362" format="d cified in <xref target="IANA"/>.</t>
efault" sectionFormat="of" derivedContent="RFC8362"/>, as specified in <xref tar
get="IANA" format="default" sectionFormat="of" derivedContent="Section 14"/>.</t
>
</section> </section>
</section> </section>
<section anchor="ADVAPPVAL" numbered="true" toc="include" removeInRFC="false <section anchor="ADVAPPVAL">
" pn="section-5"> <name>Advertisement of Application-Specific Values</name>
<name slugifiedName="name-advertisement-of-applicatio">Advertisement of Ap <t>To allow advertisement of the application-specific values of the link
plication-Specific Values</name> attribute, an Application-Specific Link Attributes (ASLA) sub-TLV is
<t indent="0" pn="section-5-1">To allow advertisement of the application-s defined. The ASLA sub-TLV is a sub-TLV of the OSPFv2 Extended Link TLV
pecific values of the link attribute, a new <xref target="RFC7684"/> and OSPFv3 Router-Link TLV <xref
Application-Specific Link Attributes (ASLA) sub-TLV is defined. The ASLA sub-T target="RFC8362"/>.</t>
LV is a sub-TLV <t>In addition to advertising the link attributes for standardized
of the OSPFv2 Extended Link TLV <xref target="RFC7684" format="default" section
Format="of" derivedContent="RFC7684"/> and OSPFv3 Router-Link TLV
<xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC8
362"/>.</t>
<t indent="0" pn="section-5-2">In addition to advertising the link attribu
tes for standardized
applications, link attributes can be advertised for the purpose of applications, link attributes can be advertised for the purpose of
applications that are not standardized. We call such an applications that are not standardized. We call such an
application a "user-defined application" or "UDA". These applications are application a "user-defined application" or "UDA". These applications are
not subject to standardization and are outside of the scope not subject to standardization and are outside of the scope
of this specification.</t> of this specification.</t>
<t indent="0" pn="section-5-3">The ASLA sub-TLV is an optional sub-TLV of the OSPFv2 Extended Link TLV and <t>The ASLA sub-TLV is an optional sub-TLV of the OSPFv2 Extended Link TLV and
OSPFv3 Router-Link TLV. Multiple ASLA sub-TLVs can be present in a parent OSPFv3 Router-Link TLV. Multiple ASLA sub-TLVs can be present in a parent
TLV when different applications want to control different link attributes or TLV when different applications want to control different link attributes or
when a different value when a different value
of the same attribute needs to be advertised by multiple applications. The ASLA sub-TLV of the same attribute needs to be advertised by multiple applications. The ASLA sub-TLV
<bcp14>MUST</bcp14> be used for advertisement of the link attributes listed at t he end of this section <bcp14>MUST</bcp14> be used for advertisement of the link attributes listed at t he end of this section
if these are advertised inside the OSPFv2 Extended Link TLV and OSPFv3 Router-Li nk TLV. if these are advertised inside the OSPFv2 Extended Link TLV and OSPFv3 Router-Li nk TLV.
It has the following format: It has the following format:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-5-4"> <artwork name="" type="" alt="">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SABM Length | UDABM Length | Reserved | | SABM Length | UDABM Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Standard Application Identifier Bit Mask(SABM) | | Standard Application Identifier Bit Mask (SABM) |
+- -+ +- -+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-Defined Application Identifier Bit Mask(UDABM) | | User-Defined Application Identifier Bit Mask (UDABM) |
+- -+ +- -+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Attribute sub-sub-TLVs | | Link Attribute sub-TLVs |
+- -+ +- -+
| ... | | ... |
</artwork> </artwork>
<t indent="0" pn="section-5-5"> where:</t> <t> where:</t>
<dl newline="false" indent="3" spacing="normal" pn="section-5-6"> <dl>
<dt pn="section-5-6.1">Type:</dt> <dt>Type:</dt>
<dd pn="section-5-6.2"> 10 (OSPFv2), 11 (OSPFv3)</dd> <dd>10 (OSPFv2), 11 (OSPFv3)</dd>
<dt pn="section-5-6.3">Length:</dt> <dt>Length:</dt>
<dd pn="section-5-6.4"> Variable</dd> <dd>Variable</dd>
<dt pn="section-5-6.5">SABM Length:</dt> <dt>SABM Length:</dt>
<dd pn="section-5-6.6"> Standard Application Identifier Bit Mask Length <dd>Standard Application Identifier Bit Mask Length in octets.
in octets.
The value <bcp14>MUST</bcp14> be 0, 4, or 8. The value <bcp14>MUST</bcp14> be 0, 4, or 8.
If the Standard Application Identifier Bit Mask is not present, the SABM If the Standard Application Identifier Bit Mask is not present, the SABM
Length <bcp14>MUST</bcp14> be set to 0.</dd> Length <bcp14>MUST</bcp14> be set to 0.</dd>
<dt pn="section-5-6.7">UDABM Length:</dt> <dt>UDABM Length:</dt>
<dd pn="section-5-6.8"> User-Defined Application Identifier Bit Mask Len <dd>User-Defined Application Identifier Bit Mask Length in octets.
gth in octets.
The value <bcp14>MUST</bcp14> be 0, 4, or 8. The value <bcp14>MUST</bcp14> be 0, 4, or 8.
If the User-Defined Application Identifier Bit Mask is not present, the If the User-Defined Application Identifier Bit Mask is not present, the
UDABM Length <bcp14>MUST</bcp14> be set to 0.</dd> UDABM Length <bcp14>MUST</bcp14> be set to 0.</dd>
<dt pn="section-5-6.9">Standard Application Identifier Bit Mask:</dt> <dt>Standard Application Identifier Bit Mask:</dt>
<dd pn="section-5-6.10"> <dd>
<t indent="0" pn="section-5-6.10.1">Optional <t>Optional
set of bits, where each bit represents a single standard set of bits, where each bit represents a single standard
application. Bits are defined in the "Link Attribute Applications" application. Bits are defined in the "Link Attribute Application Ident
registry, which is defined in <xref target="RFC8919" format="default" ifiers"
sectionFormat="of" derivedContent="RFC8919"/>. Current assignments are repeated registry, which is defined in <xref target="RFC9479"/>. Current assig
here for nments are repeated here for
informational purposes:</t> informational purposes:</t>
<artwork name="" type="" align="left" alt="" pn="section-5-6.10.2"> <artwork name="" align="center" type="" alt="">
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 newline="false" spacing="normal" indent="3" pn="section-5-6.10.3"> -+-+-+-+-+-+-+-+...
<dt pn="section-5-6.10.3.1">Bit 0 (R-bit):</dt> <dl>
<dd pn="section-5-6.10.3.2"> RSVP-TE.</dd> <dt>Bit 0 (R-bit):</dt>
<dt pn="section-5-6.10.3.3">Bit 1 (S-bit):</dt> <dd>RSVP-TE.</dd>
<dd pn="section-5-6.10.3.4"> Segment Routing Policy. <dt>Bit 1 (S-bit):</dt>
(this is dataplane independent).</dd> <dd>SR Policy (this is data plane independent).</dd>
<dt pn="section-5-6.10.3.5">Bit 2 (F-bit):</dt> <dt>Bit 2 (F-bit):</dt>
<dd pn="section-5-6.10.3.6"> Loop-Free Alternate (LFA). Includes all <dd>Loop-Free Alternate (includes all LFA
LFA types.</dd> types).</dd>
</dl> </dl>
</dd> </dd>
<dt pn="section-5-6.11">User-Defined Application Identifier Bit Mask:</d <dt>User-Defined Application Identifier Bit Mask:</dt>
t> <dd>Optional set of bits, where each bit
<dd pn="section-5-6.12"> Optional set of bits, where each bit
represents a single user-defined application.</dd> represents a single user-defined application.</dd>
</dl> </dl>
<t indent="0" pn="section-5-7">If the SABM or UDABM Length is other than 0 , 4, or 8, the ASLA sub-TLV <bcp14>MUST</bcp14> be ignored <t>If the SABM or UDABM Length is other than 0, 4, or 8, the ASLA sub-TLV <bcp14>MUST</bcp14> be ignored
by the receiver.</t> by the receiver.</t>
<t indent="0" pn="section-5-8">Standard Application Identifier Bits are de fined and sent starting with <t>Standard Application Identifier Bits are defined and sent starting with
bit 0. Undefined bits that are transmitted <bcp14>MUST</bcp14> be transmitte d as 0 and <bcp14>MUST</bcp14> be ignored bit 0. Undefined bits that are transmitted <bcp14>MUST</bcp14> be transmitte d as 0 and <bcp14>MUST</bcp14> be ignored
on receipt. Bits that are not transmitted <bcp14>MUST</bcp14> be treated as if they on receipt. Bits that are not transmitted <bcp14>MUST</bcp14> be treated as if they
are set to 0 on receipt. Bits that are not supported by an are set to 0 on receipt. Bits that are not supported by an
implementation <bcp14>MUST</bcp14> be ignored on receipt.</t> implementation <bcp14>MUST</bcp14> be ignored on receipt.</t>
<t indent="0" pn="section-5-9">User-Defined Application Identifier Bits ha ve 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 these bits be used any other standards body. It is recommended that these bits be used
starting with bit 0 so as to minimize the number of octets required starting with bit 0 so as to minimize the number of octets required
to advertise all UDAs. Undefined bits that are transmitted <bcp14>MUST</bcp14 > be to advertise all UDAs. Undefined bits that are transmitted <bcp14>MUST</bcp14 > be
transmitted as 0 and <bcp14>MUST</bcp14> be ignored on receipt. Bits that are not transmitted as 0 and <bcp14>MUST</bcp14> be ignored on receipt. Bits that are not
transmitted <bcp14>MUST</bcp14> be treated as if they are set to 0 on receipt . Bits that are not transmitted <bcp14>MUST</bcp14> be treated as if they are set to 0 on receipt . Bits that are not
supported by an implementation <bcp14>MUST</bcp14> be ignored on receipt.</t> supported by an implementation <bcp14>MUST</bcp14> be ignored on receipt.</t>
<t indent="0" pn="section-5-10">If the link attribute advertisement is int <t>If the link attribute advertisement is intended to be only used by a sp
ended to be only used by a specific set of applications, ecific set of applications,
corresponding bit masks <bcp14>MUST</bcp14> be present, and application-specific corresponding bit masks <bcp14>MUST</bcp14> be present and one or more applicati
bit(s) <bcp14>MUST</bcp14> be set for all on-specific bits <bcp14>MUST</bcp14> be set for all
applications that use the link attributes advertised in the ASLA sub-TLV.</t> applications that use the link attributes advertised in the ASLA sub-TLV.</t>
<t indent="0" pn="section-5-11">Application Identifier Bit Masks apply to all link attributes that support application-specific <t>Application Identifier Bit Masks apply to all link attributes that supp ort application-specific
values and are advertised in the ASLA sub-TLV.</t> values and are advertised in the ASLA sub-TLV.</t>
<t indent="0" pn="section-5-12">The advantage of not making the Applicatio n Identifier Bit Masks part of the attribute advertisement <t>The advantage of not making the Application Identifier Bit Masks part o f the attribute advertisement
itself is that the format of any previously defined link attributes itself is that the format of any previously defined link attributes
can be kept and reused when advertising them in the ASLA sub-TLV.</t> can be kept and reused when advertising them in the ASLA sub-TLV.</t>
<t indent="0" pn="section-5-13">If the same attribute is advertised in mor e than one ASLA sub-TLVs with the application <t>If the same attribute is advertised in more than one ASLA sub-TLV with the application
listed in the Application Identifier Bit Masks, the application <bcp14>SHOULD</b cp14> use the first instance of listed in the Application Identifier Bit Masks, the application <bcp14>SHOULD</b cp14> use the first instance of
advertisement and ignore any subsequent advertisements of that attribute.</t> advertisement and ignore any subsequent advertisements of that attribute.</t>
<t indent="0" pn="section-5-14">Link attributes MAY be advertised associat ed with zero-length <t>Link attributes <bcp14>MAY</bcp14> be advertised associated with zero-l ength
Application Identifier Bit Masks for both standard applications Application Identifier Bit Masks for both standard applications
and user-defined applications. Such link attribute advertisements and user-defined applications. Such link attribute advertisements
MUST be used by standard applications and/or user defined applications <bcp14>MUST</bcp14> be used by standard applications and/or user-defined a pplications
when no link attribute advertisements with a non-zero-length when no link attribute advertisements with a non-zero-length
Application Identifier Bit Mask and a matching Application Identifier Application Identifier Bit Mask and a matching Application Identifier
Bit set are present. Otherwise, such link attribute Bit set are present. Otherwise, such link attribute
advertisements MUST NOT be used.</t> advertisements <bcp14>MUST NOT</bcp14> be used.</t>
<t indent="0" pn="section-5-15">This document defines the initial set of l <t>This document defines the initial set of link attributes that <bcp14>MU
ink attributes that <bcp14>MUST</bcp14> use the ASLA sub-TLV if ST</bcp14> use the ASLA sub-TLV if
advertised in the OSPFv2 Extended Link TLV or in the OSPFv3 Router-Link TLV. advertised in the OSPFv2 Extended Link TLV or in the OSPFv3 Router-Link TLV.
Documents that define new link attributes <bcp14>MUST</bcp14> state whether the new attributes support Documents that define new link attributes <bcp14>MUST</bcp14> state whether the new attributes support
application-specific values and, as such, are advertised in an ASLA sub-TLV. The standard application-specific values and, as such, are advertised in an ASLA sub-TLV. The standard
link attributes that are advertised in ASLA sub-TLVs are: link attributes that are advertised in ASLA sub-TLVs are:
</t> </t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-5-1 <ul>
6"> <li>Shared Risk Link Group <xref target="RFC4203"/></li>
<li pn="section-5-16.1"> Shared Risk Link Group <xref target="RFC4203" f <li>Unidirectional Link Delay <xref target="RFC7471"/></li>
ormat="default" sectionFormat="of" derivedContent="RFC4203"/></li> <li>Min/Max Unidirectional Link Delay <xref target="RFC7471"/></li>
<li pn="section-5-16.2"> Unidirectional Link Delay <xref target="RFC7471 <li>Unidirectional Delay Variation <xref target="RFC7471"/></li>
" format="default" sectionFormat="of" derivedContent="RFC7471"/></li> <li>Unidirectional Link Loss <xref target="RFC7471"/></li>
<li pn="section-5-16.3"> Min/Max Unidirectional Link Delay <xref target= <li>Unidirectional Residual Bandwidth <xref target="RFC7471"/></li>
"RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/></li> <li>Unidirectional Available Bandwidth <xref target="RFC7471"/></li>
<li pn="section-5-16.4"> Unidirectional Delay Variation <xref target="RF <li>Unidirectional Utilized Bandwidth <xref target="RFC7471"/></li>
C7471" format="default" sectionFormat="of" derivedContent="RFC7471"/></li> <li>Administrative Group <xref target="RFC3630"/></li>
<li pn="section-5-16.5"> Unidirectional Link Loss <xref target="RFC7471" <li>Extended Administrative Group <xref target="RFC7308"/></li>
format="default" sectionFormat="of" derivedContent="RFC7471"/></li> <li>TE Metric <xref target="RFC3630"/></li>
<li pn="section-5-16.6"> Unidirectional Residual Bandwidth <xref target=
"RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/></li>
<li pn="section-5-16.7"> Unidirectional Available Bandwidth <xref target
="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/></li>
<li pn="section-5-16.8"> Unidirectional Utilized Bandwidth <xref target=
"RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/></li>
<li pn="section-5-16.9"> Administrative Group <xref target="RFC3630" for
mat="default" sectionFormat="of" derivedContent="RFC3630"/></li>
<li pn="section-5-16.10"> Extended Administrative Group <xref target="RF
C7308" format="default" sectionFormat="of" derivedContent="RFC7308"/></li>
<li pn="section-5-16.11"> TE Metric <xref target="RFC3630" format="defau
lt" sectionFormat="of" derivedContent="RFC3630"/></li>
</ul> </ul>
</section> </section>
<section anchor="REUSED_ATTR" numbered="true" toc="include" removeInRFC="fal <section anchor="REUSED_ATTR">
se" pn="section-6"> <name>Reused TE Link Attributes</name>
<name slugifiedName="name-reused-te-link-attributes">Reused TE Link Attrib <t>This section defines the use case and indicates the codepoints (<xref t
utes</name> arget="IANA"/>) from the "OSPFv2 Extended Link TLV
<t indent="0" pn="section-6-1">This section defines the use case and indic
ates the codepoints (<xref target="IANA" format="default" sectionFormat="of" der
ivedContent="Section 14"/>) from the "OSPFv2 Extended Link TLV
Sub-TLVs" registry and "OSPFv3 Extended-LSA Sub-TLVs" registry for some of Sub-TLVs" registry and "OSPFv3 Extended-LSA Sub-TLVs" registry for some of
the link attributes that have been originally defined for RSVP-TE or the link attributes that have been originally defined for RSVP-TE or
GMPLS.</t> GMPLS.</t>
<section anchor="SRLG" numbered="true" toc="include" removeInRFC="false" p <section anchor="SRLG">
n="section-6.1"> <name>Shared Risk Link Group (SRLG)</name>
<name slugifiedName="name-shared-risk-link-group-srlg">Shared Risk Link <t>The SRLG of a link can be used in OSPF-calculated IPFRR (IP Fast Reroute)
Group (SRLG)</name> <xref target="RFC5714"/> to compute a backup path
<t indent="0" pn="section-6.1-1">The SRLG of a link can be used in OSPF- that does not share any SRLG with the protected link.</t>
calculated IPFRR (IP Fast Reroute) <t>To advertise the SRLG of the link in the OSPFv2 Extended Link TLV, th
<xref target="RFC5714" format="default" sectionFormat="of" derivedContent="RF e same format
C5714"/> to compute a backup path for the sub-TLV defined in <xref target="RFC4203" section="1.3"/> is used wit
that does not share any SRLG group with the protected link.</t> h TLV
<t indent="0" pn="section-6.1-2">To advertise the SRLG of the link in th
e OSPFv2 Extended Link TLV, the same format
for the sub-TLV defined in <xref target="RFC4203" sectionFormat="of" section=
"1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4203#section-1
.3" derivedContent="RFC4203"/> is used with TLV
type 11. Similarly, for OSPFv3 to advertise the SRLG in the OSPFv3 Router-Lin k type 11. Similarly, for OSPFv3 to advertise the SRLG in the OSPFv3 Router-Lin k
TLV, TLV type 12 is used.</t> TLV, TLV type 12 is used.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6.2 <section>
"> <name>Extended Metrics</name>
<name slugifiedName="name-extended-metrics">Extended Metrics</name> <t><xref target="RFC3630"/> defines several link bandwidth types. <xref
<t indent="0" pn="section-6.2-1"><xref target="RFC3630" format="default" target="RFC7471"/>
sectionFormat="of" derivedContent="RFC3630"/> defines several link bandwidth ty
pes. <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="
RFC7471"/>
defines extended link metrics that are based on link bandwidth, delay, and los s defines extended link metrics that are based on link bandwidth, delay, and los s
characteristics. All of these can be used to compute primary and backup paths within an characteristics. All of these can be used to compute primary and backup paths within an
OSPF area to satisfy requirements for bandwidth, delay (nominal or worst case) , or loss.</t> OSPF area to satisfy requirements for bandwidth, delay (nominal or worst case) , or loss.</t>
<t indent="0" pn="section-6.2-2">To advertise extended link metrics in t <t>To advertise extended link metrics in the OSPFv2 Extended Link TLV, t
he OSPFv2 Extended Link TLV, the same format he same format
for the sub-TLVs defined in <xref target="RFC7471" format="default" sectionF for the sub-TLVs defined in <xref target="RFC7471"/> is used with the follow
ormat="of" derivedContent="RFC7471"/> is used with the following ing
TLV types: TLV types:
</t> </t>
<dl indent="3" newline="false" spacing="normal" pn="section-6.2-3"> <dl>
<dt pn="section-6.2-3.1">12:</dt> <dt>12:</dt>
<dd pn="section-6.2-3.2"> Unidirectional Link Delay</dd> <dd>Unidirectional Link Delay</dd>
<dt pn="section-6.2-3.3">13:</dt> <dt>13:</dt>
<dd pn="section-6.2-3.4"> Min/Max Unidirectional Link Delay</dd> <dd>Min/Max Unidirectional Link Delay</dd>
<dt pn="section-6.2-3.5">14:</dt> <dt>14:</dt>
<dd pn="section-6.2-3.6"> Unidirectional Delay Variation</dd> <dd>Unidirectional Delay Variation</dd>
<dt pn="section-6.2-3.7">15:</dt> <dt>15:</dt>
<dd pn="section-6.2-3.8"> Unidirectional Link Loss</dd> <dd>Unidirectional Link Loss</dd>
<dt pn="section-6.2-3.9">16:</dt> <dt>16:</dt>
<dd pn="section-6.2-3.10"> Unidirectional Residual Bandwidth</dd> <dd>Unidirectional Residual Bandwidth</dd>
<dt pn="section-6.2-3.11">17:</dt> <dt>17:</dt>
<dd pn="section-6.2-3.12"> Unidirectional Available Bandwidth</dd> <dd>Unidirectional Available Bandwidth</dd>
<dt pn="section-6.2-3.13">18:</dt> <dt>18:</dt>
<dd pn="section-6.2-3.14"> Unidirectional Utilized Bandwidth</dd> <dd>Unidirectional Utilized Bandwidth</dd>
</dl> </dl>
<t indent="0" pn="section-6.2-4">To advertise extended link metrics in t <t>To advertise extended link metrics in the Router-Link TLV inside
he Router-Link TLV inside the OSPFv3 E-Router-LSA, the same format for the sub-TLVs defined in <xre
the OSPFv3 E-Router-LSA, the same format for the sub-TLVs defined in <xre f target="RFC7471"/> is used with the following
f target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/
> is used with the following
TLV types: TLV types:
</t> </t>
<dl indent="3" newline="false" spacing="normal" pn="section-6.2-5"> <dl>
<dt pn="section-6.2-5.1">13:</dt> <dt>13:</dt>
<dd pn="section-6.2-5.2"> Unidirectional Link Delay</dd> <dd>Unidirectional Link Delay</dd>
<dt pn="section-6.2-5.3">14:</dt> <dt>14:</dt>
<dd pn="section-6.2-5.4"> Min/Max Unidirectional Link Delay</dd> <dd>Min/Max Unidirectional Link Delay</dd>
<dt pn="section-6.2-5.5">15:</dt> <dt>15:</dt>
<dd pn="section-6.2-5.6"> Unidirectional Delay Variation</dd> <dd>Unidirectional Delay Variation</dd>
<dt pn="section-6.2-5.7">16:</dt> <dt>16:</dt>
<dd pn="section-6.2-5.8"> Unidirectional Link Loss</dd> <dd>Unidirectional Link Loss</dd>
<dt pn="section-6.2-5.9">17:</dt> <dt>17:</dt>
<dd pn="section-6.2-5.10"> Unidirectional Residual Bandwidth</dd> <dd>Unidirectional Residual Bandwidth</dd>
<dt pn="section-6.2-5.11">18:</dt> <dt>18:</dt>
<dd pn="section-6.2-5.12"> Unidirectional Available Bandwidth</dd> <dd>Unidirectional Available Bandwidth</dd>
<dt pn="section-6.2-5.13">19:</dt> <dt>19:</dt>
<dd pn="section-6.2-5.14"> Unidirectional Utilized Bandwidth</dd> <dd>Unidirectional Utilized Bandwidth</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6.3 <section>
"> <name>Administrative Group</name>
<name slugifiedName="name-administrative-group">Administrative Group</na <t><xref target="RFC3630"/> and <xref target="RFC7308"/> define the Admi
me> nistrative Group and
<t indent="0" pn="section-6.3-1"><xref target="RFC3630" format="default"
sectionFormat="of" derivedContent="RFC3630"/> and <xref target="RFC7308" format
="default" sectionFormat="of" derivedContent="RFC7308"/> define the Administrati
ve Group and
Extended Administrative Group sub-TLVs, respectively.</t> Extended Administrative Group sub-TLVs, respectively.</t>
<t indent="0" pn="section-6.3-2">To advertise the Administrative Group a <t>To advertise the Administrative Group and Extended Administrative Gro
nd Extended Administrative Group in the OSPFv2 up in the OSPFv2
Extended Link TLV, the same format for the sub-TLVs defined in <xref target= Extended Link TLV, the same format for the sub-TLVs defined in <xref target=
"RFC3630" format="default" sectionFormat="of" derivedContent="RFC3630"/> "RFC3630"/>
and <xref target="RFC7308" format="default" sectionFormat="of" derivedConten and <xref target="RFC7308"/> is used with the following TLV types:
t="RFC7308"/> is used with the following TLV types:
</t> </t>
<dl indent="3" newline="false" spacing="normal" pn="section-6.3-3"> <dl>
<dt pn="section-6.3-3.1">19:</dt> <dt>19:</dt>
<dd pn="section-6.3-3.2"> Administrative Group</dd> <dd>Administrative Group</dd>
<dt pn="section-6.3-3.3">20:</dt> <dt>20:</dt>
<dd pn="section-6.3-3.4"> Extended Administrative Group</dd> <dd>Extended Administrative Group</dd>
</dl> </dl>
<t indent="0" pn="section-6.3-4">To advertise the Administrative Group a <t>To advertise the Administrative Group and Extended Administrative Gro
nd Extended Administrative Group in the OSPFv3 up in the OSPFv3
Router-Link TLV, the same format for the sub-TLVs defined in <xref target="R Router-Link TLV, the same format for the sub-TLVs defined in <xref target="R
FC3630" format="default" sectionFormat="of" derivedContent="RFC3630"/> FC3630"/>
and <xref target="RFC7308" format="default" sectionFormat="of" derivedConten and <xref target="RFC7308"/> is used with the following TLV types:
t="RFC7308"/> is used with the following TLV types:
</t> </t>
<dl indent="3" newline="false" spacing="normal" pn="section-6.3-5"> <dl>
<dt pn="section-6.3-5.1">20:</dt> <dt>20:</dt>
<dd pn="section-6.3-5.2"> Administrative Group</dd> <dd>Administrative Group</dd>
<dt pn="section-6.3-5.3">21:</dt> <dt>21:</dt>
<dd pn="section-6.3-5.4"> Extended Administrative Group</dd> <dd>Extended Administrative Group</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6.4 <section>
"> <name>TE Metric</name>
<name slugifiedName="name-traffic-engineering-metric">Traffic Engineerin <t><xref target="RFC3630"/> defines the TE Metric.</t>
g Metric</name> <t>To advertise the TE Metric in the OSPFv2 Extended Link TLV,
<t indent="0" pn="section-6.4-1"><xref target="RFC3630" format="default" the same format for the sub-TLV defined in <xref target="RFC3630" section="2.5
sectionFormat="of" derivedContent="RFC3630"/> defines the Traffic Engineering M .5"/>
etric.</t>
<t indent="0" pn="section-6.4-2">To advertise the Traffic Engineering Me
tric in the OSPFv2 Extended Link TLV,
the same format for the sub-TLV defined in <xref target="RFC3630" sectionForma
t="of" section="2.5.5" format="default" derivedLink="https://rfc-editor.org/rfc/
rfc3630#section-2.5.5" derivedContent="RFC3630"/>
is used with TLV type 22. Similarly, for OSPFv3 to advertise the is used with TLV type 22. Similarly, for OSPFv3 to advertise the
Traffic Engineering Metric in the OSPFv3 Router-Link TLV, TLV type 22 is used. </t> TE Metric in the OSPFv3 Router-Link TLV, TLV type 22 is used.</t>
</section> </section>
</section> </section>
<section anchor="SPECIALMAXBANDW" numbered="true" toc="include" removeInRFC= <section anchor="SPECIALMAXBANDW">
"false" pn="section-7"> <name>Maximum Link Bandwidth</name>
<name slugifiedName="name-maximum-link-bandwidth">Maximum Link Bandwidth</ <t>Maximum link bandwidth is an application-independent attribute of the
name> link that is defined in <xref target="RFC3630"/>. Because
<t indent="0" pn="section-7-1">Maximum link bandwidth is an application-in
dependent attribute of the
link that is defined in <xref target="RFC3630" format="default" sectionFormat=
"of" derivedContent="RFC3630"/>. Because
it is an application-independent attribute, it <bcp14>MUST NOT</bcp14> be it is an application-independent attribute, it <bcp14>MUST NOT</bcp14> be
advertised in the ASLA sub-TLV. advertised in the ASLA sub-TLV.
Instead, it <bcp14>MAY</bcp14> be Instead, it <bcp14>MAY</bcp14> be
advertised as a sub-TLV of the Extended Link TLV in the Extended Link Opaque advertised as a sub-TLV of the Extended Link TLV in the Extended Link Opaque
LSA in OSPFv2 <xref target="RFC7684" format="default" sectionFormat="of" deriv edContent="RFC7684"/> or as a sub-TLV of LSA in OSPFv2 <xref target="RFC7684"/> or as a sub-TLV of
the Router-Link TLV in the E-Router-LSA Router-Link TLV in OSPFv3 the Router-Link TLV in the E-Router-LSA Router-Link TLV in OSPFv3
<xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC <xref target="RFC8362"/>.</t>
8362"/>.</t> <t>To advertise the maximum link bandwidth in the OSPFv2 Extended Link TLV
<t indent="0" pn="section-7-2">To advertise the maximum link bandwidth in , the same
the OSPFv2 Extended Link TLV, the same format for the sub-TLV defined in <xref target="RFC3630"/> is used with
format for the sub-TLV defined in <xref target="RFC3630" format="default" sect
ionFormat="of" derivedContent="RFC3630"/> is used with
TLV type 23.</t> TLV type 23.</t>
<t indent="0" pn="section-7-3">To advertise the maximum link bandwidth in <t>To advertise the maximum link bandwidth in the OSPFv3 Router-Link TLV,
the OSPFv3 Router-Link TLV, the same the same
format for the sub-TLV defined in <xref target="RFC3630" format="default" sect format for the sub-TLV defined in <xref target="RFC3630"/> is used with
ionFormat="of" derivedContent="RFC3630"/> is used with
TLV type 23.</t> TLV type 23.</t>
</section> </section>
<section anchor="EXT_METRICS" numbered="true" toc="include" removeInRFC="fal <section anchor="EXT_METRICS">
se" pn="section-8"> <name>Considerations for Extended TE Metrics</name>
<name slugifiedName="name-considerations-for-extended">Considerations for <t><xref target="RFC7471"/> defines a number of dynamic performance metric
Extended TE Metrics</name> s associated
<t indent="0" pn="section-8-1"><xref target="RFC7471" format="default" sec
tionFormat="of" derivedContent="RFC7471"/> defines a number of dynamic performan
ce metrics associated
with a link. It is conceivable that such metrics could be measured with a link. It is conceivable that such metrics could be measured
specific to traffic associated with a specific application. specific to traffic associated with a specific application.
Therefore, this document includes support for advertising these link Therefore, this document includes support for advertising these link
attributes specific to a given application. However, in practice, it attributes specific to a given application. However, in practice, it
may well be more practical to have these metrics reflect the may well be more practical to have these metrics reflect the
performance of all traffic on the link regardless of application. In performance of all traffic on the link regardless of application. In
such cases, advertisements for these attributes can be associated such cases, advertisements for these attributes can be associated
with all of the applications utilizing that link. This can be done with all of the applications utilizing that link. This can be done
either by explicitly specifying the applications in the Application either by explicitly specifying the applications in the Application
Identifier Bit Mask or by using a zero-length Application Identifier Identifier Bit Mask or by using a zero-length Application Identifier
Bit Mask. The use of zero-length Application Identifier Bit Mask is Bit Mask. The use of zero-length Application Identifier Bit Mask is
further discussed in <xref target="ZLABM" format="default" sectionFormat="of" derivedContent="Section 12.2"/>.</t> further discussed in <xref target="ZLABM"/>.</t>
</section> </section>
<section anchor="LOCALIPV6ADDR" numbered="true" toc="include" removeInRFC="f <section anchor="LOCALIPV6ADDR">
alse" pn="section-9"> <name>Local Interface IPv6 Address Sub-TLV</name>
<name slugifiedName="name-local-interface-ipv6-addres">Local Interface IPv <t>The Local Interface IPv6 Address sub-TLV is an application-independent
6 Address Sub-TLV</name> attribute of the
<t indent="0" pn="section-9-1">The Local Interface IPv6 Address sub-TLV is link that is defined in <xref target="RFC5329"/>. Because it is an application
an application-independent attribute of the -independent attribute, it <bcp14>MUST NOT</bcp14> be advertised in the ASLA sub
link that is defined in <xref target="RFC5329" format="default" sectionFormat= -TLV. Instead, it <bcp14>MAY</bcp14> be
"of" derivedContent="RFC5329"/>. Because it is an application-independent attrib advertised as a sub-TLV of the Router-Link TLV inside the OSPFv3 E-Router-LSA
ute, it <bcp14>MUST NOT</bcp14> be advertised in the ASLA sub-TLV. Instead, it <xref target="RFC8362"/>.</t>
<bcp14>MAY</bcp14> be <t>To advertise the Local Interface IPv6 Address sub-TLV in the OSPFv3 Rou
advertised as a sub-TLV of the Router-Link TLV inside the OSPFv3 E-Router-LSA ter-Link TLV,
<xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC83 the same format for the sub-TLV defined in <xref target="RFC5329"/> is used wi
62"/>.</t> th
<t indent="0" pn="section-9-2">To advertise the Local Interface IPv6 Addre
ss sub-TLV in the OSPFv3 Router-Link TLV,
the same format for the sub-TLV defined in <xref target="RFC5329" format="defa
ult" sectionFormat="of" derivedContent="RFC5329"/> is used with
TLV type 24.</t> TLV type 24.</t>
</section> </section>
<section anchor="REMOTEIPV6ADDR" numbered="true" toc="include" removeInRFC=" <section anchor="REMOTEIPV6ADDR">
false" pn="section-10"> <name>Remote Interface IPv6 Address Sub-TLV</name>
<name slugifiedName="name-remote-interface-ipv6-addre">Remote Interface IP <t>The Remote Interface IPv6 Address sub-TLV is an application-independent
v6 Address Sub-TLV</name> attribute of the
<t indent="0" pn="section-10-1">The Remote Interface IPv6 Address sub-TLV link that is defined in <xref target="RFC5329"/>. Because it is an application
is an application-independent attribute of the -independent attribute, it <bcp14>MUST NOT</bcp14> be advertised in the ASLA sub
link that is defined in <xref target="RFC5329" format="default" sectionFormat= -TLV. Instead, it <bcp14>MAY</bcp14> be
"of" derivedContent="RFC5329"/>. Because it is an application-independent attrib advertised as a sub-TLV of the Router-Link TLV inside the OSPFv3 E-Router-LSA
ute, it <bcp14>MUST NOT</bcp14> be advertised in the ASLA sub-TLV. Instead, it < <xref target="RFC8362"/>.</t>
bcp14>MAY</bcp14> be <t>To advertise the Remote Interface IPv6 Address sub-TLV in the OSPFv3 Ro
advertised as a sub-TLV of the Router-Link TLV inside the OSPFv3 E-Router-LSA uter-Link TLV,
<xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC83 the same format for the sub-TLV defined in <xref target="RFC5329"/> is used wi
62"/>.</t> th
<t indent="0" pn="section-10-2">To advertise the Remote Interface IPv6 Add
ress sub-TLV in the OSPFv3 Router-Link TLV,
the same format for the sub-TLV defined in <xref target="RFC5329" format="defa
ult" sectionFormat="of" derivedContent="RFC5329"/> is used with
TLV type 25.</t> TLV type 25.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-11"> <section>
<name slugifiedName="name-attribute-advertisements-an">Attribute Advertise <name>Attribute Advertisements and Enablement</name>
ments and Enablement</name> <t>This document defines extensions to support the advertisement of
<t indent="0" pn="section-11-1">This document defines extensions to suppor
t the advertisement of
application-specific link attributes.</t> application-specific link attributes.</t>
<t indent="0" pn="section-11-2">There are applications where the applicati on enablement on the link <t>There are applications where the application enablement on the link
is relevant; for example, with RSVP-TE, one needs to make sure that RSVP is relevant; for example, with RSVP-TE, one needs to make sure that RSVP
is enabled on the link before sending an RSVP-TE signaling message over it .</t> is enabled on the link before sending an RSVP-TE signaling message over it .</t>
<t indent="0" pn="section-11-3">There are applications where the enablemen t of the application on the link is <t>There are applications where the enablement of the application on the l ink is
irrelevant and has nothing to do with the fact that some link attributes are advertised irrelevant and has nothing to do with the fact that some link attributes are advertised
for the purpose of such application. An example of this is LFA.</t> for the purpose of such application. An example of this is LFA.</t>
<t indent="0" pn="section-11-4">Whether the presence of link attribute adv ertisements for a given <t>Whether the presence of link attribute advertisements for a given
application indicates that the application is enabled on that link application indicates that the application is enabled on that link
depends upon the application. Similarly, whether the absence of link depends upon the application. Similarly, whether the absence of link
attribute advertisements indicates that the application is not attribute advertisements indicates that the application is not
enabled depends upon the application.</t> enabled depends upon the application.</t>
<t indent="0" pn="section-11-5">In the case of RSVP-TE, the advertisement of application-specific <t>In the case of RSVP-TE, the advertisement of application-specific
link attributes has no implication of RSVP-TE being enabled on that link. link attributes has no implication of RSVP-TE being enabled on that link.
The RSVP-TE enablement is solely derived from the information carried in The RSVP-TE enablement is solely derived from the information carried in
the OSPFv2 TE Opaque LSA <xref target="RFC3630" format="default" sectionForm the OSPFv2 TE Opaque LSA <xref target="RFC3630"/> and OSPFv3 Intra-Area-TE-L
at="of" derivedContent="RFC3630"/> and OSPFv3 Intra-Area-TE-LSA SA
<xref target="RFC5329" format="default" sectionFormat="of" derivedContent="RF <xref target="RFC5329"/>.</t>
C5329"/>.</t> <t>In the case of SR Policy, advertisement of application-specific link
<t indent="0" pn="section-11-6">In the case of SR Policy, advertisement of
application-specific link
attributes does not indicate enablement of SR Policy. The advertisements attributes does not indicate enablement of SR Policy. The advertisements
are only used to support constraints that may be applied when are only used to support constraints that may be applied when
specifying an explicit path. SR Policy is implicitly enabled on all links specifying an explicit path. SR Policy is implicitly enabled on all links
that are part of the SR-enabled topology independent of that are part of the SR-enabled topology independent of
the existence of link attribute advertisements.</t> the existence of link attribute advertisements.</t>
<t indent="0" pn="section-11-7">In the case of LFA, the advertisement of a pplication-specific link <t>In the case of LFA, the advertisement of application-specific link
attributes does not indicate enablement of LFA on that link. attributes does not indicate enablement of LFA on that link.
Enablement is controlled by local configuration.</t> Enablement is controlled by local configuration.</t>
<t indent="0" pn="section-11-8">In the future, if additional standard appl ications 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> d efine use this mechanism, the specification defining this use <bcp14>MUST</bcp14> d efine
the relationship between application-specific link attribute the relationship between application-specific link attribute
advertisements and enablement for that application.</t> advertisements and enablement for that application.</t>
<t indent="0" pn="section-11-9">This document allows the advertisement of <t>This document allows the advertisement of application-specific link
application-specific link attributes with no application identifiers, i.e., both the SABM and the UDABM
attributes with no application identifiers, i.e., both the Standard are not present (see <xref target="ADVAPPVAL"/>).
Application Identifier Bit Mask and the User-Defined Application
Identifier Bit Mask are not present (see <xref target="ADVAPPVAL" format="def
ault" sectionFormat="of" derivedContent="Section 5"/>).
This supports the use of the link attribute by any application. In the prese nce of This supports the use of the link attribute by any application. In the prese nce of
an application where the advertisement of link attributes is used to infer th e enablement of an application on an 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 that link (e.g., RSVP-TE), the absence of the application identifier
leaves ambiguous whether that application is enabled on such a link. leaves ambiguous whether that application is enabled on such a link.
This needs to be considered when making use of the "any application" This needs to be considered when making use of the "any application"
encoding.</t> encoding.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-12"> <section>
<name slugifiedName="name-deployment-considerations">Deployment Considerat <name>Deployment Considerations</name>
ions</name> <section anchor="LEGACY_OSPF">
<section anchor="LEGACY_OSPF" numbered="true" toc="include" removeInRFC="f <name>Use of Legacy RSVP-TE LSA Advertisements</name>
alse" pn="section-12.1"> <t>Bit identifiers for standard applications are defined in <xref target
<name slugifiedName="name-use-of-legacy-rsvp-te-lsa-a">Use of Legacy RSV ="ADVAPPVAL"/>.
P-TE LSA Advertisements</name>
<t indent="0" pn="section-12.1-1">Bit identifiers for standard applicati
ons are defined in <xref target="ADVAPPVAL" format="default" sectionFormat="of"
derivedContent="Section 5"/>.
All of the identifiers defined in this document are associated with All of the identifiers defined in this document are associated with
applications that were already deployed in some networks prior to applications that were already deployed in some networks prior to
the writing of this document. Therefore, such applications have been the writing of this document. Therefore, such applications have been
deployed using the RSVP-TE LSA advertisements. The standard applications deployed using the RSVP-TE LSA advertisements. The standard applications
defined in this document may continue to use RSVP-TE LSA advertisements defined in this document may continue to use RSVP-TE LSA advertisements
for a given link so long as at least one of the following conditions for a given link so long as at least one of the following conditions
is true: is true:
</t> </t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1 <ul>
2.1-2"> <li>The application is RSVP-TE.</li>
<li pn="section-12.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-12.1-2.2">The application is SR Policy or LFA, and RSV
P-TE is not deployed
anywhere in the network.</li> anywhere in the network.</li>
<li pn="section-12.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 Policy advertisements are required and the attribute values used by SR Policy
and/or LFA on all such links are fully congruent with the links and and/or LFA on all such links are fully congruent with the links and
attribute values used by RSVP-TE.</li> attribute values used by RSVP-TE.</li>
</ul> </ul>
<t indent="0" pn="section-12.1-3">Under the conditions defined above, im plementations that support the <t>Under the conditions defined above, implementations that support the
extensions defined in this document have the choice of using RSVP-TE LSA extensions defined in this document have the choice of using RSVP-TE LSA
advertisements or application-specific advertisements in support of advertisements or application-specific advertisements in support of
SR Policy and/or LFA. This will require implementations to provide SR Policy and/or LFA. This will require implementations to provide
controls specifying which types of advertisements are to be sent and processe d on receipt for these applications. Further discussion of controls specifying which types of advertisements are to be sent and processe d on receipt for these applications. Further discussion of
the associated issues can be found in <xref target="IBCMC" format="default" s the associated issues can be found in <xref target="IBCMC"/>.</t>
ectionFormat="of" derivedContent="Section 12.3"/>.</t> <t>New applications that future documents define to make use of the
<t indent="0" pn="section-12.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 R SVP-TE LSA advertisements defined in this document <bcp14>MUST NOT</bcp14> make use of R SVP-TE LSA
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="ZLABM" numbered="true" toc="include" removeInRFC="false" <section anchor="ZLABM">
pn="section-12.2"> <name>Use of Zero-Length Application Identifier Bit Masks</name>
<name slugifiedName="name-use-zero-length-">Use of Zero-Length Applicati <t>Link attribute advertisements associated with zero-length Application
on Identifier Bit Masks</name>
<t indent="0" pn="section-12.2-1">Link attribute advertisements associat
ed with zero-length Application
Identifier Bit Masks for both standard applications and user-defined Identifier Bit Masks for both standard applications and user-defined
applications are usable by any application, subject to the applications are usable by any application, subject to the
restrictions specified in Section 4.2. If support for a new restrictions specified in <xref target="ADVAPPVAL"/>. If support for a new
application is introduced on any node in a network in the presence of application is introduced on any node in a network in the presence of
such advertisements, the new application will use these 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 MUST be readvertised with an explicit set of advertisements <bcp14>MUST</bcp14> be readvertised with an explicit set of
applications specified before a new application is introduced.</t> applications specified before a new application is introduced.</t>
</section> </section>
<section anchor="IBCMC" numbered="true" toc="include" removeInRFC="false" pn= <section anchor="IBCMC">
"section-12.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-12.3-1">Existing deployments of RSVP-TE, SR Po legacy advertisements listed in <xref target="LEG_ADV"/>. Routers that d
licy, and/or LFA utilize the o not
legacy advertisements listed in <xref target="LEG_ADV" format="default"
sectionFormat="of" derivedContent="Section 3"/>. Routers that do not
support the extensions defined in this document will only process support the extensions defined in this document will only process
legacy advertisements and are likely to infer that RSVP-TE is enabled legacy advertisements and are likely to infer that RSVP-TE is enabled
on the links for which legacy advertisements exist. It is expected on the links for which legacy advertisements exist. It is expected
that deployments using the legacy advertisements will persist for a that deployments using the legacy advertisements will persist for a
significant period of time. Therefore, deployments using the significant period of time. Therefore, deployments using the
extensions defined in this document in the presence of routers that extensions defined in this document in the presence of routers that
do not support these extensions need to be able to interoperate with do not support these extensions need to be able to interoperate with
the use of legacy advertisements by the legacy routers. The following su bsections the use of legacy advertisements by the legacy routers. The following su bsections
discuss interoperability and backwards-compatibility concerns for a numb er of discuss interoperability and backwards-compatibility concerns for a numb er of
deployment scenarios.</t> deployment scenarios.</t>
<section anchor="MACARSVP" numbered="true" toc="include" removeInRFC="fa <section anchor="MACARSVP">
lse" pn="section-12.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-12.3.1-1">In cases where multiple applicatio
ns 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 for RSVP-TE. link, interoperability is achieved by using legacy advertisements for RSVP-TE.
Attributes for applications other than RSVP-TE <bcp14>MUST</bcp14> be advertised using Attributes for applications other than RSVP-TE <bcp14>MUST</bcp14> be advertised using
application-specific advertisements. This results in duplicate application-specific advertisements. This results in duplicate
advertisements for those attributes.</t> advertisements for those attributes.</t>
</section> </section>
<section anchor="MAALLNS" numbered="true" toc="include" removeInRFC="fal <section anchor="MAALLNS">
se" pn="section-12.3.2"> <name>Multiple Applications: Some Attributes Not Shared with RSVP-TE</
<name slugifiedName="name-multiple-applications-some-">Multiple Applic name>
ations: Some 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-12.3.2-1">In cases where one or more applica
tions 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, interoperability is achieved by using legacy adve rtisements shared with RSVP-TE, interoperability is achieved by using legacy adve rtisements
for RSVP-TE. Attributes for applications other than RSVP-TE <bcp14>MUS T</bcp14> be advertised using for RSVP-TE. Attributes for applications other than RSVP-TE <bcp14>MUS T</bcp14> be advertised using
application-specific advertisements. In cases where some link attribut es are application-specific advertisements. In cases where some link attribut es are
shared with RSVP-TE, this requires duplicate advertisements for those attributes.</t> shared with RSVP-TE, this requires duplicate advertisements for those attributes.</t>
</section> </section>
<section anchor="LEGACY" numbered="true" toc="include" removeInRFC="fals <section anchor="LEGACY">
e" pn="section-12.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-12.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 type="%d)">
n-12.3.3-2"> <li derivedCounter="1)">Send new application-specific advertisements w
<li pn="section-12.3.3-2.1" derivedCounter="1)">Send new application-s hile continuing to
pecific advertisements while continuing to
advertise using the legacy advertisement (all advertisements are advertise using the legacy advertisement (all advertisements are
then duplicated). Receiving routers continue to use legacy advertiseme nts.</li> then duplicated). Receiving routers continue to use legacy advertiseme nts.</li>
<li pn="section-12.3.3-2.2" derivedCounter="2)">Enable the use of th e application-specific advertisements on <li derivedCounter="2)">Enable the use of the application-specific a dvertisements on
all routers.</li> all routers.</li>
<li pn="section-12.3.3-2.3" derivedCounter="3)">Keep legacy advertis ements if needed for RSVP-TE purposes.</li> <li derivedCounter="3)">Keep legacy advertisements if needed for RSV P-TE purposes.</li>
</ol> </ol>
<t indent="0" pn="section-12.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-12.3.3-4">Documents defining new application s 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-12.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 support RSVP-TE as one of
ion-Specific Advertisements for RSVP-TE</name>
<t indent="0" pn="section-12.3.4-1">The extensions defined in this doc
ument support RSVP-TE as one of
the supported applications. It is, however, <bcp14>RECOMMENDED</bcp14> to advertise all the supported applications. It is, however, <bcp14>RECOMMENDED</bcp14> to advertise all
link attributes for RSVP-TE in the existing OSPFv2 TE Opaque LSA link attributes for RSVP-TE in the existing OSPFv2 TE Opaque LSA
<xref target="RFC3630" format="default" sectionFormat="of" derivedCont ent="RFC3630"/> and OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329" format="defa ult" sectionFormat="of" derivedContent="RFC5329"/> <xref target="RFC3630"/> and OSPFv3 Intra-Area-TE-LSA <xref target="RF C5329"/>
to maintain backwards compatibility. RSVP-TE can eventually to maintain backwards compatibility. RSVP-TE can eventually
utilize the application-specific advertisements for newly defined utilize the application-specific advertisements for newly defined
link attributes that are defined as application specific.</t> link attributes that are defined as application specific.</t>
<t indent="0" pn="section-12.3.4-2">Link attributes that are not allow ed to be advertised in the ASLA sub-TLV, <t>Link attributes that are not allowed to be advertised in the ASLA s ub-TLV,
such as maximum reservable link bandwidth and unreserved bandwidth, <b cp14>MUST</bcp14> use the such as maximum reservable link bandwidth and unreserved bandwidth, <b cp14>MUST</bcp14> use the
OSPFv2 TE Opaque LSA <xref target="RFC3630" format="default" sectionFo OSPFv2 TE Opaque LSA <xref target="RFC3630"/> and OSPFv3 Intra-Area-TE
rmat="of" derivedContent="RFC3630"/> and OSPFv3 Intra-Area-TE-LSA -LSA
<xref target="RFC5329" format="default" sectionFormat="of" derivedCont <xref target="RFC5329"/> and <bcp14>MUST NOT</bcp14> be advertised in
ent="RFC5329"/> and <bcp14>MUST NOT</bcp14> be advertised in the ASLA sub-TLV.</ the ASLA sub-TLV.</t>
t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-13"> <section>
<name slugifiedName="name-security-considerations">Security Considerations <name>Security Considerations</name>
</name> <t>Existing security extensions as described in <xref target="RFC2328"/>,
<t indent="0" pn="section-13-1">Existing security extensions as described <xref target="RFC5340"/>, and <xref target="RFC8362"/> apply to extension
in <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RF s
C2328"/>,
<xref target="RFC5340" format="default" sectionFormat="of" derivedContent
="RFC5340"/>, and <xref target="RFC8362" format="default" sectionFormat="of" der
ivedContent="RFC8362"/> apply to extensions
defined in this document. While OSPF is under a single administrative dom ain, defined in this document. While OSPF is under a single administrative dom ain,
there can be deployments where potential attackers have access to one or more there can be deployments where potential attackers have access to one or more
networks in the OSPF routing domain. In these deployments, stronger authe ntication networks in the OSPF routing domain. In these deployments, stronger authe ntication
mechanisms such as those specified in <xref target="RFC5709" format="defa mechanisms such as those specified in <xref target="RFC5709"/>,
ult" sectionFormat="of" derivedContent="RFC5709"/>, <xref target="RFC7474"/>, <xref target="RFC4552"/>, or
<xref target="RFC7474" format="default" sectionFormat="of" derivedContent <xref target="RFC7166"/> <bcp14>SHOULD</bcp14> be
="RFC7474"/>, <xref target="RFC4552" format="default" sectionFormat="of" derived
Content="RFC4552"/>, or
<xref target="RFC7166" format="default" sectionFormat="of" derivedContent
="RFC7166"/> <bcp14>SHOULD</bcp14> be
used.</t> used.</t>
<t indent="0" pn="section-13-2">Implementations must ensure that if any of the TLVs and sub-TLVs <t>Implementations must ensure that if any of the TLVs and sub-TLVs
defined in this document are malformed, they are detected and do not defined in this document are malformed, they are detected and do not
facilitate a vulnerability for attackers to crash or otherwise compromise facilitate a vulnerability for attackers to crash or otherwise compromise
the OSPF router or routing process. Reception of a the OSPF router or routing process. Reception of a
malformed TLV or sub-TLV <bcp14>SHOULD</bcp14> be counted and/or logged malformed TLV or sub-TLV <bcp14>SHOULD</bcp14> be counted and/or logged
for further analysis. Logging of malformed TLVs and sub-TLVs for further analysis. Logging of malformed TLVs and sub-TLVs
<bcp14>SHOULD</bcp14> be rate-limited to prevent a denial-of-service <bcp14>SHOULD</bcp14> be rate-limited to prevent a denial-of-service
(DoS) attack (distributed or otherwise) from overloading the OSPF (DoS) attack (distributed or otherwise) from overloading the OSPF
control plane.</t> control plane.</t>
<t indent="0" pn="section-13-3">This document defines a new way to adverti se 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 effect on applications using it, including impacting TE, which uses variou
engineering, which uses various link attributes for its path s link attributes for its path
computation. This is similar in nature to the impacts associated with, computation. This is similar in nature to the impacts associated with,
for example, <xref target="RFC3630" format="default" sectionFormat="of" de rivedContent="RFC3630"/>. As the for example, <xref target="RFC3630"/>. As the
advertisements defined in this document limit the scope to specific advertisements defined in this document limit the scope to specific
applications, the impact of tampering is similarly limited in scope.</t> applications, the impact of tampering is similarly limited in scope.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn= <section anchor="IANA">
"section-14"> <name>IANA Considerations</name>
<name slugifiedName="name-iana-considerations">IANA Considerations</name> <t>This specification updates two existing registries:
<t indent="0" pn="section-14-1">This specification updates two existing re
gistries:
</t> </t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-14- <ul>
2"> <li>the "OSPFv2 Extended Link TLV Sub-TLVs" registry</li>
<li pn="section-14-2.1">the "OSPFv2 Extended Link TLV Sub-TLVs" registry <li>the "OSPFv3 Extended-LSA Sub-TLVs" registry</li>
</li>
<li pn="section-14-2.2">the "OSPFv3 Extended-LSA Sub-TLVs" registry</li>
</ul> </ul>
<t indent="0" pn="section-14-3">The new values defined in this document ha ve been allocated using the <t>The values defined in this document have been allocated using the
IETF Review procedure as described in IETF Review procedure as described in
<xref target="RFC8126" format="default" sectionFormat="of" derivedContent= <xref target="RFC8126"/>.</t>
"RFC8126"/>.</t> <section anchor="OSPFV2IANA">
<section anchor="OSPFV2IANA" numbered="true" toc="include" removeInRFC="fa <name>OSPFv2</name>
lse" pn="section-14.1"> <t>The "OSPFv2 Extended Link TLV Sub-TLVs" registry <xref target="RFC768
<name slugifiedName="name-ospfv2">OSPFv2</name> 4"/> defines sub-TLVs at any level of
<t indent="0" pn="section-14.1-1">The "OSPFv2 Extended Link TLV Sub-TLVs
" registry <xref target="RFC7684" format="default" sectionFormat="of" derivedCon
tent="RFC7684"/> defines sub-TLVs at any level of
nesting for OSPFv2 Extended Link TLVs. IANA has assigned the following nesting for OSPFv2 Extended Link TLVs. IANA has assigned the following
sub-TLV types from the "OSPFv2 Extended Link TLV Sub-TLVs" registry: sub-TLV types in the "OSPFv2 Extended Link TLV Sub-TLVs" registry:
</t> </t>
<dl indent="3" newline="false" spacing="normal" pn="section-14.1-2"> <dl>
<dt pn="section-14.1-2.1">10:</dt> <dt>10:</dt>
<dd pn="section-14.1-2.2"> Application-Specific Link Attributes</dd> <dd>Application-Specific Link Attributes</dd>
<dt pn="section-14.1-2.3">11:</dt> <dt>11:</dt>
<dd pn="section-14.1-2.4"> Shared Risk Link Group</dd> <dd>Shared Risk Link Group</dd>
<dt pn="section-14.1-2.5">12:</dt> <dt>12:</dt>
<dd pn="section-14.1-2.6"> Unidirectional Link Delay</dd> <dd>Unidirectional Link Delay</dd>
<dt pn="section-14.1-2.7">13:</dt> <dt>13:</dt>
<dd pn="section-14.1-2.8"> Min/Max Unidirectional Link Delay</dd> <dd>Min/Max Unidirectional Link Delay</dd>
<dt pn="section-14.1-2.9">14:</dt> <dt>14:</dt>
<dd pn="section-14.1-2.10"> Unidirectional Delay Variation</dd> <dd>Unidirectional Delay Variation</dd>
<dt pn="section-14.1-2.11">15:</dt> <dt>15:</dt>
<dd pn="section-14.1-2.12"> Unidirectional Link Loss</dd> <dd>Unidirectional Link Loss</dd>
<dt pn="section-14.1-2.13">16:</dt> <dt>16:</dt>
<dd pn="section-14.1-2.14"> Unidirectional Residual Bandwidth</dd> <dd>Unidirectional Residual Bandwidth</dd>
<dt pn="section-14.1-2.15">17:</dt> <dt>17:</dt>
<dd pn="section-14.1-2.16"> Unidirectional Available Bandwidth</dd> <dd>Unidirectional Available Bandwidth</dd>
<dt pn="section-14.1-2.17">18:</dt> <dt>18:</dt>
<dd pn="section-14.1-2.18"> Unidirectional Utilized Bandwidth</dd> <dd>Unidirectional Utilized Bandwidth</dd>
<dt pn="section-14.1-2.19">19:</dt> <dt>19:</dt>
<dd pn="section-14.1-2.20"> Administrative Group</dd> <dd>Administrative Group</dd>
<dt pn="section-14.1-2.21">20:</dt> <dt>20:</dt>
<dd pn="section-14.1-2.22"> Extended Administrative Group</dd> <dd>Extended Administrative Group</dd>
<dt pn="section-14.1-2.23">22:</dt> <dt>22:</dt>
<dd pn="section-14.1-2.24"> TE Metric</dd> <dd>TE Metric</dd>
<dt pn="section-14.1-2.25">23:</dt> <dt>23:</dt>
<dd pn="section-14.1-2.26"> Maximum link bandwidth</dd> <dd>Maximum link bandwidth</dd>
</dl> </dl>
</section> </section>
<section anchor="OSPFV3IANA" numbered="true" toc="include" removeInRFC="fa <section anchor="OSPFV3IANA">
lse" pn="section-14.2"> <name>OSPFv3</name>
<name slugifiedName="name-ospfv3">OSPFv3</name> <t>The "OSPFv3 Extended-LSA Sub-TLVs" registry <xref target="RFC8362"/>
<t indent="0" pn="section-14.2-1">The "OSPFv3 Extended-LSA Sub-TLVs" reg defines
istry <xref target="RFC8362" format="default" sectionFormat="of" derivedContent= sub-TLVs at any level of nesting for OSPFv3
"RFC8362"/> defines sub-TLVs at any level of nesting for OSPFv3 Extended LSAs. IANA has assigned the following sub-TLV types in the
Extended LSAs. IANA has assigned the following sub-TLV types from the
"OSPFv3 Extended-LSA Sub-TLVs" registry: "OSPFv3 Extended-LSA Sub-TLVs" registry:
</t> </t>
<dl indent="3" newline="false" spacing="normal" pn="section-14.2-2"> <dl>
<dt pn="section-14.2-2.1">11:</dt> <dt>11:</dt>
<dd pn="section-14.2-2.2"> Application-Specific Link Attributes</dd> <dd>Application-Specific Link Attributes</dd>
<dt pn="section-14.2-2.3">12:</dt> <dt>12:</dt>
<dd pn="section-14.2-2.4"> Shared Risk Link Group</dd> <dd>Shared Risk Link Group</dd>
<dt pn="section-14.2-2.5">13:</dt> <dt>13:</dt>
<dd pn="section-14.2-2.6"> Unidirectional Link Delay</dd> <dd>Unidirectional Link Delay</dd>
<dt pn="section-14.2-2.7">14:</dt> <dt>14:</dt>
<dd pn="section-14.2-2.8"> Min/Max Unidirectional Link Delay</dd> <dd>Min/Max Unidirectional Link Delay</dd>
<dt pn="section-14.2-2.9">15:</dt> <dt>15:</dt>
<dd pn="section-14.2-2.10"> Unidirectional Delay Variation</dd> <dd>Unidirectional Delay Variation</dd>
<dt pn="section-14.2-2.11">16:</dt> <dt>16:</dt>
<dd pn="section-14.2-2.12"> Unidirectional Link Loss</dd> <dd>Unidirectional Link Loss</dd>
<dt pn="section-14.2-2.13">17:</dt> <dt>17:</dt>
<dd pn="section-14.2-2.14"> Unidirectional Residual Bandwidth</dd> <dd>Unidirectional Residual Bandwidth</dd>
<dt pn="section-14.2-2.15">18:</dt> <dt>18:</dt>
<dd pn="section-14.2-2.16"> Unidirectional Available Bandwidth</dd> <dd>Unidirectional Available Bandwidth</dd>
<dt pn="section-14.2-2.17">19:</dt> <dt>19:</dt>
<dd pn="section-14.2-2.18"> Unidirectional Utilized Bandwidth</dd> <dd>Unidirectional Utilized Bandwidth</dd>
<dt pn="section-14.2-2.19">20:</dt> <dt>20:</dt>
<dd pn="section-14.2-2.20"> Administrative Group</dd> <dd>Administrative Group</dd>
<dt pn="section-14.2-2.21">21:</dt> <dt>21:</dt>
<dd pn="section-14.2-2.22"> Extended Administrative Group</dd> <dd>Extended Administrative Group</dd>
<dt pn="section-14.2-2.23">22:</dt> <dt>22:</dt>
<dd pn="section-14.2-2.24"> TE Metric</dd> <dd>TE Metric</dd>
<dt pn="section-14.2-2.25">23:</dt> <dt>23:</dt>
<dd pn="section-14.2-2.26"> Maximum link bandwidth</dd> <dd>Maximum link bandwidth</dd>
<dt pn="section-14.2-2.27">24:</dt> <dt>24:</dt>
<dd pn="section-14.2-2.28"> Local Interface IPv6 Address</dd> <dd>Local Interface IPv6 Address</dd>
<dt pn="section-14.2-2.29">25:</dt> <dt>25:</dt>
<dd pn="section-14.2-2.30"> Remote Interface IPv6 Address</dd> <dd>Remote Interface IPv6 Address</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="changes-to-rfc8920" numbered="true" toc="include" removeInR <section anchor="changes-to-rfc8920">
FC="false" pn="section-15"> <name>Changes to RFC 8920</name>
<name slugifiedName="name-changes-to-rfc8920">Changes to RFC 8920</name> <t>Discussion within the LSR WG indicated that there was confusion regardi
<t indent="0" pn="section-15-1">Discussion within the LSR WG indicated tha ng
t 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 The discussion can be seen by searching the LSR WG mailing
list archives for the thread "Proposed Errata for RFCs 8919/8920" list archives for the thread "Proposed Errata for RFCs 8919/8920"
starting on 15 June 2021. </t> starting on 15 June 2021. </t>
<t indent="0" pn="section-15-2">Changes to Section 5 have been introduced <t>Changes to <xref target="ADVAPPVAL"/> have been introduced to clarify n
to clarify normative ormative
behavior in the presence of such advertisements. RFC 8920 defines advertis behavior in the presence of such advertisements. <xref target="RFC8920"/>
ing link attributes with zero defines advertising link attributes with zero-length
length Standard Application Bit Mask (SABM) and zero length User SABM and zero-length UDABM as a means of advertising link
Defined ApplicationBit Mask (UDABM) as a means of advertising link
attributes that can be used by any application. However, the text uses attributes that can be used by any application. However, the text uses
the word "permitted", suggesting that the use of such advertisements the word "permitted", suggesting that the use of such advertisements
is "optional". Such an interpretation could lead to interoperability is "optional". Such an interpretation 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-15-3">The replacement text makes explicit the sp ecific 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>
<t indent="0" pn="section-15-4">A new subsection discussing the use of zer o-length Application Identifier Bit Masks has been added for greater consistency with <xref target="RFC8919" format="default" sectionFormat="of" derivedContent= "RFC8919"/>. See <xref target="ZLABM" format="default" sectionFormat="of" derive dContent="Section 12.2"/>.</t> <t>A subsection discussing the use of zero-length Application Identifier B it Masks has been added for greater consistency with <xref target="RFC9479"/>. S ee <xref target="ZLABM"/>.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9256" to="SEGMENT-ROUTING"/> <references>
<references pn="section-16"> <name>References</name>
<name slugifiedName="name-references">References</name> <references>
<references pn="section-16.1"> <name>Normative References</name>
<name slugifiedName="name-normative-references">Normative References</na <reference anchor="RFC9479" target="https://www.rfc-editor.org/info/rfc9479">
me> <front>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 <title>IS-IS Application-Specific Link Attributes</title>
119" quoteTitle="true" derivedAnchor="RFC2119"> <author initials="L." surname="Ginsberg" fullname="Les Ginsberg">
<front> </author>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <author initials="P." surname="Psenak" fullname="Peter Psenak">
le> </author>
<author initials="S." surname="Bradner" fullname="S. Bradner"> <author initials="S." surname="Previdi" fullname="Stefano Previdi">
<organization showOnFrontPage="true"/> </author>
</author> <author initials="W." surname="Henderickx" fullname="Wim Henderickx">
<date year="1997" month="March"/> </author>
<abstract> <author initials="J." surname="Drake" fullname="John Drake">
<t indent="0">In many standards track documents several words are </author>
used to signify the requirements in the specification. These words are often ca <date month="October" year="2023"/>
pitalized. This document defines these words as they should be interpreted in IE </front>
TF documents. This document specifies an Internet Best Current Practices for th <seriesInfo name="RFC" value="9479"/>
e Internet Community, and requests discussion and suggestions for improvements.< <seriesInfo name="DOI" value="10.17487/RFC9479"/>
/t> </reference>
</abstract>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
<seriesInfo name="BCP" value="14"/> />
<seriesInfo name="RFC" value="2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"
<seriesInfo name="DOI" value="10.17487/RFC2119"/> />
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"
<reference anchor="RFC2328" target="https://www.rfc-editor.org/info/rfc2 />
328" quoteTitle="true" derivedAnchor="RFC2328"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4203.xml"
<front> />
<title>OSPF Version 2</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"
<author initials="J." surname="Moy" fullname="J. Moy"> />
<organization showOnFrontPage="true"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"
</author> />
<date year="1998" month="April"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7308.xml"
<abstract> />
<t indent="0">This memo documents version 2 of the OSPF protocol. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml"
OSPF is a link- state routing protocol. [STANDARDS-TRACK]</t> />
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7684.xml"
</front> />
<seriesInfo name="STD" value="54"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
<seriesInfo name="RFC" value="2328"/> />
<seriesInfo name="DOI" value="10.17487/RFC2328"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"
</reference> />
<reference anchor="RFC3630" target="https://www.rfc-editor.org/info/rfc3
630" quoteTitle="true" derivedAnchor="RFC3630">
<front>
<title>Traffic Engineering (TE) Extensions to OSPF Version 2</title>
<author initials="D." surname="Katz" fullname="D. Katz">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Kompella" fullname="K. Kompella">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Yeung" fullname="D. Yeung">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="September"/>
<abstract>
<t indent="0">This document describes extensions to the OSPF proto
col version 2 to support intra-area Traffic Engineering (TE), using Opaque Link
State Advertisements.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3630"/>
<seriesInfo name="DOI" value="10.17487/RFC3630"/>
</reference>
<reference anchor="RFC4203" target="https://www.rfc-editor.org/info/rfc4
203" quoteTitle="true" derivedAnchor="RFC4203">
<front>
<title>OSPF Extensions in Support of Generalized Multi-Protocol Labe
l 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="2005" month="October"/>
<abstract>
<t indent="0">This document specifies encoding of extensions to th
e OSPF routing protocol in support of Generalized Multi-Protocol Label Switching
(GMPLS). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4203"/>
<seriesInfo name="DOI" value="10.17487/RFC4203"/>
</reference>
<reference anchor="RFC5329" target="https://www.rfc-editor.org/info/rfc5
329" quoteTitle="true" derivedAnchor="RFC5329">
<front>
<title>Traffic Engineering Extensions to OSPF Version 3</title>
<author initials="K." surname="Ishiguro" fullname="K. Ishiguro">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Manral" fullname="V. Manral">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Davey" fullname="A. Davey">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lindem" fullname="A. Lindem" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="September"/>
<abstract>
<t indent="0">This document describes extensions to OSPFv3 to supp
ort intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to han
dle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IP
v6 networks. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5329"/>
<seriesInfo name="DOI" value="10.17487/RFC5329"/>
</reference>
<reference anchor="RFC5340" target="https://www.rfc-editor.org/info/rfc5
340" quoteTitle="true" derivedAnchor="RFC5340">
<front>
<title>OSPF for IPv6</title>
<author initials="R." surname="Coltun" fullname="R. Coltun">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Ferguson" fullname="D. Ferguson">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Moy" fullname="J. Moy">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lindem" fullname="A. Lindem">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="July"/>
<abstract>
<t indent="0">This document describes the modifications to OSPF to
support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms
of OSPF (flooding, Designated Router (DR) election, area support, Short Path Fir
st (SPF) calculations, etc.) remain unchanged. However, some changes have been
necessary, either due to changes in protocol semantics between IPv4 and IPv6, or
simply to handle the increased address size of IPv6. These modifications will
necessitate incrementing the protocol version from version 2 to version 3. OSPF
for IPv6 is also referred to as OSPF version 3 (OSPFv3).</t>
<t indent="0">Changes between OSPF for IPv4, OSPF Version 2, and O
SPF for IPv6 as described herein include the following. Addressing semantics ha
ve been removed from OSPF packets and the basic Link State Advertisements (LSAs)
. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now ru
ns on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for
LSAs has been generalized. Authentication has been removed from the OSPF proto
col and instead relies on IPv6's Authentication Header and Encapsulating Securit
y Payload (ESP).</t>
<t indent="0">Even with larger IPv6 addresses, most packets in OSP
F for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and pac
ket- size limitations present in OSPF for IPv4 have been relaxed. In addition,
option handling has been made more flexible.</t>
<t indent="0">All of OSPF for IPv4's optional capabilities, includ
ing demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported i
n OSPF for IPv6. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5340"/>
<seriesInfo name="DOI" value="10.17487/RFC5340"/>
</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="RFC7471" target="https://www.rfc-editor.org/info/rfc7
471" quoteTitle="true" derivedAnchor="RFC7471">
<front>
<title>OSPF Traffic Engineering (TE) Metric Extensions</title>
<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="A." surname="Atlas" fullname="A. Atlas">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="March"/>
<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 information (e.g., link propagation delay) is becoming critical to data pa
th selection.</t>
<t indent="0">This document describes common extensions to RFC 363
0 "Traffic Engineering (TE) Extensions
to OSPF Version 2" and RFC 5329 "Traffic En
gineering Extensions to OSPF Version 3" to enable network performance informatio
n to be distributed in a scalable fashion. The information distributed using OS
PF TE Metric Extensions can then be used to make path selection decisions based
on network performance.</t>
<t indent="0">Note that this document only covers the mechanisms b
y which network performance information is distributed. The mechanisms for meas
uring network performance information or using that information, once distribute
d, are outside the scope of this document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7471"/>
<seriesInfo name="DOI" value="10.17487/RFC7471"/>
</reference>
<reference anchor="RFC7684" target="https://www.rfc-editor.org/info/rfc7
684" quoteTitle="true" derivedAnchor="RFC7684">
<front>
<title>OSPFv2 Prefix/Link Attribute Advertisement</title>
<author initials="P." surname="Psenak" fullname="P. Psenak">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Gredler" fullname="H. Gredler">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<author initials="W." surname="Henderickx" fullname="W. Henderickx">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Tantsura" fullname="J. Tantsura">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lindem" fullname="A. Lindem">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="November"/>
<abstract>
<t indent="0">OSPFv2 requires functional extension beyond what can
readily be done with the fixed-format Link State Advertisements (LSAs) as descr
ibed in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length
-Value (TLV) tuples that can be used to associate additional attributes with pre
fixes or links. Depending on the application, these prefixes and links may or m
ay not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optio
nal and fully backward compatible.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7684"/>
<seriesInfo name="DOI" value="10.17487/RFC7684"/>
</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="RFC8362" target="https://www.rfc-editor.org/info/rfc8
362" quoteTitle="true" derivedAnchor="RFC8362">
<front>
<title>OSPFv3 Link State Advertisement (LSA) Extensibility</title>
<author initials="A." surname="Lindem" fullname="A. Lindem">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Roy" fullname="A. Roy">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Goethals" fullname="D. Goethals">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Reddy Vallem" fullname="V. Reddy Vall
em">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Baker" fullname="F. Baker">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="April"/>
<abstract>
<t indent="0">OSPFv3 requires functional extension beyond what can
readily be done with the fixed-format Link State Advertisement (LSA) as describ
ed in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links
and advertised IPv6 prefixes must be advertised in separate LSAs and correlated
to the fixed-format LSAs. This document extends the LSA format by encoding the
existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing a
dvertisement of additional information with additional TLVs. Backward-compatibi
lity mechanisms are also described.</t>
<t indent="0">This document updates RFC 5340, "OSPF for IPv6", and
RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encod
ings for the base OSPFv3 unicast support and OSPFv3 address family support.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8362"/>
<seriesInfo name="DOI" value="10.17487/RFC8362"/>
</reference>
<reference anchor="RFC8919" target="https://www.rfc-editor.org/info/rfc8
919" quoteTitle="true" derivedAnchor="RFC8919">
<front>
<title>IS-IS Application-Specific Link Attributes</title>
<author initials="L" surname="Ginsberg" fullname="Les Ginsberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="P" surname="Psenak" fullname="Peter Psenak">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization showOnFrontPage="true"/>
</author>
<author initials="W" surname="Henderickx" fullname="Wim Henderickx">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Drake" fullname="John Drake">
<organization showOnFrontPage="true"/>
</author>
<date month="October" year="2020"/>
</front>
<seriesInfo name="RFC" value="8919"/>
<seriesInfo name="DOI" value="10.17487/RFC8919"/>
</reference>
</references> </references>
<references pn="section-16.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.4552.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.5286.xml"
<organization showOnFrontPage="true"/> />
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5709.xml"
<author initials="L." surname="Berger" fullname="L. Berger"> />
<organization showOnFrontPage="true"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5714.xml"
</author> />
<author initials="D." surname="Gan" fullname="D. Gan"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7166.xml"
<organization showOnFrontPage="true"/> />
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7474.xml"
<author initials="T." surname="Li" fullname="T. Li"> />
<organization showOnFrontPage="true"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml"
</author> />
<author initials="V." surname="Srinivasan" fullname="V. Srinivasan"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
<organization showOnFrontPage="true"/> />
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8920.xml"
<author initials="G." surname="Swallow" fullname="G. Swallow"> />
<organization showOnFrontPage="true"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"
</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="RFC4552" target="https://www.rfc-editor.org/info/rfc4
552" quoteTitle="true" derivedAnchor="RFC4552">
<front>
<title>Authentication/Confidentiality for OSPFv3</title>
<author initials="M." surname="Gupta" fullname="M. Gupta">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Melam" fullname="N. Melam">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="June"/>
<abstract>
<t indent="0">This document describes means and mechanisms to prov
ide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header
/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="4552"/>
<seriesInfo name="DOI" value="10.17487/RFC4552"/>
</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="RFC5709" target="https://www.rfc-editor.org/info/rfc5
709" quoteTitle="true" derivedAnchor="RFC5709">
<front>
<title>OSPFv2 HMAC-SHA 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="M." surname="Fanto" fullname="M. Fanto">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="White" fullname="R. White">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Barnes" fullname="M. Barnes">
<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>
<date year="2009" month="October"/>
<abstract>
<t indent="0">This document describes how the National Institute o
f Standards and Technology (NIST) Secure Hash Standard family of algorithms can
be used with OSPF version 2's built-in, cryptographic authentication mechanism.
This updates, but does not supercede, the cryptographic authentication mechanis
m specified in RFC 2328. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5709"/>
<seriesInfo name="DOI" value="10.17487/RFC5709"/>
</reference>
<reference anchor="RFC5714" target="https://www.rfc-editor.org/info/rfc5
714" quoteTitle="true" derivedAnchor="RFC5714">
<front>
<title>IP Fast Reroute Framework</title>
<author initials="M." surname="Shand" fullname="M. Shand">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Bryant" fullname="S. Bryant">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="January"/>
<abstract>
<t indent="0">This document provides a framework for the developme
nt of IP fast- reroute mechanisms that provide protection against link or router
failure by invoking locally determined repair paths. Unlike MPLS fast-reroute,
the mechanisms are applicable to a network employing conventional IP routing an
d forwarding. This document is not an Internet Standards Track specification;
it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5714"/>
<seriesInfo name="DOI" value="10.17487/RFC5714"/>
</reference>
<reference anchor="RFC7166" target="https://www.rfc-editor.org/info/rfc7
166" quoteTitle="true" derivedAnchor="RFC7166">
<front>
<title>Supporting Authentication Trailer for OSPFv3</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="A." surname="Lindem" fullname="A. Lindem">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="March"/>
<abstract>
<t indent="0">Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the
only mechanism for authenticating protocol packets. This behavior is different
from authentication mechanisms present in other routing protocols (OSPFv2, Inter
mediate System to Intermediate System (IS-IS), RIP, and Routing Information Prot
ocol Next Generation (RIPng)). In some environments, it has been found that IPs
ec is difficult to configure and maintain and thus cannot be used. This documen
t defines an alternative mechanism to authenticate OSPFv3 protocol packets so th
at OSPFv3 does not depend only upon IPsec for authentication.</t>
<t indent="0">The OSPFv3 Authentication Trailer was originally def
ined in RFC 6506. This document obsoletes RFC 6506 by providing a revised defini
tion, including clarifications and refinements of the procedures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7166"/>
<seriesInfo name="DOI" value="10.17487/RFC7166"/>
</reference>
<reference anchor="RFC7474" target="https://www.rfc-editor.org/info/rfc7
474" quoteTitle="true" derivedAnchor="RFC7474">
<front>
<title>Security Extension for OSPFv2 When Using Manual Key Managemen
t</title>
<author initials="M." surname="Bhatia" fullname="M. Bhatia">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Hartman" fullname="S. Hartman">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Zhang" fullname="D. Zhang">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lindem" fullname="A. Lindem" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="April"/>
<abstract>
<t indent="0">The current OSPFv2 cryptographic authentication mech
anism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and i
ntra- session replay attacks when using manual keying. Additionally, the existi
ng cryptographic authentication mechanism does not cover the IP header. This om
ission can be exploited to carry out various types of attacks.</t>
<t indent="0">This document defines changes to the authentication
sequence number mechanism that will protect OSPFv2 from both inter-session and i
ntra- session replay attacks when using manual keys for securing OSPFv2 protocol
packets. Additionally, we also describe some changes in the cryptographic hash
computation that will eliminate attacks resulting from OSPFv2 not protecting th
e IP header.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7474"/>
<seriesInfo name="DOI" value="10.17487/RFC7474"/>
</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="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="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>
<date month="July" day="24" year="2022"/>
<abstract>
<t indent="0"> Segment Routing (SR) allows a headend node to ste
er a packet flow
along any path. Intermediate per-flow states are eliminated thanks
to source routing. The headend node steers a flow into an SR Policy.
The header of a packet steered in an SR Policy is augmented with an
ordered list of segments associated with that SR Policy. This
document details the concepts of SR Policy and steering into an SR
Policy.
</t>
</abstract>
</front>
<seriesInfo name="STD" value="54"/>
<seriesInfo name="RFC" value="9256"/>
<seriesInfo name="DOI" value="10.17487/RFC9256"/>
</reference>
</references> </references>
</references> </references>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe <section numbered="false">
ndix.a"> <name>Acknowledgments</name>
<name slugifiedName="name-acknowledgments">Acknowledgments</name> <t>The following acknowledgments are included in <xref target="RFC8920"/>:
<t indent="0" pn="section-appendix.a-1"> RFC 8920 included the following a </t>
cknowledgments:</t> <t>Thanks to <contact fullname="Chris Bowers"/> for his review and comment
<t indent="0" pn="section-appendix.a-2">Thanks to <contact fullname="Chris s.</t>
Bowers"/> for his review and comments.</t> <t>Thanks to <contact fullname="Alvaro Retana"/> for his detailed review a
<t indent="0" pn="section-appendix.a-3">Thanks to <contact fullname="Alvar nd comments.</t>
o Retana"/> for his detailed review and comments.</t> <t>For this document, the authors would like to thank
<t indent="0" pn="section-appendix.a-4"> For the new version, the authors
would like to thank
<contact fullname="Bruno Decraene"/>.</t> <contact fullname="Bruno Decraene"/>.</t>
</section> </section>
<section anchor="CONTR" numbered="false" toc="include" removeInRFC="false" p <section anchor="CONTR" numbered="false">
n="section-appendix.b"> <name>Contributors</name>
<name slugifiedName="name-contributors">Contributors</name> <t>The following people contributed to the content
<t indent="0" pn="section-appendix.b-1">The following people contributed t
o the content
of this document and should be considered as coauthors:</t> of this document and should be considered as coauthors:</t>
<contact fullname="Acee Lindem"> <contact fullname="Acee Lindem">
<organization showOnFrontPage="true">Cisco Systems</organization> <organization>LabN Consulting, L.L.C.</organization>
<address> <address>
<postal> <postal>
<street/> <country>United States of America</country>
<city/>
<region/>
<code/>
<country>United States of America</country>
</postal> </postal>
<email>acee@cisco.com</email> <email>acee.ietf@gmail.com</email>
</address> </address>
</contact> </contact>
<contact fullname="Ketan Talaulikar"> <contact fullname="Ketan Talaulikar">
<organization showOnFrontPage="true">Arrcus, Inc.</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</contact> </contact>
<contact fullname="Hannes Gredler"> <contact fullname="Hannes Gredler">
<organization showOnFrontPage="true">RtBrick Inc.</organization> <organization>RtBrick Inc.</organization>
<address> <address>
<postal>
<country/>
</postal>
<email>hannes@rtbrick.com</email> <email>hannes@rtbrick.com</email>
</address> </address>
</contact> </contact>
</section> </section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.c">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Peter Psenak" initials="P." role="editor" surname="Psena
k">
<organization showOnFrontPage="true">Cisco Systems</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>Slovakia</country>
</postal>
<email>ppsenak@cisco.com</email>
</address>
</author>
<author initials="L." surname="Ginsberg" fullname="Les 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 initials="W." surname="Henderickx" fullname="Wim Henderickx">
<organization showOnFrontPage="true">Nokia</organization>
<address>
<postal>
<street>Copernicuslaan 50</street>
<city>Antwerp</city>
<country>Belgium</country>
<code>2018 94089</code>
</postal>
<email>wim.henderickx@nokia.com</email>
</address>
</author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization showOnFrontPage="true">Nvidia</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>United States of America</country>
</postal>
<email>jefftant.ietf@gmail.com</email>
</address>
</author>
<author fullname="John Drake" initials="J." surname="Drake">
<organization showOnFrontPage="true">Juniper Networks</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>United States of America</country>
</postal>
<email>jdrake@juniper.net</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 148 change blocks. 
1744 lines changed or deleted 598 lines changed or added

This html diff was produced by rfcdiff 1.48.