Diff: rfc8920xml2.original.xml

	rfc8920xml2.original.xml	rfc8920.xml
	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>

	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc toc="yes" ?>
	<?rfc symrefs="yes" ?>
	<?rfc sortrefs="yes"?>
	<?rfc iprnotified="no" ?>
	<?rfc strict="yes" ?>
	<?rfc compact='yes'?>
	<?rfc subcompact='no'?>
	<rfc category="std" ipr="trust200902" docName="draft-ietf-ospf-te-link-attr-reus
	e-16.txt">

	<front>
	<title abbrev="OSPF Link TE Attributes Reuse">OSPF Application-Specific Link Att
	ributes</title>

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

	<address>
	<postal>
	<street>Eurovea Centre, Central 3</street>

	<street>Pribinova Street 10</street>

	<city>Bratislava</city>

	<code>81109</code>

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

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

	<author initials='L.' surname="Ginsberg" fullname='Les Ginsberg'>
	<organization>Cisco Systems</organization>
	<address>
	<postal>
	<street>821 Alder Drive</street>
	<city> MILPITAS</city> <region>CA</region>
	<country>USA</country>
	<code>95035</code>
	</postal>
	<email>ginsberg@cisco.com</email>
	</address>
	</author>

	<author initials='W.' surname="Henderickx" fullname='Wim Henderickx'>
	<organization>Nokia</organization>
	<address>
	<postal>
	<street>Copernicuslaan 50</street>
	<city>Antwerp</city><region>2018</region>
	<country>Belgium</country>
	<code>94089</code>
	</postal>
	<email>wim.henderickx@nokia.com</email>
	</address>
	</author>

	<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
	<organization>Apstra</organization>

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

	<city></city>

	<region></region>

	<code></code>

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

	<email>jefftant.ietf@gmail.com</email>
	</address>
	</author>

	<author fullname="John Drake" initials="J." surname="Drake">
	<organization>Juniper Networks</organization>
	<address>
	<postal>
	<street>1194 N. Mathilda Ave</street>

	<city>Sunnyvale</city>

	<region>California</region>

	<code>94089</code>

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

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

	<date/>

	<area>Routing</area>
	<workgroup>LSR Working Group</workgroup>

	<abstract>

	<t>Existing traffic engineering related link attribute advertisements
	have been defined and are used in RSVP-TE deployments. Since the
	original RSVP-TE use case was defined, additional applications (e.g.,
	Segment Routing Policy, Loop Free Alternate) have been
	defined that also make use of the link attribute advertisements. In
	cases where multiple applications wish to make use of these link
	attributes the current advertisements do not support application
	specific values for a given attribute nor do they support indication
	of which applications are using the advertised value for a given
	link. This document introduces new link attribute advertisements in OSPFv2 a
	nd OSPFv3
	that address both of these shortcomings.</t>
	</abstract>
	</front>

	<middle>
	<section title="Introduction">

	<t>Advertisement of link attributes by the OSPFv2 <xref target="RFC2328"/> a
	nd OSPFv3
	<xref target="RFC5340"/> protocols in support of traffic
	engineering (TE) was introduced by <xref target="RFC3630"/> and <xref target=
	"RFC5329"/>
	respectively. It has been extended by <xref target="RFC4203"/>, <xref target=
	"RFC7308"/>
	and <xref target="RFC7471"/>. Use of these extensions has been associated wi
	th
	deployments supporting Traffic Engineering over Multiprotocol Label Switching
	(MPLS)
	in the presence of the Resource Reservation Protocol (RSVP) - more succinctly
	referred to as RSVP-TE <xref target="RFC3209"/>.</t>

	<t>For the purposes of this document an application is a technology
	that makes use of link attribute advertisements, examples of which
	are listed in <xref target="ADVAPPVAL"/>.</t>

	<t>In recent years new applications have been introduced that have use
	cases for many of the link attributes historically used by RSVP-TE.
	Such applications include Segment Routing (SR) Policy
	<xref target="I-D.ietf-spring-segment-routing-policy"/> and Loop Free Alterna
	tes
	(LFA) <xref target="RFC5286"/>. This has introduced ambiguity in that if a
	deployment includes a mix of RSVP-TE support and SR Policy support (for
	example) it is not possible to unambiguously indicate which
	advertisements are to be used by RSVP-TE and which advertisements are
	to be used by SR Policy. If the topologies are fully congruent this may
	not be an issue, but any incongruence leads to ambiguity.</t>

	<t>An example where this ambiguity causes a problem is a network in that RSVP
	-TE
	is enabled only on a subset of its links. A link attribute is advertised for
	the
	purpose of another application (e.g. SR Policy) for a link that is not enable
	d for RSVP-TE.
	As soon as the router that is an RSVP-TE head-end sees the link attribute bei
	ng
	advertised for that link, it assumes RSVP-TE is enabled on that link, even th
	ough
	it is not. If such RSVP-TE head-end router tries to setup an RSVP-TE path vi
	a
	that link, it will result in the path setup failure.</t>

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

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

	</section>

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

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

	<t><list style="numbers">
	<t>Support for indicating which applications are using the link
	attribute advertisements on a link</t>

	<t>Support for advertising application-specific values for the same
	attribute on a link</t>
	</list>[RFC7855] discusses use cases/requirements for Segment Routing
	(SR). Included among these use cases is SR Policy which is defined in
	<xref target="I-D.ietf-spring-segment-routing-policy"/>. If both RSVP-TE
	and SR Policy are deployed in a network, link attribute advertisements
	can be used by one or both of these applications. As there is no
	requirement for the link attributes advertised on a given link used by
	SR Policy to be identical to the link attributes advertised on that same
	link used by RSVP-TE, there is a clear requirement to indicate
	independently which link attribute advertisements are to be used by each
	application.</t>

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

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

	<section anchor="LEG_ADV" title="Existing Advertisement of Link Attributes">

	<t>There are existing advertisements used in support of RSVP-TE. These advertis
	ements
	are carried in the OSPFv2 TE Opaque LSA <xref target="RFC3630"/> and
	OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329"/>. Additional RSVP-TE link attr
	ibutes have
	been defined by <xref target="RFC4203"/>, <xref target="RFC7308"/>
	and <xref target="RFC7471"/>.</t>

	<t>Extended Link Opaque LSAs as defined in <xref target="RFC7684"/> for OSPFv2 a
	nd
	Extended Router-LSAs <xref target="RFC8362"/> for OSPFv3 are used to advertise
	link
	attributes that are used by applications other than RSVP-TE or GMPLS <xref targ
	et="RFC4203"/>.
	These LSAs were defined as a generic containers for distribution of the extende
	d link attributes.</t>

	</section>

	<section title="Advertisement of Link Attributes">

	<t>This section outlines the solution for advertising link attributes
	originally defined for RSVP-TE or GMPLS when they are used for other applicati
	ons.</t>

	<section title="OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA">

	<t>Advantages of Extended Link Opaque LSAs as defined in <xref target="RFC7684
	"/>
	for OSPFv2 and Extended Router-LSAs <xref target="RFC8362"/> for OSPFv3 with r
	espect
	to advertisement of link attributes originally defined for RSVP-TE when used i
	n packet
	networks and in GMPLS:
	<list style="numbers">

	<t>Advertisement of the link attributes does not make the link part of the R
	SVP-TE topology.
	It avoids any conflicts and is fully compatible with <xref target="RFC3630"
	/> and
	<xref target="RFC5329"/>.</t>


	<t>The OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA remains truly opaqu	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	e to OSPFv2
	and OSPFv3 as originally defined in <xref target="RFC3630"/> and <xref targe
	t="RFC5329"/>
	respectively. Their contents are not inspected by OSPF, which instead acts a
	s a pure
	transport.</t>


	<t>There is a clear distinction between link attributes used by RSVP-TE and	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
	link attributes used by other OSPFv2 or OSPFv3 applications.</t>	category="std" consensus="true" ipr="trust200902"
		docName="draft-ietf-ospf-te-link-attr-reuse-16" number="8920"
		obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true"
		sortRefs="true" version="3">


	<t>All link attributes that are used by other applications are advertised in	<front>
	a single LSA, the Extended Link Opaque LSA in OSPFv2 or the OSPFv3	<title abbrev="OSPF App-Specific Link Attributes">OSPF Application-Specific
	E-Router-LSA <xref target="RFC8362"/> in OSPFv3.</t>	Link Attributes</title>
	</list></t>	<seriesInfo name="RFC" value="8920"/>
		<author fullname="Peter Psenak" initials="P." role="editor" surname="Psenak
		">
		<organization>Cisco Systems</organization>
		<address>
		<postal>
		<extaddr>Eurovea Centre, Central 3</extaddr>
		<street>Pribinova Street 10</street>
		<city>Bratislava</city>
		<code>81109</code>
		<country>Slovakia</country>
		</postal>
		<email>ppsenak@cisco.com</email>
		</address>
		</author>
		<author initials="L." surname="Ginsberg" fullname="Les Ginsberg">
		<organization>Cisco Systems</organization>
		<address>
		<postal>
		<street>821 Alder Drive</street>
		<city>Milpitas</city>
		<region>CA</region>
		<country>United States of America</country>
		<code>95035</code>
		</postal>
		<email>ginsberg@cisco.com</email>
		</address>
		</author>
		<author initials="W." surname="Henderickx" fullname="Wim Henderickx">
		<organization>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>Apstra</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>Juniper Networks</organization>
		<address>
		<postal>
		<street>1194 N. Mathilda Ave</street>
		<city>Sunnyvale</city>
		<region>California</region>
		<code>94089</code>
		<country>United States of America</country>
		</postal>
		<email>jdrake@juniper.net</email>
		</address>
		</author>
		<date year="2020" month="October" />
		<area>Routing</area>
		<workgroup>LSR Working Group</workgroup>
		<abstract>
		<t>Existing traffic-engineering-related link attribute advertisements
		have been defined and are used in RSVP-TE deployments. Since the
		original RSVP-TE use case was defined, additional applications (e.g.,
		Segment Routing Policy and Loop-Free Alternates) that also make use of the
		link attribute advertisements have been defined. In
		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
		of which applications are using the advertised value for a given
		link. This document introduces new link attribute advertisements in OSPFv2
		and OSPFv3 that address both of these shortcomings.</t>
		</abstract>
		</front>
		<middle>
		<section numbered="true" toc="default">
		<name>Introduction</name>
		<t>Advertisement of link attributes by the OSPFv2 <xref
		target="RFC2328" format="default"/> and OSPFv3 <xref target="RFC5340"
		format="default"/> protocols in support of traffic engineering (TE) was
		introduced by <xref target="RFC3630" format="default"/> and <xref
		target="RFC5329" format="default"/>, respectively. It has been extended
		by <xref target="RFC4203" format="default"/>, <xref target="RFC7308"
		format="default"/>, and <xref target="RFC7471" format="default"/>. Use
		of these extensions has been associated with deployments supporting
		Traffic Engineering over Multiprotocol Label Switching (MPLS) in the
		presence of the Resource Reservation Protocol (RSVP), more succinctly
		referred to as RSVP-TE <xref target="RFC3209" format="default"/>.</t>


	<t>The disadvantage of this approach is that in rare cases, the same link attr	<t>For the purposes of this document, an application is a technology
	ibute is	that makes use of link attribute advertisements, examples of which are
	advertised in both the TE Opaque and Extended Link Attribute LSAs in OSPFv2 o	listed in <xref target="ADVAPPVAL" format="default"/>.</t>
	r
	the Intra-Area-TE-LSA and E-Router-LSA in OSPFv3.</t>


	<t>Extended Link Opaque LSA <xref target="RFC7684"/> and E-Router-LSA	<t>In recent years, new applications have been introduced that have use
	<xref target="RFC8362"/> are used to advertise any link attributes used	cases for many of the link attributes historically used by RSVP-TE.
	for non-RSVP-TE applications in OSPFv2 or OSPFv3 respectively, including those	Such applications include Segment Routing (SR) Policy <xref
	that have	target="I-D.ietf-spring-segment-routing-policy" format="default"/> and
	been originally defined for RSVP-TE applications (See <xref target="REUSED_ATT	Loop-Free Alternates (LFAs) <xref target="RFC5286"
	R"/>).</t>	format="default"/>. This has introduced ambiguity in that if a
		deployment includes a mix of RSVP-TE support and SR Policy support, for
		example, it is not possible to unambiguously indicate which
		advertisements are to be used by RSVP-TE and which advertisements are
		to be used by SR Policy. If the topologies are fully congruent, this
		may not be an issue, but any incongruence leads to ambiguity.</t>


	<t>TE link attributes used for RSVP-TE/GMPLS continue to use OSPFv2 TE Opaque	<t>An example of where this ambiguity causes a problem is a network
	LSA	where RSVP-TE is enabled only on a subset of its links. A link
	<xref target="RFC3630"/> and OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329"/>	attribute is advertised for the purpose of another application (e.g.,
	.</t>	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
		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
		up an RSVP-TE path via that link, it will result in the path setup
		failure.</t>


	<t>The format of the link attribute TLVs that have been defined for RSVP-TE ap	<t>An additional issue arises in cases where both applications are
	plications	supported on a link but the link attribute values associated with each
	will be kept unchanged even when they are used for non-RSVP-TE applications. U	application differ. Current advertisements do not support advertising
	nique code	application-specific values for the same attribute on a specific
	points are allocated for these link attribute TLVs from the	link.</t>
	OSPFv2 Extended Link TLV Sub-TLV Registry <xref target="RFC7684"/> and from th	<t>This document defines extensions that address these issues. Also,
	e	as evolution of use cases for link attributes can be expected to
	OSPFv3 Extended-LSA Sub-TLV Registry <xref target="RFC8362"/>, as specified in	continue in the years to come, this document defines a solution that
	<xref target="IANA"/>.</t>	is easily extensible for the introduction of new applications and new
		use cases.</t>


	</section>	<section numbered="true" toc="default">
	</section>


	<section anchor="ADVAPPVAL" title="Advertisement of Application-Specific Values"	<name>Requirements Language</name>
	>	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp1
		4>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
		"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</b
		cp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
		"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as describe
		d in
		BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174"
		format="default"/> when, and only when, they appear in all
		capitals, as shown here.</t>
		</section>
		</section>


	<t>To allow advertisement of the application-specific values of the link attribu	<section anchor="REQDIS" numbered="true" toc="default">
	te, a new	<name>Requirements Discussion</name>
	Application-Specific Link Attributes (ASLA) sub-TLV is defined. The ASLA sub-TL	<t>As stated previously, evolution of use cases for link attributes can
	V is a sub-TLV	be expected to continue. Therefore, any discussion of existing use cases
	of the OSPFv2 Extended Link TLV <xref target="RFC7684"/> and OSPFv3 Router-Link	is limited to requirements that are known at the time of this writing.
	TLV	However, in order to determine the functionality required beyond what
	<xref target="RFC8362"/>.</t>	already exists in OSPF, it is only necessary to discuss use cases that
		justify the key points identified in the introduction, which are:</t>
		<ol spacing="normal" type="1">
		<li>Support for indicating which applications are using the link
		attribute advertisements on a link</li>
		<li>Support for advertising application-specific values for the same
		attribute on a link</li>
		</ol>
		<t><xref target="RFC7855"/> discusses use cases and requirements for Segm
		ent Routing
		(SR). Included among these use cases is SR Policy, which is defined in
		<xref target="I-D.ietf-spring-segment-routing-policy" format="default"/>.
		If both RSVP-TE
		and SR Policy are deployed in a network, link attribute advertisements
		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
		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
		independently which link attribute advertisements are to be used by each
		application.</t>
		<t>As the number of applications that may wish to utilize link
		attributes may grow in the future, an additional requirement is that the
		extensions defined allow the association of additional applications to
		link attributes without altering the format of the advertisements or
		introducing new backwards-compatibility issues.</t>
		<t>Finally, there may still be many cases where a single attribute value
		can be shared among multiple applications, so the solution must minimize
		advertising duplicate link/attribute pairs whenever possible.</t>
		</section>
		<section anchor="LEG_ADV" numbered="true" toc="default">
		<name>Existing Advertisement of Link Attributes</name>
		<t>There are existing advertisements used in support of RSVP-TE. These
		advertisements are carried in the OSPFv2 TE Opaque Link State
		Advertisement (LSA) <xref target="RFC3630" format="default"/> and
		OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329"
		format="default"/>. Additional RSVP-TE link attributes have been
		defined by <xref target="RFC4203" format="default"/>, <xref
		target="RFC7308" format="default"/>, and <xref target="RFC7471"
		format="default"/>.</t>
		<t>Extended Link Opaque LSAs as defined in <xref target="RFC7684" format=
		"default"/> for OSPFv2 and
		E-Router-LSAs <xref target="RFC8362" format="default"/> 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"/>.
		These LSAs were defined as generic containers for distribution of the extended
		link attributes.</t>
		</section>
		<section numbered="true" toc="default">
		<name>Advertisement of Link Attributes</name>
		<t>This section outlines the solution for advertising link attributes
		originally defined for RSVP-TE or GMPLS when they are used for other applicat
		ions.</t>
		<section numbered="true" toc="default">
		<name>OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA</name>
		<t>The following are the advantages of Extended Link Opaque LSAs as defi
		ned in <xref target="RFC7684" format="default"/>
		for OSPFv2 and E-Router-LSAs <xref target="RFC8362" format="default"/> for OS
		PFv3 with respect
		to the advertisement of link attributes originally defined for RSVP-TE when u
		sed in packet
		networks and in GMPLS:
		</t>
		<ol spacing="normal" type="1">
		<li>Advertisement of the link attributes does not make the link part o
		f the RSVP-TE topology.
		It avoids any conflicts and is fully compatible with <xref target="RFC3630
		" format="default"/> and
		<xref target="RFC5329" format="default"/>.</li>
		<li>The OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA remain
		truly opaque to OSPFv2 and OSPFv3 as originally defined in <xref
		target="RFC3630" format="default"/> and <xref target="RFC5329"
		format="default"/>, respectively. Their contents are not inspected
		by OSPF, which instead acts as a pure transport.</li>
		<li>There is a clear distinction between link attributes used by RSVP-
		TE and
		link attributes used by other OSPFv2 or OSPFv3 applications.</li>
		<li>All link attributes that are used by other applications are advert
		ised in the Extended Link Opaque LSA in OSPFv2 <xref
		target="RFC7684" format="default"/> or the OSPFv3
		E-Router-LSA <xref target="RFC8362" format="default"/> in OSPFv3.</li>
		</ol>
		<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
		the Intra-Area-TE-LSA and E-Router-LSA in OSPFv3.</t>
		<t>The Extended Link Opaque LSA <xref target="RFC7684"
		format="default"/> and E-Router-LSA
		<xref target="RFC8362" format="default"/> are used to advertise any link attr
		ibutes used
		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
		TR" format="default"/>).</t>
		<t>TE link attributes used for RSVP-TE/GMPLS continue to use the OSPFv2
		TE Opaque LSA
		<xref target="RFC3630" format="default"/> and OSPFv3 Intra-Area-TE-LSA <xref
		target="RFC5329" format="default"/>.</t>
		<t>The format of the link attribute TLVs that have been defined for
		RSVP-TE applications will be kept unchanged even when they are used
		for non-RSVP-TE applications. Unique codepoints are allocated for
		these link attribute TLVs from the "OSPFv2 Extended Link TLV Sub-TLVs"
		registry <xref target="RFC7684" format="default"/> and from the
		"OSPFv3 Extended-LSA Sub-TLVs" registry <xref target="RFC8362"
		format="default"/>, as specified in <xref target="IANA"
		format="default"/>.</t>
		</section>
		</section>
		<section anchor="ADVAPPVAL" numbered="true" toc="default">
		<name>Advertisement of Application-Specific Values</name>
		<t>To allow advertisement of the application-specific values of the link
		attribute, a new
		Application-Specific Link Attributes (ASLA) sub-TLV is defined. The ASLA sub-T
		LV is a sub-TLV
		of the OSPFv2 Extended Link TLV <xref target="RFC7684" format="default"/> and O
		SPFv3 Router-Link TLV
		<xref target="RFC8362" format="default"/>.</t>


	<t>On top of advertising the link attributes for standardized	<t>In addition to advertising the link attributes 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>The ASLA sub-TLV is an optional sub-TLV of the OSPFv2 Extended Link TLV
	<t>The ASLA sub-TLV is an optional sub-TLV of OSPFv2 Extended Link TLV and	and
	OSPFv3 Router-Link TLV. Multiple ASLA sub-TLVs can be present in its parent TLV	OSPFv3 Router-Link TLV. Multiple ASLA sub-TLVs can be present in a parent
	when	TLV when different applications want to control different link attributes or
	different applications want to control different link attributes or when differe	when a different value
	nt 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

	MUST be used for advertisement of the link attributes listed at the end on this	<bcp14>MUST</bcp14> be used for advertisement of the link attributes listed at t
	section	he end of this section
	if these are advertised inside OSPFv2 Extended Link TLV and OSPFv3 Router-Link T	if these are advertised inside the OSPFv2 Extended Link TLV and OSPFv3 Router-Li
	LV.	nk TLV.
	It has the following format:	It has the following format:

	<figure>	</t>
	<artwork>	<artwork name="" type="" align="left" alt=""><![CDATA[
	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 \|	\| Standard Application Identifier Bit Mask \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	\| User Defined Application Identifier Bit Mask \|	\| User-Defined Application Identifier Bit Mask \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Link Attribute sub-sub-TLVs \|	\| Link Attribute sub-sub-TLVs \|
	+- -+	+- -+
	\| ... \|	\| ... \|

		]]></artwork>


	where:	<t> where:</t>
	</artwork>
	</figure>
	<list style="hanging">
	<t>Type: 10 (OSPFv2), 11 (OSPFv3)</t>


	<t>Length: variable</t>	<dl newline="false">


	<t>SABM Length: Standard Application Identifier Bit Mask Length in o	<dt>Type:</dt><dd> 10 (OSPFv2), 11 (OSPFv3)</dd>
	ctets.
	The value MUST be 0, 4 or 8.
	If the Standard Application Bit Mask is not present, the Standard
	Application Bit Mask Length MUST be set to 0.</t>


	<t>UDABM Length: User Defined Application Identifier Bit Mask Length	<dt>Length:</dt><dd> Variable</dd>
	in octets.
	The value MUST be 0, 4 or 8.
	If the User Defined Application Bit Mask is not present, the User De
	fined
	Application Bit Mask Length MUST be set to 0.</t>


	<t>Standard Application Identifier Bit Mask: Optional set of bits, w	<dt>SABM Length:</dt><dd> Standard Application Identifier Bit Mask Lengt
	here each bit	h in octets.
	represents a single standard application. Bits are defined in the Li	The value <bcp14>MUST</bcp14> be 0, 4, or 8.
	nk	If the Standard Application Identifier Bit Mask is not present, the
	Attribute Application Identifier Registry, which has been defined in	SABM
	<xref target="I-D.ietf-isis-te-app"/>.	Length <bcp14>MUST</bcp14> be set to 0.</dd>
	Current assignments are repeated here for
	informational purpose:	<dt>UDABM Length:</dt><dd> User-Defined Application Identifier Bit Mask
	<figure>	Length in octets.
	<artwork>	The value <bcp14>MUST</bcp14> be 0, 4, or 8.
		If the User-Defined Application Identifier Bit Mask is not present,
		the
		UDABM Length <bcp14>MUST</bcp14> be set to 0.</dd>

		<dt>Standard Application Identifier Bit Mask:</dt><dd><t>Optional
		set of bits, where each bit represents a single standard
		application. Bits are defined in the "Link Attribute Applications"
		registry, which is defined in <xref target="RFC8919"
		format="default"/>. Current assignments are repeated here for
		informational purposes:</t>

		<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3 4 5 6 7 ...	0 1 2 3 4 5 6 7 ...
	+-+-+-+-+-+-+-+-+...	+-+-+-+-+-+-+-+-+...
	\|R\|S\|F\| ...	\|R\|S\|F\| ...
	+-+-+-+-+-+-+-+-+...	+-+-+-+-+-+-+-+-+...

	</artwork>	]]></artwork>
	</figure>
	<list style="hanging">
	<t>Bit-0 (R-bit): RSVP-TE</t>


	<t>Bit-1 (S-bit): Segment Routing Policy</t>	<dl newline="false" spacing="normal">


	<t>Bit-2 (F-bit): Loop Free Alternate (LFA). Includes all LFA ty pes</t>	<dt>Bit 0 (R-bit):</dt><dd> RSVP-TE.</dd>


	</list></t>	<dt>Bit 1 (S-bit):</dt><dd> Segment Routing Policy.</dd>


	<t>User Defined Application Identifier Bit Mask: Optional set of bit	<dt>Bit 2 (F-bit):</dt><dd> Loop-Free Alternate (LFA). Includes all
	s, where each bit	LFA types.</dd>
	represents a single user defined application.</t>	</dl>
	</list></t>	</dd>


	<t>If the SABM or UDABM length is other than 0, 4, or 8, the ASLA sub-TLV MUST b	<dt>User-Defined Application Identifier Bit Mask:</dt><dd> Optional
	e ignored	set of bits, where each bit
	by the receiver.</t>	represents a single user-defined application.</dd>
		</dl>


	<t>Standard Application Identifier Bits are defined/sent starting with	<t>If the SABM or UDABM Length is other than 0, 4, or 8, the ASLA sub-TLV
	Bit 0. Undefined bits that are transmitted MUST be transmitted as 0 and MUST	<bcp14>MUST</bcp14> be ignored
	be ignored	by the receiver.</t>
	on receipt. Bits that are not transmitted MUST be treated as if they	<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
		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 MUST be ignored on receipt.</t>	implementation <bcp14>MUST</bcp14> be ignored on receipt.</t>
		<t>User-Defined Application Identifier Bits have no relationship to
	<t>User Defined Application Identifier Bits have no relationship to
	Standard Application Identifier Bits and are not managed by IANA or	Standard Application Identifier Bits and are not managed by IANA or

	any other standards body. It is recommended that bits are 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 which are transmitted MUST be	to advertise all UDAs. Undefined bits that are transmitted <bcp14>MUST</bcp14
	transmitted as 0 and MUST be ignored on receipt. Bits that are not	> be
	transmitted MUST be treated as if they are set to 0 on receipt. Bits that ar	transmitted as 0 and <bcp14>MUST</bcp14> be ignored on receipt. Bits that are
	e not	not
	supported by an implementation MUST be ignored on receipt.</t>	transmitted <bcp14>MUST</bcp14> be treated as if they are set to 0 on receipt
		. Bits that are not
	<t>If the link attribute advertisement is intended to be only used by a specific	supported by an implementation <bcp14>MUST</bcp14> be ignored on receipt.</t>
	set of applications,	<t>If the link attribute advertisement is intended to be only used by a sp
	corresponding Bit Masks MUST be present and application-specific bit(s) MUST be	ecific set of applications,
	set for all	corresponding bit masks <bcp14>MUST</bcp14> be present, and application-specific
		bit(s) <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>Application Identifier Bit Masks apply to all link attributes that supp
	<t>Application Bit Masks apply to all link attributes that support application-s	ort application-specific
	pecific
	values and are advertised in the ASLA sub-TLV.</t>	values and are advertised in the ASLA sub-TLV.</t>

		<t>The advantage of not making the Application Identifier Bit Masks part o
	<t>The advantage of not making the Application Bit Masks part of the attribute a	f the attribute advertisement
	dvertisement
	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>If the same attribute is advertised in more than one ASLA sub-TLVs with
	<t>If the same attribute is advertised in more than one ASLA sub-TLVs with the a	the application
	pplication	listed in the Application Identifier Bit Masks, the application <bcp14>SHOULD</b
	listed in the Application Bit Masks, the application SHOULD use the first instan	cp14> use the first instance of
	ce of
	advertisement and ignore any subsequent advertisements of that attribute.</t>	advertisement and ignore any subsequent advertisements of that attribute.</t>

		<t>If link attributes are advertised with zero-length
	<t>If link attributes are advertised with zero length
	Application Identifier Bit Masks for both standard applications and	Application Identifier Bit Masks for both standard applications and

	user defined applications, then any Standard Application and/or any	user-defined applications, then any standard application and/or any
	User Defined Application is permitted to use that set of link	user-defined application is permitted to use that set of link
	attributes. If support for a new application is introduced	attributes. If support for a new application is introduced
	on any node in a network in the presence of such advertisements,	on any node in a network in the presence of such advertisements,
	these advertisements are permitted to be used by the new application.	these advertisements are permitted to be used by the new application.

	If this is not what is intended, then existing advertisements MUST be	If this is not what is intended, then existing advertisements <bcp14>MUST</b cp14> be
	readvertised with an explicit set of applications specified before a	readvertised with an explicit set of applications specified before a
	new application is introduced.</t>	new application is introduced.</t>

		<t>An application-specific advertisement (Application Identifier Bit
	<t>An application-specific advertisement (Application Identifier Bit
	Mask with a matching Application Identifier Bit set) for an attribute	Mask with a matching Application Identifier Bit set) for an attribute

	MUST always be preferred over the advertisement of the same attribute	<bcp14>MUST</bcp14> always be preferred over the advertisement of the same a
	with the zero length Application Identifier Bit Masks for both	ttribute
	standard applications and user defined applications on the same link.</t>	with the zero-length Application Identifier Bit Masks for both
		standard applications and user-defined applications on the same link.</t>
	<t>This document defines the initial set of link attributes that MUST use the AS	<t>This document defines the initial set of link attributes that <bcp14>MU
	LA 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 which define new link attributes MUST state whether the new attributes	Documents that define new link attributes <bcp14>MUST</bcp14> state whether the
	support	new attributes support
	application-specific values and as such are advertised in an ASLA sub-TLV. The s	application-specific values and, as such, are advertised in an ASLA sub-TLV. The
	tandard	standard
	link attributes that are advertised in ASLA sub-TLVs are:	link attributes that are advertised in ASLA sub-TLVs are:


	<list style="hanging">	</t>
	<t>- Shared Risk Link Group <xref target="RFC4203"/></t>	<ul>
	<t>- Unidirectional Link Delay <xref target="RFC7471"/></t>
	<t>- Min/Max Unidirectional Link Delay <xref target="RFC7471"/></t>
	<t>- Unidirectional Delay Variation <xref target="RFC7471"/></t>
	<t>- Unidirectional Link Loss <xref target="RFC7471"/></t>
	<t>- Unidirectional Residual Bandwidth <xref target="RFC7471"/></t>
	<t>- Unidirectional Available Bandwidth <xref target="RFC7471"/></t>
	<t>- Unidirectional Utilized Bandwidth <xref target="RFC7471"/></t>
	<t>- Administrative Group <xref target="RFC3630"/></t>
	<t>- Extended Administrative Group <xref target="RFC7308"/></t>
	<t>- TE Metric <xref target="RFC3630"/></t>
	</list></t>
	</section>


	<section anchor="REUSED_ATTR" title="Reused TE link attributes">	<li> Shared Risk Link Group <xref target="RFC4203" format="default"/></l i>


	<t>This section defines the use case and indicates the code points (<xref targ	<li> Unidirectional Link Delay <xref target="RFC7471" format="default"/>
	et="IANA"/>)	</li>
	from the OSPFv2 Extended Link TLV Sub-TLV Registry and OSPFv3 Extended-LSA Sub
	-TLV
	Registry for some of the link attributes that have been originally defined for
	RSVP-TE
	or GMPLS.</t>


	<section anchor ="SRLG" title="Shared Risk Link Group (SRLG)">	<li> Min/Max Unidirectional Link Delay <xref target="RFC7471" format="de
	<t>The SRLG of a link can be used in OSPF calculated IPFRR (IP Fast Reroute)	fault"/></li>
	<xref target="RFC5714"/> to compute a backup path
		<li> Unidirectional Delay Variation <xref target="RFC7471" format="defau
		lt"/></li>

		<li> Unidirectional Link Loss <xref target="RFC7471" format="default"/><
		/li>

		<li> Unidirectional Residual Bandwidth <xref target="RFC7471" format="de
		fault"/></li>

		<li> Unidirectional Available Bandwidth <xref target="RFC7471" format="d
		efault"/></li>

		<li> Unidirectional Utilized Bandwidth <xref target="RFC7471" format="de
		fault"/></li>

		<li> Administrative Group <xref target="RFC3630" format="default"/></li>

		<li> Extended Administrative Group <xref target="RFC7308" format="defaul
		t"/></li>

		<li> TE Metric <xref target="RFC3630" format="default"/></li>
		</ul>
		</section>
		<section anchor="REUSED_ATTR" numbered="true" toc="default">
		<name>Reused TE Link Attributes</name>
		<t>This section defines the use case and indicates the codepoints (<xref
		target="IANA" format="default"/>) from the "OSPFv2 Extended Link TLV
		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
		GMPLS.</t>

		<section anchor="SRLG" numbered="true" toc="default">
		<name>Shared Risk Link Group (SRLG)</name>
		<t>The SRLG of a link can be used in OSPF-calculated IPFRR (IP Fast Rero
		ute)
		<xref target="RFC5714" format="default"/> to compute a backup path
	that does not share any SRLG group with the protected link.</t>	that does not share any SRLG group with the protected link.</t>


	<t>To advertise the SRLG of the link in the OSPFv2 Extended Link TLV, the sam	<t>To advertise the SRLG of the link in the OSPFv2 Extended Link TLV, th
	e format	e same format
	for the sub-TLV defined in section 1.3 of <xref target="RFC4203"/> is used an	for the sub-TLV defined in <xref target="RFC4203"
	d TLV	sectionFormat="of" section="1.3"/> is used with TLV
	type 11 is used. Similarly, for OSPFv3 to advertise the SRLG in the OSPFv3 Ro	type 11. Similarly, for OSPFv3 to advertise the SRLG in the OSPFv3 Router-Lin
	uter-Link	k
	TLV, TLV type 12 is used.</t>	TLV, TLV type 12 is used.</t>

	</section>	</section>
		<section numbered="true" toc="default">
	<section title="Extended Metrics">	<name>Extended Metrics</name>
	<t><xref target="RFC3630"/> defines several link bandwidth types. <xref target	<t><xref target="RFC3630" format="default"/> defines several link bandwi
	="RFC7471"/>	dth types. <xref target="RFC7471" format="default"/>
	defines extended link metrics that are based on link bandwidth, delay and loss	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)	OSPF area to satisfy requirements for bandwidth, delay (nominal or worst case)
	or loss.</t>	, or loss.</t>
		<t>To advertise extended link metrics in the OSPFv2 Extended Link TLV, t
	<t>To advertise extended link metrics in the OSPFv2 Extended Link TLV, the sa	he same format
	me format	for the sub-TLVs defined in <xref target="RFC7471" format="default"/> is use
	for the sub-TLVs defined in <xref target="RFC7471"/> is used with the follow	d with the following
	ing
	TLV types:	TLV types:

	<list style="hanging">	</t>
	<t>12 - Unidirectional Link Delay</t>	<dl>
	<t>13 - Min/Max Unidirectional Link Delay</t>
	<t>14 - Unidirectional Delay Variation</t>
	<t>15 - Unidirectional Link Loss</t>
	<t>16 - Unidirectional Residual Bandwidth</t>
	<t>17 - Unidirectional Available Bandwidth</t>
	<t>18 - Unidirectional Utilized Bandwidth</t>
	</list></t>


	<t>To advertise extended link metrics in the OSPFv3 Extended-LSA Router-Link	<dt>12:</dt><dd> Unidirectional Link Delay</dd>
	TLV, the
	same format for the sub-TLVs defined in <xref target="RFC7471"/> is used wit
	h the following
	TLV types:
	<list style="hanging">
	<t>13 - Unidirectional Link Delay</t>
	<t>14 - Min/Max Unidirectional Link Delay</t>
	<t>15 - Unidirectional Delay Variation</t>
	<t>16 - Unidirectional Link Loss</t>
	<t>17 - Unidirectional Residual Bandwidth</t>
	<t>18 - Unidirectional Available Bandwidth</t>
	<t>19 - Unidirectional Utilized Bandwidth</t>
	</list></t>


	</section>	<dt>13:</dt><dd> Min/Max Unidirectional Link Delay</dd>


	<section title="Administrative Group">	<dt>14:</dt><dd> Unidirectional Delay Variation</dd>
	<t><xref target="RFC3630"/> and <xref target="RFC7308"/> define the Administra
	tive Group and
	Extended Administrative Group sub-TLVs respectively.</t>


	<t>To advertise the Administrative Group and Extended Administrative Group in	<dt>15:</dt><dd> Unidirectional Link Loss</dd>
	the OSPFv2
	Extended Link TLV, the same format for the sub-TLVs defined in <xref target=
	"RFC3630"/>
	and <xref target="RFC7308"/> is used with the following TLV types:


	<list style="hanging">	<dt>16:</dt><dd> Unidirectional Residual Bandwidth</dd>
	<t>19 - Administrative Group</t>
	<t>20 - Extended Administrative Group</t>
	</list></t>


	<t>To advertise Administrative Group and Extended Administrative Group in th	<dt>17:</dt><dd> Unidirectional Available Bandwidth</dd>
	e OSPFv3
	Router-Link TLV, the same format for the sub-TLVs defined in <xref target="R
	FC3630"/>
	and <xref target="RFC7308"/> is used with the following TLV types:


	<list style="hanging">	<dt>18:</dt><dd> Unidirectional Utilized Bandwidth</dd>
	<t>20 - Administrative Group</t>	</dl>
	<t>21 - Extended Administrative Group</t>	<t>To advertise extended link metrics in the Router-Link TLV inside
	</list></t>	the OSPFv3 E-Router-LSA, the same format for the sub-TLVs defined in <xre
		f target="RFC7471" format="default"/> is used with the following
		TLV types:
		</t>
		<dl>


	</section>	<dt>13:</dt><dd> Unidirectional Link Delay</dd>


	<section title="Traffic Engineering Metric">	<dt>14:</dt><dd> Min/Max Unidirectional Link Delay</dd>


	<t><xref target="RFC3630"/> defines Traffic Engineering Metric.</t>	<dt>15:</dt><dd> Unidirectional Delay Variation</dd>


	<t>To advertise the Traffic Engineering Metric in the OSPFv2 Extended Link TLV	<dt>16:</dt><dd> Unidirectional Link Loss</dd>
	,
	the same format for the sub-TLV defined in section 2.5.5 of <xref target="RFC3
	630"/>
	is used and TLV type 22 is used. Similarly, for OSPFv3 to advertise the
	Traffic Engineering Metric in the OSPFv3 Router-Link TLV, TLV type 22 is used.
	</t>


	</section>	<dt>17:</dt><dd> Unidirectional Residual Bandwidth</dd>


	</section>	<dt>18:</dt><dd> Unidirectional Available Bandwidth</dd>


	<section anchor="SPECIALMAXBANDW" title="Maximum Link Bandwidth">	<dt>19:</dt><dd> Unidirectional Utilized Bandwidth</dd>
		</dl>
		</section>
		<section numbered="true" toc="default">
		<name>Administrative Group</name>
		<t><xref target="RFC3630" format="default"/> and <xref target="RFC7308"
		format="default"/> define the Administrative Group and
		Extended Administrative Group sub-TLVs, respectively.</t>
		<t>To advertise the Administrative Group and Extended Administrative Gro
		up in the OSPFv2
		Extended Link TLV, the same format for the sub-TLVs defined in <xref target=
		"RFC3630" format="default"/>
		and <xref target="RFC7308" format="default"/> is used with the following TLV
		types:


	<t>Maximum link bandwidth is an application independent attribute of the	</t>
	link that is defined in <xref target="RFC3630"/>. Because it is an application	<dl>
	independent attribute, it MUST NOT be advertised in ASLA sub-TLV. Instead, it
	MAY be
	advertised as a sub-TLV of the Extended Link Opaque LSA Extended Link TLV in O
	SPFv2
	<xref target="RFC7684"/> or sub-TLV of OSPFv3 E-Router-LSA Router-Link TLV in
	OSPFv3
	<xref target="RFC8362"/>.</t>


	<t>To advertise the Maximum link bandwidth in the OSPFv2 Extended Link TLV, th	<dt>19:</dt><dd> Administrative Group</dd>
	e same
	format for sub-TLV defined in <xref target="RFC3630"/> is used with
	TLV type 23.</t>


	<t>To advertise the Maximum link bandwidth in the OSPFv3 Router-Link TLV, the	<dt>20:</dt><dd> Extended Administrative Group</dd>
	same	</dl>
	format for sub-TLV defined in <xref target="RFC3630"/> is used with	<t>To advertise the Administrative Group and Extended Administrative Gro
	TLV type 23.</t>	up in the OSPFv3
		Router-Link TLV, the same format for the sub-TLVs defined in <xref target="R
		FC3630" format="default"/>
		and <xref target="RFC7308" format="default"/> is used with the following TLV
		types:


	</section>	</t>
		<dl>


	<section anchor="EXT_METRICS" title="Considerations for Extended TE Metrics">	<dt>20:</dt><dd> Administrative Group</dd>


	<t><xref target="RFC7471"/> defines a number of dynamic performance metrics a	<dt>21:</dt><dd> Extended Administrative Group</dd>
	ssociated	</dl>
		</section>
		<section numbered="true" toc="default">
		<name>Traffic Engineering Metric</name>
		<t><xref target="RFC3630" format="default"/> defines the Traffic Enginee
		ring Metric.</t>
		<t>To advertise the Traffic Engineering Metric in the OSPFv2 Extended Li
		nk TLV,
		the same format for the sub-TLV defined in <xref
		target="RFC3630" sectionFormat="of" section="2.5.5"/>
		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>
		</section>
		</section>
		<section anchor="SPECIALMAXBANDW" numbered="true" toc="default">
		<name>Maximum Link Bandwidth</name>

		<t>Maximum link bandwidth is an application-independent attribute of the
		link that is defined in <xref target="RFC3630" format="default"/>. Because
		it is an application-independent attribute, it <bcp14>MUST NOT</bcp14> be
		advertised in the ASLA sub-TLV.

		Instead, it <bcp14>MAY</bcp14> be
		advertised as a sub-TLV of the Extended Link TLV in the Extended Link Opaque
		LSA in OSPFv2 <xref target="RFC7684" format="default"/> or as a sub-TLV of
		the Router-Link TLV in the E-Router-LSA Router-Link TLV in OSPFv3
		<xref target="RFC8362" format="default"/>.</t>
		<t>To advertise the maximum link bandwidth in the OSPFv2 Extended Link TLV
		, the same
		format for the sub-TLV defined in <xref target="RFC3630" format="default"/> is
		used with
		TLV type 23.</t>
		<t>To advertise the maximum link bandwidth in the OSPFv3 Router-Link TLV,
		the same
		format for the sub-TLV defined in <xref target="RFC3630" format="default"/> is
		used with
		TLV type 23.</t>
		</section>
		<section anchor="EXT_METRICS" numbered="true" toc="default">
		<name>Considerations for Extended TE Metrics</name>
		<t><xref target="RFC7471" format="default"/> defines a number of dynamic p
		erformance 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.</t>	Bit Mask.</t>

		</section>
	</section>	<section anchor="LOCALIPV6ADDR" numbered="true" toc="default">
		<name>Local Interface IPv6 Address Sub-TLV</name>
	<section anchor="LOCALIPV6ADDR" title="Local Interface IPv6 Address Sub-TLV">	<t>The Local Interface IPv6 Address sub-TLV is an application-independent
		attribute of the
	<t>The Local Interface IPv6 Address Sub-TLV is an application independent attri	link that is defined in <xref target="RFC5329" format="default"/>. Because it
	bute of the	is an application-independent attribute, it <bcp14>MUST NOT</bcp14> be advertise
	link that is defined in <xref target="RFC5329"/>. Because it is an application	d in the ASLA sub-TLV. Instead, it <bcp14>MAY</bcp14> be
	independent attribute, it MUST NOT be advertised in the ASLA sub-TLV. Instead	advertised as a sub-TLV of the Router-Link TLV inside the OSPFv3 E-Router-LSA
	, it MAY be	<xref target="RFC8362" format="default"/>.</t>
	advertised as a sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV <xref targe	<t>To advertise the Local Interface IPv6 Address sub-TLV in the OSPFv3 Rou
	t="RFC8362"/>.</t>	ter-Link TLV,
		the same format for the sub-TLV defined in <xref target="RFC5329" format="defa
	<t>To advertise the Local Interface IPv6 Address Sub-TLV in the OSPFv3 Router-	ult"/> is used with
	Link TLV,
	the same format for sub-TLV defined in <xref target="RFC5329"/> is used with
	TLV type 24.</t>	TLV type 24.</t>

		</section>
	</section>	<section anchor="REMOTEIPV6ADDR" numbered="true" toc="default">
		<name>Remote Interface IPv6 Address Sub-TLV</name>
	<section anchor="REMOTEIPV6ADDR" title="Remote Interface IPv6 Address Sub-TLV">	<t>The Remote Interface IPv6 Address sub-TLV is an application-independent
		attribute of the
	<t>The Remote Interface IPv6 Address Sub-TLV is an application independent attr	link that is defined in <xref target="RFC5329" format="default"/>. Because it
	ibute of the	is an application-independent attribute, it <bcp14>MUST NOT</bcp14> be advertise
	link that is defined in <xref target="RFC5329"/>. Because it is an application	d in the ASLA sub-TLV. Instead, it <bcp14>MAY</bcp14> be
	independent attribute, it MUST NOT be advertised in the ASLA sub-TLV. Instead,	advertised as a sub-TLV of the Router-Link TLV inside the OSPFv3 E-Router-LSA
	it MAY be	<xref target="RFC8362" format="default"/>.</t>
	advertised as a sub-TLV of the OSPFv3 E-Router-LSA Router-Link TLV <xref targe	<t>To advertise the Remote Interface IPv6 Address sub-TLV in the OSPFv3 Ro
	t="RFC8362"/>.</t>	uter-Link TLV,
		the same format for the sub-TLV defined in <xref target="RFC5329" format="defa
	<t>To advertise the Remote Interface IPv6 Address Sub-TLV in the OSPFv3 Router	ult"/> is used with
	-Link TLV,
	the same format for sub-TLV defined in <xref target="RFC5329"/> is used with
	TLV type 25.</t>	TLV type 25.</t>

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

		<t>There are applications where the application enablement on the link
	<t>There are applications where the application enablement on the link is rel	is relevant; for example, with RSVP-TE, one needs to make sure that RSVP
	evant -	is enabled on the link before sending an RSVP-TE signaling message over it
	e.g., RSVP-TE - one needs to make sure that RSVP is enabled on the link befor	.</t>
	e	<t>There are applications where the enablement of the application on the l
	sending a RSVP-TE signaling message over it.</t>	ink is

	<t>There are applications where the enablement of the application on the link
	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>Whether the presence of link attribute advertisements for a given
	<t>Whether the presence of link attribute advertisements for a given
	application indicates that the application is enabled on that link	application indicates that the application is enabled on that link
	depends upon the application. Similarly, whether the absence of link	depends upon the application. Similarly, whether the absence of link
	attribute advertisements indicates that the application is not	attribute advertisements indicates that the application is not
	enabled depends upon the application.</t>	enabled depends upon the application.</t>

		<t>In the case of RSVP-TE, the advertisement of application-specific
	<t>In the case of RSVP-TE, the advertisement of application-specific
	link attributes 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"/> and OSPFv3 Intra-Area-TE-L	the OSPFv2 TE Opaque LSA <xref target="RFC3630" format="default"/> and OSPFv
	SA	3 Intra-Area-TE-LSA
	<xref target="RFC5329"/>.</t>	<xref target="RFC5329" format="default"/>.</t>
		<t>In the case of SR Policy, advertisement of application-specific link
	<t>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 Segment Routing 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>In the case of LFA, the advertisement of application-specific link
	<t>In the case of LFA, advertisement of application-specific link
	attributes does not indicate enablement of LFA on that link.	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>In the future, if additional standard applications are defined to
	<t>If, in the future, additional standard applications are defined to	use this mechanism, the specification defining this use <bcp14>MUST</bcp14> d
	use this mechanism, the specification defining this use MUST define	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>This document allows the advertisement of application-specific link
	<t>This document allows the advertisement of application-specific link	attributes with no application identifiers, i.e., both the Standard
	attributes with no application identifiers i.e., both the Standard	Application Identifier Bit Mask and the User-Defined Application
	Application Identifier Bit Mask and the User Defined Application	Identifier Bit Mask are not present (see <xref target="ADVAPPVAL" format="def
	Identifier Bit Mask are not present (See <xref target="ADVAPPVAL"/>).	ault"/>).
	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 attribute	an application where the advertisement of link attributes is used to infer th
	advertisements is used to infer the enablement of an application on	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="default">
		<name>Deployment Considerations</name>
	<section title="Deployment Considerations">	<section anchor="LEGACY_OSPF" numbered="true" toc="default">
		<name>Use of Legacy RSVP-TE LSA Advertisements</name>
	<section anchor="LEGACY_OSPF" title="Use of Legacy RSVP-TE LSA Advertisements">	<t>Bit identifiers for standard applications are defined in <xref target
		="ADVAPPVAL" format="default"/>.
	<t>Bit Identifiers for Standard Applications are defined in <xref target="ADV
	APPVAL"/>.
	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:


	<list style="hanging">	</t>
		<ul spacing="normal">


	<t>The application is RSVP-TE</t>	<li>The application is RSVP-TE.</li>


	<t>The application is SR Policy or LFA and RSVP-TE is not deployed	<li>The application is SR Policy or LFA, and RSVP-TE is not deployed
	anywhere in the network</t>	anywhere in the network.</li>


	<t>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 is 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</t>	attribute values used by RSVP-TE.</li>
	</list></t>	</ul>
		<t>Under the conditions defined above, implementations 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 type of advertisements are to be sent/	controls specifying which types of advertisements are to be sent and processe
	processed on receive for these applications. Further discussion of	d on receipt for these applications. Further discussion of
	the associated issues can be found in <xref target="IBCMC"/>.</t>	the associated issues can be found in <xref target="IBCMC" format="default"/>
		.</t>
	<t>New applications that future documents define to make use of the	<t>New applications that future documents define to make use of the
	advertisements defined in this document MUST NOT make use of RSVP-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="IBCMC" numbered="true" toc="default">
		<name>Interoperability, Backwards Compatibility, and Migration Concerns<
	<section anchor="IBCMC"	/name>
	title="Interoperability, Backwards Compatibility and Migration Co
	ncerns">
	<t>Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the	<t>Existing deployments of RSVP-TE, SR Policy, and/or LFA utilize the

	legacy advertisements listed in <xref target="LEG_ADV"/>. Routers which do not	legacy advertisements listed in <xref target="LEG_ADV" format="default"/ >. 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	the use of legacy advertisements by the legacy routers. The following su
	b-sections	bsections
	discuss interoperability and backwards compatibility concerns for a numb	discuss interoperability and backwards-compatibility concerns for a numb
	er of	er of
	deployment scenarios.</t>	deployment scenarios.</t>

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

	Attributes for applications other than RSVP-TE MUST be advertised usin g	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="default">
	<section anchor="MAALLNS"	<name>Multiple Applications: Some Attributes Not Shared with RSVP-TE</
	title="Multiple Applications: Some Attributes Not Shared with R	name>
	SVP-TE">
	<t>In cases where one or more applications other than RSVP-TE are	<t>In cases where one or more applications other than RSVP-TE are
	utilizing a given link and one or more link attribute values are not	utilizing a given link and one or more link attribute values are not
	shared with RSVP-TE, 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 MUST be ad vertised 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	shared with RSVP-TE, this requires duplicate advertisements for those
	attributes</t>	attributes.</t>
		</section>
		<section anchor="LEGACY" numbered="true" toc="default">
		<name>Interoperability with Legacy Routers</name>
		<t>For the applications defined in this document, routers that do
		not support the extensions defined in this document will send and
		receive only legacy link attribute advertisements. So long as there
		is any legacy router in the network that has any of the
		applications enabled, all routers <bcp14>MUST</bcp14> continue to adve
		rtise link
		attributes using legacy advertisements. In addition, the link
		attribute values associated with the set of applications supported
		by legacy routers (RSVP-TE, SR Policy, and/or LFA) are always shared
		since legacy routers have no way of advertising or processing
		application-specific values. Once all legacy routers have been
		upgraded, migration from legacy advertisements to
		application-specific advertisements can be achieved via the
		following steps:</t>
		<ol type="%d)">
		<li>Send new application-specific advertisements while continuing to
		advertise using the legacy advertisement (all advertisements are
		then duplicated). Receiving routers continue to use legacy advertiseme
		nts.</li>
		<li>Enable the use of the application-specific advertisements on
		all routers.</li>
		<li>Keep legacy advertisements if needed for RSVP-TE purposes.</li>
		</ol>
		<t>When the migration is complete, it then becomes possible to
		advertise incongruent values per application on a given link.</t>
		<t>Documents defining new applications that make use of the
		application-specific advertisements defined in this document <bcp14>MU
		ST</bcp14>
		discuss interoperability and backwards-compatibility issues that
		could occur in the presence of routers that do not support the new
		application.</t>
		</section>
		<section anchor="APPRSVP" numbered="true" toc="default">
		<name>Use of Application-Specific Advertisements for RSVP-TE</name>
		<t>The extensions defined in this document support RSVP-TE as one of
		the supported applications. It is, however, <bcp14>RECOMMENDED</bcp14>
		to advertise all
		link attributes for RSVP-TE in the existing OSPFv2 TE Opaque LSA
		<xref target="RFC3630" format="default"/> and OSPFv3 Intra-Area-TE-LSA
		<xref target="RFC5329" format="default"/>
		to maintain backwards compatibility. RSVP-TE can eventually
		utilize the application-specific advertisements for newly defined
		link attributes that are defined as application specific.</t>
		<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
		OSPFv2 TE Opaque LSA <xref target="RFC3630" format="default"/> and OSP
		Fv3 Intra-Area-TE-LSA
		<xref target="RFC5329" format="default"/> and <bcp14>MUST
		NOT</bcp14> be advertised in the ASLA sub-TLV.</t>
	</section>	</section>

		</section>
		</section>
		<section numbered="true" toc="default">
		<name>Security Considerations</name>
		<t>Existing security extensions as described in <xref target="RFC2328" for
		mat="default"/>,
		<xref target="RFC5340" format="default"/>, and <xref target="RFC8362" for
		mat="default"/> apply to extensions
		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
		networks in the OSPF routing domain. In these deployments, stronger authe
		ntication
		mechanisms such as those specified in <xref target="RFC5709" format="defa
		ult"/>,
		<xref target="RFC7474" format="default"/>, <xref target="RFC4552" format=
		"default"/>, or
		<xref target="RFC7166" format="default"/> <bcp14>SHOULD</bcp14> be
		used.</t>
		<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
		facilitate a vulnerability for attackers to crash the OSPF router or routi
		ng process. Reception of a
		malformed TLV or sub-TLV <bcp14>SHOULD</bcp14> be counted and/or logged
		for further analysis. Logging of malformed TLVs and sub-TLVs
		<bcp14>SHOULD</bcp14> be rate-limited to prevent a denial-of-service
		(DoS) attack (distributed or otherwise) from overloading the OSPF
		control plane.</t>
		<t>This document defines a new way to advertise link attributes.
		Tampering with the information defined in this document may have an
		effect on applications using it, including impacting traffic
		engineering, which uses various link attributes for its path
		computation. This is similar in nature to the impacts associated with,
		for example, <xref target="RFC3630" format="default"/>. As the
		advertisements defined in this document limit the scope to specific
		applications, the impact of tampering is similarly limited in scope.</t>
		</section>
		<section anchor="IANA" numbered="true" toc="default">
		<name>IANA Considerations</name>
		<t>This specification updates two existing registries:
		</t>
		<ul>


	<section anchor="LEGACY" title="Interoperability with Legacy Routers">	<li>the "OSPFv2 Extended Link TLV Sub-TLVs" registry</li>
	<t>For the applications defined in this document, routers that do
	not support the extensions defined in this document will send and
	receive only legacy link attribute advertisements. So long as there
	is any legacy router in the network that has any of the
	applications enabled, all routers MUST continue to advertise link
	attributes using legacy advertisements. In addition, the link
	attribute values associated with the set of applications supported
	by legacy routers (RSVP-TE, SR Policy, and/or LFA) are always shared
	since legacy routers have no way of advertising or processing
	application-specific values. Once all legacy routers have been
	upgraded, migration from legacy advertisements to application
	specific advertisements can be achieved via the following steps:</t>


	<t>1)Send new application-specific advertisements while continuing to	<li>the "OSPFv3 Extended-LSA Sub-TLVs" registry</li>
	advertise using the legacy advertisement (all advertisements are then	</ul>
	duplicated).
	Receiving routers continue to use legacy advertisements.</t>


	<t>2)Enable the use of the application-specific advertisements on	<t>The new values defined in this document have been allocated using the
	all routers</t>	IETF Review procedure as described in
		<xref target="RFC8126" format="default"/>.</t>
		<section anchor="OSPFV2IANA" numbered="true" toc="default">
		<name>OSPFv2</name>
		<t>The "OSPFv2 Extended Link TLV Sub-TLVs" registry <xref
		target="RFC7684" format="default"/> defines sub-TLVs at any level of
		nesting for OSPFv2 Extended Link TLVs. IANA has assigned the following
		sub-TLV types from the "OSPFv2 Extended Link TLV Sub-TLVs" registry:
		</t>
		<dl>


	<t>3)Keep legacy advertisements if needed for RSVP-TE purposes.</t>	<dt>10:</dt><dd> Application-Specific Link Attributes</dd>


	<t>When the migration is complete, it then becomes possible to	<dt>11:</dt><dd> Shared Risk Link Group</dd>
	advertise incongruent values per application on a given link.</t>


	<t>Documents defining new applications that make use of the	<dt>12:</dt><dd> Unidirectional Link Delay</dd>
	application-specific advertisements defined in this document MUST
	discuss interoperability and backwards compatibility issues that
	could occur in the presence of routers that do not support the new
	application.</t>
	</section>


	<section anchor="APPRSVP"	<dt>13:</dt><dd> Min/Max Unidirectional Link Delay</dd>
	title="Use of Application-Specific Advertisements for RSVP-TE">


	<t>The extensions defined in this document support RSVP-TE as one of	<dt>14:</dt><dd> Unidirectional Delay Variation</dd>
	the supported applications. It is however RECOMMENDED to advertise all
	link-attributes for RSVP-TE in the existing OSPFv2 TE Opaque LSA
	<xref target="RFC3630"/> and OSPFv3 Intra-Area-TE-LSA <xref target="RF
	C5329"/>
	to maintain backward compatibility. RSVP-TE can eventually
	utilize the application-specific advertisements for newly defined link
	attributes,
	that are defined as application-specific.</t>


	<t>Link attributes that are not allowed to be advertised in the ASLA S	<dt>15:</dt><dd> Unidirectional Link Loss</dd>
	ub-TLV,
	such as Maximum Reservable Link Bandwidth and Unreserved Bandwidth MUS
	T use the
	OSPFv2 TE Opaque LSA <xref target="RFC3630"/> and OSPFv3 Intra-Area-TE
	-LSA
	<xref target="RFC5329"/> and MUST NOT be advertised in ASLA Sub-TLV.</
	t>


	</section>	<dt>16:</dt><dd> Unidirectional Residual Bandwidth</dd>
	</section>


	</section>	<dt>17:</dt><dd> Unidirectional Available Bandwidth</dd>


	<section title="Security Considerations">	<dt>18:</dt><dd> Unidirectional Utilized Bandwidth</dd>


	<t>Existing security extensions as described in <xref target="RFC2328"></	<dt>19:</dt><dd> Administrative Group</dd>
	xref>,
	<xref target="RFC5340"></xref> and <xref target="RFC8362"/> apply to exte
	nsions
	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
	networks in the OSPF routing domain. In these deployments, stronger authe
	ntication
	mechanisms such as those specified in <xref target="RFC5709"></xref>,
	<xref target="RFC7474"></xref>, <xref target="RFC4552"></xref> or
	<xref target="RFC7166"></xref> SHOULD be used.</t>


	<t>Implementations must assure that malformed TLV and Sub-TLV defined in	<dt>20:</dt><dd> Extended Administrative Group</dd>
	this document
	are detected and do not provide a vulnerability for attackers to crash th
	e OSPF
	router or routing process. Reception of a malformed TLV or Sub-TLV SHOULD
	be counted
	and/or logged for further analysis. Logging of malformed TLVs and Sub-TLV
	s SHOULD
	be rate-limited to prevent a Denial of Service (DoS) attack (distributed
	or otherwise)
	from overloading the OSPF control plane.</t>


	<t>This document defines a new way to advertise link attributes.	<dt>22:</dt><dd> TE Metric</dd>
	Tampering with the information defined in this document may have an
	effect on applications using it, including impacting Traffic
	Engineering that uses various link attributes for its path computation. T
	his is
	similar in nature to the impacts associated with (for example)
	<xref target="RFC3630"/>. As the advertisements defined in this
	document limit the scope to specific applications, the impact of
	tampering is similarly limited in scope.</t>


	</section>	<dt>23:</dt><dd> Maximum link bandwidth</dd>
		</dl>
		</section>
		<section anchor="OSPFV3IANA" numbered="true" toc="default">
		<name>OSPFv3</name>
		<t>The "OSPFv3 Extended-LSA Sub-TLVs" registry <xref target="RFC8362"
		format="default"/> defines sub-TLVs at any level of nesting for OSPFv3
		Extended LSAs. IANA has assigned the following sub-TLV types from the
		"OSPFv3 Extended-LSA Sub-TLVs" registry:
		</t>
		<dl>


	<section anchor="IANA" title="IANA Considerations">	<dt>11:</dt><dd> Application-Specific Link Attributes</dd>


	<t>This specifications updates two existing registries:	<dt>12:</dt><dd> Shared Risk Link Group</dd>
	<list style="hanging">
	<t>- OSPFv2 Extended Link TLV Sub-TLVs Registry</t>


	<t>- OSPFv3 Extended-LSA Sub-TLV Registry</t>	<dt>13:</dt><dd> Unidirectional Link Delay</dd>
	</list></t>


	<t>New values are allocated using the IETF Review procedure as described i	<dt>14:</dt><dd> Min/Max Unidirectional Link Delay</dd>
	n
	<xref target="RFC5226"/>.</t>


	<section anchor="OSPFV2IANA" title="OSPFv2">	<dt>15:</dt><dd> Unidirectional Delay Variation</dd>


	<t>The OSPFv2 Extended Link TLV Sub-TLVs Registry <xref target="RFC7684"/> def	<dt>16:</dt><dd> Unidirectional Link Loss</dd>
	ines sub-TLVs
	at any level of nesting for OSPFv2 Extended Link TLVs. IANA has assigned the
	following
	Sub-TLV types from the OSPFv2 Extended Link TLV Sub-TLVs Registry:
	<list style="hanging">
	<t>10 - Application-Specific Link Attributes</t>
	<t>11 - Shared Risk Link Group</t>
	<t>12 - Unidirectional Link Delay</t>
	<t>13 - Min/Max Unidirectional Link Delay</t>
	<t>14 - Unidirectional Delay Variation</t>
	<t>15 - Unidirectional Link Loss</t>
	<t>16 - Unidirectional Residual Bandwidth</t>
	<t>17 - Unidirectional Available Bandwidth</t>
	<t>18 - Unidirectional Utilized Bandwidth</t>
	<t>19 - Administrative Group</t>
	<t>20 - Extended Administrative Group</t>
	<t>22 - TE Metric</t>
	<t>23 - Maximum Link Bandwidth</t>
	</list></t>


	</section>	<dt>17:</dt><dd> Unidirectional Residual Bandwidth</dd>


	<section anchor="OSPFV3IANA" title="OSPFv3">	<dt>18:</dt><dd> Unidirectional Available Bandwidth</dd>


	<t>The OSPFv3 Extended-LSA Sub-TLV Registry <xref target="RFC8362"/> defines	<dt>19:</dt><dd> Unidirectional Utilized Bandwidth</dd>
	sub-TLVs
	at any level of nesting for OSPFv3 Extended LSAs. IANA has assigned the follo
	wing
	Sub-TLV types from the OSPFv3 Extended-LSA Sub-TLV Registry:
	<list style="hanging">
	<t>11 - Application-Specific Link Attributes</t>
	<t>12 - Shared Risk Link Group</t>
	<t>13 - Unidirectional Link Delay</t>
	<t>14 - Min/Max Unidirectional Link Delay</t>
	<t>15 - Unidirectional Delay Variation</t>
	<t>16 - Unidirectional Link Loss</t>
	<t>17 - Unidirectional Residual Bandwidth</t>
	<t>18 - Unidirectional Available Bandwidth</t>
	<t>19 - Unidirectional Utilized Bandwidth</t>
	<t>20 - Administrative Group</t>
	<t>21 - Extended Administrative Group</t>
	<t>22 - TE Metric</t>
	<t>23 - Maximum Link Bandwidth</t>
	<t>24 - Local Interface IPv6 Address Sub-TLV</t>
	<t>25 - Remote Interface IPv6 Address Sub-TLV</t>


	</list></t>	<dt>20:</dt><dd> Administrative Group</dd>

		<dt>21:</dt><dd> Extended Administrative Group</dd>

		<dt>22:</dt><dd> TE Metric</dd>


		<dt>23:</dt><dd> Maximum link bandwidth</dd>

		<dt>24:</dt><dd> Local Interface IPv6 Address</dd>

		<dt>25:</dt><dd> Remote Interface IPv6 Address</dd>
		</dl>
		</section>
	</section>	</section>

		</middle>
		<back>


	</section>	<displayreference target="I-D.ietf-spring-segment-routing-policy" to="SEGMENT-RO UTING"/>


	<section anchor="CONTR" title="Contributors">	<references>
		<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2328.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3630.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4203.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5340.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7471.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7684.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7308.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5329.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8362.xml"/>


	<t>The following people contributed to the content	<reference anchor='RFC8919'>
	of this document and should be considered as co-authors:</t>	<front>
		<title>IS-IS Application-Specific Link Attributes</title>


	<t><figure>	<author initials='L' surname='Ginsberg' fullname='Les Ginsberg'>
	<artwork><![CDATA[	<organization />
		</author>


	Acee Lindem	<author initials='P' surname='Psenak' fullname='Peter Psenak'>
	Cisco Systems	<organization />
	301 Midenhall Way	</author>
	Cary, NC 27513
	USA


	Email: acee@cisco.com	<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
		<organization />
		</author>


	Ketan Talaulikar	<author initials='W' surname='Henderickx' fullname='Wim Henderickx'>
	Cisco Systems, Inc.	<organization />
	India	</author>


	Email: ketant@cisco.com	<author initials='J' surname='Drake' fullname='John Drake'>
		<organization />
		</author>


	Hannes Gredler	<date month='September' year='2020' />
	RtBrick Inc.	</front>
	Austria	<seriesInfo name="RFC" value="8919"/>
		<seriesInfo name="DOI" value="10.17487/RFC8919"/>
		</reference>


	Email: hannes@rtbrick.com	</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.3209.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4552.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5709.xml"/>
		<xi:include
		href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5286.x
		ml"/>


	]]></artwork>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</figure></t>	FC.8126.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5714.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7166.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7474.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7855.xml"/>


	</section>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
		.ietf-spring-segment-routing-policy.xml"/>
		</references>
		</references>


	<section title="Acknowledgments">	<section numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t>Thanks to <contact fullname="Chris Bowers"/> for his review and comment
		s.</t>
		<t>Thanks to <contact fullname="Alvaro Retana"/> for his detailed review a
		nd comments.</t>
		</section>


	<t>Thanks to Chris Bowers for his review and comments.</t>	<section anchor="CONTR" numbered="false" toc="default">
		<name>Contributors</name>
		<t>The following people contributed to the content
		of this document and should be considered as coauthors:</t>


	<t>Thanks to Alvaro Retana for his detailed review and comments.</t>	<contact fullname="Acee Lindem">
	</section>	<organization>Cisco Systems</organization>
		<address>
		<postal>
		<street>301 Midenhall Way</street>
		<city>Cary</city>
		<region>NC</region><code>27513</code>
		<country>United States of America</country>
		</postal>


	</middle>	<email>acee@cisco.com</email>
		</address>
		</contact>


	<back>	<contact fullname="Ketan Talaulikar">
	<references title="Normative References">	<organization>Cisco Systems, Inc. </organization>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<address>
	FC.2119.xml"?>	<postal>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<country>India</country>
	FC.2328.xml"?>	</postal>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.3630.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.4203.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.5340.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.7471.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.7684.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.7308.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.5329.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.8174.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.8362.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.
	I-D.ietf-isis-te-app.xml"?>
	</references>


	<references title="Informative References">	<email>ketant@cisco.com</email>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	</address>
	FC.3209.xml"?>	</contact>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.4552.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.5709.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.5286.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.5226.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.5714.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.7166.xml"?>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.7474.xml"?>
	<?rfc include="reference.I-D.ietf-spring-segment-routing-policy.xml"?>
	</references>
	</back>


		<contact fullname="Hannes Gredler">
		<organization>RtBrick Inc.</organization>
		<address>
		<postal>
		<country>Austria</country>
		</postal>
		<email>hannes@rtbrick.com</email>
		</address>
		</contact>

		</section>

		</back>
	</rfc>	</rfc>

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