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="" xm l: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="Prev idi"> <author fullname="Stefano Previdi" initials="S." role="editor" surname="Prev idi">
<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 wi th RSVP or LDP.</t> interoperate in the presence of Label Switched Paths (LSPs) established wi th 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 target="RFC8402" format="default"/>. This document also defines an a dvertisement <xref target="RFC8402" format="default"/>. This document also defines an a dvertisement
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 target="RFC8402" format="default"/>. Segment Routing use cases are described in <xref target="R FC7855" format="default"/>.</t> <t>The Segment Routing architecture is described in <xref target="RFC8402" format="default"/>. Segment Routing use cases are described in <xref target="R FC7855" 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 in BCP 14 <xref target="RFC2119" format="default"/> <xref target=" RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
RFC8174" format="default"/> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="
RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.</t> 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 target="RFC8402" format="default "/> defines <t>The Segment Routing architecture <xref target="RFC8402" 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 target="RFC8402" format="default"/>. The 'Prefix SID ' MUST be as defined in <xref target="RFC8402" 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
and MAY 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 <xref target="RFC5 <li>TLV-135 (Extended IPv4 reachability) defined in <xref target="RFC5
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 target="RFC5308" f <li>TLV-236 (IPv6 IP Reachability) defined in <xref target="RFC5308" 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 target="BINDINGTLV" format="counter"/> and <xref target="MTBINDINGTLV ions <xref target="BINDINGTLV" format="counter"/> and <xref target="MTBINDINGTLV
" 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 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|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-SID ref
<dd>N-Flag: Node-SID flag. If set, then the Prefix-SID refers 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 add ress. is set on Prefix-SIDs that are attached to a router loopback add ress.
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 target="RFC8402" format="default"/>.</dd> described in <xref target="RFC8402" 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 hop MUST NOT</bcp14> pop the Prefix-SID before delivering the packet to t
NOT pop the Prefix-SID before delivering the packet to the 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 upstream neigh
<dd>E-Flag: Explicit-Null Flag. If set, any upstream neighbor bor
of the Prefix-SID originator MUST replace the Prefix-SID with of the Prefix-SID originator <bcp14>MUST</bcp14> replace the Pre
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-SID carrie
<dd>V-Flag: Value flag. If set, then the Prefix-SID carries 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/index carri
<dd>L-Flag: Local Flag. If set, then the value/index carried 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 when originate
<dd>Other bits: MUST be zero when originated 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 target="SRAL GOSUBTLV" format="default"/>. Examples of these algorithms are metric-based these nodes. Algorithm identifiers are defined in <xref target="SRAL GOSUBTLV" 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 field MUST 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 target="SRALGOSUBTLV" format="defaul SR-Algorithm sub-TLV (see <xref target="SRALGOSUBTLV" format="defaul
t"/>) MUST ignore t"/>) <bcp14>MUST</bcp14> ignore
the Prefix-SID sub‑TLV.</dd> the Prefix-SID sub-TLV.</li>
<dt/>
<dd>SID/Index/Label as defined in <xref target="VANDLFLAGS" format="de <li>SID/Index/Label as defined in <xref target="VANDLFLAGS" format="de
fault"/>.</dd> fault"/>.</li>
</dl> </ul>
<t>When the Prefix SID is an index (and the V-flag is not set), the valu e <t>When the Prefix SID is an index (and the V-flag is not set), the valu e
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 to 0: The SID/Index/Label <ul empty="true"><li>
field is a 4‑octet index defining the offset in the SID/Label <dl>
<dt>The V-flag and L-flag are set to 0:</dt><dd>The SID/Index/Label
field is a 4-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
<xref target="SRCAPSUBTLV" format="default"/>.</t> <xref target="SRCAPSUBTLV" format="default"/>.</dd>
<t>The V-flag and L-flag are set to 1: The SID/Index/Label
<dt>The V-flag and L-flag are set to 1:</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 label value.</t> used for encoding the label value.</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
flags MUST 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-Flag MUST be set for prefixes that are not local to the <t>The R-Flag <bcp14>MUST</bcp14> be set for prefixes that are not l ocal 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 into Level-2);</dd> <li>propagation (Level-1 into Level-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 another protocol).</li>
<dt/> </ul>
<dd>redistribution (e.g., from another protocol).</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 router MAY <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 router MUST ignore the N-Flag on a received Prefix-SID if <t>The router <bcp14>MUST</bcp14> ignore the N-Flag on a received Pr
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 target="RFC7794" format= "default"/> <t>The Prefix Attribute Flags sub-TLV <xref target="RFC7794" 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-TLV MUST 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 originator MUST pop the Prefix-SID. This is Prefix-SID originator <bcp14>MUST</bcp14> pop the Prefix-SID. Th is 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 originator MUST keep the Prefix-SID on top the Prefix-SID originator <bcp14>MUST</bcp14> keep the Prefi x-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 originator MUST 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 Le vel‑1) <t>When propagating (from either Level-1 to Level-2 or Level-2 to Le vel-1)
a reachability advertisement originated by another IS-IS speaker, a reachability advertisement originated by another IS-IS speaker,
the router MUST 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-TLV MUST be included when the associated <t>The Prefix-SID sub-TLV <bcp14>MUST</bcp14> be included when the ass ociated
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 target="RANDNFLAGS" format="counter"/> and <xref tar get="EANDPFLAGS" format="counter"/>.</t> in Sections <xref target="RANDNFLAGS" format="counter"/> and <xref tar get="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 target="RFC8402" format="d efault"/> with Routing IGP-Adjacency-SID as defined in <xref target="RFC8402" format="d efault"/> 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 target="RFC5305" format="d
<dd>TLV-22 (Extended IS reachability) <xref target="RFC5305" format="d efault"/></li>
efault"/></dd> <li>TLV-222 (MT-ISN) <xref target="RFC5120" format="default"/></li>
<dt/> <li>TLV-23 (IS Neighbor Attribute) <xref target="RFC5311" format="defa
<dd>TLV-222 (MT-ISN) <xref target="RFC5120" format="default"/></dd> ult"/></li>
<dt/> <li>TLV-223 (MT IS Neighbor Attribute) <xref target="RFC5311" format="
<dd>TLV-23 (IS Neighbor Attribute) <xref target="RFC5311" format="defa default"/></li>
ult"/></dd> <li>TLV-141 (inter-AS reachability information) <xref target="RFC5316"
<dt/> format="default"/></li>
<dd>TLV-223 (MT IS Neighbor Attribute) <xref target="RFC5311" format=" </ul>
default"/></dd> <t>Multiple Adj-SID sub-TLVs <bcp14>MAY</bcp14> be associated with a sin
<dt/> gle
<dd>TLV-141 (inter-AS reachability information) <xref target="RFC5316"
format="default"/></dd>
</dl>
<t>Multiple Adj-SID sub-TLVs MAY be associated with a single
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 following flags:</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 following flags: </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 the Adj-SID <dt>F-Flag:</dt><dd>Address-Family flag. If unset, then the Adj-
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 R eroute (MPLS-FRR)) as described in protection (e.g., using IP Fast Reroute (IPFRR) or MPLS Fast R eroute (MPLS-FRR)) as described in
<xref target="RFC8402" format="default"/>.</dd> <xref target="RFC8402" 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/index carried <dt>L-Flag:</dt><dd>Local Flag. If set, then the value/index car
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 indicates that the <dt>S-Flag:</dt><dd>Set flag. When set, the S-Flag indicates tha
Adj‑SID refers to a set of adjacencies (and therefore MAY 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-Flag indicates <dt>P-Flag:</dt><dd>Persistent flag. When set, the P-Flag indica
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 when originated and ignored when <dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero when origina
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 target="RFC8402" format="default"/>.</dd> is defined in <xref target="RFC8402" format="default"/>.</dd>
<dt/> </dl>
<dd>SID/Index/Label as defined in <xref target="VANDLFLAGS" format=" </li>
default"/>.</dd> </ul>
<dt/>
<dd>An SR-capable router MAY allocate an Adj-SID for each of its <ul empty="true">
adjacencies.</dd> <li>SID/Index/Label as defined in <xref target="VANDLFLAGS" format="defa
<dt/> ult"/>.</li>
<dd>An SR-capable router MAY allocate more than one Adj-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 router MAY allocate the same Adj-SID to adjacencies.</li>
different adjacencies.</dd>
<dt/> <li>An SR-capable router <bcp14>MAY</bcp14> allocate more than one A
<dd>When the P-flag is not set, the Adj-SID MAY be persistent. dj-SID to an
When the P-flag is set, the Adj-SID MUST be persistent.</dd> adjacency.</li>
<dt/>
<dd>Examples of Adj-SID sub-TLV use are described in <xref target="R <li>An SR-capable router <bcp14>MAY</bcp14> allocate the same Adj-SI
FC8402" format="default"/>.</dd> D to
<dt/> different adjacencies.</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> be pe
rsistent.
When the P-flag is set, the Adj-SID <bcp14>MUST</bcp14> be persist
ent.</li>
<li>Examples of Adj-SID sub-TLV use are described in <xref target="R
FC8402" format="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 LAN MAY <t>When Segment Routing is used, each router in the LAN <bcp14>MAY</bc p14>
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 following flags:</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 following flags: </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 targ et="ADJSIDSUBTLV" format="default"/>. </t> <t> where the F, B, V, L, S, and P flags are defined in <xref targ et="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 target="RFC8402" format="default"/>.</dd> is defined in <xref target="RFC8402" format="default"/>.</dd>
<dt/>
<dd>Neighbor System-ID: IS-IS System-ID of length "ID Length" as <dt>Neighbor System-ID:</dt><dd>IS-IS System-ID of length "ID Length
" as
defined in <xref target="ISO10589" format="default"/>.</dd> defined in <xref target="ISO10589" format="default"/>.</dd>
<dt/>
<dd>SID/Index/Label: As defined in <xref target="VANDLFLAGS" format= <dt>SID/Index/Label:</dt><dd>As defined in <xref target="VANDLFLAGS"
"default"/>.</dd> format="default"/>.</dd>
</dl> </dl>
<t>Multiple LAN-Adj-SID sub-TLVs MAY be encoded.</t> </li>
<t>Note that this sub-TLV MUST NOT appear in TLV 141.</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 TLV 141.</
t>
<t>In case TLV-22, TLV-23, TLV-222, or TLV-223 (reporting the adjacenc y to the <t>In case TLV-22, TLV-23, TLV-222, or TLV-223 (reporting the adjacenc y 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 DIS MUST be used, and all advertisements of the adjacency to the DIS <bcp14>MUST</bcp14> be used
advertisements MUST 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 (<xref target="SRCAPSUBTLV" format="default"/ <ul empty="true">
>)</t> <li>SR-Capabilities sub-TLV (<xref target="SRCAPSUBTLV" format="default"
<t>SR Local Block sub-TLV (<xref target="SRLBSUBTLV" format="default"/>) />)</li>
</t> <li>SR Local Block sub-TLV (<xref target="SRLBSUBTLV" format="default"/>
<t>SID/Label Binding TLV (<xref target="BINDINGTLV" format="default"/>)< )</li>
/t> <li>SID/Label Binding TLV (<xref target="BINDINGTLV" format="default"/>)
<t>Multi-Topology SID/Label Binding TLV (<xref target="MTBINDINGTLV" for </li>
mat="default"/>)</t> <li>Multi-Topology SID/Label Binding TLV (<xref target="MTBINDINGTLV" fo
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 or 4</dd>
<li>Length: 3 or 4</li>
<li>SID/Label: If the length is set to 3, then the 20 rightmost bits <dt>SID/Label:</dt><dd>If the length is set to 3, then the 20 rightmos
t bits
represent an MPLS label. If the length is set to 4, then the value i s a represent an MPLS label. If the length is set to 4, then the value i s a
32-bit index.</li> 32-bit index.</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 TLV MAY be originated by any router in an <t>The SID/Label Binding TLV <bcp14>MAY</bcp14> be originated by any rou ter 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 targ et="RFC8661" format="default"/>.</t> Mapping Server (SRMS). The behavior of the SRMS is defined in <xref targ et="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 desti ned to SID indicating the ability of a node to process traffic originally desti ned to
another IGP node. This behavior is defined in <xref target="RFC8402" for mat="default"/>.</t> another IGP node. This behavior is defined in <xref target="RFC8402" for mat="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 target="RFC8402" format="default"/>.</dd> is described in <xref target="RFC8402" format="default"/>.</dd>
<dt/>
<dd>S-Flag: If set, the SID/Label Binding TLV SHOULD 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 TLV MUST NOT be leaked between levels. This SID/Label Binding TLV <bcp14>MUST NOT</bcp14> be leaked between le
bit MUST NOT be altered during the TLV leaking.</dd> vels. This
<dt/> bit <bcp14>MUST NOT</bcp14> be altered during the TLV leaking.</dd
<dd>D-Flag: When the SID/Label Binding TLV is leaked from Level-2 >
to Level-1, the D-Flag MUST be set. Otherwise, this flag MUST be
clear. SID/Label Binding TLVs with the D-Flag set MUST NOT be <dt>D-Flag:</dt><dd>When the SID/Label Binding TLV is leaked from Le
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 TLV MAY set the A bit in order to signal that the Binding TLV <bcp14>MAY</bcp14> set the A bit in order to signal th
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-flag MUST 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 field MUST be set to one. For range advertisements &gt; 1, the Range field <bcp14>MUST</bcp14> be set to one. For range advertise
the Range field MUST be set to the number of addresses that need to ments &gt; 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 1 13 for prefix length 25 up to 32, ...., and 16 octets for prefix length 1 13
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 target="PREFIXSIDSUBTLV" format="default"/> and contains the SID/Index/Label value <t>The Prefix-SID sub-TLV is defined in <xref target="PREFIXSIDSUBTLV" format="default"/> and contains the SID/Index/Label value
associated with the prefix and range. The Prefix-SID sub-TLV MUST be associated with the prefix and range. The Prefix-SID sub-TLV <bcp14>MU ST</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-TLV MUST NOT be present when the M-flag is set.</t> Prefix-SID sub-TLV <bcp14>MUST NOT</bcp14> be present when the M-flag is 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 target="PREFIXSIDSUBTLV " format="default"/>. The Mapping Server MAY advertise a <t>The Prefix-SID flags are defined in <xref target="PREFIXSIDSUBTLV " 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 target="PREFIXSIDSUBTLV" format= "default"/> are <t>The other flags defined in <xref target="PREFIXSIDSUBTLV" format= "default"/> are
not used by the Mapping Server and MUST 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 target="RFC7794" format="default"/>.</li> <xref target="RFC7794" 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 target=" RFC7794" format="default"/>, the A flag in the binding TLV indicates that <t>In the absence of a Prefix Attribute Flags sub-TLV <xref target=" RFC7794" 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, PHP MUST be done by the neighbors connected to the prefix; thus, PHP <bcp14>MUST</bcp14> be done by th e 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 target="PREFIXSIDSUBTLV" f ormat="default"/>.</t> the Algorithm field is described in <xref target="PREFIXSIDSUBTLV" f ormat="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 target="SIDLABELSUBTLV" format="default"/>. It MUST b e present in defined in <xref target="SIDLABELSUBTLV" 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: Index 1 <ul empty="true">
Router-B: 192.0.2.2/32, Prefix-SID: Index 2 <li>Router-A: 192.0.2.1/32, Prefix-SID: Index 1</li>
Router-C: 192.0.2.3/32, Prefix-SID: Index 3 <li>Router-B: 192.0.2.2/32, Prefix-SID: Index 2</li>
Router-D: 192.0.2.4/32, Prefix-SID: Index 4 <li>Router-C: 192.0.2.3/32, Prefix-SID: Index 3</li>
]]></artwork> <li>Router-D: 192.0.2.4/32, Prefix-SID: Index 4</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: Index 51 <ul empty="true">
10.1.2/24, Prefix-SID: Index 52 <li>10.1.1/24, Prefix-SID: Index 51</li>
10.1.3/24, Prefix-SID: Index 53 <li>10.1.2/24, Prefix-SID: Index 52</li>
10.1.4/24, Prefix-SID: Index 54 <li>10.1.3/24, Prefix-SID: Index 53</li>
10.1.5/24, Prefix-SID: Index 55 <li>10.1.4/24, Prefix-SID: Index 54</li>
10.1.6/24, Prefix-SID: Index 56 <li>10.1.5/24, Prefix-SID: Index 55</li>
10.1.7/24, Prefix-SID: Index 57 <li>10.1.6/24, Prefix-SID: Index 56</li>
]]></artwork> <li>10.1.7/24, Prefix-SID: Index 57</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: Index 151 <ul empty="true">
2001:db8:2/48, Prefix-SID: Index 152 <li>2001:db8:1/48, Prefix-SID: Index 151</li>
2001:db8:3/48, Prefix-SID: Index 153 <li>2001:db8:2/48, Prefix-SID: Index 152</li>
2001:db8:4/48, Prefix-SID: Index 154 <li>2001:db8:3/48, Prefix-SID: Index 153</li>
]]></artwork> <li>2001:db8:4/48, Prefix-SID: Index 154</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 implementation MAY generate several noncontinuous mapping ranges, an implementation <bcp14>MAY</bcp14> gen erate 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 target="RFC5120" forma t="default"/>. The Multi-Topology Multi-Topology IS-IS (M-ISIS) as defined in <xref target="RFC5120" forma t="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 target="BINDINGTLV" format="default"/> with the differe nce consisting defined in <xref target="BINDINGTLV" format="default"/> with the differe nce consisting
of a Multitopology Identifier (MTID) as defined here below:</t> of a Multitopology Identifier (MT ID) 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 defined as: </t>
<t>MT ID is the multitopology identifier defined as:</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 of the <dt>MT ID:</dt><dd>A 12-bit field containing the non-zero ID of th
topology being announced. The TLV MUST 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 <xref target="BINDING </ul>
TLV" format="default"/>.</dd> </li>
</dl> </ul>
<ul empty="true"><li>
<t>The other fields and sub-TLVs are defined in <xref target="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 target="RFC7981" format="defaul t"/>.</t> Router Capability that is defined in <xref target="RFC7981" format="defaul t"/>.</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-TLV MUST be propagated advertisement. The SR-Capabilities sub-TLV <bcp14>MUST</bcp14> be propag
throughout the level and MUST NOT be advertised across level ated
throughout the level and <bcp14>MUST NOT</bcp14> be advertised across le
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 is capable <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 is cap
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 is capable <dt>V-Flag:</dt><dd>MPLS IPv6 flag. If set, then the router is cap
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 entrie s, each of which have the <t>One or more Segment Routing Global Block (SRGB) Descriptor entrie s, 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 <xref target="SIDLABELSUBTLV" <dt>SID/Label sub-TLV:</dt><dd>MPLS label as defined in <xref targ
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 value MUST 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-TLV MAY be advertised in an LSP of any <t>The SR-Capabilities sub-TLV <bcp14>MAY</bcp14> be advertised in an LS
number, but a router MUST NOT advertise more than one SR-Capabilities P of any
number, but a router <bcp14>MUST NOT</bcp14> advertise more than one SR-
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 originator SHOULD select the first advertisement in the lowest-numb ered 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 descriptor SHOULD add the newly SR-Capabilities sub-TLV, the new descriptor <bcp14>SHOULD</bcp14> add th
configured block at the end of the sub-TLV and SHOULD 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 router MUST ensure the order is unchanged after a <t>The originating router <bcp14>MUST</bcp14> ensure the order is unchan ged 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 router MUST NOT advertise overlapping ranges.</t> <t>The originating router <bcp14>MUST NOT</bcp14> advertise overlapping
<t>When a router receives multiple overlapping ranges, it MUST conform ranges.</t>
<t>When a router receives multiple overlapping ranges, it <bcp14>MUST</b
cp14> conform
to the procedures defined in <xref target="RFC8660" format="default"/>.< /t> to the procedures defined in <xref target="RFC8660" 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 as follows: order and build the SRGB as follows:</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 multiple ranges: <ul empty="true" spacing="normal">
<li>The indexes span multiple ranges:</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 target="RFC8665" format="default"/>. defined in <xref target="RFC8665" 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 target="RFC8665" format="default"/>. defined in <xref target="RFC8665" 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 local policy.</li> the SPF path with a different path based on local policy.</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 policy MUST NOT alter the forwarding decision decision. Local policy <bcp14>MUST NOT</bcp14> alter the forwarding decision
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-Algorithm MUST be propagated throughout the advertisement. The SR-Algorithm <bcp14>MUST</bcp14> be propagated throug
level and MUST 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 flag MUST be unset.</t> the S flag <bcp14>MUST</bcp14> be unset.</t>
<t>The SR-Algorithm sub-TLV is optional. It MUST NOT be advertised <t>The SR-Algorithm sub-TLV is optional. It <bcp14>MUST NOT</bcp14> be a
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 originator SHOULD select the first SR-Algorithm sub-TLVs from the same originator <bcp14>SHOULD</bcp14> sel ect 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 0 MUST 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 this stage.</dd> <dt>Flags:</dt><dd>1 octet of flags. None are defined at this stage.</
<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 <xref target="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 <xref targ
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 value MUST 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-TLV MAY be advertised in an LSP of any number, but a <t>The SRLB sub-TLV <bcp14>MAY</bcp14> be advertised in an LSP of any nu
router MUST NOT advertise more than one SRLB sub-TLV. A router 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. A r
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 router MUST NOT advertise overlapping ranges.</t> <t>The originating router <bcp14>MUST NOT</bcp14> advertise overlapping
<t>When a router receives multiple overlapping ranges, it MUST conform ranges.</t>
<t>When a router receives multiple overlapping ranges, it <bcp14>MUST</b
cp14> conform
to the procedures defined in <xref target="RFC8660" format="default"/>.< /t> to the procedures defined in <xref target="RFC8660" 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 SRMS preference.</dd> <dt>Preference:</dt><dd>1 octet and unsigned 8-bit SRMS preference.</d
d>
</dl> </dl>
<t>The SRMS Preference sub-TLV MAY be advertised in an LSP of any </li>
number, but a router MUST NOT advertise more than one SRMS Preference </ul>
<t>The SRMS Preference sub-TLV <bcp14>MAY</bcp14> be advertised in an LS
P of any
number, but a router <bcp14>MUST NOT</bcp14> advertise more than one SRM
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 advertisemen t 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 target="RFC8661" format="default"/>.</t> described in <xref target="RFC8661" 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 Routing Capability <!-- <name>Registrations in the "Sub-TLVs for TLV 242" Registry</name>-->
19 Segment Routing Algorithm <thead>
22 Segment Routing Local Block (SRLB) <tr>
24 Segment Routing Mapping Server Preference (SRMS Preference) <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 Routing Capability</td>
</tr>
<tr>
<td align="center">19</td>
<td align="left">Segment Routing Algorithm</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 (SRMS Preferenc
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">
149 Segment Identifier/Label Binding n y n n <!--<name>Registrations for TLVs 149 and 150</name>-->
150 Multi-Topology Segment Identifier n y n n <thead>
/ Label Binding]]></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/Label Binding</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 / Label Binding</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 and 150 <dl>
Registration Procedure: Expert Review <xref target="RFC8126" format="default"/>< <dt>Name:</dt>
/t> <dd>Sub-TLVs for TLVs 149 and 150</dd>
<artwork name="" type="" align="left" alt=""><![CDATA[ <dt>Registration Procedure:</dt>
Type Description <dd>Expert Review <xref target="RFC8126" format="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 target="RFC3031" format="default"/>. In general, the same type of at tacks that can be carried out <xref target="RFC3031" format="default"/>. In general, the same type of at tacks 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 target="RFC5304" for mat="default"/> <t>Existing security extensions as described in <xref target="RFC5304" for mat="default"/>
skipping to change at line 1248 skipping to change at line 1457
<xref target="RFC3031" format="default"/>. In general, the same type of at tacks that can be carried out <xref target="RFC3031" format="default"/>. In general, the same type of at tacks 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 target="RFC5304" for mat="default"/> <t>Existing security extensions as described in <xref target="RFC5304" for mat="default"/>
and <xref target="RFC5310" format="default"/> apply to these segment ro uting extensions.</t> and <xref target="RFC5310" format="default"/> apply to these segment ro uting 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" target="https://www.rfc-editor.org/info/rfc2
119" 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-dom ain <title>Information technology -- Telecommunications and information exchange between systems -- Intermediate system to Intermediate system intra-dom ain
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 Standard ization</organization> <organization abbrev="ISO">International Organization for Standard ization</organization>
</author> </author>
<date month="November" year="2002"/> <date month="November" year="2002"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3
031" 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" target="https://www.rfc-editor.org/info/rfc5
304" 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" target="https://www.rfc-editor.org/info/rfc5
310" 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" target="https://www.rfc-editor.org/info/rfc5
120" 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" target="https://www.rfc-editor.org/info/rfc7
981" 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" target="https://www.rfc-editor.org/info/rfc7
794" 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" target="https://www.rfc-editor.org/info/rfc8
174" 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" target="https://www.rfc-editor.org/info/rfc8
402" 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" target="https://www.rfc-editor.org/info/rfc8 665"> <reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8 665">
<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" ro le="editor"> <author initials="S" surname="Previdi" fullname="Stefano Previdi" ro le="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 Litkowsk i"> <author initials="S" surname="Litkowski" fullname="Stephane Litkowsk i">
<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" target="https://www.rfc-editor.org/info/rfc5
305" 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" target="https://www.rfc-editor.org/info/rfc5
308" 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" target="https://www.rfc-editor.org/info/rfc5
311" 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" target="https://www.rfc-editor.org/info/rfc5
316" 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" target="https://www.rfc-editor.org/info/rfc7
855" 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" target="https://www.rfc-editor.org/info/rfc8
126" 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 from http://tools.ietf.org/tools/rfcdiff/