Diff: rfc9352xml2.original.xml

	rfc9352xml2.original.xml	rfc9352.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
	<?rfc toc="yes"?>	nsus="true" docName="draft-ietf-lsr-isis-srv6-extensions-18" indexInclude="true"
	<?rfc tocompact="yes"?>	ipr="trust200902" number="9352" prepTime="2023-02-21T18:03:30" scripts="Common,
	<?rfc tocdepth="3"?>	Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocIncl
	<?rfc tocindent="yes"?>	ude="true" updates="7370" xml:lang="en">
	<?rfc symrefs="yes"?>	<link href="https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensio
	<?rfc sortrefs="yes"?>	ns-18" rel="prev"/>
	<?rfc comments="yes"?>	<link href="https://dx.doi.org/10.17487/rfc9352" rel="alternate"/>
	<?rfc inline="yes"?>	<link href="urn:issn:2070-1721" rel="alternate"/>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc category="std" docName="draft-ietf-lsr-isis-srv6-extensions-18"
	ipr="trust200902" updates="7370">
	<front>	<front>

	<title abbrev="ISIS Srv6 Extensions">IS-IS Extensions to	<title abbrev="IS-IS SRv6 Extensions">IS-IS Extensions to Support Segment Ro
	Support Segment Routing over IPv6 Dataplane</title>	uting over the IPv6 Data Plane</title>
		<seriesInfo name="RFC" value="9352" stream="IETF"/>
	<author fullname="Peter Psenak" initials="P" role="editor"	<author fullname="Peter Psenak" initials="P" role="editor" surname="Psenak">
	surname="Psenak">	<organization showOnFrontPage="true">Cisco Systems</organization>
	<organization>Cisco Systems</organization>

	<address>	<address>
	<postal>	<postal>
	<street>Pribinova Street 10</street>	<street>Pribinova Street 10</street>

		<city>Bratislava</city>
	<city>Bratislava 81109</city>	<code>81109</code>

	<region/>	<region/>


	<code/>

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


	<phone/>	<phone/>


	<facsimile/>

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


	<uri/>	<uri/>
	</address>	</address>
	</author>	</author>


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

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

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


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


	<code/>	<code/>


	<region/>	<region/>


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


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


	<author fullname="Ahmed Bashandy" initials="A" surname="Bashandy">	<author fullname="Ahmed Bashandy" initials="A" surname="Bashandy">

	<organization>Individual</organization>	<organization showOnFrontPage="true">Cisco Systems</organization>

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

		<city>Milpitas</city>
		<country>United States of America</country>
	</postal>	</postal>

		<email>bashandy@cisco.com</email>
	<email>abashandy.ietf@gmail.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Bruno Decraene" initials="B" surname="Decraene">	<author fullname="Bruno Decraene" initials="B" surname="Decraene">

	<organization>Orange</organization>	<organization showOnFrontPage="true">Orange</organization>

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

		<city>Chatillon</city>
	<city>Issy-les-Moulineaux</city>

	<code/>	<code/>


	<region/>	<region/>


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


	<email>bruno.decraene@orange.com</email>	<email>bruno.decraene@orange.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Zhibo Hu" initials="Z" surname="Hu">	<author fullname="Zhibo Hu" initials="Z" surname="Hu">

	<organization>Huawei Technologies</organization>	<organization showOnFrontPage="true">Huawei Technologies</organization>

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


	<city/>	<city/>


	<code/>	<code/>


	<region/>	<region/>


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


	<email>huzhibo@huawei.com</email>	<email>huzhibo@huawei.com</email>
	</address>	</address>
	</author>	</author>

		<date month="02" year="2023"/>
	<date year=""/>

	<area>Routing Area</area>	<area>Routing Area</area>


	<workgroup>Networking Working Group</workgroup>	<workgroup>Networking Working Group</workgroup>

		<abstract pn="section-abstract">
	<keyword/>	<t indent="0" pn="section-abstract-1">The Segment Routing (SR) architectur
		e allows a flexible definition of the end-to-end
	<abstract>
	<t>The Segment Routing (SR) architecture allows flexible definition of the
	end-to-end
	path by encoding it as a sequence of topological elements called	path by encoding it as a sequence of topological elements called
	"segments". It can be implemented over the MPLS or the IPv6 data plane.	"segments". It can be implemented over the MPLS or the IPv6 data plane.

	This document describes the IS-IS extensions required to support Segment R outing	This document describes the IS-IS extensions required to support SR
	over the IPv6 data plane.</t>	over the IPv6 data plane.</t>

		<t indent="0" pn="section-abstract-2">This document updates RFC 7370 by mo
	<t>This document updates RFC 7370 by modifying an existing registry.</t>	difying an existing registry.</t>
	</abstract>	</abstract>

		<boilerplate>
	<note title="Requirements Language">	<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	"exclude" pn="section-boilerplate.1">
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
	"OPTIONAL" in this document are to be interpreted as described in BCP 14	>
	[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as	<t indent="0" pn="section-boilerplate.1-1">
	shown here.</t>	This is an Internet Standards Track document.
	</note>	</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/rfc9352" 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>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.1.2">
		<li pn="section-toc.1-1.1.2.1">
		<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
		xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
		1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-re
		quirements-language">Requirements Language</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.2">
		<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
		ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref
		derivedContent="" format="title" sectionFormat="of" target="name-srv6-capabilit
		ies-sub-tlv">SRv6 Capabilities Sub-TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.3">
		<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
		at="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-advertising-supported-algor">Adver
		tising Supported Algorithms</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-advertising-maximum-srv6-si">Adver
		tising Maximum SRv6 SID Depths</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.4.2">
		<li pn="section-toc.1-1.4.2.1">
		<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
		"4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-maximum-segments-left-
		msd-t">Maximum Segments Left MSD Type</xref></t>
		</li>
		<li pn="section-toc.1-1.4.2.2">
		<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
		"4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-maximum-end-pop-msd-ty
		pe">Maximum End Pop MSD Type</xref></t>
		</li>
		<li pn="section-toc.1-1.4.2.3">
		<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
		"4.3" format="counter" sectionFormat="of" target="section-4.3"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-maximum-hencaps-msd-ty
		pe">Maximum H.Encaps MSD Type</xref></t>
		</li>
		<li pn="section-toc.1-1.4.2.4">
		<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent=
		"4.4" format="counter" sectionFormat="of" target="section-4.4"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-maximum-end-d-msd-type
		">Maximum End D MSD Type</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.5">
		<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
		at="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-srv6-sids-and-reachability">SRv6 S
		IDs and Reachability</xref></t>
		</li>
		<li pn="section-toc.1-1.6">
		<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
		at="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-advertising-anycast-propert">Adver
		tising Anycast Property</xref></t>
		</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-advertising-locators-and-en">Adver
		tising Locators and End SIDs</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-srv6-locator-tlv-forma
		t">SRv6 Locator TLV Format</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-srv6-end-sid-sub-tlv">
		SRv6 End SID 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-advertising-srv6-adjacency-">Adver
		tising SRv6 Adjacency SIDs</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.8.2">
		<li pn="section-toc.1-1.8.2.1">
		<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
		"8.1" format="counter" sectionFormat="of" target="section-8.1"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-srv6-endx-sid-sub-tlv"
		>SRv6 End.X SID Sub-TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.8.2.2">
		<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
		"8.2" format="counter" sectionFormat="of" target="section-8.2"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-srv6-lan-endx-sid-sub-
		tlv">SRv6 LAN End.X SID Sub-TLV</xref></t>
		</li>
		</ul>
		</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-srv6-sid-structure-sub-sub-">SRv6
		SID Structure Sub-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-advertising-endpoint-behavi">Adv
		ertising Endpoint Behaviors</xref></t>
		</li>
		<li pn="section-toc.1-1.11">
		<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
		rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
		erations</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-srv6-locator-tlv">S
		Rv6 Locator TLV</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-toc.1-1.11.2.1.2">
		<li pn="section-toc.1-1.11.2.1.2.1">
		<t indent="0" pn="section-toc.1-1.11.2.1.2.1.1"><xref derive
		dContent="11.1.1" format="counter" sectionFormat="of" target="section-11.1.1"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-srv6-en
		d-sid-sub-tlv-2">SRv6 End SID Sub-TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.11.2.1.2.2">
		<t indent="0" pn="section-toc.1-1.11.2.1.2.2.1"><xref derive
		dContent="11.1.2" format="counter" sectionFormat="of" target="section-11.1.2"/>.
		<xref derivedContent="" format="title" sectionFormat="of" target="name-is-is-s
		ub-tlvs-for-tlvs-adve">IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability R
		egistry</xref></t>
		</li>
		</ul>
		</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-srv6-capabilities-s
		ub-tlv-2">SRv6 Capabilities Sub-TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.11.2.3">
		<t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent
		="11.3" format="counter" sectionFormat="of" target="section-11.3"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-is-is-sub-sub-tlvs-
		for-the-">IS-IS Sub-Sub-TLVs for the SRv6 Capabilities Sub-TLV Registry</xref></
		t>
		</li>
		<li pn="section-toc.1-1.11.2.4">
		<t indent="0" pn="section-toc.1-1.11.2.4.1"><xref derivedContent
		="11.4" format="counter" sectionFormat="of" target="section-11.4"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-srv6-endx-sid-and-s
		rv6-lan-">SRv6 End.X SID and SRv6 LAN End.X SID Sub-TLVs</xref></t>
		</li>
		<li pn="section-toc.1-1.11.2.5">
		<t indent="0" pn="section-toc.1-1.11.2.5.1"><xref derivedContent
		="11.5" format="counter" sectionFormat="of" target="section-11.5"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-msd-types">MSD Type
		s</xref></t>
		</li>
		<li pn="section-toc.1-1.11.2.6">
		<t indent="0" pn="section-toc.1-1.11.2.6.1"><xref derivedContent
		="11.6" format="counter" sectionFormat="of" target="section-11.6"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-is-is-sub-sub-tlvs-
		for-srv6-">IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.11.2.7">
		<t indent="0" pn="section-toc.1-1.11.2.7.1"><xref derivedContent
		="11.7" format="counter" sectionFormat="of" target="section-11.7"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-prefix-attribute-fl
		ags-sub-">Prefix Attribute Flags Sub-TLV</xref></t>
		</li>
		<li pn="section-toc.1-1.11.2.8">
		<t indent="0" pn="section-toc.1-1.11.2.8.1"><xref derivedContent
		="11.8" format="counter" sectionFormat="of" target="section-11.8"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-is-is-srv6-capabili
		ties-sub">IS-IS SRv6 Capabilities Sub-TLV Flags Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.11.2.9">
		<t indent="0" pn="section-toc.1-1.11.2.9.1"><xref derivedContent
		="11.9" format="counter" sectionFormat="of" target="section-11.9"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-is-is-srv6-locator-
		tlv-flag">IS-IS SRv6 Locator TLV Flags Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.11.2.10">
		<t indent="0" pn="section-toc.1-1.11.2.10.1"><xref derivedConten
		t="11.10" format="counter" sectionFormat="of" target="section-11.10"/>. <xref de
		rivedContent="" format="title" sectionFormat="of" target="name-is-is-srv6-end-si
		d-sub-tlv-">IS-IS SRv6 End SID Sub-TLV Flags Registry</xref></t>
		</li>
		<li pn="section-toc.1-1.11.2.11">
		<t indent="0" pn="section-toc.1-1.11.2.11.1"><xref derivedConten
		t="11.11" format="counter" sectionFormat="of" target="section-11.11"/>. <xref de
		rivedContent="" format="title" sectionFormat="of" target="name-is-is-srv6-adjace
		ncy-sid-su">IS-IS SRv6 Adjacency SID Sub-TLVs Flags Registry</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-security-considerations">Securit
		y Considerations</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-references">References</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-normative-reference
		s">Normative References</xref></t>
		</li>
		<li pn="section-toc.1-1.13.2.2">
		<t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent
		="13.2" format="counter" sectionFormat="of" target="section-13.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.14">
		<t indent="0" pn="section-toc.1-1.14.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.15">
		<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" form
		at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
		" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
		f></t>
		</li>
		<li pn="section-toc.1-1.16">
		<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
		at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
		" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
		resses</xref></t>
		</li>
		</ul>
		</section>
		</toc>
	</front>	</front>


	<middle>	<middle>

	<section title="Introduction">	<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
	<t>With Segment Routing (SR) <xref target="RFC8402"/>, a node steers a pac	<name slugifiedName="name-introduction">Introduction</name>
	ket	<t indent="0" pn="section-1-1">With Segment Routing (SR) <xref target="RFC
	through an ordered list of instructions, called segments.</t>	8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>, a node ste
		ers a packet
	<t>Segments are identified through Segment Identifiers (SIDs).</t>	through an ordered list of instructions, which are called segments.</t>
		<t indent="0" pn="section-1-2">Segments are identified through Segment Ide
	<t>Segment Routing can be directly instantiated on the IPv6 data plane	ntifiers (SIDs).</t>
	through the use of the Segment Routing Header defined in <xref target="RFC	<t indent="0" pn="section-1-3">SR can be directly instantiated on the IPv6
	8754"/>.	data plane
	SRv6 refers to this SR instantiation on the IPv6 dataplane.</t>	through the use of the Segment Routing Header (SRH) defined in <xref targe
		t="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/>.
	<t>The network programming paradigm <xref	SRv6 refers to this SR instantiation on the IPv6 data plane.</t>
	target="RFC8986"/> is central to	<t indent="0" pn="section-1-4">The network programming paradigm <xref targ
		et="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/> is c
		entral to
	SRv6. It describes how any behavior can be bound to a SID and how any	SRv6. It describes how any behavior can be bound to a SID and how any
	network program can be expressed as a combination of SIDs.</t>	network program can be expressed as a combination of SIDs.</t>

		<t indent="0" pn="section-1-5">This document specifies IS-IS extensions th
	<t>This document specifies IS-IS extensions that allow the IS-IS	at allow the IS-IS
	protocol to encode some of these SIDs and their behaviors.</t>	protocol to encode some of these SIDs and their behaviors.</t>

		<t indent="0" pn="section-1-6">Familiarity with the network programming pa
	<t>Familiarity with the network programming paradigm <xref	radigm <xref target="RFC8986" format="default" sectionFormat="of" derivedContent
	target="RFC8986"/> is necessary to	="RFC8986"/> is necessary to
	understand the extensions specified in this document.</t>	understand the extensions specified in this document.</t>

		<t indent="0" pn="section-1-7">The new SRv6 Locator top-level TLV announce
	<t>The new SRv6 Locator top level TLV announces SRv6 locators - a form of	s SRv6 Locators -- a form of
	summary address for the set of topology/algorithm-specific SIDs	summary address for the set of topology-/algorithm-specific SIDs
	instantiated at the node.</t>	instantiated at the node.</t>

		<t indent="0" pn="section-1-8">The SRv6 Capabilities sub-TLV announces the
	<t>The SRv6 Capabilities sub-TLV announces the ability to support SRv6.</t	ability to support SRv6.</t>
	>	<t indent="0" pn="section-1-9">Several new sub-TLVs are defined to adverti
		se various SRv6 Maximum SID Depths (MSDs).</t>
	<t>Several new sub-TLVs are defined to advertise various SRv6 Maximum SID	<t indent="0" pn="section-1-10">The SRv6 End SID sub-TLV, the SRv6 End.X S
	Depths.</t>	ID sub-TLV, and the SRv6

	<t>The SRv6 End SID sub-TLV, the SRv6 End.X SID sub-TLV, and the SRv6
	LAN End.X SID sub-TLV are used to advertise which SIDs are instantiated	LAN End.X SID sub-TLV are used to advertise which SIDs are instantiated
	at a node and what Endpoint behavior is bound to each instantiated	at a node and what Endpoint behavior is bound to each instantiated
	SID.</t>	SID.</t>

		<t indent="0" pn="section-1-11">This document updates <xref target="RFC737
	<t>This document updates <xref target="RFC7370"/> by modifying an existing	0" format="default" sectionFormat="of" derivedContent="RFC7370"/> by modifying a
	registry	n existing registry
	(<xref target="REVISEDREG"/>).</t>	(<xref target="REVISEDREG" format="default" sectionFormat="of" derivedCont
		ent="Section 11.1.2"/>).</t>
		<section anchor="req-lang" numbered="true" toc="include" removeInRFC="fals
		e" pn="section-1.1">
		<name slugifiedName="name-requirements-language">Requirements Language</
		name>
		<t indent="0" pn="section-1.1-1">
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
		D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
		OT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
		f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
		mat="of" derivedContent="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
		</section>
	</section>	</section>

		<section anchor="SRV6CAP" numbered="true" toc="include" removeInRFC="false"
	<section anchor="SRV6CAP" title="SRv6 Capabilities sub-TLV">	pn="section-2">
	<t>A node indicates that it supports the SR Segment Endpoint Node function	<name slugifiedName="name-srv6-capabilities-sub-tlv">SRv6 Capabilities Sub
	ality	-TLV</name>
	as specified in <xref target="RFC8754"/> by advertising a new SRv6 Capabi	<t indent="0" pn="section-2-1">A node indicates that it supports the SR Se
	lities	gment Endpoint Node functionality
	sub-TLV of the router capabilities TLV [RFC7981].</t>	as specified in <xref target="RFC8754" format="default" sectionFormat="of
		" derivedContent="RFC8754"/> by advertising a new SRv6 Capabilities
	<t>The SRv6 Capabilities sub-TLV may contain optional sub-sub-TLVs. No	sub-TLV of the Router Capability TLV <xref target="RFC7981" format="defau
		lt" sectionFormat="of" derivedContent="RFC7981"/>.</t>
		<t indent="0" pn="section-2-2">The SRv6 Capabilities sub-TLV may contain o
		ptional sub-sub-TLVs. No
	sub-sub-TLVs are currently defined.</t>	sub-sub-TLVs are currently defined.</t>

		<t indent="0" pn="section-2-3">The SRv6 Capabilities sub-TLV has the follo
	<t>The SRv6 Capabilities sub-TLV has the following format:</t>	wing format:</t>
		<artwork name="" type="" align="left" alt="" pn="section-2-4">
	<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 \| Flags \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \|	\| optional sub-sub-TLVs...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	</artwork>
	\| optional sub-sub-TLVs...	<dl newline="false" spacing="normal" indent="3" pn="section-2-5">
		<dt pn="section-2-5.1">Type:</dt>
	Type: 25. Single octet as defined in section 9 of [ISO10589].	<dd pn="section-2-5.2">25. Single octet, as defined in Section 9 of <xre
		f target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO10589
	Length: Single octet as defined in section 9 of [ISO10589]. The length valu	"/>.</dd>
	e is	<dt pn="section-2-5.3">Length:</dt>
	2 + length of sub-sub-TLVs.	<dd pn="section-2-5.4">Single octet, as defined in Section 9 of <xref ta
		rget="ISO10589" format="default" sectionFormat="of" derivedContent="ISO10589"/>.
	Flags: 2 octets The following flags are defined:	The
		length value is 2 + length of sub-sub-TLVs.</dd>
	0 1	<dt pn="section-2-5.5">Flags:</dt>
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5	<dd pn="section-2-5.6">
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<t indent="0" pn="section-2-5.6.1">2 octets. The following flags are d
	\| \|O\| Reserved \|	efined:</t>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<artwork name="" type="" align="left" alt="" pn="section-2-5.6.2">
		0 1
	where:	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	O-flag: If set, the router supports use of the O-bit	\| \|O\| Reserved \|
	in the Segment Routing Header (SRH) as defined in	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	[I-D.ietf-6man-spring-srv6-oam].	</artwork>
		<dl newline="true" spacing="normal" indent="3" pn="section-2-5.6.3">
	The remaining bits, including bit 0, are reserved for future use. They M	<dt pn="section-2-5.6.3.1">where:</dt>
	UST be	<dd pn="section-2-5.6.3.2">
	set to zero on transmission and MUST be ignored on receipt.	<dl newline="false" spacing="normal" indent="3" pn="section-2-5.6.
		3.2.1">
	]]></artwork>	<dt pn="section-2-5.6.3.2.1.1">O-flag:</dt>
	</figure></t>	<dd pn="section-2-5.6.3.2.1.2">
		<t indent="0" pn="section-2-5.6.3.2.1.2.1">If set, the router
		supports use of the O-bit
		in the SRH, as defined in <xref target="RFC9259" format="default" sectionFo
		rmat="of" derivedContent="RFC9259"/>.</t>
		<t indent="0" pn="section-2-5.6.3.2.1.2.2">The remaining bits,
		including bit 0, are reserved for future use. They <bcp14>MUST</bcp14>
		be set to zero on transmission and <bcp14>MUST</bcp14> be ignored on receip
		t.</t>
		</dd>
		</dl>
		</dd>
		</dl>
		</dd>
		</dl>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-3">
	<section title="Advertising Supported Algorithms">	<name slugifiedName="name-advertising-supported-algor">Advertising Support
		ed Algorithms</name>
	<t>An SRv6 capable router indicates supported algorithm(s) by advertising th	<t indent="0" pn="section-3-1">An SRv6-capable router indicates one or mor
	e	e supported algorithms by advertising the
	Segment Routing Algorithm sub-TLV as defined in <xref target="RFC8667"/>.	Segment Routing Algorithm sub-TLV, as defined in <xref target="RFC8667" f
	</t>	ormat="default" sectionFormat="of" derivedContent="RFC8667"/>.</t>

	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-4">
	<section title="Advertising Maximum SRv6 SID Depths">	<name slugifiedName="name-advertising-maximum-srv6-si">Advertising Maximum
	<t><xref target="RFC8491"/> defines the means	SRv6 SID Depths</name>
	to advertise node/link specific values for Maximum SID Depths (MSD) of	<t indent="0" pn="section-4-1"><xref target="RFC8491" format="default" sec
	various types. Node MSDs are advertised in a sub-TLV of the Router	tionFormat="of" derivedContent="RFC8491"/> defines the means
	Capabilities TLV <xref target="RFC7981"/>. Link MSDs are advertised in a	to advertise node-/link-specific values for MSDs of
		various types.
		Node MSDs are advertised in a sub-TLV of the Router
		Capability TLV <xref target="RFC7981" format="default" sectionFormat="of"
		derivedContent="RFC7981"/>. Link MSDs are advertised in a
	sub-TLV of TLVs 22, 23, 25, 141, 222, and 223.</t>	sub-TLV of TLVs 22, 23, 25, 141, 222, and 223.</t>

		<t indent="0" pn="section-4-2">This document defines the relevant SRv6 MSD
	<t>This document defines the relevant SRv6 MSDs and requests MSD type	s and requests MSD type
	assignments in the MSD Types registry created by <xref target="RFC8491"/>.	assignments in the "IGP MSD-Types" registry created by <xref target="RFC84
	</t>	91" format="default" sectionFormat="of" derivedContent="RFC8491"/>.</t>
		<section anchor="MAXSEGLEFT" numbered="true" toc="include" removeInRFC="fa
	<section anchor="MAXSEGLEFT" title="Maximum Segments Left MSD Type">	lse" pn="section-4.1">
	<t>The Maximum Segments Left MSD Type signals the maximum value of	<name slugifiedName="name-maximum-segments-left-msd-t">Maximum Segments
	the "Segments Left" field <xref target="RFC8754"/>	Left MSD Type</name>
		<t indent="0" pn="section-4.1-1">The Maximum Segments Left MSD Type sign
		als the maximum value of
		the "Segments Left" field <xref target="RFC8754" format="default" sectio
		nFormat="of" derivedContent="RFC8754"/>
	in the SRH of a received packet before applying the Endpoint behavior	in the SRH of a received packet before applying the Endpoint behavior
	associated with a SID.</t>	associated with a SID.</t>

		<t indent="3" pn="section-4.1-2">SRH Max Segments Left Type: 41</t>
	<t><figure>	<t indent="3" pn="section-4.1-3">If no value is advertised, the supporte
	<artwork><![CDATA[ SRH Max Segments Left Type: 41	d value is 0.</t>

	If no value is advertised, the supported value is 0.
	]]></artwork>
	</figure></t>
	</section>	</section>

		<section anchor="MAXSENDPOP" numbered="true" toc="include" removeInRFC="fa
	<section anchor="MAXSENDPOP" title="Maximum End Pop MSD Type">	lse" pn="section-4.2">
	<t>The Maximum End Pop MSD Type signals the maximum number of SIDs	<name slugifiedName="name-maximum-end-pop-msd-type">Maximum End Pop MSD
	in the SRH to which the router can apply "Penultimate Segment Pop of the	Type</name>
	SRH" or	<t indent="0" pn="section-4.2-1">The Maximum End Pop MSD Type signals th
	"Ultimate Segment Pop of the SRH" behavior, as defined in <xref target="	e maximum number of SIDs
	RFC8986"/>	in the SRH to which the router can apply "Penultimate Segment Pop (PSP)
	flavors.</t>	of the SRH" or
		"Ultimate Segment Pop (USP) of the SRH" behavior, as defined in "Flavors
	<t><figure>	" (<xref target="RFC8986" sectionFormat="of" section="4.16" format="default" der
	<artwork><![CDATA[ SRH Max End Pop Type: 42	ivedLink="https://rfc-editor.org/rfc/rfc8986#section-4.16" derivedContent="RFC89
		86"/>).</t>
	If the advertised value is zero or no value is advertised,	<t indent="3" pn="section-4.2-2">SRH Max End Pop Type: 42</t>
	then the router cannot apply PSP or USP flavors.	<t indent="3" pn="section-4.2-3">If the advertised value is zero or no v
	]]></artwork>	alue is advertised,
	</figure></t>	then the router cannot apply PSP or USP flavors.</t>
	</section>	</section>

		<section anchor="MAXHENCAP" numbered="true" toc="include" removeInRFC="fal
	<section anchor="MAXHENCAP" title="Maximum H.Encaps MSD Type">	se" pn="section-4.3">
		<name slugifiedName="name-maximum-hencaps-msd-type">Maximum H.Encaps MSD
	<t>The Maximum H.Encaps MSD Type signals the maximum number of SIDs that	Type</name>
	can be added to the Segment List of an SRH as part of the "H.Encaps"	<t indent="0" pn="section-4.3-1">The Maximum H.Encaps MSD Type signals t
	behavior as defined in <xref target="RFC8986"/>.</t>	he maximum number of SIDs that
		can be added to the segment list of an SRH as part of the "H.Encaps"
	<t><figure>	behavior, as defined in <xref target="RFC8986" format="default" sectionF
	<artwork><![CDATA[ SRH Max H.encaps Type: 44	ormat="of" derivedContent="RFC8986"/>.</t>
		<t indent="3" pn="section-4.3-2">SRH Max H.encaps Type: 44</t>
	If the advertised value is zero or no value is advertised, then the	<t indent="3" pn="section-4.3-3">If the advertised value is zero or no v
	headend can apply an SR Policy that only contains one segment, without	alue is advertised, then the
	inserting any SRH header.	headend can apply an SR Policy that only contains one segment without
		inserting any SRH header.</t>
	A non-zero SRH Max H.encaps MSD indicates that the headend can insert	<t indent="3" pn="section-4.3-4">A non-zero SRH Max H.encaps MSD indicat
	an SRH up to the advertised number of SIDs.	es that the headend can insert
		an SRH up to the advertised number of SIDs.</t>
	]]></artwork>
	</figure></t>
	</section>	</section>

		<section anchor="MAXENDD" numbered="true" toc="include" removeInRFC="false
	<section anchor="MAXENDD" title="Maximum End D MSD Type">	" pn="section-4.4">
		<name slugifiedName="name-maximum-end-d-msd-type">Maximum End D MSD Type
	<t>The Maximum End D MSD Type specifies the maximum number of SIDs prese	</name>
	nt	<t indent="0" pn="section-4.4-1">The Maximum End D MSD Type specifies th
	in an SRH when performing decapsulation. As specified in <xref target="R	e maximum number of SIDs present
	FC8986"/>	in an SRH when performing decapsulation. As specified in <xref target="R
	the permitted SID types include, but are not limited to End.DX6, End.DT4	FC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/>,
	,	the permitted SID types include, but are not limited to, End.DX6, End.DT
	End.DT46, End with USD, End.X with USD.</t>	4,
		End.DT46, End with USD, and End.X with USD.</t>
	<t><figure>	<t indent="3" pn="section-4.4-2">SRH Max End D Type: 45</t>
	<artwork><![CDATA[ SRH Max End D Type: 45	<t indent="3" pn="section-4.4-3">If the advertised value is zero or no v
		alue is advertised,
	If the advertised value is zero or no value is advertised	then the router cannot apply any behavior that results in
	then the router cannot apply any behavior that results in	decapsulation and forwarding of the inner packet if the
	decapsulation and forwarding of the inner packet if the	outer IPv6 header contains an SRH.</t>
	outer IPv6 header contains an SRH.
	]]></artwork>
	</figure></t>
	</section>	</section>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-5">
	<section title="SRv6 SIDs and Reachability">	<name slugifiedName="name-srv6-sids-and-reachability">SRv6 SIDs and Reacha
	<t>As discussed in <xref	bility</name>
	target="RFC8986"/>, an SRv6 Segment	<t indent="0" pn="section-5-1">As discussed in <xref target="RFC8986" form
	Identifier (SID) is 128 bits and consists of Locator, Function and Argu	at="default" sectionFormat="of" derivedContent="RFC8986"/>, an SRv6 Segment
	ment parts.</t>	Identifier (SID) is 128 bits and consists of locator, function, and argume
		nt parts.</t>
	<t>A node is provisioned with topology/algorithm specific locators for	<t indent="0" pn="section-5-2">A node is provisioned with topology-/algori
		thm-specific locators for
	each of the topology/algorithm pairs supported by that node. Each	each of the topology/algorithm pairs supported by that node. Each

	locator is a covering prefix for all SIDs provisioned on that node which	locator is a covering prefix for all SIDs provisioned on that node that
	have the matching topology/algorithm.</t>	have the matching topology/algorithm.</t>

		<t indent="0" pn="section-5-3">Locators <bcp14>MUST</bcp14> be advertised
	<t>Locators MUST be advertised in the SRv6 Locator TLV (see <xref target="	in the SRv6 Locator TLV (see <xref target="LOCTLV" format="default" sectionForma
	LOCTLV"/>).	t="of" derivedContent="Section 7.1"/>).
	Forwarding entries for the locators advertised in the SRv6 Locator	Forwarding entries for the locators advertised in the SRv6 Locator

	TLV MUST be installed in the forwarding plane of receiving SRv6 capable	TLV <bcp14>MUST</bcp14> be installed in the forwarding plane of receiving SRv6-capable
	routers when the associated topology/algorithm is supported by the	routers when the associated topology/algorithm is supported by the
	receiving node. The processing of the prefix advertised in the SRv6 Locato r TLV,	receiving node. The processing of the prefix advertised in the SRv6 Locato r TLV,

	the calculation of its reachability and the installation in the forwarding plane	the calculation of its reachability, and the installation in the forwardin g plane
	follows the process defined for the Prefix Reachability TLV 236	follows the process defined for the Prefix Reachability TLV 236

	<xref target="RFC5308"/>, or TLV 237 <xref target="RFC5120"/>.</t>	<xref target="RFC5308" format="default" sectionFormat="of" derivedContent=
		"RFC5308"/> or TLV 237 <xref target="RFC5120" format="default" sectionFormat="of
	<t>Locators associated with algorithm 0 and 1 (for all supported topologie	" derivedContent="RFC5120"/>.</t>
	s)	<t indent="0" pn="section-5-4">Locators associated with algorithms 0 and 1
	SHOULD be advertised in a Prefix Reachability TLV (236 or 237) so that	(for all supported topologies)
	legacy routers (i.e., routers which do not support SRv6) will install a	<bcp14>SHOULD</bcp14> also be advertised in a Prefix Reachability TLV (236
	forwarding entry for algorithm 0 and 1 SRv6 traffic.</t>	or 237) so that
		legacy routers (i.e., routers that do not support SRv6) will install a
	<t>In cases where the same prefix, with the same prefix-length, Multi Topo	forwarding entry for algorithms 0 and 1 SRv6 traffic.</t>
	logy ID	<t indent="0" pn="section-5-5">In cases where the same prefix with the sam
	(MT ID), and algorithm is received in both a Prefix Reachability TLV and	e prefix length, Multi-Topology Identifier
	an SRv6	(MTID), and algorithm is received in both a Prefix Reachability TLV and a
	Locator TLV, the Prefix Reachability advertisement MUST be preferred when	n SRv6
	installing	Locator TLV, the Prefix Reachability advertisement <bcp14>MUST</bcp14> be
		preferred when installing
	entries in the forwarding plane. This is to prevent inconsistent forwardin g entries	entries in the forwarding plane. This is to prevent inconsistent forwardin g entries

	between SRv6 capable and SRv6 incapable routers. Such preference of Prefix Reachability	between SRv6-capable and SRv6-incapable routers. Such preference of Prefix Reachability
	advertisement does not have any impact on the rest of the data advertised in the	advertisement does not have any impact on the rest of the data advertised in the
	SRv6 Locator TLV.</t>	SRv6 Locator TLV.</t>

		<t indent="0" pn="section-5-6">Locators associated with Flexible Algorithm
	<t>Locators associated with Flexible Algorithms (see Section 4 of	s (see <xref target="RFC9350" section="4" sectionFormat="of" format="default" de
	<xref target="I-D.ietf-lsr-flex-algo"/>) SHOULD NOT be advertised	rivedLink="https://rfc-editor.org/rfc/rfc9350#section-4" derivedContent="RFC9350
		"/>) <bcp14>SHOULD NOT</bcp14> be advertised
	in Prefix Reachability TLVs (236 or 237). Advertising the Flexible	in Prefix Reachability TLVs (236 or 237). Advertising the Flexible

	Algorithm locator in regular Prefix Reachability TLV (236 or 237) would ma	Algorithm locator in a regular Prefix Reachability TLV (236 or 237) would
	ke	make
	the forwarding for it to follow algo 0 path.</t>	the forwarding for it follow the algorithm 0 path.</t>
		<t indent="0" pn="section-5-7">SRv6 SIDs are advertised as sub-TLVs in the
	<t>SRv6 SIDs are advertised as sub-TLVs in the SRv6 Locator TLV except	SRv6 Locator TLV, except
	for SRv6 SIDs which are associated with a specific	for SRv6 SIDs that are associated with a specific
	Neighbor/Link and are therefore advertised as sub-TLVs in TLVs 22, 23,	neighbor/link and are therefore advertised as sub-TLVs in TLVs 22, 23,
	25, 141, 222, and 223.</t>	25, 141, 222, and 223.</t>

		<t indent="0" pn="section-5-8">SRv6 SIDs received from other nodes are not
	<t>SRv6 SIDs received from other nodes are not directly routable and MUST	directly routable and <bcp14>MUST NOT</bcp14>
	NOT
	be installed in the forwarding plane. Reachability to SRv6 SIDs depends up on the existence	be installed in the forwarding plane. Reachability to SRv6 SIDs depends up on the existence
	of a covering locator.</t>	of a covering locator.</t>

		<t indent="0" pn="section-5-9">Adherence to the rules defined in this sect
	<t>Adherence to the rules defined in this section will assure that SRv6	ion will ensure that SRv6
	SIDs associated with a supported topology/algorithm pair will be	SIDs associated with a supported topology/algorithm pair will be
	forwarded correctly, while SRv6 SIDs associated with an unsupported	forwarded correctly, while SRv6 SIDs associated with an unsupported
	topology/algorithm pair will be dropped. NOTE: The drop behavior depends	topology/algorithm pair will be dropped. NOTE: The drop behavior depends
	on the absence of a default/summary route covering a given locator.</t>	on the absence of a default/summary route covering a given locator.</t>

		<t indent="0" pn="section-5-10">In order for forwarding to work correctly,
	<t>In order for forwarding to work correctly, the locator associated	the locator associated
	with SRv6 SID advertisements must be the longest match prefix installed	with SRv6 SID advertisements must be the longest match prefix installed
	in the forwarding plane for those SIDs. In order to ensure correct forward ing,	in the forwarding plane for those SIDs. In order to ensure correct forward ing,
	network operators should take steps to make sure that this requirement is not	network operators should take steps to make sure that this requirement is not
	compromised. For example, the following situations should be avoided:</t>	compromised. For example, the following situations should be avoided:</t>

		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-1
	<t><list style="symbols">	1">
	<t>Another locator associated with a different topology/algorithm is	<li pn="section-5-11.1">Another locator associated with a different topo
	the longest match</t>	logy/algorithm is
		the longest match.</li>
	<t>Another prefix advertisement (i.e., from TLV 236 or 237) is the lon	<li pn="section-5-11.2">Another prefix advertisement (i.e., from TLV 236
	gest	or 237) is the longest
	match</t>	match.</li>
	</list></t>	</ul>
	</section>	</section>

		<section anchor="ANYCASTFLAG" numbered="true" toc="include" removeInRFC="fal
	<section anchor="ANYCASTFLAG" title="Advertising Anycast Property">	se" pn="section-6">
		<name slugifiedName="name-advertising-anycast-propert">Advertising Anycast
	<t>Both prefixes and SRv6 Locators may be configured as anycast and as suc	Property</name>
	h the	<t indent="0" pn="section-6-1">Both prefixes and SRv6 Locators may be conf
		igured as anycast; as such, the
	same value can be advertised by multiple routers. It is useful for other routers	same value can be advertised by multiple routers. It is useful for other routers
	to know that the advertisement is for an anycast identifier.</t>	to know that the advertisement is for an anycast identifier.</t>

		<t indent="0" pn="section-6-2">A new flag in the Prefix Attribute Flags su
	<t>A new flag in Prefix Attribute Flags Sub-TLV <xref target="RFC7794"/> i	b-TLV <xref target="RFC7794" format="default" sectionFormat="of" derivedContent=
	s defined to	"RFC7794"/> is
	advertise the anycast property:</t>	defined to advertise the anycast property:</t>
		<dl newline="false" spacing="compact" indent="3" pn="section-6-3">
	<t><figure>	<dt pn="section-6-3.1">Bit #:</dt>
	<artwork>	<dd pn="section-6-3.2">4</dd>
	Bit #: 4	<dt pn="section-6-3.3">Name:</dt>
	Name: Anycast Flag (A-flag)	<dd pn="section-6-3.4">Anycast Flag (A-flag)</dd>
		</dl>
	When the prefix/SRv6 locator is configured as anycast, the A-flag	<t indent="0" pn="section-6-4">When the prefix/SRv6 Locator is configured
	SHOULD be set. Otherwise, this flag MUST be clear.	as anycast, the A-flag
		<bcp14>SHOULD</bcp14> be set. Otherwise, this flag <bcp14>MUST</bcp14> be
	</artwork>	clear.</t>
	</figure></t>	<t indent="0" pn="section-6-5">The A-flag <bcp14>MUST</bcp14> be preserved
		when the advertisement is leaked between levels.</t>
	<t>The A-flag MUST be preserved when the advertisement is leaked betwee	<t indent="0" pn="section-6-6">The A-flag and the N-flag <bcp14>MUST NOT</
	n levels.</t>	bcp14> both be set. If both the N-flag and the A-flag are
		set in the prefix/SRv6 Locator advertisement, the receiving routers <bcp14
	<t>The A-flag and the N-flag MUST NOT both be set. If both N-flag and A-fl	>MUST</bcp14> ignore
	ag are
	set in the prefix/SRv6 Locator advertisement, the receiving routers MUST i
	gnore
	the N-flag.</t>	the N-flag.</t>

		<t indent="0" pn="section-6-7">The same prefix/SRv6 Locator can be adverti
	<t>The same prefix/SRv6 Locator can be advertised by multiple routers. If	sed by multiple routers. If at least
	at least	one of them sets the A-flag in its advertisement, the prefix/SRv6 Locator
	one of them sets the A-Flag in its advertisement, the prefix/SRv6 Locator	<bcp14>SHOULD</bcp14> be
	SHOULD be
	considered as anycast.</t>	considered as anycast.</t>

		<t indent="0" pn="section-6-8">A prefix/SRv6 Locator that is advertised by
	<t>A prefix/SRv6 Locator that is advertised by a single node and without	a single node and without
	an A-Flag is considered node specific.</t>	an A-flag <bcp14>MUST</bcp14> be considered node specific.</t>
		<t indent="0" pn="section-6-9">All the nodes advertising the same anycast
	<t>All the nodes advertising the same anycast locator MUST instantiate the	locator <bcp14>MUST</bcp14> instantiate the
	exact same set of SIDs under that anycast locator. Failure to do so may re sult in	exact same set of SIDs under that anycast locator. Failure to do so may re sult in

	traffic being black-holed or mis-routed.</t>	traffic being dropped or misrouted.</t>
		<t indent="0" pn="section-6-10">The Prefix Attribute Flags sub-TLV can be
	<t>The Prefix Attribute Flags Sub-TLV can be carried in the SRv6	carried in the SRv6
	Locator TLV as well as the Prefix Reachability TLVs. When a router origina tes	Locator TLV as well as the Prefix Reachability TLVs. When a router origina tes
	both the Prefix Reachability TLV and the SRv6 Locator TLV for a given	both the Prefix Reachability TLV and the SRv6 Locator TLV for a given

	prefix, and the router is originating the Prefix Attribute Flags Sub-TLV	prefix, it <bcp14>SHOULD</bcp14> advertise the Prefix Attribute Flags sub-
	in one of the TLVs, the router SHOULD advertise the same flags in the	TLV, if used, in both TLVs and use the same flags. However, unlike TLVs 236
	Prefix Attribute Flags Sub-TLV in both TLVs. However, unlike TLVs 236	<xref target="RFC5308" format="default" sectionFormat="of" derivedContent=
	<xref target="RFC5308"/> and 237 <xref target="RFC5120"/> the	"RFC5308"/> and 237 <xref target="RFC5120" format="default" sectionFormat="of" d
	X-flag in the Prefix Attributes Flags sub-TLV is valid when sent in the SR	erivedContent="RFC5120"/>,
	v6	the X-flag in the Prefix Attributes Flags sub-TLV is valid when sent in th
	Locator TLV. The state of the X-flag in the Prefix Attributes Flags sub-TL	e SRv6
	V when	Locator TLV. When included in the Locator TLV, the state of the X-flag in
	included in the Locator TLV MUST match the setting of the embedded "X-bit"	the Prefix Attributes
	in any	Flags sub-TLV <bcp14>MUST</bcp14> match the setting of the embedded "X-bit
	advertisement for the same prefix in TLVs 236 <xref target="RFC5308"/> and	" in any
	237	advertisement for the same prefix in TLVs 236 <xref target="RFC5308" forma
	<xref target="RFC5120"/>. In case of any inconsistency between the Prefix	t="default" sectionFormat="of" derivedContent="RFC5308"/> and 237
	Attribute	<xref target="RFC5120" format="default" sectionFormat="of" derivedContent=
		"RFC5120"/>. In case of any inconsistency between the Prefix Attribute
	Flags advertised in the Locator TLV and in the Prefix Reachability TLV, th e ones	Flags advertised in the Locator TLV and in the Prefix Reachability TLV, th e ones

	advertised in Prefix Reachability TLV MUST be preferred.</t>	advertised in the Prefix Reachability TLV <bcp14>MUST</bcp14> be preferred
		.</t>
	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
	<section title="Advertising Locators and End SIDs">	<name slugifiedName="name-advertising-locators-and-en">Advertising Locator
	<t>The SRv6 Locator TLV is introduced to advertise SRv6 Locators and End	s and End SIDs</name>
		<t indent="0" pn="section-7-1">The SRv6 Locator TLV is introduced to adver
		tise SRv6 Locators and End
	SIDs associated with each locator.</t>	SIDs associated with each locator.</t>

		<t indent="0" pn="section-7-2">This new TLV shares the sub-TLV space defin
	<t>This new TLV shares the sub-TLV space defined for TLVs 135, 235, 236	ed for TLVs 135, 235, 236,
	and 237.</t>	and 237.</t>

		<section anchor="LOCTLV" numbered="true" toc="include" removeInRFC="false"
		pn="section-7.1">
		<name slugifiedName="name-srv6-locator-tlv-format">SRv6 Locator TLV Form
		at</name>
		<t indent="0" pn="section-7.1-1">The SRv6 Locator TLV has the following
		format:


	<section anchor="LOCTLV" title="SRv6 Locator TLV Format">	</t>
	<t>The SRv6 Locator TLV has the following format:	<artwork name="" type="" align="left" alt="" pn="section-7.1-2">
		0 1 2 3
	<figure>	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
	<artwork><![CDATA[ 0 1 2	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3	\| Type \| Length \|R\|R\|R\|R\| MTID \|
	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	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	\| Locator Entries . . . \|
	\| Type \| Length \|R\|R\|R\|R\| MT ID \|	</artwork>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dl newline="false" spacing="normal" indent="3" pn="section-7.1-3">
	\| Locator Entries . . . \|	<dt pn="section-7.1-3.1">Type:</dt>
	]]></artwork>	<dd pn="section-7.1-3.2">27. Single octet, as defined in Section 9 of
	</figure>	<xref target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO1
		0589"/>.</dd>
	<list style="hanging">	<dt pn="section-7.1-3.3">Length:</dt>
		<dd pn="section-7.1-3.4">Single octet, as defined in Section 9 of <xre
	<t>Type: 27. Single octet as defined in section 9 of [ISO10589].</t>	f target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO10589
		"/>.
	<t>Length: Single octet as defined in section 9 of [ISO10589]. The length v	The length value is variable.</dd>
	alue is	<dt pn="section-7.1-3.5">R Bits:</dt>
	variable.</t>	<dd pn="section-7.1-3.6">Reserved for future use. They <bcp14>MUST</bc
		p14> be
	<t>R bits: reserved for future use. They MUST be	set to zero on transmission and <bcp14>MUST</bcp14> be ignored on recei
	set to zero on transmission and MUST be ignored on receipt.</t>	pt.</dd>
		<dt pn="section-7.1-3.7">MTID:</dt>
	<t>MT ID: Multitopology Identifier as defined in [RFC5120].	<dd pn="section-7.1-3.8">Multi-Topology Identifier, as defined in <xre
	Note that the value 0 is legal.</t>	f target="RFC5120" format="default" sectionFormat="of" derivedContent="RFC5120"/
		>.
	</list></t>	Note that the value 0 is legal.</dd>
		</dl>
	<t>Followed by one or more locator entries of the form:	<t indent="0" pn="section-7.1-4">The SRv6 Locator TLV is followed by one
		or more locator entries of the form:</t>
	<figure>	<artwork name="" type="" align="left" alt="" pn="section-7.1-5">
	<artwork><![CDATA[ 0 1 2	0 1 2 3
	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	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	\| Metric \|
	\| Metric \|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	\| Flags \| Algorithm \| Loc Size \|
	\| Flags \| Algorithm \| Loc Size \|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Locator (continued, variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Sub-TLV-len \| Sub-TLVs (variable) . . . \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>
	</figure>

	<list style="hanging">

	<t>Metric: 4 octets. As described in Section 4 of [RFC5305].</t>

	<t>Flags: 1 octet. The following flags are defined:

	<figure>
	<artwork><![CDATA[ 0
	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+
	\|D\| Reserved \|
	+-+-+-+-+-+-+-+-+
	]]></artwork>
	</figure>
	<list style="hanging">
	<t>D-flag: Same as described in section 4.1. of [RFC5305].</t>

	<t>The remaining bits are reserved for future use. They MUST be
	set to zero on transmission and MUST be ignored on receipt.</t>
	</list></t>

	<t>Algorithm: 1 octet. As defined in IGP Algorithm Types registry <xref tar
	get="RFC8665"/>.</t>

	<t>Loc-Size: 1 octet. Number of bits in the SRv6 Locator field.
	MUST be from the range (1 - 128). The TLV MUST be ignored if
	the Loc-Size is outside this range.</t>

	<t>Locator: 1-16 octets. This field encodes the advertised SRv6
	Locator. The Locator is encoded in the minimal number of
	octets for the given number of bits. Trailing bits MUST be set
	to zero and ignored when received.</t>

	<t>Sub-TLV-length: 1 octet. Number of octets used by sub-TLVs.</t>

	<t>Optional sub-TLVs: Supported sub-TLVs are specified in <xref target="REV
	ISEDREG"/>.
	Any Sub-TLV that is not allowed in the SRv6 Locator TLV MUST be ignored.</t
	>

	</list></t>

	<t>Prefix Attribute Flags Sub-TLV <xref target="RFC7794"/> SHOULD be includ
	ed in
	the Locator TLV.</t>

	<t>Prefix Attribute Flags Sub-TLV MUST be included in the the Locator TLV w
	hen it
	is leaked upwards in the hierarchy or originated as a result of the redistr
	ibution
	from another protocol or another ISIS instance. If the Prefix Attribute Fla
	gs Sub-TLV
	is not included in these cases, receivers will be unable to determine the c
	orrect source
	of the advertisement. The receivers will be unable to detect the violation.
	</t>

	</section>


	<section anchor="ENDTLV" title="SRv6 End SID sub-TLV">	-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	<t>The SRv6 End SID sub-TLV is introduced to advertise SRv6 Segment	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Identifiers (SID) with Endpoint behaviors which do not require a	// Locator (continued, variable) //
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Sub-TLV-len \| Sub-TLVs (variable) . . . \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		</artwork>
		<dl newline="false" spacing="normal" indent="3" pn="section-7.1-6">
		<dt pn="section-7.1-6.1">Metric:</dt>
		<dd pn="section-7.1-6.2">4 octets, as described in <xref target="RFC53
		05" section="4" sectionFormat="of" format="default" derivedLink="https://rfc-edi
		tor.org/rfc/rfc5305#section-4" derivedContent="RFC5305"/>.</dd>
		<dt pn="section-7.1-6.3">Flags:</dt>
		<dd pn="section-7.1-6.4">
		<t indent="0" pn="section-7.1-6.4.1">1 octet. The following flags ar
		e defined:</t>
		<artwork name="" type="" align="left" alt="" pn="section-7.1-6.4.2">
		0
		0 1 2 3 4 5 6 7
		+-+-+-+-+-+-+-+-+
		\|D\| Reserved \|
		+-+-+-+-+-+-+-+-+
		</artwork>
		<dl newline="false" spacing="normal" indent="3" pn="section-7.1-6.4.
		3">
		<dt pn="section-7.1-6.4.3.1"/>
		<dd pn="section-7.1-6.4.3.2">D-flag: "up/down bit" as described in
		<xref target="RFC5305" sectionFormat="of" section="4.1" format="def
		ault" derivedLink="https://rfc-editor.org/rfc/rfc5305#section-4.1" derivedConten
		t="RFC5305"/>.</dd>
		<dt pn="section-7.1-6.4.3.3"/>
		<dd pn="section-7.1-6.4.3.4">The remaining bits are reserved for f
		uture use. They <bcp14>MUST</bcp14> be
		set to zero on transmission and <bcp14>MUST</bcp14> be ignored on r
		eceipt.</dd>
		</dl>
		</dd>
		<dt pn="section-7.1-6.5">Algorithm:</dt>
		<dd pn="section-7.1-6.6">1 octet, as defined in the "IGP Algorithm Typ
		es" registry <xref target="RFC8665" format="default" sectionFormat="of" derivedC
		ontent="RFC8665"/>.</dd>
		<dt pn="section-7.1-6.7">Loc-Size:</dt>
		<dd pn="section-7.1-6.8">1 octet. Number of bits in the SRv6 Locator f
		ield, which
		<bcp14>MUST</bcp14> be from the range (1-128). The entire TLV <bcp14>MU
		ST</bcp14> be ignored
		if the Loc-Size is outside this range.</dd>
		<dt pn="section-7.1-6.9">Locator:</dt>
		<dd pn="section-7.1-6.10">1-16 octets. This field encodes the advertis
		ed SRv6
		Locator. The SRv6 Locator is encoded in the minimal number of
		octets for the given number of bits. Trailing bits <bcp14>MUST</bcp14>
		be set
		to zero and ignored when received.</dd>
		<dt pn="section-7.1-6.11">Sub-TLV-length:</dt>
		<dd pn="section-7.1-6.12">1 octet. Number of octets used by sub-TLVs.<
		/dd>
		<dt pn="section-7.1-6.13">Optional Sub-TLVs:</dt>
		<dd pn="section-7.1-6.14">Supported sub-TLVs are specified in <xref ta
		rget="REVISEDREG" format="default" sectionFormat="of" derivedContent="Section 11
		.1.2"/>.
		Any sub-TLV that is not allowed in the SRv6 Locator TLV <bcp14>MUST</bc
		p14> be
		ignored.</dd>
		</dl>
		<t indent="0" pn="section-7.1-7">The Prefix Attribute Flags sub-TLV <xre
		f target="RFC7794" format="default" sectionFormat="of" derivedContent="RFC7794"/
		>
		<bcp14>SHOULD</bcp14> be included in the Locator TLV.</t>
		<t indent="0" pn="section-7.1-8">The Prefix Attribute Flags sub-TLV <bcp
		14>MUST</bcp14> be included in the Locator
		TLV when it is leaked upwards in the hierarchy or originated as a result
		of the
		redistribution from another protocol or another IS-IS instance. If the Pr
		efix Attribute
		Flags sub-TLV is not included in these cases, receivers will be unable to
		determine the
		correct source of the advertisement. The receivers will be unable to dete
		ct the
		violation.</t>
		</section>
		<section anchor="ENDTLV" numbered="true" toc="include" removeInRFC="false"
		pn="section-7.2">
		<name slugifiedName="name-srv6-end-sid-sub-tlv">SRv6 End SID Sub-TLV</na
		me>
		<t indent="0" pn="section-7.2-1">The SRv6 End SID sub-TLV is introduced
		to advertise SRv6 SIDs with Endpoint behaviors that do not require a
	particular neighbor in order to be correctly applied.	particular neighbor in order to be correctly applied.
	SRv6 SIDs associated with a neighbor are advertised using the sub-TLVs d efined	SRv6 SIDs associated with a neighbor are advertised using the sub-TLVs d efined

	in <xref target="ADJSID"/>.</t>	in <xref target="ADJSID" format="default" sectionFormat="of" derivedCont
		ent="Section 8"/>.</t>
	<t>Supported behavior values, together with parent TLVs in which they ar	<t indent="0" pn="section-7.2-2">Supported behavior values, together wit
	e	h parent TLVs in which they are
	advertised, are specified in <xref target="ENDBEH"/> of this	advertised, are specified in <xref target="ENDBEH" format="default" sect
	document. Please note that not all behaviors defined in <xref target="RF	ionFormat="of" derivedContent="Section 10"/> of this document. Please note
	C8986"/>	that not all behaviors defined in <xref target="RFC8986" format="default"
	are defined in this document, e.g. END.T is not.</t>	sectionFormat="of" derivedContent="RFC8986"/>
		are defined in this document, e.g., End.T is not.</t>
	<t>This new sub-TLV is advertised in the SRv6 Locator TLV defined in	<t indent="0" pn="section-7.2-3">This new sub-TLV is advertised in the S
		Rv6 Locator TLV defined in
	the previous section. SRv6 End SIDs inherit the topology/algorithm	the previous section. SRv6 End SIDs inherit the topology/algorithm
	from the parent locator.</t>	from the parent locator.</t>

		<t indent="0" pn="section-7.2-4">The SRv6 End SID sub-TLV has the follow
		ing format:</t>
		<artwork name="" type="" align="left" alt="" pn="section-7.2-5">
		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 \| Flags \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


	<t>The SRv6 End SID sub-TLV has the following format:	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Endpoint Behavior \|
	<figure>	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	<artwork><![CDATA[ 0 1 2	\| SID (128 bits) . . . \|
	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	\| SID (cont . . .) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \|	\| SID (cont . . .) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| SID (cont . . .) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Endpoint Behavior \|	\|Sub-sub-TLV-len\| Sub-sub-TLVs (variable) . . . \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SID (128 bits) . . . \|	</artwork>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dl newline="false" spacing="normal" indent="3" pn="section-7.2-6">
	\| SID (cont . . .) \|	<dt pn="section-7.2-6.1">Type:</dt>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dd pn="section-7.2-6.2">5. Single octet, as defined in Section 9 of <
	\| SID (cont . . .) \|	xref target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO10
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	589"/>.</dd>
	\| SID (cont . . .) \|	<dt pn="section-7.2-6.3">Length:</dt>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dd pn="section-7.2-6.4">Single octet, as defined in Section 9 of <xre
	\|Sub-sub-TLV-len\| Sub-sub-TLVs (variable) . . . \|	f target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO10589
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	"/>.
	]]></artwork>	The length value is variable.</dd>
	</figure>	<dt pn="section-7.2-6.5">Flags:</dt>
		<dd pn="section-7.2-6.6">1 octet. No flags are currently defined. All
	<list style="hanging">	bits are reserved for future
		use. They <bcp14>MUST</bcp14> be set to zero on transmission and <bcp1
	<t>Type: 5. Single octet as defined in section 9 of [ISO10589].</t>	4>MUST</bcp14> be
		ignored on receipt.</dd>
	<t>Length: Single octet as defined in section 9 of [ISO10589]. The length	<dt pn="section-7.2-6.7">Endpoint Behavior:</dt>
	value is	<dd pn="section-7.2-6.8">2 octets, as defined in <xref target="RFC8986
	variable.</t>	" format="default" sectionFormat="of" derivedContent="RFC8986"/>.
		Supported behavior values for this sub-TLV are defined in <xref target
	<t>Flags: 1 octet. No flags are currently defined. All bits are reserved f	="ENDBEH" format="default" sectionFormat="of" derivedContent="Section 10"/> of t
	or future	his document. Unsupported or unrecognized behavior values are
	use. They MUST be set to zero on transmission and MUST be ignored on rece	ignored by the receiver.</dd>
	ipt.</t>	<dt pn="section-7.2-6.9">SID:</dt>
		<dd pn="section-7.2-6.10">16 octets. This field encodes the advertised
	<t>Endpoint Behavior: 2 octets, as defined in <xref target="RFC8986"/>.	SRv6 SID.</dd>
	Supported behavior values for this sub-TLV are defined in <xref target=	<dt pn="section-7.2-6.11">Sub-sub-TLV-length:</dt>
	"ENDBEH"/>	<dd pn="section-7.2-6.12">1 octet. Number of octets used by sub-sub-TL
	of this document. Unsupported or unrecognized behavior values are ignor	Vs.</dd>
	ed	<dt pn="section-7.2-6.13">Optional Sub-sub-TLVs:</dt>
	by the receiver.</t>	<dd pn="section-7.2-6.14">Supported sub-sub-TLVs are specified in
		<xref target="SUBTLVREGISTRY" format="default" sectionFormat="of" deriv
	<t>SID: 16 octets. This field encodes the advertised SRv6 SID.</t>	edContent="Section 11.6"/>. Any sub-sub-TLV that is not allowed in the
		SRv6 End SID sub-TLV <bcp14>MUST</bcp14> be ignored.</dd>
	<t>Sub-sub-TLV-length: 1 octet. Number of octets used by sub-sub-TLVs.</t>	</dl>
		<t indent="0" pn="section-7.2-7">The SRv6 End SID <bcp14>MUST</bcp14> be
	<t>Optional Sub-sub-TLVs: Supported Sub-sub-TLVs are specified in	allocated from its associated locator.
	<xref target="SUBTLVREGISTRY"/>. Any Sub-sub-TLV that is not allowed in SR
	v6 End SID
	sub-TLV MUST be ignored.</t>
	</list></t>

	<t>The SRv6 End SID MUST be allocated from its associated locator.
	SRv6 End SIDs that are not allocated from the associated	SRv6 End SIDs that are not allocated from the associated

	locator MUST be ignored.</t>	locator <bcp14>MUST</bcp14> be ignored.</t>
		<t indent="0" pn="section-7.2-8">Multiple SRv6 End SIDs <bcp14>MAY</bcp1
	<t>Multiple SRv6 End SIDs MAY be associated with the same locator. In	4> be associated with the same locator. In
	cases where the number of SRv6 End SID sub-TLVs exceeds the capacity	cases where the number of SRv6 End SID sub-TLVs exceeds the capacity

	of a single TLV, multiple Locator TLVs for the same locator MAY be	of a single TLV, multiple Locator TLVs for the same locator <bcp14>MAY</
	advertised. For a given MTID/Locator the algorithm MUST be the same in	bcp14> be
	all TLVs. If this restriction is not met all TLVs for that	advertised. For a given MTID/Locator, the algorithm <bcp14>MUST</bcp14>
	MTID/Locator MUST be ignored.</t>	be the same in
		all TLVs. If this restriction is not met, all TLVs for that
		MTID/Locator <bcp14>MUST</bcp14> be ignored.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="ADJSID" numbered="true" toc="include" removeInRFC="false" p
	<section anchor="ADJSID" title="Advertising SRv6 Adjacency SIDs">	n="section-8">
	<t>Certain SRv6 Endpoint behaviors <xref	<name slugifiedName="name-advertising-srv6-adjacency-">Advertising SRv6 Ad
	target="RFC8986"/> are	jacency SIDs</name>
		<t indent="0" pn="section-8-1">Certain SRv6 Endpoint behaviors <xref targe
		t="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/> are
	associated with a particular adjacency.</t>	associated with a particular adjacency.</t>

		<t indent="0" pn="section-8-2">This document defines two new sub-TLVs of T
	<t>This document defines two new sub-TLVs of TLV 22, 23, 25, 141, 222, and	LVs 22, 23, 25, 141, 222, and 223
	223	-- namely "SRv6 End.X SID sub-TLVs" and "SRv6 LAN End.X SID sub-TLVs".</t
	- namely "SRv6 End.X SID sub-TLVs" and "SRv6 LAN End.X SID sub-TLVs".</t>	>
		<t indent="0" pn="section-8-3">IS-IS neighbor advertisements are topology
	<t>IS-IS Neighbor advertisements are topology specific - but not	specific but not
	algorithm specific. SIDs advertised in SRv6 End.X SID and SRv6 LAN End.X S ID sub-TLVs	algorithm specific. SIDs advertised in SRv6 End.X SID and SRv6 LAN End.X S ID sub-TLVs
	therefore inherit the topology from the associated neighbor advertisement, but	therefore inherit the topology from the associated neighbor advertisement, but
	the algorithm is specified in the individual SID.</t>	the algorithm is specified in the individual SID.</t>

		<t indent="0" pn="section-8-4">All SIDs advertised in SRv6 End.X SID and S
	<t>All SIDs advertised in SRv6 End.X SID and SRv6 LAN End.X SID sub-TLVs M	Rv6 LAN End.X SID sub-TLVs <bcp14>MUST</bcp14>
	UST	be a subnet of a Locator with matching topology and algorithm that are ad
	be a subnet of a Locator with matching topology and algorithm which is a	vertised
	dvertised
	by the same node in an SRv6 Locator TLV. SIDs that do not meet this	by the same node in an SRv6 Locator TLV. SIDs that do not meet this

	requirement MUST be ignored. This ensures that the node advertising	requirement <bcp14>MUST</bcp14> be ignored. This ensures that the node adv ertising
	these SIDs is also advertising its corresponding Locator with the algorith m	these SIDs is also advertising its corresponding Locator with the algorith m
	that will be used for computing paths destined to the SID.</t>	that will be used for computing paths destined to the SID.</t>

		<section anchor="ENDXTLV" numbered="true" toc="include" removeInRFC="false
	<section anchor="ENDXTLV" title="SRv6 End.X SID sub-TLV">	" pn="section-8.1">
	<t>This sub-TLV is used to advertise an SRv6 SID associated with a	<name slugifiedName="name-srv6-endx-sid-sub-tlv">SRv6 End.X SID Sub-TLV<
	point to point adjacency. Multiple SRv6 End.X SID sub-TLVs MAY be	/name>
		<t indent="0" pn="section-8.1-1">This sub-TLV is used to advertise an SR
		v6 SID associated with a
		point-to-point adjacency. Multiple SRv6 End.X SID sub-TLVs <bcp14>MAY</b
		cp14> be
	associated with the same adjacency.</t>	associated with the same adjacency.</t>

		<t indent="0" pn="section-8.1-2">The SRv6 End.X SID sub-TLV has the foll owing format:


	<t>The SRv6 End.X SID sub-TLV has the following format:	</t>
		<artwork name="" type="" align="left" alt="" pn="section-8.1-3">
	<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 \| Flags \| Algorithm \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \| Algorithm \|	\| Weight \| Endpoint Behavior \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Weight \| Endpoint Behavior \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SID (128 bits) . . . \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SID (cont . . .) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SID (cont . . .) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SID (cont . . .) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|Sub-sub-tlv-len\| Sub-sub-TLVs (variable) . . . \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	]]></artwork>
	</figure>

	<list style="hanging">

	<t>Type: 43. Single octet as defined in section 9 of [ISO10589].</t>

	<t>Length: Single octet as defined in section 9 of [ISO10589]. The length
	value is
	variable.</t>

	<t>Flags: 1 octet.
	<figure align="center">
	<artwork>

	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+
	\|B\|S\|P\|Reserved \|
	+-+-+-+-+-+-+-+-+

	where: </artwork>
	</figure>
	<list style="hanging">

	<t>B-Flag: Backup flag. If set, the SID is eligible
	for protection, e.g., using IP Fast Re-route (IPFRR) <xref target="RFC5
	286"/>,
	as described in <xref target="RFC8355"/>.</t>

	<t>S-Flag. Set flag. When set, the S-Flag indicates that the
	SID refers to a set of adjacencies (and therefore
	MAY be assigned to other adjacencies as well).</t>

	<t>P-Flag. Persistent flag. When set, the P-Flag indicates that
	the SID is persistently allocated, i.e., the
	SID value remains consistent across router restart
	and/or interface flap.</t>

	<t>Reserved bits: MUST be zero when originated and MUST be ignored when
	received.</t>
	</list></t>

	<t>Algorithm: 1 octet. As defined in IGP Algorithm Types registry <xref ta
	rget="RFC8665"/>.</t>

	<t>Weight: 1 octet. The value represents the weight of the
	SID for the purpose of load balancing. The use
	of the weight is defined in [RFC8402].</t>

	<t>Endpoint Behavior: 2 octets. As defined in <xref target="RFC8986"/>.
	Supported behavior values for this sub-TLV are defined in <xref target="EN
	DBEH"/>
	of this document. Unsupported or unrecognized behavior values are ignor
	ed
	by the receiver.</t>

	<t>SID: 16 octets. This field encodes the advertised SRv6 SID.</t>

	<t>Sub-sub-TLV-length: 1 octet. Number of octets used by sub-sub-
	TLVs.</t>

	<t>Optional Sub-sub-TLVs: Supported Sub-sub-TLVs are specified in
	<xref target="SUBTLVREGISTRY"/>. Any Sub-sub-TLV that is not allowed in SR
	v6 End.X SID
	sub-TLV MUST be ignored.</t>
	</list></t>


	<t>Note that multiple TLVs for the same neighbor may be	-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| SID (128 bits) . . . \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| SID (cont . . .) \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| SID (cont . . .) \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| SID (cont . . .) \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\|Sub-sub-tlv-len\| Sub-sub-TLVs (variable) . . . \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		</artwork>
		<dl newline="false" spacing="normal" indent="3" pn="section-8.1-4">
		<dt pn="section-8.1-4.1">Type: 43.</dt>
		<dd pn="section-8.1-4.2">Single octet, as defined in Section 9 of <xre
		f target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO10589
		"/>.</dd>
		<dt pn="section-8.1-4.3">Length:</dt>
		<dd pn="section-8.1-4.4">Single octet, as defined in Section 9 of <xre
		f target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO10589
		"/>.
		The length value is variable.</dd>
		<dt pn="section-8.1-4.5">Flags:</dt>
		<dd pn="section-8.1-4.6">
		<t indent="0" pn="section-8.1-4.6.1">1 octet.</t>
		<artwork name="" type="" align="left" alt="" pn="section-8.1-4.6.2">
		0 1 2 3 4 5 6 7
		+-+-+-+-+-+-+-+-+
		\|B\|S\|P\|Reserved \|
		+-+-+-+-+-+-+-+-+
		</artwork>
		<dl newline="true" spacing="normal" indent="3" pn="section-8.1-4.6.3
		">
		<dt pn="section-8.1-4.6.3.1">where:</dt>
		<dd pn="section-8.1-4.6.3.2">
		<dl newline="false" spacing="normal" indent="3" pn="section-8.1-
		4.6.3.2.1">
		<dt pn="section-8.1-4.6.3.2.1.1">B-Flag:</dt>
		<dd pn="section-8.1-4.6.3.2.1.2">Backup flag. If set, the SID
		is eligible
		for protection, e.g., using IP Fast Reroute (IPFRR) <xref target="
		RFC5286" format="default" sectionFormat="of" derivedContent="RFC5286"/>, as desc
		ribed in <xref target="RFC8355" format="default" sectionFormat="of" derivedConte
		nt="RFC8355"/>.</dd>
		<dt pn="section-8.1-4.6.3.2.1.3">S-Flag:</dt>
		<dd pn="section-8.1-4.6.3.2.1.4">Set flag. When set, the S-fl
		ag indicates that the
		SID refers to a set of adjacencies (and therefore
		<bcp14>MAY</bcp14> be assigned to other adjacencies as well).</dd>
		<dt pn="section-8.1-4.6.3.2.1.5">P-Flag:</dt>
		<dd pn="section-8.1-4.6.3.2.1.6">Persistent flag. When set, t
		he P-flag indicates that
		the SID is persistently allocated, i.e., the
		SID value remains consistent across router restart
		and/or interface flap.</dd>
		<dt pn="section-8.1-4.6.3.2.1.7">Reserved bits:</dt>
		<dd pn="section-8.1-4.6.3.2.1.8">Reserved bits <bcp14>MUST</bc
		p14> be zero when originated and
		<bcp14>MUST</bcp14> be ignored when received.</dd>
		</dl>
		</dd>
		</dl>
		</dd>
		<dt pn="section-8.1-4.7">Algorithm:</dt>
		<dd pn="section-8.1-4.8">1 octet, as defined in the "IGP Algorithm Typ
		es" registry <xref target="RFC8665" format="default" sectionFormat="of" derivedC
		ontent="RFC8665"/>.</dd>
		<dt pn="section-8.1-4.9">Weight:</dt>
		<dd pn="section-8.1-4.10">1 octet. The value represents the weight of
		the
		SID for the purpose of load balancing. The use
		of the weight is defined in [RFC8402].</dd>
		<dt pn="section-8.1-4.11">Endpoint Behavior:</dt>
		<dd pn="section-8.1-4.12">2 octets, as defined in <xref target="RFC89
		86" format="default" sectionFormat="of" derivedContent="RFC8986"/>.
		Supported behavior values for this sub-TLV are defined in <xref target=
		"ENDBEH" format="default" sectionFormat="of" derivedContent="Section 10"/>
		of this document. Unsupported or unrecognized behavior values are igno
		red
		by the receiver.</dd>
		<dt pn="section-8.1-4.13">SID:</dt>
		<dd pn="section-8.1-4.14">16 octets. This field encodes the advertised
		SRv6 SID.</dd>
		<dt pn="section-8.1-4.15">Sub-sub-TLV-length:</dt>
		<dd pn="section-8.1-4.16">1 octet. Number of octets used by sub-sub- T
		LVs.</dd>
		<dt pn="section-8.1-4.17">Optional Sub-sub-TLVs:</dt>
		<dd pn="section-8.1-4.18">Supported sub-sub-TLVs are specified in
		<xref target="SUBTLVREGISTRY" format="default" sectionFormat="of" deriv
		edContent="Section 11.6"/>. Any sub-sub-TLV that is not allowed in
		SRv6 End.X SID sub-TLV <bcp14>MUST</bcp14> be ignored.</dd>
		</dl>
		<t indent="0" pn="section-8.1-5">Note that multiple TLVs for the same ne
		ighbor may be
	required in order to advertise all the SRv6 SIDs associated	required in order to advertise all the SRv6 SIDs associated
	with that neighbor.</t>	with that neighbor.</t>

	</section>	</section>
		<section anchor="LANENDXTLV" numbered="true" toc="include" removeInRFC="fa
	<section anchor="LANENDXTLV" title="SRv6 LAN End.X SID sub-TLV">	lse" pn="section-8.2">
	<t>This sub-TLV is used to advertise an SRv6 SID associated with a LAN	<name slugifiedName="name-srv6-lan-endx-sid-sub-tlv">SRv6 LAN End.X SID
		Sub-TLV</name>
		<t indent="0" pn="section-8.2-1">This sub-TLV is used to advertise an SR
		v6 SID associated with a LAN
	adjacency. Since the parent TLV is advertising an adjacency to the	adjacency. Since the parent TLV is advertising an adjacency to the
	Designated Intermediate System (DIS) for the LAN, it is necessary to	Designated Intermediate System (DIS) for the LAN, it is necessary to

	include the System ID of the physical neighbor on the LAN with which	include the System-ID of the physical neighbor on the LAN with which
	the SRv6 SID is associated. Given that many neighbors may	the SRv6 SID is associated. Given that many neighbors may
	exist on a given LAN, multiple SRv6 LAN END.X SID sub-TLVs may	exist on a given LAN, multiple SRv6 LAN END.X SID sub-TLVs may
	be associated with the same LAN. Note that multiple TLVs for the same	be associated with the same LAN. Note that multiple TLVs for the same
	DIS neighbor may be required in order to advertise all the SRv6	DIS neighbor may be required in order to advertise all the SRv6
	SIDs associated with that neighbor.</t>	SIDs associated with that neighbor.</t>

		<t indent="0" pn="section-8.2-2">The SRv6 LAN End.X SID sub-TLV has the
		following format:</t>
		<artwork name="" type="" align="left" alt="" pn="section-8.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 \| \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
		\| Neighbor System-ID (ID length octets) \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Flags \| Algorithm \| Weight \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


	<t>The SRv6 LAN End.X SID sub-TLV has the following format:	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Endpoint Behavior \|
	<figure>	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	<artwork><![CDATA[ 0 1 2	\| SID (128 bits) . . . \|
	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	\| SID (cont . . .) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| \|	\| SID (cont . . .) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Neighbor System-ID (ID length octets) \|	\| SID (cont . . .) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Flags \| Algorithm \| Weight \|	\|Sub-sub-TLV-len\| Sub-sub-TLVs (variable) . . . \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		</artwork>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dl newline="false" spacing="normal" indent="3" pn="section-8.2-4">
	\| Endpoint Behavior \|	<dt pn="section-8.2-4.1">Type:</dt>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dd pn="section-8.2-4.2">44. Single octet, as defined in Section 9 of
	\| SID (128 bits) . . . \|	<xref target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	0589"/>.</dd>
	\| SID (cont . . .) \|	<dt pn="section-8.2-4.3">Length:</dt>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dd pn="section-8.2-4.4">Single octet, as defined in Section 9 of <xre
	\| SID (cont . . .) \|	f target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO10589
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	"/>.
	\| SID (cont . . .) \|	The length value is variable.</dd>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	<dt pn="section-8.2-4.5">Neighbor System-ID:</dt>
	\|Sub-sub-TLV-len\| sub-sub-TLVs (variable) . . . \|	<dd pn="section-8.2-4.6">IS-IS System-ID of length "ID Length", as def
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	ined in <xref target="ISO10589" format="default" sectionFormat="of" derivedConte
		nt="ISO10589"/>.</dd>
	]]></artwork>	<dt pn="section-8.2-4.7">Flags:</dt>
	</figure>	<dd pn="section-8.2-4.8">
	<list style="hanging">	<t indent="0" pn="section-8.2-4.8.1">1 octet.</t>
		<artwork name="" type="" align="left" alt="" pn="section-8.2-4.8.2">
	<t>Type: 44. Single octet as defined in section 9 of [ISO10589].</t>	0 1 2 3 4 5 6 7
		+-+-+-+-+-+-+-+-+
	<t>Length: Single octet as defined in section 9 of [ISO10589]. The length	\|B\|S\|P\|Reserved \|
	value is	+-+-+-+-+-+-+-+-+
	variable.</t>	</artwork>
		<t indent="0" pn="section-8.2-4.8.3">The B-, S-, and P-flags are as
	<t>Neighbor System-ID: IS-IS System-ID of length "ID Length" as	described in <xref target="ENDXTLV" format="default" sectionFormat="of" derivedC
	defined in [ISO10589].</t>	ontent="Section 8.1"/>. Reserved bits <bcp14>MUST</bcp14> be zero when originate
		d and
	<t>Flags: 1 octet.	<bcp14>MUST</bcp14> be ignored when received.</t>
	<figure align="center">	</dd>
	<artwork>	<dt pn="section-8.2-4.9">Algorithm:</dt>
		<dd pn="section-8.2-4.10">1 octet, as defined in the "IGP Algorithm Ty
	0 1 2 3 4 5 6 7	pes" registry <xref target="RFC8665" format="default" sectionFormat="of" derived
	+-+-+-+-+-+-+-+-+	Content="RFC8665"/>.</dd>
	\|B\|S\|P\|Reserved \|	<dt pn="section-8.2-4.11">Weight:</dt>
	+-+-+-+-+-+-+-+-+	<dd pn="section-8.2-4.12">1 octet. The value represents the weight of
		the
	</artwork>	SID for the purpose of load balancing. The use
	</figure>	of the weight is defined in [RFC8402].</dd>
	<list style="hanging">	<dt pn="section-8.2-4.13">Endpoint Behavior:</dt>
		<dd pn="section-8.2-4.14">2 octets, as defined in <xref target="RFC898
	<t>where B,S, and P flags are as described in <xref target="ENDXTLV"/>.	6" format="default" sectionFormat="of" derivedContent="RFC8986"/>.
	Reserved bits MUST be zero when originated and MUST be ignored when	Supported behavior values for this sub-TLV are defined in <xref target=
	received.</t>	"ENDBEH" format="default" sectionFormat="of" derivedContent="Section 10"/> of th
	</list></t>	is document. Unsupported or unrecognized behavior values are
		ignored by the receiver.</dd>
	<t>Algorithm: 1 octet. As defined in IGP Algorithm Types registry <xref targ	<dt pn="section-8.2-4.15">SID:</dt>
	et="RFC8665"/>.</t>	<dd pn="section-8.2-4.16">16 octets. This field encodes the advertised
		SRv6 SID.</dd>
	<t>Weight: 1 octet. The value represents the weight of the	<dt pn="section-8.2-4.17">Sub-sub-TLV-length:</dt>
	SID for the purpose of load balancing. The use	<dd pn="section-8.2-4.18">1 octet. Number of octets used by sub-sub- T
	of the weight is defined in [RFC8402].</t>	LVs.</dd>
		<dt pn="section-8.2-4.19">Optional Sub-sub-TLVs:</dt>
	<t>Endpoint Behavior: 2 octets. As defined in <xref target="RFC8986"/>.	<dd pn="section-8.2-4.20">Supported sub-sub-TLVs are specified in
	Supported behavior values for this sub-TLV are defined in <xref target="ENDB	<xref target="SUBTLVREGISTRY" format="default" sectionFormat="of" deriv
	EH"/>	edContent="Section 11.6"/>. Any sub-sub-TLV that is not allowed in
	of this document. Unsupported or unrecognized behavior values are ignor	SRv6 LAN End.X SID sub-TLV <bcp14>MUST</bcp14> be ignored.</dd>
	ed	</dl>
	by the receiver.</t>	<t indent="0" pn="section-8.2-5">Note that multiple TLVs for the same ne
		ighbor, on the same LAN, may be
	<t>SID: 16 octets. This field encodes the advertised SRv6 SID.</t>

	<t>Sub-sub-TLV-length: 1 octet. Number of octets used by sub-sub-
	TLVs.</t>

	<t>Optional Sub-sub-TLVs: Supported Sub-sub-TLVs are specified in
	<xref target="SUBTLVREGISTRY"/>. Any Sub-sub-TLV that is not allowed in SR
	v6
	LAN End.X SID sub-TLV MUST be ignored.</t>

	</list></t>

	<t>Note that multiple TLVs for the same neighbor, on the same LAN, may be
	required in order to advertise all the SRv6 SIDs associated	required in order to advertise all the SRv6 SIDs associated
	with that neighbor.</t>	with that neighbor.</t>


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

		<section anchor="STRUCTTLV" numbered="true" toc="include" removeInRFC="false
	<section anchor="STRUCTTLV" title="SRv6 SID Structure Sub-Sub-TLV">	" pn="section-9">
		<name slugifiedName="name-srv6-sid-structure-sub-sub-">SRv6 SID Structure
	<t>SRv6 SID Structure Sub-Sub-TLV is an optional Sub-Sub-TLV of:	Sub-Sub-TLV</name>
	<list style="hanging">	<t indent="0" pn="section-9-1">The SRv6 SID Structure sub-sub-TLV is an op
	<t>SRv6 End SID Sub-TLV (<xref target="ENDTLV"/>)</t>	tional sub-sub-TLV of:</t>
		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-9-2
	<t>SRv6 End.X SID Sub-TLV (<xref target="ENDXTLV"/>)</t>	">
		<li pn="section-9-2.1">SRv6 End SID sub-TLV (<xref target="ENDTLV" forma
	<t>SRv6 LAN End.X SID Sub-TLV (<xref target="LANENDXTLV"/>)</t>	t="default" sectionFormat="of" derivedContent="Section 7.2"/>)</li>
	</list></t>	<li pn="section-9-2.2">SRv6 End.X SID sub-TLV (<xref target="ENDXTLV" fo
		rmat="default" sectionFormat="of" derivedContent="Section 8.1"/>)</li>
	<t>SRv6 SID Structure Sub-Sub-TLV is used to advertise the structure of the	<li pn="section-9-2.3">SRv6 LAN End.X SID sub-TLV (<xref target="LANENDX
	SRv6 SID	TLV" format="default" sectionFormat="of" derivedContent="Section 8.2"/>)</li>
	as defined in <xref target="RFC8986"/>. It has the following format:	</ul>
		<t indent="0" pn="section-9-3">The SRv6 SID Structure sub-sub-TLV is used
	<figure>	to advertise the structure of the SRv6 SID,
	<artwork>	as defined in <xref target="RFC8986" format="default" sectionFormat="of" d
		erivedContent="RFC8986"/>. It has the following format:</t>
		<artwork name="" type="" align="left" alt="" pn="section-9-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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| LB Length \| LN Length \| Fun. Length \| Arg. Length \|	\| LB Length \| LN Length \| Fun. Length \| Arg. Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		</artwork>
	where:	<dl newline="true" spacing="normal" indent="3" pn="section-9-5">
	</artwork>	<dt pn="section-9-5.1">where:</dt>
	</figure>	<dd pn="section-9-5.2">
	<list style="hanging">	<dl newline="false" spacing="normal" indent="3" pn="section-9-5.2.1">
	<t>Type: 1. Single octet as defined in section 9 of [ISO10589].</t>	<dt pn="section-9-5.2.1.1">Type:</dt>
		<dd pn="section-9-5.2.1.2">1. Single octet, as defined in Section 9
	<t>Length: Single octet as defined in section 9 of [ISO10589]. The l	of <xref target="ISO10589" format="default" sectionFormat="of" derivedContent="I
	ength	SO10589"/>.</dd>
	value is 4 octets.</t>	<dt pn="section-9-5.2.1.3">Length:</dt>
		<dd pn="section-9-5.2.1.4">Single octet, as defined in Section 9 of
	<t>LB Length: 1 octet. SRv6 SID Locator Block length in bits.</t>	<xref target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO1
		0589"/>.
	<t>LN Length: 1 octet. SRv6 SID Locator Node length in bits.</t>	The length value is 4 octets.</dd>
		<dt pn="section-9-5.2.1.5">LB Length:</dt>
	<t>Fun. Length: 1 octet. SRv6 SID Function length in bits.</t>	<dd pn="section-9-5.2.1.6">1 octet. SRv6 SID Locator Block length in
		bits.</dd>
	<t>Arg. Length: 1 octet. SRv6 SID Arguments length in bits.</t>	<dt pn="section-9-5.2.1.7">LN Length:</dt>
	</list></t>	<dd pn="section-9-5.2.1.8">1 octet. SRv6 SID Locator Node length in
		bits.</dd>
	<t>ISIS SRv6 SID Structure Sub-Sub-TLV MUST NOT appear more than once in its	<dt pn="section-9-5.2.1.9">Fun. Length:</dt>
	parent Sub-TLV.	<dd pn="section-9-5.2.1.10">1 octet. SRv6 SID Function length in bit
	If it appears more than once in its parent Sub-TLV, the parent Sub-TLV MUST	s.</dd>
	be ignored by	<dt pn="section-9-5.2.1.11">Arg. Length:</dt>
	the receiver.</t>	<dd pn="section-9-5.2.1.12">1 octet. SRv6 SID Arguments length in bi
		ts.</dd>
	<t>The sum of all four sizes advertised in ISIS SRv6 SID Structure Sub-Sub-T	</dl>
	LV MUST be	</dd>
	less than or equal to 128 bits. If the sum of all four sizes advertised in t	</dl>
	he ISIS SRv6	<t indent="0" pn="section-9-6">The IS-IS SRv6 SID Structure sub-sub-TLV <b
	SID Structure Sub-Sub-TLV is larger than 128 bits, the parent Sub-TLV MUST b	cp14>MUST NOT</bcp14> appear more than once in its parent
	e ignored	sub-TLV. If it appears more than once in its parent sub-TLV, the parent su
	by the receiver.</t>	b-TLV <bcp14>MUST</bcp14> be
		ignored by the receiver.</t>
	<t>The SRv6 SID Structure Sub-Sub-TLV is intended for informational use by t	<t indent="0" pn="section-9-7">The sum of all four sizes advertised in the
	he control and	IS-IS SRv6 SID Structure sub-sub-TLV <bcp14>MUST</bcp14>
	management planes. It MUST NOT be used at a transit node (as defined in	be less than or equal to 128 bits. If the sum of all four sizes advertised
	<xref target="RFC8754"/>) for forwarding packets. As an example, this inform	in the IS-IS SRv6
	ation	SID Structure sub-sub-TLV is larger than 128 bits, the parent sub-TLV <bcp
	could be used for:	14>MUST</bcp14> be ignored
		by the receiver.</t>
	<list style="symbols">	<t indent="0" pn="section-9-8">The SRv6 SID Structure sub-sub-TLV is inten
		ded for informational use by the control and
	<t>validation of SRv6 SIDs being instantiated in the network and	management planes. It <bcp14>MUST NOT</bcp14> be used at a transit node (a
	advertised via ISIS. These can be learnt by controllers via BGP-LS and the	s defined in
	n be	<xref target="RFC8754" format="default" sectionFormat="of" derivedContent=
	monitored for conformance to the SRv6 SID allocation scheme chosen by the	"RFC8754"/>) for forwarding packets. As an example, this information
	operator	could be used for the following:</t>
	as described in Section 3.2 of <xref target="RFC8986"/>.</t>	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9-9
		">
	<t>verification and the automation for securing the SRv6 domain by	<li pn="section-9-9.1">validation of SRv6 SIDs being instantiated in the
	provisioning filtering rules at SR domain boundaries as described	network and
	in Section 5 of <xref target="RFC8754"/>.</t>	advertised via IS-IS. These can be learned by controllers via Border Gate
		way Protocol - Link
	</list></t>	State (BGP-LS) and then be
		monitored for conformance to the SRv6 SID allocation scheme chosen by the
	<t>The details of these potential applications are outside the scope of	operator,
		as described in <xref target="RFC8986" section="3.2" sectionFormat="of" f
		ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc8986#section-3.2" der
		ivedContent="RFC8986"/>.</li>
		<li pn="section-9-9.2">verification and automation for securing the SRv6
		domain by
		provisioning filtering rules at SR domain boundaries, as described
		in <xref target="RFC8754" section="5" sectionFormat="of" format="defaul
		t" derivedLink="https://rfc-editor.org/rfc/rfc8754#section-5" derivedContent="RF
		C8754"/>.</li>
		</ul>
		<t indent="0" pn="section-9-10">The details of these potential application
		s are outside the scope of
	this document.</t>	this document.</t>


	</section>	</section>

		<section anchor="ENDBEH" numbered="true" toc="include" removeInRFC="false" p
	<section anchor="ENDBEH" title="Advertising Endpoint Behaviors">	n="section-10">
	<t>Endpoint behaviors are defined in	<name slugifiedName="name-advertising-endpoint-behavi">Advertising Endpoin
	<xref target="RFC8986"/>. The codepoints for the	t Behaviors</name>
		<t indent="0" pn="section-10-1">Endpoint behaviors are defined in
		<xref target="RFC8986" format="default" sectionFormat="of" derivedContent=
		"RFC8986"/>. The codepoints for the
	Endpoint behaviors are defined in the "SRv6 Endpoint Behaviors" registry d efined in	Endpoint behaviors are defined in the "SRv6 Endpoint Behaviors" registry d efined in

	<xref target="RFC8986"/>. If a behavior is advertised it MUST only be adve	<xref target="RFC8986" format="default" sectionFormat="of" derivedContent=
	rtised in the	"RFC8986"/>. If a behavior is advertised, it
	TLV[s] marked with "Y" in the table below, and MUST NOT be advertised in t	<bcp14>MUST</bcp14> only be advertised in the
	he	TLV(s) marked with "Y" in the table below and <bcp14>MUST NOT</bcp14> be a
	TLV[s] marked with "N" in the table below.</t>	dvertised in the
		TLV(s) marked with "N" in the table below.</t>
	<t><figure>	<table align="center" pn="table-1">
	<artwork><![CDATA[	<name slugifiedName="name-endpoint-behaviors">Endpoint Behaviors</name>
	Endpoint \|Endpoint \| End \| End.X \| Lan End.X \|	<thead>
	Behavior \|Behavior Codepoint\| SID \| SID \| SID \|	<tr>
	----------------------\|------------------\|-----\|-------\|-----------\|	<th align="left" colspan="1" rowspan="1">Endpoint Behavior</th>
	End (PSP, USP, USD)\| 1-4, 28-31 \| Y \| N \| N \|	<th align="left" colspan="1" rowspan="1">Endpoint Behavior Codepoint
	----------------------\|------------------\|-----\|-------\|-----------\|	</th>
	End.X (PSP, USP, USD)\| 5-8, 32-35 \| N \| Y \| Y \|	<th align="left" colspan="1" rowspan="1">End SID</th>
	----------------------\|------------------\|-----\|-------\|-----------\|	<th align="left" colspan="1" rowspan="1">End.X SID</th>
	End.DX6 \| 16 \| N \| Y \| Y \|	<th align="left" colspan="1" rowspan="1">Lan End.X SID</th>
	----------------------\|------------------\|-----\|-------\|-----------\|	</tr>
	End.DX4 \| 17 \| N \| Y \| Y \|	</thead>
	----------------------\|------------------\|-----\|-------\|-----------\|	<tbody>
	End.DT6 \| 18 \| Y \| N \| N \|	<tr>
	----------------------\|------------------\|-----\|-------\|-----------\|	<td align="left" colspan="1" rowspan="1">End (PSP, USP, USD)</td>
	End.DT4 \| 19 \| Y \| N \| N \|	<td align="left" colspan="1" rowspan="1">1-4, 28-31</td>
	----------------------\|------------------\|-----\|-------\|-----------\|	<td align="left" colspan="1" rowspan="1">Y</td>
	End.DT46 \| 20 \| Y \| N \| N \|	<td align="left" colspan="1" rowspan="1">N</td>
		<td align="left" colspan="1" rowspan="1">N</td>
	]]></artwork>	</tr>
	</figure></t>	<tr>
		<td align="left" colspan="1" rowspan="1">End.X (PSP, USP, USD)</td>
		<td align="left" colspan="1" rowspan="1">5-8, 32-35</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>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">End.DX6</td>
		<td align="left" colspan="1" rowspan="1">16</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>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">End.DX4</td>
		<td align="left" colspan="1" rowspan="1">17</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>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">End.DT6</td>
		<td align="left" colspan="1" rowspan="1">18</td>
		<td align="left" colspan="1" rowspan="1">Y</td>
		<td align="left" colspan="1" rowspan="1">N</td>
		<td align="left" colspan="1" rowspan="1">N</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">End.DT4</td>
		<td align="left" colspan="1" rowspan="1">19</td>
		<td align="left" colspan="1" rowspan="1">Y</td>
		<td align="left" colspan="1" rowspan="1">N</td>
		<td align="left" colspan="1" rowspan="1">N</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">End.DT46</td>
		<td align="left" colspan="1" rowspan="1">20</td>
		<td align="left" colspan="1" rowspan="1">Y</td>
		<td align="left" colspan="1" rowspan="1">N</td>
		<td align="left" colspan="1" rowspan="1">N</td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
	<section anchor="IANA" title="IANA Considerations">	"section-11">
	<t>This document requests allocation for the following TLVs, sub-TLVs,	<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	and sub-sub-TLVs as well as updating the ISIS TLV registry and defining	<t indent="0" pn="section-11-1">This document requests allocation for the
	new registries.</t>	following TLVs, sub-TLVs,
		and sub-sub-TLVs by updating the existing registries and defining
	<section title="SRv6 Locator TLV">	new registries under the "IS-IS TLV Codepoints" grouping.</t>
	<t>This document makes the following registrations in the IS-IS TLV Code	<section numbered="true" toc="include" removeInRFC="false" pn="section-11.
	points	1">
	registry.</t>	<name slugifiedName="name-srv6-locator-tlv">SRv6 Locator TLV</name>
		<t indent="0" pn="section-11.1-1">The SRv6 Locator TLV shares sub-TLV sp
	<t><figure>	ace with TLVs advertising prefix
	<artwork><![CDATA[	reachability. IANA has updated the "IS-IS Sub-TLVs for TLVs Advertising
	Type Description IIH LSP SNP Purge	Prefix Reachability" registry initially defined in <xref target="RFC7370
	---- --------------------- --- --- --- -----	" format="default" sectionFormat="of" derivedContent="RFC7370"/> by adding this
	27 SRv6 Locator TLV n y n n	document as a reference and updating the description of that registry to include
	]]></artwork>	the SRv6 Locator TLV (27).</t>
	</figure></t>	<t indent="0" pn="section-11.1-2">This document makes the following regi
		stration in the "IS-IS Top-Level TLV Codepoints"
	<section title="SRv6 End SID sub-TLV ">	registry:</t>
		<table align="center" pn="table-2">
	<t>The SRv6 Locator TLV shares sub-TLV space with TLVs 135, 235, 236 and	<name slugifiedName="name-is-is-top-level-tlv-codepoi">IS-IS Top-Level
	237.	TLV Codepoints Registry</name>
	This document updates the "Sub-TLVs for TLVs 135, 235,	<thead>
	236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, an	<tr>
	d	<th align="left" colspan="1" rowspan="1">Value</th>
	MT IPv6 IP. Reach TLVs)" registry defined in <xref target="RFC7370"/>.	<th align="left" colspan="1" rowspan="1">Name</th>
	IANA is requested to update the name of the "Sub-TLVs for TLVs 135, 235,	<th align="left" colspan="1" rowspan="1">IIH</th>
	236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, an	<th align="left" colspan="1" rowspan="1">LSP</th>
	d	<th align="left" colspan="1" rowspan="1">SNP</th>
	MT IPv6 IP. Reach TLVs)" registry to "Sub-TLVs for TLVs 27, 135, 235, 23	<th align="left" colspan="1" rowspan="1">Purge</th>
	6,	</tr>
	and 237 (SRv6 Locator, Extended IP reachability, MT IP. Reach, IPv6 IP.	</thead>
	Reach, and MT IPv6 IP. Reach TLVs)".</t>	<tbody>
		<tr>
	<t>IANA is asked to add this document as a reference to (renamed) "Sub-T	<td align="left" colspan="1" rowspan="1">27</td>
	LVs for	<td align="left" colspan="1" rowspan="1">SRv6 Locator</td>
	TLVs 27, 135, 235, 236, and 237 (SRv6 Locator, Extended IP reachability,	<td align="left" colspan="1" rowspan="1">n</td>
	MT IP.	<td align="left" colspan="1" rowspan="1">y</td>
	Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)" registry.</t>	<td align="left" colspan="1" rowspan="1">n</td>
		<td align="left" colspan="1" rowspan="1">n</td>
	<t>This document makes the following registrations in the (renamed)	</tr>
	"Sub-TLVs for TLVs 27, 135, 235, 236, and 237 (SRv6 Locator, Extended	</tbody>
	IP	</table>
	reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs	<section numbered="true" toc="include" removeInRFC="false" pn="section-1
	)" registry:	1.1.1">
	<list style="hanging">	<name slugifiedName="name-srv6-end-sid-sub-tlv-2">SRv6 End SID Sub-TLV
		</name>
	<t>Type: 5</t>	<t indent="0" pn="section-11.1.1-1">This document makes the following
		registration:</t>
	<t>Description: SRv6 End SID sub-TLV.</t>	<table align="center" pn="table-3">
		<name slugifiedName="name-is-is-sub-tlvs-for-tlvs-adv">IS-IS Sub-TLV
	<t>Reference: This document (<xref target="ENDTLV"/>).</t>	s for TLVs Advertising Prefix Reachability Registry</name>
	</list></t>	<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">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">5</td>
		<td align="left" colspan="1" rowspan="1">SRv6 End SID</td>
		<td align="left" colspan="1" rowspan="1">y</td>
		<td align="left" colspan="1" rowspan="1">n</td>
		<td align="left" colspan="1" rowspan="1">n</td>
		<td align="left" colspan="1" rowspan="1">n</td>
		<td align="left" colspan="1" rowspan="1">n</td>
		<td align="left" colspan="1" rowspan="1">RFC 9352, <xref target=
		"ENDTLV" format="default" sectionFormat="of" derivedContent="Section 7.2"/></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="REVISEDREG" numbered="true" toc="include" removeInRFC="
	<section anchor="REVISEDREG" title="Revised sub-TLV table">	false" pn="section-11.1.2">
	<t>The revised table of sub-TLVs for the (renamed) "Sub-TLVs for TLVs	<name slugifiedName="name-is-is-sub-tlvs-for-tlvs-adve">IS-IS Sub-TLVs
	27,	for TLVs Advertising Prefix Reachability Registry</name>
	135, 235, 236, and 237 (SRv6 Locator, Extended IP reachability, MT IP.	<t indent="0" pn="section-11.1.2-1">IANA has updated the "IS-IS Sub-TL
	Reach,	Vs for TLVs Advertising Prefix Reachability" registry to include a column for th
	IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)" registry is shown below:<	e SRv6 Locator TLV (27) as shown below:</t>
	/t>	<table anchor="revised_sub-TLVs" align="center" pn="table-4">
		<name slugifiedName="name-is-is-sub-tlvs-for-tlvs-adver">IS-IS Sub-T
	<t><figure>	LVs for TLVs Advertising Prefix Reachability Registry</name>
	<artwork><![CDATA[ Type 27 135 235 236 237	<thead>
		<tr>
	1 y y y y y	<th align="left" colspan="1" rowspan="1">Type</th>
	2 y y y y y	<th align="left" colspan="1" rowspan="1">Description</th>
	3 n y y y y	<th align="left" colspan="1" rowspan="1">27</th>
	4 y y y y y	<th align="left" colspan="1" rowspan="1">135</th>
	5 y n n n n	<th align="left" colspan="1" rowspan="1">235</th>
	6 n y y y y	<th align="left" colspan="1" rowspan="1">236</th>
	11 y y y y y	<th align="left" colspan="1" rowspan="1">237</th>
	12 y y y y y	</tr>
	32 n y y y y	</thead>
	]]></artwork>	<tbody>
	</figure></t>	<tr>
		<td align="left" colspan="1" rowspan="1">1</td>
		<td align="left" colspan="1" rowspan="1">32-bit Administrative T
		ag Sub-TLV</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">y</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">2</td>
		<td align="left" colspan="1" rowspan="1">64-bit Administrative T
		ag Sub-TLV</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">y</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">3</td>
		<td align="left" colspan="1" rowspan="1">Prefix Segment Identifi
		er</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>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">4</td>
		<td align="left" colspan="1" rowspan="1">Prefix Attribute Flags<
		/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">y</td>
		</tr>
		<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>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">11</td>
		<td align="left" colspan="1" rowspan="1">IPv4 Source Router ID</
		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">y</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">12</td>
		<td align="left" colspan="1" rowspan="1">IPv6 Source Router ID</
		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">y</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">32</td>
		<td align="left" colspan="1" rowspan="1">BIER Info</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>
		</tr>
		</tbody>
		</table>
	</section>	</section>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-11.
	<section title="SRv6 Capabilities sub-TLV">	2">
	<t>This document makes the following registrations in the "Sub-TLVs for	<name slugifiedName="name-srv6-capabilities-sub-tlv-2">SRv6 Capabilities
	TLV 242	Sub-TLV</name>
	(IS-IS Router CAPABILITY TLV)":	<t indent="0" pn="section-11.2-1">This document makes the following regi
		stration in the "IS-IS Sub-TLVs for IS-IS
	<list style="hanging">	Router CAPABILITY TLV" registry:</t>
		<table align="center" pn="table-5">
	<t>Type: 25</t>	<name slugifiedName="name-is-is-sub-tlvs-for-is-is-ro">IS-IS Sub-TLVs
		for IS-IS Router CAPABILITY TLV Registry</name>
	<t>Description: SRv6 Capabilities sub-TLV.</t>	<thead>
		<tr>
	<t>Reference: This document (<xref target="SRV6CAP"/>).</t>	<th align="left" colspan="1" rowspan="1">Value</th>
	</list></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">25</td>
		<td align="left" colspan="1" rowspan="1">SRv6 Capabilities</td>
		<td align="left" colspan="1" rowspan="1">RFC 9352, <xref target="S
		RV6CAP" format="default" sectionFormat="of" derivedContent="Section 2"/></td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-11.
	<section title="Sub-Sub-TLVs of the SRv6 Capability sub-TLV">	3">
		<name slugifiedName="name-is-is-sub-sub-tlvs-for-the-">IS-IS Sub-Sub-TLV
	<t>This document requests a new IANA registry be created under the	s for the SRv6 Capabilities Sub-TLV Registry</name>
	IS-IS TLV Codepoints Registry to control the assignment of sub-TLV	<t indent="0" pn="section-11.3-1">IANA has created the "IS-IS Sub-Sub-TL
	types for the SRv6 Capability sub-TLV specified in this document -	Vs for SRv6 Capabilities Sub-TLV" registry under the
	<xref target="SRV6CAP"/>. The suggested name of the	"IS-IS TLV Codepoints" grouping for the assignment of sub-TLV
	new registry is "sub-sub-TLVs of the SRv6 Capability sub-TLV".	types for the SRv6 Capabilities sub-TLV specified in this document (<xre
	The registration procedure is "Expert Review" as defined in	f target="SRV6CAP" format="default" sectionFormat="of" derivedContent="Section 2
	<xref target="RFC8126"/>. Guidance for the Designated Experts is provid	"/>). This registry defines sub-sub-TLVs for the SRv6
	ed in	Capabilities sub-TLV (25) advertised in the IS-IS Router
	the <xref target="RFC7370"/>. No sub-sub-TLVs are defined by this docum	CAPABILITY TLV (242).</t>
	ent	<t indent="0" pn="section-11.3-2"> The registration procedure is "Expert
	except for the reserved type 0.</t>	Review", as defined in <xref target="RFC8126" format="default" sectionFormat="o
		f" derivedContent="RFC8126"/>. Guidance for the designated
	<t><figure>	experts is provided in <xref target="RFC7370" format="default" sectionFor
	<artwork><![CDATA[ Type Description Encod	mat="of" derivedContent="RFC7370"/>.
	ing	No sub-sub-TLVs are defined by this document, except for
	Reference	the reserved type 0.</t>
	0 Reserved	<table align="center" pn="table-6">
	1-255 Unassigned	<name slugifiedName="name-is-is-sub-sub-tlvs-for-srv6">IS-IS Sub-Sub-T
	]]></artwork>	LVs for SRv6 Capabilities Sub-TLV Registry</name>
	</figure></t>	<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">0</td>
		<td align="left" colspan="1" rowspan="1">Reserved</td>
		<td align="left" colspan="1" rowspan="1">RFC 9532</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">1-255</td>
		<td align="left" colspan="1" rowspan="1">Unassigned</td>
		<td align="left" colspan="1" rowspan="1"/>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-11.
	<section title="SRv6 End.X SID and SRv6 LAN End.X SID sub-TLVs">	4">
	<t>This document makes the following registrations in the	<name slugifiedName="name-srv6-endx-sid-and-srv6-lan-">SRv6 End.X SID an
	"Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachabili	d SRv6 LAN End.X SID Sub-TLVs</name>
	ty,	<t indent="0" pn="section-11.4-1">This document makes the following regi
	IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachabili	strations in the
	ty	"IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry:</t>
	information, MT-ISN, and MT IS Neighbor Attribute TLVs)" registry:	<table align="center" pn="table-7">
		<name slugifiedName="name-is-is-sub-tlvs-for-tlvs-advert">IS-IS Sub-TL
	<list style="hanging">	Vs for TLVs Advertising Neighbor Information Registry</name>
		<thead>
	<t>Type: 43</t>	<tr>
		<th align="left" colspan="1" rowspan="1">Type</th>
	<t>Description: SRv6 End.X SID sub-TLV.</t>	<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">22</th>
	<t>Reference: This document (<xref target="ENDXTLV"/>).</t>	<th align="left" colspan="1" rowspan="1">23</th>
		<th align="left" colspan="1" rowspan="1">25</th>
	<t>Type: 44</t>	<th align="left" colspan="1" rowspan="1">141</th>
		<th align="left" colspan="1" rowspan="1">222</th>
	<t>Description: SRv6 LAN End.X SID sub-TLV.</t>	<th align="left" colspan="1" rowspan="1">223</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
	<t>Reference: This document (<xref target="LANENDXTLV"/>).</t>	</tr>
	</list></t>	</thead>
		<tbody>
	<t><figure>	<tr>
	<artwork><![CDATA[ Type 22 23 25 141 222 223	<td align="left" colspan="1" rowspan="1">43</td>
		<td align="left" colspan="1" rowspan="1">SRv6 End.X SID</td>
	43 y y y y y y	<td align="left" colspan="1" rowspan="1">y</td>
	44 y y y y y y	<td align="left" colspan="1" rowspan="1">y</td>
		<td align="left" colspan="1" rowspan="1">y</td>
	]]></artwork>	<td align="left" colspan="1" rowspan="1">y</td>
	</figure></t>	<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 9352, <xref target="E
		NDXTLV" format="default" sectionFormat="of" derivedContent="Section 8.1"/></td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">44</td>
		<td align="left" colspan="1" rowspan="1">SRv6 LAN End.X SID</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">y</td>
		<td align="left" colspan="1" rowspan="1">y</td>
		<td align="left" colspan="1" rowspan="1">RFC 9352, <xref target="L
		ANENDXTLV" format="default" sectionFormat="of" derivedContent="Section 8.2"/></t
		d>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-11.
	<section title="MSD Types">	5">
	<t>This document makes the following registrations in the IGP MSD-Types	<name slugifiedName="name-msd-types">MSD Types</name>
		<t indent="0" pn="section-11.5-1">This document makes the following regi
		strations in the "IGP MSD-Types"
	registry:</t>	registry:</t>

		<table align="center" pn="table-8">
	<t><figure>	<name slugifiedName="name-igp-msd-types">IGP MSD-Types</name>
	<artwork><![CDATA[Value Name Reference	<thead>
	41 SRH Max SL [This Document]	<tr>
	42 SRH Max End Pop [This Document]	<th align="left" colspan="1" rowspan="1">Value</th>
	44 SRH Max H.encaps [This Document]	<th align="left" colspan="1" rowspan="1">Name</th>
	45 SRH Max End D [This Document]]]></artwork>	<th align="left" colspan="1" rowspan="1">Reference</th>
	</figure></t>	</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left" colspan="1" rowspan="1">41</td>
		<td align="left" colspan="1" rowspan="1">SRH Max SL</td>
		<td align="left" colspan="1" rowspan="1">RFC 9352</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">42</td>
		<td align="left" colspan="1" rowspan="1">SRH Max End Pop</td>
		<td align="left" colspan="1" rowspan="1">RFC 9352</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">44</td>
		<td align="left" colspan="1" rowspan="1">SRH Max H.encaps</td>
		<td align="left" colspan="1" rowspan="1">RFC 9352</td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">45</td>
		<td align="left" colspan="1" rowspan="1">SRH Max End D</td>
		<td align="left" colspan="1" rowspan="1">RFC 9352</td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="SUBTLVREGISTRY" numbered="true" toc="include" removeInRFC
	<section anchor="SUBTLVREGISTRY" title="Sub-Sub-TLVs for SID Sub-TLVs">	="false" pn="section-11.6">
		<name slugifiedName="name-is-is-sub-sub-tlvs-for-srv6-">IS-IS Sub-Sub-TL
	<t>This document requests a new IANA registry be created under the	Vs for SRv6 SID Sub-TLVs Registry</name>
	IS-IS TLV Codepoints Registry to control the assignment of sub-TLV	<t indent="0" pn="section-11.6-1">IANA has created the "IS-IS Sub-Sub-TL
	types for the SID Sub-TLVs specified in this document - <xref target="ENDT	Vs for SRv6 SID Sub-TLVs" registry under the
	LV"/>,	"IS-IS TLV Codepoints" grouping to assign sub-TLV
	<xref target="ENDXTLV"/>, <xref target="LANENDXTLV"/>. The suggested name	types for the SID sub-TLVs specified in this document (Sections
	of the	<xref target="ENDTLV" format="counter" sectionFormat="of" derivedContent=
	new registry is "sub-sub-TLVs for SRv6 End SID and SRv6 End.X SID". The re	"7.2"/>, <xref target="ENDXTLV" format="counter" sectionFormat="of" derivedConte
	gistration	nt="8.1"/>, and <xref target="LANENDXTLV" format="counter" sectionFormat="of" de
	procedure is "Expert Review" as defined in <xref target="RFC8126"/>. Guid	rivedContent="8.2"/>). </t>
	ance for the	<t indent="0" pn="section-11.6-2">
	Designated Experts is provided in <xref target="RFC7370"/>. The following	This registry defines sub-sub-TLVs for SRv6 SID sub-TLVs. This include
	assignments are made by this document:</t>	s the following sub-TLVs:</t>
		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1
	<t><figure>	1.6-3">
	<artwork><![CDATA[ Type Description Encod	<li pn="section-11.6-3.1">SRv6 End SID (5) (Advertised in SRv6 Locator
	ing	TLV (27))</li>
	Reference	<li pn="section-11.6-3.2">SRv6 End.X SID (43) (Advertised in TLVs adve
	0 Reserved	rtising neighbor
	1 SRv6 SID Structure Sub-Sub-TLV [This Document]	information)</li>
	2-255 Unassigned	<li pn="section-11.6-3.3">SRv6 LAN End.X SID (44) (Advertised in TLVs
		advertising
	Type 5 43 44	neighbor information)</li>
		</ul>
	1 y y y	<t indent="0" pn="section-11.6-4">The registration procedure is "Expert
		Review", as defined in <xref target="RFC8126" format="default" sectionFormat="of
	]]></artwork>	" derivedContent="RFC8126"/>. Guidance for the designated experts is provided in
	</figure></t>	<xref target="RFC7370" format="default" sectionFormat="of" derivedContent="RFC7
		370"/>. The following
	</section>	assignments are made by this document:</t>
		<table align="center" pn="table-9">
	<section anchor="ANYCASTBIT" title="Prefix Attribute Flags Sub-TLV">	<name slugifiedName="name-is-is-sub-sub-tlvs-for-srv6-s">IS-IS Sub-Sub
		-TLVs for SRv6 SID Sub-TLVs Registry</name>
	<t>This document adds a new bit in the "Bit Values for Prefix Attribute Flags	<thead>
	Sub-TLV" registry:	<tr>
		<th align="left" colspan="1" rowspan="1">Type</th>
	<list style="hanging">	<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">5</th>
	<t>Bit #: 4</t>	<th align="left" colspan="1" rowspan="1">43</th>
		<th align="left" colspan="1" rowspan="1">44</th>
	<t>Description: Anycast Flag (A-flag)</t>	<th align="left" colspan="1" rowspan="1">Reference</th>
		</tr>
	<t>Reference: This document (<xref target="ANYCASTFLAG"/>).</t>	</thead>
		<tbody>
	</list></t>	<tr>
		<td align="left" colspan="1" rowspan="1">0</td>
	</section>	<td align="left" colspan="1" rowspan="1">Reserved</td>
		<td align="left" colspan="1" rowspan="1"/>
	<section anchor="FLAGREGCAP" title="ISIS SRv6 Capabilities sub-TLV Flags Regi	<td align="left" colspan="1" rowspan="1"/>
	stry">	<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1">RFC 9352</td>
	<t>This document requests a new IANA registry be created under the IS-IS TLV	</tr>
	Codepoints Registry to control the assignment of bits 0 to 15 in the Flags f	<tr>
	ield of the	<td align="left" colspan="1" rowspan="1">1</td>
	ISIS SRv6 Capabilities sub-TLV specified in this document (<xref target="SRV	<td align="left" colspan="1" rowspan="1">SRv6 SID Structure</td>
	6CAP"/>).	<td align="left" colspan="1" rowspan="1">y</td>
	The suggested name of the new registry is "ISIS SRv6 Capabilities sub-TLV Fl	<td align="left" colspan="1" rowspan="1">y</td>
	ags".	<td align="left" colspan="1" rowspan="1">y</td>
	The registration procedure is "Expert Review" as defined in <xref target="R	<td align="left" colspan="1" rowspan="1">RFC 9352</td>
	FC8126"/>.	</tr>
	Guidance for the Designated Experts is provided in <xref target="RFC7370"/>.	<tr>
	The	<td align="left" colspan="1" rowspan="1">2-255</td>
	following assignments are made by this document:	<td align="left" colspan="1" rowspan="1">Unassigned</td>
		<td align="left" colspan="1" rowspan="1"/>
	<list style="hanging">	<td align="left" colspan="1" rowspan="1"/>
		<td align="left" colspan="1" rowspan="1"/>
	<t>Bit #: 1</t>	<td align="left" colspan="1" rowspan="1"/>
		</tr>
	<t>Description: O-flag</t>	</tbody>
		</table>
	<t>Reference: This document (<xref target="SRV6CAP"/>).</t>	</section>
		<section anchor="ANYCASTBIT" numbered="true" toc="include" removeInRFC="fa
	<t>Bit #: 0, 2-7</t>	lse" pn="section-11.7">
		<name slugifiedName="name-prefix-attribute-flags-sub-">Prefix Attribute
	<t>Description: Unassigned</t>	Flags Sub-TLV</name>
		<t indent="0" pn="section-11.7-1">This document adds a new bit in the "I
	</list></t>	S-IS Bit Values for Prefix Attribute Flags
		Sub-TLV" registry:</t>
	</section>	<table align="center" pn="table-10">
		<name slugifiedName="name-is-is-bit-values-for-prefix">IS-IS Bit Value
	<section anchor="FLAGREGLOC" title="ISIS SRv6 Locator TLV Flags Registry">	s for Prefix Attribute Flags Sub-TLV Registry</name>
		<thead>
	<t>This document requests a new IANA registry be created under the IS-IS TLV	<tr>
	Codepoints Registry to control the assignment of bits 0 to 7 in the Flags fi	<th align="left" colspan="1" rowspan="1">Bit #</th>
	eld of the	<th align="left" colspan="1" rowspan="1">Name</th>
	ISIS SRv6 Locator TLV specified in this document (<xref target="LOCTLV"/>).	<th align="left" colspan="1" rowspan="1">Reference</th>
	The suggested name of the new registry is "ISIS SRv6 Locator TLV Flags".	</tr>
	The registration procedure is "Expert Review" as defined in <xref target="RF	</thead>
	C8126"/>.	<tbody>
	Guidance for the Designated Experts is provided in <xref target="RFC7370"/>.	<tr>
	The	<td align="left" colspan="1" rowspan="1">4</td>
	following assignments are made by this document:	<td align="left" colspan="1" rowspan="1">Anycast Flag (A-flag)</td
		>
	<list style="hanging">	<td align="left" colspan="1" rowspan="1">RFC 9352, <xref target="A
		NYCASTFLAG" format="default" sectionFormat="of" derivedContent="Section 6"/></td
	<t>Bit #: 0</t>	>
		</tr>
	<t>Description: D-flag</t>	</tbody>
		</table>
	<t>Reference: This document (<xref target="LOCTLV"/>).</t>	</section>
		<section anchor="FLAGREGCAP" numbered="true" toc="include" removeInRFC="fa
	<t>Bit #: 1-7</t>	lse" pn="section-11.8">
		<name slugifiedName="name-is-is-srv6-capabilities-sub">IS-IS SRv6 Capabi
	<t>Description: Unassigned</t>	lities Sub-TLV Flags Registry</name>
		<t indent="0" pn="section-11.8-1">IANA has created the "IS-IS SRv6 Capab
	</list></t>	ilities Sub-TLV Flags" registry under the "IS-IS TLV
		Codepoints" grouping to assign bits 0 to 15 in the Flags field of the
	</section>	IS-IS SRv6 Capabilities sub-TLV specified in this document (<xref target=
		"SRV6CAP" format="default" sectionFormat="of" derivedContent="Section 2"/>). Thi
	<section anchor="FLAGREGEND" title="ISIS SRv6 End SID sub-TLV Flags Registry"	s registry defines bit values advertised in the
	>	Flags field of the SRv6 Capabilities sub-TLV (25). This sub-TLV
		is advertised in the IS-IS Router CAPABILITY TLV (242).
	<t>This document requests a new IANA registry be created under the IS-IS TLV	</t>
	Codepoints Registry to control the assignment of bits 0 to 7 in the Flags fi	<t indent="0" pn="section-11.8-2">The registration procedure is "Expert
	eld of the	Review", as defined in
	ISIS SRv6 End SID sub-TLV specified in this document (<xref target="ENDTLV"/	<xref target="RFC8126" format="default" sectionFormat="of" derivedContent
	>).	="RFC8126"/>. Guidance for the designated
	The suggested name of the new registry is "ISIS SRv6 End SID sub-TLV Flags".	experts is provided in <xref target="RFC7370" format="default" sectionFor
	The registration procedure is "Expert Review" as defined in <xref target="RF	mat="of" derivedContent="RFC7370"/>.
	C8126"/>.	The following assignments are made by this document:</t>
	Guidance for the Designated Experts is provided in <xref target="RFC7370"/>.	<table align="center" pn="table-11">
	No	<name slugifiedName="name-is-is-srv6-capabilities-sub-">IS-IS SRv6 Cap
	assignments are made by this document.	abilities Sub-TLV Flags Registry</name>
		<thead>
	<list style="hanging">	<tr>
		<th align="left" colspan="1" rowspan="1">Type</th>
	<t>Bit #: 0-7</t>	<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
	<t>Description: Unassigned</t>	</tr>
		</thead>
	</list></t>	<tbody>
		<tr>
	</section>	<td align="left" colspan="1" rowspan="1">0</td>
		<td align="left" colspan="1" rowspan="1">Unassigned</td>
	<section anchor="FLAGENDX" title="ISIS SRv6 End.X SID and LAN End.X SID sub-T	<td align="left" colspan="1" rowspan="1"/>
	LVs Flags Registry">	</tr>
		<tr>
	<t>This document requests a new IANA registry be created under the IS-IS TLV	<td align="left" colspan="1" rowspan="1">1</td>
	Codepoints Registry to control the assignment of bits 0 to 7 in the Flags fi	<td align="left" colspan="1" rowspan="1">O-flag</td>
	eld of the	<td align="left" colspan="1" rowspan="1">RFC 9352, <xref target="S
	ISIS SRv6 End.X SID and LAN End.X SID sub-TLVs (<xref target="ENDXTLV"/> and	RV6CAP" format="default" sectionFormat="of" derivedContent="Section 2"/></td>
	<xref target="LANENDXTLV"/>). The suggested name of the new registry is	</tr>
	"ISIS SRv6 End.X SID and LAN End.X SID sub-TLVs Flags". The registration pro	<tr>
	cedure	<td align="left" colspan="1" rowspan="1">2-15</td>
	is "Expert Review" as defined in <xref target="RFC8126"/>. Guidance for the	<td align="left" colspan="1" rowspan="1">Unassigned</td>
	Designated	<td align="left" colspan="1" rowspan="1"/>
	Experts is provided in <xref target="RFC7370"/>. The following assignments a	</tr>
	re made	</tbody>
	by this document:	</table>
		</section>
	<list style="hanging">	<section anchor="FLAGREGLOC" numbered="true" toc="include" removeInRFC="fa
		lse" pn="section-11.9">
	<t>Bit #: 0</t>	<name slugifiedName="name-is-is-srv6-locator-tlv-flag">IS-IS SRv6 Locato
		r TLV Flags Registry</name>
	<t>Description: B-flag</t>	<t indent="0" pn="section-11.9-1">IANA has created the "IS-IS SRv6 Locat
		or TLV Flags" registry under the "IS-IS TLV
	<t>Reference: This document (<xref target="ENDXTLV"/>).</t>	Codepoints" grouping to assign bits 0 to 7 in the Flags field of the
		SRv6 Locator TLV specified in this document (<xref target="LOCTLV" format
	<t>Bit #: 1</t>	="default" sectionFormat="of" derivedContent="Section 7.1"/>). This registry def
		ines bit values advertised in the
	<t>Description: S-flag</t>	Flags field of the SRv6 Locator TLV (27). </t>
		<t indent="0" pn="section-11.9-2">The registration procedure is "Expert
	<t>Reference: This document (<xref target="ENDXTLV"/>).</t>	Review", as defined in
		<xref target="RFC8126" format="default" sectionFormat="of" derivedContent
	<t>Bit #: 2</t>	="RFC8126"/>. Guidance for the designated
		experts is provided in <xref target="RFC7370" format="default" sectionFor
	<t>Description: P-flag</t>	mat="of" derivedContent="RFC7370"/>. The following
		assignments are made by this document:</t>
	<t>Reference: This document (<xref target="ENDXTLV"/>).</t>	<table align="center" pn="table-12">
		<name slugifiedName="name-is-is-srv6-locator-tlv-flags">IS-IS SRv6 Loc
	<t>Bit #: 3-7</t>	ator TLV Flags Registry</name>
		<thead>
	<t>Description: Unassigned</t>	<tr>
		<th align="left" colspan="1" rowspan="1">Value</th>
	</list></t>	<th align="left" colspan="1" rowspan="1">Description</th>
		<th align="left" colspan="1" rowspan="1">Reference</th>
	</section>	</tr>
		</thead>
	</section>	<tbody>
		<tr>
	<section anchor="Security" title="Security Considerations">	<td align="left" colspan="1" rowspan="1">0</td>
		<td align="left" colspan="1" rowspan="1">D-flag</td>
	<t>Security concerns for IS-IS are addressed in <xref target="ISO10589"/>,	<td align="left" colspan="1" rowspan="1">RFC 9352, <xref target="L
	<xref target="RFC5304"/>, and <xref target="RFC5310"/>. While IS-IS is dep	OCTLV" format="default" sectionFormat="of" derivedContent="Section 7.1"/></td>
	loyed	</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">1-7</td>
		<td align="left" colspan="1" rowspan="1">Unassigned</td>
		<td align="left" colspan="1" rowspan="1"/>
		</tr>
		</tbody>
		</table>
		</section>
		<section anchor="FLAGREGEND" numbered="true" toc="include" removeInRFC="fa
		lse" pn="section-11.10">
		<name slugifiedName="name-is-is-srv6-end-sid-sub-tlv-">IS-IS SRv6 End SI
		D Sub-TLV Flags Registry</name>
		<t indent="0" pn="section-11.10-1">IANA has created the "IS-IS SRv6 End
		SID Sub-TLV Flags" registry under the "IS-IS TLV
		Codepoints" grouping to assign bits 0 to 7 in the Flags field of the
		IS-IS SRv6 End SID sub-TLV specified in this document (<xref target="ENDT
		LV" format="default" sectionFormat="of" derivedContent="Section 7.2"/>). This re
		gistry defines bit values advertised in the
		Flags field of the SRv6 End SID sub-TLV (5), which is advertised in
		the SRv6 Locator TLV (27). </t>
		<t indent="0" pn="section-11.10-2">The registration procedure is "Expert
		Review", as defined in
		<xref target="RFC8126" format="default" sectionFormat="of" derivedContent
		="RFC8126"/>. Guidance for the designated
		experts is provided in <xref target="RFC7370" format="default" sectionFor
		mat="of" derivedContent="RFC7370"/>.
		No assignments are made by this document.</t>
		<table align="center" pn="table-13">
		<name slugifiedName="name-is-is-srv6-end-sid-sub-tlv-f">IS-IS SRv6 End
		SID Sub-TLV Flags 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">0-7</td>
		<td align="left" colspan="1" rowspan="1">Unassigned</td>
		<td align="left" colspan="1" rowspan="1"/>
		</tr>
		</tbody>
		</table>
		</section>
		<section anchor="FLAGENDX" numbered="true" toc="include" removeInRFC="fals
		e" pn="section-11.11">
		<name slugifiedName="name-is-is-srv6-adjacency-sid-su">IS-IS SRv6 Adjace
		ncy SID Sub-TLVs Flags Registry</name>
		<t indent="0" pn="section-11.11-1">IANA has created the "IS-IS SRv6 Adja
		cency SID Sub-TLVs Flags" registry under the "IS-IS TLV
		Codepoints" grouping to assign bits 0 to 7 in the Flags field of the
		IS-IS SRv6 End.X SID and LAN End.X SID sub-TLVs (Sections <xref target="E
		NDXTLV" format="counter" sectionFormat="of" derivedContent="8.1"/> and <xref tar
		get="LANENDXTLV" format="counter" sectionFormat="of" derivedContent="8.2"/>).</t
		>
		<t indent="0" pn="section-11.11-2">This registry defines bit values adve
		rtised in the
		Flags field of SRv6 SID sub-TLVs associated with adjacencies.
		These sub-TLVs are advertised in TLVs advertising neighbor
		information. The list of sub-TLVs includes:</t>
		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1
		1.11-3">
		<li pn="section-11.11-3.1">SRv6 End.X SID (43)</li>
		<li pn="section-11.11-3.2">SRv6 LAN End.X SID (44)</li>
		</ul>
		<t indent="0" pn="section-11.11-4">The registration procedure is "Expert
		Review", as defined in <xref target="RFC8126" format="default" sectionFormat="o
		f" derivedContent="RFC8126"/>. Guidance for the designated experts is provided i
		n <xref target="RFC7370" format="default" sectionFormat="of" derivedContent="RFC
		7370"/>. The
		following assignments are made by this document:</t>
		<table align="center" pn="table-14">
		<name slugifiedName="name-is-is-srv6-adjacency-sid-sub">IS-IS SRv6 Adj
		acency SID Sub-TLVs Flags 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">0</td>
		<td align="left" colspan="1" rowspan="1">B-flag</td>
		<td align="left" colspan="1" rowspan="1">RFC 9352, <xref target="E
		NDXTLV" format="default" sectionFormat="of" derivedContent="Section 8.1"/></td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">1</td>
		<td align="left" colspan="1" rowspan="1">S-flag</td>
		<td align="left" colspan="1" rowspan="1">RFC 9352, <xref target="E
		NDXTLV" format="default" sectionFormat="of" derivedContent="Section 8.1"/></td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">2</td>
		<td align="left" colspan="1" rowspan="1">P-flag</td>
		<td align="left" colspan="1" rowspan="1">RFC 9352, <xref target="E
		NDXTLV" format="default" sectionFormat="of" derivedContent="Section 8.1"/></td>
		</tr>
		<tr>
		<td align="left" colspan="1" rowspan="1">3-7</td>
		<td align="left" colspan="1" rowspan="1">Unassigned</td>
		<td align="left" colspan="1" rowspan="1"/>
		</tr>
		</tbody>
		</table>
		</section>
		</section>
		<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
		pn="section-12">
		<name slugifiedName="name-security-considerations">Security Considerations
		</name>
		<t indent="0" pn="section-12-1">Security concerns for IS-IS are addressed
		in <xref target="ISO10589" format="default" sectionFormat="of" derivedContent="I
		SO10589"/>,
		<xref target="RFC5304" format="default" sectionFormat="of" derivedContent=
		"RFC5304"/>, and <xref target="RFC5310" format="default" sectionFormat="of" deri
		vedContent="RFC5310"/>. While IS-IS is deployed
	under a single administrative domain, there can be deployments where poten tial	under a single administrative domain, there can be deployments where poten tial
	attackers have access to one or more networks in the IS-IS routing domain.	attackers have access to one or more networks in the IS-IS routing domain.
	In these deployments, the stronger authentication mechanisms defined in th e	In these deployments, the stronger authentication mechanisms defined in th e

	aforementioned documents SHOULD be used.</t>	aforementioned documents <bcp14>SHOULD</bcp14> be used.</t>
		<t indent="0" pn="section-12-2">This document describes the IS-IS extensio
	<t>This document describes the IS-IS extensions required to support Segmen	ns required to support SR over an IPv6 data plane. The security considerations
	t	for SR are discussed in <xref target="RFC8402" format="default" sectionFormat="o
	Routing over an IPv6 data plane. The security considerations for Segment	f" derivedContent="RFC8402"/>. <xref target="RFC8986" format="default" sectionF
	Routing are discussed in <xref target="RFC8402"/>. <xref target="RFC8986"	ormat="of" derivedContent="RFC8986"/>
	/>
	defines the SRv6 Network Programming concept and specifies the main	defines the SRv6 Network Programming concept and specifies the main

	Segment Routing behaviors to enable the creation of interoperable overlays ;	SR behaviors to enable the creation of interoperable overlays;
	the security considerations from that document apply too.</t>	the security considerations from that document apply too.</t>

		<t indent="0" pn="section-12-3">The advertisement for an incorrect MSD val
	<t>The advertisement for an incorrect MSD value may have negative	ue may have negative
	consequences, see <xref target="RFC8491"/> for additional considerations.<	consequences; see <xref target="RFC8491" format="default" sectionFormat="o
	/t>	f" derivedContent="RFC8491"/> for additional considerations.</t>
		<t indent="0" pn="section-12-4">Security concerns associated with the sett
	<t>Security concerns associated with the setting of the O-flag are describ	ing of the O-flag are described in
	ed in	<xref target="RFC9259" format="default" sectionFormat="of" derivedContent=
	<xref target="I-D.ietf-6man-spring-srv6-oam"/>.</t>	"RFC9259"/>.</t>
		<t indent="0" pn="section-12-5">Security concerns associated with the usag
	<t>Security concerns associated with the usage of Flex-Algorithms are desc	e of Flexible Algorithms are described in
	ribed in	<xref target="RFC9350" format="default" sectionFormat="of" derivedContent=
	<xref target="I-D.ietf-lsr-flex-algo"/>).</t>	"RFC9350"/>).</t>

	</section>

	<section anchor="CONTRIB" title="Contributors">
	<t>The following people gave a substantial contribution to the content
	of this document and should be considered as co-authors:</t>

	<t><figure>
	<artwork><![CDATA[ Stefano Previdi
	Huawei Technologies
	Email: stefano@previdi.net

	Paul Wells
	Cisco Systems
	Saint Paul,
	Minnesota
	United States
	Email: pauwells@cisco.com

	Daniel Voyer
	Email: daniel.voyer@bell.ca

	Satoru Matsushima
	Email: satoru.matsushima@g.softbank.co.jp

	Bart Peirens
	Email: bart.peirens@proximus.com

	Hani Elmalky
	Email: hani.elmalky@ericsson.com

	Prem Jonnalagadda
	Email: prem@barefootnetworks.com

	Milad Sharif
	Email: msharif@barefootnetworks.com>

	Robert Hanzl
	Cisco Systems
	Millenium Plaza Building, V Celnici 10, Prague 1,
	Prague, Czech Republic
	Email rhanzl@cisco.com

	Ketan Talaulikar
	Cisco Systems, Inc.
	Email: ketant@cisco.com

	]]></artwork>
	</figure></t>
	</section>	</section>


	<section title="Acknowledgments">

	<t>Thanks to Christian Hopps for his review comments and shepherd work.</t>
	<t>Thanks to Alvaro Retana and John Scudder for AD review and comments.</t>

	</section>

	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">	<references pn="section-13">
	<?rfc include="reference.RFC.7981"?>	<name slugifiedName="name-references">References</name>
		<references pn="section-13.1">
	<?rfc include='reference.RFC.5305'?>	<name slugifiedName="name-normative-references">Normative References</na
		me>
	<?rfc include='reference.RFC.5308'?>	<reference anchor="ISO10589" quoteTitle="true" derivedAnchor="ISO10589">
		<front>
	<?rfc include='reference.RFC.5120'?>	<title>Information technology - Telecommunications and information e
		xchange between systems - Intermediate System to Intermediate System intra-domai
	<?rfc include='reference.RFC.2119'?>	n routeing information exchange protocol for use in conjunction with the protoco
		l for providing the connectionless-mode network service (ISO 8473)</title>
	<?rfc include='reference.RFC.8174'?>	<author>
		<organization abbrev="ISO" showOnFrontPage="true">International Or
	<?rfc include="reference.RFC.8491"?>	ganization for Standardization</organization>
		</author>
	<?rfc include="reference.RFC.8754"?>	<date month="November" year="2002"/>
		</front>
	<?rfc include='reference.RFC.7370'?>	<seriesInfo name="ISO/IEC" value="10589:2002"/>
		<refcontent>Second Edition</refcontent>
	<?rfc include='reference.RFC.7794'?>	</reference>
		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<?rfc include='reference.RFC.8667'?>	119" quoteTitle="true" derivedAnchor="RFC2119">
		<front>
	<?rfc include='reference.RFC.8126'?>	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
		le>
	<?rfc include='reference.RFC.8665'?>	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
		<date month="March" year="1997"/>
	<?rfc include='reference.RFC.8986'?>	<abstract>
		<t indent="0">In many standards track documents several words are
	<?rfc include='reference.RFC.8402'?>	used to signify the requirements in the specification. These words are often ca
		pitalized. This document defines these words as they should be interpreted in I
	<?rfc include="reference.I-D.ietf-lsr-flex-algo.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="reference.I-D.ietf-6man-spring-srv6-oam.xml"?>	</t>
		</abstract>
	<reference anchor="ISO10589">	</front>
	<front>	<seriesInfo name="BCP" value="14"/>
	<title>Intermediate system to Intermediate system intra-domain	<seriesInfo name="RFC" value="2119"/>
	routeing information exchange protocol for use in conjunction with	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	the protocol for providing the connectionless-mode Network Service	</reference>
	(ISO 8473)</title>	<reference anchor="RFC5120" target="https://www.rfc-editor.org/info/rfc5
		120" quoteTitle="true" derivedAnchor="RFC5120">
	<author>	<front>
	<organization abbrev="ISO">International Organization for	<title>M-ISIS: Multi Topology (MT) Routing in Intermediate System to
	Standardization</organization>	Intermediate Systems (IS-ISs)</title>
	</author>	<author fullname="T. Przygienda" initials="T." surname="Przygienda"/
		>
	<date month="Nov" year="2002"/>	<author fullname="N. Shen" initials="N." surname="Shen"/>
	</front>	<author fullname="N. Sheth" initials="N." surname="Sheth"/>
	</reference>	<date month="February" year="2008"/>
	</references>	<abstract>
		<t indent="0">This document describes an optional mechanism within
	<references title="Informative References">	Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs fo
		r IGP routing within their clouds. This document describes how to run, within a
	<?rfc include='reference.RFC.5286'?>	single IS-IS domain, a set of independent IP topologies that we call Multi-Topo
		logies (MTs). This MT extension can be used for a variety of purposes, such as
	<?rfc include='reference.RFC.5304'?>	an in-band management network "on top" of the original IGP topology, maintaining
		separate IGP routing domains for isolated multicast or IPv6 islands within the
	<?rfc include='reference.RFC.5310'?>	backbone, or forcing a subset of an address space to follow a different topology
		. [STANDARDS-TRACK]</t>
	<?rfc include='reference.RFC.8355'?>	</abstract>
		</front>
		<seriesInfo name="RFC" value="5120"/>
		<seriesInfo name="DOI" value="10.17487/RFC5120"/>
		</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="RFC5308" target="https://www.rfc-editor.org/info/rfc5
		308" quoteTitle="true" derivedAnchor="RFC5308">
		<front>
		<title>Routing IPv6 with IS-IS</title>
		<author fullname="C. Hopps" initials="C." surname="Hopps"/>
		<date month="October" year="2008"/>
		<abstract>
		<t indent="0">This document specifies a method for exchanging IPv6
		routing information using the IS-IS routing protocol. The described method uti
		lizes two new TLVs: a reachability TLV and an interface address TLV to distribut
		e the necessary IPv6 information throughout a routing domain. Using this method
		, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing
		protocol. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="5308"/>
		<seriesInfo name="DOI" value="10.17487/RFC5308"/>
		</reference>
		<reference anchor="RFC7370" target="https://www.rfc-editor.org/info/rfc7
		370" quoteTitle="true" derivedAnchor="RFC7370">
		<front>
		<title>Updates to the IS-IS TLV Codepoints Registry</title>
		<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
		<date month="September" year="2014"/>
		<abstract>
		<t indent="0">This document recommends some editorial changes to t
		he IANA "IS-IS TLV Codepoints" registry to more accurately document the state of
		the protocol. It also sets out new guidelines for Designated Experts to apply
		when reviewing allocations from the registry.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7370"/>
		<seriesInfo name="DOI" value="10.17487/RFC7370"/>
		</reference>
		<reference anchor="RFC7794" target="https://www.rfc-editor.org/info/rfc7
		794" quoteTitle="true" derivedAnchor="RFC7794">
		<front>
		<title>IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachabili
		ty</title>
		<author fullname="L. Ginsberg" initials="L." role="editor" surname="
		Ginsberg"/>
		<author fullname="B. Decraene" initials="B." surname="Decraene"/>
		<author fullname="S. Previdi" initials="S." surname="Previdi"/>
		<author fullname="X. Xu" initials="X." surname="Xu"/>
		<author fullname="U. Chunduri" initials="U." surname="Chunduri"/>
		<date month="March" year="2016"/>
		<abstract>
		<t indent="0">This document introduces new sub-TLVs to support adv
		ertisement of IPv4 and IPv6 prefix attribute flags and the source router ID of t
		he router that originated a prefix advertisement.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7794"/>
		<seriesInfo name="DOI" value="10.17487/RFC7794"/>
		</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="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="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="RFC8402" target="https://www.rfc-editor.org/info/rfc8
		402" quoteTitle="true" derivedAnchor="RFC8402">
		<front>
		<title>Segment Routing Architecture</title>
		<author fullname="C. Filsfils" initials="C." role="editor" surname="
		Filsfils"/>
		<author fullname="S. Previdi" initials="S." role="editor" surname="P
		revidi"/>
		<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
		<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="July" year="2018"/>
		<abstract>
		<t indent="0">Segment Routing (SR) leverages the source routing pa
		radigm. A node steers a packet through an ordered list of instructions, called "
		segments". A segment can represent any instruction, topological or service based
		. A segment can have a semantic local to an SR node or global within an SR domai
		n. SR provides a mechanism that allows a flow to be restricted to a specific top
		ological path, while maintaining per-flow state only at the ingress node(s) to t
		he SR domain.</t>
		<t indent="0">SR can be directly applied to the MPLS architecture
		with no change to the forwarding plane. A segment is encoded as an MPLS label. A
		n ordered list of segments is encoded as a stack of labels. The segment to proce
		ss is on the top of the stack. Upon completion of a segment, the related label i
		s popped from the stack.</t>
		<t indent="0">SR can be applied to the IPv6 architecture, with a n
		ew type of routing header. A segment is encoded as an IPv6 address. An ordered l
		ist of segments is encoded as an ordered list of IPv6 addresses in the routing h
		eader. The active segment is indicated by the Destination Address (DA) of the pa
		cket. The next active segment is indicated by a pointer in the new routing heade
		r.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8402"/>
		<seriesInfo name="DOI" value="10.17487/RFC8402"/>
		</reference>
		<reference anchor="RFC8491" target="https://www.rfc-editor.org/info/rfc8
		491" quoteTitle="true" derivedAnchor="RFC8491">
		<front>
		<title>Signaling Maximum SID Depth (MSD) Using IS-IS</title>
		<author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
		<author fullname="U. Chunduri" initials="U." surname="Chunduri"/>
		<author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
		<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
		<date month="November" year="2018"/>
		<abstract>
		<t indent="0">This document defines a way for an Intermediate Syst
		em to Intermediate System (IS-IS) router to advertise multiple types of supporte
		d Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisement
		s allow entities (e.g., centralized controllers) to determine whether a particul
		ar Segment ID (SID) stack can be supported in a given network. This document on
		ly defines one type of MSD: Base MPLS Imposition. However, it defines an encodi
		ng that can support other MSD types. This document focuses on MSD use in a netw
		ork that is Segment Routing (SR) enabled, but MSD may also be useful when SR is
		not enabled.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8491"/>
		<seriesInfo name="DOI" value="10.17487/RFC8491"/>
		</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="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="RFC8754" target="https://www.rfc-editor.org/info/rfc8
		754" quoteTitle="true" derivedAnchor="RFC8754">
		<front>
		<title>IPv6 Segment Routing Header (SRH)</title>
		<author fullname="C. Filsfils" initials="C." role="editor" surname="
		Filsfils"/>
		<author fullname="D. Dukes" initials="D." role="editor" surname="Duk
		es"/>
		<author fullname="S. Previdi" initials="S." surname="Previdi"/>
		<author fullname="J. Leddy" initials="J." surname="Leddy"/>
		<author fullname="S. Matsushima" initials="S." surname="Matsushima"/
		>
		<author fullname="D. Voyer" initials="D." surname="Voyer"/>
		<date month="March" year="2020"/>
		<abstract>
		<t indent="0">Segment Routing can be applied to the IPv6 data plan
		e using a new type of Routing Extension Header called the Segment Routing Header
		(SRH). This document describes the SRH and how it is used by nodes that are Se
		gment Routing (SR) capable.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8754"/>
		<seriesInfo name="DOI" value="10.17487/RFC8754"/>
		</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="RFC9259" target="https://www.rfc-editor.org/info/rfc9
		259" quoteTitle="true" derivedAnchor="RFC9259">
		<front>
		<title>Operations, Administration, and Maintenance (OAM) in Segment
		Routing over IPv6 (SRv6)</title>
		<author fullname="Z. Ali" initials="Z." surname="Ali"/>
		<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
		<author fullname="S. Matsushima" initials="S." surname="Matsushima"/
		>
		<author fullname="D. Voyer" initials="D." surname="Voyer"/>
		<author fullname="M. Chen" initials="M." surname="Chen"/>
		<date month="June" year="2022"/>
		<abstract>
		<t indent="0">This document describes how the existing IPv6 mechan
		isms for ping and traceroute can be used in a Segment Routing over IPv6 (SRv6) n
		etwork. The document also specifies the OAM flag (O-flag) in the Segment Routin
		g Header (SRH) for performing controllable and predictable flow sampling from se
		gment endpoints. In addition, the document describes how a centralized monitori
		ng system performs a path continuity check between any nodes within an SRv6 doma
		in.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="9259"/>
		<seriesInfo name="DOI" value="10.17487/RFC9259"/>
		</reference>
		<reference anchor="RFC9350" quoteTitle="true" target="https://www.rfc-ed
		itor.org/rfc/rfc9350" derivedAnchor="RFC9350">
		<front>
		<title>IGP Flexible Algorithm</title>
		<author initials="P" surname="Psenak" fullname="Peter Psenak" role="
		editor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="S" surname="Hegde" fullname="Shraddha Hegde">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
		>
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="K" surname="Talaulikar" fullname="Ketan Talaulikar
		">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="A" surname="Gulko" fullname="Arkadiy Gulko">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2023" month="February"/>
		</front>
		<seriesInfo name="RFC" value="9350"/>
		<seriesInfo name="DOI" value="10.17487/RFC9350"/>
		</reference>
		</references>
		<references pn="section-13.2">
		<name slugifiedName="name-informative-references">Informative References
		</name>
		<reference anchor="RFC5286" target="https://www.rfc-editor.org/info/rfc5
		286" quoteTitle="true" derivedAnchor="RFC5286">
		<front>
		<title>Basic Specification for IP Fast Reroute: Loop-Free Alternates
		</title>
		<author fullname="A. Atlas" initials="A." role="editor" surname="Atl
		as"/>
		<author fullname="A. Zinin" initials="A." role="editor" surname="Zin
		in"/>
		<date month="September" year="2008"/>
		<abstract>
		<t indent="0">This document describes the use of loop-free alterna
		tes to provide local protection for unicast traffic in pure IP and MPLS/LDP netw
		orks in the event of a single failure, whether link, node, or shared risk link g
		roup (SRLG). The goal of this technology is to reduce the packet loss that happ
		ens while routers converge after a topology change due to a failure. Rapid fail
		ure repair is achieved through use of precalculated backup next-hops that are lo
		op-free and safe to use until the distributed network convergence process comple
		tes. This simple approach does not require any support from other routers. The
		extent to which this goal can be met by this specification is dependent on the
		topology of the network. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="5286"/>
		<seriesInfo name="DOI" value="10.17487/RFC5286"/>
		</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="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="RFC8355" target="https://www.rfc-editor.org/info/rfc8
		355" quoteTitle="true" derivedAnchor="RFC8355">
		<front>
		<title>Resiliency Use Cases in Source Packet Routing in Networking (
		SPRING) Networks</title>
		<author fullname="C. Filsfils" initials="C." role="editor" surname="
		Filsfils"/>
		<author fullname="S. Previdi" initials="S." role="editor" surname="P
		revidi"/>
		<author fullname="B. Decraene" initials="B." surname="Decraene"/>
		<author fullname="R. Shakir" initials="R." surname="Shakir"/>
		<date month="March" year="2018"/>
		<abstract>
		<t indent="0">This document identifies and describes the requireme
		nts for a set of use cases related to Segment Routing network resiliency on Sour
		ce Packet Routing in Networking (SPRING) networks.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8355"/>
		<seriesInfo name="DOI" value="10.17487/RFC8355"/>
		</reference>
		</references>
	</references>	</references>

		<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
		ndix.a">
		<name slugifiedName="name-acknowledgements">Acknowledgements</name>
		<t indent="0" pn="section-appendix.a-1">Thanks to <contact fullname="Chris
		tian Hopps"/> for his review comments and shepherd
		work.</t>
		<t indent="0" pn="section-appendix.a-2">Thanks to <contact fullname="Alvar
		o Retana"/> and <contact fullname="John Scudder"/> for
		AD review and comments.</t>
		</section>
		<section anchor="CONTRIB" numbered="false" toc="include" removeInRFC="false"
		pn="section-appendix.b">
		<name slugifiedName="name-contributors">Contributors</name>
		<t indent="0" pn="section-appendix.b-1">The following people gave a substa
		ntial contribution to the content
		of this document and should be considered coauthors:</t>
		<contact fullname="Stefano Previdi">
		<organization showOnFrontPage="true">Huawei Technologies</organization>
		<address>
		<postal/>
		<email>stefano@previdi.net</email>
		</address>
		</contact>
		<contact fullname="Paul Wells">
		<organization showOnFrontPage="true">Cisco Systems</organization>
		<address>
		<postal>
		<street/>
		<city>Saint Paul</city>
		<region>Minnesota</region>
		<country>United States of America</country>
		</postal>
		<email>pauwells@cisco.com</email>
		</address>
		</contact>
		<contact fullname="Daniel Voyer">
		<address>
		<email>daniel.voyer@bell.ca</email>
		</address>
		</contact>
		<contact fullname="Satoru Matsushima">
		<address>
		<postal/>
		<email>satoru.matsushima@g.softbank.co.jp</email>
		</address>
		</contact>
		<contact fullname="Bart Peirens">
		<address>
		<postal/>
		<email>bart.peirens@proximus.com</email>
		</address>
		</contact>
		<contact fullname="Hani Elmalky">
		<address>
		<postal/>
		<email>hani.elmalky@ericsson.com</email>
		</address>
		</contact>
		<contact fullname="Prem Jonnalagadda">
		<address>
		<postal/>
		<email>prem@barefootnetworks.com</email>
		</address>
		</contact>
		<contact fullname="Milad Sharif">
		<address>
		<postal/>
		<email>msharif@barefootnetworks.com</email>
		</address>
		</contact>
		<contact fullname="Robert Hanzl">
		<organization showOnFrontPage="true">Cisco Systems</organization>
		<address>
		<postal>
		<street>Millenium Plaza Building, V Celnici 10, Prague 1</street>
		<city>Prague</city>
		<country>Czech Republic</country>
		</postal>
		<email>rhanzl@cisco.com</email>
		</address>
		</contact>
		<contact fullname="Ketan Talaulikar">
		<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
		<address>
		<postal/>
		<email>ketant@cisco.com</email>
		</address>
		</contact>
		</section>
		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
		="include" pn="section-appendix.c">
		<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
		<author fullname="Peter Psenak" initials="P" role="editor" surname="Psenak
		">
		<organization showOnFrontPage="true">Cisco Systems</organization>
		<address>
		<postal>
		<street>Pribinova Street 10</street>
		<city>Bratislava</city>
		<code>81109</code>
		<region/>
		<country>Slovakia</country>
		</postal>
		<phone/>
		<email>ppsenak@cisco.com</email>
		<uri/>
		</address>
		</author>
		<author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
		<organization showOnFrontPage="true">Cisco Systems</organization>
		<address>
		<postal>
		<street/>
		<city>Brussels</city>
		<code/>
		<region/>
		<country>Belgium</country>
		</postal>
		<email>cfilsfil@cisco.com</email>
		</address>
		</author>
		<author fullname="Ahmed Bashandy" initials="A" surname="Bashandy">
		<organization showOnFrontPage="true">Cisco Systems</organization>
		<address>
		<postal>
		<street/>
		<city>Milpitas</city>
		<country>United States of America</country>
		</postal>
		<email>bashandy@cisco.com</email>
		</address>
		</author>
		<author fullname="Bruno Decraene" initials="B" surname="Decraene">
		<organization showOnFrontPage="true">Orange</organization>
		<address>
		<postal>
		<street/>
		<city>Chatillon</city>
		<code/>
		<region/>
		<country>France</country>
		</postal>
		<email>bruno.decraene@orange.com</email>
		</address>
		</author>
		<author fullname="Zhibo Hu" initials="Z" surname="Hu">
		<organization showOnFrontPage="true">Huawei Technologies</organization>
		<address>
		<postal>
		<street/>
		<city/>
		<code/>
		<region/>
		<country/>
		</postal>
		<email>huzhibo@huawei.com</email>
		</address>
		</author>
		</section>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 115 change blocks.
	1350 lines changed or deleted	2622 lines changed or added
This html diff was produced by rfcdiff 1.48.