Movatterモバイル変換

[0]ホーム

	rfc8667.original.v2v3.xml	rfc8667.form.xml
	<?xml version='1.0' encoding='utf-8'?>	<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="yes" number="8667" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" number="8667" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3" docName="draft-ietf-pce-segment-routing-16">
	<!-- xml2rfc v2v3 conversion 2.27.1 -->	<!-- xml2rfc v2v3 conversion 2.27.1 -->
	<front>	<front>
	<title abbrev="IS-IS Extensions for Segment Routing">IS-IS Extensions for	<title abbrev="IS-IS Extensions for Segment Routing">IS-IS Extensions for
	Segment Routing</title>	Segment Routing</title>
	<seriesInfo name="RFC" value="8667"/>	<seriesInfo name="RFC" value="8667"/>
	<author fullname="Stefano Previdi" initials="S." role="editor" surname="Previdi">	<author fullname="Stefano Previdi" initials="S." role="editor" surname="Previdi">
	<organization>Huawei Technologies</organization>	<organization>Huawei Technologies</organization>
	<address>	<address>
	<postal>	<postal>
	<street/>	<street/>

	skipping to change at line 125 ¶	skipping to change at line 125 ¶
	SR paths do not require any LDP or RSVP-TE signaling. Still, SR can	SR paths do not require any LDP or RSVP-TE signaling. Still, SR can
	interoperate in the presence of Label Switched Paths (LSPs) established with RSVP or LDP.</t>	interoperate in the presence of Label Switched Paths (LSPs) established with RSVP or LDP.</t>
	<t>There are additional segment types, e.g., the Binding SID as defined in	<t>There are additional segment types, e.g., the Binding SID as defined in
	<xref format="default"/>. This document also defines an advertisement	<xref format="default"/>. This document also defines an advertisement
	for one type of Binding SID: the Mirror Context segment.</t>	for one type of Binding SID: the Mirror Context segment.</t>
	<t>This document describes the IS-IS extensions that need to be	<t>This document describes the IS-IS extensions that need to be
	introduced for Segment Routing operating on an MPLS data plane.</t>	introduced for Segment Routing operating on an MPLS data plane.</t>
	<t>The Segment Routing architecture is described in <xref format="default"/>. Segment Routing use cases are described in <xref format="default"/>.</t>	<t>The Segment Routing architecture is described in <xref format="default"/>. Segment Routing use cases are described in <xref format="default"/>.</t>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Requirements Language</name>	<name>Requirements Language</name>

	<t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	<t>The key words"<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"MAY", and"OPTIONAL" in this document are to be interpreted as	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	described inBCP 14 <xref format="default"/> <xref, "<bcp14>NOT RECOMMENDED</bcp14>",
	RFC8174" format="default"/>	"<bcp14>MAY</bcp14>", and"<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described inBCP 14 <xref format="default"/> <xref format="default"/>
	when, and only when, they appear in all capitals, as shown here.</t>	when, and only when, they appear in all capitals, as shown here.</t>
	</section>	</section>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Segment Routing Identifiers</name>	<name>Segment Routing Identifiers</name>
	<t>The Segment Routing architecture <xref format="default"/> defines	<t>The Segment Routing architecture <xref format="default"/> defines
	different types of Segment Identifiers (SIDs). This document defines the	different types of Segment Identifiers (SIDs). This document defines the
	IS-IS encodings for the IGP-Prefix Segment, the IGP-Adjacency Segment,	IS-IS encodings for the IGP-Prefix Segment, the IGP-Adjacency Segment,
	the IGP-LAN-Adjacency Segment, and the Binding Segment.</t>	the IGP-LAN-Adjacency Segment, and the Binding Segment.</t>
	<section anchor="PREFIXSIDSUBTLV" numbered="true" toc="default">	<section anchor="PREFIXSIDSUBTLV" numbered="true" toc="default">
	<name>Prefix Segment Identifier (Prefix-SID) Sub-TLV</name>	<name>Prefix Segment Identifier (Prefix-SID) Sub-TLV</name>
	<t>A new IS-IS sub-TLV is defined: the Prefix Segment Identifier	<t>A new IS-IS sub-TLV is defined: the Prefix Segment Identifier
	(Prefix-SID) sub-TLV.</t>	(Prefix-SID) sub-TLV.</t>
	<t>The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID	<t>The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID

	as defined in <xref format="default"/>. The 'Prefix SID'MUST be	as defined in <xref format="default"/>. The 'Prefix SID'<bcp14>MUST</bcp14> be
	unique within a given IGP domain (when the L-flag is not set).</t>	unique within a given IGP domain (when the L-flag is not set).</t>
	<t>A Prefix-SID sub-TLV is associated to a prefix advertised by a node	<t>A Prefix-SID sub-TLV is associated to a prefix advertised by a node

	andMAY be present in any of the following TLVs: </t>	and<bcp14>MAY</bcp14> be present in any of the following TLVs: </t>
	<dl newline="false" spacing="normal">
	<dt/>	<ul empty="true">
	<dd>TLV-135 (Extended IPv4 reachability) defined in <xrefRFC5
	305"format="default"/>.</dd>	305"format="default"/>.</li>
	<dt/>
	<dd>TLV-235 (Multitopology IPv4 Reachability) defined in <xref target=	<li>TLV-235 (Multitopology IPv4 Reachability) defined in <xref target=
	"RFC5120"format="default"/>.</dd>	"RFC5120"format="default"/>.</li>
	<dt/>
	<dd>TLV-236 (IPv6 IP Reachability) defined in <xref f	<li>TLV-236 (IPv6 IP Reachability) defined in <xref f
	ormat="default"/>.</dd>	ormat="default"/>.</li>
	<dt/>
	<dd>TLV-237 (Multitopology IPv6 IP Reachability) defined in <xref targ	<li>TLV-237 (Multitopology IPv6 IP Reachability) defined in <xref targ
	et="RFC5120"format="default"/>.</dd>	et="RFC5120"format="default"/>.</li>
	<dt/>
	<dd>The Binding TLV and Multi-Topology Binding TLV are defined in Sect	<li>The Binding TLV and Multi-Topology Binding TLV are defined in Sect
	ions <xref format="counter"/> and <xrefBINDINGTLV" format="counter"/> and <xref format="counter"/>,	" format="counter"/>,
	respectively.</dd>	respectively.</li>
	</dl>	</ul>

	<t>The Prefix-SID sub-TLV has the following format:</t>	<t>The Prefix-SID sub-TLV has the following format:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \| Algorithm \|	\| Type \| Length \| Flags \| Algorithm \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SID/Index/Label (variable) \|	\| SID/Index/Label (variable) \|

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
		<t>where:</t>
	where:]]></artwork>	<ul empty="true">
	<dl newline="false"spacing="normal">	<li>
	<dt/>	<dl newline="false"spacing="normal" indent="9">
	<dd>Type: 3</dd>	<dt>Type:</dt><dd>3</dd>
	<dt/>	<dt>Length:</dt><dd>5 or 6 depending on the size of the SID (described
	<dd>Length: 5 or 6 depending on the size of the SID (described
	below)</dd>	below)</dd>

	<dt/>	<dt>
	<dd>	Flags:</dt><dd><t> 1-octet field of the followingflags:</t>
	<t>Flags: 1-octet field of the followingflags: </t>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|R\|N\|P\|E\|V\|L\| \|	\|R\|N\|P\|E\|V\|L\| \|

	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+]]></artwork>
	]]></artwork>	<t> where: </t>
	<t> where: </t>	<dl newline="false"spacing="normal" indent="9">
	<dl newline="false"spacing="normal">	<dt>R-Flag:</dt><dd>Re-advertisement flag. If set, then the prefix
	<dt/>	to
	<dd>R-Flag: Re-advertisement flag. If set, then the prefix to
	which this Prefix-SID is attached has been propagated by the	which this Prefix-SID is attached has been propagated by the
	router from either another level (i.e., from Level-1 to	router from either another level (i.e., from Level-1 to
	Level-2 or the opposite) or redistribution (e.g., from	Level-2 or the opposite) or redistribution (e.g., from
	another protocol).</dd>	another protocol).</dd>

	<dt/>	<dt>N-Flag:</dt><dd>Node-SID flag. If set, then the Prefix-SIDref
	<dd>N-Flag: Node-SID flag. If set, then the Prefix-SIDrefers	ers
	to the router identified by the prefix. Typically, the N-Flag	to the router identified by the prefix. Typically, the N-Flag
	is set on Prefix-SIDs that are attached to a router loopback address.	is set on Prefix-SIDs that are attached to a router loopback address.
	The N-Flag is set when the Prefix-SID is a Node-SID as	The N-Flag is set when the Prefix-SID is a Node-SID as
	described in <xref format="default"/>.</dd>	described in <xref format="default"/>.</dd>

	<dt/>	<dt>P-Flag:</dt><dd>No-PHP flag (No Penultimate Hop-Popping flag).
	<dd>P-Flag: No-PHP flag (No Penultimate Hop-Popping flag). If set,	If set, then the penultimate hop<bcp14>MUST
	then the penultimate hopMUST	NOT</bcp14> pop the Prefix-SID before delivering the packet tot
	NOT pop the Prefix-SID before delivering the packet tothe	he
	node that advertised the Prefix-SID.</dd>	node that advertised the Prefix-SID.</dd>

	<dt/>	<dt>E-Flag:</dt><dd>Explicit-Null Flag. If set, any upstreamneigh
	<dd>E-Flag: Explicit-Null Flag. If set, any upstreamneighbor	bor
	of the Prefix-SID originatorMUST replace thePrefix-SID with	of the Prefix-SID originator<bcp14>MUST</bcp14> replace thePre
		fix-SID with
	a Prefix-SID that has an Explicit-NULL value (0 for IPv4 and 2	a Prefix-SID that has an Explicit-NULL value (0 for IPv4 and 2
	for IPv6) before forwarding the packet.</dd>	for IPv6) before forwarding the packet.</dd>

	<dt/>	<dt>V-Flag:</dt><dd>Value flag. If set, then the Prefix-SIDcarrie
	<dd>V-Flag: Value flag. If set, then the Prefix-SIDcarries a	s a
	value (instead of an index). By default, the flag is UNSET.</dd>	value (instead of an index). By default, the flag is UNSET.</dd>

	<dt/>	<dt>L-Flag:</dt><dd>Local Flag. If set, then the value/indexcarri
	<dd>L-Flag: Local Flag. If set, then the value/indexcarried by	ed by
	the Prefix-SID has local significance. By default, the flag is	the Prefix-SID has local significance. By default, the flag is
	UNSET.</dd>	UNSET.</dd>

	<dt/>	<dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero whenoriginate
	<dd>Other bits: MUST be zero whenoriginated and ignored when	d and ignored when
	received.</dd>	received.</dd>

	</dl>	</dl>
	</dd>	</dd>
	<dt/>	</dl>
	<dd>Algorithm: the router may use various algorithms when	</li>
		</ul>
		<ul empty="true">
		<li><dl newline="false" spacing="normal">

		<dt>Algorithm:</dt><dd>the router may use various algorithms when
	calculating reachability to other nodes or to prefixes attached to	calculating reachability to other nodes or to prefixes attached to
	these nodes. Algorithm identifiers are defined in <xref format="default"/>. Examples of these algorithms are metric-based	these nodes. Algorithm identifiers are defined in <xref format="default"/>. Examples of these algorithms are metric-based
	Shortest Path First (SPF), various sorts of Constrained SPF,	Shortest Path First (SPF), various sorts of Constrained SPF,
	etc. The Algorithm field of the Prefix-SID contains the identifier	etc. The Algorithm field of the Prefix-SID contains the identifier
	of the algorithm the router uses to compute the reachability of	of the algorithm the router uses to compute the reachability of
	the prefix to which the Prefix-SID is associated.</dd>	the prefix to which the Prefix-SID is associated.</dd>

	<dt/>	</dl></li></ul>
	<dd>At origination, the Prefix-SID Algorithm fieldMUST be set to 0
	or to any value advertised in the SR-Algorithm sub-TLV (see <xref ta	<ul empty="true">
	rget="SRALGOSUBTLV"format="default"/>).</dd>	<li>
	<dt/>	At origination, the Prefix-SID Algorithm field<bcp14>MUST</bcp14> be
	<dd>A router receiving a Prefix-SID from a remote node and with an	set to 0
		or to any value advertised in the SR-Algorithm sub-TLV (see <xref ta
		rget="SRALGOSUBTLV"format="default"/>).</li>

		<li>A router receiving a Prefix-SID from a remote node and with an
	algorithm value that such remote node has not advertised in the	algorithm value that such remote node has not advertised in the

	SR-Algorithm sub-TLV (see <xref format="defaul	SR-Algorithm sub-TLV (see <xref format="defaul
	t"/>)MUST ignore	t"/>)<bcp14>MUST</bcp14> ignore
	the Prefix-SIDsub‑TLV.</dd>	the Prefix-SIDsub-TLV.</li>
	<dt/>
	<dd>SID/Index/Label as defined in <xref format="de	<li>SID/Index/Label as defined in <xref format="de
	fault"/>.</dd>	fault"/>.</li>
	</dl>	</ul>
	<t>When the Prefix SID is an index (and the V-flag is not set), the value	<t>When the Prefix SID is an index (and the V-flag is not set), the value
	is used to determine the actual label value inside the set of all	is used to determine the actual label value inside the set of all
	advertised label ranges of a given router. This allows a receiving	advertised label ranges of a given router. This allows a receiving
	router to construct the forwarding state to a particular destination	router to construct the forwarding state to a particular destination
	router.</t>	router.</t>
	<t>In many use cases, a 'stable transport' address is overloaded as an	<t>In many use cases, a 'stable transport' address is overloaded as an
	identifier of a given node. Because Prefixes may be re-advertised into	identifier of a given node. Because Prefixes may be re-advertised into

	other levels, there may be some ambiguity (e.g., originating router vs. L1L2 router) for which node a particular IP prefix serves as the	other levels, there may be some ambiguity (e.g., originating router vs.L1L2 router) for which node a particular IP prefix serves as the
	identifier. The Prefix-SID sub-TLV contains the necessary flags to	identifier. The Prefix-SID sub-TLV contains the necessary flags to
	disambiguate Prefix-to-node mappings. Furthermore, if a given node has	disambiguate Prefix-to-node mappings. Furthermore, if a given node has
	several 'stable transport' addresses, there are flags to differentiate	several 'stable transport' addresses, there are flags to differentiate
	those among other Prefixes advertised from a given node.</t>	those among other Prefixes advertised from a given node.</t>


	<section anchor="FLAGS" numbered="true" toc="default">	<section anchor="FLAGS" numbered="true" toc="default">
	<name>Flags</name>	<name>Flags</name>
	<section anchor="VANDLFLAGS" numbered="true" toc="default">	<section anchor="VANDLFLAGS" numbered="true" toc="default">
	<name>V and L Flags</name>	<name>V and L Flags</name>
	<t>The V-flag indicates whether the SID/Index/Label field is a	<t>The V-flag indicates whether the SID/Index/Label field is a
	value or an index.</t>	value or an index.</t>


	<t>The L-Flag indicates whether the value/index in the	<t>The L-Flag indicates whether the value/index in the
	SID/Index/Label field has local or global significance.</t>	SID/Index/Label field has local or global significance.</t>


	<t>The following settings for V and L flags are valid:</t>	<t>The following settings for V and L flags are valid:</t>

	<t>The V-flag and L-flag are set to0: The SID/Index/Label	<ul empty="true"><li>
	field is a4‑octet index defining the offset in the SID/Label	<dl>
		<dt>The V-flag and L-flag are set to0:</dt><dd>The SID/Index/Label
		field is a4-octet index defining the offset in the SID/Label
	space advertised by this router using the encodings defined in	space advertised by this router using the encodings defined in

	<xrefformat="default"/>.</t>	<xrefformat="default"/>.</dd>
	<t>The V-flag and L-flag are set to1: The SID/Index/Label
		<dt>The V-flag and L-flag are set to1:</dt><dd>The SID/Index/Label
	field is a 3-octet local label where the 20 rightmost bits are	field is a 3-octet local label where the 20 rightmost bits are

	used for encoding the labelvalue.</t>	used for encoding the labelvalue.</dd>
		</dl>
		</li>
		</ul>

	<t>All other combinations of V-flag and L-flag are invalid, and any	<t>All other combinations of V-flag and L-flag are invalid, and any
	SID advertisement received with an invalid setting for the V and L	SID advertisement received with an invalid setting for the V and L

	flagsMUST be ignored.</t>	flags<bcp14>MUST</bcp14> be ignored.</t>
	</section>	</section>


	<section anchor="RANDNFLAGS" numbered="true" toc="default">	<section anchor="RANDNFLAGS" numbered="true" toc="default">
	<name>R and N Flags</name>	<name>R and N Flags</name>

	<t>The R-FlagMUST be set for prefixes that are not local to the	<t>The R-Flag<bcp14>MUST</bcp14> be set for prefixes that are not local to the
	router and are advertised because of:</t>	router and are advertised because of:</t>

	<dl newline="false" spacing="normal">
	<dt/>	<ul empty="true">
	<dd>propagation (Level-1 intoLevel-2);</dd>	<li>propagation (Level-1 intoLevel-2);</li>
	<dt/>	<li>leaking (Level-2 into Level-1);or</li>
	<dd>leaking (Level-2 into Level-1);or</dd>	<li>redistribution (e.g., from anotherprotocol).</li>
	<dt/>	</ul>
	<dd>redistribution (e.g., from anotherprotocol).</dd>
	</dl>
	<t>In the case where a Level-1-2 router has local interface	<t>In the case where a Level-1-2 router has local interface
	addresses configured in one level, it may also propagate these	addresses configured in one level, it may also propagate these
	addresses into the other level. In such case, the Level-1-2 router	addresses into the other level. In such case, the Level-1-2 router

	MUST NOT set the R bit.</t>	<bcp14>MUST NOT</bcp14> set the R bit.</t>
	<t>The N-Flag is used in order to define a Node-SID. A routerMAY	<t>The N-Flag is used in order to define a Node-SID. A router<bcp14
		>MAY</bcp14>
	set the N-Flag only if all of the following conditions are	set the N-Flag only if all of the following conditions are
	met:</t>	met:</t>

	<dl newline="false" spacing="normal">
	<dt/>	<ul empty="true">
	<dd>The prefix to which the Prefix-SID is attached is local to	<li>The prefix to which the Prefix-SID is attached is local to
	the router (i.e., the prefix is configured on one of the local	the router (i.e., the prefix is configured on one of the local

	interfaces, e.g., a 'stable transport'loopback).</dd>	interfaces, e.g., a 'stable transport'loopback).</li>
	<dt/>	<li>The prefix to which the Prefix-SID is attached has a Prefix
	<dd>The prefix to which the Prefix-SID is attached has a Prefix	length of either /32 (IPv4) or /128(IPv6).</li>
	length of either /32 (IPv4) or /128(IPv6).</dd>	</ul>
	</dl>
	<t>The routerMUST ignore the N-Flag on a receivedPrefix-SID if	<t>The router<bcp14>MUST</bcp14> ignore the N-Flag on a receivedPr
		efix-SID if
	the prefix has a Prefix length different than /32 (IPv4) or /128	the prefix has a Prefix length different than /32 (IPv4) or /128
	(IPv6).</t>	(IPv6).</t>
	<t>The Prefix Attribute Flags sub-TLV <xref format="default"/>	<t>The Prefix Attribute Flags sub-TLV <xref format="default"/>
	also defines the N and R flags and with the same semantics of the	also defines the N and R flags and with the same semantics of the
	equivalent flags defined in this document. Whenever the Prefix	equivalent flags defined in this document. Whenever the Prefix
	Attribute Flags sub-TLV is present for a given prefix, the values	Attribute Flags sub-TLV is present for a given prefix, the values

	of the N and R flags advertised in that sub-TLVMUST be used, and	of the N and R flags advertised in that sub-TLV<bcp14>MUST</bcp14>
	the values in a corresponding Prefix SID sub-TLV (if present)MUST	be used, and
		the values in a corresponding Prefix SID sub-TLV (if present)<bcp14
		>MUST</bcp14>
	be ignored.</t>	be ignored.</t>
	</section>	</section>
	<section anchor="EANDPFLAGS" numbered="true" toc="default">	<section anchor="EANDPFLAGS" numbered="true" toc="default">
	<name>E and P Flags</name>	<name>E and P Flags</name>
	<t>The following behavior is associated with the settings of the E	<t>The following behavior is associated with the settings of the E
	and P flags:</t>	and P flags:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>If the P-flag is not set, then any upstream neighbor of the	<li>If the P-flag is not set, then any upstream neighbor of the

	Prefix-SID originatorMUST pop the Prefix-SID. This is	Prefix-SID originator<bcp14>MUST</bcp14> pop the Prefix-SID. This is
	equivalent to the penultimate hop-popping mechanism used in	equivalent to the penultimate hop-popping mechanism used in
	the MPLS data plane, which improves performance of the ultimate	the MPLS data plane, which improves performance of the ultimate
	hop. MPLS EXP bits of the Prefix-SID are not preserved to the	hop. MPLS EXP bits of the Prefix-SID are not preserved to the
	ultimate hop (the Prefix-SID being removed). If the P-flag is	ultimate hop (the Prefix-SID being removed). If the P-flag is
	unset, the received E-flag is ignored.</li>	unset, the received E-flag is ignored.</li>
	<li>	<li>
	<t>If the P-flag is set, then:</t>	<t>If the P-flag is set, then:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>If the E-flag is not set, then any upstream neighbor of	<li>If the E-flag is not set, then any upstream neighbor of

	the Prefix-SID originatorMUST keep the Prefix-SID on top	the Prefix-SID originator<bcp14>MUST</bcp14> keep the Prefix-SID on top
	of the stack. This is useful when, e.g., the originator of	of the stack. This is useful when, e.g., the originator of
	the Prefix-SID must stitch the incoming packet into a	the Prefix-SID must stitch the incoming packet into a
	continuing MPLS LSP to the final destination. This could	continuing MPLS LSP to the final destination. This could
	occur at an inter-area border router (prefix propagation	occur at an inter-area border router (prefix propagation
	from one area to another) or at an interdomain border	from one area to another) or at an interdomain border
	router (prefix propagation from one domain to	router (prefix propagation from one domain to
	another).</li>	another).</li>
	<li>If the E-flag is set, then any upstream neighbor of the	<li>If the E-flag is set, then any upstream neighbor of the

	Prefix-SID originatorMUST replace the Prefix-SID with a	Prefix-SID originator<bcp14>MUST</bcp14> replace the Prefix-SID with a
	Prefix-SID having an Explicit-NULL value. This is useful,	Prefix-SID having an Explicit-NULL value. This is useful,
	e.g., when the originator of the Prefix-SID is the final	e.g., when the originator of the Prefix-SID is the final
	destination for the related prefix and the originator	destination for the related prefix and the originator
	wishes to receive the packet with the original EXP	wishes to receive the packet with the original EXP
	bits.</li>	bits.</li>
	</ul>	</ul>
	</li>	</li>
	</ul>	</ul>

	<t>When propagating (from either Level-1 to Level-2 or Level-2 to Level‑1)	<t>When propagating (from either Level-1 to Level-2 or Level-2 to Level-1)
	a reachability advertisement originated by another IS-IS speaker,	a reachability advertisement originated by another IS-IS speaker,

	the routerMUST set the P-flag and MUST clear the E-flag of the	the router<bcp14>MUST</bcp14> set the P-flag and <bcp14>MUST</bcp14> clear the E-flag of the
	related Prefix-SIDs.</t>	related Prefix-SIDs.</t>
	</section>	</section>
	</section>	</section>


	<section anchor="PROPAGATION" numbered="true" toc="default">	<section anchor="PROPAGATION" numbered="true" toc="default">
	<name>Prefix-SID Propagation</name>	<name>Prefix-SID Propagation</name>

	<t>The Prefix-SID sub-TLVMUST be included when the associated	<t>The Prefix-SID sub-TLV<bcp14>MUST</bcp14> be included when the associated
	Prefix Reachability TLV is propagated across level boundaries.</t>	Prefix Reachability TLV is propagated across level boundaries.</t>
	<t>The Level-1-2 router that propagates the Prefix-SID sub-TLV	<t>The Level-1-2 router that propagates the Prefix-SID sub-TLV
	between levels maintains the content (flags and SID), except as noted	between levels maintains the content (flags and SID), except as noted
	in Sections <xref format="counter"/> and <xref target="EANDPFLAGS" format="counter"/>.</t>	in Sections <xref format="counter"/> and <xref target="EANDPFLAGS" format="counter"/>.</t>

	</section>	</section>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Adjacency Segment Identifier</name>	<name>Adjacency Segment Identifier</name>
	<t>A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier (Adj-SID)	<t>A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier (Adj-SID)

	sub‑TLV.</t>	sub-TLV.</t>
	<t>The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment	<t>The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment
	Routing IGP-Adjacency-SID as defined in <xref format="default"/> with	Routing IGP-Adjacency-SID as defined in <xref format="default"/> with
	flags and fields that may be used, in future extensions of Segment	flags and fields that may be used, in future extensions of Segment
	Routing, for carrying other types of SIDs.</t>	Routing, for carrying other types of SIDs.</t>
	<t>IS-IS adjacencies are advertised using one of the IS Neighbor TLVs	<t>IS-IS adjacencies are advertised using one of the IS Neighbor TLVs
	below:</t>	below:</t>

	<dl newline="false" spacing="normal">	<ul empty="true">
	<dt/>	<li>TLV-22 (Extended IS reachability) <xref format="d
	<dd>TLV-22 (Extended IS reachability) <xref format="d	efault"/></li>
	efault"/></dd>	<li>TLV-222 (MT-ISN) <xrefformat="default"/></li>
	<dt/>	<li>TLV-23 (IS Neighbor Attribute) <xref format="defa
	<dd>TLV-222 (MT-ISN) <xrefformat="default"/></dd>	ult"/></li>
	<dt/>	<li>TLV-223 (MT IS Neighbor Attribute) <xref format="
	<dd>TLV-23 (IS Neighbor Attribute) <xref format="defa	default"/></li>
	ult"/></dd>	<li>TLV-141 (inter-AS reachability information) <xref
	<dt/>	format="default"/></li>
	<dd>TLV-223 (MT IS Neighbor Attribute) <xref format="	</ul>
	default"/></dd>	<t>Multiple Adj-SID sub-TLVs<bcp14>MAY</bcp14> be associated with asin
	<dt/>	gle
	<dd>TLV-141 (inter-AS reachability information) <xref
	format="default"/></dd>
	</dl>
	<t>Multiple Adj-SID sub-TLVsMAY be associated with asingle
	IS Neighbor.</t>	IS Neighbor.</t>


	<section anchor="ADJSIDSUBTLV" numbered="true" toc="default">	<section anchor="ADJSIDSUBTLV" numbered="true" toc="default">
	<name>Adjacency Segment Identifier (Adj-SID) Sub-TLV</name>	<name>Adjacency Segment Identifier (Adj-SID) Sub-TLV</name>


	<t>The following format is defined for the Adj-SID sub-TLV:</t>	<t>The following format is defined for the Adj-SID sub-TLV:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \| Weight \|	\| Type \| Length \| Flags \| Weight \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SID/Label/Index (variable) \|	\| SID/Label/Index (variable) \|

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
		<t>where:</t>
	where:]]></artwork>	<ul empty="true"><li>
	<dl newline="false"spacing="normal">	<dl newline="false"spacing="normal" indent="9">
	<dt/>	<dt>Type:</dt><dd>31</dd>
	<dd>Type: 31</dd>	<dt>Length:</dt><dd>5 or 6 depending on size of the SID</dd>
	<dt/>	<dt>Flags:</dt><dd><t>1-octet field of the followingflags:</t>
	<dd>Length: 5 or 6 depending on size of the SID</dd>	<artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2
	<dt/>	3 4 5 6 7
	<dd>
	<t>Flags: 1-octet field of the followingflags: </t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|F\|B\|V\|L\|S\|P\| \|	\|F\|B\|V\|L\|S\|P\| \|

	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+]]></artwork>
	]]></artwork>
	<t> where: </t>	<t> where: </t>

	<dl newline="false"spacing="normal">	<dl newline="false"spacing="normal" indent="9">
	<dt/>
	<dd>F-Flag: Address-Family flag. If unset, then theAdj-SID	<dt>F-Flag:</dt><dd>Address-Family flag. If unset, then theAdj-
		SID
	is used when forwarding IPv4-encapsulated traffic to the	is used when forwarding IPv4-encapsulated traffic to the
	neighbor. If set, then the Adj-SID is used when forwarding	neighbor. If set, then the Adj-SID is used when forwarding
	IPv6-encapsulated traffic to the neighbor.</dd>	IPv6-encapsulated traffic to the neighbor.</dd>

	<dt/>
	<dd>B-Flag: Backup flag. If set, the Adj-SID is eligible for	<dt>B-Flag:</dt><dd>Backup flag. If set, the Adj-SID is eligible
		for
	protection (e.g., using IP Fast Reroute (IPFRR) or MPLS Fast Reroute (MPLS-FRR)) as described in	protection (e.g., using IP Fast Reroute (IPFRR) or MPLS Fast Reroute (MPLS-FRR)) as described in
	<xref format="default"/>.</dd>	<xref format="default"/>.</dd>

	<dt/>
	<dd>V-Flag: Value flag. If set, then the Adj-SID carries a	<dt>V-Flag:</dt><dd>Value flag. If set, then the Adj-SID carries
		a
	value. By default, the flag is SET.</dd>	value. By default, the flag is SET.</dd>

	<dt/>
	<dd>L-Flag: Local Flag. If set, then the value/indexcarried	<dt>L-Flag:</dt><dd>Local Flag. If set, then the value/indexcar
		ried
	by the Adj-SID has local significance. By default, the flag	by the Adj-SID has local significance. By default, the flag
	is SET.</dd>	is SET.</dd>

	<dt/>
	<dd>S-Flag: Set flag. When set, the S-Flag indicatesthat the	<dt>S-Flag:</dt><dd>Set flag. When set, the S-Flag indicatestha
	Adj‑SID refers to a set of adjacencies (and thereforeMAY be	t the
		Adj-SID refers to a set of adjacencies (and therefore<bcp14>M
		AY</bcp14> be
	assigned to other adjacencies as well).</dd>	assigned to other adjacencies as well).</dd>

	<dt/>
	<dd>P-Flag: Persistent flag. When set, the P-Flagindicates	<dt>P-Flag:</dt><dd>Persistent flag. When set, the P-Flagindica
		tes
	that the Adj-SID is persistently allocated, i.e., the	that the Adj-SID is persistently allocated, i.e., the
	Adj-SID value remains consistent across router restart	Adj-SID value remains consistent across router restart
	and/or interface flap.</dd>	and/or interface flap.</dd>

	<dt/>
	<dd>Other bits: MUST be zero whenoriginated and ignored when	<dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero whenorigina
		ted and ignored when
	received.</dd>	received.</dd>
	</dl>	</dl>
	</dd>	</dd>

	<dt/>	</dl>
	<dd>Weight: 1 octet. The value represents the weight of the	</li>
		</ul>
		<ul empty="true">
		<li><dl newline="false" spacing="normal" indent="9">

		<dt>Weight:</dt><dd>1 octet. The value represents the weight of the
	Adj-SID for the purpose of load balancing. The use of the weight	Adj-SID for the purpose of load balancing. The use of the weight
	is defined in <xref format="default"/>.</dd>	is defined in <xref format="default"/>.</dd>

	<dt/>	</dl>
	<dd>SID/Index/Label as defined in <xrefformat="	</li>
	default"/>.</dd>	</ul>
	<dt/>
	<dd>An SR-capable routerMAY allocate an Adj-SID for each of its	<ul empty="true">
	adjacencies.</dd>	<li>SID/Index/Label as defined in <xrefformat="defa
	<dt/>	ult"/>.</li>
	<dd>An SR-capable routerMAY allocate more than oneAdj-SID to an
	adjacency.</dd>	<li>An SR-capable router<bcp14>MAY</bcp14> allocate an Adj-SID for
	<dt/>	each of its
	<dd>An SR-capable routerMAY allocate the sameAdj-SID to	adjacencies.</li>
	differentadjacencies.</dd>
	<dt/>	<li>An SR-capable router<bcp14>MAY</bcp14> allocate more than oneA
	<dd>When the P-flag is not set, the Adj-SIDMAY bepersistent.	dj-SID to an
	When the P-flag is set, the Adj-SIDMUST bepersistent.</dd>	adjacency.</li>
	<dt/>
	<dd>Examples of Adj-SID sub-TLV use are described in <xrefformat="default"/>.</dd>	D to
	<dt/>	differentadjacencies.</li>
	<dd>The F-flag is used in order for the router to advertise the
		<li>When the P-flag is not set, the Adj-SID<bcp14>MAY</bcp14> bepe
		rsistent.
		When the P-flag is set, the Adj-SID<bcp14>MUST</bcp14> bepersist
		ent.</li>

		<li>Examples of Adj-SID sub-TLV use are described in <xrefformat="default"/>.</li>

		<li>The F-flag is used in order for the router to advertise the
	outgoing encapsulation of the adjacency the Adj-SID is attached	outgoing encapsulation of the adjacency the Adj-SID is attached

	to.</dd>	to.</li>
	</dl>	</ul>
	</section>	</section>


	<section anchor="LANADJSIDSUBTLV" numbered="true" toc="default">	<section anchor="LANADJSIDSUBTLV" numbered="true" toc="default">
	<name>Adjacency Segment Identifiers in LANs</name>	<name>Adjacency Segment Identifiers in LANs</name>
	<t>In LAN subnetworks, the Designated Intermediate System (DIS) is	<t>In LAN subnetworks, the Designated Intermediate System (DIS) is
	elected and originates the Pseudonode LSP (PN LSP) including all	elected and originates the Pseudonode LSP (PN LSP) including all
	neighbors of the DIS.</t>	neighbors of the DIS.</t>

	<t>When Segment Routing is used, each router in the LANMAY	<t>When Segment Routing is used, each router in the LAN<bcp14>MAY</bcp14>
	advertise the Adj-SID of each of its neighbors. Since, on LANs, each	advertise the Adj-SID of each of its neighbors. Since, on LANs, each
	router only advertises one adjacency to the DIS (and doesn't	router only advertises one adjacency to the DIS (and doesn't
	advertise any other adjacency), each router advertises the set of	advertise any other adjacency), each router advertises the set of
	Adj-SIDs (for each of its neighbors) inside a newly defined sub-TLV	Adj-SIDs (for each of its neighbors) inside a newly defined sub-TLV
	that is a part of the TLV advertising the adjacency to the DIS (e.g.,	that is a part of the TLV advertising the adjacency to the DIS (e.g.,
	TLV-22).</t>	TLV-22).</t>
	<t>The following new sub-TLV is defined: LAN-Adj-SID containing the	<t>The following new sub-TLV is defined: LAN-Adj-SID containing the
	set of Adj-SIDs the router assigned to each of its LAN	set of Adj-SIDs the router assigned to each of its LAN
	neighbors.</t>	neighbors.</t>
	<t>The format of the LAN-Adj-SID sub-TLV is as follows:</t>	<t>The format of the LAN-Adj-SID sub-TLV is as follows:</t>

	skipping to change at line 500 ¶	skipping to change at line 512 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Neighbor System-ID (ID length octets) \|	\| Neighbor System-ID (ID length octets) \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SID/Label/Index (variable) \|	\| SID/Label/Index (variable) \|

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
		<ul empty="true"><li><t>where:</t>
		<dl newline="false" spacing="normal" indent="9">


	where: ]]></artwork>	<dt>Type:</dt><dd>32</dd>
	<dl newline="false" spacing="normal">
	<dt/>	<dt>Length:</dt><dd>Variable</dd>
	<dd>Type: 32</dd>
	<dt/>	<dt>Flags:</dt><dd><t> 1-octet field of the followingflags:</t>
	<dd>Length: Variable</dd>
	<dt/>	<artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2
	<dd>	3 4 5 6 7
	<t>Flags: 1-octet field of the followingflags: </t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|F\|B\|V\|L\|S\|P\| \|	\|F\|B\|V\|L\|S\|P\| \|

	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+]]></artwork>
	]]></artwork>
	<t> where the F, B, V, L, S, and P flags are defined in <xref target="ADJSIDSUBTLV" format="default"/>. </t>	<t> where the F, B, V, L, S, and P flags are defined in <xref target="ADJSIDSUBTLV" format="default"/>. </t>

	</dd>	</dd>
	<dt/>	</dl>
	<dd>	</li>
	Other bits: MUST be zero when	</ul>
		<ul empty="true"><li>
		<dl newline="false" spacing="normal" indent="13">
		<dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero when
	originated and ignored when received.</dd>	originated and ignored when received.</dd>

	<dt/>
	<dd>Weight: 1 octet. The value represents the weight of the	<dt>Weight:</dt><dd>1 octet. The value represents the weight of the
	Adj-SID for the purpose of load balancing. The use of the weight	Adj-SID for the purpose of load balancing. The use of the weight
	is defined in <xref format="default"/>.</dd>	is defined in <xref format="default"/>.</dd>

	<dt/>
	<dd>Neighbor System-ID: IS-IS System-ID of length "IDLength" as	<dt>Neighbor System-ID:</dt><dd>IS-IS System-ID of length "IDLength
		" as
	defined in <xref format="default"/>.</dd>	defined in <xref format="default"/>.</dd>

	<dt/>
	<dd>SID/Index/Label: As defined in <xrefformat=	<dt>SID/Index/Label:</dt><dd>As defined in <xref
	"default"/>.</dd>	format="default"/>.</dd>
	</dl>	</dl>

	<t>Multiple LAN-Adj-SID sub-TLVsMAY be encoded.</t>	</li>
	<t>Note that this sub-TLVMUST NOT appear in TLV141.</t>	</ul>

		<t>Multiple LAN-Adj-SID sub-TLVs<bcp14>MAY</bcp14> be encoded.</t>
		<t>Note that this sub-TLV<bcp14>MUST NOT</bcp14> appear in TLV141.</
		t>
	<t>In case TLV-22, TLV-23, TLV-222, or TLV-223 (reporting the adjacency to the	<t>In case TLV-22, TLV-23, TLV-222, or TLV-223 (reporting the adjacency to the
	DIS) can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple	DIS) can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple

	advertisements of the adjacency to the DISMUST beused, and all	advertisements of the adjacency to the DIS<bcp14>MUST</bcp14> beused
	advertisementsMUST have the same metric.</t>	, and all
		advertisements<bcp14>MUST</bcp14> have the same metric.</t>
	<t>Each router within the level, by receiving the DIS PN LSP as well	<t>Each router within the level, by receiving the DIS PN LSP as well
	as the non-PN LSP of each router in the LAN, is capable of	as the non-PN LSP of each router in the LAN, is capable of
	reconstructing the LAN topology as well as the set of Adj-SIDs each	reconstructing the LAN topology as well as the set of Adj-SIDs each
	router uses for each of its neighbors.</t>	router uses for each of its neighbors.</t>
	</section>	</section>
	</section>	</section>


	<section anchor="SIDLABELSUBTLV" numbered="true" toc="default">	<section anchor="SIDLABELSUBTLV" numbered="true" toc="default">
	<name>SID/Label Sub-TLV</name>	<name>SID/Label Sub-TLV</name>
	<t>The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs	<t>The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs
	defined in this document:</t>	defined in this document:</t>

	<t>SR-Capabilities sub-TLV (<xrefformat="default"/	<ul empty="true">
	>)</t>	<li>SR-Capabilities sub-TLV (<xrefformat="default"
	<t>SR Local Block sub-TLV (<xrefformat="default"/>)	/>)</li>
	</t>	<li>SR Local Block sub-TLV (<xrefformat="default"/>
	<t>SID/Label Binding TLV (<xrefformat="default"/>)<	)</li>
	/t>	<li>SID/Label Binding TLV (<xrefformat="default"/>)
	<t>Multi-Topology SID/Label Binding TLV (<xreffor	</li>
	mat="default"/>)</t>	<li>Multi-Topology SID/Label Binding TLV (<xreffo
		rmat="default"/>)</li>
		</ul>

	<t>Note that the code point used in all of the above cases is the	<t>Note that the code point used in all of the above cases is the
	SID/Label sub-TLV code point specified in the new "sub-TLVs for	SID/Label sub-TLV code point specified in the new "sub-TLVs for
	TLV 149 and 150" registry created by this document.</t>	TLV 149 and 150" registry created by this document.</t>
	<t>The SID/Label sub-TLV contains a SID or an MPLS label. The SID/Label	<t>The SID/Label sub-TLV contains a SID or an MPLS label. The SID/Label
	sub-TLV has the following format: </t>	sub-TLV has the following format: </t>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \|	\| Type \| Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SID/Label (variable) \|	\| SID/Label (variable) \|

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
		<t>where:</t>
		<ul empty="true"><li>
		<dl newline="false" spacing="normal" indent="12">


	where:]]></artwork>	<dt>Type:</dt><dd>1</dd>
	<ul empty="true" spacing="normal">
	<li>Type: 1</li>	<dt>Length:</dt><dd>3 or4</dd>
	<li>Length: 3 or4</li>
	<li>SID/Label: If the length is set to 3, then the 20rightmost bits	<dt>SID/Label:</dt><dd>If the length is set to 3, then the 20rightmos
		t bits
	represent an MPLS label. If the length is set to 4, then the value is a	represent an MPLS label. If the length is set to 4, then the value is a

	32-bitindex.</li>	32-bitindex.</dd>
	</ul>	</dl>
		</li>
		</ul>
	</section>	</section>


	<section anchor="BINDINGTLV" numbered="true" toc="default">	<section anchor="BINDINGTLV" numbered="true" toc="default">
	<name>SID/Label Binding TLV</name>	<name>SID/Label Binding TLV</name>

	<t>The SID/Label Binding TLVMAY be originated by any router in an	<t>The SID/Label Binding TLV<bcp14>MAY</bcp14> be originated by any router in an
	IS-IS domain. There are multiple uses of the SID/Label Binding	IS-IS domain. There are multiple uses of the SID/Label Binding
	TLV.</t>	TLV.</t>
	<t>The SID/Label Binding TLV may be used to advertise prefixes to	<t>The SID/Label Binding TLV may be used to advertise prefixes to
	SID/Label mappings. This functionality is called the Segment Routing	SID/Label mappings. This functionality is called the Segment Routing
	Mapping Server (SRMS). The behavior of the SRMS is defined in <xref target="RFC8661" format="default"/>.</t>	Mapping Server (SRMS). The behavior of the SRMS is defined in <xref target="RFC8661" format="default"/>.</t>
	<t>The SID/Label Binding TLV may also be used to advertise a Mirror	<t>The SID/Label Binding TLV may also be used to advertise a Mirror
	SID indicating the ability of a node to process traffic originally destined to	SID indicating the ability of a node to process traffic originally destined to
	another IGP node. This behavior is defined in <xref format="default"/>.</t>	another IGP node. This behavior is defined in <xref format="default"/>.</t>
	<t>The SID/Label Binding TLV has the following format:</t>	<t>The SID/Label Binding TLV has the following format:</t>


	<figure anchor="SID-MPLS-Binding-TLV-figure">	<figure anchor="SID-MPLS-Binding-TLV-figure">
	<name>SID/Label Binding TLV Format</name>	<name>SID/Label Binding TLV Format</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \| Flags \| RESERVED \|	\| Type \| Length \| Flags \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Range \| Prefix Length \| Prefix \|	\| Range \| Prefix Length \| Prefix \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	skipping to change at line 601 ¶	skipping to change at line 627 ¶
	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 \| Flags \| RESERVED \|	\| Type \| Length \| Flags \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Range \| Prefix Length \| Prefix \|	\| Range \| Prefix Length \| Prefix \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Prefix (continued, variable) //	// Prefix (continued, variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Sub-TLVs (variable) \|	\| Sub-TLVs (variable) \|

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
	]]></artwork>	</figure>
	</figure>
	<ul spacing="normal">	<ul spacing="normal">
	<li>Type: 149</li>	<li>Type: 149</li>
	<li>Length: Variable</li>	<li>Length: Variable</li>
	<li>1 octet of flags</li>	<li>1 octet of flags</li>

	<li>1 octet of RESERVED (SHOULD be transmitted as 0 and MUST be	<li>1 octet of RESERVED (<bcp14>SHOULD</bcp14> be transmitted as 0 and <bcp14>MUST</bcp14> be
	ignored on receipt)</li>	ignored on receipt)</li>
	<li>2 octets of Range</li>	<li>2 octets of Range</li>
	<li>1 octet of Prefix Length</li>	<li>1 octet of Prefix Length</li>
	<li>0-16 octets of prefix</li>	<li>0-16 octets of prefix</li>
	<li>	<li>
	<t>sub-TLVs, where each sub-TLV consists of a sequence of: </t>	<t>sub-TLVs, where each sub-TLV consists of a sequence of: </t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>1 octet of sub-TLV type</li>	<li>1 octet of sub-TLV type</li>
	<li>1 octet of length of the value field of the sub-TLV</li>	<li>1 octet of length of the value field of the sub-TLV</li>
	<li>0-243 octets of value</li>	<li>0-243 octets of value</li>
	</ul>	</ul>
	</li>	</li>
	</ul>	</ul>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Flags</name>	<name>Flags</name>
	<t>Flags: 1-octet field of the following flags:</t>	<t>Flags: 1-octet field of the following flags:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|F\|M\|S\|D\|A\| \|	\|F\|M\|S\|D\|A\| \|

	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+]]></artwork>
	]]></artwork>
	<t> where: </t>	<t> where: </t>

	<dl newline="false"spacing="normal">	<ul empty="true"><li>
	<dt/>	<dl newline="false"spacing="normal" indent="9">
	<dd>F-Flag: Address-Family flag. If unset, then the prefix
		<dt>F-Flag:</dt><dd>Address-Family flag. If unset, then the prefix
	carries an IPv4 Prefix. If set, then the Prefix carries an IPv6	carries an IPv4 Prefix. If set, then the Prefix carries an IPv6
	Prefix.</dd>	Prefix.</dd>

	<dt/>
	<dd>M-Flag: Mirror Context flag. Set if the advertised SID	<dt>M-Flag:</dt><dd>Mirror Context flag. Set if the advertised SID
	corresponds to a mirrored context. The use of a mirrored context	corresponds to a mirrored context. The use of a mirrored context
	is described in <xref format="default"/>.</dd>	is described in <xref format="default"/>.</dd>

	<dt/>
	<dd>S-Flag: If set, the SID/Label Binding TLVSHOULD be flooded	<dt>S-Flag:</dt><dd>If set, the SID/Label Binding TLV<bcp14>SHOULD<
		/bcp14> be flooded
	across the entire routing domain. If the S flag is not set, the	across the entire routing domain. If the S flag is not set, the

	SID/Label Binding TLVMUST NOT be leaked betweenlevels. This	SID/Label Binding TLV<bcp14>MUST NOT</bcp14> be leaked betweenle
	bitMUST NOT be altered during the TLVleaking.</dd>	vels. This
	<dt/>	bit<bcp14>MUST NOT</bcp14> be altered during the TLVleaking.</dd
	<dd>D-Flag: When the SID/Label Binding TLV is leaked fromLevel-2	>
	to Level-1, the D-FlagMUST be set. Otherwise, this flagMUST be
	clear. SID/Label Binding TLVs with the D-Flag setMUST NOT be	<dt>D-Flag:</dt><dd>When the SID/Label Binding TLV is leaked fromLe
		vel-2
		to Level-1, the D-Flag<bcp14>MUST</bcp14> be set. Otherwise, this
		flag<bcp14>MUST</bcp14> be
		clear. SID/Label Binding TLVs with the D-Flag set<bcp14>MUST NOT<
		/bcp14> be
	leaked from Level-1 to Level-2. This is to prevent TLV looping	leaked from Level-1 to Level-2. This is to prevent TLV looping
	across levels.</dd>	across levels.</dd>

	<dt/>
	<dd>A-Flag: Attached flag. The originator of the SID/Label	<dt>A-Flag:</dt><dd>Attached flag. The originator of the SID/Label
	Binding TLVMAY set the A bit in order to signalthat the	Binding TLV<bcp14>MAY</bcp14> set the A bit in order to signalth
		at the
	prefixes and SIDs advertised in the SID/Label Binding TLV are	prefixes and SIDs advertised in the SID/Label Binding TLV are
	directly connected to their originators. The mechanisms through	directly connected to their originators. The mechanisms through
	which the originator of the SID/Label Binding TLV can figure out	which the originator of the SID/Label Binding TLV can figure out
	if a prefix is attached or not are outside the scope of this	if a prefix is attached or not are outside the scope of this
	document (e.g., through explicit configuration). If the Binding	document (e.g., through explicit configuration). If the Binding

	TLV is leaked to other areas/levels, the A-flagMUST be	TLV is leaked to other areas/levels, the A-flag<bcp14>MUST</bcp14> be
	cleared.</dd>	cleared.</dd>

	<dt/>	</dl>
	<dd>An implementation may decide not to honor the S-flag in order	</li>
		</ul>

		<ul empty="true">
		<li>An implementation may decide not to honor the S-flag in order
	to not leak Binding TLVs between levels (for policy	to not leak Binding TLVs between levels (for policy

	reasons).</dd>	reasons).</li></ul>
	<dt/>
	<dd>Other bits: MUST be zero when originated and ignored when	<ul empty="true"><li>
		<dl>
		<dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero when originated
		and ignored when
	received.</dd>	received.</dd>

	</dl>	</dl>
		</li>
		</ul>

	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Range</name>	<name>Range</name>
	<t>The 'Range' field provides the ability to specify a range of	<t>The 'Range' field provides the ability to specify a range of
	addresses and their associated Prefix SIDs. This advertisement	addresses and their associated Prefix SIDs. This advertisement
	supports the SRMS functionality. It is essentially a compression	supports the SRMS functionality. It is essentially a compression
	scheme to distribute a continuous prefix and their continuous,	scheme to distribute a continuous prefix and their continuous,
	corresponding SID/Label Block. If a single SID is advertised, then	corresponding SID/Label Block. If a single SID is advertised, then

	the Range fieldMUST be set to one. For rangeadvertisements > 1,	the Range field<bcp14>MUST</bcp14> be set to one. For rangeadvertise
	the Range fieldMUST be set to the number of addresses that need to	ments > 1,
		the Range field<bcp14>MUST</bcp14> be set to the number of addresses
		that need to
	be mapped into a Prefix-SID. In either case, the prefix is the first	be mapped into a Prefix-SID. In either case, the prefix is the first
	address to which a SID is to be assigned.</t>	address to which a SID is to be assigned.</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Prefix Length, Prefix</name>	<name>Prefix Length, Prefix</name>
	<t>The 'Prefix' represents the Forwarding Equivalence Class at the	<t>The 'Prefix' represents the Forwarding Equivalence Class at the
	tail end of the advertised path. The 'Prefix' does not need to	tail end of the advertised path. The 'Prefix' does not need to
	correspond to a routable prefix of the originating node.</t>	correspond to a routable prefix of the originating node.</t>
	<t>The 'Prefix Length' field contains the length of the prefix in	<t>The 'Prefix Length' field contains the length of the prefix in
	bits. Only the most significant octets of the prefix are encoded	bits. Only the most significant octets of the prefix are encoded
	(i.e., 1 octet for prefix length 1 up to 8, 2 octets for prefix	(i.e., 1 octet for prefix length 1 up to 8, 2 octets for prefix
	length 9 to up 16, 3 octets for prefix length 17 up to 24, 4 octets	length 9 to up 16, 3 octets for prefix length 17 up to 24, 4 octets
	for prefix length 25 up to 32, ...., and 16 octets for prefix length 113	for prefix length 25 up to 32, ...., and 16 octets for prefix length 113
	up to 128).</t>	up to 128).</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Mapping Server Prefix-SID</name>	<name>Mapping Server Prefix-SID</name>
	<t>The Prefix-SID sub-TLV is defined in <xref format="default"/> and contains the SID/Index/Label value	<t>The Prefix-SID sub-TLV is defined in <xref format="default"/> and contains the SID/Index/Label value

	associated with the prefix and range. The Prefix-SID sub-TLVMUST be	associated with the prefix and range. The Prefix-SID sub-TLV<bcp14>MUST</bcp14> be
	present in the SID/Label Binding TLV when the M-flag is clear. The	present in the SID/Label Binding TLV when the M-flag is clear. The

	Prefix-SID sub-TLVMUST NOT be present when the M-flagis set.</t>	Prefix-SID sub-TLV<bcp14>MUST NOT</bcp14> be present when the M-flagis set.</t>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Prefix-SID Flags</name>	<name>Prefix-SID Flags</name>

	<t>The Prefix-SID flags are defined in <xref format="default"/>. The Mapping ServerMAY advertise a	<t>The Prefix-SID flags are defined in <xref format="default"/>. The Mapping Server<bcp14>MAY</bcp14> advertise a
	mapping with the N flag set when the prefix being mapped is known	mapping with the N flag set when the prefix being mapped is known
	in the link-state topology with a mask length of 32 (IPv4) or 128	in the link-state topology with a mask length of 32 (IPv4) or 128
	(IPv6) and when the prefix represents a node. The mechanisms	(IPv6) and when the prefix represents a node. The mechanisms
	through which the operator defines that a prefix represents a node	through which the operator defines that a prefix represents a node
	are outside the scope of this document (typically it will be	are outside the scope of this document (typically it will be
	through configuration).</t>	through configuration).</t>
	<t>The other flags defined in <xref format="default"/> are	<t>The other flags defined in <xref format="default"/> are

	not used by the Mapping Server andMUST be ignored at	not used by the Mapping Server and<bcp14>MUST</bcp14> be ignored at
	reception.</t>	reception.</t>
	</section>	</section>
	<section anchor="MSPHP" numbered="true" toc="default">	<section anchor="MSPHP" numbered="true" toc="default">
	<name>PHP Behavior when Using Mapping Server Advertisements</name>	<name>PHP Behavior when Using Mapping Server Advertisements</name>
	<t>As the mapping server does not specify the originator of a	<t>As the mapping server does not specify the originator of a
	prefix advertisement, it is not possible to determine PHP behavior	prefix advertisement, it is not possible to determine PHP behavior
	solely based on the Mapping Server Advertisement. However, if	solely based on the Mapping Server Advertisement. However, if
	additional information is available, PHP behavior may safely be	additional information is available, PHP behavior may safely be
	done. The required information consists of:</t>	done. The required information consists of:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>A prefix reachability advertisement for the prefix has been	<li>A prefix reachability advertisement for the prefix has been
	received, which includes the Prefix Attribute Flags sub-TLV	received, which includes the Prefix Attribute Flags sub-TLV
	<xref format="default"/>.</li>	<xref format="default"/>.</li>
	<li>X and R flags are both set to 0 in the Prefix Attribute	<li>X and R flags are both set to 0 in the Prefix Attribute
	Flags sub-TLV.</li>	Flags sub-TLV.</li>
	</ul>	</ul>
	<t>In the absence of a Prefix Attribute Flags sub-TLV <xref format="default"/>, the A flag in the binding TLV indicates that	<t>In the absence of a Prefix Attribute Flags sub-TLV <xref format="default"/>, the A flag in the binding TLV indicates that
	the originator of a prefix reachability advertisement is directly	the originator of a prefix reachability advertisement is directly

	connected to the prefix; thus, PHPMUST be done by the neighbors	connected to the prefix; thus, PHP<bcp14>MUST</bcp14> be done by the neighbors
	of the router originating the prefix reachability advertisement.	of the router originating the prefix reachability advertisement.
	Note that the A-flag is only valid in the original area in which the	Note that the A-flag is only valid in the original area in which the
	Binding TLV is advertised.</t>	Binding TLV is advertised.</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Prefix-SID Algorithm</name>	<name>Prefix-SID Algorithm</name>
	<t>The Algorithm field contains the identifier of the algorithm	<t>The Algorithm field contains the identifier of the algorithm
	associated with the SIDs for the prefix(es) in the range. Use of	associated with the SIDs for the prefix(es) in the range. Use of
	the Algorithm field is described in <xref format="default"/>.</t>	the Algorithm field is described in <xref format="default"/>.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="BSIDSUBTLV" numbered="true" toc="default">	<section anchor="BSIDSUBTLV" numbered="true" toc="default">
	<name>SID/Label Sub-TLV</name>	<name>SID/Label Sub-TLV</name>
	<t>The SID/Label sub-TLV (Type: 1) contains the SID/Label value as	<t>The SID/Label sub-TLV (Type: 1) contains the SID/Label value as

	defined in <xref format="default"/>. ItMUST be present in	defined in <xref format="default"/>. It<bcp14>MUST</bcp14> be present in
	the SID/Label Binding TLV when the M-flag is set in the Flags field	the SID/Label Binding TLV when the M-flag is set in the Flags field
	of the parent TLV.</t>	of the parent TLV.</t>
	</section>	</section>
	<section anchor="BSIDEXAMPLE" numbered="true" toc="default">	<section anchor="BSIDEXAMPLE" numbered="true" toc="default">
	<name>Example Encodings</name>	<name>Example Encodings</name>
	<t>Example 1: If the following IPv4 router addresses (loopback	<t>Example 1: If the following IPv4 router addresses (loopback
	addresses) need to be mapped into the corresponding Prefix SID	addresses) need to be mapped into the corresponding Prefix SID
	indexes, then: </t>	indexes, then: </t>

	<artwork name="" type="" align="left" alt=""><![CDATA[
	Router-A: 192.0.2.1/32, Prefix-SID: Index1	<ul empty="true">
	Router-B: 192.0.2.2/32, Prefix-SID: Index2	<li>Router-A: 192.0.2.1/32, Prefix-SID: Index1</li>
	Router-C: 192.0.2.3/32, Prefix-SID: Index3	<li>Router-B: 192.0.2.2/32, Prefix-SID: Index2</li>
	Router-D: 192.0.2.4/32, Prefix-SID: Index4	<li>Router-C: 192.0.2.3/32, Prefix-SID: Index3</li>
	]]></artwork>	<li>Router-D: 192.0.2.4/32, Prefix-SID: Index4</li>
		</ul>

	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \|0\|0\|0\|0\|0\| \| RESERVED \|	\| Type \| Length \|0\|0\|0\|0\|0\| \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Range = 4 \| 32 \| 192 \|	\| Range = 4 \| 32 \| 192 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 0 \| 2 \| 1 \|Prefix-SID Type\|	\| 0 \| 2 \| 1 \|Prefix-SID Type\|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Sub-TLV Length\| Flags \| Algorithm \| \|	\| Sub-TLV Length\| Flags \| Algorithm \| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 1 \|	\| 1 \|

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
	]]></artwork>
	<t>Example 2: If the following IPv4 prefixes need to be mapped into	<t>Example 2: If the following IPv4 prefixes need to be mapped into
	the corresponding Prefix-SID indexes, then: </t>	the corresponding Prefix-SID indexes, then: </t>

	<artwork name="" type="" align="left" alt=""><![CDATA[
	10.1.1/24, Prefix-SID: Index51	<ul empty="true">
	10.1.2/24, Prefix-SID: Index52	<li>10.1.1/24, Prefix-SID: Index51</li>
	10.1.3/24, Prefix-SID: Index53	<li>10.1.2/24, Prefix-SID: Index52</li>
	10.1.4/24, Prefix-SID: Index54	<li>10.1.3/24, Prefix-SID: Index53</li>
	10.1.5/24, Prefix-SID: Index55	<li>10.1.4/24, Prefix-SID: Index54</li>
	10.1.6/24, Prefix-SID: Index56	<li>10.1.5/24, Prefix-SID: Index55</li>
	10.1.7/24, Prefix-SID: Index57	<li>10.1.6/24, Prefix-SID: Index56</li>
	]]></artwork>	<li>10.1.7/24, Prefix-SID: Index57</li>
		</ul>

	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \|0\|0\|0\|0\|0\| \| RESERVED \|	\| Type \| Length \|0\|0\|0\|0\|0\| \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Range = 7 \| 24 \| 10 \|	\| Range = 7 \| 24 \| 10 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 1 \| 1 \|Prefix-SID Type\| Sub-TLV Length\|	\| 1 \| 1 \|Prefix-SID Type\| Sub-TLV Length\|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Flags \| Algorithm \| \|	\| Flags \| Algorithm \| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 51 \|	\| 51 \|

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
	]]></artwork>
	<t>Example 3: If the following IPv6 prefixes need to be mapped into	<t>Example 3: If the following IPv6 prefixes need to be mapped into
	the corresponding Prefix-SID indexes, then: </t>	the corresponding Prefix-SID indexes, then: </t>

	<artwork name="" type="" align="left" alt=""><![CDATA[
	2001:db8:1/48, Prefix-SID: Index151	<ul empty="true">
	2001:db8:2/48, Prefix-SID: Index152	<li>2001:db8:1/48, Prefix-SID: Index151</li>
	2001:db8:3/48, Prefix-SID: Index153	<li>2001:db8:2/48, Prefix-SID: Index152</li>
	2001:db8:4/48, Prefix-SID: Index154	<li>2001:db8:3/48, Prefix-SID: Index153</li>
	]]></artwork>	<li>2001:db8:4/48, Prefix-SID: Index154</li>
		</ul>

	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \|1\|0\|0\|0\|0\| \| RESERVED \|	\| Type \| Length \|1\|0\|0\|0\|0\| \| RESERVED \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Range = 4 \| 48 \| 0x20 \|	\| Range = 4 \| 48 \| 0x20 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 0x01 \| 0x0d \| 0xb8 \| 0x00 \|	\| 0x01 \| 0x0d \| 0xb8 \| 0x00 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 0x01 \|Prefix-SID Type\| Sub-TLV Length\| Flags \|	\| 0x01 \|Prefix-SID Type\| Sub-TLV Length\| Flags \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Algorithm \| 0 \|	\| Algorithm \| 0 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 151 \|	\| 151 \|
	+-+-+-+-+-+-+-+-+]]></artwork>	+-+-+-+-+-+-+-+-+]]></artwork>
	<t>It is not expected that a network operator will be able to keep	<t>It is not expected that a network operator will be able to keep
	fully continuous Prefix/SID/Index mappings. In order to support	fully continuous Prefix/SID/Index mappings. In order to support

	noncontinuous mapping ranges, an implementationMAY generate several	noncontinuous mapping ranges, an implementation<bcp14>MAY</bcp14> generate several
	instances of Binding TLVs.</t>	instances of Binding TLVs.</t>
	<t>For example, if a router wants to advertise the following ranges:	<t>For example, if a router wants to advertise the following ranges:
	</t>	</t>

		<ul empty="true"><li>
	<dl newline="false" spacing="normal">	<dl newline="false" spacing="normal">

	<dt/>
	<dd>Range 16: { 192.0.2.1-15, Index 1-15 }</dd>	<dt>Range 16:</dt><dd>{ 192.0.2.1-15, Index 1-15 }</dd>
	<dt/>
	<dd>Range 6: { 192.0.2.22-27, Index 22-27 }</dd>	<dt>Range 6:</dt><dd>{ 192.0.2.22-27, Index 22-27 }</dd>
	<dt/>
	<dd>Range 41: { 192.0.2.44-84, Index 80-120 }</dd>	<dt>Range 41:</dt><dd>{ 192.0.2.44-84, Index 80-120 }</dd>
	</dl>	</dl>

		</li>
		</ul>
	<t> A router would need to advertise three instances of the	<t> A router would need to advertise three instances of the
	Binding TLV.</t>	Binding TLV.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="MTBINDINGTLV" numbered="true" toc="default">	<section anchor="MTBINDINGTLV" numbered="true" toc="default">
	<name>Multi-Topology SID/Label Binding TLV</name>	<name>Multi-Topology SID/Label Binding TLV</name>
	<t>The Multi-Topology SID/Label Binding TLV allows the support of	<t>The Multi-Topology SID/Label Binding TLV allows the support of
	Multi-Topology IS-IS (M-ISIS) as defined in <xref format="default"/>. The Multi-Topology	Multi-Topology IS-IS (M-ISIS) as defined in <xref format="default"/>. The Multi-Topology
	SID/Label Binding TLV has the same format as the SID/Label Binding TLV	SID/Label Binding TLV has the same format as the SID/Label Binding TLV
	defined in <xref format="default"/> with the difference consisting	defined in <xref format="default"/> with the difference consisting

	of a Multitopology Identifier (MTID) as defined here below:</t>	of a Multitopology Identifier (MTID) as defined here below:</t>
	<figure anchor="MTBINDINGTLVFIG">	<figure anchor="MTBINDINGTLVFIG">
	<name>Multi-Topology SID/Label Binding TLV format</name>	<name>Multi-Topology SID/Label Binding TLV format</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	\| Type \| Length \| MTID \|	\| Type \| Length \| MT ID \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Flags \| RESERVED \| Range \|	\| Flags \| RESERVED \| Range \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Prefix Length \| Prefix (variable) //	\| Prefix Length \| Prefix (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Sub-TLVs (variable) \|	\| Sub-TLVs (variable) \|

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
	]]></artwork>
	</figure>	</figure>

	<t>where: </t>	<t>where: </t>
	<dl newline="false"spacing="normal">	<ul empty="true"><li>
	<dt/>	<dl newline="false"spacing="normal" indent="9">
	<dd>Type: 150</dd>
	<dt/>	<dt>Type:</dt><dd>150</dd>
	<dd>Length: Variable</dd>
	<dt/>	<dt>Length:</dt><dd>Variable</dd>
	<dd>	</dl>
	<t>MTID is the multitopology identifier definedas: </t>
		<t>MT ID is the multitopology identifier definedas:</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1	0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	\| RESVD \|MTID \|	\| RESVD \|MT ID \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
	]]></artwork>	<ul empty="true"><li>
	<dl newline="false"spacing="normal">	<dl newline="false"spacing="normal" indent="9">
	<dt/>
	<dd>RESVD: Reserved bits.MUST be reset on transmission and	<dt>RESVD:</dt><dd>Reserved bits.<bcp14>MUST</bcp14> be reset on
		transmission and
	ignored on receive.</dd>	ignored on receive.</dd>

	<dt/>
	<dd>MTID: A 12-bit field containing the non-zero ID ofthe	<dt>MT ID:</dt><dd>A 12-bit field containing the non-zero ID ofth
	topology being announced. The TLVMUST be ignored if the ID is	e
		topology being announced. The TLV<bcp14>MUST</bcp14> be ignored
		if the ID is
	zero. This is to ensure the consistent view of the standard	zero. This is to ensure the consistent view of the standard
	unicast topology.</dd>	unicast topology.</dd>

	</dl>
	</dd>	</dl>
	<dt/>	</li>
	<dd>The other fields and sub-TLVs are defined in <xreftarget="BINDING	</ul>
	TLV" format="default"/>.</dd>	</li>
	</dl>	</ul>

		<ul empty="true"><li>
		<t>The other fields and sub-TLVs are defined in <xreftarget="BINDINGT
		LV" format="default"/>.</t>
		</li></ul>

	</section>	</section>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Router Capabilities</name>	<name>Router Capabilities</name>
	<t>This section defines sub-TLVs that are inserted into the IS-IS	<t>This section defines sub-TLVs that are inserted into the IS-IS
	Router Capability that is defined in <xref format="default"/>.</t>	Router Capability that is defined in <xref format="default"/>.</t>
	<section anchor="SRCAPSUBTLV" numbered="true" toc="default">	<section anchor="SRCAPSUBTLV" numbered="true" toc="default">
	<name>SR-Capabilities Sub-TLV</name>	<name>SR-Capabilities Sub-TLV</name>
	<t>Segment Routing requires each router to advertise its SR data plane	<t>Segment Routing requires each router to advertise its SR data plane
	capability and the range of MPLS label values it uses for Segment	capability and the range of MPLS label values it uses for Segment
	Routing in the case where global SIDs are allocated (i.e., global	Routing in the case where global SIDs are allocated (i.e., global
	indexes). Data plane capabilities and label ranges are advertised	indexes). Data plane capabilities and label ranges are advertised
	using the newly defined SR-Capabilities sub-TLV.</t>	using the newly defined SR-Capabilities sub-TLV.</t>
	<t>The Router Capability TLV specifies flags that control its	<t>The Router Capability TLV specifies flags that control its

	advertisement. The SR-Capabilities sub-TLVMUST bepropagated	advertisement. The SR-Capabilities sub-TLV<bcp14>MUST</bcp14> bepropag
	throughout the level andMUST NOT be advertised acrosslevel	ated
		throughout the level and<bcp14>MUST NOT</bcp14> be advertised acrossle
		vel
	boundaries. Therefore, Router Capability TLV distribution flags are set	boundaries. Therefore, Router Capability TLV distribution flags are set

	accordingly, i.e., the S flag in the Router Capability TLV <xref target="RFC7981" format="default"/>MUST be unset.</t>	accordingly, i.e., the S flag in the Router Capability TLV <xref target="RFC7981" format="default"/><bcp14>MUST</bcp14> be unset.</t>
	<t>The SR-Capabilities sub-TLV has the following format:</t>	<t>The SR-Capabilities sub-TLV has the following format:</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[ 0	<artwork name="" type="" align="left" alt=""><![CDATA[
	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 \| Flags \|	\| Type \| Length \| Flags \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Range \|	\| Range \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// SID/Label Sub-TLV (variable) //	// SID/Label Sub-TLV (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

	<dl newline="false"spacing="normal">	<ul empty="true"><li>
	<dt/>	<dl newline="false"spacing="normal" indent="9">
	<dd>Type: 2</dd>	<dt>Type:</dt><dd>2</dd>
	<dt/>
	<dd>Length: Variable</dd>	<dt>Length:</dt><dd>Variable</dd>
	<dt/>
	<dd>	<dt>Flags:</dt><dd><t>1 octet of flags. The following are defined:</t
	<t>Flags: 1 octet of flags. The following are defined:</t>	>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	<artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4
		5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\|I\|V\| \|	\|I\|V\| \|

	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+]]></artwork>
	]]></artwork>
	<t>where: </t>	</dd></dl>
	<dl newline="false"spacing="normal">	</li>
	<dt/>	</ul>
	<dd>I-Flag: MPLS IPv4 flag. If set, then the router iscapable	<ul empty="true"><li>
		<t>where: </t>
		<ul empty="true"><li>
		<dl newline="false"spacing="normal" indent="9">
		<dt>I-Flag:</dt><dd>MPLS IPv4 flag. If set, then the router iscap
		able
	of processing SR-MPLS-encapsulated IPv4 packets on all	of processing SR-MPLS-encapsulated IPv4 packets on all
	interfaces.</dd>	interfaces.</dd>

	<dt/>
	<dd>V-Flag: MPLS IPv6 flag. If set, then the router iscapable	<dt>V-Flag:</dt><dd>MPLS IPv6 flag. If set, then the router iscap
		able
	of processing SR-MPLS-encapsulated IPv6 packets on all	of processing SR-MPLS-encapsulated IPv6 packets on all
	interfaces.</dd>	interfaces.</dd>
	</dl>	</dl>

	</dd>	</li></ul></li></ul>
	<dt/>
	<dd>	<ul empty="true"><li>
	<t>One or more Segment Routing Global Block (SRGB) Descriptor entries, each of which have the	<t>One or more Segment Routing Global Block (SRGB) Descriptor entries, each of which have the
	following format:</t>	following format:</t>

	<dl newline="false"spacing="normal">
	<dt/>	<ul empty="true"><li>
	<dd>Range: 3 octets</dd>	<dl newline="false"spacing="normal" indent="9">
	<dt/>	<dt>Range:</dt><dd>3 octets</dd>
	<dd>SID/Label sub-TLV: As defined in <xreftarget="SIDLABELSUBTLV"	<dt>SID/Label sub-TLV:</dt><dd>MPLS label as defined in <xreftarg
	format="default"/>.</dd>	et="SIDLABELSUBTLV" format="default"/>.</dd>
	</dl>	</dl>

	</dd>	</li>
	</dl>	</ul>
		</li>
		</ul>

	<t>The SID/Label sub-TLV contains the first value of the SRGB while the	<t>The SID/Label sub-TLV contains the first value of the SRGB while the

	range contains the number of SRGB elements. The range valueMUST be	range contains the number of SRGB elements. The range value<bcp14>MUST</bcp14> be
	higher than 0.</t>	higher than 0.</t>

	<t>The SR-Capabilities sub-TLVMAY be advertised in anLSP of any	<t>The SR-Capabilities sub-TLV<bcp14>MAY</bcp14> be advertised in anLS
	number, but a routerMUST NOT advertise more than oneSR-Capabilities	P of any
		number, but a router<bcp14>MUST NOT</bcp14> advertise more than oneSR-
		Capabilities
	sub-TLV. A router receiving multiple SR-Capabilities sub-TLVs from the	sub-TLV. A router receiving multiple SR-Capabilities sub-TLVs from the

	same originatorSHOULD select the first advertisement in the lowest-numbered	same originator<bcp14>SHOULD</bcp14> select the first advertisement in the lowest-numbered
	LSP.</t>	LSP.</t>
	<t>When multiple SRGB Descriptors are advertised, the entries define an	<t>When multiple SRGB Descriptors are advertised, the entries define an
	ordered set of ranges on which a SID index is to be applied. For this	ordered set of ranges on which a SID index is to be applied. For this
	reason, changing the order in which the descriptors are advertised will	reason, changing the order in which the descriptors are advertised will
	have a disruptive effect on forwarding.</t>	have a disruptive effect on forwarding.</t>
	<t>When a router adds a new SRGB Descriptor to an existing	<t>When a router adds a new SRGB Descriptor to an existing

	SR‑Capabilities sub-TLV, the new descriptorSHOULD addthe newly	SR-Capabilities sub-TLV, the new descriptor<bcp14>SHOULD</bcp14> addth
	configured block at the end of the sub-TLV andSHOULD NOT change the	e newly
		configured block at the end of the sub-TLV and<bcp14>SHOULD NOT</bcp14>
		change the
	order of previously advertised blocks. Changing the order of the	order of previously advertised blocks. Changing the order of the
	advertised descriptors will create label churn in the FIB and	advertised descriptors will create label churn in the FIB and
	black hole / misdirect some traffic during the IGP convergence. In	black hole / misdirect some traffic during the IGP convergence. In
	particular, if a range that is not the last is extended, it's	particular, if a range that is not the last is extended, it's
	preferable to add a new range rather than extending the previously	preferable to add a new range rather than extending the previously
	advertised range.</t>	advertised range.</t>

	<t>The originating routerMUST ensure the order is unchanged after a	<t>The originating router<bcp14>MUST</bcp14> ensure the order is unchanged after a
	graceful restart (using checkpointing, non-volatile storage, or any	graceful restart (using checkpointing, non-volatile storage, or any
	other mechanism).</t>	other mechanism).</t>

	<t>The originating routerMUST NOT advertise overlapping ranges.</t>	<t>The originating router<bcp14>MUST NOT</bcp14> advertise overlapping
	<t>When a router receives multiple overlapping ranges, itMUST conform	ranges.</t>
		<t>When a router receives multiple overlapping ranges, it<bcp14>MUST</b
		cp14> conform
	to the procedures defined in <xref format="default"/>.</t>	to the procedures defined in <xref format="default"/>.</t>


	<t>Here follows an example of the advertisement of multiple ranges:</t>	<t>Here follows an example of the advertisement of multiple ranges:</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[
	The originating router advertises the following ranges:


	SR-Cap: range: 100, SID value: 100	<ul empty="true" spacing="normal">
	SR-Cap: range: 100, SID value:1000	<li>
	SR-Cap: range: 100, SID value:500	<ul empty="true" spacing="normal">
		<li>The originating router advertises the following ranges:</li>
		<li>SR-Cap: range: 100, SID value: 100</li>
		<li>SR-Cap: range: 100, SID value:1000</li>
		<li>SR-Cap: range: 100, SID value:500</li>
		</ul>
		</li>
		</ul>


		<ul empty="true" spacing="normal">
		<li>
	The receiving routers concatenate the ranges in the received	The receiving routers concatenate the ranges in the received

	order and build the SRGB asfollows:	order and build the SRGB asfollows:</li>
		</ul>


		<artwork name="" type="" align="left" alt=""><![CDATA[
	SRGB = [100, 199]	SRGB = [100, 199]
	[1000, 1099]	[1000, 1099]

	[500, 599]	[500, 599]]]></artwork>


	The indexes span multipleranges:	<ul empty="true" spacing="normal">
		<li>The indexes span multipleranges:</li>
		</ul>


		<artwork name="" type="" align="left" alt=""><![CDATA[
	index=0 means label 100	index=0 means label 100
	...	...
	index 99 means label 199	index 99 means label 199
	index 100 means label 1000	index 100 means label 1000
	index 199 means label 1099	index 199 means label 1099
	...	...
	index 200 means label 500	index 200 means label 500
	...]]></artwork>	...]]></artwork>


	</section>	</section>
	<section anchor="SRALGOSUBTLV" numbered="true" toc="default">	<section anchor="SRALGOSUBTLV" numbered="true" toc="default">
	<name>SR-Algorithm Sub-TLV</name>	<name>SR-Algorithm Sub-TLV</name>
	<t>The router may use various algorithms when calculating reachability	<t>The router may use various algorithms when calculating reachability
	to other nodes or to prefixes attached to these nodes. Examples of	to other nodes or to prefixes attached to these nodes. Examples of
	these algorithms are metric-based SPF, various	these algorithms are metric-based SPF, various
	sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the	sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the
	router to advertise the algorithms that the router is currently using.	router to advertise the algorithms that the router is currently using.
	Algorithm values are defined in the "IGP Algorithm Type" registry	Algorithm values are defined in the "IGP Algorithm Type" registry
	defined in <xref format="default"/>.	defined in <xref format="default"/>.

	skipping to change at line 1027 ¶	skipping to change at line 1096 ¶
	<section anchor="SRALGOSUBTLV" numbered="true" toc="default">	<section anchor="SRALGOSUBTLV" numbered="true" toc="default">
	<name>SR-Algorithm Sub-TLV</name>	<name>SR-Algorithm Sub-TLV</name>
	<t>The router may use various algorithms when calculating reachability	<t>The router may use various algorithms when calculating reachability
	to other nodes or to prefixes attached to these nodes. Examples of	to other nodes or to prefixes attached to these nodes. Examples of
	these algorithms are metric-based SPF, various	these algorithms are metric-based SPF, various
	sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the	sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the
	router to advertise the algorithms that the router is currently using.	router to advertise the algorithms that the router is currently using.
	Algorithm values are defined in the "IGP Algorithm Type" registry	Algorithm values are defined in the "IGP Algorithm Type" registry
	defined in <xref format="default"/>.	defined in <xref format="default"/>.
	The following values have been defined:</t>	The following values have been defined:</t>

	<ul empty="true" spacing="normal">
	<li>0: SPF algorithm based on link metric.	<ul empty="true"spacing="normal"><li>
		<dl newline="false" spacing="normal">
		<dt>0:</dt><dd>SPF algorithm based on link metric.
	This is the well-known shortest path algorithm as computed by the	This is the well-known shortest path algorithm as computed by the
	IS-IS Decision Process. Consistent with the deployed practice for	IS-IS Decision Process. Consistent with the deployed practice for
	link-state protocols, algorithm 0 permits any node to overwrite	link-state protocols, algorithm 0 permits any node to overwrite

	the SPF path with a different path based on localpolicy.</li>	the SPF path with a different path based on localpolicy.</dd>
	<li>1: Strict SPF algorithm based on link	<dt>1:</dt><dd>Strict SPF algorithm based on link
	metric. The algorithm is identical to algorithm 0, but algorithm 1	metric. The algorithm is identical to algorithm 0, but algorithm 1
	requires that all nodes along the path will honor the SPF routing	requires that all nodes along the path will honor the SPF routing

	decision. Local policyMUST NOT alter the forwardingdecision	decision. Local policy<bcp14>MUST NOT</bcp14> alter the forwardingdecision
	computed by algorithm 1 at the node claiming to support algorithm	computed by algorithm 1 at the node claiming to support algorithm

	1.</li>	1.</dd>
		</dl>
		</li>
	</ul>	</ul>
	<t>The Router Capability TLV specifies flags that control its	<t>The Router Capability TLV specifies flags that control its

	advertisement. The SR-AlgorithmMUST be propagatedthroughout the	advertisement. The SR-Algorithm<bcp14>MUST</bcp14> be propagatedthroug
	level andMUST NOT be advertised across level boundaries. Therefore,	hout the
		level and<bcp14>MUST NOT</bcp14> be advertised across level boundaries.
		Therefore,
	Router Capability TLV distribution flags are set accordingly, i.e.,	Router Capability TLV distribution flags are set accordingly, i.e.,

	the S flagMUST be unset.</t>	the S flag<bcp14>MUST</bcp14> be unset.</t>
	<t>The SR-Algorithm sub-TLV is optional. ItMUST NOT beadvertised	<t>The SR-Algorithm sub-TLV is optional. It<bcp14>MUST NOT</bcp14> bea
		dvertised
	more than once at a given level. A router receiving multiple	more than once at a given level. A router receiving multiple

	SR-Algorithm sub-TLVs from the same originatorSHOULD select the first	SR-Algorithm sub-TLVs from the same originator<bcp14>SHOULD</bcp14> select the first
	advertisement in the lowest-numbered LSP.</t>	advertisement in the lowest-numbered LSP.</t>
	<t>When the originating router does not advertise the SR-Algorithm	<t>When the originating router does not advertise the SR-Algorithm

	sub‑TLV, it implies that Algorithm 0 is the only algorithm supported by the routers	sub-TLV, it implies that algorithm 0 is the only algorithm supported by the routers
	that support the extensions defined in this document.</t>	that support the extensions defined in this document.</t>
	<t>When the originating router does advertise the SR-Algorithm	<t>When the originating router does advertise the SR-Algorithm

	sub-TLV, then algorithm 0MUST be present while non-zero algorithms	sub-TLV, then algorithm 0<bcp14>MUST</bcp14> be present while non-zero
	MAY be present.</t>	algorithms
		<bcp14>MAY</bcp14> be present.</t>
	<t>The SR-Algorithm sub-TLV has the following format: </t>	<t>The SR-Algorithm sub-TLV has the following format: </t>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type \| Length \|	\| Type \| Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Algorithm 1 \| Algorithm 2 \| Algorithm ... \| Algorithm n \|	\| Algorithm 1 \| Algorithm 2 \| Algorithm ... \| Algorithm n \|

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
	]]></artwork>
	<t> where: </t>	<t> where: </t>

	<dl newline="false"spacing="normal">	<ul empty="true"><li>
	<dt/>	<dl newline="false"spacing="normal" indent="12">
	<dd>Type: 19</dd>
	<dt/>	<dt>Type:</dt><dd>19</dd>
	<dd>Length: Variable</dd>
	<dt/>	<dt>Length:</dt><dd>Variable</dd>
	<dd>Algorithm: 1 octet of algorithm</dd>
	</dl>	<dt>Algorithm:</dt><dd>1 octet of algorithm</dd>
		</dl></li></ul>
	</section>	</section>
	<section anchor="SRLBSUBTLV" numbered="true" toc="default">	<section anchor="SRLBSUBTLV" numbered="true" toc="default">
	<name>SR Local Block Sub-TLV</name>	<name>SR Local Block Sub-TLV</name>
	<t>The SR Local Block (SRLB) sub-TLV contains the range of labels the	<t>The SR Local Block (SRLB) sub-TLV contains the range of labels the
	node has reserved for local SIDs. Local SIDs are used, e.g., for	node has reserved for local SIDs. Local SIDs are used, e.g., for
	Adjacency-SIDs, and may also be allocated by components other than the	Adjacency-SIDs, and may also be allocated by components other than the
	IS-IS protocol. As an example, an application or a controller may	IS-IS protocol. As an example, an application or a controller may
	instruct the router to allocate a specific local SID. Therefore, in	instruct the router to allocate a specific local SID. Therefore, in
	order for such applications or controllers to know what local	order for such applications or controllers to know what local
	SIDs are available in the router, it is required that the router	SIDs are available in the router, it is required that the router

	skipping to change at line 1098 ¶	skipping to change at line 1171 ¶
	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 \| Flags \|	\| Type \| Length \| Flags \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Range \|	\| Range \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// SID/Label Sub-TLV (variable) //	// SID/Label Sub-TLV (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

	<dl newline="false"spacing="normal">	<ul empty="true"><li>
	<dt/>	<dl newline="false"spacing="normal" indent="9">
	<dd>Type: 22</dd>	<dt>Type:</dt><dd>22</dd>
	<dt/>
	<dd>Length: Variable</dd>	<dt>Length:</dt><dd>Variable</dd>
	<dt/>
	<dd>Flags: 1 octet of flags. None are defined at thisstage.</dd>	<dt>Flags:</dt><dd>1 octet of flags. None are defined at thisstage.</
	<dt/>	dd>
	<dd>	</dl>
		</li>
		</ul>
		<ul empty="true"><li>
	<t>One or more SRLB Descriptor entries, each of which have the	<t>One or more SRLB Descriptor entries, each of which have the
	following format:</t>	following format:</t>

	<dl newline="false"spacing="normal">
	<dt/>	<ul empty="true"><li>
	<dd>Range: 3 octets</dd>	<dl newline="false"spacing="normal" indent="9">
	<dt/>
	<dd>SID/Label sub-TLV (as defined in <xreftarget="SIDLABELSUBTLV"	<dt>Range:</dt><dd>3 octets</dd>
	format="default"/>).</dd>	<!--NOTE: tell authors that we added a colon here.-->

		<dt>SID/Label sub-TLV:</dt><dd>MPLS label as defined in <xreftarg
		et="SIDLABELSUBTLV" format="default"/></dd>
	</dl>	</dl>

	</dd>	</li>
	</dl>	</ul>
		</li>
		</ul>
	<t>The SID/Label sub-TLV contains the first value of the SRLB while the	<t>The SID/Label sub-TLV contains the first value of the SRLB while the

	range contains the number of SRLB elements. The range valueMUST be	range contains the number of SRLB elements. The range value<bcp14>MUST</bcp14> be
	higher than 0.</t>	higher than 0.</t>

	<t>The SRLB sub-TLVMAY be advertised in an LSP of anynumber, but a	<t>The SRLB sub-TLV<bcp14>MAY</bcp14> be advertised in an LSP of anynu
	routerMUST NOT advertise more than one SRLB sub-TLV. Arouter	mber, but a
	receiving multiple SRLB sub-TLVs, from the same originator,SHOULD	router<bcp14>MUST NOT</bcp14> advertise more than one SRLB sub-TLV. Ar
		outer
		receiving multiple SRLB sub-TLVs, from the same originator,<bcp14>SHOUL
		D</bcp14>
	select the first advertisement in the lowest-numbered LSP.</t>	select the first advertisement in the lowest-numbered LSP.</t>

	<t>The originating routerMUST NOT advertise overlapping ranges.</t>	<t>The originating router<bcp14>MUST NOT</bcp14> advertise overlapping
	<t>When a router receives multiple overlapping ranges, itMUST conform	ranges.</t>
		<t>When a router receives multiple overlapping ranges, it<bcp14>MUST</b
		cp14> conform
	to the procedures defined in <xref format="default"/>.</t>	to the procedures defined in <xref format="default"/>.</t>
	<t>It is important to note that each time a SID from the SRLB is	<t>It is important to note that each time a SID from the SRLB is
	allocated, it should also be reported to all components (e.g.,	allocated, it should also be reported to all components (e.g.,
	controller or applications) in order for these components to have an	controller or applications) in order for these components to have an
	up-to-date view of the current SRLB allocation and to avoid	up-to-date view of the current SRLB allocation and to avoid
	collision between allocation instructions.</t>	collision between allocation instructions.</t>
	<t>Within the context of IS-IS, the reporting of local SIDs is done	<t>Within the context of IS-IS, the reporting of local SIDs is done
	through IS-IS sub-TLVs such as the Adjacency-SID. However, the	through IS-IS sub-TLVs such as the Adjacency-SID. However, the
	reporting of allocated local SIDs may also be done through other means	reporting of allocated local SIDs may also be done through other means
	and protocols that are outside the scope of this document.</t>	and protocols that are outside the scope of this document.</t>

	skipping to change at line 1153 ¶	skipping to change at line 1233 ¶
	<name>SRMS Preference Sub-TLV</name>	<name>SRMS Preference Sub-TLV</name>
	<t>The SRMS Preference sub-TLV is	<t>The SRMS Preference sub-TLV is
	used in order to associate a preference with SRMS advertisements from	used in order to associate a preference with SRMS advertisements from
	a particular source.</t>	a particular source.</t>
	<t>The SRMS Preference sub-TLV has the following format:</t>	<t>The SRMS Preference sub-TLV has the following format:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3	<artwork name="" type="" align="left" alt=""><![CDATA[ 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 \| Preference \|	\| Type \| Length \| Preference \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

	<dl newline="false"spacing="normal">	<ul empty="true"><li>
	<dt/>	<dl newline="false"spacing="normal" indent="13">
	<dd>Type: 24</dd>	<dt>Type:</dt><dd>24</dd>
	<dt/>
	<dd>Length: 1</dd>	<dt>Length:</dt><dd>1</dd>
	<dt/>
	<dd>Preference: 1 octet and unsigned 8-bit SRMSpreference.</dd>	<dt>Preference:</dt><dd>1 octet and unsigned 8-bit SRMSpreference.</d
		d>
	</dl>	</dl>

	<t>The SRMS Preference sub-TLVMAY be advertised in anLSP of any	</li>
	number, but a routerMUST NOT advertise more than oneSRMS Preference	</ul>
		<t>The SRMS Preference sub-TLV<bcp14>MAY</bcp14> be advertised in anLS
		P of any
		number, but a router<bcp14>MUST NOT</bcp14> advertise more than oneSRM
		S Preference
	sub-TLV. A router receiving multiple SRMS Preference sub-TLVs, from	sub-TLV. A router receiving multiple SRMS Preference sub-TLVs, from

	the same originator,SHOULD select the first advertisement in the	the same originator,<bcp14>SHOULD</bcp14> select the first advertisement in the
	lowest-numbered LSP.</t>	lowest-numbered LSP.</t>
	<t>The use of the SRMS preference during the SID selection process is	<t>The use of the SRMS preference during the SID selection process is
	described in <xref format="default"/>.</t>	described in <xref format="default"/>.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="IANA" numbered="true" toc="default">	<section anchor="IANA" numbered="true" toc="default">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>
	<t>Per this document, IANA has allocated the following TLVs and	<t>Per this document, IANA has allocated the following TLVs and

	sub‑TLVs.</t>	sub-TLVs.</t>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Sub-TLVs for Types 22, 23, 25, 141, 222, and 223</name>	<name>Sub-TLVs for Types 22, 23, 25, 141, 222, and 223</name>
	<t>This document makes the following registrations in the "Sub-TLVs	<t>This document makes the following registrations in the "Sub-TLVs
	for TLV 22, 23, 25, 141, 222, and 223" registry.</t>	for TLV 22, 23, 25, 141, 222, and 223" registry.</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[
	Type Description 22 23 25 141 222 223
	31 Adjacency Segment Identifier y y n y y y
	32 LAN Adjacency Segment Identifier y y n y y y


	]]></artwork>	<table anchor="IANA_table_1" align="left">
		<!-- <name>Registrations in the "Sub-TLVs for TLV 22, 23, 25, 141, 222, and 223
		" Registry</name>-->
		<thead>
		<tr>
		<th align='center'>Type</th>
		<th align='left'>Description</th>
		<th align='center'>22</th>
		<th align='center'>23</th>
		<th align='center'>25</th>
		<th align='center'>141</th>
		<th align='center'>222</th>
		<th align='center'>223</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="center">31</td>
		<td align="left">Adjacency Segment Identifier</td>
		<td align="center">y</td>
		<td align="center">y</td>
		<td align="center">n</td>
		<td align="center">y</td>
		<td align="center">y</td>
		<td align="center">y</td>
		</tr>
		<tr>
		<td align="center">32</td>
		<td align="left">LAN Adjacency Segment Identifier</td>
		<td align="center">y</td>
		<td align="center">y</td>
		<td align="center">n</td>
		<td align="center">y</td>
		<td align="center">y</td>
		<td align="center">y</td>
		</tr>
		</tbody>
		</table>

	</section>	</section>


	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Sub-TLVs for Types 135, 235, 236, and 237</name>	<name>Sub-TLVs for Types 135, 235, 236, and 237</name>
	<t>This document makes the following registrations in the "Sub-TLVs	<t>This document makes the following registrations in the "Sub-TLVs
	for TLV 135, 235, 236, and 237" registry.</t>	for TLV 135, 235, 236, and 237" registry.</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[
	Type Description 135 235 236 237
	3 Prefix Segment Identifier y y y y


	]]></artwork>	<table anchor="IANA_table_2" align="left">
		<!-- <name>Registrations in the "Sub-TLVs for TLV 135, 235, 236, and 237" Regis
		try</name>-->
		<thead>
		<tr>
		<th align='center'>Type</th>
		<th align='left'>Description</th>
		<th align='center'>135</th>
		<th align='center'>2235</th>
		<th align='center'>236</th>
		<th align='center'>237</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="center">3</td>
		<td align="left">Prefix Segment Identifier</td>
		<td align="center">y</td>
		<td align="center">y</td>
		<td align="center">y</td>
		<td align="center">y</td>
		</tr>
		</tbody>
		</table>

	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Sub-TLVs for Type 242</name>	<name>Sub-TLVs for Type 242</name>
	<t>This document makes the following registrations in the "Sub-TLVs	<t>This document makes the following registrations in the "Sub-TLVs
	for TLV 242" registry.</t>	for TLV 242" registry.</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[
	Type Description	<table anchor="IANA_table_3" align="left">
	2 Segment RoutingCapability	<!-- <name>Registrations in the "Sub-TLVs for TLV 242" Registry</name>-->
	19 Segment RoutingAlgorithm	<thead>
	22 Segment Routing Local Block(SRLB)	<tr>
	24 Segment Routing Mapping Server Preference (SRMSPreference)	<th align='center'>Type</th>
	]]></artwork>	<th align='left'>Description</th>
	<t/>	</tr>
		</thead>
		<tbody>
		<tr>
		<td align="center">2</td>
		<td align="left">Segment RoutingCapability</td>
		</tr>
		<tr>
		<td align="center">19</td>
		<td align="left">Segment RoutingAlgorithm</td>
		</tr>
		<tr>
		<td align="center">22</td>
		<td align="left">Segment Routing Local Block(SRLB)</td>
		</tr>
		<tr>
		<td align="center">24</td>
		<td align="left">Segment Routing Mapping Server Preference (SRMSPreferenc
		e)</td>
		</tr>
		</tbody>
		</table>

	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>New TLV Codepoint and Sub-TLV Registry</name>	<name>New TLV Codepoint and Sub-TLV Registry</name>
	<t>This document registers the following TLV:</t>	<t>This document registers the following TLV:</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[
	Value Name IIH LSP SNP Purge	<table anchor="IANA_table_4" align="left">
	149Segment Identifier/LabelBinding n y n n	<!--<name>Registrations for TLVs 149and 150</name>-->
	150 Multi-Topology Segment Identifiern y n n	<thead>
	/ LabelBinding]]></artwork>	<tr>
		<th align='center'>Value</th>
		<th align='left'>Name</th>
		<th align='center'>IIH</th>
		<th align='center'>LSP</th>
		<th align='center'>SNP</th>
		<th align='center'>Purge</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="center">149</td>
		<td align="left">Segment Identifier/LabelBinding</td>
		<td align="center">n</td>
		<td align="center">y</td>
		<td align="center">n</td>
		<td align="center">n</td>
		</tr>
		<tr>
		<td align="center">150</td>
		<td align="left">Multi-Topology Segment Identifier / LabelBinding</td>
		<td align="center">n</td>
		<td align="center">y</td>
		<td align="center">n</td>
		<td align="center">n</td>
		</tr>
		</tbody>
		</table>
	<t>This document creates the following sub-TLV Registry:</t>	<t>This document creates the following sub-TLV Registry:</t>

	<t>
	Name: Sub-TLVs for TLVs 149 and150	<dl>
	Registration Procedure: Expert Review <xrefformat="default"/><	<dt>Name:</dt>
	/t>	<dd>Sub-TLVs for TLVs 149 and150</dd>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<dt>Registration Procedure:</dt>
	Type Description	<dd>Expert Review <xrefformat="default"/></dd>
	0 Reserved	</dl>
	1 SID/Label
	2 Unassigned	<table anchor="IANA_table_5" align="left">
	3 Prefix SID	<!-- <name>Sub-TLVs for TLVs 149 and 150</name>-->
	4-255 Unassigned]]></artwork>	<thead>
		<tr>
		<th align='center'>Type</th>
		<th align='center'>Description</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="center">0</td>
		<td align="center">Reserved</td>
		</tr>
		<tr>
		<td align="center">1</td>
		<td align="center">SID/Label</td>
		</tr>
		<tr>
		<td align="center">2</td>
		<td align="center">Unassigned</td>
		</tr>
		<tr>
		<td align="center">3</td>
		<td align="center">Prefix SID</td>
		</tr>
		<tr>
		<td align="center">4-255</td>
		<td align="center">Unassigned</td>
		</tr>
		</tbody>
		</table>
	</section>	</section>
	</section>	</section>


	<section anchor="Security" numbered="true" toc="default">	<section anchor="Security" numbered="true" toc="default">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>With the use of the extensions defined in this document, IS-IS	<t>With the use of the extensions defined in this document, IS-IS
	carries information that will be used to program the MPLS data plane	carries information that will be used to program the MPLS data plane
	<xref format="default"/>. In general, the same type of attacks that can be carried out	<xref format="default"/>. In general, the same type of attacks that can be carried out
	on the IP/IPv6 control plane can be carried out on the MPLS control	on the IP/IPv6 control plane can be carried out on the MPLS control
	plane, resulting in traffic being misrouted in the respective data	plane, resulting in traffic being misrouted in the respective data
	planes. However, the latter may be more difficult to detect and	planes. However, the latter may be more difficult to detect and
	isolate.</t>	isolate.</t>
	<t>Existing security extensions as described in <xref format="default"/>	<t>Existing security extensions as described in <xref format="default"/>

	skipping to change at line 1248 ¶	skipping to change at line 1457 ¶
	<xref format="default"/>. In general, the same type of attacks that can be carried out	<xref format="default"/>. In general, the same type of attacks that can be carried out
	on the IP/IPv6 control plane can be carried out on the MPLS control	on the IP/IPv6 control plane can be carried out on the MPLS control
	plane, resulting in traffic being misrouted in the respective data	plane, resulting in traffic being misrouted in the respective data
	planes. However, the latter may be more difficult to detect and	planes. However, the latter may be more difficult to detect and
	isolate.</t>	isolate.</t>
	<t>Existing security extensions as described in <xref format="default"/>	<t>Existing security extensions as described in <xref format="default"/>
	and <xref format="default"/> apply to these segment routing extensions.</t>	and <xref format="default"/> apply to these segment routing extensions.</t>
	</section>	</section>
	</middle>	</middle>
	<back>	<back>


	<references>	<references>
	<name>References</name>	<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>

	<reference anchor="RFC2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
	19.xml">	xml"/>
	<front>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3031.
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit	xml"/>
	le>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5304.
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>	xml"/>
	<seriesInfo name="RFC" value="2119"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5310.
	<seriesInfo name="BCP" value="14"/>	xml"/>
	<author initials="S." surname="Bradner" fullname="S. Bradner">	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5120.
	<organization/>	xml"/>
	</author>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7981.
	<date year="1997" month="March"/>	xml"/>
	<abstract>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7794.
	<t>In many standards track documents several words are used to sig	xml"/>
	nify the requirements in the specification. These words are often capitalized.	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
	This document defines these words as they should be interpreted in IETF document	xml"/>
	s. This document specifies an Internet Best Current Practices for the Internet	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.
	Community, and requests discussion and suggestions for improvements.</t>	xml"/>
	</abstract>
	</front>
	</reference>
	<reference anchor="ISO10589">	<reference anchor="ISO10589">
	<front>	<front>
	<title>Information technology -- Telecommunications and information exchange between systems -- Intermediate system to Intermediate system intra-domain	<title>Information technology -- Telecommunications and information exchange between systems -- Intermediate system to Intermediate system intra-domain
	routeing information exchange protocol for use in conjunction with	routeing information exchange protocol for use in conjunction with
	the protocol for providing the connectionless-mode network service	the protocol for providing the connectionless-mode network service
	(ISO 8473)</title>	(ISO 8473)</title>
	<seriesInfo name="ISO/IEC 10589:2002," value="Second Edition"/>	<seriesInfo name="ISO/IEC 10589:2002," value="Second Edition"/>
	<author>	<author>
	<organization abbrev="ISO">International Organization for Standardization</organization>	<organization abbrev="ISO">International Organization for Standardization</organization>
	</author>	</author>
	<date month="November" year="2002"/>	<date month="November" year="2002"/>
	</front>	</front>
	</reference>	</reference>

	<reference anchor="RFC3031" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.30
	31.xml">
	<front>
	<title>Multiprotocol Label Switching Architecture</title>
	<seriesInfo name="DOI" value="10.17487/RFC3031"/>
	<seriesInfo name="RFC" value="3031"/>
	<author initials="E." surname="Rosen" fullname="E. Rosen">
	<organization/>
	</author>
	<author initials="A." surname="Viswanathan" fullname="A. Viswanathan
	">
	<organization/>
	</author>
	<author initials="R." surname="Callon" fullname="R. Callon">
	<organization/>
	</author>
	<date year="2001" month="January"/>
	<abstract>
	<t>This document specifies the architecture for Multiprotocol Labe
	l Switching (MPLS). [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC5304" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.53
	04.xml">
	<front>
	<title>IS-IS Cryptographic Authentication</title>
	<seriesInfo name="DOI" value="10.17487/RFC5304"/>
	<seriesInfo name="RFC" value="5304"/>
	<author initials="T." surname="Li" fullname="T. Li">
	<organization/>
	</author>
	<author initials="R." surname="Atkinson" fullname="R. Atkinson">
	<organization/>
	</author>
	<date year="2008" month="October"/>
	<abstract>
	<t>This document describes the authentication of Intermediate Syst
	em to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Me
	ssage Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in R
	FC 2104. IS-IS is specified in International Standards Organization (ISO) 10589
	, with extensions to support Internet Protocol version 4 (IPv4) described in RFC
	1195. The base specification includes an authentication mechanism that allows
	for multiple authentication algorithms. The base specification only specifies t
	he algorithm for cleartext passwords. This document replaces RFC 3567.</t>
	<t>This document proposes an extension to that specification that
	allows the use of the HMAC-MD5 authentication algorithm to be used in conjunctio
	n with the existing authentication mechanisms. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC5310" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.53
	10.xml">
	<front>
	<title>IS-IS Generic Cryptographic Authentication</title>
	<seriesInfo name="DOI" value="10.17487/RFC5310"/>
	<seriesInfo name="RFC" value="5310"/>
	<author initials="M." surname="Bhatia" fullname="M. Bhatia">
	<organization/>
	</author>
	<author initials="V." surname="Manral" fullname="V. Manral">
	<organization/>
	</author>
	<author initials="T." surname="Li" fullname="T. Li">
	<organization/>
	</author>
	<author initials="R." surname="Atkinson" fullname="R. Atkinson">
	<organization/>
	</author>
	<author initials="R." surname="White" fullname="R. White">
	<organization/>
	</author>
	<author initials="M." surname="Fanto" fullname="M. Fanto">
	<organization/>
	</author>
	<date year="2009" month="February"/>
	<abstract>
	<t>This document proposes an extension to Intermediate System to I
	ntermediate System (IS-IS) to allow the use of any cryptographic authentication
	algorithm in addition to the already-documented authentication schemes, describe
	d in the base specification and RFC 5304. IS-IS is specified in International S
	tandards Organization (ISO) 10589, with extensions to support Internet Protocol
	version 4 (IPv4) described in RFC 1195.</t>
	<t>Although this document has been written specifically for using
	the Hashed Message Authentication Code (HMAC) construct along with the Secure Ha
	sh Algorithm (SHA) family of cryptographic hash functions, the method described
	in this document is generic and can be used to extend IS-IS to support any crypt
	ographic hash function in the future. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC5120" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.51
	20.xml">
	<front>
	<title>M-ISIS: Multi Topology (MT) Routing in Intermediate System to
	Intermediate Systems (IS-ISs)</title>
	<seriesInfo name="DOI" value="10.17487/RFC5120"/>
	<seriesInfo name="RFC" value="5120"/>
	<author initials="T." surname="Przygienda" fullname="T. Przygienda">
	<organization/>
	</author>
	<author initials="N." surname="Shen" fullname="N. Shen">
	<organization/>
	</author>
	<author initials="N." surname="Sheth" fullname="N. Sheth">
	<organization/>
	</author>
	<date year="2008" month="February"/>
	<abstract>
	<t>This document describes an optional mechanism within Intermedia
	te System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routi
	ng within their clouds. This document describes how to run, within a single IS-
	IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs
	). This MT extension can be used for a variety of purposes, such as an in-band m
	anagement network "on top" of the original IGP topology, maintaining separate IG
	P routing domains for isolated multicast or IPv6 islands within the backbone, or
	forcing a subset of an address space to follow a different topology. [STANDARD
	S-TRACK]</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC7981" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.79
	81.xml">
	<front>
	<title>IS-IS Extensions for Advertising Router Information</title>
	<seriesInfo name="DOI" value="10.17487/RFC7981"/>
	<seriesInfo name="RFC" value="7981"/>
	<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
	<organization/>
	</author>
	<author initials="S." surname="Previdi" fullname="S. Previdi">
	<organization/>
	</author>
	<author initials="M." surname="Chen" fullname="M. Chen">
	<organization/>
	</author>
	<date year="2016" month="October"/>
	<abstract>
	<t>This document defines a new optional Intermediate System to Int
	ermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, whic
	h allows a router to announce its capabilities within an IS-IS level or the enti
	re routing domain. This document obsoletes RFC 4971.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC7794" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.77
	94.xml">
	<front>
	<title>IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachabili
	ty</title>
	<seriesInfo name="DOI" value="10.17487/RFC7794"/>
	<seriesInfo name="RFC" value="7794"/>
	<author initials="L." surname="Ginsberg" fullname="L. Ginsberg" role
	="editor">
	<organization/>
	</author>
	<author initials="B." surname="Decraene" fullname="B. Decraene">
	<organization/>
	</author>
	<author initials="S." surname="Previdi" fullname="S. Previdi">
	<organization/>
	</author>
	<author initials="X." surname="Xu" fullname="X. Xu">
	<organization/>
	</author>
	<author initials="U." surname="Chunduri" fullname="U. Chunduri">
	<organization/>
	</author>
	<date year="2016" month="March"/>
	<abstract>
	<t>This document introduces new sub-TLVs to support advertisement
	of IPv4 and IPv6 prefix attribute flags and the source router ID of the router t
	hat originated a prefix advertisement.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81
	74.xml">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="BCP" value="14"/>
	<author initials="B." surname="Leiba" fullname="B. Leiba">
	<organization/>
	</author>
	<date year="2017" month="May"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying tha
	t only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC8402" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84
	02.xml">
	<front>
	<title>Segment Routing Architecture</title>
	<seriesInfo name="DOI" value="10.17487/RFC8402"/>
	<seriesInfo name="RFC" value="8402"/>
	<author initials="C." surname="Filsfils" fullname="C. Filsfils" role
	="editor">
	<organization/>
	</author>
	<author initials="S." surname="Previdi" fullname="S. Previdi" role="
	editor">
	<organization/>
	</author>
	<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
	<organization/>
	</author>
	<author initials="B." surname="Decraene" fullname="B. Decraene">
	<organization/>
	</author>
	<author initials="S." surname="Litkowski" fullname="S. Litkowski">
	<organization/>
	</author>
	<author initials="R." surname="Shakir" fullname="R. Shakir">
	<organization/>
	</author>
	<date year="2018" month="July"/>
	<abstract>
	<t>Segment Routing (SR) leverages the source routing paradigm. A
	node steers a packet through an ordered list of instructions, called "segments".
	A segment can represent any instruction, topological or service based. A segm
	ent can have a semantic local to an SR node or global within an SR domain. SR p
	rovides a mechanism that allows a flow to be restricted to a specific topologica
	l path, while maintaining per-flow state only at the ingress node(s) to the SR d
	omain.</t>
	<t>SR can be directly applied to the MPLS architecture with no cha
	nge to the forwarding plane. A segment is encoded as an MPLS label. An ordered
	list of segments is encoded as a stack of labels. The segment to process is on
	the top of the stack. Upon completion of a segment, the related label is poppe
	d from the stack.</t>
	<t>SR can be applied to the IPv6 architecture, with a new type of
	routing header. A segment is encoded as an IPv6 address. An ordered list of se
	gments is encoded as an ordered list of IPv6 addresses in the routing header. T
	he active segment is indicated by the Destination Address (DA) of the packet. T
	he next active segment is indicated by a pointer in the new routing header.</t>
	</abstract>
	</front>
	</reference>
	<!--draft-ietf-ospf-segment-routing-extensions">; companion document RFC 8665 -->	<!--draft-ietf-ospf-segment-routing-extensions">; companion document RFC 8665 -->
	<reference anchor="RFC8665">	<reference anchor="RFC8665">
	<front>	<front>
	<title>OSPF Extensions for Segment Routing</title>	<title>OSPF Extensions for Segment Routing</title>
	<seriesInfo name="DOI" value="10.17487/RFC8665"/>	<seriesInfo name="DOI" value="10.17487/RFC8665"/>
	<seriesInfo name="RFC" value="8665"/>	<seriesInfo name="RFC" value="8665"/>
	<author initials="P" surname="Psenak" fullname="Peter Psenak" role="editor">	<author initials="P" surname="Psenak" fullname="Peter Psenak" role="editor">
	<organization/>	<organization/>
	</author>	</author>
	<author initials="S" surname="Previdi" fullname="Stefano Previdi" role="editor">	<author initials="S" surname="Previdi" fullname="Stefano Previdi" role="editor">

	skipping to change at line 1542 ¶	skipping to change at line 1571 ¶
	<author initials="B" surname="Decraene" fullname="Bruno Decraene">	<author initials="B" surname="Decraene" fullname="Bruno Decraene">
	<organization/>	<organization/>
	</author>	</author>
	<author initials="S" surname="Litkowski" fullname="Stephane Litkowski">	<author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
	<organization/>	<organization/>
	</author>	</author>
	<date month="September" year="2019"/>	<date month="September" year="2019"/>
	</front>	</front>
	</reference>	</reference>
	</references>	</references>


	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>

	<reference anchor="RFC5305" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.53	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5305.
	05.xml">	xml"/>
	<front>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5308.
	<title>IS-IS Extensions for Traffic Engineering</title>	xml"/>
	<seriesInfo name="DOI" value="10.17487/RFC5305"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5311.
	<seriesInfo name="RFC" value="5305"/>	xml"/>
	<author initials="T." surname="Li" fullname="T. Li">	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5316.
	<organization/>	xml"/>
	</author>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7855.
	<author initials="H." surname="Smit" fullname="H. Smit">	xml"/>
	<organization/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
	</author>	xml"/>
	<date year="2008" month="October"/>
	<abstract>
	<t>This document describes extensions to the Intermediate System t
	o Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). Thi
	s document extends the IS-IS protocol by specifying new information that an Inte
	rmediate System (router) can place in Link State Protocol Data Units (LSP). Thi
	s information describes additional details regarding the state of the network th
	at are useful for traffic engineering computations. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC5308" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.53
	08.xml">
	<front>
	<title>Routing IPv6 with IS-IS</title>
	<seriesInfo name="DOI" value="10.17487/RFC5308"/>
	<seriesInfo name="RFC" value="5308"/>
	<author initials="C." surname="Hopps" fullname="C. Hopps">
	<organization/>
	</author>
	<date year="2008" month="October"/>
	<abstract>
	<t>This document specifies a method for exchanging IPv6 routing in
	formation using the IS-IS routing protocol. The described method utilizes two n
	ew TLVs: a reachability TLV and an interface address TLV to distribute the neces
	sary IPv6 information throughout a routing domain. Using this method, one can r
	oute IPv6 along with IPv4 and OSI using a single intra-domain routing protocol.
	[STANDARDS-TRACK]</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC5311" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.53
	11.xml">
	<front>
	<title>Simplified Extension of Link State PDU (LSP) Space for IS-IS<
	/title>
	<seriesInfo name="DOI" value="10.17487/RFC5311"/>
	<seriesInfo name="RFC" value="5311"/>
	<author initials="D." surname="McPherson" fullname="D. McPherson" ro
	le="editor">
	<organization/>
	</author>
	<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
	<organization/>
	</author>
	<author initials="S." surname="Previdi" fullname="S. Previdi">
	<organization/>
	</author>
	<author initials="M." surname="Shand" fullname="M. Shand">
	<organization/>
	</author>
	<date year="2009" month="February"/>
	<abstract>
	<t>This document describes a simplified method for extending the L
	ink State PDU (LSP) space beyond the 256 LSP limit. This method is intended as
	a preferred replacement for the method defined in RFC 3786. [STANDARDS-TRACK]</
	t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC5316" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.53
	16.xml">
	<front>
	<title>ISIS Extensions in Support of Inter-Autonomous System (AS) MP
	LS and GMPLS Traffic Engineering</title>
	<seriesInfo name="DOI" value="10.17487/RFC5316"/>
	<seriesInfo name="RFC" value="5316"/>
	<author initials="M." surname="Chen" fullname="M. Chen">
	<organization/>
	</author>
	<author initials="R." surname="Zhang" fullname="R. Zhang">
	<organization/>
	</author>
	<author initials="X." surname="Duan" fullname="X. Duan">
	<organization/>
	</author>
	<date year="2008" month="December"/>
	<abstract>
	<t>This document describes extensions to the ISIS (ISIS) protocol
	to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Tra
	ffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-T
	E extensions for the flooding of TE information about inter-AS links, which can
	be used to perform inter- AS TE path computation.</t>
	<t>No support for flooding information from within one AS to anoth
	er AS is proposed or defined in this document. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC7855" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.78
	55.xml">
	<front>
	<title>Source Packet Routing in Networking (SPRING) Problem Statemen
	t and Requirements</title>
	<seriesInfo name="DOI" value="10.17487/RFC7855"/>
	<seriesInfo name="RFC" value="7855"/>
	<author initials="S." surname="Previdi" fullname="S. Previdi" role="
	editor">
	<organization/>
	</author>
	<author initials="C." surname="Filsfils" fullname="C. Filsfils" role
	="editor">
	<organization/>
	</author>
	<author initials="B." surname="Decraene" fullname="B. Decraene">
	<organization/>
	</author>
	<author initials="S." surname="Litkowski" fullname="S. Litkowski">
	<organization/>
	</author>
	<author initials="M." surname="Horneffer" fullname="M. Horneffer">
	<organization/>
	</author>
	<author initials="R." surname="Shakir" fullname="R. Shakir">
	<organization/>
	</author>
	<date year="2016" month="May"/>
	<abstract>
	<t>The ability for a node to specify a forwarding path, other than
	the normal shortest path, that a particular packet will traverse, benefits a nu
	mber of network functions. Source-based routing mechanisms have previously been
	specified for network protocols but have not seen widespread adoption. In this
	context, the term "source" means "the point at which the explicit route is impo
	sed"; therefore, it is not limited to the originator of the packet (i.e., the no
	de imposing the explicit route may be the ingress node of an operator's network)
	.</t>
	<t>This document outlines various use cases, with their requiremen
	ts, that need to be taken into account by the Source Packet Routing in Networkin
	g (SPRING) architecture for unicast traffic. Multicast use cases and requiremen
	ts are out of scope for this document.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC8126" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81
	26.xml">
	<front>
	<title>Guidelines for Writing an IANA Considerations Section in RFCs
	</title>
	<seriesInfo name="DOI" value="10.17487/RFC8126"/>
	<seriesInfo name="RFC" value="8126"/>
	<seriesInfo name="BCP" value="26"/>
	<author initials="M." surname="Cotton" fullname="M. Cotton">
	<organization/>
	</author>
	<author initials="B." surname="Leiba" fullname="B. Leiba">
	<organization/>
	</author>
	<author initials="T." surname="Narten" fullname="T. Narten">
	<organization/>
	</author>
	<date year="2017" month="June"/>
	<abstract>
	<t>Many protocols make use of points of extensibility that use con
	stants to identify various protocol parameters. To ensure that the values in th
	ese fields do not have conflicting uses and to promote interoperability, their a
	llocations are often coordinated by a central record keeper. For IETF protocols
	, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
	<t>To make assignments in a given registry prudently, guidance des
	cribing the conditions under which new values should be assigned, as well as whe
	n and how modifications to existing values can be made, is needed. This documen
	t defines a framework for the documentation of these guidelines by specification
	authors, in order to assure that the provided guidance for the IANA Considerati
	ons is clear and addresses the various issues that are likely in the operation o
	f a registry.</t>
	<t>This is the third edition of this document; it obsoletes RFC 52
	26.</t>
	</abstract>
	</front>
	</reference>
	</references>	</references>
	</references>	</references>
	<section anchor="Acknowledgements" numbered="false" toc="default">	<section anchor="Acknowledgements" numbered="false" toc="default">
	<name>Acknowledgements</name>	<name>Acknowledgements</name>
	<t>We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre	<t>We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre
	Francois, and Jesper Skrivers for their contribution to the content of	Francois, and Jesper Skrivers for their contribution to the content of
	this document.</t>	this document.</t>
	</section>	</section>
	<section anchor="Contributors" numbered="false" toc="default">	<section anchor="Contributors" numbered="false" toc="default">
	<name>Contributors</name>	<name>Contributors</name>
	<t>The following people gave a substantial contribution to the content	<t>The following people gave a substantial contribution to the content
	of this document and should be considered as coauthors:</t>	of this document and should be considered as coauthors:</t>

	<artwork name="" type="" align="left"alt=""><![CDATA[Stephane Litkowski	<artwork name="" type="" align="left"alt=""><![CDATA[
		Stephane Litkowski
	Orange	Orange
	France	France
	Email: stephane.litkowski@orange.com	Email: stephane.litkowski@orange.com

		]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Jeff Tantsura	Jeff Tantsura
	Apstra, Inc.	Apstra, Inc.
	Email: jefftant@gmail.com	Email: jefftant@gmail.com

		]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Peter Psenak	Peter Psenak
	Cisco Systems Inc.	Cisco Systems Inc.
	United States of America	United States of America
	Email: ppsenak@cisco.com	Email: ppsenak@cisco.com

		]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Martin Horneffer	Martin Horneffer
	Deutsche Telekom	Deutsche Telekom
	Germany	Germany
	Email: Martin.Horneffer@telekom.de	Email: Martin.Horneffer@telekom.de

		]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Wim Henderickx	Wim Henderickx
	Nokia	Nokia
	Belgium	Belgium
	Email: wim.henderickx@nokia.com	Email: wim.henderickx@nokia.com

		]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Edward Crabbe	Edward Crabbe
	Oracle	Oracle
	United States of America	United States of America
	Email: edward.crabbe@oracle.com	Email: edward.crabbe@oracle.com

		]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Rob Shakir	Rob Shakir
	Google	Google
	United Kingdom	United Kingdom
	Email: robjs@google.com	Email: robjs@google.com

		]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Igor Milojevic	Igor Milojevic
	Individual	Individual
	Serbia	Serbia
	Email: milojevicigor@gmail.com	Email: milojevicigor@gmail.com

		]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Saku Ytti	Saku Ytti
	TDC	TDC
	Finland	Finland
	Email: saku@ytti.fi	Email: saku@ytti.fi

		]]></artwork>
		<artwork name="" type="" align="left" alt=""><![CDATA[
	Steven Luong	Steven Luong
	Cisco Systems, Inc.	Cisco Systems, Inc.
	United States of America	United States of America
	Email: sluong@cisco.com]]></artwork>	Email: sluong@cisco.com]]></artwork>
	</section>	</section>
	<!-- [rfced] Throughout the text, the following terminology appears to be	<!-- [rfced] Throughout the text, the following terminology appears to be
	used inconsistently. Please review these occurrences and let us know if/how	used inconsistently. Please review these occurrences and let us know if/how
	they may be made consistent.	they may be made consistent.

	0 vs. zero (e.g., 'must be zero' or 'set to 0')	0 vs. zero (e.g., 'must be zero' or 'set to 0')

End of changes. 179 change blocks.
	940 lines changed or deleted	817 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available fromhttp://tools.ietf.org/tools/rfcdiff/

[8]ページ先頭