Diff: rfc9350xml2.original.xml

	rfc9350xml2.original.xml	rfc9350.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>	nsus="true" docName="draft-ietf-lsr-flex-algo-26" indexInclude="true" ipr="trust
	<?rfc toc="yes" ?>	200902" number="9350" prepTime="2023-02-21T15:23:01" scripts="Common,Latin" sort
	<?rfc symrefs="yes" ?>	Refs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true"
	<?rfc sortrefs="yes"?>	xml:lang="en">
	<?rfc iprnotified="no" ?>	<link href="https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-26" rel=
	<?rfc strict="yes" ?>	"prev"/>
	<?rfc compact='yes'?>	<link href="https://dx.doi.org/10.17487/rfc9350" rel="alternate"/>
	<?rfc subcompact='no'?>	<link href="urn:issn:2070-1721" rel="alternate"/>
	<rfc category="std" docName="draft-ietf-lsr-flex-algo-26" ipr="trust200902">
	<front>	<front>
	<title abbrev="IGP Flexible Algorithm">IGP Flexible Algorithm</title>	<title abbrev="IGP Flexible Algorithm">IGP Flexible Algorithm</title>

		<seriesInfo name="RFC" value="9350" stream="IETF"/>
	<author fullname="Peter Psenak" initials="P." role="editor"	<author fullname="Peter Psenak" initials="P." role="editor" surname="Psenak"
	surname="Psenak">	>
	<organization>Cisco Systems, Inc.</organization>	<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>

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

	<street>Apollo Business Center</street>	<extaddr>Apollo Business Center</extaddr>

	<street>Mlynske nivy 43</street>	<street>Mlynske nivy 43</street>


	<city>Bratislava</city>	<city>Bratislava</city>

		<code>82109</code>
	<region>82109</region>

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


	<code/>	<code/>
	</postal>	</postal>


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


	<author fullname="Shraddha Hegde" initials="S" surname="Hegde">	<author fullname="Shraddha Hegde" initials="S" surname="Hegde">

	<organization>Juniper Networks, Inc.</organization>	<organization showOnFrontPage="true">Juniper Networks, Inc.</organization>

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

	<street>Embassy Business Park</street>	<extaddr>Embassy Business Park</extaddr>

	<street/>	<street/>

		<city>Bangalore</city>
	<city>Bangalore, KA</city>	<region>KA</region>
		<code>560093</code>
	<region>560093</region>

	<country>India</country>	<country>India</country>


	<code/>	<code/>
	</postal>	</postal>


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


	<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">	<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">

	<organization>Cisco Systems, Inc.</organization>	<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>

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


	<city>Brussels</city>	<city>Brussels</city>


	<region/>	<region/>


	<code/>	<code/>


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


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


	<author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar">	<author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar">

	<organization>Cisco Systems, Inc</organization>	<organization showOnFrontPage="true">Cisco Systems, Inc</organization>

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

	<street></street>	<street/>
		<city/>
	<city></city>	<code/>

	<code></code>

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


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


	<author fullname="Arkadiy Gulko" initials="A." surname="Gulko">	<author fullname="Arkadiy Gulko" initials="A." surname="Gulko">

	<organization>Edward Jones</organization>	<organization showOnFrontPage="true">Edward Jones</organization>

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


	<city/>	<city/>


	<region/>	<region/>


	<code/>	<code/>


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


	<email>arkadiy.gulko@edwardjones.com</email>	<email>arkadiy.gulko@edwardjones.com</email>
	</address>	</address>
	</author>	</author>

		<date month="02" year="2023"/>
	<date/>	<area>rtg</area>
		<workgroup>lsr</workgroup>
	<abstract>	<abstract pn="section-abstract">
	<t>IGP protocols historically compute best paths over the network based	<t indent="0" pn="section-abstract-1">IGP protocols historically compute t
		he best paths over the network based
	on the IGP metric assigned to the links. Many network deployments use	on the IGP metric assigned to the links. Many network deployments use

	RSVP-TE based or Segment Routing based Traffic Engineering to steer	RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer
	traffic over a path that is computed using different metrics or	traffic over a path that is computed using different metrics or
	constraints than the shortest IGP path. This document specifies a	constraints than the shortest IGP path. This document specifies a
	solution that allows IGPs themselves to compute constraint-based paths	solution that allows IGPs themselves to compute constraint-based paths
	over the network. This document also specifies a way of using Segment	over the network. This document also specifies a way of using Segment
	Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the	Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the
	constraint-based paths.</t>	constraint-based paths.</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/rfc9350" 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) 2023 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 Revised BSD License text as described in
		Section 4.e of the Trust Legal Provisions and are provided without
		warranty as described in the Revised 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>
		</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-l
		anguage">Requirements Language</xref></t>
		</li>
		<li pn="section-toc.1-1.3">
		<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
		ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref
		derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
		erminology</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-flexible-algorithm">Flexible Algor
		ithm</xref></t>
		</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-flexible-algorithm-definiti">Flexi
		ble Algorithm Definition Advertisement</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.5.2">
		<li pn="section-toc.1-1.5.2.1">
		<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
		"5.1" format="counter" sectionFormat="of" target="section-5.1"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-is-is-flexible-algorit
		hm-de">IS-IS Flexible Algorithm Definition Sub-TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.5.2.2">
		<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
		"5.2" format="counter" sectionFormat="of" target="section-5.2"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-ospf-flexible-algorith
		m-def">OSPF Flexible Algorithm Definition TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.5.2.3">
		<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
		"5.3" format="counter" sectionFormat="of" target="section-5.3"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-common-handling-of-the
		-flex">Common Handling of the Flexible Algorithm Definition TLV</xref></t>
		</li>
		</ul>
		</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-sub-tlvs-of-is-is-fad-sub-t">Sub-T
		LVs of IS-IS FAD Sub-TLV</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-is-is-flexible-algorit
		hm-ex">IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV</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-is-is-flexible-algorit
		hm-in">IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV</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-is-is-flexible-algorit
		hm-inc">IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV</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-is-is-flexible-algorit
		hm-def">IS-IS Flexible Algorithm Definition Flags Sub-TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.6.2.5">
		<t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent=
		"6.5" format="counter" sectionFormat="of" target="section-6.5"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-is-is-flexible-algorit
		hm-exc">IS-IS Flexible Algorithm Exclude SRLG Sub-TLV</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-sub-tlvs-of-the-ospf-fad-tl">Sub-T
		LVs of the OSPF FAD TLV</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.7.2">
		<li pn="section-toc.1-1.7.2.1">
		<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
		"7.1" format="counter" sectionFormat="of" target="section-7.1"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-ospf-flexible-algorith
		m-exc">OSPF Flexible Algorithm Exclude Admin Group Sub-TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.7.2.2">
		<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
		"7.2" format="counter" sectionFormat="of" target="section-7.2"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-ospf-flexible-algorith
		m-inc">OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.7.2.3">
		<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
		"7.3" format="counter" sectionFormat="of" target="section-7.3"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-ospf-flexible-algorith
		m-incl">OSPF Flexible Algorithm Include-All Admin Group Sub-TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.7.2.4">
		<t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent=
		"7.4" format="counter" sectionFormat="of" target="section-7.4"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-ospf-flexible-algorith
		m-defi">OSPF Flexible Algorithm Definition Flags Sub-TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.7.2.5">
		<t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent=
		"7.5" format="counter" sectionFormat="of" target="section-7.5"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-ospf-flexible-algorith
		m-excl">OSPF Flexible Algorithm Exclude SRLG Sub-TLV</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.8">
		<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
		at="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-is-is-flexible-algorithm-pr">IS-IS
		Flexible Algorithm Prefix Metric Sub-TLV</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-ospf-flexible-algorithm-pre">OSPF
		Flexible Algorithm Prefix Metric 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-ospf-flexible-algorithm-asb">OSP
		F Flexible Algorithm ASBR Reachability Advertisement</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.10.2">
		<li pn="section-toc.1-1.10.2.1">
		<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent
		="10.1" format="counter" sectionFormat="of" target="section-10.1"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-ospfv2-extended-int
		er-area-">OSPFv2 Extended Inter-Area ASBR LSA</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-toc.1-1.10.2.1.2">
		<li pn="section-toc.1-1.10.2.1.2.1">
		<t indent="0" pn="section-toc.1-1.10.2.1.2.1.1"><xref derive
		dContent="10.1.1" format="counter" sectionFormat="of" target="section-10.1.1"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-ospfv2-
		extended-inter-area-a">OSPFv2 Extended Inter-Area ASBR TLV</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.10.2.2">
		<t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent
		="10.2" format="counter" sectionFormat="of" target="section-10.2"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-ospf-flexible-algor
		ithm-asbr">OSPF Flexible Algorithm ASBR Metric Sub-TLV</xref></t>
		</li>
		</ul>
		</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-advertisement-of-node-parti">Adv
		ertisement of Node Participation in a Flex-Algorithm</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.11.2">
		<li pn="section-toc.1-1.11.2.1">
		<t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent
		="11.1" format="counter" sectionFormat="of" target="section-11.1"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-advertisement-of-no
		de-partic">Advertisement of Node Participation for Segment Routing</xref></t>
		</li>
		<li pn="section-toc.1-1.11.2.2">
		<t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent
		="11.2" format="counter" sectionFormat="of" target="section-11.2"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-advertisement-of-no
		de-partici">Advertisement of Node Participation for Other Data Planes</xref></t>
		</li>
		</ul>
		</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-advertisement-of-link-attri">Adv
		ertisement of Link Attributes for Flex-Algorithm</xref></t>
		</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-calculation-of-flexible-alg">Cal
		culation of Flexible Algorithm Paths</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.13.2">
		<li pn="section-toc.1-1.13.2.1">
		<t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent
		="13.1" format="counter" sectionFormat="of" target="section-13.1"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-multi-area-and-mult
		i-domain">Multi-area and Multi-domain Considerations</xref></t>
		</li>
		</ul>
		</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-flex-algorithm-and-forwardi">Fle
		x-Algorithm and Forwarding Plane</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-segment-routing-mpl
		s-forwar">Segment Routing MPLS Forwarding for Flex-Algorithm</xref></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-srv6-forwarding-for
		-flex-al">SRv6 Forwarding for Flex-Algorithm</xref></t>
		</li>
		<li pn="section-toc.1-1.14.2.3">
		<t indent="0" pn="section-toc.1-1.14.2.3.1"><xref derivedContent
		="14.3" format="counter" sectionFormat="of" target="section-14.3"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-other-data-planes-f
		orwardin">Other Data Planes' Forwarding for Flex-Algorithm</xref></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-15"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-operational-considerations">Oper
		ational Considerations</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-15.1"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-inter-area-consider
		ations">Inter-area Considerations</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-15.2"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-usage-of-the-srlg-e
		xclude-r">Usage of the SRLG Exclude Rule with Flex-Algorithm</xref></t>
		</li>
		<li pn="section-toc.1-1.15.2.3">
		<t indent="0" pn="section-toc.1-1.15.2.3.1"><xref derivedContent
		="15.3" format="counter" sectionFormat="of" target="section-15.3"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-max-metric-consider
		ation">Max-Metric Consideration</xref></t>
		</li>
		<li pn="section-toc.1-1.15.2.4">
		<t indent="0" pn="section-toc.1-1.15.2.4.1"><xref derivedContent
		="15.4" format="counter" sectionFormat="of" target="section-15.4"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-flexible-algorithm-
		definitio">Flexible Algorithm Definition and Changes</xref></t>
		</li>
		<li pn="section-toc.1-1.15.2.5">
		<t indent="0" pn="section-toc.1-1.15.2.5.1"><xref derivedContent
		="15.5" format="counter" sectionFormat="of" target="section-15.5"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-number-of-flex-algo
		rithms">Number of Flex-Algorithms</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.16">
		<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="16" fo
		rmat="counter" sectionFormat="of" target="section-16"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-backward-compatibility">Backward
		Compatibility</xref></t>
		</li>
		<li pn="section-toc.1-1.17">
		<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="17" fo
		rmat="counter" sectionFormat="of" target="section-17"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-security-considerations">Securit
		y Considerations</xref></t>
		</li>
		<li pn="section-toc.1-1.18">
		<t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="18" fo
		rmat="counter" sectionFormat="of" target="section-18"/>. <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.18.2">
		<li pn="section-toc.1-1.18.2.1">
		<t indent="0" pn="section-toc.1-1.18.2.1.1"><xref derivedContent
		="18.1" format="counter" sectionFormat="of" target="section-18.1"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-igp-iana-considerat
		ions">IGP IANA Considerations</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-toc.1-1.18.2.1.2">
		<li pn="section-toc.1-1.18.2.1.2.1">
		<t indent="0" pn="section-toc.1-1.18.2.1.2.1.1"><xref derive
		dContent="18.1.1" format="counter" sectionFormat="of" target="section-18.1.1"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-igp-alg
		orithm-types-registr">IGP Algorithm Types Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.18.2.1.2.2">
		<t indent="0" pn="section-toc.1-1.18.2.1.2.2.1"><xref derive
		dContent="18.1.2" format="counter" sectionFormat="of" target="section-18.1.2"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-igp-met
		ric-type-registry">IGP Metric-Type Registry</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.18.2.2">
		<t indent="0" pn="section-toc.1-1.18.2.2.1"><xref derivedContent
		="18.2" format="counter" sectionFormat="of" target="section-18.2"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-igp-flexible-algori
		thm-defi">IGP Flexible Algorithm Definition Flags Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.18.2.3">
		<t indent="0" pn="section-toc.1-1.18.2.3.1"><xref derivedContent
		="18.3" format="counter" sectionFormat="of" target="section-18.3"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-is-is-iana-consider
		ations">IS-IS IANA Considerations</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-toc.1-1.18.2.3.2">
		<li pn="section-toc.1-1.18.2.3.2.1">
		<t indent="0" pn="section-toc.1-1.18.2.3.2.1.1"><xref derive
		dContent="18.3.1" format="counter" sectionFormat="of" target="section-18.3.1"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-is-is-s
		ub-tlvs-for-is-is-ro">IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV Registry</x
		ref></t>
		</li>
		<li pn="section-toc.1-1.18.2.3.2.2">
		<t indent="0" pn="section-toc.1-1.18.2.3.2.2.1"><xref derive
		dContent="18.3.2" format="counter" sectionFormat="of" target="section-18.3.2"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-is-is-s
		ub-tlvs-for-tlvs-adv">IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability Re
		gistry</xref></t>
		</li>
		<li pn="section-toc.1-1.18.2.3.2.3">
		<t indent="0" pn="section-toc.1-1.18.2.3.2.3.1"><xref derive
		dContent="18.3.3" format="counter" sectionFormat="of" target="section-18.3.3"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-is-is-s
		ub-sub-tlvs-for-flex">IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-T
		LV Registry</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.18.2.4">
		<t indent="0" pn="section-toc.1-1.18.2.4.1"><xref derivedContent
		="18.4" format="counter" sectionFormat="of" target="section-18.4"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-ospf-iana-considera
		tions">OSPF IANA Considerations</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-toc.1-1.18.2.4.2">
		<li pn="section-toc.1-1.18.2.4.2.1">
		<t indent="0" pn="section-toc.1-1.18.2.4.2.1.1"><xref derive
		dContent="18.4.1" format="counter" sectionFormat="of" target="section-18.4.1"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-ospf-ro
		uter-information-ri-">OSPF Router Information (RI) TLVs Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.18.2.4.2.2">
		<t indent="0" pn="section-toc.1-1.18.2.4.2.2.1"><xref derive
		dContent="18.4.2" format="counter" sectionFormat="of" target="section-18.4.2"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-ospfv2-
		extended-prefix-tlv-">OSPFv2 Extended Prefix TLV Sub-TLVs Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.18.2.4.2.3">
		<t indent="0" pn="section-toc.1-1.18.2.4.2.3.1"><xref derive
		dContent="18.4.3" format="counter" sectionFormat="of" target="section-18.4.3"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-ospfv3-
		extended-lsa-sub-tlv">OSPFv3 Extended-LSA Sub-TLVs Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.18.2.4.2.4">
		<t indent="0" pn="section-toc.1-1.18.2.4.2.4.1"><xref derive
		dContent="18.4.4" format="counter" sectionFormat="of" target="section-18.4.4"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-ospf-fl
		ex-algorithm-prefix-">OSPF Flex-Algorithm Prefix Metric Bits Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.18.2.4.2.5">
		<t indent="0" pn="section-toc.1-1.18.2.4.2.5.1"><xref derive
		dContent="18.4.5" format="counter" sectionFormat="of" target="section-18.4.5"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-opaque-
		link-state-advertise">Opaque Link-State Advertisements (LSA) Option Types Regist
		ry</xref></t>
		</li>
		<li pn="section-toc.1-1.18.2.4.2.6">
		<t indent="0" pn="section-toc.1-1.18.2.4.2.6.1"><xref derive
		dContent="18.4.6" format="counter" sectionFormat="of" target="section-18.4.6"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-ospfv2-
		extended-inter-area-as">OSPFv2 Extended Inter-Area ASBR TLVs Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.18.2.4.2.7">
		<t indent="0" pn="section-toc.1-1.18.2.4.2.7.1"><xref derive
		dContent="18.4.7" format="counter" sectionFormat="of" target="section-18.4.7"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-ospfv2-
		extended-inter-area-asbr">OSPFv2 Extended Inter-Area ASBR Sub-TLVs Registry</xre
		f></t>
		</li>
		<li pn="section-toc.1-1.18.2.4.2.8">
		<t indent="0" pn="section-toc.1-1.18.2.4.2.8.1"><xref derive
		dContent="18.4.8" format="counter" sectionFormat="of" target="section-18.4.8"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-ospf-fl
		exible-algorithm-defin">OSPF Flexible Algorithm Definition TLV Sub-TLVs Registry
		</xref></t>
		</li>
		<li pn="section-toc.1-1.18.2.4.2.9">
		<t indent="0" pn="section-toc.1-1.18.2.4.2.9.1"><xref derive
		dContent="18.4.9" format="counter" sectionFormat="of" target="section-18.4.9"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-link-at
		tribute-application-">Link Attribute Application Identifiers Registry</xref></t>
		</li>
		</ul>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.19">
		<t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent="19" fo
		rmat="counter" sectionFormat="of" target="section-19"/>. <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.19.2">
		<li pn="section-toc.1-1.19.2.1">
		<t indent="0" pn="section-toc.1-1.19.2.1.1"><xref derivedContent
		="19.1" format="counter" sectionFormat="of" target="section-19.1"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-normative-reference
		s">Normative References</xref></t>
		</li>
		<li pn="section-toc.1-1.19.2.2">
		<t indent="0" pn="section-toc.1-1.19.2.2.1"><xref derivedContent
		="19.2" format="counter" sectionFormat="of" target="section-19.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.20">
		<t indent="0" pn="section-toc.1-1.20.1"><xref derivedContent="" form
		at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
		" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
		nts</xref></t>
		</li>
		<li pn="section-toc.1-1.21">
		<t indent="0" pn="section-toc.1-1.21.1"><xref derivedContent="" form
		at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
		" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
		resses</xref></t>
		</li>
		</ul>
		</section>
		</toc>
	</front>	</front>


	<middle>	<middle>

	<section title="Introduction">	<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
	<t>An IGP-computed path based on the shortest IGP metric is often	<name slugifiedName="name-introduction">Introduction</name>
		<t indent="0" pn="section-1-1">An IGP-computed path based on the shortest
		IGP metric is often
	replaced by a traffic-engineered path due to requirements	replaced by a traffic-engineered path due to requirements

	which are not reflected by the IGP metric. Some networks engineer the	that are not reflected by the IGP metric. Some networks engineer the
	IGP metric assignments in a way that the IGP metric reflects the link	IGP metric assignments in a way that the IGP metric reflects the link
	bandwidth or delay. If, for example, the IGP metric reflects the	bandwidth or delay. If, for example, the IGP metric reflects the
	bandwidth on the link and user traffic is delay sensitive,	bandwidth on the link and user traffic is delay sensitive,
	the best IGP path may not reflect the best path from such a user's perspec tive.</t>	the best IGP path may not reflect the best path from such a user's perspec tive.</t>

		<t indent="0" pn="section-1-2">To overcome this limitation, various sorts
	<t>To overcome this limitation, various sorts of traffic engineering	of Traffic Engineering
	have been deployed, including RSVP-TE and SR-TE, in which case the TE	have been deployed, including RSVP-TE and SR-TE, in which case the TE
	component is responsible for computing paths based on additional metrics	component is responsible for computing paths based on additional metrics
	and/or constraints. Such paths need to be installed in the forwarding	and/or constraints. Such paths need to be installed in the forwarding
	tables in addition to, or as a replacement for, the original paths	tables in addition to, or as a replacement for, the original paths
	computed by IGPs. Tunnels are often used to represent the engineered	computed by IGPs. Tunnels are often used to represent the engineered

	paths and mechanisms like the one described in <xref target="RFC3906"/> ar e	paths and mechanisms, like the one described in <xref target="RFC3906" for mat="default" sectionFormat="of" derivedContent="RFC3906"/>, and are
	used to replace the original IGP paths with such tunnel paths.</t>	used to replace the original IGP paths with such tunnel paths.</t>

		<t indent="0" pn="section-1-3">This document specifies a set of extensions
	<t>This document specifies a set of extensions to IS-IS, OSPFv2, and	to IS-IS, OSPFv2, and
	OSPFv3 that enable a router to advertise TLVs that (a) identify	OSPFv3 that enable a router to advertise TLVs that (a) identify a
	calculation-type, (b) specify a metric-type, and (c) describe a set of	calculation-type, (b) specify a metric-type, and (c) describe a set of

	constraints on the topology, that are to be used to compute the best	constraints on the topology that are to be used to compute the best
	paths along the constrained topology. A given combination of	paths along the constrained topology. A given combination of
	calculation-type, metric-type, and constraints is known as a "Flexible	calculation-type, metric-type, and constraints is known as a "Flexible
	Algorithm Definition". A router that sends such a set of TLVs also	Algorithm Definition". A router that sends such a set of TLVs also
	assigns a Flex-Algorithm value to the specified combination of	assigns a Flex-Algorithm value to the specified combination of
	calculation-type, metric-type, and constraints.</t>	calculation-type, metric-type, and constraints.</t>

		<t indent="0" pn="section-1-4">This document also specifies a way for a ro
	<t>This document also specifies a way for a router to use IGPs to	uter to use IGPs to
	associate one or more "Segment Routing with the MPLS Data Plane (SR-MPLS)	associate one or more Segment Routing with the MPLS Data Plane (SR-MPLS)
	"	Prefix-SIDs <xref target="RFC8660" format="default" sectionFormat="of" der
	Prefix-SIDs <xref target="RFC8660"/>, or "Segment Routing over IPv6 (SRv6)	ivedContent="RFC8660"/> or Segment Routing over IPv6 (SRv6)
	"	locators <xref target="RFC8986" format="default" sectionFormat="of" derive
	locators <xref target="RFC8986"/> with a particular Flex-Algorithm. Each	dContent="RFC8986"/> with a particular Flex-Algorithm. Each
	such Prefix-SID or SRv6 locator then represents a path that is computed	such Prefix-SID or SRv6 locator then represents a path that is computed

	according to the identified Flex-Algorithm. In SRv6 it is the locator, not the SID,	according to the identified Flex-Algorithm. In SRv6, it is the locator, no t the Segment Identifier (SID),
	that holds the binding to the algorithm.</t>	that holds the binding to the algorithm.</t>


	</section>	</section>

		<section anchor="reqlang" numbered="true" toc="include" removeInRFC="false"
	<section anchor="reqlang" title="Requirements Language">	pn="section-2">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	<name slugifiedName="name-requirements-language">Requirements Language</na
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	me>
	"OPTIONAL" in this document are to be interpreted as described in BCP 14	<t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp1
	<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,	4>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>
		SHALL NOT</bcp14>",
		"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED<
		/bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
		"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as descri
		bed in BCP 14
		<xref target="RFC2119" format="default" sectionFormat="of" derivedContent=
		"RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedCo
		ntent="RFC8174"/> when, and only when,
	they appear in all capitals, as shown here.</t>	they appear in all capitals, as shown here.</t>
	</section>	</section>

		<section anchor="TERMINOLOGY" numbered="true" toc="include" removeInRFC="fal
	<section anchor="TERMINOLOGY" title="Terminology">	se" pn="section-3">
	<t>This section defines terms that are often used in this document.</t>	<name slugifiedName="name-terminology">Terminology</name>
		<t indent="0" pn="section-3-1">This section defines terms that are often u
	<t>Flexible Algorithm Definition (FAD) - the set consisting of (a)	sed in this document.</t>
	calculation-type, (b) metric-type, and (c) a set of constraints.</t>	<dl newline="false" spacing="normal" indent="3" pn="section-3-2">
		<dt pn="section-3-2.1">Flexible Algorithm Definition (FAD):</dt>
	<t>Flex-Algorithm - a numeric identifier in the range 128-255 that	<dd pn="section-3-2.2">the set consisting of (a) a
	is associated via configuration with the Flexible Algorithm	calculation-type, (b) a metric-type, and (c) a set of constraints.</dd>
	Definition.</t>	<dt pn="section-3-2.3">Flex-Algorithm:</dt>
		<dd pn="section-3-2.4">a numeric identifier in the range 128-255 that
	<t>Local Flexible Algorithm Definition - Flexible Algorithm Definition	is associated via configuration with the Flexible Algorithm
	defined locally on the node.</t>	Definition.</dd>
		<dt pn="section-3-2.5">Flexible Algorithm Participation:</dt>
	<t>Remote Flexible Algorithm Definition - Flexible Algorithm Definition	<dd pn="section-3-2.6">per the data plane configuration
	received from other nodes via IGP flooding.</t>	state that expresses whether the node is participating in a particular
		Flexible Algorithm. Not all routers in a given network need to participat
	<t>Flexible Algorithm Participation - per data-plane configuration	e
	state that expresses whether the node is participating in a particular	in a given Flexible Algorithm. The Flexible Algorithm(s) that a given rou
	Flexible Algorithm. Not all routers in a given network need to participate	ter
	in a given Flexible Algorithm. The Flexible Algorithm(s) a given router	participates in is determined by configuration.</dd>
	participates in is determined by configuration.</t>	<dt pn="section-3-2.7">IGP Algorithm:</dt>
		<dd pn="section-3-2.8">value from the IANA "IGP Algorithm Types" registr
	<t>IGP Algorithm - value from the "IGP Algorithm Types" registry	y
	defined under "Interior Gateway Protocol (IGP) Parameters" IANA	defined under the "Interior Gateway Protocol (IGP) Parameters"
	registry grouping. IGP Algorithms represents the triplet (calculation-type	registry group. IGP Algorithms represent the triplet (calculation-type,
	,	metric-type, and constraints), where the second and third elements of the
	metric-type, constraints), where the second and third elements of the trip	triplet
	le	<bcp14>MAY</bcp14> be unspecified.</dd>
	MAY be unspecified.</t>	<dt pn="section-3-2.9">ABR:</dt>
		<dd pn="section-3-2.10">Area Border Router. In IS-IS terminology, it is
	<t>ABR - Area Border Router. In IS-IS terminology it is also known as	also known as the
	L1/L2 router.</t>	Level 1 (L1) / Level 2 (L2) router.</dd>
		<dt pn="section-3-2.11">ASBR:</dt>
	<t>ASBR - Autonomous System Border Router.</t>	<dd pn="section-3-2.12">Autonomous System Border Router.</dd>
		</dl>
	</section>	</section>

		<section anchor="FLEXALG" numbered="true" toc="include" removeInRFC="false"
	<section anchor="FLEXALG" title="Flexible Algorithm">	pn="section-4">
	<t>Many possible constraints may be used to compute a path over a	<name slugifiedName="name-flexible-algorithm">Flexible Algorithm</name>
		<t indent="0" pn="section-4-1">Many possible constraints may be used to co
		mpute a path over a
	network. Some networks are deployed as multiple planes. A simple form of	network. Some networks are deployed as multiple planes. A simple form of
	constraint may be to use a particular plane. A more sophisticated form	constraint may be to use a particular plane. A more sophisticated form

	of constraint can include some extended metric as described in <xref	of constraint can include some extended metric, as described in <xref targ
	target="RFC8570"/>. Constraints which restrict paths to links with	et="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>. Con
		straints that restrict paths to links with
	specific affinities or avoid links with specific affinities are also	specific affinities or avoid links with specific affinities are also
	possible. Combinations of these are also possible.</t>	possible. Combinations of these are also possible.</t>

		<t indent="0" pn="section-4-2">To provide maximum flexibility, a mechanism
	<t>To provide maximum flexibility, a mechanism is provided that	is provided that
	allows a router to (a) identify a particular calculation-type and (b)	allows a router to identify a particular calculation-type and
	metric-type, (c) describe a particular set of constraints, and (d)	metric-type, describe a particular set of constraints, and
	assign a numeric identifier, referred to as Flex-Algorithm, to the	assign a numeric identifier, referred to as Flex-Algorithm, to the
	combination of that calculation-type, metric-type, and those	combination of that calculation-type, metric-type, and those
	constraints. The mapping between the Flex-Algorithm and its	constraints. The mapping between the Flex-Algorithm and its
	meaning is flexible and defined by the user. As long as all routers	meaning is flexible and defined by the user. As long as all routers
	in the domain have a common understanding as to what a particular	in the domain have a common understanding as to what a particular
	Flex-Algorithm represents, the resulting routing computation is	Flex-Algorithm represents, the resulting routing computation is
	consistent and traffic is not subject to any looping.</t>	consistent and traffic is not subject to any looping.</t>

		<t indent="0" pn="section-4-3">The set consisting of (a) a calculation-typ
	<t>The set consisting of (a) calculation-type, (b) metric-type, and (c)	e, (b) a metric-type, and (c)
	a set of constraints is referred to as a Flexible Algorithm	a set of constraints is referred to as a Flexible Algorithm
	Definition.</t>	Definition.</t>

		<t indent="0" pn="section-4-4">The Flex-Algorithm is a numeric identifier
	<t>Flex-Algorithm is a numeric identifier in the range 128-255 that	in the range 128-255 that
	is associated via configuration with the Flexible Algorithm	is associated via configuration with the Flexible Algorithm
	Definition.</t>	Definition.</t>

		<t indent="0" pn="section-4-5">The IANA "IGP Algorithm Types" registry def
	<t>The IANA "IGP Algorithm Types" registry defines the set of values for I	ines the set of values for IGP
	GP	Algorithms. The following values are allocated by IANA from this registry
	Algorithms. The following values area allocated by IANA from this registry	for
	for	Flex-Algorithms: </t>
	Flex-Algorithms: <list style="hanging">	<t indent="3" pn="section-4-6">128-255 - Flex-Algorithms</t>
	<t>128-255 - Flex-Algorithms</t>
	</list></t>
	</section>	</section>

		<section anchor="FLEXALGDEF" numbered="true" toc="include" removeInRFC="fals
	<section anchor="FLEXALGDEF"	e" pn="section-5">
	title="Flexible Algorithm Definition Advertisement">	<name slugifiedName="name-flexible-algorithm-definiti">Flexible Algorithm
	<t>To guarantee loop-free forwarding for paths computed for a	Definition Advertisement</name>
		<t indent="0" pn="section-5-1">To guarantee loop-free forwarding for paths
		computed for a
	particular Flex-Algorithm, all routers that (a) are configured to	particular Flex-Algorithm, all routers that (a) are configured to

	participate in a particular Flex-Algorithm, and (b) are in the same	participate in a particular Flex-Algorithm and (b) are in the same
	Flex-Algorithm definition advertisement scope MUST agree on the	Flex-Algorithm Definition advertisement scope <bcp14>MUST</bcp14> agree on
		the
	definition of the Flex-Algorithm. The following procedures	definition of the Flex-Algorithm. The following procedures
	ensure this condition is fulfilled.</t>	ensure this condition is fulfilled.</t>

		<section anchor="ISISFLEXALGTLV" numbered="true" toc="include" removeInRFC
	<section anchor="ISISFLEXALGTLV"	="false" pn="section-5.1">
	title="IS-IS Flexible Algorithm Definition Sub-TLV">	<name slugifiedName="name-is-is-flexible-algorithm-de">IS-IS Flexible Al
	<t>The IS-IS Flexible Algorithm Definition Sub-TLV (FAD Sub-TLV) is	gorithm Definition Sub-TLV</name>
		<t indent="0" pn="section-5.1-1">The IS-IS Flexible Algorithm Definition
		(FAD) sub-TLV is
	used to advertise the definition of the Flex-Algorithm.</t>	used to advertise the definition of the Flex-Algorithm.</t>

		<t indent="0" pn="section-5.1-2">The IS-IS FAD sub-TLV is advertised as
	<t>The IS-IS FAD Sub-TLV is advertised as a Sub-TLV of the IS-IS Router	a sub-TLV of the IS-IS Router
	Capability TLV-242 that is defined in <xref target="RFC7981"/>.</t>	CAPABILITY TLV-242, which is defined in <xref target="RFC7981" format="d
		efault" sectionFormat="of" derivedContent="RFC7981"/>.</t>
	<t>IS-IS FAD Sub-TLV has the following format: <figure>	<t indent="0" pn="section-5.1-3">The IS-IS FAD sub-TLV has the following
	<artwork><![CDATA[	format: </t>
		<artwork name="" type="" align="left" alt="" pn="section-5.1-4">
	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 \|Flex-Algorithm \| Metric-Type \|	\| Type \| Length \|Flex-Algorithm \| Metric-Type \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Calc-Type \| Priority \|	\| Calc-Type \| Priority \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Sub-TLVs \|	\| Sub-TLVs \|
	+ +	+ +
	\| ... \|	\| ... \|

	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		</artwork>
	where:	<dl newline="true" spacing="normal" indent="3" pn="section-5.1-5">
	]]></artwork>	<dt pn="section-5.1-5.1">where:</dt>
	</figure> <list style="hanging">	<dd pn="section-5.1-5.2">
	<t>Type: 26</t>	<dl newline="false" spacing="normal" indent="3" pn="section-5.1-5.2.
		1">
	<t>Length: variable number of octets, dependent on the included Sub-	<dt pn="section-5.1-5.2.1.1">Type:</dt>
	TLVs</t>	<dd pn="section-5.1-5.2.1.2">26</dd>
		<dt pn="section-5.1-5.2.1.3">Length:</dt>
	<t>Flex-Algorithm: Flexible Algorithm number. Single octet value bet	<dd pn="section-5.1-5.2.1.4">variable number of octets, dependent
	ween	on the included sub-TLVs.</dd>
	128 and 255 inclusive.</t>	<dt pn="section-5.1-5.2.1.5">Flex-Algorithm:</dt>
		<dd pn="section-5.1-5.2.1.6">Flexible Algorithm number. Single oct
	<t>Metric-Type: Type of metric from the "IGP Metric-Type Registry"	et value between
	(<xref target="IGPMETRICTYPE"/>) to be used during the calculation.	128 and 255 inclusive.</dd>
	The following values are defined: <list style="hanging">	<dt pn="section-5.1-5.2.1.7">Metric-Type:</dt>
	<t>0: IGP Metric</t>	<dd pn="section-5.1-5.2.1.8">
		<t indent="0" pn="section-5.1-5.2.1.8.1">type of metric from the
	<t>1: Min Unidirectional Link Delay as defined in <xref	IANA "IGP Metric-Type" registry
	target="RFC8570"/>, section 4.2, encoded as application	(<xref target="IGPMETRICTYPE" format="default" sectionFormat="of"
	specific link attribute as specified in <xref	derivedContent="Section 18.1.2"/>) to be used during the
	target="RFC8919"/> and <xref target="FLEXALGLINKATTR"/> of	calculation. The following values are defined: </t>
	this document.</t>	<dl newline="false" spacing="normal" indent="3" pn="section-5.1-
		5.2.1.8.2">
	<t>2: Traffic Engineering Default Metric as defined in <xref	<dt pn="section-5.1-5.2.1.8.2.1">0:</dt>
	target="RFC5305"/>, section 3.7, encoded as application	<dd pn="section-5.1-5.2.1.8.2.2">IGP Metric</dd>
	specific link attribute as specified in <xref	<dt pn="section-5.1-5.2.1.8.2.3">1:</dt>
	target="RFC8919"/> and <xref target="FLEXALGLINKATTR"/> of	<dd pn="section-5.1-5.2.1.8.2.4">Min Unidirectional Link Delay
	this document.</t>	, as defined in <xref target="RFC8570" section="4.2" sectionFormat="of" format="
	</list></t>	default" derivedLink="https://rfc-editor.org/rfc/rfc8570#section-4.2" derivedCon
		tent="RFC8570"/>, encoded as an application-specific link attribute, as specifie
	<t>Calc-Type: calculation-type, value from 0 to 127 inclusive from t	d in <xref target="RFC8919" format="default" sectionFormat="of" derivedContent="
	he "IGP	RFC8919"/> and <xref target="FLEXALGLINKATTR" format="default" sectionFormat="of
	Algorithm Types" registry defined under "Interior Gateway Protocol	" derivedContent="Section 12"/> of this document.</dd>
	(IGP) Parameters" IANA registries. IGP algorithms in the range of	<dt pn="section-5.1-5.2.1.8.2.5">2:</dt>
	0-127 have a defined triplet (calculation-type, metric-type,	<dd pn="section-5.1-5.2.1.8.2.6">Traffic Engineering Default M
	constraints). When used to specify the calculation-type in the FAD	etric, as defined in <xref target="RFC5305" section="3.7" sectionFormat="of" for
	Sub-TLV, only the calculation-type defined for the specified IGP	mat="default" derivedLink="https://rfc-editor.org/rfc/rfc5305#section-3.7" deriv
	Algorithm is used. The Metric/Constraints MUST NOT be inherited.	edContent="RFC5305"/>, encoded as an
	If the required calculation-type is Shortest Path First, the value	application-specific link attribute, as specified in <xref targ
	0 MUST appear in this field.</t>	et="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/> and
		<xref target="FLEXALGLINKATTR" format="default" sectionFormat="of" derivedConten
	<t>Priority: Value between 0 and 255 inclusive that specifies the	t="Section 12"/> of this document.</dd>
	priority of the advertisement. Numerically greater values are prefer	</dl>
	red.	</dd>
	Usage fo the priority is described in <xref target="COMMONLEXALGTLV"	<dt pn="section-5.1-5.2.1.9">Calc-Type:</dt>
	/>.</t>	<dd pn="section-5.1-5.2.1.10">calculation-type. Value from 0-127 i
		nclusive from the IANA "IGP
	<t>Sub-TLVs - optional sub-TLVs.</t>	Algorithm Types" registry defined under the "Interior Gateway Prot
	</list></t>	ocol
		(IGP) Parameters" registry. IGP Algorithms in the range of
	<t>The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number.	0-127 have a defined triplet (calculation-type, metric-type,
	IS-IS router MAY advertise more than one IS-IS FAD Sub-TLV for a given	constraints). When used to specify the calculation-type in the FAD
	Flexible Algorithm (see <xref target="ISISFADLTLVS"/>).</t>	sub-TLV, only the calculation-type defined for the specified IGP
		Algorithm is used. The Metric/Constraints <bcp14>MUST NOT</bcp14>
	<t>The IS-IS FAD Sub-TLV has an area scope. The Router Capability TLV	be
	in which the FAD Sub-TLV is present MUST have the S-bit clear.</t>	inherited.
		If the required calculation-type is Shortest Path First, the value
	<t>An IS-IS L1/L2 router MAY be configured to re-generate the winning FA	0 <bcp14>MUST</bcp14> appear in this field.</dd>
	D	<dt pn="section-5.1-5.2.1.11">Priority:</dt>
		<dd pn="section-5.1-5.2.1.12">value between 0 and 255 inclusive th
		at specifies the
		priority of the advertisement. Numerically greater values are pref
		erred.
		Usage of the priority is described in <xref target="COMMONLEXALGTL
		V" format="default" sectionFormat="of" derivedContent="Section 5.3"/>.</dd>
		<dt pn="section-5.1-5.2.1.13">Sub-TLVs:</dt>
		<dd pn="section-5.1-5.2.1.14">optional sub-TLVs.</dd>
		</dl>
		</dd>
		</dl>
		<t indent="0" pn="section-5.1-6">The IS-IS FAD sub-TLV <bcp14>MAY</bcp14
		> be advertised in a Label Switched Path (LSP) of any number.
		The IS-IS router <bcp14>MAY</bcp14> advertise more than one IS-IS FAD su
		b-TLV for a given
		Flexible Algorithm (see <xref target="ISISFADLTLVS" format="default" sec
		tionFormat="of" derivedContent="Section 6"/>).</t>
		<t indent="0" pn="section-5.1-7">The IS-IS FAD sub-TLV has an area/level
		scope. The Router Capability TLV
		in which the FAD sub-TLV is present <bcp14>MUST</bcp14> have the S bit c
		lear.</t>
		<t indent="0" pn="section-5.1-8">An IS-IS L1/L2 router <bcp14>MAY</bcp14
		> be configured to regenerate the winning FAD
	from level 2, without any modification to it, to the level 1 area. The	from level 2, without any modification to it, to the level 1 area. The

	re-generation of the FAD Sub-TLV from level 2 to level 1 is determined	regeneration of the FAD sub-TLV from level 2 to level 1 is determined
	by the L1/L2 router, not by the originator of the FAD advertisement in	by the L1/L2 router, not by the originator of the FAD advertisement in

	the level 2. In such a case, the re-generated FAD Sub-TLV will be	level 2. In such a case, the regenerated FAD sub-TLV will be
	advertised in the level 1 Router Capability TLV originated by the	advertised in the level 1 Router Capability TLV originated by the
	L1/L2 router.</t>	L1/L2 router.</t>

		<t indent="0" pn="section-5.1-9">An L1/L2 router <bcp14>MUST NOT</bcp14>
	<t>An L1/L2 router MUST NOT re-generate any FAD Sub-TLV from level 1 to	regenerate any FAD sub-TLV from level 1 to
	level 2.</t>	level 2.</t>
	</section>	</section>

		<section anchor="OSPFFLEXALGTLV" numbered="true" toc="include" removeInRFC
		="false" pn="section-5.2">
		<name slugifiedName="name-ospf-flexible-algorithm-def">OSPF Flexible Alg
		orithm Definition TLV</name>
		<t indent="0" pn="section-5.2-1">The OSPF FAD TLV is advertised as a top
		-level TLV of the Router Information (RI)
		Link State Advertisement (LSA), which is defined in <xref target="RFC777
		0" format="default" sectionFormat="of" derivedContent="RFC7770"/>.</t>
		<t indent="0" pn="section-5.2-2">The OSPF FAD TLV has the following form
		at: </t>
		<artwork name="" type="" align="left" alt="" pn="section-5.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
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Type \| Length \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\|Flex-Algorithm \| Metric-Type \| Calc-Type \| Priority \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Sub-TLVs \|
		+ +
		\| ... \|


	<section anchor="OSPFFLEXALGTLV"	\| \|
	title="OSPF Flexible Algorithm Definition TLV">	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	<t>The OSPF FAD TLV is advertised as a top-level TLV of the Router Infor	</artwork>
	mation (RI)	<dl newline="true" spacing="normal" indent="3" pn="section-5.2-4">
	LSA that is defined in <xref target="RFC7770"/>.</t>	<dt pn="section-5.2-4.1">where:</dt>
		<dd pn="section-5.2-4.2">
	<t>The OSPF FAD TLV has the following format: <figure>	<dl newline="false" spacing="normal" indent="3" pn="section-5.2-4.2.
	<artwork><![CDATA[	1">
		<dt pn="section-5.2-4.2.1.1">Type:</dt>
	0 1 2 3	<dd pn="section-5.2-4.2.1.2">16</dd>
	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	<dt pn="section-5.2-4.2.1.3">Length:</dt>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dd pn="section-5.2-4.2.1.4">variable number of octets, dependent
	\| Type \| Length \|	on the included sub-TLVs.</dd>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dt pn="section-5.2-4.2.1.5">Flex-Algorithm:</dt>
	\|Flex-Algorithm \| Metric-Type \| Calc-Type \| Priority \|	<dd pn="section-5.2-4.2.1.6">Flexible Algorithm number. Single oct
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	et value between
	\| Sub-TLVs \|	128 and 255 inclusive.</dd>
	+ +	<dt pn="section-5.2-4.2.1.7">Metric-Type: </dt>
	\| ... \|	<dd pn="section-5.2-4.2.1.8">
		<t indent="0" pn="section-5.2-4.2.1.8.1">type of metric from the
	\| \|	IANA "IGP Metric-Type" registry
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	(<xref target="IGPMETRICTYPE" format="default" sectionFormat="of"
		derivedContent="Section 18.1.2"/>) to be used during the
	where:	calculation. The following values are defined: </t>
	]]></artwork>	<dl newline="false" spacing="normal" indent="3" pn="section-5.2-
	</figure> <list style="hanging">	4.2.1.8.2">
	<t>Type: 16</t>	<dt pn="section-5.2-4.2.1.8.2.1">0:</dt>
		<dd pn="section-5.2-4.2.1.8.2.2">IGP Metric</dd>
	<t>Length: variable number of octets, dependent on the included Sub-	<dt pn="section-5.2-4.2.1.8.2.3">1:</dt>
	TLVs</t>	<dd pn="section-5.2-4.2.1.8.2.4">Min Unidirectional Link Delay
		, as defined in <xref target="RFC7471" section="4.2" sectionFormat="of" format="
	<t>Flex-Algorithm: Flexible Algorithm number. Single octet value bet	default" derivedLink="https://rfc-editor.org/rfc/rfc7471#section-4.2" derivedCon
	ween	tent="RFC7471"/>, encoded as an
	128 and 255 inclusive.</t>	application-specific link attribute, as specified in <xref target="
		RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/> and <xre
	<t>Metric-Type: Type of metric from the "IGP Metric-Type Registry"	f target="FLEXALGLINKATTR" format="default" sectionFormat="of" derivedContent="S
	(<xref target="IGPMETRICTYPE"/>) to be used during the calculation.	ection 12"/> of
	The following values are defined: <list style="hanging">	this document.</dd>
	<t>0: IGP Metric</t>	<dt pn="section-5.2-4.2.1.8.2.5">2:</dt>
		<dd pn="section-5.2-4.2.1.8.2.6">Traffic Engineering Metric, a
	<t>1: Min Unidirectional Link Delay as defined in <xref	s defined in <xref target="RFC3630" section="2.5.5" sectionFormat="of" format="d
	target="RFC7471"/>, section 4.2, encoded as application	efault" derivedLink="https://rfc-editor.org/rfc/rfc3630#section-2.5.5" derivedCo
	specific link attribute as specified in <xref	ntent="RFC3630"/>, encoded as an
	target="RFC8920"/> and <xref target="FLEXALGLINKATTR"/> of	application-specific link attribute, as specified in <xref target="
	this document.</t>	RFC8920" format="default" sectionFormat="of" derivedContent="RFC8920"/> and <xre
		f target="FLEXALGLINKATTR" format="default" sectionFormat="of" derivedContent="S
	<t>2: Traffic Engineering metric as defined in <xref	ection 12"/> of
	target="RFC3630"/>, section 2.5.5, encoded as application	this document.</dd>
	specific link attribute as specified in <xref	</dl>
	target="RFC8920"/> and <xref target="FLEXALGLINKATTR"/> of	</dd>
	this document.</t>	<dt pn="section-5.2-4.2.1.9">Calc-Type:</dt>
	</list></t>	<dd pn="section-5.2-4.2.1.10">as described in <xref target="ISISFL
		EXALGTLV" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</d
	<t>Calc-Type: as described in <xref target="ISISFLEXALGTLV"/></t>	d>
		<dt pn="section-5.2-4.2.1.11">Priority: </dt>
	<t>Priority: as described in <xref target="ISISFLEXALGTLV"/></t>	<dd pn="section-5.2-4.2.1.12">as described in <xref target="ISISFL
		EXALGTLV" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</d
	<t>Sub-TLVs - optional sub-TLVs.</t>	d>
	</list></t>	<dt pn="section-5.2-4.2.1.13">Sub-TLVs:</dt>
		<dd pn="section-5.2-4.2.1.14">optional sub-TLVs.</dd>
	<t>When multiple OSPF FAD TLVs, for the same Flexible Algorithm, are	</dl>
	received from a given router, the receiver MUST use the first	</dd>
	occurrence of the TLV in the Router Information LSA. If the OSPF FAD	</dl>
	TLV, for the same Flex-Algorithm, appears in multiple Router	<t indent="0" pn="section-5.2-5">When multiple OSPF FAD TLVs, for the sa
	Information LSAs that have different flooding scopes, the OSPF FAD TLV	me Flexible Algorithm, are
	in the Router Information LSA with the area-scoped flooding scope MUST	received from a given router, the receiver <bcp14>MUST</bcp14> use the f
		irst
		occurrence of the TLV in the RI LSA. If the OSPF FAD
		TLV, for the same Flex-Algorithm, appears in multiple RI
		LSAs that have different flooding scopes, the OSPF FAD TLV
		in the RI LSA with the area-scoped flooding scope <bcp14>MUST</bcp14>
	be used. If the OSPF FAD TLV, for the same algorithm, appears in	be used. If the OSPF FAD TLV, for the same algorithm, appears in

	multiple Router Information LSAs that have the same flooding scope,	multiple RI LSAs that have the same flooding scope,
	the OSPF FAD TLV in the Router Information (RI) LSA with the	the OSPF FAD TLV in the RI LSA with the
	numerically smallest Instance ID MUST be used and subsequent instances	numerically smallest Instance ID <bcp14>MUST</bcp14> be used and subsequ
	of the OSPF FAD TLV MUST be ignored.</t>	ent
		instances of the OSPF FAD TLV <bcp14>MUST</bcp14> be ignored.</t>
	<t>The RI LSA can be advertised at any of the defined opaque flooding	<t indent="0" pn="section-5.2-6">The RI LSA can be advertised at any of
		the defined opaque flooding
	scopes (link, area, or Autonomous System (AS)). For the purpose of	scopes (link, area, or Autonomous System (AS)). For the purpose of

	OSPF FAD TLV advertisement, area-scoped flooding is REQUIRED. The	OSPF FAD TLV advertisement, area-scoped flooding is <bcp14>REQUIRED</bcp
	Autonomous System flooding scope SHOULD NOT be used unless	14>. The
	local configuration policy on the originating router indicates domain	AS flooding scope <bcp14>SHOULD NOT</bcp14> be used unless
	wide flooding.</t>	local configuration policy on the originating router indicates domain-wi
		de
		flooding.</t>
	</section>	</section>

		<section anchor="COMMONLEXALGTLV" numbered="true" toc="include" removeInRF
	<section anchor="COMMONLEXALGTLV"	C="false" pn="section-5.3">
	title="Common Handling of Flexible Algorithm Definition TLV">	<name slugifiedName="name-common-handling-of-the-flex">Common Handling o
	<t>This section describes the protocol-independent handling of the FAD	f the Flexible Algorithm Definition TLV</name>
	TLV (OSPF) or FAD Sub-TLV (IS-IS). We will refer to it as FAD TLV in	<t indent="0" pn="section-5.3-1">This section describes the protocol-ind
	this section, even though in the case of IS-IS it is a Sub-TLV.</t>	ependent handling of the FAD
		TLV (OSPF) or FAD sub-TLV (IS-IS). We will refer to it as FAD TLV in
	<t>The value of the Flex-Algorithm MUST be between 128 and 255	this section, even though, in the case of IS-IS, it is a sub-TLV.</t>
	inclusive. If it is not, the FAD TLV MUST be ignored.</t>	<t indent="0" pn="section-5.3-2">The value of the Flex-Algorithm <bcp14>
		MUST</bcp14> be between 128 and 255
	<t>Only a subset of the routers participating in the particular	inclusive. If it is not, the FAD TLV <bcp14>MUST</bcp14> be ignored.</t>
		<t indent="0" pn="section-5.3-3">Only a subset of the routers participat
		ing in the particular
	Flex-Algorithm need to advertise the definition of the	Flex-Algorithm need to advertise the definition of the
	Flex-Algorithm.</t>	Flex-Algorithm.</t>

		<t indent="0" pn="section-5.3-4">Every router that is configured to part
	<t>Every router, that is configured to participate in a particular	icipate in a particular
	Flex-Algorithm, MUST select the Flex-Algorithm definition based on the	Flex-Algorithm <bcp14>MUST</bcp14> select the Flex-Algorithm Definition
		based on the
	following ordered rules. This allows for the consistent Flex-Algorithm	following ordered rules. This allows for the consistent Flex-Algorithm

	definition selection in cases where different routers advertise	Definition selection in cases where different routers advertise
	different definitions for a given Flex-Algorithm: <list>	different definitions for a given Flex-Algorithm: </t>
	<t>1. From the advertisements of the FAD in the area (including	<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.
	both locally generated advertisements and received advertisements)	3-5">
	select the one(s) with the numerically greatest priority value.</t>	<li pn="section-5.3-5.1" derivedCounter="1.">From the advertisements o
		f the FAD in the area (including
	<t>2. If there are multiple advertisements of the FAD with the	both locally generated advertisements and received advertisements),
	same numerically greatest priority, select the one that is originate	select the one(s) with the numerically greatest priority value.</li>
	d from the	<li pn="section-5.3-5.2" derivedCounter="2.">If there are multiple adv
	router with the numerically greatest System-ID, in the case of IS-IS	ertisements of the FAD with the
	, or Router	same numerically greatest priority, select the one that is originated
	ID, in the case of OSPFv2 and OSPFv3. For IS-IS, the System-ID is	from
	described in <xref target="ISO10589"/>. For OSPFv2 and OSPFv3,	the router with the numerically greatest System-ID, in the case of IS-I
	standard Router ID is described in <xref target="RFC2328"/> and	S, or
	<xref target="RFC5340"/> respectively.</t>	Router ID, in the case of OSPFv2 and OSPFv3. For IS-IS, the System-ID i
	</list></t>	s
		described in <xref target="ISO10589" format="default" sectionFormat="o
	<t>The FAD selected according to these rules is also known as the	f" derivedContent="ISO10589"/>. For OSPFv2 and OSPFv3,
		the standard Router ID is described in <xref target="RFC2328" format="
		default" sectionFormat="of" derivedContent="RFC2328"/> and <xref target="RFC5340
		" format="default" sectionFormat="of" derivedContent="RFC5340"/>,
		respectively.</li>
		</ol>
		<t indent="0" pn="section-5.3-6">The FAD selected according to these rul
		es is also known as the
	"winning FAD".</t>	"winning FAD".</t>

		<t indent="0" pn="section-5.3-7">A router that is not configured to part
	<t>A router that is not configured to participate in a particular	icipate in a particular
	Flex-Algorithm MUST ignore FAD Sub-TLVs advertisements for such	Flex-Algorithm <bcp14>MUST</bcp14> ignore FAD sub-TLV advertisements for
		such
	Flex-Algorithm.</t>	Flex-Algorithm.</t>

		<t indent="0" pn="section-5.3-8">A router that is not participating in a
	<t>A router that is not participating in a particular Flex-Algorithm	particular Flex-Algorithm
	MAY advertise FAD for such Flex-Algorithm. Receiving routers	<bcp14>MAY</bcp14> advertise the FAD for such Flex-Algorithm. Receiving
	MUST consider a received FAD advertisement regardless of the Flex-Algori	routers
	thm	<bcp14>MUST</bcp14> consider a received FAD advertisement regardless of
		the Flex-Algorithm
	participation of that FAD advertisement's originator.</t>	participation of that FAD advertisement's originator.</t>

		<t indent="0" pn="section-5.3-9">Any change in the Flex-Algorithm Defini
	<t>Any change in the Flex-Algorithm definition may result in temporary	tion may result in a temporary
	disruption of traffic that is forwarded based on such Flex-Algorithm	disruption of traffic that is forwarded based on such Flex-Algorithm
	paths. The impact is similar to any other event that requires	paths. The impact is similar to any other event that requires
	network-wide convergence.</t>	network-wide convergence.</t>

		<t indent="0" pn="section-5.3-10">If a node is configured to participate
	<t>If a node is configured to participate in a particular	in a particular
	Flexible Algorithm, but there is no valid Flex-Algorithm definition avai	Flexible Algorithm, but there is no valid Flex-Algorithm Definition avai
	lable for	lable for
	it, or the selected Flex-Algorithm definition includes calculation-type,	it or the selected Flex-Algorithm Definition includes calculation-type,
	metric-type,	metric-type,
	constraint, flag, or Sub-TLV that is not supported by the node, it MUST	constraint, flag, or sub-TLV that is not supported by the node, it <bcp1
	stop	4>MUST</bcp14> stop
	participating in such Flexible Algorithm. That implies that it MUST NOT	participating in such Flexible Algorithm. That implies that it <bcp14>MU
	announce	ST NOT</bcp14> announce
	participation for such Flexible Algorithm as specified in <xref	participation for such Flexible Algorithm, as specified in <xref target=
	target="FLEXALGPART"/> and it MUST remove any forwarding state	"FLEXALGPART" format="default" sectionFormat="of" derivedContent="Section 11"/>,
		and it <bcp14>MUST</bcp14> remove any forwarding state
	associated with it.</t>	associated with it.</t>

		<t indent="0" pn="section-5.3-11">The Flex-Algorithm Definition is topol
	<t>Flex-Algorithm definition is topology independent. It applies to	ogy independent. It applies to
	all topologies that a router participates in.</t>	all topologies that a router participates in.</t>


	</section>	</section>
	</section>	</section>

		<section anchor="ISISFADLTLVS" numbered="true" toc="include" removeInRFC="fa
	<section anchor="ISISFADLTLVS" title="Sub-TLVs of IS-IS FAD Sub-TLV">	lse" pn="section-6">
		<name slugifiedName="name-sub-tlvs-of-is-is-fad-sub-t">Sub-TLVs of IS-IS F
	<t>One of the limitations of IS-IS <xref target="ISO10589"/> is that the len	AD Sub-TLV</name>
	gth of	<t indent="0" pn="section-6-1">One of the limitations of IS-IS <xref targe
		t="ISO10589" format="default" sectionFormat="of" derivedContent="ISO10589"/> is
		that the length of
	a TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub-TLV, th ere are	a TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub-TLV, th ere are

	a number of sub-sub-TLVs (defined below) which are supported. For a given	a number of sub-sub-TLVs (defined below) that are supported. For a given
	Flex-Algorithm, it is possible that the total number of octets required to	Flex-Algorithm, it is possible that the total number of octets required to
	completely define a FAD exceeds the maximum length supported by a single FAD sub-TLV.	completely define a FAD exceeds the maximum length supported by a single FAD sub-TLV.

	In such cases, the FAD MAY be split into multiple such sub-TLVs and the cont	In such cases, the FAD <bcp14>MAY</bcp14> be split into multiple such sub-TL
	ent of	Vs, and the content of
	the multiple FAD sub-TLVs combined to provide a complete FAD for the Flex-Al	the multiple FAD sub-TLVs are combined to provide a complete FAD for the Fle
	gorithm.	x-Algorithm.
	In such a case, the fixed portion of the FAD (see <xref target="ISISFLEXALGT	In such a case, the fixed portion of the FAD (see <xref target="ISISFLEXALGT
	LV"/>)	LV" format="default" sectionFormat="of" derivedContent="Section 5.1"/>)
	MUST be identical in all FAD sub-TLVs for a given Flex-Algorithm from a give	<bcp14>MUST</bcp14> be identical in all FAD sub-TLVs for a given Flex-Algori
	n IS.	thm from a given IS.
	In case the fixed portion of such FAD Sub-TLVs differ, the values	In case the fixed portion of such FAD sub-TLVs differ, the values
	in the fixed portion in the FAD sub-TLV in the first occurrence in the lowes	in the fixed portion in the FAD sub-TLV in the first occurrence in the lowes
	t	t-numbered LSP from a given IS <bcp14>MUST</bcp14> be used.</t>
	numbered LSP from a given IS MUST be used.</t>	<t indent="0" pn="section-6-2">Any specification that introduces a new IS-
		IS FAD sub-sub-TLV <bcp14>MUST</bcp14> specify whether
	<t>Any specification that introduces a new IS-IS FAD sub-sub-TLV MUST specif
	y whether
	the FAD sub-TLV may appear multiple times in the set of FAD sub-TLVs for a g iven	the FAD sub-TLV may appear multiple times in the set of FAD sub-TLVs for a g iven
	Flex-Algorithm from a given IS and how to handle them if multiple are allowe d.</t>	Flex-Algorithm from a given IS and how to handle them if multiple are allowe d.</t>

		<section anchor="ISISFLEXALGEXLTLV" numbered="true" toc="include" removeIn
	<section anchor="ISISFLEXALGEXLTLV"	RFC="false" pn="section-6.1">
	title="IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV">	<name slugifiedName="name-is-is-flexible-algorithm-ex">IS-IS Flexible Al
	<t>The Flexible Algorithm definition can specify 'colors' that are	gorithm Exclude Admin Group Sub-TLV</name>
		<t indent="0" pn="section-6.1-1">The Flexible Algorithm Definition can s
		pecify "colors" that are
	used by the operator to exclude links during the Flex-Algorithm path	used by the operator to exclude links during the Flex-Algorithm path
	computation.</t>	computation.</t>

		<t indent="0" pn="section-6.1-2">The IS-IS Flexible Algorithm Exclude Ad
	<t>The IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV is used to	min Group (FAEAG) sub-TLV is used to
	advertise the exclude rule that is used during the Flex-Algorithm path	advertise the exclude rule that is used during the Flex-Algorithm path

	calculation as specified in <xref target="FLEXALGPATHCALC"/>.</t>	calculation, as specified in <xref target="FLEXALGPATHCALC" format="defa
		ult" sectionFormat="of" derivedContent="Section 13"/>.</t>
	<t>The IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV (FAEAG	<t indent="0" pn="section-6.1-3">The IS-IS FAEAG sub-TLV
	Sub-TLV) is a Sub-TLV of the IS-IS FAD Sub-TLV. It has the following	is a sub-TLV of the IS-IS FAD sub-TLV. It has the following
	format: <figure>	format: </t>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt="" pn="section-6.1-4">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Extended Admin Group \|	\| Extended Admin Group \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where:	</artwork>
	]]></artwork>	<dl newline="true" spacing="normal" indent="3" pn="section-6.1-5">
	</figure> <list style="hanging">	<dt pn="section-6.1-5.1">where:</dt>
	<t>Type: 1</t>	<dd pn="section-6.1-5.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-6.1-5.2.
	<t>Length: variable, dependent on the size of the Extended Admin	1">
	Group. MUST be a multiple of 4 octets.</t>	<dt pn="section-6.1-5.2.1.1">Type:</dt>
		<dd pn="section-6.1-5.2.1.2">1</dd>
	<t>Extended Administrative Group: Extended Administrative Group as	<dt pn="section-6.1-5.2.1.3">Length:</dt>
	defined in <xref target="RFC7308"/>.</t>	<dd pn="section-6.1-5.2.1.4">variable, dependent on the size of th
	</list></t>	e Extended Admin
		Group. <bcp14>MUST</bcp14> be a multiple of 4 octets.</dd>
	<t>The IS-IS FAEAG Sub-TLV MUST NOT appear more than once in a single IS	<dt pn="section-6.1-5.2.1.5">Extended Administrative Group:</dt>
	-IS	<dd pn="section-6.1-5.2.1.6">Extended Administrative Group, as
	FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-TLV MUST	defined in <xref target="RFC7308" format="default" sectionFormat="
		of" derivedContent="RFC7308"/>.</dd>
		</dl>
		</dd>
		</dl>
		<t indent="0" pn="section-6.1-6">The IS-IS FAEAG sub-TLV <bcp14>MUST NOT
		</bcp14> appear more than once in a single IS-IS
		FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV <bcp14>
		MUST</bcp14>
	be ignored by the receiver.</t>	be ignored by the receiver.</t>

		<t indent="0" pn="section-6.1-7">The IS-IS FAEAG sub-TLV <bcp14>MUST NOT
	<t>The IS-IS FAEAG Sub-TLV MUST NOT appear more than once in the set of	</bcp14> appear more than once in the set of FAD
	FAD
	sub-TLVs for a given Flex-Algorithm from a given IS. If it appears more than once	sub-TLVs for a given Flex-Algorithm from a given IS. If it appears more than once

	in such a set, the IS-IS FAEAG Sub-TLV in the first occurrence in the lo	in such a set, the IS-IS FAEAG sub-TLV in the first occurrence in the lo
	west numbered	west-numbered
	LSP from a given IS MUST be used and any other occurrences MUST be ignor	LSP from a given IS <bcp14>MUST</bcp14> be used, and any other occurrenc
	ed.</t>	es <bcp14>MUST</bcp14> be ignored.</t>

	</section>	</section>

		<section anchor="ISISFLEXALGINCANYTLV" numbered="true" toc="include" remov
	<section anchor="ISISFLEXALGINCANYTLV"	eInRFC="false" pn="section-6.2">
	title="IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV">	<name slugifiedName="name-is-is-flexible-algorithm-in">IS-IS Flexible Al
	<t>The Flexible Algorithm definition can specify 'colors' that are	gorithm Include-Any Admin Group Sub-TLV</name>
		<t indent="0" pn="section-6.2-1">The Flexible Algorithm Definition can s
		pecify "colors" that are
	used by the operator to include links during the Flex-Algorithm path	used by the operator to include links during the Flex-Algorithm path
	computation.</t>	computation.</t>

		<t indent="0" pn="section-6.2-2">The IS-IS Flexible Algorithm Include-An
	<t>The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV is used	y Admin Group sub-TLV is used
	to advertise the include-any rule that is used during the Flex-Algorithm	to advertise the include-any rule that is used during the Flex-Algorithm

	path calculation as specified in <xref target="FLEXALGPATHCALC"/>.</t>	path calculation, as specified in <xref target="FLEXALGPATHCALC" format=
		"default" sectionFormat="of" derivedContent="Section 13"/>.</t>
	<t>The IS-IS Flexible Algorithm Include-Any Admin Group	<t indent="0" pn="section-6.2-3">The IS-IS Flexible Algorithm Include-An
	Sub-TLV is a Sub-TLV of the IS-IS FAD Sub-TLV. It has the following	y Admin Group
	format: <figure>	sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It has the following
	<artwork><![CDATA[	format: </t>
		<artwork name="" type="" align="left" alt="" pn="section-6.2-4">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Extended Admin Group \|	\| Extended Admin Group \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where:	</artwork>
	]]></artwork>	<dl newline="true" spacing="normal" indent="3" pn="section-6.2-5">
	</figure> <list style="hanging">	<dt pn="section-6.2-5.1">where:</dt>
	<t>Type: 2</t>	<dd pn="section-6.2-5.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-6.2-5.2.
	<t>Length: variable, dependent on the size of the Extended Admin	1">
	Group. MUST be a multiple of 4 octets.</t>	<dt pn="section-6.2-5.2.1.1">Type: </dt>
		<dd pn="section-6.2-5.2.1.2">2</dd>
	<t>Extended Administrative Group: Extended Administrative Group as	<dt pn="section-6.2-5.2.1.3">Length:</dt>
	defined in <xref target="RFC7308"/>.</t>	<dd pn="section-6.2-5.2.1.4">variable, dependent on the size of th
	</list></t>	e Extended Admin
		Group. <bcp14>MUST</bcp14> be a multiple of 4 octets.</dd>
	<t>The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV MUST	<dt pn="section-6.2-5.2.1.5">Extended Administrative Group:</dt>
	NOT appear more than once in a single IS-IS FAD Sub-TLV. If it appears m	<dd pn="section-6.2-5.2.1.6">Extended Administrative Group, as
	ore	defined in <xref target="RFC7308" format="default" sectionFormat="
	than once, the IS-IS FAD Sub-TLV MUST be ignored by the receiver.</t>	of" derivedContent="RFC7308"/>.</dd>
		</dl>
	<t>The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV MUST NOT	</dd>
	appear	</dl>
		<t indent="0" pn="section-6.2-6">The IS-IS Flexible Algorithm Include-An
		y Admin Group sub-TLV <bcp14>MUST NOT</bcp14> appear more than once in a single
		IS-IS FAD sub-TLV. If it appears more
		than once, the IS-IS FAD sub-TLV <bcp14>MUST</bcp14> be ignored by the r
		eceiver.</t>
		<t indent="0" pn="section-6.2-7">The IS-IS Flexible Algorithm Include-An
		y Admin Group sub-TLV <bcp14>MUST NOT</bcp14> appear
	more than once in the set of FAD sub-TLVs for a given Flex-Algorithm fro m a given IS.	more than once in the set of FAD sub-TLVs for a given Flex-Algorithm fro m a given IS.
	If it appears more than once in such a set, the IS-IS Flexible Algorithm	If it appears more than once in such a set, the IS-IS Flexible Algorithm

	Include-Any Admin Group Sub-TLV in the first occurrence in the lowest nu	Include-Any Admin Group sub-TLV in the first occurrence in the lowest-nu
	mbered	mbered
	LSP from a given IS MUST be used and any other occurrences MUST be ignor	LSP from a given IS <bcp14>MUST</bcp14> be used, and any other occurrenc
	ed.</t>	es <bcp14>MUST</bcp14> be ignored.</t>

	</section>	</section>

		<section anchor="ISISFLEXALGINCALLTLV" numbered="true" toc="include" remov
	<section anchor="ISISFLEXALGINCALLTLV"	eInRFC="false" pn="section-6.3">
	title="IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV">	<name slugifiedName="name-is-is-flexible-algorithm-inc">IS-IS Flexible A
	<t>The Flexible Algorithm definition can specify 'colors' that are	lgorithm Include-All Admin Group Sub-TLV</name>
		<t indent="0" pn="section-6.3-1">The Flexible Algorithm Definition can s
		pecify "colors" that are
	used by the operator to include links during the Flex-Algorithm path	used by the operator to include links during the Flex-Algorithm path
	computation.</t>	computation.</t>

		<t indent="0" pn="section-6.3-2">The IS-IS Flexible Algorithm Include-Al
	<t>The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV is used	l Admin Group sub-TLV is used
	to advertise the include-all rule that is used during the Flex-Algorithm	to advertise the include-all rule that is used during the Flex-Algorithm

	path calculation as specified in <xref target="FLEXALGPATHCALC"/>.</t>	path calculation, as specified in <xref target="FLEXALGPATHCALC" format=
		"default" sectionFormat="of" derivedContent="Section 13"/>.</t>
	<t>The IS-IS Flexible Algorithm Include-All Admin Group	<t indent="0" pn="section-6.3-3">The IS-IS Flexible Algorithm Include-Al
	Sub-TLV is is a Sub-TLV of the IS-IS FAD Sub-TLV. It has the following	l Admin Group
	format: <figure>	sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It has the following
	<artwork><![CDATA[	format: </t>
		<artwork name="" type="" align="left" alt="" pn="section-6.3-4">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Extended Admin Group \|	\| Extended Admin Group \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where:	</artwork>
	]]></artwork>	<dl newline="true" spacing="normal" indent="3" pn="section-6.3-5">
	</figure> <list style="hanging">	<dt pn="section-6.3-5.1">where:</dt>
	<t>Type: 3</t>	<dd pn="section-6.3-5.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-6.3-5.2.
	<t>Length: variable, dependent on the size of the Extended Admin	1">
	Group. MUST be a multiple of 4 octets.</t>	<dt pn="section-6.3-5.2.1.1">Type:</dt>
		<dd pn="section-6.3-5.2.1.2">3</dd>
	<t>Extended Administrative Group: Extended Administrative Group as	<dt pn="section-6.3-5.2.1.3">Length:</dt>
	defined in <xref target="RFC7308"/>.</t>	<dd pn="section-6.3-5.2.1.4">variable, dependent on the size of th
	</list></t>	e Extended Admin
		Group. <bcp14>MUST</bcp14> be a multiple of 4 octets.</dd>
	<t>The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV MUST	<dt pn="section-6.3-5.2.1.5">Extended Administrative Group:</dt>
	NOT appear more than once in a single IS-IS FAD Sub-TLV. If it appears m	<dd pn="section-6.3-5.2.1.6">Extended Administrative Group, as
	ore	defined in <xref target="RFC7308" format="default" sectionFormat="
	than once, the IS-IS FAD Sub-TLV MUST be ignored by the receiver.</t>	of" derivedContent="RFC7308"/>.</dd>
		</dl>
	<t>The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV MUST NOT	</dd>
	appear	</dl>
		<t indent="0" pn="section-6.3-6">The IS-IS Flexible Algorithm Include-Al
		l Admin Group sub-TLV <bcp14>MUST NOT</bcp14> appear more than once in a single
		IS-IS FAD sub-TLV. If it appears more
		than once, the IS-IS FAD sub-TLV <bcp14>MUST</bcp14> be ignored by the r
		eceiver.</t>
		<t indent="0" pn="section-6.3-7">The IS-IS Flexible Algorithm Include-Al
		l Admin Group sub-TLV <bcp14>MUST NOT</bcp14> appear
	more than once in the set of FAD sub-TLVs for a given Flex-Algorithm fro m a given IS.	more than once in the set of FAD sub-TLVs for a given Flex-Algorithm fro m a given IS.
	If it appears more than once in such a set, the IS-IS Flexible Algorithm Include-All Admin Group	If it appears more than once in such a set, the IS-IS Flexible Algorithm Include-All Admin Group

	Sub-TLV in the first occurrence in the lowest numbered LSP from a given	sub-TLV in the first occurrence in the lowest-numbered LSP from a given
	IS MUST	IS <bcp14>MUST</bcp14>
	be used and any other occurrences MUST be ignored.</t>	be used, and any other occurrences <bcp14>MUST</bcp14> be ignored.</t>

	</section>	</section>

		<section anchor="ISISFLEXALGFLAG" numbered="true" toc="include" removeInRF
	<section anchor="ISISFLEXALGFLAG"	C="false" pn="section-6.4">
	title="IS-IS Flexible Algorithm Definition Flags Sub-TLV">	<name slugifiedName="name-is-is-flexible-algorithm-def">IS-IS Flexible A
	<t>The IS-IS Flexible Algorithm Definition Flags Sub-TLV (FADF Sub-TLV)	lgorithm Definition Flags Sub-TLV</name>
	is a Sub-TLV of the IS-IS FAD Sub-TLV. It has the following format:	<t indent="0" pn="section-6.4-1">The IS-IS Flexible Algorithm Definition
	<figure>	Flags (FADF) sub-TLV
	<artwork><![CDATA[	is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
		</t>
		<artwork name="" type="" align="left" alt="" pn="section-6.4-2">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Flags \|	\| Flags \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where:	</artwork>
	]]></artwork>	<dl newline="true" spacing="normal" indent="3" pn="section-6.4-3">
	</figure> <list style="hanging">	<dt pn="section-6.4-3.1">where:</dt>
	<t>Type: 4</t>	<dd pn="section-6.4-3.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-6.4-3.2.
	<t>Length: variable, number of octets of the Flags field</t>	1">
		<dt pn="section-6.4-3.2.1.1">Type:</dt>
	<t>Flags: <figure>	<dd pn="section-6.4-3.2.1.2">4</dd>
	<artwork><![CDATA[	<dt pn="section-6.4-3.2.1.3">Length:</dt>
		<dd pn="section-6.4-3.2.1.4">variable, number of octets of the Fla
		gs field.</dd>
		<dt pn="section-6.4-3.2.1.5">Flags:</dt>
		<dd pn="section-6.4-3.2.1.6">
		<artwork name="" type="" align="left" alt="" pn="section-6.4-3.2
		.1.6.1">
	0 1 2 3 4 5 6 7...	0 1 2 3 4 5 6 7...
	+-+-+-+-+-+-+-+-+...	+-+-+-+-+-+-+-+-+...
	\|M\| \| \| ...	\|M\| \| \| ...
	+-+-+-+-+-+-+-+-+...	+-+-+-+-+-+-+-+-+...

	]]></artwork>	</artwork>
	</figure> <list style="hanging">	<dl newline="false" spacing="normal" indent="3" pn="section-6.4-
	<t>M-flag: when set, the Flex-Algorithm specific prefix metric	3.2.1.6.2">
	MUST be used for inter-area and external prefix calculation.	<dt pn="section-6.4-3.2.1.6.2.1">M-flag:</dt>
	This flag is not applicable to prefixes advertised as SRv6	<dd pn="section-6.4-3.2.1.6.2.2">when set, the Flex-Algorithm-
	locators.</t>	specific prefix metric
	</list></t>	<bcp14>MUST</bcp14> be used for inter-area and external prefix cal
	</list></t>	culation.
		This flag is not applicable to prefixes advertised as SRv6
	<t>A new IANA "IGP Flexible Algorithm Definition Flags Registry" is	locators.</dd>
	defined for allocation of bits in the Flags field -	</dl>
	see <xref target="IANAFADFLGAS"/>.</t>	</dd>
		</dl>
	<t>Bits are defined/sent starting with Bit 0 defined above. Additional	</dd>
	bit definitions that may be defined in the future SHOULD be assigned	</dl>
	in ascending bit order so as to minimize the number of bits that will	<t indent="0" pn="section-6.4-4">A new IANA "IGP Flexible Algorithm Defi
		nition Flags" registry is
		defined for allocation of bits in the Flags field --
		see <xref target="IANAFADFLGAS" format="default" sectionFormat="of" deri
		vedContent="Section 18.2"/>.</t>
		<t indent="0" pn="section-6.4-5">Bits are defined/sent starting with bit
		0 defined above. Additional
		bit definitions that may be defined in the future <bcp14>SHOULD</bcp14>
		be assigned
		in ascending bit order to minimize the number of bits that will
	need to be transmitted.</t>	need to be transmitted.</t>

		<t indent="0" pn="section-6.4-6">Undefined bits <bcp14>MUST</bcp14> be t
	<t>Undefined bits MUST be transmitted as 0.</t>	ransmitted as 0.</t>
		<t indent="0" pn="section-6.4-7">Bits that are not transmitted <bcp14>MU
	<t>Bits that are not transmitted MUST be treated as if they are set to	ST</bcp14> be treated as if they are set to
	0 on receipt.</t>	0 on receipt.</t>

		<t indent="0" pn="section-6.4-8">The IS-IS FADF sub-TLV <bcp14>MUST NOT<
	<t>The IS-IS FADF Sub-TLV MUST NOT appear more than once in a single IS-	/bcp14> appear more than once in a single IS-IS FAD
	IS FAD	sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV <bcp14>MUST
	Sub-TLV. If it appears more than once, the IS-IS FAD Sub-TLV MUST be	</bcp14> be
	ignored by the receiver.</t>	ignored by the receiver.</t>

		<t indent="0" pn="section-6.4-9">The IS-IS FADF sub-TLV <bcp14>MUST NOT<
	<t>The IS-IS FADF Sub-TLV MUST NOT appear more than once in the set of F	/bcp14> appear more than once in the set of FAD
	AD
	sub-TLVs for a given Flex-Algorithm from a given IS. If it appears more than once	sub-TLVs for a given Flex-Algorithm from a given IS. If it appears more than once

	in such a set, the IS-IS FADF Sub-TLV in the first occurrence in the low	in such a set, the IS-IS FADF sub-TLV in the first occurrence in the low
	est	est-numbered LSP from a given IS <bcp14>MUST</bcp14> be used, and any other occu
	numbered LSP from a given IS MUST be used and any other occurrences MUST	rrences <bcp14>MUST</bcp14> be ignored.</t>
	be ignored.</t>	<t indent="0" pn="section-6.4-10">If the IS-IS FADF sub-TLV is not prese
		nt inside the IS-IS FAD
	<t>If the IS-IS FADF Sub-TLV is not present inside the IS-IS FAD	sub-TLV, all the bits are assumed to be set to 0.</t>
	Sub-TLV, all the bits are assumed to be set to 0.</t>	<t indent="0" pn="section-6.4-11">If a node is configured to participate
		in a particular Flexible Algorithm,
	<t>If a node is configured to participate in a particular Flexible Algor	but the selected Flex-Algorithm Definition includes a bit in the IS-IS F
	ithm,	ADF sub-TLV
	but the selected Flex-Algorithm definition includes a bit in the IS-IS F	that is not supported by the node, it <bcp14>MUST</bcp14> stop participa
	ADF Sub-TLV	ting in such
	that is not supported by the node, it MUST stop participating in such
	Flexible Algorithm.</t>	Flexible Algorithm.</t>

		<t indent="0" pn="section-6.4-12">New flag bits may be defined in the fu
	<t>New flag bits may be defined in the future. Implementations MUST chec	ture. Implementations <bcp14>MUST</bcp14> check all
	k all	advertised flag bits in the received IS-IS FADF sub-TLV -- not just the
	advertised flag bits in the received IS-IS FADF Sub-TLV - not just the s	subset
	ubset
	currently defined.</t>	currently defined.</t>

		<t indent="0" pn="section-6.4-13">The M-flag <bcp14>MUST</bcp14> not be
	<t>M-flag MUST not be used when calculating prefix reachability for SRv6	used when calculating prefix reachability for the SRv6
	Locator prefix.</t>	Locator prefix.</t>


	</section>	</section>

		<section anchor="ISISFLEXALGEXSRLGTLV" numbered="true" toc="include" remov
	<section anchor="ISISFLEXALGEXSRLGTLV"	eInRFC="false" pn="section-6.5">
	title="IS-IS Flexible Algorithm Exclude SRLG Sub-TLV">	<name slugifiedName="name-is-is-flexible-algorithm-exc">IS-IS Flexible A
	<t>The Flexible Algorithm definition can specify Shared Risk Link	lgorithm Exclude SRLG Sub-TLV</name>
		<t indent="0" pn="section-6.5-1">The Flexible Algorithm Definition can s
		pecify Shared Risk Link
	Groups (SRLGs) that the operator wants to exclude during the	Groups (SRLGs) that the operator wants to exclude during the
	Flex-Algorithm path computation.</t>	Flex-Algorithm path computation.</t>

		<t indent="0" pn="section-6.5-2">The IS-IS Flexible Algorithm Exclude SR
	<t>The IS-IS Flexible Algorithm Exclude SRLG Sub-TLV (FAESRLG) is used	LG (FAESRLG) sub-TLV is used
	to advertise the exclude rule that is used during the Flex-Algorithm	to advertise the exclude rule that is used during the Flex-Algorithm

	path calculation as specified in <xref target="FLEXALGPATHCALC"/>.</t>	path calculation, as specified in <xref target="FLEXALGPATHCALC" format=
		"default" sectionFormat="of" derivedContent="Section 13"/>.</t>
	<t>The IS-IS FAESRLG Sub-TLV is a Sub-TLV of the IS-IS FAD Sub-TLV. It	<t indent="0" pn="section-6.5-3">The IS-IS FAESRLG sub-TLV is a sub-TLV
	has the following format: <figure>	of the IS-IS FAD sub-TLV. It
	<artwork><![CDATA[	has the following format: </t>
		<artwork name="" type="" align="left" alt="" pn="section-6.5-4">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Shared Risk Link Group Value \|	\| Shared Risk Link Group Value \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where:	</artwork>
	]]></artwork>	<dl newline="true" spacing="normal" indent="3" pn="section-6.5-5">
	</figure> <list style="hanging">	<dt pn="section-6.5-5.1">where:</dt>
	<t>Type: 5</t>	<dd pn="section-6.5-5.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-6.5-5.2.
	<t>Length: variable, dependent on number of SRLG values. MUST be a	1">
	multiple of 4 octets.</t>	<dt pn="section-6.5-5.2.1.1">Type:</dt>
		<dd pn="section-6.5-5.2.1.2">5</dd>
	<t>Shared Risk Link Group Value: SRLG value as defined in <xref	<dt pn="section-6.5-5.2.1.3">Length:</dt>
	target="RFC5307"/>.</t>	<dd pn="section-6.5-5.2.1.4">variable, dependent on number of SRLG
	</list></t>	values. <bcp14>MUST</bcp14> be a
		multiple of 4 octets.</dd>
	<t>The IS-IS FAESRLG Sub-TLV MUST NOT appear more than once in a single	<dt pn="section-6.5-5.2.1.5">Shared Risk Link Group Value:</dt>
	IS-IS FAD	<dd pn="section-6.5-5.2.1.6">SRLG value, as defined in <xref targe
	Sub-TLV. If it appears more than once, the IS-IS FAD Sub-TLV MUST be	t="RFC5307" format="default" sectionFormat="of" derivedContent="RFC5307"/>.</dd>
		</dl>
		</dd>
		</dl>
		<t indent="0" pn="section-6.5-6">The IS-IS FAESRLG sub-TLV <bcp14>MUST N
		OT</bcp14> appear more than once in a single IS-IS FAD
		sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV <bcp14>MUST
		</bcp14> be
	ignored by the receiver.</t>	ignored by the receiver.</t>

		<t indent="0" pn="section-6.5-7">The IS-IS FAESRLG sub-TLV <bcp14>MAY</b
	<t>The IS-IS FAESRLG Sub-TLV MAY appear more than once in the set of FAD	cp14> appear more than once in the set of FAD
	sub-TLVs for a given Flex-Algorithm from a given IS. This may be necessa ry in cases	sub-TLVs for a given Flex-Algorithm from a given IS. This may be necessa ry in cases

	where the total number of SRLG values which are specified cause the FAD	where the total number of SRLG values that are specified cause the FAD s
	sub-TLV to	ub-TLV to
	exceed the maximum length of a single FAD sub-TLV. In such a case the re	exceed the maximum length of a single FAD sub-TLV. In such a case, the r
	ceiver MUST	eceiver <bcp14>MUST</bcp14>
	use the union of all values across all IS-IS FAESRLG Sub-TLVs from such	use the union of all values across all IS-IS FAESRLG sub-TLVs from such
	set.</t>	set.</t>

	</section>	</section>
	</section>	</section>

		<section anchor="OSPFFADLTLVS" numbered="true" toc="include" removeInRFC="fa
	<section anchor="OSPFFADLTLVS" title="Sub-TLVs of OSPF FAD TLV">	lse" pn="section-7">
	<section anchor="OSPFFLEXALGEXLTLV"	<name slugifiedName="name-sub-tlvs-of-the-ospf-fad-tl">Sub-TLVs of the OSP
	title="OSPF Flexible Algorithm Exclude Admin Group Sub-TLV">	F FAD TLV</name>
	<t>The Flexible Algorithm Exclude Admin Group Sub-TLV (FAEAG Sub-TLV)	<section anchor="OSPFFLEXALGEXLTLV" numbered="true" toc="include" removeIn
	is a Sub-TLV of the OSPF FAD TLV. Its usage is described in <xref	RFC="false" pn="section-7.1">
	target="ISISFLEXALGEXLTLV"/>. It has the following format: <figure>	<name slugifiedName="name-ospf-flexible-algorithm-exc">OSPF Flexible Alg
	<artwork><![CDATA[	orithm Exclude Admin Group Sub-TLV</name>
		<t indent="0" pn="section-7.1-1">The OSPF Flexible Algorithm Exclude Adm
		in Group (FAEAG) sub-TLV
		is a sub-TLV of the OSPF FAD TLV. Its usage is described in <xref target
		="ISISFLEXALGEXLTLV" format="default" sectionFormat="of" derivedContent="Section
		6.1"/>. It has the following format: </t>
		<artwork name="" type="" align="left" alt="" pn="section-7.1-2">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Extended Admin Group \|	\| Extended Admin Group \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where:	</artwork>
	]]></artwork>	<dl newline="true" spacing="normal" indent="3" pn="section-7.1-3">
	</figure> <list style="hanging">	<dt pn="section-7.1-3.1">where:</dt>
	<t>Type: 1</t>	<dd pn="section-7.1-3.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-7.1-3.2.
	<t>Length: variable, dependent on the size of the Extended Admin	1">
	Group. MUST be a multiple of 4 octets.</t>	<dt pn="section-7.1-3.2.1.1">Type:</dt>
		<dd pn="section-7.1-3.2.1.2">1</dd>
	<t>Extended Administrative Group: Extended Administrative Group as	<dt pn="section-7.1-3.2.1.3">Length:</dt>
	defined in <xref target="RFC7308"/>.</t>	<dd pn="section-7.1-3.2.1.4">variable, dependent on the size of th
	</list></t>	e Extended Admin
		Group. <bcp14>MUST</bcp14> be a multiple of 4 octets.</dd>
	<t>The OSPF FAEAG Sub-TLV MUST NOT appear more than once in an OSPF	<dt pn="section-7.1-3.2.1.5">Extended Administrative Group:</dt>
	FAD TLV. If it appears more than once, the OSPF FAD TLV MUST be	<dd pn="section-7.1-3.2.1.6">Extended Administrative Group, as
		defined in <xref target="RFC7308" format="default" sectionFormat=
		"of" derivedContent="RFC7308"/>.</dd>
		</dl>
		</dd>
		</dl>
		<t indent="0" pn="section-7.1-4">The OSPF FAEAG sub-TLV <bcp14>MUST NOT<
		/bcp14> appear more than once in an OSPF
		FAD TLV. If it appears more than once, the OSPF FAD TLV <bcp14>MUST</bcp
		14> be
	ignored by the receiver.</t>	ignored by the receiver.</t>
	</section>	</section>

		<section anchor="OSPFFLEXALGINCANYTLV" numbered="true" toc="include" remov
	<section anchor="OSPFFLEXALGINCANYTLV"	eInRFC="false" pn="section-7.2">
	title="OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV">	<name slugifiedName="name-ospf-flexible-algorithm-inc">OSPF Flexible Alg
		orithm Include-Any Admin Group Sub-TLV</name>
	<t>The OSPF Flexible Algorithm Include-Any Admin Group	<t indent="0" pn="section-7.2-1">The OSPF Flexible Algorithm Include-Any
	Sub-TLV is a Sub-TLV of the OSPF FAD TLV. The usage of this Sub-TLVs is	Admin Group
	described in <xref	sub-TLV is a sub-TLV of the OSPF FAD TLV. The usage of this sub-TLV is d
	target="ISISFLEXALGINCANYTLV"/>. It has the following format: <figure>	escribed in <xref target="ISISFLEXALGINCANYTLV" format="default" sectionFormat="
	<artwork><![CDATA[	of" derivedContent="Section 6.2"/>. It has the following format: </t>
		<artwork name="" type="" align="left" alt="" pn="section-7.2-2">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Extended Admin Group \|	\| Extended Admin Group \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where:	</artwork>
	]]></artwork>	<dl newline="true" spacing="normal" indent="3" pn="section-7.2-3">
	</figure> <list style="hanging">	<dt pn="section-7.2-3.1">where:</dt>
	<t>Type: 2</t>	<dd pn="section-7.2-3.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-7.2-3.2.
	<t>Length: variable, dependent on the size of the Extended Admin	1">
	Group. MUST be a multiple of 4 octets.</t>	<dt pn="section-7.2-3.2.1.1">Type: </dt>
		<dd pn="section-7.2-3.2.1.2">2</dd>
	<t>Extended Administrative Group: Extended Administrative Group as	<dt pn="section-7.2-3.2.1.3">Length:</dt>
	defined in <xref target="RFC7308"/>.</t>	<dd pn="section-7.2-3.2.1.4">variable, dependent on the size of th
	</list></t>	e Extended Admin
		Group. <bcp14>MUST</bcp14> be a multiple of 4 octets.</dd>
	<t>The OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV MUST	<dt pn="section-7.2-3.2.1.5">Extended Administrative Group:</dt>
	NOT appear more than once in an OSPF FAD TLV. If it appears more than	<dd pn="section-7.2-3.2.1.6">Extended Administrative Group, as
	once, the OSPF FAD TLV MUST be ignored by the receiver.</t>	defined in <xref target="RFC7308" format="default" sectionFormat="
		of" derivedContent="RFC7308"/>.</dd>
		</dl>
		</dd>
		</dl>
		<t indent="0" pn="section-7.2-4">The OSPF Flexible Algorithm Include-Any
		Admin Group sub-TLV <bcp14>MUST NOT</bcp14> appear more than once in an OSPF FA
		D TLV. If it appears more than
		once, the OSPF FAD TLV <bcp14>MUST</bcp14> be ignored by the receiver.</
		t>
	</section>	</section>

		<section anchor="OSPFFLEXALGINCALLTLV" numbered="true" toc="include" remov
	<section anchor="OSPFFLEXALGINCALLTLV"	eInRFC="false" pn="section-7.3">
	title="OSPF Flexible Algorithm Include-All Admin Group Sub-TLV">	<name slugifiedName="name-ospf-flexible-algorithm-incl">OSPF Flexible Al
		gorithm Include-All Admin Group Sub-TLV</name>
	<t>The OSPF Flexible Algorithm Include-All Admin Group	<t indent="0" pn="section-7.3-1">The OSPF Flexible Algorithm Include-All
	Sub-TLV is a Sub-TLV of the OSPF FAD TLV. The usage of this Sub-TLVs is	Admin Group
	described in <xref target="ISISFLEXALGINCALLTLV"/>. It has the following	sub-TLV is a sub-TLV of the OSPF FAD TLV. The usage of this sub-TLV is
	format: <figure>	described in <xref target="ISISFLEXALGINCALLTLV" format="default" sectio
	<artwork><![CDATA[	nFormat="of" derivedContent="Section 6.3"/>. It has the following format: </t>
		<artwork name="" type="" align="left" alt="" pn="section-7.3-2">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Extended Admin Group \|	\| Extended Admin Group \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where:	</artwork>
	]]></artwork>	<dl newline="true" spacing="normal" indent="3" pn="section-7.3-3">
	</figure> <list style="hanging">	<dt pn="section-7.3-3.1">where:</dt>
	<t>Type: 3</t>	<dd pn="section-7.3-3.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-7.3-3.2.
	<t>Length: variable, dependent on the size of the Extended Admin	1">
	Group. MUST be a multiple of 4 octets.</t>	<dt pn="section-7.3-3.2.1.1">Type:</dt>
		<dd pn="section-7.3-3.2.1.2">3</dd>
	<t>Extended Administrative Group: Extended Administrative Group as	<dt pn="section-7.3-3.2.1.3">Length: </dt>
	defined in <xref target="RFC7308"/>.</t>	<dd pn="section-7.3-3.2.1.4">variable, dependent on the size of th
	</list></t>	e Extended Admin
		Group. <bcp14>MUST</bcp14> be a multiple of 4 octets.</dd>
	<t>The OSPF Flexible Algorithm Include-All Admin Group Sub-TLV MUST	<dt pn="section-7.3-3.2.1.5">Extended Administrative Group:</dt>
	NOT appear more than once in an OSPF FAD TLV. If it appears more than	<dd pn="section-7.3-3.2.1.6">Extended Administrative Group, as
	once, the OSPF FAD TLV MUST be ignored by the receiver.</t>	defined in <xref target="RFC7308" format="default" sectionFormat="
		of" derivedContent="RFC7308"/>.</dd>
		</dl>
		</dd>
		</dl>
		<t indent="0" pn="section-7.3-4">The OSPF Flexible Algorithm Include-All
		Admin Group sub-TLV <bcp14>MUST NOT</bcp14> appear more than once in an OSPF FA
		D TLV. If it appears more than
		once, the OSPF FAD TLV <bcp14>MUST</bcp14> be ignored by the receiver.</
		t>
	</section>	</section>

		<section anchor="OSPFFLEXALGFLAG" numbered="true" toc="include" removeInRF
	<section anchor="OSPFFLEXALGFLAG"	C="false" pn="section-7.4">
	title="OSPF Flexible Algorithm Definition Flags Sub-TLV">	<name slugifiedName="name-ospf-flexible-algorithm-defi">OSPF Flexible Al
	<t>The OSPF Flexible Algorithm Definition Flags Sub-TLV (FADF Sub-TLV)	gorithm Definition Flags Sub-TLV</name>
	is a Sub-TLV of the OSPF FAD TLV. It has the following format: <figure>	<t indent="0" pn="section-7.4-1">The OSPF Flexible Algorithm Definition
	<artwork><![CDATA[	Flags (FADF) sub-TLV
		is a sub-TLV of the OSPF FAD TLV. It has the following format: </t>
		<artwork name="" type="" align="left" alt="" pn="section-7.4-2">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Flags \|	\| Flags \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where:	</artwork>
	]]></artwork>	<dl newline="true" spacing="normal" indent="3" pn="section-7.4-3">
	</figure> <list style="hanging">	<dt pn="section-7.4-3.1">where:</dt>
	<t>Type: 4</t>	<dd pn="section-7.4-3.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-7.4-3.2.
	<t>Length: variable, dependent on the size of the Flags field.	1">
	MUST be a multiple of 4 octets.</t>	<dt pn="section-7.4-3.2.1.1">Type:</dt>
		<dd pn="section-7.4-3.2.1.2">4</dd>
	<t>Flags: <figure>	<dt pn="section-7.4-3.2.1.3">Length:</dt>
	<artwork><![CDATA[	<dd pn="section-7.4-3.2.1.4">variable, dependent on the size of th
		e Flags field.
		<bcp14>MUST</bcp14> be a multiple of 4 octets.</dd>
		<dt pn="section-7.4-3.2.1.5">Flags:</dt>
		<dd pn="section-7.4-3.2.1.6">
		<artwork name="" type="" align="left" alt="" pn="section-7.4-3.2
		.1.6.1">
	0 1 2 3 4 5 6 7...	0 1 2 3 4 5 6 7...
	+-+-+-+-+-+-+-+-+...	+-+-+-+-+-+-+-+-+...
	\|M\| \| \| ...	\|M\| \| \| ...
	+-+-+-+-+-+-+-+-+...	+-+-+-+-+-+-+-+-+...

	]]></artwork>	</artwork>
	</figure> <list style="hanging">	<dl newline="false" spacing="normal" indent="3" pn="section-7.4-
	<t>M-flag: when set, the Flex-Algorithm specific prefix and	3.2.1.6.2">
	ASBR metric MUST be used for inter-area and external prefix	<dt pn="section-7.4-3.2.1.6.2.1">M-flag:</dt>
	calculation. This flag is not applicable to prefixes	<dd pn="section-7.4-3.2.1.6.2.2">when set, the Flex-Algorithm-
	advertised as SRv6 locators.</t>	specific prefix and
	</list></t>	ASBR metric <bcp14>MUST</bcp14> be used for inter-area and externa
	</list></t>	l
		prefix calculation. This flag is not applicable to prefixes
	<t>A new IANA "IGP Flexible Algorithm Definition Flags Registry" is	advertised as SRv6 locators.</dd>
	defined for allocation of bits in the Flags field -	</dl>
	see <xref target="IANAFADFLGAS"/>.</t>	</dd>
		</dl>
	<t>Bits are defined/sent starting with Bit 0 defined above. Additional	</dd>
	bit definitions that may be defined in the future SHOULD be assigned	</dl>
	in ascending bit order so as to minimize the number of bits that will	<t indent="0" pn="section-7.4-4">A new IANA "IGP Flexible Algorithm Defi
		nition Flags" registry is
		defined for allocation of bits in the Flags field --
		see <xref target="IANAFADFLGAS" format="default" sectionFormat="of" deri
		vedContent="Section 18.2"/>.</t>
		<t indent="0" pn="section-7.4-5">Bits are defined/sent starting with bit
		0 defined above. Additional
		bit definitions that may be defined in the future <bcp14>SHOULD</bcp14>
		be assigned
		in ascending bit order to minimize the number of bits that will
	need to be transmitted.</t>	need to be transmitted.</t>

		<t indent="0" pn="section-7.4-6">Undefined bits <bcp14>MUST</bcp14> be t
	<t>Undefined bits MUST be transmitted as 0.</t>	ransmitted as 0.</t>
		<t indent="0" pn="section-7.4-7">Bits that are not transmitted <bcp14>MU
	<t>Bits that are not transmitted MUST be treated as if they are set to	ST</bcp14> be treated as if they are set to
	0 on receipt.</t>	0 on receipt.</t>

		<t indent="0" pn="section-7.4-8">The OSPF FADF sub-TLV <bcp14>MUST NOT</
	<t>The OSPF FADF Sub-TLV MUST NOT appear more than once in an OSPF FAD	bcp14> appear more than once in an OSPF FAD
	TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored by	TLV. If it appears more than once, the OSPF FAD TLV <bcp14>MUST</bcp14>
		be ignored by
	the receiver.</t>	the receiver.</t>

		<t indent="0" pn="section-7.4-9">If the OSPF FADF sub-TLV is not present
	<t>If the OSPF FADF Sub-TLV is not present inside the OSPF FAD TLV,	inside the OSPF FAD TLV,
	all the bits are assumed to be set to 0.</t>	all the bits are assumed to be set to 0.</t>

		<t indent="0" pn="section-7.4-10">If a node is configured to participate
	<t>If a node is configured to participate in a particular Flexible Algor	in a particular Flexible Algorithm,
	ithm,	but the selected Flex-Algorithm Definition includes a bit in the OSPF FA
	but the selected Flex-Algorithm definition includes a bit in the OSPF FA	DF sub-TLV
	DF Sub-TLV	that is not supported by the node, it <bcp14>MUST</bcp14> stop participa
	that is not supported by the node, it MUST stop participating in such	ting in such
	Flexible Algorithm.</t>	Flexible Algorithm.</t>

		<t indent="0" pn="section-7.4-11">New flag bits may be defined in the fu
	<t>New flag bits may be defined in the future. Implementations MUST chec	ture. Implementations <bcp14>MUST</bcp14> check all
	k all	advertised flag bits in the received OSPF FADF sub-TLV -- not just the s
	advertised flag bits in the received OSPF FADF Sub-TLV - not just the su	ubset
	bset
	currently defined.</t>	currently defined.</t>

		<t indent="0" pn="section-7.4-12">The M-flag <bcp14>MUST</bcp14> not be
	<t>M-flag MUST not be used when calculating prefix reachability for SRv6	used when calculating prefix reachability for the SRv6
	Locator prefix.</t>	Locator prefix.</t>


	</section>	</section>

		<section anchor="OSPFFLEXALGEXSRLGTLV" numbered="true" toc="include" remov
	<section anchor="OSPFFLEXALGEXSRLGTLV"	eInRFC="false" pn="section-7.5">
	title="OSPF Flexible Algorithm Exclude SRLG Sub-TLV">	<name slugifiedName="name-ospf-flexible-algorithm-excl">OSPF Flexible Al
	<t>The OSPF Flexible Algorithm Exclude SRLG Sub-TLV (FAESRLG Sub-TLV)	gorithm Exclude SRLG Sub-TLV</name>
	is a Sub-TLV of the OSPF FAD TLV. Its usage is described in <xref	<t indent="0" pn="section-7.5-1">The OSPF Flexible Algorithm Exclude SRL
	target="ISISFLEXALGEXSRLGTLV"/>. It has the following format: <figure>	G (FAESRLG) sub-TLV
	<artwork><![CDATA[	is a sub-TLV of the OSPF FAD TLV. Its usage is described in <xref target
		="ISISFLEXALGEXSRLGTLV" format="default" sectionFormat="of" derivedContent="Sect
		ion 6.5"/>. It has the following format: </t>
		<artwork name="" type="" align="left" alt="" pn="section-7.5-2">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Shared Risk Link Group Value \|	\| Shared Risk Link Group Value \|
	+- -+	+- -+
	\| ... \|	\| ... \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where:	</artwork>
	]]></artwork>	<dl newline="true" spacing="normal" indent="3" pn="section-7.5-3">
	</figure> <list style="hanging">	<dt pn="section-7.5-3.1">where:</dt>
	<t>Type: 5</t>	<dd pn="section-7.5-3.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-7.5-3.2.
	<t>Length: variable, dependent on the number of SRLGs. MUST be a	1">
	multiple of 4 octets.</t>	<dt pn="section-7.5-3.2.1.1">Type:</dt>
		<dd pn="section-7.5-3.2.1.2">5</dd>
	<t>Shared Risk Link Group Value: SRLG value as defined in <xref	<dt pn="section-7.5-3.2.1.3">Length:</dt>
	target="RFC4203"/>.</t>	<dd pn="section-7.5-3.2.1.4">variable, dependent on the number of
	</list></t>	SRLGs. <bcp14>MUST</bcp14> be a
		multiple of 4 octets.</dd>
	<t>The OSPF FAESRLG Sub-TLV MUST NOT appear more than once in an OSPF	<dt pn="section-7.5-3.2.1.5">Shared Risk Link Group Value:</dt>
	FAD TLV. If it appears more than once, the OSPF FAD TLV MUST be	<dd pn="section-7.5-3.2.1.6"> SRLG value, as defined in <xref targ
		et="RFC4203" format="default" sectionFormat="of" derivedContent="RFC4203"/>.</dd
		>
		</dl>
		</dd>
		</dl>
		<t indent="0" pn="section-7.5-4">The OSPF FAESRLG sub-TLV <bcp14>MUST NO
		T</bcp14> appear more than once in an OSPF
		FAD TLV. If it appears more than once, the OSPF FAD TLV <bcp14>MUST</bcp
		14> be
	ignored by the receiver.</t>	ignored by the receiver.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="ISISFLEXMETRIC" numbered="true" toc="include" removeInRFC="
	<section anchor="ISISFLEXMETRIC"	false" pn="section-8">
	title="IS-IS Flexible Algorithm Prefix Metric Sub-TLV">	<name slugifiedName="name-is-is-flexible-algorithm-pr">IS-IS Flexible Algo
	<t>The IS-IS Flexible Algorithm Prefix Metric (FAPM) Sub-TLV supports the	rithm Prefix Metric Sub-TLV</name>
	advertisement of a Flex-Algorithm specific prefix metric associated with	<t indent="0" pn="section-8-1">The IS-IS Flexible Algorithm Prefix Metric
		(FAPM) sub-TLV supports the
		advertisement of a Flex-Algorithm-specific prefix metric associated with
	a given prefix advertisement.</t>	a given prefix advertisement.</t>

		<t indent="0" pn="section-8-2">The IS-IS FAPM sub-TLV is a sub-TLV of TLVs
	<t>The IS-IS FAPM Sub-TLV is a sub-TLV of TLVs 135, 235, 236, and 237 and	135, 235, 236, and 237 and
	has the following format: <figure>	has the following format: </t>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt="" pn="section-8-3">
	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 \|Flex-Algorithm \|	\| Type \| Length \|Flex-Algorithm \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Metric \|	\| Metric \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where:	</artwork>
	]]></artwork>	<dl newline="true" spacing="normal" indent="3" pn="section-8-4">
	</figure> <list style="hanging">	<dt pn="section-8-4.1">where:</dt>
	<t>Type: 6</t>	<dd pn="section-8-4.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-8-4.2.1">
	<t>Length: 5 octets</t>	<dt pn="section-8-4.2.1.1">Type:</dt>
		<dd pn="section-8-4.2.1.2">6</dd>
	<t>Flex-Algorithm: Single octet value between 128 and 255	<dt pn="section-8-4.2.1.3">Length:</dt>
	inclusive.</t>	<dd pn="section-8-4.2.1.4">5 octets</dd>
		<dt pn="section-8-4.2.1.5">Flex-Algorithm:</dt>
	<t>Metric: 4 octets of metric information</t>	<dd pn="section-8-4.2.1.6">single octet value between 128 and 255
	</list></t>	inclusive.</dd>
		<dt pn="section-8-4.2.1.7">Metric:</dt>
	<t>The IS-IS FAPM Sub-TLV MAY appear multiple times in its parent TLV. If	<dd pn="section-8-4.2.1.8">4 octets of metric information.</dd>
		</dl>
		</dd>
		</dl>
		<t indent="0" pn="section-8-5">The IS-IS FAPM sub-TLV <bcp14>MAY</bcp14> a
		ppear multiple times in its parent TLV. If
	it appears more than once with the same Flex-Algorithm value, the first	it appears more than once with the same Flex-Algorithm value, the first

	instance MUST be used and any subsequent instances MUST be ignored.</t>	instance <bcp14>MUST</bcp14> be used and any subsequent instances <bcp14>M
		UST</bcp14> be ignored.</t>
	<t>If a prefix is advertised with a Flex-Algorithm prefix metric larger	<t indent="0" pn="section-8-6">If a prefix is advertised with a Flex-Algor
	than MAX_PATH_METRIC as defined in <xref target="RFC5305"/> this prefix	ithm prefix metric larger
	MUST NOT be considered during the Flexible Algorithm computation.</t>	than MAX_PATH_METRIC, as defined in <xref target="RFC5305" format="default
		" sectionFormat="of" derivedContent="RFC5305"/>, this prefix
	<t>The usage of the Flex-Algorithm prefix metric is described in <xref	<bcp14>MUST NOT</bcp14> be considered during the Flexible Algorithm comput
	target="FLEXALGPATHCALC"/>.</t>	ation.</t>
		<t indent="0" pn="section-8-7">The usage of the Flex-Algorithm prefix metr
	<t>The IS-IS FAPM Sub-TLV MUST NOT be advertised as a sub-TLV of the IS-IS	ic is described in <xref target="FLEXALGPATHCALC" format="default" sectionFormat
	SRv6 Locator TLV <xref target="I-D.ietf-lsr-isis-srv6-extensions"/>. The	="of" derivedContent="Section 13"/>.</t>
	IS-IS SRv6 Locator TLV includes the Algorithm and Metric fields which	<t indent="0" pn="section-8-8">The IS-IS FAPM sub-TLV <bcp14>MUST NOT</bcp
	MUST be used instead. If the FAPM Sub-TLV is present as a sub-TLV of the	14> be advertised as a sub-TLV of the IS-IS
	IS-IS SRv6 Locator TLV in the received LSP, such FAPM Sub-TLV MUST be	SRv6 Locator TLV <xref target="RFC9352" format="default" sectionFormat="of
		" derivedContent="RFC9352"/>. The
		IS-IS SRv6 Locator TLV includes the Algorithm and Metric fields, which
		<bcp14>MUST</bcp14> be used instead. If the FAPM sub-TLV is present as a s
		ub-TLV of the
		IS-IS SRv6 Locator TLV in the received LSP, such FAPM sub-TLV <bcp14>MUST<
		/bcp14> be
	ignored.</t>	ignored.</t>
	</section>	</section>

		<section anchor="OSPFFLEXMETRIC" numbered="true" toc="include" removeInRFC="
	<section anchor="OSPFFLEXMETRIC"	false" pn="section-9">
	title="OSPF Flexible Algorithm Prefix Metric Sub-TLV">	<name slugifiedName="name-ospf-flexible-algorithm-pre">OSPF Flexible Algor
	<t>The OSPF Flexible Algorithm Prefix Metric (FAPM) Sub-TLV supports the	ithm Prefix Metric Sub-TLV</name>
	advertisement of a Flex-Algorithm specific prefix metric associated with	<t indent="0" pn="section-9-1">The OSPF Flexible Algorithm Prefix Metric (
		FAPM) sub-TLV supports the
		advertisement of a Flex-Algorithm-specific prefix metric associated with
	a given prefix advertisement.</t>	a given prefix advertisement.</t>

		<t indent="0" pn="section-9-2">The OSPF FAPM sub-TLV is a sub-TLV of the:<
	<t>The OSPF Flex-Algorithm Prefix Metric (FAPM) Sub-TLV is a Sub-TLV of	/t>
	the: <list style="hanging">	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9-3
	<t>- OSPFv2 Extended Prefix TLV <xref target="RFC7684"/></t>	">
		<li pn="section-9-3.1">OSPFv2 Extended Prefix TLV <xref target="RFC7684"
	<t>- Following OSPFv3 TLVs as defined in <xref target="RFC8362"/>:	format="default" sectionFormat="of" derivedContent="RFC7684"/>
	<list style="hanging">	and</li>
	<t>Inter-Area Prefix TLV</t>	<li pn="section-9-3.2">
		<t indent="0" pn="section-9-3.2.1">following OSPFv3 TLVs, as defined i
	<t>External Prefix TLV</t>	n <xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC
	</list></t>	8362"/>:</t>
	</list></t>	<ul bare="false" empty="false" indent="3" spacing="normal" pn="section
		-9-3.2.2">
	<t>OSPF FAPM Sub-TLV has the following format: <figure>	<li pn="section-9-3.2.2.1">Inter-Area Prefix TLV</li>
	<artwork><![CDATA[	<li pn="section-9-3.2.2.2">External-Prefix TLV</li>
		</ul>
		</li>
		</ul>
		<t indent="0" pn="section-9-4">The OSPF FAPM sub-TLV has the following for
		mat: </t>
		<artwork name="" type="" align="left" alt="" pn="section-9-5">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|Flex-Algorithm \| Flags \| Reserved \|	\|Flex-Algorithm \| Flags \| Reserved \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Metric \|	\| Metric \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		</artwork>
	where:	<dl newline="true" spacing="normal" indent="3" pn="section-9-6">
	]]></artwork>	<dt pn="section-9-6.1">where:</dt>
	</figure> <list style="hanging">	<dd pn="section-9-6.2">
	<t>Type: 3 for OSPFv2, 26 for OSPFv3</t>	<dl newline="false" spacing="normal" indent="3" pn="section-9-6.2.1">
		<dt pn="section-9-6.2.1.1">Type:</dt>
	<t>Length: 8 octets</t>	<dd pn="section-9-6.2.1.2">3 for OSPFv2, and 26 for OSPFv3</dd>
		<dt pn="section-9-6.2.1.3">Length:</dt>
	<t>Flex-Algorithm: Single octet value between 128 and 255	<dd pn="section-9-6.2.1.4">8 octets</dd>
	inclusive.</t>	<dt pn="section-9-6.2.1.5">Flex-Algorithm:</dt>
		<dd pn="section-9-6.2.1.6">single octet value between 128 and 255
	<t>Flags: One octet value <figure>	inclusive.</dd>
	<artwork><![CDATA[	<dt pn="section-9-6.2.1.7">Flags:</dt>
		<dd pn="section-9-6.2.1.8">
		<t indent="0" pn="section-9-6.2.1.8.1">1-octet value</t>
		<artwork name="" type="" align="left" alt="" pn="section-9-6.2.1.8
		.2">
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|E\| \|	\|E\| \|
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+

	]]></artwork>	</artwork>
	</figure> <list style="hanging">	<dl newline="false" spacing="normal" indent="3" pn="section-9-6.2.
	<t>E bit : position 0: The type of external metric. If bit is	1.8.3">
	set, the metric specified is a Type 2 external metric. This bit	<dt pn="section-9-6.2.1.8.3.1">E bit:</dt>
	is applicable only to OSPF External and NSSA external prefixes.	<dd pn="section-9-6.2.1.8.3.2">position 0: The type of external
	This is semantically the same as the E bit in section A.4.5 of <xr	metric. If the bit is
	ef	set, the metric specified is a Type 2 external metric. This bit
	target="RFC2328"/> and section A.4.7 of <xref target="RFC5340"/>	is applicable only to OSPF external and Not-So-Stubby Area (NSSA) ex
	for OSPFv2 and OSPFv3 respectively.</t>	ternal prefixes.
		This is semantically the same as the E bit in <xref target="RFC2328"
	<t>Bits 1 through 7: MUST be cleared by originator and ignored by	format="default" sectionFormat="of" section="A.4.5" derivedLink="https://rfc-ed
	receiver.</t>	itor.org/rfc/rfc2328#appendix-A.4.5" derivedContent="RFC2328"/> and <xref target
	</list></t>	="RFC5340" format="default" sectionFormat="of" section="A.4.7" derivedLink="http
		s://rfc-editor.org/rfc/rfc5340#appendix-A.4.7" derivedContent="RFC5340"/> for OS
	<t>Reserved: MUST be set to 0, ignored at reception.</t>	PFv2 and OSPFv3, respectively.</dd>
		<dt pn="section-9-6.2.1.8.3.3">Bits 1 through 7:</dt>
	<t>Metric: 4 octets of metric information</t>	<dd pn="section-9-6.2.1.8.3.4">
	</list></t>	<bcp14>MUST</bcp14> be cleared by the originator and ignored b
		y
	<t>The OSPF FAPM Sub-TLV MAY appear multiple times in its parent TLV. If	the receiver.</dd>
		</dl>
		</dd>
		<dt pn="section-9-6.2.1.9">Reserved:</dt>
		<dd pn="section-9-6.2.1.10">
		<bcp14>MUST</bcp14> be set to 0 and ignored at reception.</dd>
		<dt pn="section-9-6.2.1.11">Metric:</dt>
		<dd pn="section-9-6.2.1.12">4 octets of metric information.</dd>
		</dl>
		</dd>
		</dl>
		<t indent="0" pn="section-9-7">The OSPF FAPM sub-TLV <bcp14>MAY</bcp14> ap
		pear multiple times in its parent TLV. If
	it appears more than once with the same Flex-Algorithm value, the first	it appears more than once with the same Flex-Algorithm value, the first

	instance MUST be used and any subsequent instances MUST be ignored.</t>	instance <bcp14>MUST</bcp14> be used and any subsequent instances <bcp14>M
		UST</bcp14> be ignored.</t>
	<t>The usage of the Flex-Algorithm prefix metric is described in <xref	<t indent="0" pn="section-9-8">The usage of the Flex-Algorithm prefix metr
	target="FLEXALGPATHCALC"/>.</t>	ic is described in <xref target="FLEXALGPATHCALC" format="default" sectionFormat
		="of" derivedContent="Section 13"/>.</t>
	</section>	</section>

		<section anchor="OSPFASBR" numbered="true" toc="include" removeInRFC="false"
	<section anchor="OSPFASBR"	pn="section-10">
	title="OSPF Flexible Algorithm ASBR Reachability Advertisement">	<name slugifiedName="name-ospf-flexible-algorithm-asb">OSPF Flexible Algor
	<t>An OSPF ABR advertises the reachability of ASBRs in its attached	ithm ASBR Reachability Advertisement</name>
		<t indent="0" pn="section-10-1">An OSPF ABR advertises the reachability of
		ASBRs in its attached
	areas to enable routers within those areas to perform route calculations	areas to enable routers within those areas to perform route calculations
	for external prefixes advertised by the ASBRs. OSPF extensions for	for external prefixes advertised by the ASBRs. OSPF extensions for

	advertisement of Flex-Algorithm specific reachability and metric for	advertisement of Flex-Algorithm-specific reachability and the metric for
	ASBRs is similarly required for Flex-Algorithm external prefix	ASBRs is similarly required for Flex-Algorithm external prefix

	computations as described further in <xref	computations, as described further in <xref target="FLEXALGPATHCALCINTER"
	target="FLEXALGPATHCALCINTER"/>.</t>	format="default" sectionFormat="of" derivedContent="Section 13.1"/>.</t>
		<section anchor="OSPFEXTASBRLSA" numbered="true" toc="include" removeInRFC
	<section anchor="OSPFEXTASBRLSA"	="false" pn="section-10.1">
	title="OSPFv2 Extended Inter-Area ASBR LSA">	<name slugifiedName="name-ospfv2-extended-inter-area-">OSPFv2 Extended I
	<t>The OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA is an OSPF	nter-Area ASBR LSA</name>
	Opaque LSA <xref target="RFC5250"/> that is used to advertise	<t indent="0" pn="section-10.1-1">The OSPFv2 Extended Inter-Area ASBR (E
		IA-ASBR) LSA is an OSPF
		Opaque LSA <xref target="RFC5250" format="default" sectionFormat="of" de
		rivedContent="RFC5250"/> that is used to advertise
	additional attributes related to the reachability of the OSPFv2 ASBR	additional attributes related to the reachability of the OSPFv2 ASBR
	that is external to the area yet internal to the OSPF domain.	that is external to the area yet internal to the OSPF domain.
	Semantically, the OSPFv2 EIA-ASBR LSA is equivalent to the fixed	Semantically, the OSPFv2 EIA-ASBR LSA is equivalent to the fixed

	format Type 4 Summary LSA <xref target="RFC2328"/>. Unlike the Type 4	format Type 4 summary-LSA <xref target="RFC2328" format="default" sectio
	Summary LSA, the LSID of the EIA-ASBR LSA does not carry the ASBR	nFormat="of" derivedContent="RFC2328"/>. Unlike the Type 4
	Router-ID - the ASBR Router-ID is carried in the body of the LSA.	summary-LSA, the Link State ID (LSID) of the EIA-ASBR LSA does not carry
	The OSPFv2 EIA-ASBR LSA is advertised by an OSPFv2 ABR and its flooding	the ASBR
	is	Router ID -- the ASBR Router ID is carried in the body of the LSA.
		The OSPFv2 EIA-ASBR LSA is advertised by an OSPFv2 ABR, and its flooding
		is
	defined to be area-scoped only.</t>	defined to be area-scoped only.</t>

		<t indent="0" pn="section-10.1-2">An OSPFv2 ABR generates the EIA-ASBR L
	<t>An OSPFv2 ABR generates the EIA-ASBR LSA for an ASBR when it is	SA for an ASBR when it is
	advertising the Type-4 Summary LSA for it and has the need for	advertising the Type 4 summary-LSA for it and has the need for
	advertising additional attributes for that ASBR beyond what is	advertising additional attributes for that ASBR beyond what is

	conveyed in the fixed format Type-4 Summary LSA. An OSPFv2 ABR MUST	conveyed in the fixed-format Type 4 summary-LSA. An OSPFv2 ABR <bcp14>MU
	NOT advertise the EIA-ASBR LSA for an ASBR for which it is not	ST NOT</bcp14> advertise the EIA-ASBR LSA for an ASBR for which it is not
	advertising the Type 4 Summary LSA. This ensures that the ABR does not	advertising the Type 4 summary-LSA. This ensures that the ABR does not
	generate the EIA-ASBR LSA for an ASBR to which it does not have	generate the EIA-ASBR LSA for an ASBR to which it does not have
	reachability in the base OSPFv2 topology calculation. The OSPFv2 ABR	reachability in the base OSPFv2 topology calculation. The OSPFv2 ABR

	SHOULD NOT advertise the EIA-ASBR LSA for an ASBR when it does not	<bcp14>SHOULD NOT</bcp14> advertise the EIA-ASBR LSA for an ASBR when it does not
	have additional attributes to advertise for that ASBR.</t>	have additional attributes to advertise for that ASBR.</t>

		<t indent="0" pn="section-10.1-3">The OSPFv2 EIA-ASBR LSA has the follow
	<t>The OSPFv2 EIA-ASBR LSA has the following format: <figure>	ing format: </t>
	<artwork><![CDATA[	<artwork name="" type="" align="left" alt="" pn="section-10.1-4">
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| LS age \| Options \| LS Type \|	\| LS age \| Options \| LS Type \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Opaque Type \| Opaque ID \|	\| Opaque Type \| Opaque ID \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Advertising Router \|	\| Advertising Router \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| LS sequence number \|	\| LS sequence number \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| LS checksum \| Length \|	\| LS checksum \| Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \|	\| \|
	+- TLVs -+	+- TLVs -+
	\| ... \|	\| ... \|
		</artwork>
	]]></artwork>	<t indent="0" pn="section-10.1-5">The LS age and Options fields are as d
	</figure></t>	efined in
		<xref target="RFC2328" format="default" sectionFormat="of" section="A.4.
	<t>LS age and Options fields are as defined in Section A.4.1. of	1" derivedLink="https://rfc-editor.org/rfc/rfc2328#appendix-A.4.1" derivedConten
	<xref target="RFC2328"/>.</t>	t="RFC2328"/>.</t>
		<t indent="0" pn="section-10.1-6">The LS Type <bcp14>MUST</bcp14> be 10,
	<t>The LS Type MUST be 10, indicating that the Opaque	indicating that the Opaque
	LSA flooding scope is area-local <xref target="RFC5250"/>.</t>	LSA flooding scope is area-local <xref target="RFC5250" format="default"
		sectionFormat="of" derivedContent="RFC5250"/>.</t>
	<t>The Opaque Type used by the OSPFv2 EIA-ASBR LSA is 11.	<t indent="0" pn="section-10.1-7">The Opaque Type used by the OSPFv2 EIA
		-ASBR LSA is 11.
	The Opaque Type is used to differentiate the various types	The Opaque Type is used to differentiate the various types

	of OSPFv2 Opaque LSAs and is described in Section 3 of <xref	of OSPFv2 Opaque LSAs and is described in <xref target="RFC5250" section
	target="RFC5250"/>.</t>	="3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc
		/rfc5250#section-3" derivedContent="RFC5250"/>.</t>
	<t>The Opaque ID field is an arbitrary value used to maintain multiple	<t indent="0" pn="section-10.1-8">The Opaque ID field is an arbitrary va
		lue used to maintain multiple
	OSPFv2 EIA-ASBR LSAs. For OSPFv2 EIA-ASBR LSAs, the Opaque ID has no	OSPFv2 EIA-ASBR LSAs. For OSPFv2 EIA-ASBR LSAs, the Opaque ID has no
	semantic significance other than to differentiate OSPFv2 EIA-ASBR LSAs	semantic significance other than to differentiate OSPFv2 EIA-ASBR LSAs
	originated by the same OSPFv2 ABR. If multiple OSPFv2 EIA-ASBR LSAs	originated by the same OSPFv2 ABR. If multiple OSPFv2 EIA-ASBR LSAs
	specify the same ASBR, the attributes from the Opaque LSA with the	specify the same ASBR, the attributes from the Opaque LSA with the

	lowest Opaque ID SHOULD be used.</t>	lowest Opaque ID <bcp14>SHOULD</bcp14> be used.</t>
		<t indent="0" pn="section-10.1-9">The Advertising Router, LS sequence nu
	<t>Advertising Router, LS sequence number, and LS checksum fields are as	mber, and LS checksum fields are as defined in
	defined in	<xref target="RFC2328" format="default" sectionFormat="of" section="A.4.
	Section A.4.1. of <xref target="RFC2328"/>.</t>	1" derivedLink="https://rfc-editor.org/rfc/rfc2328#appendix-A.4.1" derivedConten
		t="RFC2328"/>.</t>
	<t>The Length field is as defined in Section A.4.1. of <xref target="RFC	<t indent="0" pn="section-10.1-10">The Length field is as defined in <xr
	5250"/>.	ef target="RFC2328" format="default" sectionFormat="of" section="A.4.1" derivedL
		ink="https://rfc-editor.org/rfc/rfc2328#appendix-A.4.1" derivedContent="RFC2328"
		/>.
	It represents the total length (in octets) of the Opaque LSA, including the	It represents the total length (in octets) of the Opaque LSA, including the
	LSA header and all TLVs (including padding).</t>	LSA header and all TLVs (including padding).</t>

		<t indent="0" pn="section-10.1-11">The format of the TLVs within the bod
	<t>The format of the TLVs within the body of the OSPFv2 EIA-ASBR LSA	y of the OSPFv2 EIA-ASBR LSA
	is the same as the format used by the Traffic Engineering Extensions	is the same as the format used by the Traffic Engineering Extensions

	to OSPFv2 <xref target="RFC3630"/>. The variable TLV section consists	to OSPFv2 <xref target="RFC3630" format="default" sectionFormat="of" der ivedContent="RFC3630"/>. The variable TLV section consists
	of one or more nested TLV tuples. Nested TLVs are also referred to as	of one or more nested TLV tuples. Nested TLVs are also referred to as

	sub- TLVs. The TLV Length field defines the length of the value portion in	sub-TLVs. The TLV Length field defines the length of the value portion i n
	octets (thus, a TLV with no value portion would have a length of 0).	octets (thus, a TLV with no value portion would have a length of 0).
	The TLV is padded to 4-octet alignment; padding is not included in the	The TLV is padded to 4-octet alignment; padding is not included in the
	Length field (so a 3-octet value would have a length of 3, but the	Length field (so a 3-octet value would have a length of 3, but the
	total size of the TLV would be 8 octets). Nested TLVs are also 32-bit	total size of the TLV would be 8 octets). Nested TLVs are also 32-bit
	aligned. For example, a 1-octet value would have the Length field set	aligned. For example, a 1-octet value would have the Length field set
	to 1, and 3 octets of padding would be added to the end of the value	to 1, and 3 octets of padding would be added to the end of the value
	portion of the TLV. The padding is composed of zeros.</t>	portion of the TLV. The padding is composed of zeros.</t>

		<section anchor="OSPFEXTASBRTLV" numbered="true" toc="include" removeInR
	<section anchor="OSPFEXTASBRTLV"	FC="false" pn="section-10.1.1">
	title="OSPFv2 Extended Inter-Area ASBR TLV">	<name slugifiedName="name-ospfv2-extended-inter-area-a">OSPFv2 Extende
	<t>The OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) TLV is a top-level	d Inter-Area ASBR TLV</name>
		<t indent="0" pn="section-10.1.1-1">The OSPFv2 Extended Inter-Area ASB
		R (EIA-ASBR) TLV is a top-level
	TLV of the OSPFv2 EIA-ASBR LSA and is used to advertise additional	TLV of the OSPFv2 EIA-ASBR LSA and is used to advertise additional
	attributes associated with the reachability of an ASBR.</t>	attributes associated with the reachability of an ASBR.</t>

		<t indent="0" pn="section-10.1.1-2">The OSPFv2 EIA-ASBR TLV has the fo
	<t>The OSPFv2 EIA-ASBR TLV has the following format:</t>	llowing format:</t>
		<artwork name="" type="" align="left" alt="" pn="section-10.1.1-3">
	<t><figure>	0 1 2 3
	<artwork><![CDATA[ 0 1 2	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
	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	\| Type \| Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \|	\| ASBR Router ID \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| ASBR Router ID \|	. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	. Sub-TLVs .
	. .	. .
	. Sub-TLVs .	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. .	</artwork>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dl newline="true" spacing="normal" indent="3" pn="section-10.1.1-4">
		<dt pn="section-10.1.1-4.1">where:</dt>
	where:	<dd pn="section-10.1.1-4.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-10.1.1
	]]></artwork>	-4.2.1">
	</figure></t>	<dt pn="section-10.1.1-4.2.1.1">Type:</dt>
		<dd pn="section-10.1.1-4.2.1.2">1</dd>
	<t><list style="hanging">	<dt pn="section-10.1.1-4.2.1.3">Length:</dt>
	<t>Type: 1</t>	<dd pn="section-10.1.1-4.2.1.4">variable number of octets.</dd>
		<dt pn="section-10.1.1-4.2.1.5">ASBR Router ID:</dt>
	<t>Length: variable number of octets</t>	<dd pn="section-10.1.1-4.2.1.6">4 octets carrying the OSPF Route
		r ID of
	<t>ASBR Router ID: four octets carrying the OSPF Router ID of	the ASBR whose information is being carried.</dd>
	the ASBR whose information is being carried.</t>	<dt pn="section-10.1.1-4.2.1.7">Sub-TLVs:</dt>
		<dd pn="section-10.1.1-4.2.1.8">variable</dd>
	<t>Sub-TLVs : variable</t>	</dl>
	</list></t>	</dd>
		</dl>
	<t>Only a single OSPFv2 EIA-ASBR TLV MUST be advertised in each	<t indent="0" pn="section-10.1.1-5">Only a single OSPFv2 EIA-ASBR TLV
	OSPFv2 EIA-ASBR LSA and the receiver MUST ignore all instances of	<bcp14>MUST</bcp14> be advertised in each
		OSPFv2 EIA-ASBR LSA, and the receiver <bcp14>MUST</bcp14> ignore all i
		nstances of
	this TLV other than the first one in an LSA.</t>	this TLV other than the first one in an LSA.</t>

		<t indent="0" pn="section-10.1.1-6">The OSPFv2 EIA-ASBR TLV <bcp14>MUS
	<t>OSPFv2 EIA-ASBR TLV MUST be present inside an OSPFv2 EIA-ASBR LSA	T</bcp14> be present inside an OSPFv2 EIA-ASBR LSA
	and MUST include at least a single sub-TLV, otherwise the OSPFv2	and <bcp14>MUST</bcp14> include at least a single sub-TLV; otherwise,
	EIA-ASBR LSA MUST be ignored by the receiver.</t>	the OSPFv2
		EIA-ASBR LSA <bcp14>MUST</bcp14> be ignored by the receiver.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="OSPFFAASBRMETRIC" numbered="true" toc="include" removeInR
	<section anchor="OSPFFAASBRMETRIC"	FC="false" pn="section-10.2">
	title="OSPF Flexible Algorithm ASBR Metric Sub-TLV">	<name slugifiedName="name-ospf-flexible-algorithm-asbr">OSPF Flexible Al
	<t>The OSPF Flexible Algorithm ASBR Metric (FAAM) Sub-TLV supports the	gorithm ASBR Metric Sub-TLV</name>
	advertisement of a Flex-Algorithm specific metric associated with a	<t indent="0" pn="section-10.2-1">The OSPF Flexible Algorithm ASBR Metri
		c (FAAM) sub-TLV supports the
		advertisement of a Flex-Algorithm-specific metric associated with a
	given ASBR reachability advertisement by an ABR.</t>	given ASBR reachability advertisement by an ABR.</t>

		<t indent="0" pn="section-10.2-2">The OSPF FAAM sub-TLV is a sub-TLV of
	<t>The OSPF Flex-Algorithm ASBR Metric (FAAM) Sub-TLV is a Sub-TLV of	the: </t>
	the: <list style="hanging">	<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1
	<t>- OSPFv2 Extended Inter-Area ASBR TLV as defined in <xref	0.2-3">
	target="OSPFEXTASBRTLV"/></t>	<li pn="section-10.2-3.1">OSPFv2 Extended Inter-Area ASBR TLV, as defi
		ned in <xref target="OSPFEXTASBRTLV" format="default" sectionFormat="of" derived
	<t>- OSPFv3 Inter-Area-Router TLV defined in <xref	Content="Section 10.1.1"/>, and</li>
	target="RFC8362"/></t>	<li pn="section-10.2-3.2">OSPFv3 Inter-Area-Router TLV, as defined in
	</list></t>	<xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC83
		62"/>.</li>
	<t>OSPF FAAM Sub-TLV has the following format: <figure>	</ul>
	<artwork><![CDATA[	<t indent="0" pn="section-10.2-4">The OSPF FAAM sub-TLV has the followin
		g format: </t>
		<artwork name="" type="" align="left" alt="" pn="section-10.2-5">
	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|Flex-Algorithm \| Reserved \|	\|Flex-Algorithm \| Reserved \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Metric \|	\| Metric \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		</artwork>
	where:	<dl newline="true" spacing="normal" indent="3" pn="section-10.2-6">
	]]></artwork>	<dt pn="section-10.2-6.1">where:</dt>
	</figure> <list style="hanging">	<dd pn="section-10.2-6.2">
	<t>Type: 1 for OSPFv2, 33 for OSPFv3</t>	<dl newline="false" spacing="normal" indent="3" pn="section-10.2-6.2
		.1">
	<t>Length: 8 octets</t>	<dt pn="section-10.2-6.2.1.1">Type:</dt>
		<dd pn="section-10.2-6.2.1.2">1 for OSPFv2, and 33 for OSPFv3</dd>
	<t>Flex-Algorithm: Single octet value between 128 and 255	<dt pn="section-10.2-6.2.1.3">Length:</dt>
	inclusive.</t>	<dd pn="section-10.2-6.2.1.4">8 octets</dd>
		<dt pn="section-10.2-6.2.1.5">Flex-Algorithm:</dt>
	<t>Reserved: Three octets. MUST be set to 0, ignored at reception.</	<dd pn="section-10.2-6.2.1.6">single octet value between 128 and 2
	t>	55
		inclusive.</dd>
	<t>Metric: 4 octets of metric information</t>	<dt pn="section-10.2-6.2.1.7">Reserved:</dt>
	</list></t>	<dd pn="section-10.2-6.2.1.8">3 octets. <bcp14>MUST</bcp14> be set
		to 0 and ignored at
	<t>The OSPF FAAM Sub-TLV MAY appear multiple times in its parent TLV.	reception.</dd>
		<dt pn="section-10.2-6.2.1.9">Metric:</dt>
		<dd pn="section-10.2-6.2.1.10">4 octets of metric information.</dd
		>
		</dl>
		</dd>
		</dl>
		<t indent="0" pn="section-10.2-7">The OSPF FAAM sub-TLV <bcp14>MAY</bcp1
		4> appear multiple times in its parent TLV.
	If it appears more than once with the same Flex-Algorithm value, the	If it appears more than once with the same Flex-Algorithm value, the

	first instance MUST be used and any subsequent instances MUST be	first instance <bcp14>MUST</bcp14> be used and any subsequent instances <bcp14>MUST</bcp14> be
	ignored.</t>	ignored.</t>

		<t indent="0" pn="section-10.2-8">The advertisement of the ASBR reachabi
	<t>The advertisement of the ASBR reachability using the OSPF FAAM	lity using the OSPF FAAM
	Sub-TLV inside the OSPFv2 EIA-ASBR LSA follows Section 12.4.3 of	sub-TLV inside the OSPFv2 EIA-ASBR LSA follows <xref target="RFC2328" se
	<xref target="RFC2328"/> and inside the OSPFv3 E-Inter-Area-Router LSA	ction="12.4.3" sectionFormat="of" format="default" derivedLink="https://rfc-edit
	follows Section 4.8.5 of <xref target="RFC5340"/>. The	or.org/rfc/rfc2328#section-12.4.3" derivedContent="RFC2328"/> and inside the OSP
		Fv3 E-Inter-Area-Router-LSA
		follows <xref target="RFC5340" section="4.8.5" sectionFormat="of" format
		="default" derivedLink="https://rfc-editor.org/rfc/rfc5340#section-4.8.5" derive
		dContent="RFC5340"/>. The
	reachability of the ASBR is evaluated in the context of the specific	reachability of the ASBR is evaluated in the context of the specific
	Flex-Algorithm.</t>	Flex-Algorithm.</t>

		<t indent="0" pn="section-10.2-9">The FAAM computed by the ABR will be e
	<t>The FAAM computed by the ABR will be equal to the metric to reach	qual to the metric to reach
	the ASBR for a given Flex-Algorithm in a source area or the cumulative	the ASBR for a given Flex-Algorithm in a source area or the cumulative

	metric via other ABR(s) when the ASBR is in a remote area. This is	metric via an ABR(s) when the ASBR is in a remote area. This is
	similar in nature to how the metric is set when the ASBR reachability	similar in nature to how the metric is set when the ASBR reachability
	metric is computed in the default algorithm for the metric in the	metric is computed in the default algorithm for the metric in the

	OSPFv2 Type 4 ASBR Summary LSA and the OSPFv3 Inter-Area-Router	OSPFv2 Type 4 ASBR summary-LSA and the OSPFv3 Inter-Area-Router-LSA.</t>
	LSA.</t>	<t indent="0" pn="section-10.2-10">An OSPF ABR <bcp14>MUST NOT</bcp14> i
		nclude the OSPF FAAM sub-TLV with a specific
	<t>An OSPF ABR MUST NOT include the OSPF FAAM Sub-TLV with a specific
	Flex-Algorithm in its reachability advertisement for an ASBR between	Flex-Algorithm in its reachability advertisement for an ASBR between
	areas unless that ASBR is reachable for it in the context of that	areas unless that ASBR is reachable for it in the context of that
	specific Flex-Algorithm.</t>	specific Flex-Algorithm.</t>

		<t indent="0" pn="section-10.2-11">An OSPF ABR <bcp14>MUST</bcp14> inclu
	<t>An OSPF ABR MUST include the OSPF FAAM Sub-TLVs as part of the ASBR	de the OSPF FAAM sub-TLVs as part of the ASBR
	reachability advertisement between areas for any Flex-Algorithm for	reachability advertisement between areas for any Flex-Algorithm for
	which the winning FAD includes the M-flag and the ASBR is reachable	which the winning FAD includes the M-flag and the ASBR is reachable
	in the context of that specific Flex-Algorithm.</t>	in the context of that specific Flex-Algorithm.</t>

		<t indent="0" pn="section-10.2-12">OSPF routers <bcp14>MUST</bcp14> use
	<t>OSPF routers MUST use the OSPF FAAM Sub-TLV to calculate the	the OSPF FAAM sub-TLV to calculate the
	reachability of the ASBRs if the winning FAD for the specific Flex-	reachability of the ASBRs if the winning FAD for the specific Flex-

	Algorithm includes the M-flag. OSPF routers MUST NOT use the OSPF FAAM	Algorithm includes the M-flag. OSPF routers <bcp14>MUST NOT</bcp14> use
	Sub-TLV to calculate the reachability of the ASBRs for the specific	the OSPF FAAM
		sub-TLV to calculate the reachability of the ASBRs for the specific
	Flex-Algorithm if the winning FAD for such Flex-Algorithm does not	Flex-Algorithm if the winning FAD for such Flex-Algorithm does not

	include the M-flag. Instead, the OSPFv2 Type 4 Summary LSAs or the	include the M-flag. Instead, the OSPFv2 Type 4 summary-LSAs or the
	OSPFv3 Inter-Area-Router-LSAs MUST be used instead as specified in	OSPFv3 Inter-Area-Router-LSAs <bcp14>MUST</bcp14> be used, as specified
	section 16.2 of <xref target="RFC2328"/> and section 4.8.5 of <xref	in
	target="RFC5340"/> for OSPFv2 and OSPFv3 respectively.</t>	<xref target="RFC2328" section="16.2" sectionFormat="of" format="default
		" derivedLink="https://rfc-editor.org/rfc/rfc2328#section-16.2" derivedContent="
	<t>The processing of a new or changed OSPF FAAM Sub-TLV triggers the	RFC2328"/> and <xref target="RFC5340" section="4.8.5" sectionFormat="of" format=
	processing of External routes similar to what is described in	"default" derivedLink="https://rfc-editor.org/rfc/rfc5340#section-4.8.5" derived
	section 16.5 of the <xref target="RFC2328"/> for OSPFv2 and section	Content="RFC5340"/> for OSPFv2 and OSPFv3, respectively.</t>
	4.8.5 of <xref target="RFC5340"/> for OSPFv3 for the specific	<t indent="0" pn="section-10.2-13">The processing of a new or changed OS
	Flex-Algorithm. The External and NSSA External route calculation	PF FAAM sub-TLV triggers the
	should be limited to Flex-Algorithm(s) for which the winning FAD(s)	processing of external routes similar to what is described in
		<xref target="RFC2328" format="default" sectionFormat="of" section="16.5
		" derivedLink="https://rfc-editor.org/rfc/rfc2328#section-16.5" derivedContent="
		RFC2328"/> for OSPFv2 and <xref target="RFC5340" section="4.8.5" sectionFormat="
		of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5340#section-4.8
		.5" derivedContent="RFC5340"/> for OSPFv3 for the specific
		Flex-Algorithm.
		The OSPF external and NSSA external route calculation
		should be limited to a Flex-Algorithm(s) for which the winning FAD(s)
	includes the M-flag.</t>	includes the M-flag.</t>

		<t indent="0" pn="section-10.2-14">Processing of the OSPF FAAM sub-TLV d
	<t>Processing of the OSPF FAAM Sub-TLV does not require the existence	oes not require the existence
	of the equivalent OSPFv2 Type 4 Summary LSA or the OSPFv3	of the equivalent OSPFv2 Type 4 summary-LSA or the OSPFv3
	Inter-Area-Router-LSA that is advertised by the same ABR inside the	Inter-Area-Router-LSA that is advertised by the same ABR inside the
	area. The presence of the base LSA is not mandatory for the usage of the	area. The presence of the base LSA is not mandatory for the usage of the

	extended LSA with the OSPF FAAM Sub-TLV.</t>	extended LSA with the OSPF FAAM sub-TLV.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="FLEXALGPART" numbered="true" toc="include" removeInRFC="fal
	<section anchor="FLEXALGPART"	se" pn="section-11">
	title="Advertisement of Node Participation in a Flex-Algorithm">	<name slugifiedName="name-advertisement-of-node-parti">Advertisement of No
	<t>When a router is configured to participate in a particular Flex-Algorit	de Participation in a Flex-Algorithm</name>
	hm and	<t indent="0" pn="section-11-1">When a router is configured to participate
		in a particular Flex-Algorithm and
	is advertising such participation, it is participating in that Flex-Algori thm.</t>	is advertising such participation, it is participating in that Flex-Algori thm.</t>

		<t indent="0" pn="section-11-2">Paths for various data planes <bcp14>MAY</
	<t>Paths for various data-planes MAY be computed for a specific Flex-Algor	bcp14> be computed for a specific Flex-Algorithm.
	ithm.	Each data plane uses its own specific forwarding over such Flex-Algorithm
	Each data-plane uses its own specific forwarding over such Flex-Algorithm	paths.
	paths.	To guarantee the presence of the data-plane-specific forwarding, associate
	To guarantee the presence of the data-plane specific forwarding, associate	d with
	d with	a particular Flex-Algorithm, a router <bcp14>MUST</bcp14> advertise its pa
	a particular Flex-Algorithm, a router MUST advertise its participation for	rticipation for a
	a	particular Flex-Algorithm for each data plane. Some data planes may share
	particular Flex-Algorithm for each data-plane. Some data-planes may share	a common
	a common	participation advertisement (e.g., SR-MPLS and SRv6).</t>
	participation advertisement (e.g. SR-MPLS and SRv6).</t>	<t indent="0" pn="section-11-3">Advertisement of the participation for any
		particular Flex-Algorithm in any
	<t>Advertisement of the participation for any particular Flex-Algorithm in	data plane is subject to the condition specified in
	any	<xref target="COMMONLEXALGTLV" format="default" sectionFormat="of" deriv
	data-plane is subject to the condition specified in	edContent="Section 5.3"/>.</t>
	<xref target="COMMONLEXALGTLV"/>.</t>	<section anchor="FLEXALGPARTSR" numbered="true" toc="include" removeInRFC=
		"false" pn="section-11.1">
	<section anchor="FLEXALGPARTSR"	<name slugifiedName="name-advertisement-of-node-partic">Advertisement of
	title="Advertisement of Node Participation for Segment Routing">	Node Participation for Segment Routing</name>
	<t><xref target="RFC8667"/>, <xref target="RFC8665"/>, and <xref	<t indent="0" pn="section-11.1-1"><xref target="RFC8665" format="default
	target="RFC8666"/> (IGP Segment Routing extensions) describe how the	" sectionFormat="of" derivedContent="RFC8665"/>, <xref target="RFC8666" format="
		default" sectionFormat="of" derivedContent="RFC8666"/>, and <xref target="RFC866
		7" format="default" sectionFormat="of" derivedContent="RFC8667"/> (IGP Segment R
		outing extensions) describe how the
	SR-Algorithm is used to compute the IGP best path.</t>	SR-Algorithm is used to compute the IGP best path.</t>

		<t indent="0" pn="section-11.1-2">Routers advertise support for the SR-A
	<t>Routers advertise support for the SR-Algorithm as a node	lgorithm as a node
	capability as described in the above-mentioned IGP Segment Routing	capability, as described in the above-mentioned IGP Segment Routing
	extensions. To advertise participation for a particular Flex-Algorithm	extensions. To advertise participation for a particular Flex-Algorithm
	for Segment Routing, including both SR-MPLS and SRv6, the	for Segment Routing, including both SR-MPLS and SRv6, the

	Flex-Algorithm value MUST be advertised in the SR-Algorithm TLV (OSPF)	Flex-Algorithm value <bcp14>MUST</bcp14> be advertised in the SR-Algorit hm TLV (OSPF)
	or sub-TLV (IS-IS).</t>	or sub-TLV (IS-IS).</t>

		<t indent="0" pn="section-11.1-3">Segment Routing Flex-Algorithm partici
	<t>Segment Routing Flex-Algorithm participation advertisement is	pation advertisement is
	topology independent. When a router advertises participation in an	topology independent. When a router advertises participation in an
	SR-Algorithm, the participation applies to all topologies in which the	SR-Algorithm, the participation applies to all topologies in which the
	advertising node participates.</t>	advertising node participates.</t>
	</section>	</section>

		<section anchor="FLEXALGPARTOTHER" numbered="true" toc="include" removeInR
	<section anchor="FLEXALGPARTOTHER"	FC="false" pn="section-11.2">
	title="Advertisement of Node Participation for Other Data-planes"	<name slugifiedName="name-advertisement-of-node-partici">Advertisement o
	>	f Node Participation for Other Data Planes</name>
	<t>This section describes considerations related to how other	<t indent="0" pn="section-11.2-1">This section describes considerations
	data-planes can advertise their participation in a specific	related to how other
		data planes can advertise their participation in a specific
	Flex-Algorithm.</t>	Flex-Algorithm.</t>

		<t indent="0" pn="section-11.2-2">Data-plane-specific Flex-Algorithm par
	<t>Data-plane specific Flex-Algorithm participation advertisements	ticipation advertisements
	MAY be topology specific or MAY be topology independent, depending on	<bcp14>MAY</bcp14> be topology specific or <bcp14>MAY</bcp14> be topolog
	the data-plane itself.</t>	y independent, depending on
		the data plane itself.</t>
	<t>Data-plane specific advertisement for Flex-Algorithm participation	<t indent="0" pn="section-11.2-3">Data-plane-specific advertisement for
	MUST be defined for each data-plane and is outside the scope of	Flex-Algorithm participation
		<bcp14>MUST</bcp14> be defined for each data plane and is outside the sc
		ope of
	this document.</t>	this document.</t>


	</section>	</section>
	</section>	</section>

		<section anchor="FLEXALGLINKATTR" numbered="true" toc="include" removeInRFC=
	<section anchor="FLEXALGLINKATTR"	"false" pn="section-12">
	title="Advertisement of Link Attributes for Flex-Algorithm">	<name slugifiedName="name-advertisement-of-link-attri">Advertisement of Li
	<t>Various link attributes may be used during the Flex-Algorithm path	nk Attributes for Flex-Algorithm</name>
		<t indent="0" pn="section-12-1">Various link attributes may be used during
		the Flex-Algorithm path
	calculation. For example, include or exclude rules based on link	calculation. For example, include or exclude rules based on link

	affinities can be part of the Flex-Algorithm definition as defined in	affinities can be part of the Flex-Algorithm Definition, as defined in Sec
	<xref target="ISISFADLTLVS"/> and <xref target="OSPFFADLTLVS"/>.</t>	tions
		<xref target="ISISFADLTLVS" format="counter" sectionFormat="of" derivedCon
	<t>Application-specific link attributes, as specified in	tent="6"/> and <xref target="OSPFFADLTLVS" format="counter" sectionFormat="of" d
	<xref target="RFC8919"/> or <xref target="RFC8920"/>,	erivedContent="7"/>.</t>
	that are to be used during Flex-Algorithm calculation MUST use the	<t indent="0" pn="section-12-2">Application-specific link attributes, as s
		pecified in
		<xref target="RFC8919" format="default" sectionFormat="of" derivedContent=
		"RFC8919"/> or <xref target="RFC8920" format="default" sectionFormat="of" derive
		dContent="RFC8920"/>,
		that are to be used during Flex-Algorithm calculation <bcp14>MUST</bcp14>
		use the
	Application-Specific Link Attribute (ASLA) advertisements defined in	Application-Specific Link Attribute (ASLA) advertisements defined in

	<xref target="RFC8919"/> or <xref target="RFC8920"/>, unless, in the case	<xref target="RFC8919" format="default" sectionFormat="of" derivedContent=
	of IS-IS,	"RFC8919"/> or <xref target="RFC8920" format="default" sectionFormat="of" deriv
	the L-Flag is set in the ASLA advertisement. When the L-Flag is set, then	edContent="RFC8920"/> unless, in the case of IS-IS,
	legacy	the L-flag is set in the ASLA advertisement. When the L-flag is set, then
	advertisements MUST be used, subject to the procedures and constraints def	legacy
	ined in	advertisements <bcp14>MUST</bcp14> be used, subject to the procedures and
	[<xref target="RFC8919"/> Section 4.2 and Section 6.</t>	constraints defined in
		<xref target="RFC8919" section="4.2" sectionFormat="of" format="default" d
	<t>The mandatory use of ASLA advertisements applies to link attributes	erivedLink="https://rfc-editor.org/rfc/rfc8919#section-4.2" derivedContent="RFC8
		919"/> and <xref target="ISISFADLTLVS" format="default" sectionFormat="of" deriv
		edContent="Section 6"/>.</t>
		<t indent="0" pn="section-12-3">The mandatory use of ASLA advertisements a
		pplies to link attributes
	specifically mentioned in this document (Min Unidirectional Link Delay,	specifically mentioned in this document (Min Unidirectional Link Delay,

	TE Default Metric, Administrative Group, Extended Administrative Group	TE Default Metric, Administrative Group, Extended Administrative Group,
	and Shared Risk Link Group) and any other link attributes that may be	and Shared Risk Link Group) and any other link attributes that may be
	used in support of Flex-Algorithm in the future.</t>	used in support of Flex-Algorithm in the future.</t>

		<t indent="0" pn="section-12-4">A new Application Identifier Bit is define
	<t>A new Application Identifier Bit is defined to indicate that the ASLA	d to indicate that the ASLA
	advertisement is associated with the Flex-Algorithm application. This	advertisement is associated with the Flex-Algorithm application. This

	bit is set in the Standard Application Bit Mask (SABM) defined in <xref	bit is set in the Standard Application Bit Mask (SABM) defined in <xref ta
	target="RFC8919"/> or <xref target="RFC8920"/>: <list style="hanging">	rget="RFC8919" format="default" sectionFormat="of" derivedContent="RFC8919"/> or
	<t>Bit-3: Flexible Algorithm (X-bit)</t>	<xref target="RFC8920" format="default" sectionFormat="of" derivedContent="RFC8
	</list></t>	920"/>: </t>
		<dl newline="false" spacing="normal" indent="3" pn="section-12-5">
	<t>ASLA Admin Group Advertisements to be used by the Flexible Algorithm	<dt pn="section-12-5.1">Bit 3:</dt>
	application MAY use either the Administrative Group or Extended	<dd pn="section-12-5.2">Flexible Algorithm (X-bit)</dd>
		</dl>
		<t indent="0" pn="section-12-6">ASLA Admin Group Advertisements to be used
		by the Flexible Algorithm
		application <bcp14>MAY</bcp14> use either the Administrative Group or Exte
		nded
	Administrative Group encodings.</t>	Administrative Group encodings.</t>

		<t indent="0" pn="section-12-7">A receiver supporting this specification <
	<t>A receiver supporting this specification MUST accept both ASLA	bcp14>MUST</bcp14> accept both ASLA
	Administrative Group and Extended Administrative Group TLVs as defined in	Administrative Group and Extended Administrative Group TLVs, as defined in
	<xref target="RFC8919"/> or <xref target="RFC8920"/>. In the case of IS-IS	<xref target="RFC8919" format="default" sectionFormat="of" derivedContent=
	, if	"RFC8919"/> or <xref target="RFC8920" format="default" sectionFormat="of" derive
	the L-Flag is set in ASLA advertisement, as defined in <xref target="RFC89	dContent="RFC8920"/>. In the case of IS-IS, if
	19"/>	the L-flag is set in the ASLA advertisement, as defined in <xref target="R
	Section 4.2, then the receiver MUST be able to accept both Administrative	FC8919" section="4.2" sectionFormat="of" format="default" derivedLink="https://r
	Group TLV	fc-editor.org/rfc/rfc8919#section-4.2" derivedContent="RFC8919"/>, then the rece
	as defined in <xref target="RFC5305"/> and Extended Administrative Group T	iver <bcp14>MUST</bcp14> be able to accept both the Administrative Group TLV,
	LV as	as defined in <xref target="RFC5305" format="default" sectionFormat="of" d
	defined in <xref target="RFC7308"/>.</t>	erivedContent="RFC5305"/>, and the Extended Administrative Group TLV, as
		defined in <xref target="RFC7308" format="default" sectionFormat="of" deri
	</section>	vedContent="RFC7308"/>.</t>
		</section>
	<section anchor="FLEXALGPATHCALC"	<section anchor="FLEXALGPATHCALC" numbered="true" toc="include" removeInRFC=
	title="Calculation of Flexible Algorithm Paths">	"false" pn="section-13">
	<t>A router MUST be configured to participate in a given Flex-Algorithm	<name slugifiedName="name-calculation-of-flexible-alg">Calculation of Flex
	K and MUST select the FAD based on the rules defined in <xref	ible Algorithm Paths</name>
	target="COMMONLEXALGTLV"/> before it can compute any path for that	<t indent="0" pn="section-13-1">A router <bcp14>MUST</bcp14> be configured
		to participate in a given Flex-Algorithm
		K and <bcp14>MUST</bcp14> select the FAD based on the rules defined in <xr
		ef target="COMMONLEXALGTLV" format="default" sectionFormat="of" derivedContent="
		Section 5.3"/> before it can compute any path for that
	Flex-Algorithm.</t>	Flex-Algorithm.</t>

		<t indent="0" pn="section-13-2">No specific two-way connectivity check is
	<t>No specific two-way connectivity check is performed during the Flex-Alg	performed during the Flex-Algorithm
	orithm	path computation. The result of the existing Flex-Algorithm-agnostic, two-
	path computation. The result of the existing, Flex-Algorithm agnostic, two	way
	-way
	connectivity check is used during the Flex-Algorithm path computation.</t>	connectivity check is used during the Flex-Algorithm path computation.</t>

		<t indent="0" pn="section-13-3">As described in <xref target="FLEXALGPART"
	<t>As described in <xref target="FLEXALGPART"/>, participation for any	format="default" sectionFormat="of" derivedContent="Section 11"/>, participatio
	particular Flex-Algorithm MUST be advertised on a per data-plane basis.	n for any
		particular Flex-Algorithm <bcp14>MUST</bcp14> be advertised on a per data
		plane basis.
	Calculation of the paths for any particular Flex-Algorithm is	Calculation of the paths for any particular Flex-Algorithm is

	data-plane specific.</t>	data plane specific.</t>
		<t indent="0" pn="section-13-4">Multiple data planes <bcp14>MAY</bcp14> us
	<t>Multiple data-planes MAY use the same Flex-Algorithm value at the	e the same Flex-Algorithm value at the
	same time, and as such, share the FAD for it. Traffic for each data-plane	same time and, as such, share the FAD for it. Traffic for each data plane
	will be forwarded based on the data-plane specific forwarding entries.</t>	will be forwarded based on the data-plane-specific forwarding entries.</t>
		<t indent="0" pn="section-13-5">The Flex-Algorithm Definition is data plan
	<t>Flex-Algorithm definition is data-plane independent and is used by	e independent and is used by
	all Flex-Algorithm data-planes.</t>	all Flex-Algorithm data planes.</t>
		<t indent="0" pn="section-13-6">The way various data planes handle nodes t
	<t>The way various data-planes handle nodes that do not participate in	hat do not participate in
	Flexible Algorithm is data-plane specific. If the data-plane only	Flexible Algorithm is data plane specific. If the data plane only
	wants to consider participating nodes during the Flex-Algorithm	wants to consider participating nodes during the Flex-Algorithm
	calculation, then when computing paths for a given Flex-Algorithm, all	calculation, then when computing paths for a given Flex-Algorithm, all
	nodes that do not advertise participation for that Flex-Algorithm in	nodes that do not advertise participation for that Flex-Algorithm in

	their data-plane specific advertisements MUST be pruned from the	their data-plane-specific advertisements <bcp14>MUST</bcp14> be pruned fro m the
	topology. Segment Routing, including both SR-MPLS and SRv6, are	topology. Segment Routing, including both SR-MPLS and SRv6, are

	data-planes that MUST use such pruning when computing Flex-Algorithm	data planes that <bcp14>MUST</bcp14> use such pruning when computing Flex- Algorithm
	paths.</t>	paths.</t>

		<t indent="0" pn="section-13-7">When computing the path for a given Flex-A
	<t>When computing the path for a given Flex-Algorithm, the metric-type	lgorithm, the metric-type
	that is part of the Flex-Algorithm definition (<xref	that is part of the Flex-Algorithm Definition (<xref target="FLEXALGDEF" f
	target="FLEXALGDEF"/>) MUST be used.</t>	ormat="default" sectionFormat="of" derivedContent="Section 5"/>) <bcp14>MUST</bc
		p14> be used.</t>
	<t>When computing the path for a given Flex-Algorithm, the	<t indent="0" pn="section-13-8">When computing the path for a given Flex-A
	calculation-type that is part of the Flex-Algorithm definition (<xref	lgorithm, the
	target="FLEXALGDEF"/>) MUST be used.</t>	calculation-type that is part of the Flex-Algorithm Definition (<xref targ
		et="FLEXALGDEF" format="default" sectionFormat="of" derivedContent="Section 5"/>
	<t>Various link include or exclude rules can be part of the	) <bcp14>MUST</bcp14> be used.</t>
	Flex-Algorithm definition. To refer to a particular bit within an Admin Gr	<t indent="0" pn="section-13-9">Various links that include or exclude rule
	oup or	s can be part of the
	Extended Admin Group we use the term 'color'.</t>	Flex-Algorithm Definition. To refer to a particular bit within an Admin Gr
		oup or
	<t>Rules, in the order as specified below, MUST be used to prune links	Extended Admin Group, we use the term "color".</t>
		<t indent="0" pn="section-13-10">Rules, in the order as specified below, <
		bcp14>MUST</bcp14> be used to prune links
	from the topology during the Flex-Algorithm computation.</t>	from the topology during the Flex-Algorithm computation.</t>

		<t indent="0" pn="section-13-11">For all links in the topology: </t>
	<t>For all links in the topology: <list style="hanging">	<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-13-1
	<t>1. Check if any exclude AG rule is part of the Flex-Algorithm	2">
	definition. If such exclude rule exists, check if any color that is	<li pn="section-13-12.1" derivedCounter="1.">Check if any exclude Admini
	part of the exclude rule is also set on the link. If such a color is	strative Group rule is part of the Flex-Algorithm
	set, the link MUST be pruned from the computation.</t>	Definition. If such exclude rule exists, check if any color that is
		part of the exclude rule is also set on the link. If such a color is
	<t>2. Check if any exclude SRLG rule is part of the Flex-Algorithm	set, the link <bcp14>MUST</bcp14> be pruned from the computation.</li>
	definition. If such exclude rule exists, check if the link is part	<li pn="section-13-12.2" derivedCounter="2.">Check if any exclude SRLG r
	of any SRLG that is also part of the SRLG exclude rule. If the link	ule is part of the Flex-Algorithm
	is part of such SRLG, the link MUST be pruned from the	Definition. If such exclude rule exists, check if the link is part
	computation.</t>	of any SRLG that is also part of the SRLG exclude rule. If the link
		is part of such SRLG, the link <bcp14>MUST</bcp14> be pruned from the
	<t>3. Check if any include-any AG rule is part of the Flex-Algorithm	computation.</li>
	definition. If such include-any rule exists, check if any color that	<li pn="section-13-12.3" derivedCounter="3.">Check if any include-any Ad
	is part of the include-any rule is also set on the link. If no such	ministrative Group rule is part of the Flex-Algorithm
	color is set, the link MUST be pruned from the computation.</t>	Definition. If such include-any rule exists, check if any color that
		is part of the include-any rule is also set on the link. If no such
	<t>4. Check if any include-all AG rule is part of the Flex-Algorithm	color is set, the link <bcp14>MUST</bcp14> be pruned from the computatio
	definition. If such include-all rule exists, check if all colors	n.</li>
	that are part of the include-all rule are also set on the link. If	<li pn="section-13-12.4" derivedCounter="4.">Check if any include-all Ad
	all such colors are not set on the link, the link MUST be pruned	ministrative Group rule is part of the Flex-Algorithm
	from the computation.</t>	Definition. If such include-all rule exists, check if all colors
		that are part of the include-all rule are also set on the link. If
	<t>5. If the Flex-Algorithm definition uses other than IGP metric	all such colors are not set on the link, the link <bcp14>MUST</bcp14> be
	(<xref target="FLEXALGDEF"/>), and such metric is not advertised for	pruned
	the particular link in a topology for which the computation is done,	from the computation.</li>
	such link MUST be pruned from the computation. A metric of value 0	<li pn="section-13-12.5" derivedCounter="5.">If the Flex-Algorithm Defin
	MUST NOT be assumed in such a case.</t>	ition uses something other than the IGP metric
	</list></t>	(<xref target="FLEXALGDEF" format="default" sectionFormat="of" derivedCo
		ntent="Section 5"/>), and such metric is not
	<section anchor="FLEXALGPATHCALCINTER"	advertised for the particular link in a topology for which the computatio
	title="Multi-area and Multi-domain Considerations">	n is
	<t>Any IGP Shortest Path Tree calculation is limited to a single area.	done, such link <bcp14>MUST</bcp14> be pruned from the computation. A met
		ric of
		value 0 <bcp14>MUST NOT</bcp14> be assumed in such a case.</li>
		</ol>
		<section anchor="FLEXALGPATHCALCINTER" numbered="true" toc="include" remov
		eInRFC="false" pn="section-13.1">
		<name slugifiedName="name-multi-area-and-multi-domain">Multi-area and Mu
		lti-domain Considerations</name>
		<t indent="0" pn="section-13.1-1">Any IGP Shortest Path Tree calculation
		is limited to a single area.
	This applies to Flex-Algorithm calculations as well. Given that the	This applies to Flex-Algorithm calculations as well. Given that the
	computing router does not have visibility of the topology of the next	computing router does not have visibility of the topology of the next

	areas or domain, the Flex-Algorithm specific path to an inter-area or	areas or domain, the Flex-Algorithm-specific path to an inter-area or
	inter-domain prefix will be computed for the local area only. The	inter-domain prefix will be computed for the local area only. The

	egress L1/L2 router (ABR in OSPF), or ASBR for inter-domain case, will	egress L1/L2 router (ABR in OSPF), or ASBR for an inter-domain case, wil l
	be selected based on the best path for the given Flex-Algorithm in the	be selected based on the best path for the given Flex-Algorithm in the

	local area and such egress ABR or ASBR router will be responsible to	local area, and such egress ABR or ASBR router will be responsible to
	compute the best Flex-Algorithm specific path over the next area or	compute the best Flex-Algorithm-specific path over the next area or
	domain. This may produce an end-to-end path, which is suboptimal	domain. This may produce an end-to-end path, which is suboptimal
	based on Flex-Algorithm constraints. In cases where the ABR or ASBR	based on Flex-Algorithm constraints. In cases where the ABR or ASBR
	has no reachability to a prefix for a given Flex-Algorithm in the next	has no reachability to a prefix for a given Flex-Algorithm in the next
	area or domain, the traffic could be dropped by the ABR/ASBR.</t>	area or domain, the traffic could be dropped by the ABR/ASBR.</t>

		<t indent="0" pn="section-13.1-2">To allow the optimal end-to-end path f
	<t>To allow the optimal end-to-end path for an inter-area or	or an inter-area or
	inter-domain prefix for any Flex-Algorithm to be computed, the FAPM	inter-domain prefix for any Flex-Algorithm to be computed, the FAPM

	has been defined in <xref target="ISISFLEXMETRIC"/> and <xref	has been defined in Sections <xref target="ISISFLEXMETRIC" format="count
	target="OSPFFLEXMETRIC"/>. For external route calculation for prefixes	er" sectionFormat="of" derivedContent="8"/>
	originated by ASBRs in remote areas in OSPF, the FAAM has been defined	and <xref target="OSPFFLEXMETRIC" format="counter" sectionFormat="of" der
	in <xref target="OSPFFAASBRMETRIC"/> for the ABR to indicate its ASBR	ivedContent="9"/>. For external route
	reachability along with the metric for the specific	calculation for prefixes originated by ASBRs in remote areas in OSPF, the
		FAAM
		has been defined in <xref target="OSPFFAASBRMETRIC" format="default" sect
		ionFormat="of" derivedContent="Section 10.2"/> for the
		ABR to indicate its ASBR reachability along with the metric for the speci
		fic
	Flex-Algorithm.</t>	Flex-Algorithm.</t>

		<t indent="0" pn="section-13.1-3">If the FAD selected based on the rules
	<t>If the FAD selected based on the rules defined in <xref	defined in <xref target="COMMONLEXALGTLV" format="default" sectionFormat="of" d
	target="COMMONLEXALGTLV"/> includes the M-flag, an ABR or ASBR MUST	erivedContent="Section 5.3"/> includes the M-flag, an ABR or an ASBR
	include the FAPM (<xref target="ISISFLEXMETRIC"/>, <xref	<bcp14>MUST</bcp14> include the FAPM (see Sections <xref target="ISISFLEX
	target="OSPFFLEXMETRIC"/>) when advertising the prefix, that is	METRIC" format="counter" sectionFormat="of" derivedContent="8"/> and <xref targe
	reachable in a given Flex-Algorithm, between areas or domains. Such	t="OSPFFLEXMETRIC" format="counter" sectionFormat="of" derivedContent="9"/>) whe
		n
		advertising the prefix that is
		reachable in a given Flex-Algorithm between areas or domains. Such
	metric will be equal to the metric to reach the prefix for that	metric will be equal to the metric to reach the prefix for that
	Flex-Algorithm in its source area or domain. This is similar in nature	Flex-Algorithm in its source area or domain. This is similar in nature
	to how the metric is set when prefixes are advertised between areas or	to how the metric is set when prefixes are advertised between areas or
	domains for the default algorithm. When a prefix is unreachable in its	domains for the default algorithm. When a prefix is unreachable in its
	source area or domain in a specific Flex-Algorithm, then an ABR or	source area or domain in a specific Flex-Algorithm, then an ABR or

	ASBR MUST NOT include the FAPM for that Flex-Algorithm when	ASBR <bcp14>MUST NOT</bcp14> include the FAPM for that Flex-Algorithm wh en
	advertising the prefix between areas or domains.</t>	advertising the prefix between areas or domains.</t>

		<t indent="0" pn="section-13.1-4">If the FAD selected based on the rules
	<t>If the FAD selected based on the rules defined in <xref	defined in <xref target="COMMONLEXALGTLV" format="default" sectionFormat="of" d
	target="COMMONLEXALGTLV"/> includes the M-flag, the FAPM MUST be used	erivedContent="Section 5.3"/> includes the M-flag, the FAPM <bcp14>MUST</bcp14>
		be used
	during the calculation of prefix reachability for the inter-area and	during the calculation of prefix reachability for the inter-area and
	external prefixes. If the FAPM for the Flex-Algorithm is not	external prefixes. If the FAPM for the Flex-Algorithm is not
	advertised with the inter-area or external prefix reachability	advertised with the inter-area or external prefix reachability

	advertisement, the prefix MUST be considered as unreachable for that	advertisement, the prefix <bcp14>MUST</bcp14> be considered as unreachab le for that
	Flex-Algorithm. Similarly, in the case of OSPF, for ASBRs in remote	Flex-Algorithm. Similarly, in the case of OSPF, for ASBRs in remote
	areas, if the FAAM is not advertised by the local ABR(s), the ASBR	areas, if the FAAM is not advertised by the local ABR(s), the ASBR

	MUST be considered as unreachable for that Flex-Algorithm and the	<bcp14>MUST</bcp14> be considered as unreachable for that Flex-Algorithm , and the
	external prefix advertisements from such an ASBR are not considered	external prefix advertisements from such an ASBR are not considered
	for that Flex-Algorithm.</t>	for that Flex-Algorithm.</t>

		<t indent="0" pn="section-13.1-5">The Flex-Algorithm prefix metrics and
	<t>Flex-Algorithm prefix metrics and the OSPF Flex-Algorithm ASBR	the OSPF Flex-Algorithm ASBR
	metrics MUST NOT be used during the Flex-Algorithm computation unless	metrics <bcp14>MUST NOT</bcp14> be used during the Flex-Algorithm comput
	the FAD selected based on the rules defined in <xref	ation
	target="COMMONLEXALGTLV"/> includes the M-Flag, as described in (<xref	unless the FAD selected based on the rules defined in <xref target="COMMO
	target="ISISFLEXALGFLAG"/> or <xref target="OSPFFLEXALGFLAG"/>).</t>	NLEXALGTLV" format="default" sectionFormat="of" derivedContent="Section 5.3"/> i
		ncludes the M-flag, as described in
	<t>In the case of OSPF, when calculating external routes in a	Sections <xref target="ISISFLEXALGFLAG" format="counter" sectionFormat="o
	Flex-Algorithm, if the winning FAD includes the M-Flag, and where the	f" derivedContent="6.4"/> or <xref target="OSPFFLEXALGFLAG" format="counter" sec
		tionFormat="of" derivedContent="7.4"/>.</t>
		<t indent="0" pn="section-13.1-6">In the case of OSPF, when calculating
		external routes in a
		Flex-Algorithm, if the winning FAD includes the M-flag, and the
	advertising ASBR is in a remote area, the metric will be the sum of	advertising ASBR is in a remote area, the metric will be the sum of

	the following:<list style="symbols">	the following:</t>
	<t>the FAPM for that Flex-Algorithm advertised with the external	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
	route by the ASBR</t>	3.1-7">
		<li pn="section-13.1-7.1">the FAPM for that Flex-Algorithm advertised
	<t>the metric to reach the ASBR for that Flex-Algorithm from the	with the external
	local ABR i.e., the FAAM for that Flex-Algorithm advertised by the	route by the ASBR</li>
	ABR in the local area for that ASBR</t>	<li pn="section-13.1-7.2">the metric to reach the ASBR for that Flex-A
		lgorithm from the
	<t>the Flex-Algorithm specific metric to reach the local ABR</t>	local ABR, i.e., the FAAM for that Flex-Algorithm advertised by the
	</list>This is similar in nature to how the metric is calculated for	ABR in the local area for that ASBR</li>
		<li pn="section-13.1-7.3">the Flex-Algorithm-specific metric to reach
		the local ABR</li>
		</ul>
		<t indent="0" pn="section-13.1-8">This is similar in nature to how the m
		etric is calculated for
	routes learned from remote ASBRs in the default algorithm using the	routes learned from remote ASBRs in the default algorithm using the

	OSPFv2 Type 4 ASBR Summary LSA and the OSPFv3 Inter-Area-Router	OSPFv2 Type 4 ASBR summary-LSA and the OSPFv3 Inter-Area-Router-LSA.</t>
	LSA.</t>	<t indent="0" pn="section-13.1-9">If the FAD selected based on the rules
		defined in <xref target="COMMONLEXALGTLV" format="default" sectionFormat="of" d
	<t>If the FAD selected based on the rules defined in <xref	erivedContent="Section 5.3"/> does not include the M-flag, then the IGP
	target="COMMONLEXALGTLV"/> does not include the M-flag, then the IGP
	metrics associated with the prefix reachability advertisements used by	metrics associated with the prefix reachability advertisements used by

	the base IS-IS and OSPF protocol MUST be used for the Flex-Algorithm	the base IS-IS and OSPF protocol <bcp14>MUST</bcp14> be used for the Fle x-Algorithm
	route computation. Similarly, in the case of external route	route computation. Similarly, in the case of external route
	calculations in OSPF, the ASBR reachability is determined based on the	calculations in OSPF, the ASBR reachability is determined based on the

	base OSPFv2 Type 4 Summary LSA and the OSFPv3 Inter-Area-Router	base OSPFv2 Type 4 summary-LSA and the OSFPv3 Inter-Area-Router-LSA.</t>
	LSA.</t>	<t indent="0" pn="section-13.1-10">It is <bcp14>NOT RECOMMENDED</bcp14>
		to use the Flex-Algorithm for inter-area or
	<t>It is NOT RECOMMENDED to use the Flex-Algorithm for inter-area or
	inter-domain prefix reachability without the M-flag set. The reason is	inter-domain prefix reachability without the M-flag set. The reason is

	that without the explicit Flex-Algorithm Prefix Metric advertisement	that, without the explicit Flex-Algorithm prefix metric advertisement
	(and the Flex-Algorithm ASBR metric advertisement in the case of OSPF	(and the Flex-Algorithm ASBR metric advertisement in the case of OSPF
	external route calculation), it is not possible to conclude whether	external route calculation), it is not possible to conclude whether
	the ABR or ASBR has reachability to the inter-area or inter-domain	the ABR or ASBR has reachability to the inter-area or inter-domain
	prefix for a given Flex-Algorithm in the next area or domain. Sending	prefix for a given Flex-Algorithm in the next area or domain. Sending
	the Flex-Algorithm traffic for such a prefix towards the ABR or ASBR may	the Flex-Algorithm traffic for such a prefix towards the ABR or ASBR may
	result in traffic looping or persistent traffic drop.</t>	result in traffic looping or persistent traffic drop.</t>

		<t indent="0" pn="section-13.1-11">During the route computation, it is p
	<t>During the route computation, it is possible for the Flex-Algorithm	ossible for the Flex-Algorithm-specific
	specific metric to exceed the maximum value that can be stored in an	metric to exceed the maximum value that can be stored in an
	unsigned 32-bit variable. In such scenarios, the value MUST be	unsigned 32-bit variable. In such scenarios, the value <bcp14>MUST</bcp1
		4> be
	considered to be of value 0xFFFFFFFF during the computation and	considered to be of value 0xFFFFFFFF during the computation and
	advertised as such.</t>	advertised as such.</t>

		<t indent="0" pn="section-13.1-12">The FAPM <bcp14>MUST NOT</bcp14> be a
	<t>The FAPM MUST NOT be advertised with IS-IS L1 or L2 intra-area,	dvertised with IS-IS L1 or L2 intra-area,
	OSPFv2 intra-area, or OSPFv3 intra-area routes. If the FAPM is	OSPFv2 intra-area, or OSPFv3 intra-area routes. If the FAPM is

	advertised for these route-types, it MUST be ignored during the prefix	advertised for these route-types, it <bcp14>MUST</bcp14> be ignored duri ng the prefix
	reachability calculation.</t>	reachability calculation.</t>

		<t indent="0" pn="section-13.1-13">The M-flag in the FAD is not applicab
	<t>The M-flag in the FAD is not applicable to prefixes advertised as SRv	le to prefixes advertised as SRv6
	6	locators. The IS-IS SRv6 Locator TLV <xref target="RFC9352" format="defa
	locators. The IS-IS SRv6 Locator TLV <xref	ult" sectionFormat="of" derivedContent="RFC9352"/> includes the Algorithm
	target="I-D.ietf-lsr-isis-srv6-extensions"/> includes the Algorithm
	and Metric fields. When the SRv6 Locator is advertised between areas	and Metric fields. When the SRv6 Locator is advertised between areas

	or domains, the metric field in the Locator TLV of IS-IS MUST be used	or domains, the Metric field in the Locator TLV of IS-IS <bcp14>MUST</bc p14> be used
	irrespective of the M-flag in the FAD advertisement.</t>	irrespective of the M-flag in the FAD advertisement.</t>

		<t indent="0" pn="section-13.1-14">OSPF external and NSSA external prefi
	<t>OSPF external and NSSA external prefix advertisements MAY include a	x advertisements <bcp14>MAY</bcp14> include a
	non-zero forwarding address in the prefix advertisements in the base	non-zero forwarding address in the prefix advertisements in the base

	protocol. In such a scenario, the Flex-Algorithm specific reachability	protocol. In such a scenario, the Flex-Algorithm-specific reachability
	of the external prefix is determined by Flex-Algorithm specific	of the external prefix is determined by Flex-Algorithm-specific
	reachability of the forwarding address.</t>	reachability of the forwarding address.</t>

		<t indent="0" pn="section-13.1-15">In OSPF, the procedures for translati
	<t>In OSPF, the procedures for translation of NSSA external prefix	on of NSSA external prefix
	advertisements into external prefix advertisements performed by an	advertisements into external prefix advertisements performed by an

	NSSA ABR <xref target="RFC3101"/> remain unchanged for Flex-Algorithm.	NSSA ABR <xref target="RFC3101" format="default" sectionFormat="of" deri
	An NSSA translator MUST include the OSPF FAPM Sub-TLVs for all	vedContent="RFC3101"/> remain unchanged for Flex-Algorithm.
		An NSSA translator <bcp14>MUST</bcp14> include the OSPF FAPM sub-TLVs fo
		r all
	Flex-Algorithms that are in the original NSSA external prefix	Flex-Algorithms that are in the original NSSA external prefix
	advertisement from the NSSA ASBR in the translated external prefix	advertisement from the NSSA ASBR in the translated external prefix

	advertisement generated by it regardless of its participation in those	advertisement generated by it, regardless of its participation in those
	Flex-Algorithms or its having reachability to the NSSA ASBR in those	Flex-Algorithms or its having reachability to the NSSA ASBR in those
	Flex-Algorithms.</t>	Flex-Algorithms.</t>

		<t indent="0" pn="section-13.1-16">An area could become partitioned from
	<t>An area could become partitioned from the perspective of the Flex-Alg	the perspective of the Flex-Algorithm
	orithm	due to the constraints and/or metric being used for it while maintaining
	due to the constraints and/or metric being used for it, while maintainin	the
	g the
	continuity in the base algorithm. When that happens, some destinations i nside that area	continuity in the base algorithm. When that happens, some destinations i nside that area
	could become unreachable in that Flex-Algorithm. These destinations will not be able	could become unreachable in that Flex-Algorithm. These destinations will not be able
	to use an inter-area path. This is the consequence of the fact that the	to use an inter-area path. This is the consequence of the fact that the
	inter-area prefix reachability advertisement would not be available for these	inter-area prefix reachability advertisement would not be available for these

	intra-area destinations within the area. It is RECOMMENDED to minimize t he risk of	intra-area destinations within the area. It is <bcp14>RECOMMENDED</bcp14 > to minimize the risk of
	such partitioning by providing enough redundancy inside the area for eac h	such partitioning by providing enough redundancy inside the area for eac h
	Flex-Algorithm being used.</t>	Flex-Algorithm being used.</t>


	</section>	</section>
	</section>	</section>

		<section anchor="FLEXALFORW" numbered="true" toc="include" removeInRFC="fals
	<section anchor="FLEXALFORW" title="Flex-Algorithm and Forwarding Plane">	e" pn="section-14">
	<t>This section describes how Flex-Algorithm paths are used in	<name slugifiedName="name-flex-algorithm-and-forwardi">Flex-Algorithm and
		Forwarding Plane</name>
		<t indent="0" pn="section-14-1">This section describes how Flex-Algorithm
		paths are used in
	forwarding.</t>	forwarding.</t>

		<section anchor="FLEXALGPSRFORW" numbered="true" toc="include" removeInRFC
	<section anchor="FLEXALGPSRFORW"	="false" pn="section-14.1">
	title="Segment Routing MPLS Forwarding for Flex-Algorithm">	<name slugifiedName="name-segment-routing-mpls-forwar">Segment Routing M
	<t>This section describes how Flex-Algorithm paths are used with SR	PLS Forwarding for Flex-Algorithm</name>
		<t indent="0" pn="section-14.1-1">This section describes how Flex-Algori
		thm paths are used with SR
	MPLS forwarding.</t>	MPLS forwarding.</t>

		<t indent="0" pn="section-14.1-2">Prefix-SID advertisements include an S
	<t>Prefix SID advertisements include an SR-Algorithm value and, as	R-Algorithm value and, as
	such, are associated with the specified SR-Algorithm. Prefix-SIDs are	such, are associated with the specified SR-Algorithm. Prefix-SIDs are

	also associated with a specific topology which is inherited from the	also associated with a specific topology that is inherited from the
	associated prefix reachability advertisement. When the algorithm value	associated prefix reachability advertisement. When the algorithm value

	advertised is a Flex-Algorithm value, the Prefix SID is associated	advertised is a Flex-Algorithm value, the Prefix-SID is associated
	with paths calculated using that Flex-Algorithm in the associated	with paths calculated using that Flex-Algorithm in the associated
	topology.</t>	topology.</t>

		<t indent="0" pn="section-14.1-3">A Flex-Algorithm path <bcp14>MUST</bcp
	<t>A Flex-Algorithm path MUST be installed in the MPLS forwarding	14> be installed in the MPLS forwarding
	plane using the MPLS label that corresponds to the Prefix-SID that was	plane using the MPLS label that corresponds to the Prefix-SID that was

	advertised for that Flex-algorithm. If the Prefix SID for a given	advertised for that Flex-algorithm. If the Prefix-SID for a given
	Flex-algorithm is not known, the Flex-Algorithm specific path cannot	Flex-Algorithm is not known, the Flex-Algorithm-specific path cannot
	be installed in the MPLS forwarding plane.</t>	be installed in the MPLS forwarding plane.</t>

		<t indent="0" pn="section-14.1-4">Traffic that is supposed to be routed
	<t>Traffic that is supposed to be routed via Flex-Algorithm specific	via Flex-Algorithm-specific
	paths MUST be dropped when there are no such paths available.</t>	paths <bcp14>MUST</bcp14> be dropped when there are no such paths availa
		ble.</t>
	<t>Loop Free Alternate (LFA) paths (<xref target="RFC6571"/> or its vari	<t indent="0" pn="section-14.1-5">Loop Free Alternate (LFA) paths (<xref
	ants)	target="RFC6571" format="default" sectionFormat="of" derivedContent="RFC6571"/>
	for a given Flex-Algorithm MUST be computed using the same constraints a	or its variants)
	s the	for a given Flex-Algorithm <bcp14>MUST</bcp14> be computed using the sam
	calculation of the primary paths for that Flex-Algorithm. LFA paths MUST	e constraints as the
	only	calculation of the primary paths for that Flex-Algorithm. LFA paths <bcp
	use Prefix-SIDs advertised specifically for the given algorithm. LFA pat	14>MUST</bcp14> only
	hs MUST NOT	use Prefix-SIDs advertised specifically for the given algorithm. LFA pat
	use an Adjacency-SID that belongs to a link that has been pruned from	hs <bcp14>MUST NOT</bcp14>
		use an Adjacency SID that belongs to a link that has been pruned from
	the Flex-Algorithm computation.</t>	the Flex-Algorithm computation.</t>

		<t indent="0" pn="section-14.1-6">If LFA protection is being used to pro
	<t>If LFA protection is being used to protect a given Flex-Algorithm	tect a given Flex-Algorithm
	paths, all routers in the area participating in the given	path, all routers in the area participating in the given
	Flex-Algorithm SHOULD advertise at least one Flex-Algorithm specific	Flex-Algorithm <bcp14>SHOULD</bcp14> advertise at least one
	Node-SID. These Node-SIDs are used to steer traffic over the LFA	Flex-Algorithm-specific Node-SID. These Node-SIDs are used to steer traff
	computed backup path.</t>	ic over
		the LFA-computed backup path.</t>
	</section>	</section>

		<section anchor="FLEXALGPSRV6FORW" numbered="true" toc="include" removeInR
	<section anchor="FLEXALGPSRV6FORW"	FC="false" pn="section-14.2">
	title="SRv6 Forwarding for Flex-Algorithm">	<name slugifiedName="name-srv6-forwarding-for-flex-al">SRv6 Forwarding f
	<t>This section describes how Flex-Algorithm paths are used with SRv6	or Flex-Algorithm</name>
		<t indent="0" pn="section-14.2-1">This section describes how Flex-Algori
		thm paths are used with SRv6
	forwarding.</t>	forwarding.</t>

		<t indent="0" pn="section-14.2-2">In SRv6, a node is provisioned with a
	<t>In SRv6 a node is provisioned with a (topology, algorithm) specific	(topology, algorithm) specific
	locator for each of the topology/algorithm pairs supported by that	locator for each of the topology/algorithm pairs supported by that
	node. Each locator is an aggregate prefix for all SIDs provisioned on	node. Each locator is an aggregate prefix for all SIDs provisioned on

	that node which have the matching topology/algorithm.</t>	that node that have the matching topology/algorithm.</t>
		<t indent="0" pn="section-14.2-3">The SRv6 locator advertisement in IS-I
	<t>The SRv6 locator advertisement in IS-IS <xref	S <xref target="RFC9352" format="default" sectionFormat="of" derivedContent="RFC
	target="I-D.ietf-lsr-isis-srv6-extensions"/> includes the MTID value	9352"/> includes the Multi-Topology Identifier (MTID) value
	that associates the locator with a specific topology. SRv6 locator	that associates the locator with a specific topology. SRv6 locator

	advertisements also includes an Algorithm value that explicitly	advertisements also include an algorithm value that explicitly
	associates the locator with a specific algorithm. When the algorithm	associates the locator with a specific algorithm. When the algorithm
	value advertised with a locator represents a Flex-Algorithm, the paths	value advertised with a locator represents a Flex-Algorithm, the paths

	to the locator prefix MUST be calculated using the specified	to the locator prefix <bcp14>MUST</bcp14> be calculated using the specif ied
	Flex-Algorithm in the associated topology.</t>	Flex-Algorithm in the associated topology.</t>

		<t indent="0" pn="section-14.2-4">Forwarding entries for the locator pre
	<t>Forwarding entries for the locator prefixes advertised in IS-IS MUST	fixes advertised in IS-IS <bcp14>MUST</bcp14>
	be installed in the forwarding plane of the receiving SRv6 capable	be installed in the forwarding plane of the receiving SRv6-capable
	routers when the associated topology/algorithm is participating in	routers when the associated topology/algorithm is participating in
	them. Forwarding entries for locators associated with Flex-Algorithms	them. Forwarding entries for locators associated with Flex-Algorithms

	in which the node is not participating MUST NOT be installed in the	in which the node is not participating <bcp14>MUST NOT</bcp14> be instal led in the
	forwarding plane.</t>	forwarding plane.</t>

		<t indent="0" pn="section-14.2-5">When the locator is associated with a
	<t>When the locator is associated with a Flex-Algorithm, LFA paths to	Flex-Algorithm, LFA paths to
	the locator prefix MUST be calculated using such Flex-Algorithm in the	the locator prefix <bcp14>MUST</bcp14> be calculated using such Flex-Alg
	associated topology, to guarantee that they follow the same	orithm in the
	constraints as the calculation of the primary paths. LFA paths MUST	associated topology to guarantee that they follow the same
		constraints as the calculation of the primary paths. LFA paths <bcp14>MU
		ST</bcp14>
	only use SRv6 SIDs advertised specifically for the given	only use SRv6 SIDs advertised specifically for the given
	Flex-Algorithm.</t>	Flex-Algorithm.</t>

		<t indent="0" pn="section-14.2-6">If LFA protection is being used to pro
	<t>If LFA protection is being used to protect locators associated with	tect locators associated with
	a given Flex-Algorithm, all routers in the area participating in the	a given Flex-Algorithm, all routers in the area participating in the

	given Flex-Algorithm SHOULD advertise at least one Flex-Algorithm	given Flex-Algorithm <bcp14>SHOULD</bcp14> advertise at least one
	specific locator and END SID per node and one END.X SID for every link	Flex-Algorithm-specific locator and END SID per node and one END.X SID fo
	that has not been pruned from such Flex-Algorithm computation. These	r every
		link that has not been pruned from such Flex-Algorithm computation. These
	locators and SIDs are used to steer traffic over the LFA-computed	locators and SIDs are used to steer traffic over the LFA-computed
	backup path.</t>	backup path.</t>
	</section>	</section>

		<section anchor="FLEXALGPSRFORWOTHER" numbered="true" toc="include" remove
	<section anchor="FLEXALGPSRFORWOTHER"	InRFC="false" pn="section-14.3">
	title="Other Data-planes' Forwarding for Flex-Algorithm">	<name slugifiedName="name-other-data-planes-forwardin">Other Data Planes
	<t>Any data-plane that wants to use Flex-Algorithm specific	' Forwarding for Flex-Algorithm</name>
	forwarding needs to install some form of Flex-Algorithm specific	<t indent="0" pn="section-14.3-1">Any data plane that wants to use Flex-
		Algorithm-specific
		forwarding needs to install some form of Flex-Algorithm-specific
	forwarding entries.</t>	forwarding entries.</t>

		<t indent="0" pn="section-14.3-2">Data-plane-specific forwarding for Fle
	<t>Data-plane specific forwarding for Flex-Algorithm MUST be defined	x-Algorithms <bcp14>MUST</bcp14> be defined
	for each data-plane and is outside the scope of this document.</t>	for each data plane and is outside the scope of this document.</t>
	</section>	</section>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-15">
	<section title="Operational Considerations">	<name slugifiedName="name-operational-considerations">Operational Consider
	<section title="Inter-area Considerations">	ations</name>
	<t>The scope of the Flex-Algorithm computation is an area, so is the sco	<section numbered="true" toc="include" removeInRFC="false" pn="section-15.
	pe of the	1">
	FAD. In IS-IS, the Router Capability TLV in which the FAD Sub-TLV is	<name slugifiedName="name-inter-area-considerations">Inter-area Consider
	advertised MUST have the S-bit clear, which prevents it from being flood	ations</name>
	ed	<t indent="0" pn="section-15.1-1">The scope of the Flex-Algorithm comput
		ation and the scope of the
		FAD is an area. In IS-IS, the Router Capability TLV in which the FAD sub
		-TLV is
		advertised <bcp14>MUST</bcp14> have the S bit clear, which prevents it f
		rom being flooded
	outside the level in which it was originated. Even though in OSPF	outside the level in which it was originated. Even though in OSPF

	the FAD Sub-TLV can be flooded in an RI LSA that has AS flooding	the FAD sub-TLV can be flooded in an RI LSA that has an AS flooding
	scope, the FAD selection is performed for each individual area in	scope, the FAD selection is performed for each individual area in
	which it is being used.</t>	which it is being used.</t>

		<t indent="0" pn="section-15.1-2">There is no requirement for the FAD fo
	<t>There is no requirement for the FAD for a particular Flex-Algorithm	r a particular Flex-Algorithm
	to be identical in all areas in the network. For example, traffic for	to be identical in all areas in the network. For example, traffic for
	the same Flex-Algorithm may be optimized for minimal delay (e.g.,	the same Flex-Algorithm may be optimized for minimal delay (e.g.,

	using delay metric) in one area or level, while being optimized for	using delay metric) in one area or level while being optimized for
	available bandwidth (e.g., using IGP metric) in another area or	available bandwidth (e.g., using IGP metric) in another area or
	level.</t>	level.</t>

		<t indent="0" pn="section-15.1-3">As described in <xref target="ISISFLEX
	<t>As described in <xref target="ISISFLEXALGTLV"/>, IS-IS allows the	ALGTLV" format="default" sectionFormat="of" derivedContent="Section 5.1"/>, IS-I
	re-generation of the winning FAD from level 2, without any	S allows the
		regeneration of the winning FAD from level 2, without any
	modification to it, into a level 1 area. This allows the operator to	modification to it, into a level 1 area. This allows the operator to

	configure the FAD in one or multiple routers in the level 2, without	configure the FAD in one or multiple routers in level 2, without
	the need to repeat the same task in each level 1 area, if the intent	the need to repeat the same task in each level 1 area, if the intent
	is to have the same FAD for the particular Flex-Algorithm across all	is to have the same FAD for the particular Flex-Algorithm across all
	levels. This can similarly be achieved in OSPF by using the AS	levels. This can similarly be achieved in OSPF by using the AS

	flooding scope of the RI LSA in which the FAD Sub-TLV for the	flooding scope of the RI LSA in which the FAD sub-TLV for the
	particular Flex-Algoritm is advertised.</t>	particular Flex-Algorithm is advertised.</t>
		<t indent="0" pn="section-15.1-4">Regeneration of the FAD from a level 1
	<t>Re-generation of the FAD from a level 1 area to the level 2 area is n	area to the level 2 area is not
	ot
	supported in IS-IS, so if the intent is to regenerate the FAD between	supported in IS-IS, so if the intent is to regenerate the FAD between

	IS-IS levels, the FAD MUST be defined on router(s) that are in level 2.	IS-IS levels, the FAD <bcp14>MUST</bcp14> be defined on a router(s) that
	In OSPF, the FAD definition can be done in any area and be propagated	is in level 2.
		In OSPF, the FAD definition can be done in any area and propagated
	to all routers in the OSPF routing domain by using the AS flooding	to all routers in the OSPF routing domain by using the AS flooding
	scope of the RI LSA.</t>	scope of the RI LSA.</t>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-15.
	<section title="Usage of SRLG Exclude Rule with Flex-Algorithm">	2">
	<t>There are two different ways in which SRLG information can be used	<name slugifiedName="name-usage-of-the-srlg-exclude-r">Usage of the SRLG
	with Flex-Algorithm: <list style="hanging">	Exclude Rule with Flex-Algorithm</name>
	<t>In a context of a single Flex-Algorithm, it can be used for	<t indent="0" pn="section-15.2-1">There are two different ways in which
	computation of backup paths, as described in <xref	SRLG information can be used
	target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/>. This usage does	with Flex-Algorithms: </t>
	not require association of any specific SRLG constraint with the	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
	given Flex-Algorithm definition.</t>	5.2-2">
		<li pn="section-15.2-2.1">In a context of a single Flex-Algorithm, it
	<t>In the context of multiple Flex-Algorithms, it can be used for	can be used for
		computation of backup paths, as described in <xref target="I-D.ietf-rt
		gwg-segment-routing-ti-lfa" format="default" sectionFormat="of" derivedContent="
		RTGWG-SEGMENT-ROUTING-TI-LFA"/>. This usage
		does not require association of any specific SRLG constraint with the
		given Flex-Algorithm Definition.</li>
		<li pn="section-15.2-2.2">
		<t indent="0" pn="section-15.2-2.2.1">In the context of multiple Fle
		x-Algorithms, it can be used for
	creating disjoint sets of paths by pruning the links belonging to	creating disjoint sets of paths by pruning the links belonging to
	a specific SRLG from the topology on which a specific	a specific SRLG from the topology on which a specific

	Flex-Algorithm computes its paths. This usage: <list	Flex-Algorithm computes its paths. This usage: </t>
	style="hanging">	<ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
	<t>Facilitates the usage of already deployed SRLG	on-15.2-2.2.2">
	configurations for setup of disjoint paths between two or more	<li pn="section-15.2-2.2.2.1">facilitates the usage of already dep
	Flex-Algorithms.</t>	loyed SRLG
		configurations for the setup of disjoint paths between two or more
	<t>Requires explicit association of a given Flex-Algorithm	Flex-Algorithms and</li>
	with a specific set of SRLG constraints as defined in <xref	<li pn="section-15.2-2.2.2.2">requires explicit association of a g
	target="ISISFLEXALGEXSRLGTLV"/> and <xref	iven Flex-Algorithm
	target="OSPFFLEXALGEXSRLGTLV"/>.</t>	with a specific set of SRLG constraints, as defined in Sections <x
	</list></t>	ref target="ISISFLEXALGEXSRLGTLV" format="counter" sectionFormat="of" derivedCon
	</list></t>	tent="6.5"/> and <xref target="OSPFFLEXALGEXSRLGTLV" format="counter" sectionFor
		mat="of" derivedContent="7.5"/>.</li>
	<t>The two usages mentioned above are orthogonal.</t>	</ul>
		</li>
		</ul>
		<t indent="0" pn="section-15.2-3">The two usages mentioned above are ort
		hogonal.</t>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-15.
	<section title="Max-metric consideration">	3">
	<t>Both IS-IS and OSPF have a mechanism to set the IGP metric on a link	<name slugifiedName="name-max-metric-consideration">Max-Metric Considera
	to a value that would make the link either non-reachable or to serve	tion</name>
		<t indent="0" pn="section-15.3-1">Both IS-IS and OSPF have a mechanism t
		o set the IGP metric on a link
		to a value that would make the link either unreachable or serve
	as the link of last resort. Similar functionality would be needed for	as the link of last resort. Similar functionality would be needed for
	the Min Unidirectional Link Delay and TE metric, as these can be used	the Min Unidirectional Link Delay and TE metric, as these can be used
	to compute Flex-Algorithm paths.</t>	to compute Flex-Algorithm paths.</t>

		<t indent="0" pn="section-15.3-2">The link can be made unreachable for a
	<t>The link can be made un-reachable for all Flex-Algorithms that use	ll Flex-Algorithms that use the
	Min Unidirectional Link Delay as metric, as described in <xref	Min Unidirectional Link Delay as a metric, as described in <xref target=
	target="ISISFLEXALGTLV"/>, by removing the Flex-Algorithm ASLA Min	"ISISFLEXALGTLV" format="default" sectionFormat="of" derivedContent="Section 5.1
		"/>, by removing the Flex-Algorithm ASLA Min
	Unidirectional Link Delay advertisement for the link. The link can be	Unidirectional Link Delay advertisement for the link. The link can be
	made the link of last resort by setting the delay value in the	made the link of last resort by setting the delay value in the
	Flex-Algorithm ASLA delay advertisement for the link to the value of	Flex-Algorithm ASLA delay advertisement for the link to the value of

	16,777,215 (2^24 - 1).</t>	16,777,215 (2<sup>24</sup> - 1).</t>
		<t indent="0" pn="section-15.3-3">The link can be made unreachable for a
	<t>The link can be made un-reachable for all Flex-Algorithms that use	ll Flex-Algorithms that use the
	TE metric, as described in <xref target="ISISFLEXALGTLV"/>, by	TE metric, as described in <xref target="ISISFLEXALGTLV" format="default
		" sectionFormat="of" derivedContent="Section 5.1"/>, by
	removing the Flex-Algorithm ASLA TE metric advertisement for the link.	removing the Flex-Algorithm ASLA TE metric advertisement for the link.
	The link can be made the link of last resort by setting the TE metric	The link can be made the link of last resort by setting the TE metric
	value in the Flex-Algorithm ASLA delay advertisement for the link to	value in the Flex-Algorithm ASLA delay advertisement for the link to

	the value of (2^24 - 1) in IS-IS and (2^32 - 1) in OSPF.</t>	the value of (2<sup>24</sup> - 1) in IS-IS and (2<sup>32</sup> - 1) in O SPF.</t>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-15.
	<section title="FAD Definition and Changes">	4">
		<name slugifiedName="name-flexible-algorithm-definitio">Flexible Algorit
	<t>When configuring a node to participate in a specific Flex-Algorithm,	hm Definition and Changes</name>
	the components of the FAD (calculation-type, metric-type, constraints)	<t indent="0" pn="section-15.4-1">When configuring a node to participate
		in a specific Flex-Algorithm,
		the components of the FAD (calculation-type, metric-type, and constraints)
	should be considered carefully. The configuration of participation in a pa rticular	should be considered carefully. The configuration of participation in a pa rticular
	Flex-Algorithm doesn't guarantee that the node will actively participate i n it,	Flex-Algorithm doesn't guarantee that the node will actively participate i n it,

	because it may not support the calculation-type, metric type or some const	because it may not support the calculation-type, the metric-type, or some
	raint	constraint advertised by the winning FAD (see <xref target="COMMONLEXALGTL
	advertised by the winning FAD (see <xref target="COMMONLEXALGTLV"/>). Chan	V" format="default" sectionFormat="of" derivedContent="Section 5.3"/>). Changes
	ges in	in
	the FAD configuration should also be considered in light of the capabiliti es of	the FAD configuration should also be considered in light of the capabiliti es of
	the participating routers in the scope of the FAD advertisement.</t>	the participating routers in the scope of the FAD advertisement.</t>

		<t indent="0" pn="section-15.4-2">As <xref target="COMMONLEXALGTLV" form
	<t>As <xref target="COMMONLEXALGTLV"/> notes, a change in the Flex-Algorit	at="default" sectionFormat="of" derivedContent="Section 5.3"/> notes, a change i
	hm	n the Flex-Algorithm
	definition may require network-wide SPF re-computation and network re-conv	Definition may require network-wide Shortest Path First (SPF) recomputatio
	ergence.	n and network reconvergence.
	This potential for disruption should be taken into consideration when plan ning	This potential for disruption should be taken into consideration when plan ning
	and making changes to the FAD.</t>	and making changes to the FAD.</t>


	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-15.
	<section title="Number of Flex-Algorithms">	5">
	<t>The maximum number of Flex-Algorithms is determined by the algorithm ra	<name slugifiedName="name-number-of-flex-algorithms">Number of Flex-Algo
	nge	rithms</name>
	that is (128-255), as specified in <xref target="FLEXALG"/>. Although poss	<t indent="0" pn="section-15.5-1">The maximum number of Flex-Algorithms
	ible,	is determined by the algorithm range
		128-255, as specified in <xref target="FLEXALG" format="default" sectionFo
		rmat="of" derivedContent="Section 4"/>. Although possible,
	it is not expected that all of them will be used simultaneously. Typically ,	it is not expected that all of them will be used simultaneously. Typically ,
	only a limited subset of Flex-Algorithms is expected to be deployed in the network.</t>	only a limited subset of Flex-Algorithms is expected to be deployed in the network.</t>
	</section>	</section>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-16">
	<section title="Backward Compatibility">	<name slugifiedName="name-backward-compatibility">Backward Compatibility</
	<t>This extension brings no new backward compatibility issues. IS-IS,	name>
	OSPFv2 and OSPFv3 all have well-defined handling of unrecognized TLVs	<t indent="0" pn="section-16-1">This extension brings no new backward-comp
		atibility issues. IS-IS,
		OSPFv2, and OSPFv3 all have well-defined handling of unrecognized TLVs
	and sub-TLVs that allows the introduction of new extensions, similar	and sub-TLVs that allows the introduction of new extensions, similar
	to those defined here, without introducing any interoperability	to those defined here, without introducing any interoperability
	issues.</t>	issues.</t>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-17">
	<section title="Security Considerations">	<name slugifiedName="name-security-considerations">Security Considerations
	<t>This draft adds two new ways to disrupt IGP networks: <list	</name>
	style="hanging">	<t indent="0" pn="section-17-1">This document adds two new ways to disrupt
	<t>An attacker can hijack a particular Flex-Algorithm by advertising	IGP networks: </t>
	a FAD with a priority of 255 (or any priority higher than that of	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-17-
	the legitimate nodes).</t>	2">
		<li pn="section-17-2.1">An attacker can hijack a particular Flex-Algorit
	<t>An attacker could make it look like a router supports a	hm by advertising
	particular Flex-Algorithm when it actually doesn't, or vice	a FAD with a priority of 255 (or any priority higher than that of
	versa.</t>	the legitimate nodes).</li>
	</list></t>	<li pn="section-17-2.2">An attacker could make it look like a router sup
		ports a
	<t>Both of these attacks can be addressed by the existing security	particular Flex-Algorithm when it actually doesn't, or vice
	extensions as described in <xref target="RFC5304"/> and <xref	versa.</li>
	target="RFC5310"/> for IS-IS, in <xref target="RFC2328"/> and <xref	</ul>
	target="RFC7474"/> for OSPFv2, and in <xref target="RFC5340"/> and <xref	<t indent="0" pn="section-17-3">Both of these attacks can be addressed by
	target="RFC4552"/> for OSPFv3.</t>	the existing security
		extensions, as described in <xref target="RFC5304" format="default" sectio
	<t>If the node that is authenticated is taken over by an attacker, such ro	nFormat="of" derivedContent="RFC5304"/> and <xref target="RFC5310" format="defau
	gue	lt" sectionFormat="of" derivedContent="RFC5310"/> for IS-IS, in <xref target="RF
		C2328" format="default" sectionFormat="of" derivedContent="RFC2328"/> and <xref
		target="RFC7474" format="default" sectionFormat="of" derivedContent="RFC7474"/>
		for OSPFv2, and in <xref target="RFC4552" format="default" sectionFormat="of" de
		rivedContent="RFC4552"/> and <xref target="RFC5340" format="default" sectionForm
		at="of" derivedContent="RFC5340"/> for OSPFv3.</t>
		<t indent="0" pn="section-17-4">If the node that is authenticated is taken
		over by an attacker, such rogue
	node can advertise the FAD for any Flex-Algorithm. Doing so may result in	node can advertise the FAD for any Flex-Algorithm. Doing so may result in

	traffic for such Flex-Algorithm to be misrouted, or not being delivered	traffic for such Flex-Algorithm to be misrouted, or not delivered
	at all, for example, by using an unsupported metric-type, calculation-type ,	at all, for example, by using an unsupported metric-type, calculation-type ,
	or constraint. Such attack is not preventable through authentication, and it is	or constraint. Such attack is not preventable through authentication, and it is
	not different from advertising any other incorrect information through IS- IS or	not different from advertising any other incorrect information through IS- IS or
	OSPF.</t>	OSPF.</t>


	</section>	</section>

		<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
	<section anchor="IANA" title="IANA Considerations">	"section-18">
	<section anchor="IANAIGP" title="IGP IANA Considerations">	<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	<section anchor="IANAIGPIGPALGTYPE"	<section anchor="IANAIGP" numbered="true" toc="include" removeInRFC="false
	title="IGP Algorithm Types Registry">	" pn="section-18.1">
	<t>This document makes the following registrations in the "IGP	<name slugifiedName="name-igp-iana-considerations">IGP IANA Consideratio
	Algorithm Types" registry: <list style="hanging">	ns</name>
	<t>Type: 128-255.</t>	<section anchor="IANAIGPIGPALGTYPE" numbered="true" toc="include" remove
		InRFC="false" pn="section-18.1.1">
	<t>Description: Flexible Algorithms.</t>	<name slugifiedName="name-igp-algorithm-types-registr">IGP Algorithm T
		ypes Registry</name>
	<t>Reference: This document (<xref target="FLEXALG"/>).</t>	<t indent="0" pn="section-18.1.1-1">This document makes the following
	</list></t>	registration in the "IGP
		Algorithm Types" registry: </t>
		<table align="center" pn="table-1">
		<name slugifiedName="name-igp-algorithm-types-registry">IGP Algorith
		m Types Registry</name>
		<thead>
		<tr>
		<th align="left" colspan="1" rowspan="1">Value</th>
		<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">128-255</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithms</td
		>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"FLEXALG" format="default" sectionFormat="of" derivedContent="Section 4"/></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="IGPMETRICTYPE" numbered="true" toc="include" removeInRF
	<section anchor="IGPMETRICTYPE" title="IGP Metric-Type Registry">	C="false" pn="section-18.1.2">
	<t>IANA is requested to set up a registry called "IGP Metric-Type	<name slugifiedName="name-igp-metric-type-registry">IGP Metric-Type Re
	Registry" under the "Interior Gateway Protocol (IGP) Parameters" IANA	gistry</name>
	grouping. The registration policy for this registry is "Standards	<t indent="0" pn="section-18.1.2-1">IANA has created the "IGP Metric-T
	Action" (<xref target="RFC8126"/> and <xref target="RFC7120"/>).</t>	ype" registry
		within the "Interior Gateway Protocol (IGP) Parameters" registry group
	<t>Values in this registry come from the range 0-255.</t>	. The registration policy is "Standards
		Action" <xref target="RFC8126" format="default" sectionFormat="of" der
	<t>This document registers following values in the "IGP Metric-Type	ivedContent="RFC8126"/> <xref target="RFC7120" format="default" sectionFormat="o
	Registry": <list style="hanging">	f" derivedContent="RFC7120"/>. Values are assigned from the range 0-255 and have
	<t>Type: 0</t>	been registered as follows. </t>
		<table align="center" pn="table-2">
	<t>Description: IGP metric</t>	<name slugifiedName="name-igp-metric-type-registry-2">IGP Metric-Typ
		e Registry</name>
	<t>Reference: This document (<xref target="ISISFLEXALGTLV"/>)</t>	<thead>
		<tr>
	<t>Type: 1</t>	<th align="left" colspan="1" rowspan="1">Type</th>
		<th align="left" colspan="1" rowspan="1">Description</th>
	<t>Description: Min Unidirectional Link Delay as defined in	<th align="left" colspan="1" rowspan="1">Reference</th>
	<xref target="RFC8570"/>, section 4.2, and <xref	</tr>
	target="RFC7471"/>, section 4.2.</t>	</thead>
		<tbody>
	<t>Reference: This document (<xref	<tr>
	target="ISISFLEXALGTLV"/>)</t>	<td align="left" colspan="1" rowspan="1">0</td>
		<td align="left" colspan="1" rowspan="1">IGP Metric</td>
	<t>Type: 2</t>	<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"ISISFLEXALGTLV" format="default" sectionFormat="of" derivedContent="Section 5.1
	<t>Description: Traffic Engineering Default Metric as defined in	"/></td>
	<xref target="RFC5305"/>, section 3.7, and Traffic engineering	</tr>
	metric as defined in <xref target="RFC3630"/>, section 2.5.5</t>	<tr>
		<td align="left" colspan="1" rowspan="1">1</td>
	<t>Reference: This document (<xref	<td align="left" colspan="1" rowspan="1">Min Unidirectional Link
	target="ISISFLEXALGTLV"/>)</t>	Delay as defined in <xref target="RFC8570" section="4.2" sectionFormat="comma"
	</list></t>	format="default" derivedLink="https://rfc-editor.org/rfc/rfc8570#section-4.2" de
		rivedContent="RFC8570"/> and <xref target="RFC7471" section="4.2" sectionFormat=
		"comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7471#section
		-4.2" derivedContent="RFC7471"/></td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"ISISFLEXALGTLV" format="default" sectionFormat="of" derivedContent="Section 5.1
		"/></td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">2</td>
		<td align="left" colspan="1" rowspan="1">Traffic Engineering Def
		ault Metric as defined in <xref target="RFC5305" section="3.7" sectionFormat="co
		mma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5305#section-3.
		7" derivedContent="RFC5305"/> and Traffic Engineering Metric as defined in <xref
		target="RFC3630" section="2.5.5" sectionFormat="comma" format="default" derived
		Link="https://rfc-editor.org/rfc/rfc3630#section-2.5.5" derivedContent="RFC3630"
		/></td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"ISISFLEXALGTLV" format="default" sectionFormat="of" derivedContent="Section 5.1
		"/></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>
	</section>	</section>

		<section anchor="IANAFADFLGAS" numbered="true" toc="include" removeInRFC="
	<section anchor="IANAFADFLGAS"	false" pn="section-18.2">
	title="Flexible Algorithm Definition Flags Registry">	<name slugifiedName="name-igp-flexible-algorithm-defi">IGP Flexible Algo
	<t>IANA is requested to set up a registry called "IGP Flexible	rithm Definition Flags Registry</name>
	Algorithm Definition Flags Registry" under the "Interior Gateway	<t indent="0" pn="section-18.2-1">IANA has created the "IGP Flexible
	Protocol (IGP) Parameters" IANA grouping. The registration policy	Algorithm Definition Flags" registry within the "Interior Gateway
	for this registry is "Standards Action" (<xref target="RFC8126"/> and	Protocol (IGP) Parameters" registry group. The registration policy
	<xref target="RFC7120"/>). New registrations should be assigned in	is "Standards Action". New registrations should be assigned in
	ascending bit order (see <xref target="ISISFLEXALGFLAG"/>).</t>	ascending bit order (see <xref target="ISISFLEXALGFLAG" format="default"
		sectionFormat="of" derivedContent="Section 6.4"/>); the following single bit ha
	<t>This document defines the following single bit in Flexible	s been assigned as follows.</t>
	Algorithm Definition Flags registry: <figure>	<table align="center" pn="table-3">
	<artwork><![CDATA[	<name slugifiedName="name-igp-flexible-algorithm-defin">IGP Flexible A
	Bit # Name	lgorithm Definition Flags Registry</name>
	----- ------------------------------	<thead>
	0 Prefix Metric Flag (M-flag)	<tr>
		<th align="left" colspan="1" rowspan="1">Bit</th>
	]]></artwork>	<th align="left" colspan="1" rowspan="1">Name</th>
	</figure></t>	<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
	<t>Reference: This document (<xref target="ISISFLEXALGFLAG"/>, <xref	</thead>
	target="OSPFFLEXALGFLAG"/>).</t>	<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">0</td>
		<td align="left" colspan="1" rowspan="1">Prefix Metric Flag (M-fla
		g)</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, Sections <xref
		target="ISISFLEXALGFLAG" format="counter" sectionFormat="of" derivedContent="6.4
		"/> and <xref target="OSPFFLEXALGFLAG" format="counter" sectionFormat="of" deri
		vedContent="7.4"/></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="IANAISIS" numbered="true" toc="include" removeInRFC="fals
	<section anchor="IANAISIS" title="IS-IS IANA Considerations">	e" pn="section-18.3">
	<section anchor="SUBTLVS" title="IS-IS Sub-TLVs for IS-IS Router CAPABIL	<name slugifiedName="name-is-is-iana-considerations">IS-IS IANA Consider
	ITY TLV">	ations</name>
	<t>This document makes the following registrations in the	<section anchor="SUBTLVS" numbered="true" toc="include" removeInRFC="fal
	"IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry. <list style	se" pn="section-18.3.1">
	="hanging">	<name slugifiedName="name-is-is-sub-tlvs-for-is-is-ro">IS-IS Sub-TLVs
	<t>Type: 26.</t>	for IS-IS Router CAPABILITY TLV Registry</name>
		<t indent="0" pn="section-18.3.1-1">This document makes the following
	<t>Description: Flexible Algorithm Definition (FAD)</t>	registration in the
		"IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry. </t>
	<t>Reference: This document (<xref target="ISISFLEXALGTLV"/>).</t>	<table align="center" pn="table-4">
	</list></t>	<name slugifiedName="name-is-is-sub-tlvs-for-is-is-rou">IS-IS Sub-TL
		Vs for IS-IS Router CAPABILITY TLV Registry</name>
		<thead>
		<tr>
		<th align="left" colspan="1" rowspan="1">Value</th>
		<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">26</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Defi
		nition (FAD)</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"ISISFLEXALGTLV" format="default" sectionFormat="of" derivedContent="Section 5.1
		"/></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="SUBTLVS135" numbered="true" toc="include" removeInRFC="
	<section anchor="SUBTLVS135"	false" pn="section-18.3.2">
	title="IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability"	<name slugifiedName="name-is-is-sub-tlvs-for-tlvs-adv">IS-IS Sub-TLVs
	>	for TLVs Advertising Prefix Reachability Registry</name>
	<t>This document makes the following registrations in the	<t indent="0" pn="section-18.3.2-1">This document makes the following
	"IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability" registry. <l	registration in the
	ist style="hanging">	"IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability" registry. </
	<t>Type: 6</t>	t>
		<table align="center" pn="table-5">
	<t>Description: Flexible Algorithm Prefix Metric (FAPM).</t>	<name slugifiedName="name-is-is-sub-tlvs-for-tlvs-adve">IS-IS Sub-TL
		Vs for TLVs Advertising Prefix Reachability Registry</name>
	<t>Reference: This document (<xref target="ISISFLEXMETRIC"/>).</t>	<thead>
	</list></t>	<tr>
		<th align="left" colspan="1" rowspan="1">Type</th>
		<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">27</th>
		<th align="left" colspan="1" rowspan="1">135</th>
		<th align="left" colspan="1" rowspan="1">235</th>
		<th align="left" colspan="1" rowspan="1">236</th>
		<th align="left" colspan="1" rowspan="1">237</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">6</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Pref
		ix Metric (FAPM)</td>
		<td align="left" colspan="1" rowspan="1">n</td>
		<td align="left" colspan="1" rowspan="1">y</td>
		<td align="left" colspan="1" rowspan="1">y</td>
		<td align="left" colspan="1" rowspan="1">y</td>
		<td align="left" colspan="1" rowspan="1">y</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"ISISFLEXMETRIC" format="default" sectionFormat="of" derivedContent="Section 8"/
		></td>
		</tr>
		</tbody>
		</table>
		</section>
		<section anchor="SUBTLVREGISTRY" numbered="true" toc="include" removeInR
		FC="false" pn="section-18.3.3">
		<name slugifiedName="name-is-is-sub-sub-tlvs-for-flex">IS-IS Sub-Sub-T
		LVs for Flexible Algorithm Definition Sub-TLV Registry</name>
		<t indent="0" pn="section-18.3.3-1">IANA has created the "IS-IS Sub-Su
		b-TLVs for Flexible Algorithm Definition Sub-TLV" registry within the
		"IS-IS TLV Codepoints" registry group. The registration procedure is "E
		xpert Review" (note that the "IS-IS TLV
		Codepoints" registry group includes Expert Review guidance that applies
		to all registries thereunder).</t>
		<t indent="0" pn="section-18.3.3-2">The sub-sub-TLVs defined in this d
		ocument have been assigned as follows.
		</t>
		<table align="center" pn="table-6">
		<name slugifiedName="name-is-is-sub-sub-tlvs-for-flexi">IS-IS Sub-Su
		b-TLVs for Flexible Algorithm Definition Sub-TLV Registry</name>
		<thead>
		<tr>
		<th align="left" colspan="1" rowspan="1">Type</th>
		<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">0</td>
		<td align="left" colspan="1" rowspan="1">Reserved</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">1</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Excl
		ude Admin Group</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"ISISFLEXALGEXLTLV" format="default" sectionFormat="of" derivedContent="Section
		6.1"/></td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">2</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Incl
		ude-Any Admin Group</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"ISISFLEXALGINCANYTLV" format="default" sectionFormat="of" derivedContent="Secti
		on 6.2"/></td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">3</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Incl
		ude-All Admin Group</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"ISISFLEXALGINCALLTLV" format="default" sectionFormat="of" derivedContent="Secti
		on 6.3"/></td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">4</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Defi
		nition Flags</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"ISISFLEXALGFLAG" format="default" sectionFormat="of" derivedContent="Section 6.
		4"/></td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">5</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Excl
		ude SRLG</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"ISISFLEXALGEXSRLGTLV" format="default" sectionFormat="of" derivedContent="Secti
		on 6.5"/></td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">6-255</td>
		<td align="left" colspan="1" rowspan="1">Unassigned</td>
		<td align="left" colspan="1" rowspan="1"/>
		</tr>
		</tbody>
		</table>
	</section>	</section>


	<section anchor="SUBTLVREGISTRY"
	title="Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV">
	<t>This document creates the following Sub-Sub-TLV Registry, under the
	IS-IS TLV Codepoints grouping. <list style="hanging">
	<t>Registry: Sub-Sub-TLVs for Flexible Algorithm Definition
	Sub-TLV</t>

	<t>Registration Procedure: Expert review. (Note that the IS-IS TLV
	Codepoints grouping includes Expert Review guidance that applies t
	o
	all registries thereunder.) </t>

	<t>Reference: This document (<xref
	target="ISISFLEXALGTLV"/>)</t>
	</list></t>

	<t>This document defines the following Sub-Sub-TLVs in the
	"Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry:
	<list style="hanging">
	<t>Type: 0</t>

	<t>Description: Reserved</t>

	<t>Reference: This document.</t>
	</list> <list style="hanging">
	<t>Type: 1</t>

	<t>Description: Flexible Algorithm Exclude Admin Group</t>

	<t>Reference: This document (<xref target="ISISFLEXALGEXLTLV"/>).<
	/t>
	</list> <list style="hanging">
	<t>Type: 2</t>

	<t>Description: Flexible Algorithm Include-Any Admin Group</t>

	<t>Reference: This document (<xref target="ISISFLEXALGINCANYTLV"/>
	).</t>
	</list> <list style="hanging">
	<t>Type: 3</t>

	<t>Description: Flexible Algorithm Include-All Admin Group</t>

	<t>Reference: This document (<xref target="ISISFLEXALGINCALLTLV"/>
	).</t>
	</list> <list style="hanging">
	<t>Type: 4</t>

	<t>Description: Flexible Algorithm Definition Flags</t>

	<t>Reference: This document (<xref target="ISISFLEXALGFLAG"/>).</t
	>
	</list> <list style="hanging">
	<t>Type: 5</t>

	<t>Description: Flexible Algorithm Exclude SRLG</t>

	<t>Reference: This document (<xref target="ISISFLEXALGEXSRLGTLV"/>
	).</t>
	</list> <list style="hanging">
	<t>Type: 6-255</t>

	<t>Description: Unassigned</t>

	<t>Reference: This document.</t>
	</list></t>
	</section>
	</section>	</section>

		<section anchor="IANAOSPF" numbered="true" toc="include" removeInRFC="fals
	<section anchor="IANAOSPF" title="OSPF IANA Considerations">	e" pn="section-18.4">
	<section anchor="RITLVREG"	<name slugifiedName="name-ospf-iana-considerations">OSPF IANA Considerat
	title="OSPF Router Information (RI) TLVs Registry">	ions</name>
	<t>This specification makes the following registration in the OSPF	<section anchor="RITLVREG" numbered="true" toc="include" removeInRFC="fa
	Router Information (RI) TLVs Registry. <list style="hanging">	lse" pn="section-18.4.1">
	<t>Type: 16</t>	<name slugifiedName="name-ospf-router-information-ri-">OSPF Router Inf
		ormation (RI) TLVs Registry</name>
	<t>Description: Flexible Algorithm Definition (FAD) TLV.</t>	<t indent="0" pn="section-18.4.1-1">This document makes the following
		registration in the "OSPF
	<t>Reference: This document (<xref	Router Information (RI) TLVs" registry. </t>
	target="OSPFFLEXALGTLV"/>).</t>	<table align="center" pn="table-7">
	</list></t>	<name slugifiedName="name-ospf-router-information-ri-t">OSPF Router
		Information (RI) TLVs Registry</name>
		<thead>
		<tr>
		<th align="left" colspan="1" rowspan="1">Value</th>
		<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">16</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Defi
		nition (FAD) TLV</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"OSPFFLEXALGTLV" format="default" sectionFormat="of" derivedContent="Section 5.2
		"/></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="SUBTLVEXTPFX" numbered="true" toc="include" removeInRFC
	<section anchor="SUBTLVEXTPFX"	="false" pn="section-18.4.2">
	title="OSPFv2 Extended Prefix TLV Sub-TLVs">	<name slugifiedName="name-ospfv2-extended-prefix-tlv-">OSPFv2 Extended
	<t>This document makes the following registrations in the "OSPFv2	Prefix TLV Sub-TLVs Registry</name>
	Extended Prefix TLV Sub-TLVs" registry. <list style="hanging">	<t indent="0" pn="section-18.4.2-1">This document makes the following
	<t>Type: 3</t>	registration in the "OSPFv2
		Extended Prefix TLV Sub-TLVs" registry. </t>
	<t>Description: Flexible Algorithm Prefix Metric (FAPM).</t>	<table align="center" pn="table-8">
		<name slugifiedName="name-ospfv2-extended-prefix-tlv-s">OSPFv2 Exten
	<t>Reference: This document (<xref	ded Prefix TLV Sub-TLVs Registry</name>
	target="OSPFFLEXMETRIC"/>).</t>	<thead>
	</list></t>	<tr>
		<th align="left" colspan="1" rowspan="1">Value</th>
		<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">3</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Pref
		ix Metric (FAPM)</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"OSPFFLEXMETRIC" format="default" sectionFormat="of" derivedContent="Section 9"/
		></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="SUBTLVV3EXTLSA" numbered="true" toc="include" removeInR
	<section anchor="SUBTLVV3EXTLSA" title="OSPFv3 Extended-LSA Sub-TLVs">	FC="false" pn="section-18.4.3">
	<t>This document makes the following registrations in the "OSPFv3	<name slugifiedName="name-ospfv3-extended-lsa-sub-tlv">OSPFv3 Extended
	Extended-LSA Sub-TLVs" registry. <list style="hanging">	-LSA Sub-TLVs Registry</name>
	<t>Type: 26</t>	<t indent="0" pn="section-18.4.3-1">This document makes the following
		registrations in the "OSPFv3
	<t>Description: Flexible Algorithm Prefix Metric (FAPM).</t>	Extended-LSA Sub-TLVs" registry. </t>
		<table align="center" pn="table-9">
	<t>Reference: This document (<xref	<name slugifiedName="name-ospfv3-extended-lsa-sub-tlvs">OSPFv3 Exten
	target="OSPFFLEXMETRIC"/>).</t>	ded-LSA Sub-TLVs Registry</name>
		<thead>
	<t>Type: 33</t>	<tr>
		<th align="left" colspan="1" rowspan="1">Value</th>
	<t>Description: OSPF Flexible Algorithm ASBR Metric</t>	<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
	<t>Reference: This document (<xref target="OSPFFAASBRMETRIC"/>).</	</tr>
	t>	</thead>
	</list></t>	<tbody>
		<tr>
	<t>For both of these sub-TLVs the column L2BN in the registry is set	<td align="left" colspan="1" rowspan="1">26</td>
	to "X" -	<td align="left" colspan="1" rowspan="1">Flexible Algorithm Pref
	meaning "sub-TLV is not a Router Link sub-TLV; it MUST NOT appear	ix Metric (FAPM)</td>
	in L2 Bundle Member sub-TLV".</t>	<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"OSPFFLEXMETRIC" format="default" sectionFormat="of" derivedContent="Section 9"/
		></td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">33</td>
		<td align="left" colspan="1" rowspan="1">OSPF Flexible Algorithm
		ASBR Metric</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"OSPFFAASBRMETRIC" format="default" sectionFormat="of" derivedContent="Section 1
		0.2"/></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="FAPMFLAGS" numbered="true" toc="include" removeInRFC="f
	<section anchor="FAPMFLAGS"	alse" pn="section-18.4.4">
	title="OSPF Flex-Algorithm Prefix Metric Bits">	<name slugifiedName="name-ospf-flex-algorithm-prefix-">OSPF Flex-Algor
	<t>This specification requests creation of the "OSPF Flex-Algorithm	ithm Prefix Metric Bits Registry</name>
		<t indent="0" pn="section-18.4.4-1">IANA has created the "OSPF Flex-Al
		gorithm
	Prefix Metric Bits" registry under the "Open Shortest Path First	Prefix Metric Bits" registry under the "Open Shortest Path First

	(OSPF) Parameters" with the following initial values:</t>	(OSPF) Parameters" registry. The registration procedure
		is "IETF Review". Bits 1-7 are unassigned, and the initial value has b
	<t><list style="hanging">	een assigned as follows.</t>
	<t>Bit Number: 0</t>	<table align="center" pn="table-10">
		<name slugifiedName="name-ospf-flex-algorithm-prefix-m">OSPF Flex-Al
	<t>Description: E bit - External Type</t>	gorithm Prefix Metric Bits Registry</name>
		<thead>
	<t>Reference: this document (<xref target="OSPFFLEXMETRIC"/>).</t>	<tr>
	</list>The bits 1-7 are unassigned and the registration procedure	<th align="left" colspan="1" rowspan="1">Bit Number</th>
	to be followed for this registry is IETF Review.</t>	<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">0</td>
		<td align="left" colspan="1" rowspan="1">E bit - External Type</
		td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"OSPFFLEXMETRIC" format="default" sectionFormat="of" derivedContent="Section 9"/
		></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="OPQLSAOPTS" numbered="true" toc="include" removeInRFC="
	<section anchor="OPQLSAOPTS" title="OSPFv2 Opaque LSA Option Types ">	false" pn="section-18.4.5">
	<t>This document makes the following registrations in the "Opaque Link	<name slugifiedName="name-opaque-link-state-advertise">Opaque Link-Sta
	-State	te Advertisements (LSA) Option Types Registry</name>
	Advertisements (LSA) Option Types" registry under the "Open Shortest P	<t indent="0" pn="section-18.4.5-1">This document makes the following
	ath First	registration in the "Opaque Link-State
	(OSPF) Opaque Link-State Advertisements (LSA) Option Types" grouping.	Advertisements (LSA) Option Types" registry within the "Open Shortest
	<list style="hanging">	Path First
		(OSPF) Opaque Link-State Advertisements (LSA) Option Types" registry g
	<t>Value: 11</t>	roup. </t>
		<table align="center" pn="table-11">
	<t>Description: OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA</t>	<name slugifiedName="name-opaque-link-state-advertisem">Opaque Link-
		State Advertisements (LSA) Option Types Registry</name>
	<t>Reference: This document (<xref	<thead>
	target="OSPFEXTASBRLSA"/>).</t>	<tr>
	</list></t>	<th align="left" colspan="1" rowspan="1">Value</th>
		<th align="left" colspan="1" rowspan="1">Opaque Type</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">11</td>
		<td align="left" colspan="1" rowspan="1">OSPFv2 Extended Inter-A
		rea ASBR (EIA-ASBR) LSA</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"OSPFEXTASBRLSA" format="default" sectionFormat="of" derivedContent="Section 10.
		1"/></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="IAASBRTLV" numbered="true" toc="include" removeInRFC="f
	<section anchor="IAASBRTLV"	alse" pn="section-18.4.6">
	title="OSPFv2 Extended Inter-Area ASBR TLVs">	<name slugifiedName="name-ospfv2-extended-inter-area-as">OSPFv2 Extend
	<t>This specification requests creation of "OSPFv2 Extended	ed Inter-Area ASBR TLVs Registry</name>
	Inter-Area ASBR TLVs" registry under the OSPFv2 Parameters Registry	<t indent="0" pn="section-18.4.6-1">IANA has created the "OSPFv2 Exten
	with the following initial values.</t>	ded
		Inter-Area ASBR TLVs" registry within the "Open Shortest Path First v2
	<t><list style="hanging">	(OSPFv2) Parameters" registry group. The registration procedure is "IETF Review
	<t>Value: 1</t>	" or "IESG Approval". The initial value has been assigned as follows.</t>
		<table align="center" pn="table-12">
	<t>Description : Extended Inter-Area ASBR</t>	<name slugifiedName="name-ospfv2-extended-inter-area-asb">OSPFv2 Ext
		ended Inter-Area ASBR TLVs Registry</name>
	<t>Reference: this document</t>	<thead>
	</list>The values 2 to 32767 are unassigned, values 32768 to 33023	<tr>
	are reserved for experimental use while the values 0 and 33024 to	<th align="left" colspan="1" rowspan="1">Value</th>
	65535 are reserved. The registration procedure to be followed for	<th align="left" colspan="1" rowspan="1">Description</th>
	this registry is IETF Review or IESG Approval.</t>	<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">1</td>
		<td align="left" colspan="1" rowspan="1">Extended Inter-Area ASB
		R</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350</td>
		</tr>
		</tbody>
		</table>
		<t indent="0" pn="section-18.4.6-3">The values 2-32767 are unassigned,
		the values 32768-33023
		are reserved for Experimental Use, and the values 0 and 33024-65535 ar
		e
		reserved.</t>
	</section>	</section>

		<section anchor="IAASBRSTLV" numbered="true" toc="include" removeInRFC="
	<section anchor="IAASBRSTLV" title="OSPFv2 Inter-Area ASBR Sub-TLVs">	false" pn="section-18.4.7">
	<t>This specification requests creation of "OSPFv2 Extended	<name slugifiedName="name-ospfv2-extended-inter-area-asbr">OSPFv2 Exte
		nded Inter-Area ASBR Sub-TLVs Registry</name>
		<t indent="0" pn="section-18.4.7-1">IANA has created the "OSPFv2 Exten
		ded
	Inter-Area ASBR Sub-TLVs" registry under the "Open Shortest Path	Inter-Area ASBR Sub-TLVs" registry under the "Open Shortest Path

	First v2 (OSPFv2) Parameters" grouping, with the following initial val	First v2 (OSPFv2) Parameters" registry. The registration procedure is
	ues.</t>	"IETF Review" or "IESG Approval". The initial value has been assigned as follows
		.</t>
	<t><list style="hanging">	<table align="center" pn="table-13">
	<t>Value: 1</t>	<name slugifiedName="name-ospfv2-extended-inter-area-asbr-">OSPFv2 E
		xtended Inter-Area ASBR Sub-TLVs Registry</name>
	<t>Description : OSPF Flexible Algorithm ASBR Metric</t>	<thead>
		<tr>
	<t>Reference: this document</t>	<th align="left" colspan="1" rowspan="1">Value</th>
	</list>The values 2 to 32767 are unassigned, values 32768 to 33023	<th align="left" colspan="1" rowspan="1">Description</th>
	are reserved for experimental use while the values 0 and 33024 to	<th align="left" colspan="1" rowspan="1">Reference</th>
	65535 are reserved. The registration procedure to be followed for	</tr>
	this registry is IETF Review or IESG Approval.</t>	</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">1</td>
		<td align="left" colspan="1" rowspan="1">OSPF Flexible Algorithm
		ASBR Metric</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350</td>
		</tr>
		</tbody>
		</table>
		<t indent="0" pn="section-18.4.7-3">The values 2-32767 are unassigned,
		the values 32768-33023
		are reserved for Experimental Use, and the values 0 and 33024-65535 ar
		e
		reserved.</t>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-1
	<section title="OSPF Flexible Algorithm Definition TLV Sub-TLV Registry"	8.4.8">
	>	<name slugifiedName="name-ospf-flexible-algorithm-defin">OSPF Flexible
	<t>This document creates the following registry under the "Open Shorte	Algorithm Definition TLV Sub-TLVs Registry</name>
	st	<t indent="0" pn="section-18.4.8-1">IANA has created the "OSPF Flexibl
	Path First (OSPF) Parameters" grouping:	e Algorithm Definition TLV Sub-TLVs" registry within the "Open Shortest Path Fir
	<list style="hanging">	st (OSPF) Parameters" registry group. The registration procedure is "IETF Review
	<t>Registry: OSPF Flexible Algorithm Definition TLV sub-TLVs</t>	" or "IESG Approval".
		</t>
	<t>Registration Procedure: IETF Review or IESG Approval</t>	<t indent="0" pn="section-18.4.8-2">The "OSPF Flexible Algorithm Defin
		ition TLV Sub-TLVs" registry
	<t>Reference: This document (<xref
	target="OSPFFLEXALGTLV"/>)</t>
	</list></t>

	<t>The "OSPF Flexible Algorithm Definition TLV sub-TLV" registry
	will define sub-TLVs at any level of nesting for the Flexible	will define sub-TLVs at any level of nesting for the Flexible

	Algorithm TLV New values can be allocated via IETF Review or IESG App	Algorithm TLV, and new values can be allocated via the registration pr
	roval.</t>	ocedure.</t>
		<t indent="0" pn="section-18.4.8-3">This document registers the follow
	<t>This document registers following Sub-TLVs in the "OSPF Flexible Al	ing sub-TLVs. </t>
	gorithm	<table align="center" pn="table-14">
	Definition TLV sub-TLV" registry: <list style="hanging">	<name slugifiedName="name-ospf-flexible-algorithm-defini">OSPF Flexi
	<t>Type: 0</t>	ble Algorithm Definition TLV Sub-TLVs Registry</name>
		<thead>
	<t>Description: Reserved</t>	<tr>
		<th align="left" colspan="1" rowspan="1">Bit Number</th>
	<t>Reference: This document (<xref	<th align="left" colspan="1" rowspan="1">Description</th>
	target="OSPFFLEXALGEXLTLV"/>).</t>	<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
	</list><list style="hanging">	</thead>
	<t>Type: 1</t>	<tbody>
		<tr>
	<t>Description: Flexible Algorithm Exclude Admin Group</t>	<td align="left" colspan="1" rowspan="1">0</td>
		<td align="left" colspan="1" rowspan="1">Reserved</td>
	<t>Reference: This document (<xref	<td align="left" colspan="1" rowspan="1">RFC 9350</td>
	target="OSPFFLEXALGEXLTLV"/>).</t>	</tr>
	</list> <list style="hanging">	<tr>
	<t>Type: 2</t>	<td align="left" colspan="1" rowspan="1">1</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Excl
	<t>Description: Flexible Algorithm Include-Any Admin Group</t>	ude Admin Group</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
	<t>Reference: This document (<xref	"OSPFFLEXALGEXLTLV" format="default" sectionFormat="of" derivedContent="Section
	target="OSPFFLEXALGINCANYTLV"/>).</t>	7.1"/></td>
	</list> <list style="hanging">	</tr>
	<t>Type: 3</t>	<tr>
		<td align="left" colspan="1" rowspan="1">2</td>
	<t>Description: Flexible Algorithm Include-All Admin Group</t>	<td align="left" colspan="1" rowspan="1">Flexible Algorithm Incl
		ude-Any Admin Group</td>
	<t>Reference: This document (<xref	<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
	target="OSPFFLEXALGINCALLTLV"/>).</t>	"OSPFFLEXALGINCANYTLV" format="default" sectionFormat="of" derivedContent="Secti
	</list> <list style="hanging">	on 7.2"/></td>
	<t>Type: 4</t>	</tr>
		<tr>
	<t>Description: Flexible Algorithm Definition Flags</t>	<td align="left" colspan="1" rowspan="1">3</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Incl
	<t>Reference: This document (<xref	ude-All Admin Group</td>
	target="OSPFFLEXALGFLAG"/>).</t>	<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
	</list> <list style="hanging">	"OSPFFLEXALGINCALLTLV" format="default" sectionFormat="of" derivedContent="Secti
	<t>Type: 5</t>	on 7.3"/></td>
		</tr>
	<t>Description: Flexible Algorithm Exclude SRLG</t>	<tr>
		<td align="left" colspan="1" rowspan="1">4</td>
	<t>Reference: This document (<xref	<td align="left" colspan="1" rowspan="1">Flexible Algorithm Defi
	target="OSPFFLEXALGEXSRLGTLV"/>).</t>	nition Flags</td>
	</list></t>	<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"OSPFFLEXALGFLAG" format="default" sectionFormat="of" derivedContent="Section 7.
	<t>The values 6 to 32767 are unassigned, values 32768-33023 are for	4"/></td>
	experimental use; these will not be registered with IANA.</t>	</tr>
		<tr>
	<t>Types in the range 33024-65535 are not to be assigned at this	<td align="left" colspan="1" rowspan="1">5</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm Excl
		ude SRLG</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"OSPFFLEXALGEXSRLGTLV" format="default" sectionFormat="of" derivedContent="Secti
		on 7.5"/></td>
		</tr>
		</tbody>
		</table>
		<t indent="0" pn="section-18.4.8-5">The values 6-32767 are unassigned,
		and values 32768-33023 are for
		Experimental Use; these will not be registered with IANA.</t>
		<t indent="0" pn="section-18.4.8-6">Types in the range 33024-65535 are
		not to be assigned at this
	time. Before any assignments can be made in the 33024-65535 range,	time. Before any assignments can be made in the 33024-65535 range,

	there MUST be an IETF specification that specifies IANA	there <bcp14>MUST</bcp14> be an IETF specification that specifies IANA
	Considerations that covers the range being assigned.</t>	considerations that cover the range being assigned.</t>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-1
	<section title="Link Attribute Applications Registry">	8.4.9">
	<t>This document registers following bit in the Link Attribute	<name slugifiedName="name-link-attribute-application-">Link Attribute
	Applications Registry: <list style="hanging">	Application Identifiers Registry</name>
	<t>Bit-3</t>	<t indent="0" pn="section-18.4.9-1">This document registers the follow
		ing bit in the "Link Attribute
	<t>Description: Flexible Algorithm (X-bit)</t>	Application Identifiers" registry.</t>
		<table align="center" pn="table-15">
	<t>Reference: This document (<xref	<name slugifiedName="name-link-attribute-application-i">Link Attribu
	target="FLEXALGLINKATTR"/>).</t>	te Application Identifiers Registry</name>
	</list></t>	<thead>
		<tr>
		<th align="left" colspan="1" rowspan="1">Bit</th>
		<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">3</td>
		<td align="left" colspan="1" rowspan="1">Flexible Algorithm (X-b
		it)</td>
		<td align="left" colspan="1" rowspan="1">RFC 9350, <xref target=
		"FLEXALGLINKATTR" format="default" sectionFormat="of" derivedContent="Section 12
		"/></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>
	</section>	</section>
	</section>	</section>


	<section anchor="ACK" title="Acknowledgements">
	<t>This draft, among other things, is also addressing the problem that
	the <xref target="I-D.gulkohegde-routing-planes-using-sr"/> was trying
	to solve. All authors of that draft agreed to join this draft.</t>

	<t>Thanks to Eric Rosen, Tony Przygienda, William Britto A J, Gunter Van
	De Velde, Dirk Goethals, Manju Sivaji and, Baalajee S for their detailed
	review and excellent comments.</t>

	<t>Thanks to Cengiz Halit for his review and feedback during initial
	phase of the solution definition.</t>

	<t>Thanks to Kenji Kumaki for his comments.</t>

	<t>Thanks to Acee Lindem for editorial comments.</t>
	</section>
	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">	<displayreference target="I-D.gulkohegde-routing-planes-using-sr" to="ROUTIN
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	G-PLANES-USING-SR"/>
	FC.2119.xml"?>	<displayreference target="I-D.ietf-rtgwg-segment-routing-ti-lfa" to="RTGWG-S
		EGMENT-ROUTING-TI-LFA"/>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<references pn="section-19">
	FC.4203.xml"?>	<name slugifiedName="name-references">References</name>
		<references pn="section-19.1">
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<name slugifiedName="name-normative-references">Normative References</na
	FC.5307.xml"?>	me>
		<reference anchor="ISO10589" quoteTitle="true" derivedAnchor="ISO10589">
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<front>
	FC.7308.xml"?>	<title>Information technology - Telecommunications and information e
		xchange between systems - Intermediate System to Intermediate System intra-domai
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	n routeing information exchange protocol for use in conjunction with the protoco
	FC.5250.xml"?>	l for providing the connectionless-mode network service (ISO 8473)</title>
		<author>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<organization abbrev="ISO" showOnFrontPage="true">International Or
	FC.8920.xml"?>	ganization for Standardization</organization>
		</author>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<date month="November" year="2002"/>
	FC.8919.xml"?>	</front>
		<seriesInfo name="ISO/IEC" value="10589:2002"/>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<refcontent>Second Edition</refcontent>
	FC.7770.xml"?>	</reference>
		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	119" quoteTitle="true" derivedAnchor="RFC2119">
	FC.7981.xml"?>	<front>
		<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	le>
	FC.8174.xml"?>	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
		<date month="March" year="1997"/>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<abstract>
	FC.7684.xml"?>	<t indent="0">In many standards track documents several words are
		used to signify the requirements in the specification. These words are often ca
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	pitalized. This document defines these words as they should be interpreted in I
	FC.8362.xml"?>	ETF documents. This document specifies an Internet Best Current Practices for t
		he Internet Community, and requests discussion and suggestions for improvements.
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	</t>
	FC.8660.xml"?>	</abstract>
		</front>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<seriesInfo name="BCP" value="14"/>
	FC.8665.xml"?>	<seriesInfo name="RFC" value="2119"/>
		<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	</reference>
	FC.8666.xml"?>	<reference anchor="RFC4203" target="https://www.rfc-editor.org/info/rfc4
		203" quoteTitle="true" derivedAnchor="RFC4203">
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<front>
	FC.8667.xml"?>	<title>OSPF Extensions in Support of Generalized Multi-Protocol Labe
		l Switching (GMPLS)</title>
	<reference anchor="ISO10589">	<author fullname="K. Kompella" initials="K." role="editor" surname="
	<front>	Kompella"/>
	<title>Intermediate system to Intermediate system intra-domain	<author fullname="Y. Rekhter" initials="Y." role="editor" surname="R
	routeing information exchange protocol for use in conjunction with	ekhter"/>
	the protocol for providing the connectionless-mode Network Service	<date month="October" year="2005"/>
	(ISO 8473)</title>	<abstract>
		<t indent="0">This document specifies encoding of extensions to th
	<author>	e OSPF routing protocol in support of Generalized Multi-Protocol Label Switching
	<organization abbrev="ISO">International Organization for	(GMPLS). [STANDARDS-TRACK]</t>
	Standardization</organization>	</abstract>
	</author>	</front>
		<seriesInfo name="RFC" value="4203"/>
	<date month="Nov" year="2002"/>	<seriesInfo name="DOI" value="10.17487/RFC4203"/>
	</front>	</reference>
		<reference anchor="RFC5250" target="https://www.rfc-editor.org/info/rfc5
	<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>	250" quoteTitle="true" derivedAnchor="RFC5250">
	</reference>	<front>
		<title>The OSPF Opaque LSA Option</title>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.	<author fullname="L. Berger" initials="L." surname="Berger"/>
	I-D.ietf-lsr-isis-srv6-extensions.xml"?>	<author fullname="I. Bryskin" initials="I." surname="Bryskin"/>
	</references>	<author fullname="A. Zinin" initials="A." surname="Zinin"/>
		<author fullname="R. Coltun" initials="R." surname="Coltun"/>
	<references title="Informative References">	<date month="July" year="2008"/>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<abstract>
	FC.2328.xml"?>	<t indent="0">This document defines enhancements to the OSPF proto
		col to support a new class of link state advertisements (LSAs) called Opaque LSA
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	s. Opaque LSAs provide a generalized mechanism to allow for the future extensibi
	FC.3630.xml"?>	lity of OSPF. Opaque LSAs consist of a standard LSA header followed by applicati
		on-specific information. The information field may be used directly by OSPF or b
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	y other applications. Standard OSPF link-state database flooding mechanisms are
	FC.3101.xml"?>	used to distribute Opaque LSAs to all or some limited portion of the OSPF topolo
		gy.</t>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<t indent="0">This document replaces RFC 2370 and adds to it a mec
	FC.3906.xml"?>	hanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque
		LSAs originated outside of the router's OSPF area. [STANDARDS-TRACK]</t>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	</abstract>
	FC.4552.xml"?>	</front>
		<seriesInfo name="RFC" value="5250"/>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<seriesInfo name="DOI" value="10.17487/RFC5250"/>
	FC.5304.xml"?>	</reference>
		<reference anchor="RFC5307" target="https://www.rfc-editor.org/info/rfc5
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	307" quoteTitle="true" derivedAnchor="RFC5307">
	FC.5305.xml"?>	<front>
		<title>IS-IS Extensions in Support of Generalized Multi-Protocol Lab
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	el Switching (GMPLS)</title>
	FC.5310.xml"?>	<author fullname="K. Kompella" initials="K." role="editor" surname="
		Kompella"/>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<author fullname="Y. Rekhter" initials="Y." role="editor" surname="R
	FC.5340.xml"?>	ekhter"/>
		<date month="October" year="2008"/>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<abstract>
	FC.6571.xml"?>	<t indent="0">This document specifies encoding of extensions to th
		e IS-IS routing protocol in support of Generalized Multi-Protocol Label Switchin
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	g (GMPLS). [STANDARDS-TRACK]</t>
	FC.7120.xml"?>	</abstract>
		</front>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<seriesInfo name="RFC" value="5307"/>
	FC.7471.xml"?>	<seriesInfo name="DOI" value="10.17487/RFC5307"/>
		</reference>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<reference anchor="RFC7308" target="https://www.rfc-editor.org/info/rfc7
	FC.7474.xml"?>	308" quoteTitle="true" derivedAnchor="RFC7308">
		<front>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<title>Extended Administrative Groups in MPLS Traffic Engineering (M
	FC.8570.xml"?>	PLS-TE)</title>
		<author fullname="E. Osborne" initials="E." surname="Osborne"/>
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<date month="July" year="2014"/>
	FC.8126.xml"?>	<abstract>
		<t indent="0">MPLS Traffic Engineering (MPLS-TE) advertises 32 adm
	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	inistrative groups (commonly referred to as "colors" or "link colors") using the
	FC.8986.xml"?>	Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RF
		C 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 adminis
		trative 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="RFC7684" target="https://www.rfc-editor.org/info/rfc7
		684" quoteTitle="true" derivedAnchor="RFC7684">
		<front>
		<title>OSPFv2 Prefix/Link Attribute Advertisement</title>
		<author fullname="P. Psenak" initials="P." surname="Psenak"/>
		<author fullname="H. Gredler" initials="H." surname="Gredler"/>
		<author fullname="R. Shakir" initials="R." surname="Shakir"/>
		<author fullname="W. Henderickx" initials="W." surname="Henderickx"/
		>
		<author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
		<author fullname="A. Lindem" initials="A." surname="Lindem"/>
		<date month="November" year="2015"/>
		<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="RFC7770" target="https://www.rfc-editor.org/info/rfc7
		770" quoteTitle="true" derivedAnchor="RFC7770">
		<front>
		<title>Extensions to OSPF for Advertising Optional Router Capabiliti
		es</title>
		<author fullname="A. Lindem" initials="A." role="editor" surname="Li
		ndem"/>
		<author fullname="N. Shen" initials="N." surname="Shen"/>
		<author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
		<author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
		<author fullname="S. Shaffer" initials="S." surname="Shaffer"/>
		<date month="February" year="2016"/>
		<abstract>
		<t indent="0">It is useful for routers in an OSPFv2 or OSPFv3 rout
		ing domain to know the capabilities of their neighbors and other routers in the
		routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for adve
		rtising optional router capabilities. The Router Information (RI) Link State Ad
		vertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be im
		plemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented
		with a unique LSA type function code. In both protocols, the RI LSA can be adv
		ertised at any of the defined flooding scopes (link, area, or autonomous system
		(AS)). This document obsoletes RFC 4970 by providing a revised specification th
		at includes support for advertisement of multiple instances of the RI LSA and a
		TLV for functional capabilities.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7770"/>
		<seriesInfo name="DOI" value="10.17487/RFC7770"/>
		</reference>
		<reference anchor="RFC7981" target="https://www.rfc-editor.org/info/rfc7
		981" quoteTitle="true" derivedAnchor="RFC7981">
		<front>
		<title>IS-IS Extensions for Advertising Router Information</title>
		<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
		<author fullname="S. Previdi" initials="S." surname="Previdi"/>
		<author fullname="M. Chen" initials="M." surname="Chen"/>
		<date month="October" year="2016"/>
		<abstract>
		<t indent="0">This document defines a new optional Intermediate Sy
		stem to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub
		-TLVs, which allows a router to announce its capabilities within an IS-IS level
		or the entire routing domain. This document obsoletes RFC 4971.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7981"/>
		<seriesInfo name="DOI" value="10.17487/RFC7981"/>
		</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 fullname="B. Leiba" initials="B." surname="Leiba"/>
		<date month="May" year="2017"/>
		<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 clar
		ifying that only UPPERCASE usage of the key words have the defined special meani
		ngs.</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 fullname="A. Lindem" initials="A." surname="Lindem"/>
		<author fullname="A. Roy" initials="A." surname="Roy"/>
		<author fullname="D. Goethals" initials="D." surname="Goethals"/>
		<author fullname="V. Reddy Vallem" initials="V." surname="Reddy Vall
		em"/>
		<author fullname="F. Baker" initials="F." surname="Baker"/>
		<date month="April" year="2018"/>
		<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 a
		nd advertised IPv6 prefixes must be advertised in separate LSAs and correlated t
		o the fixed-format LSAs. This document extends the LSA format by encoding the ex
		isting OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing adv
		ertisement of additional information with additional TLVs. Backward-compatibilit
		y 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="RFC8660" target="https://www.rfc-editor.org/info/rfc8
		660" quoteTitle="true" derivedAnchor="RFC8660">
		<front>
		<title>Segment Routing with the MPLS Data Plane</title>
		<author fullname="A. Bashandy" initials="A." role="editor" surname="
		Bashandy"/>
		<author fullname="C. Filsfils" initials="C." role="editor" surname="
		Filsfils"/>
		<author fullname="S. Previdi" initials="S." surname="Previdi"/>
		<author fullname="B. Decraene" initials="B." surname="Decraene"/>
		<author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
		<author fullname="R. Shakir" initials="R." surname="Shakir"/>
		<date month="December" year="2019"/>
		<abstract>
		<t indent="0">Segment Routing (SR) leverages the source-routing pa
		radigm. A node steers a packet through a controlled set of instructions, called
		segments, by prepending the packet with an SR header. In the MPLS data plane,
		the SR header is instantiated through a label stack. This document specifies th
		e forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPL
		S).</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8660"/>
		<seriesInfo name="DOI" value="10.17487/RFC8660"/>
		</reference>
		<reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8
		665" quoteTitle="true" derivedAnchor="RFC8665">
		<front>
		<title>OSPF Extensions for Segment Routing</title>
		<author fullname="P. Psenak" initials="P." role="editor" surname="Ps
		enak"/>
		<author fullname="S. Previdi" initials="S." role="editor" surname="P
		revidi"/>
		<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
		<author fullname="H. Gredler" initials="H." surname="Gredler"/>
		<author fullname="R. Shakir" initials="R." surname="Shakir"/>
		<author fullname="W. Henderickx" initials="W." surname="Henderickx"/
		>
		<author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
		<date month="December" year="2019"/>
		<abstract>
		<t indent="0">Segment Routing (SR) allows a flexible definition of
		end-to-end paths within IGP topologies by encoding paths as sequences of topolo
		gical subpaths called "segments". These segments are advertised by the link-stat
		e routing protocols (IS-IS and OSPF).</t>
		<t indent="0">This document describes the OSPFv2 extensions requir
		ed for Segment Routing.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8665"/>
		<seriesInfo name="DOI" value="10.17487/RFC8665"/>
		</reference>
		<reference anchor="RFC8666" target="https://www.rfc-editor.org/info/rfc8
		666" quoteTitle="true" derivedAnchor="RFC8666">
		<front>
		<title>OSPFv3 Extensions for Segment Routing</title>
		<author fullname="P. Psenak" initials="P." role="editor" surname="Ps
		enak"/>
		<author fullname="S. Previdi" initials="S." role="editor" surname="P
		revidi"/>
		<date month="December" year="2019"/>
		<abstract>
		<t indent="0">Segment Routing (SR) allows a flexible definition of
		end-to-end paths within IGP topologies by encoding paths as sequences of topolo
		gical subpaths called "segments". These segments are advertised by the link-stat
		e routing protocols (IS-IS and OSPF).</t>
		<t indent="0">This document describes the OSPFv3 extensions requir
		ed for Segment Routing with the MPLS data plane.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8666"/>
		<seriesInfo name="DOI" value="10.17487/RFC8666"/>
		</reference>
		<reference anchor="RFC8667" target="https://www.rfc-editor.org/info/rfc8
		667" quoteTitle="true" derivedAnchor="RFC8667">
		<front>
		<title>IS-IS Extensions for Segment Routing</title>
		<author fullname="S. Previdi" initials="S." role="editor" surname="P
		revidi"/>
		<author fullname="L. Ginsberg" initials="L." role="editor" surname="
		Ginsberg"/>
		<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
		<author fullname="A. Bashandy" initials="A." surname="Bashandy"/>
		<author fullname="H. Gredler" initials="H." surname="Gredler"/>
		<author fullname="B. Decraene" initials="B." surname="Decraene"/>
		<date month="December" year="2019"/>
		<abstract>
		<t indent="0">Segment Routing (SR) allows for a flexible definitio
		n of end-to-end paths within IGP topologies by encoding paths as sequences of to
		pological sub-paths, called "segments". These segments are advertised by the lin
		k-state routing protocols (IS-IS and OSPF).</t>
		<t indent="0">This document describes the IS-IS extensions that ne
		ed to be introduced for Segment Routing operating on an MPLS data plane.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8667"/>
		<seriesInfo name="DOI" value="10.17487/RFC8667"/>
		</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 fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
		<author fullname="P. Psenak" initials="P." surname="Psenak"/>
		<author fullname="S. Previdi" initials="S." surname="Previdi"/>
		<author fullname="W. Henderickx" initials="W." surname="Henderickx"/
		>
		<author fullname="J. Drake" initials="J." surname="Drake"/>
		<date month="October" year="2020"/>
		<abstract>
		<t indent="0">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 R
		outing 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 ap
		plication-specific values for a given attribute, nor do they support indication
		of which applications are using the advertised value for a given link. This doc
		ument introduces new link attribute advertisements that address both of these sh
		ortcomings.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8919"/>
		<seriesInfo name="DOI" value="10.17487/RFC8919"/>
		</reference>
		<reference anchor="RFC8920" target="https://www.rfc-editor.org/info/rfc8
		920" quoteTitle="true" derivedAnchor="RFC8920">
		<front>
		<title>OSPF Application-Specific Link Attributes</title>
		<author fullname="P. Psenak" initials="P." role="editor" surname="Ps
		enak"/>
		<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
		<author fullname="W. Henderickx" initials="W." surname="Henderickx"/
		>
		<author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
		<author fullname="J. Drake" initials="J." surname="Drake"/>
		<date month="October" year="2020"/>
		<abstract>
		<t indent="0">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 R
		outing 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 ap
		plication-specific values for a given attribute, nor do they support indication
		of which applications are using the advertised value for a given link. This doc
		ument introduces new link attribute advertisements in OSPFv2 and OSPFv3 that add
		ress both of these shortcomings.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8920"/>
		<seriesInfo name="DOI" value="10.17487/RFC8920"/>
		</reference>
		<reference anchor="RFC9352" target="https://www.rfc-editor.org/info/rfc9
		352" quoteTitle="true" derivedAnchor="RFC9352">
		<front>
		<title>IS-IS Extensions to Support Segment Routing over the IPv6 Dat
		a Plane</title>
		<author initials="P" surname="Psenak" fullname="Peter Psenak" role="
		editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
		>
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="B" surname="Decraene" fullname="Bruno Decraene">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="Z" surname="Hu" fullname="Zhibo Hu">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2023" month="February"/>
		</front>
		<seriesInfo name="RFC" value="9352"/>
		<seriesInfo name="DOI" value="10.17487/RFC9352"/>
		</reference>
		</references>
		<references pn="section-19.2">
		<name slugifiedName="name-informative-references">Informative References
		</name>
		<reference anchor="RFC2328" target="https://www.rfc-editor.org/info/rfc2
		328" quoteTitle="true" derivedAnchor="RFC2328">
		<front>
		<title>OSPF Version 2</title>
		<author fullname="J. Moy" initials="J." surname="Moy"/>
		<date month="April" year="1998"/>
		<abstract>
		<t indent="0">This memo documents version 2 of the OSPF protocol.
		OSPF is a link- state routing protocol. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="STD" value="54"/>
		<seriesInfo name="RFC" value="2328"/>
		<seriesInfo name="DOI" value="10.17487/RFC2328"/>
		</reference>
		<reference anchor="RFC3101" target="https://www.rfc-editor.org/info/rfc3
		101" quoteTitle="true" derivedAnchor="RFC3101">
		<front>
		<title>The OSPF Not-So-Stubby Area (NSSA) Option</title>
		<author fullname="P. Murphy" initials="P." surname="Murphy"/>
		<date month="January" year="2003"/>
		<abstract>
		<t indent="0">This memo documents an optional type of Open Shortes
		t Path First (OSPF) area that is somewhat humorously referred to as a "not-so-st
		ubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configur
		ation option but have the additional capability of importing AS external routes
		in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587.
		The functional differences between this memo and RFC 1587 are explained in Appe
		ndix F. All differences, while expanding capability, are backward-compatible in
		nature. Implementations of this memo and of RFC 1587 will interoperate. [STAND
		ARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="3101"/>
		<seriesInfo name="DOI" value="10.17487/RFC3101"/>
		</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 fullname="D. Katz" initials="D." surname="Katz"/>
		<author fullname="K. Kompella" initials="K." surname="Kompella"/>
		<author fullname="D. Yeung" initials="D." surname="Yeung"/>
		<date month="September" year="2003"/>
		<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="RFC3906" target="https://www.rfc-editor.org/info/rfc3
		906" quoteTitle="true" derivedAnchor="RFC3906">
		<front>
		<title>Calculating Interior Gateway Protocol (IGP) Routes Over Traff
		ic Engineering Tunnels</title>
		<author fullname="N. Shen" initials="N." surname="Shen"/>
		<author fullname="H. Smit" initials="H." surname="Smit"/>
		<date month="October" year="2004"/>
		<abstract>
		<t indent="0">This document describes how conventional hop-by-hop
		link-state routing protocols interact with new Traffic Engineering capabilities
		to create Interior Gateway Protocol (IGP) shortcuts. In particular, this docume
		nt describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted s
		o that link-state IGPs will calculate IP routes to forward traffic over tunnels
		that are set up by Traffic Engineering. This memo provides information for the
		Internet community.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="3906"/>
		<seriesInfo name="DOI" value="10.17487/RFC3906"/>
		</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 fullname="M. Gupta" initials="M." surname="Gupta"/>
		<author fullname="N. Melam" initials="N." surname="Melam"/>
		<date month="June" year="2006"/>
		<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="RFC5304" target="https://www.rfc-editor.org/info/rfc5
		304" quoteTitle="true" derivedAnchor="RFC5304">
		<front>
		<title>IS-IS Cryptographic Authentication</title>
		<author fullname="T. Li" initials="T." surname="Li"/>
		<author fullname="R. Atkinson" initials="R." surname="Atkinson"/>
		<date month="October" year="2008"/>
		<abstract>
		<t indent="0">This document describes the authentication of Interm
		ediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using th
		e Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as
		found in RFC 2104. IS-IS is specified in International Standards Organization (
		ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) descri
		bed in RFC 1195. The base specification includes an authentication mechanism tha
		t allows for multiple authentication algorithms. The base specification only spe
		cifies the algorithm for cleartext passwords. This document replaces RFC 3567.</
		t>
		<t indent="0">This document proposes an extension to that specific
		ation that allows the use of the HMAC-MD5 authentication algorithm to be used in
		conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="5304"/>
		<seriesInfo name="DOI" value="10.17487/RFC5304"/>
		</reference>
		<reference anchor="RFC5305" target="https://www.rfc-editor.org/info/rfc5
		305" quoteTitle="true" derivedAnchor="RFC5305">
		<front>
		<title>IS-IS Extensions for Traffic Engineering</title>
		<author fullname="T. Li" initials="T." surname="Li"/>
		<author fullname="H. Smit" initials="H." surname="Smit"/>
		<date month="October" year="2008"/>
		<abstract>
		<t indent="0">This document describes extensions to the Intermedia
		te System to Intermediate System (IS-IS) protocol to support Traffic Engineering
		(TE). This document extends the IS-IS protocol by specifying new information t
		hat an Intermediate System (router) can place in Link State Protocol Data Units
		(LSP). This information describes additional details regarding the state of the
		network that are useful for traffic engineering computations. [STANDARDS-TRACK]
		</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="5305"/>
		<seriesInfo name="DOI" value="10.17487/RFC5305"/>
		</reference>
		<reference anchor="RFC5310" target="https://www.rfc-editor.org/info/rfc5
		310" quoteTitle="true" derivedAnchor="RFC5310">
		<front>
		<title>IS-IS Generic Cryptographic Authentication</title>
		<author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
		<author fullname="V. Manral" initials="V." surname="Manral"/>
		<author fullname="T. Li" initials="T." surname="Li"/>
		<author fullname="R. Atkinson" initials="R." surname="Atkinson"/>
		<author fullname="R. White" initials="R." surname="White"/>
		<author fullname="M. Fanto" initials="M." surname="Fanto"/>
		<date month="February" year="2009"/>
		<abstract>
		<t indent="0">This document proposes an extension to Intermediate
		System to Intermediate System (IS-IS) to allow the use of any cryptographic auth
		entication algorithm in addition to the already-documented authentication scheme
		s, described in the base specification and RFC 5304. IS-IS is specified in Inter
		national Standards Organization (ISO) 10589, with extensions to support Internet
		Protocol version 4 (IPv4) described in RFC 1195.</t>
		<t indent="0">Although this document has been written specifically
		for using the Hashed Message Authentication Code (HMAC) construct along with th
		e Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method
		described in this document is generic and can be used to extend IS-IS to suppor
		t any cryptographic hash function in the future. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="5310"/>
		<seriesInfo name="DOI" value="10.17487/RFC5310"/>
		</reference>
		<reference anchor="RFC5340" target="https://www.rfc-editor.org/info/rfc5
		340" quoteTitle="true" derivedAnchor="RFC5340">
		<front>
		<title>OSPF for IPv6</title>
		<author fullname="R. Coltun" initials="R." surname="Coltun"/>
		<author fullname="D. Ferguson" initials="D." surname="Ferguson"/>
		<author fullname="J. Moy" initials="J." surname="Moy"/>
		<author fullname="A. Lindem" initials="A." surname="Lindem"/>
		<date month="July" year="2008"/>
		<abstract>
		<t indent="0">This document describes the modifications to OSPF to
		support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms o
		f OSPF (flooding, Designated Router (DR) election, area support, Short Path Firs
		t (SPF) calculations, etc.) remain unchanged. However, some changes have been ne
		cessary, either due to changes in protocol semantics between IPv4 and IPv6, or s
		imply to handle the increased address size of IPv6. These modifications will nec
		essitate 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 hav
		e 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 runs
		on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSA
		s has been generalized. Authentication has been removed from the OSPF protocol a
		nd instead relies on IPv6's Authentication Header and Encapsulating Security Pay
		load (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 pack
		et- size limitations present in OSPF for IPv4 have been relaxed. In addition, op
		tion 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="RFC6571" target="https://www.rfc-editor.org/info/rfc6
		571" quoteTitle="true" derivedAnchor="RFC6571">
		<front>
		<title>Loop-Free Alternate (LFA) Applicability in Service Provider (
		SP) Networks</title>
		<author fullname="C. Filsfils" initials="C." role="editor" surname="
		Filsfils"/>
		<author fullname="P. Francois" initials="P." role="editor" surname="
		Francois"/>
		<author fullname="M. Shand" initials="M." surname="Shand"/>
		<author fullname="B. Decraene" initials="B." surname="Decraene"/>
		<author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
		<author fullname="N. Leymann" initials="N." surname="Leymann"/>
		<author fullname="M. Horneffer" initials="M." surname="Horneffer"/>
		<date month="June" year="2012"/>
		<abstract>
		<t indent="0">In this document, we analyze the applicability of th
		e Loop-Free Alternate (LFA) method of providing IP fast reroute in both the core
		and access parts of Service Provider networks. We consider both the link and n
		ode failure cases, and provide guidance on the applicability of LFAs to differen
		t network topologies, with special emphasis on the access parts of the network.
		This document is not an Internet Standards Track specification; it is published
		for informational purposes.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6571"/>
		<seriesInfo name="DOI" value="10.17487/RFC6571"/>
		</reference>
		<reference anchor="RFC7120" target="https://www.rfc-editor.org/info/rfc7
		120" quoteTitle="true" derivedAnchor="RFC7120">
		<front>
		<title>Early IANA Allocation of Standards Track Code Points</title>
		<author fullname="M. Cotton" initials="M." surname="Cotton"/>
		<date month="January" year="2014"/>
		<abstract>
		<t indent="0">This memo describes the process for early allocation
		of code points by IANA from registries for which "Specification Required", "RFC
		Required", "IETF Review", or "Standards Action" policies apply. This process c
		an be used to alleviate the problem where code point allocation is needed to fac
		ilitate desired or required implementation and deployment experience prior to pu
		blication of an RFC, which would normally trigger code point allocation. The pr
		ocedures in this document are intended to apply only to IETF Stream documents.</
		t>
		</abstract>
		</front>
		<seriesInfo name="BCP" value="100"/>
		<seriesInfo name="RFC" value="7120"/>
		<seriesInfo name="DOI" value="10.17487/RFC7120"/>
		</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 fullname="S. Giacalone" initials="S." surname="Giacalone"/>
		<author fullname="D. Ward" initials="D." surname="Ward"/>
		<author fullname="J. Drake" initials="J." surname="Drake"/>
		<author fullname="A. Atlas" initials="A." surname="Atlas"/>
		<author fullname="S. Previdi" initials="S." surname="Previdi"/>
		<date month="March" year="2015"/>
		<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
		Engineering Extensions to OSPF Version 3" to enable network performance informat
		ion to be distributed in a scalable fashion. The information distributed using O
		SPF 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 measu
		ring network performance information or using that information, once distributed
		, 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="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 fullname="M. Bhatia" initials="M." surname="Bhatia"/>
		<author fullname="S. Hartman" initials="S." surname="Hartman"/>
		<author fullname="D. Zhang" initials="D." surname="Zhang"/>
		<author fullname="A. Lindem" initials="A." role="editor" surname="Li
		ndem"/>
		<date month="April" year="2015"/>
		<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 existin
		g cryptographic authentication mechanism does not cover the IP header. This omis
		sion 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 the
		IP header.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7474"/>
		<seriesInfo name="DOI" value="10.17487/RFC7474"/>
		</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 fullname="M. Cotton" initials="M." surname="Cotton"/>
		<author fullname="B. Leiba" initials="B." surname="Leiba"/>
		<author fullname="T. Narten" initials="T." surname="Narten"/>
		<date month="June" year="2017"/>
		<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 va
		lues in these fields do not have conflicting uses and to promote interoperabilit
		y, their allocations are often coordinated by a central record keeper. For IETF
		protocols, that role is filled by the Internet Assigned Numbers Authority (IANA)
		.</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. Th
		is document defines a framework for the documentation of these guidelines by spe
		cification authors, in order to assure that the provided guidance for the IANA C
		onsiderations is clear and addresses the various issues that are likely in the o
		peration 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="RFC8570" target="https://www.rfc-editor.org/info/rfc8
		570" quoteTitle="true" derivedAnchor="RFC8570">
		<front>
		<title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
		<author fullname="L. Ginsberg" initials="L." role="editor" surname="
		Ginsberg"/>
		<author fullname="S. Previdi" initials="S." role="editor" surname="P
		revidi"/>
		<author fullname="S. Giacalone" initials="S." surname="Giacalone"/>
		<author fullname="D. Ward" initials="D." surname="Ward"/>
		<author fullname="J. Drake" initials="J." surname="Drake"/>
		<author fullname="Q. Wu" initials="Q." surname="Wu"/>
		<date month="March" year="2019"/>
		<abstract>
		<t indent="0">In certain networks, such as, but not limited to, fi
		nancial information networks (e.g., stock market data providers), network-perfor
		mance criteria (e.g., latency) are becoming as critical to data-path selection a
		s other metrics.</t>
		<t indent="0">This document describes extensions to IS-IS Traffic
		Engineering Extensions (RFC 5305). These extensions provide a way to distribute
		and collect network-performance information in a scalable fashion. The informati
		on distributed using IS-IS TE Metric Extensions can then be used to make path-se
		lection decisions based on network performance.</t>
		<t indent="0">Note that this document only covers the mechanisms w
		ith which network-performance information is distributed. The mechanisms for mea
		suring network performance or acting on that information, once distributed, are
		outside the scope of this document.</t>
		<t indent="0">This document obsoletes RFC 7810.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8570"/>
		<seriesInfo name="DOI" value="10.17487/RFC8570"/>
		</reference>
		<reference anchor="RFC8986" target="https://www.rfc-editor.org/info/rfc8
		986" quoteTitle="true" derivedAnchor="RFC8986">
		<front>
		<title>Segment Routing over IPv6 (SRv6) Network Programming</title>
		<author fullname="C. Filsfils" initials="C." role="editor" surname="
		Filsfils"/>
		<author fullname="P. Camarillo" initials="P." role="editor" surname=
		"Camarillo"/>
		<author fullname="J. Leddy" initials="J." surname="Leddy"/>
		<author fullname="D. Voyer" initials="D." surname="Voyer"/>
		<author fullname="S. Matsushima" initials="S." surname="Matsushima"/
		>
		<author fullname="Z. Li" initials="Z." surname="Li"/>
		<date month="February" year="2021"/>
		<abstract>
		<t indent="0">The Segment Routing over IPv6 (SRv6) Network Program
		ming framework enables a network operator or an application to specify a packet
		processing program by encoding a sequence of instructions in the IPv6 packet hea
		der.</t>
		<t indent="0">Each instruction is implemented on one or several no
		des in the network and identified by an SRv6 Segment Identifier in the packet.</
		t>
		<t indent="0">This document defines the SRv6 Network Programming c
		oncept and specifies the base set of SRv6 behaviors that enables the creation of
		interoperable overlays with underlay optimization.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8986"/>
		<seriesInfo name="DOI" value="10.17487/RFC8986"/>
		</reference>
		<reference anchor="I-D.gulkohegde-routing-planes-using-sr" target="https
		://datatracker.ietf.org/doc/html/draft-gulkohegde-routing-planes-using-sr-00" qu
		oteTitle="true" derivedAnchor="ROUTING-PLANES-USING-SR">
		<front>
		<title>Separating Routing Planes using Segment Routing</title>
		<author initials="S." surname="Hegde" fullname="Shraddha Hegde">
		<organization showOnFrontPage="true">Juniper Networks</organizatio
		n>
		</author>
		<author initials="A." surname="Gulko" fullname="Arkadiy Gulko">
		<organization showOnFrontPage="true">Thomson Reuters</organization
		>
		</author>
		<date month="March" day="13" year="2017"/>
		<abstract>
		<t indent="0"> Many network deployments arrange the network topo
		logies in two or
		more planes. The traffic generally uses one of the planes and fails
		over to the other plane when there are link or node failure. Certain
		applications require the traffic to be strictly restricted to a
		particular plane and should not failover to the other plane. This
		document proposes a solution for the strict planar routing using
		Segment Routing.


	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.	</t>
	I-D.gulkohegde-routing-planes-using-sr.xml"?>	</abstract>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-gulkohegde-routing-plan
		es-using-sr-00"/>
		<refcontent>Work in Progress</refcontent>
		</reference>
		<reference anchor="I-D.ietf-rtgwg-segment-routing-ti-lfa" target="https:
		//datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-09" quot
		eTitle="true" derivedAnchor="RTGWG-SEGMENT-ROUTING-TI-LFA">
		<front>
		<title>Topology Independent Fast Reroute using Segment Routing</titl
		e>
		<author initials="S." surname="Litkowski" fullname="Stephane Litkows
		ki">
		<organization showOnFrontPage="true">Cisco Systems</organization>
		</author>
		<author initials="A." surname="Bashandy" fullname="Ahmed Bashandy">
		<organization showOnFrontPage="true">Individual</organization>
		</author>
		<author initials="C." surname="Filsfils" fullname="Clarence Filsfils
		">
		<organization showOnFrontPage="true">Cisco Systems</organization>
		</author>
		<author initials="P." surname="Francois" fullname="Pierre Francois">
		<organization showOnFrontPage="true">INSA Lyon</organization>
		</author>
		<author initials="B." surname="Decraene" fullname="Bruno Decraene">
		<organization showOnFrontPage="true">Orange</organization>
		</author>
		<author initials="D." surname="Voyer" fullname="Daniel Voyer">
		<organization showOnFrontPage="true">Bell Canada</organization>
		</author>
		<date month="December" day="23" year="2022"/>
		<abstract>
		<t indent="0"> This document presents Topology Independent Loop-
		free Alternate Fast
		Re-route (TI-LFA), aimed at providing protection of node and
		adjacency segments within the Segment Routing (SR) framework. This
		Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being
		LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding
		(DLFA). It extends these concepts to provide guaranteed coverage in
		any two connected network using a link-state IGP. A key aspect of
		TI-LFA is the FRR path selection approach establishing protection
		over the expected post-convergence paths from the point of local
		repair, reducing the operational need to control the tie-breaks among
		various FRR options.


	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.	</t>
	I-D.ietf-rtgwg-segment-routing-ti-lfa.xml"?>	</abstract>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-segment-rout
		ing-ti-lfa-09"/>
		<refcontent>Work in Progress</refcontent>
		</reference>
		</references>
	</references>	</references>

		<section anchor="ACK" numbered="false" toc="include" removeInRFC="false" pn=
		"section-appendix.a">
		<name slugifiedName="name-acknowledgements">Acknowledgements</name>
		<t indent="0" pn="section-appendix.a-1">This document, among other things,
		addresses the problem that
		<xref target="I-D.gulkohegde-routing-planes-using-sr" format="default" sec
		tionFormat="of" derivedContent="ROUTING-PLANES-USING-SR"/> was trying
		to solve. All authors of that document agreed to join this document.</t>
		<t indent="0" pn="section-appendix.a-2">Thanks to <contact fullname="Eric
		Rosen"/>, <contact fullname="Tony Przygienda"/>, <contact fullname="William Brit
		to A. J."/>, <contact fullname="Gunter Van de Velde"/>, <contact fullname=
		"Dirk Goethals"/>, <contact fullname="Manju Sivaji"/>, and <contact fullname="Ba
		alajee S."/> for their detailed
		review and excellent comments.</t>
		<t indent="0" pn="section-appendix.a-3">Thanks to <contact fullname="Cengi
		z Halit"/> for his review and feedback during
		the initial phase of the solution definition.</t>
		<t indent="0" pn="section-appendix.a-4">Thanks to <contact fullname="Kenji
		Kumaki"/> for his comments.</t>
		<t indent="0" pn="section-appendix.a-5">Thanks to <contact fullname="Acee
		Lindem"/> for editorial comments.</t>
		</section>
		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
		="include" pn="section-appendix.b">
		<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
		<author fullname="Peter Psenak" initials="P." role="editor" surname="Psena
		k">
		<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
		<address>
		<postal>
		<extaddr>Apollo Business Center</extaddr>
		<street>Mlynske nivy 43</street>
		<city>Bratislava</city>
		<code>82109</code>
		<country>Slovakia</country>
		<code/>
		</postal>
		<email>ppsenak@cisco.com</email>
		</address>
		</author>
		<author fullname="Shraddha Hegde" initials="S" surname="Hegde">
		<organization showOnFrontPage="true">Juniper Networks, Inc.</organizatio
		n>
		<address>
		<postal>
		<extaddr>Embassy Business Park</extaddr>
		<street/>
		<city>Bangalore</city>
		<region>KA</region>
		<code>560093</code>
		<country>India</country>
		<code/>
		</postal>
		<email>shraddha@juniper.net</email>
		</address>
		</author>
		<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
		<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
		<address>
		<postal>
		<street/>
		<city>Brussels</city>
		<region/>
		<code/>
		<country>Belgium</country>
		</postal>
		<email>cfilsfil@cisco.com</email>
		</address>
		</author>
		<author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar">
		<organization showOnFrontPage="true">Cisco Systems, Inc</organization>
		<address>
		<postal>
		<street/>
		<city/>
		<code/>
		<country>India</country>
		</postal>
		<email>ketant.ietf@gmail.com</email>
		</address>
		</author>
		<author fullname="Arkadiy Gulko" initials="A." surname="Gulko">
		<organization showOnFrontPage="true">Edward Jones</organization>
		<address>
		<postal>
		<street/>
		<city/>
		<region/>
		<code/>
		<country/>
		</postal>
		<email>arkadiy.gulko@edwardjones.com</email>
		</address>
		</author>
		</section>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 285 change blocks.
	1935 lines changed or deleted	3891 lines changed or added
This html diff was produced by rfcdiff 1.48.