rfc8667xml2.original.xml   rfc8667.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc tocompact="yes"?> std" consensus="true" number="8667" ipr="trust200902" obsoletes="" updates="" xm
<?rfc tocdepth="3"?> l:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3" docName
<?rfc tocindent="yes"?> ="draft-ietf-pce-segment-routing-16">
<?rfc symrefs="yes"?> <!-- xml2rfc v2v3 conversion 2.27.1 -->
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-isis-segment-routing-extensions-25"
ipr="trust200902">
<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"/>
<author fullname="Stefano Previdi" initials="S." role="editor" <author fullname="Stefano Previdi" initials="S." role="editor" surname="Prev
surname="Previdi"> idi">
<organization>Huawei</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country>Italy</country>
<country>IT</country>
</postal> </postal>
<email>stefano@previdi.net</email> <email>stefano@previdi.net</email>
</address> </address>
</author> </author>
<author fullname="Les Ginsberg" initials="L." role="editor" surname="Ginsber
<author fullname="Les Ginsberg" initials="L." role="editor" g">
surname="Ginsberg">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>ginsberg@cisco.com</email> <email>ginsberg@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Brussels</city> <city>Brussels</city>
<region/> <region/>
<code/> <code/>
<country>Belgium</country>
<country>BE</country>
</postal> </postal>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Ahmed Bashandy" initials="A." surname="Bashandy"> <author fullname="Ahmed Bashandy" initials="A." surname="Bashandy">
<organization>Arrcus</organization> <organization>Arrcus</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<country/> <country/>
</postal> </postal>
<email>abashandy.ietf@gmail.com</email> <email>abashandy.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler"> <author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization>RtBrick Inc.</organization> <organization>RtBrick Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <code/>
<country/> <country/>
</postal> </postal>
<email>hannes@rtbrick.com</email> <email>hannes@rtbrick.com</email>
</address> </address>
</author> </author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene"> <author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country>France</country>
<country>FR</country>
</postal> </postal>
<email>bruno.decraene@orange.com</email> <email>bruno.decraene@orange.com</email>
</address> </address>
</author> </author>
<date year="2019" month="December"/>
<date day="19" month="May" year="2019"/>
<area>Routing</area> <area>Routing</area>
<workgroup>IS-IS for IP Internets</workgroup> <workgroup>IS-IS for IP Internets</workgroup>
<keyword>MPLS</keyword> <keyword>MPLS</keyword>
<keyword>SID</keyword> <keyword>SID</keyword>
<keyword>IGP</keyword> <keyword>IGP</keyword>
<keyword>IS-IS</keyword> <keyword>IS-IS</keyword>
<keyword>Label advertisement</keyword> <keyword>Label advertisement</keyword>
<keyword>Segment Routing</keyword> <keyword>Segment Routing</keyword>
<abstract> <abstract>
<t>Segment Routing (SR) allows for a flexible definition of end-to-end <t>Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are advertised topological sub-paths, called "segments". These segments are advertised
by the link-state routing protocols (IS-IS and OSPF).</t> by the link-state routing protocols (IS-IS and OSPF).</t>
<t>This document describes the IS-IS extensions that need to be
<t>This draft describes the necessary 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>
</abstract> </abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
</note>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>Segment Routing (SR) allows for a flexible definition of end-to-end <t>Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are advertised topological sub-paths, called "segments". These segments are advertised
by the link-state routing protocols (IS-IS and OSPF). Prefix segments by the link-state routing protocols (IS-IS and OSPF). Prefix segments
represent an ECMP-aware shortest-path to a prefix (or a node), as per represent an ECMP-aware shortest path to a prefix (or a node), as per
the state of the IGP topology. Adjacency segments represent a hop over a the state of the IGP topology. Adjacency segments represent a hop over a
specific adjacency between two nodes in the IGP. A prefix segment is specific adjacency between two nodes in the IGP. A prefix segment is
typically a multi-hop path while an adjacency segment, in most of the typically a multi-hop path while an adjacency segment, in most of the
cases, is a one-hop path. SR's control-plane can be applied to both IPv6 cases, is a one-hop path. SR's control plane can be applied to both IPv6
and MPLS data-planes, and does not require any additional signaling and MPLS data planes and does not require any additional signaling
(other than the regular IGP). For example, when used in MPLS networks, (other than the regular IGP). For example, when used in MPLS networks,
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 LSPs established with 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., Binding SID defined in <t>There are additional segment types, e.g., the Binding SID as defined in
<xref target="RFC8402"/>. This document also defines an advertisement <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 draft describes the necessary 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
<t>The Segment Routing architecture is described in <xref FC7855" format="default"/>.</t>
target="RFC8402"/>.</t> <section numbered="true" toc="default">
<name>Requirements Language</name>
<t>Segment Routing use cases are described in <xref <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
target="RFC7855"/>.</t> 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
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>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Segment Routing Identifiers"> <name>Segment Routing Identifiers</name>
<t>The Segment Routing architecture <xref target="RFC8402"/> defines <t>The Segment Routing architecture <xref target="RFC8402" format="default
different types of Segment Identifiers (SID). This document defines the "/> defines
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" <name>Prefix Segment Identifier (Prefix-SID) Sub-TLV</name>
title="Prefix Segment Identifier (Prefix-SID Sub-TLV)">
<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
sub-TLV (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"/>. The 'Prefix SID' MUST be as defined in <xref target="RFC8402" format="default"/>. The 'Prefix-SID
unique within a given IGP domain (when the L-flag is not set).</t> ' <bcp14>MUST</bcp14> be
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: <list style="hanging"> and <bcp14>MAY</bcp14> be present in any of the following TLVs: </t>
<t>TLV-135 (Extended IPv4 reachability) defined in <xref
target="RFC5305"/>.</t>
<t>TLV-235 (Multitopology IPv4 Reachability) defined in <xref <ul empty="true">
target="RFC5120"/>.</t> <li>TLV-135 (Extended IPv4 reachability) defined in <xref target="RFC5
305" format="default"/>.</li>
<t>TLV-236 (IPv6 IP Reachability) defined in <xref <li>TLV-235 (Multi-topology IPv4 Reachability) defined in <xref target
target="RFC5308"/>.</t> ="RFC5120" format="default"/>.</li>
<t>TLV-237 (Multitopology IPv6 IP Reachability) defined in <xref <li>TLV-236 (IPv6 IP Reachability) defined in <xref target="RFC5308" f
target="RFC5120"/>.</t> ormat="default"/>.</li>
<t>Binding-TLV and Multi-Topology Binding-TLV defined in <xref <li>TLV-237 (Multi-topology IPv6 IP Reachability) defined in <xref tar
target="BINDINGTLV"/> and <xref target="MTBINDINGTLV"/> get="RFC5120" format="default"/>.</li>
respectively.</t>
</list></t>
<t>The Prefix-SID sub-TLV has the following format:<figure> <li>The Binding TLV and Multi-Topology Binding TLV are defined in Sect
<artwork><![CDATA[ ions <xref target="BINDINGTLV" format="counter"/> and <xref target="MTBINDINGTLV
" format="counter"/>,
respectively.</li>
</ul>
<t>The Prefix-SID sub-TLV has the following format:</t>
<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">
</figure><list style="hanging"> <li>
<t>Type: 3</t> <dl newline="false" spacing="normal" indent="9">
<dt>Type:</dt><dd>3</dd>
<t>Length: 5 or 6 depending on the size of the SID (described <dt>Length:</dt><dd>5 or 6 depending on the size of the SID (described
below)</t> below)</dd>
<dt>
<t>Flags: 1 octet field of following flags: <figure> Flags:</dt><dd><t> 1-octet field of the following flags:</t>
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R|N|P|E|V|L| |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> where: <list style="hanging">
<t>R-Flag: Re-advertisement flag. If set, then the prefix to
which this Prefix-SID is attached, has been propagated by the
router either from another level (i.e., from level-1 to
level-2 or the opposite) or from redistribution (e.g.: from
another protocol).</t>
<t>N-Flag: Node-SID flag. If set, then the Prefix-SID refers <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R|N|P|E|V|L| |
+-+-+-+-+-+-+-+-+]]></artwork>
<t> where: </t>
<dl newline="false" spacing="normal" indent="9">
<dt>R-Flag:</dt><dd>Re-advertisement Flag. If set, then the prefix
to
which this Prefix-SID is attached has been propagated by the
router from either another level (i.e., from Level-1 to
Level-2 or the opposite) or redistribution (e.g., from
another protocol).</dd>
<dt>N-Flag:</dt><dd>Node-SID Flag. If set, then the Prefix-SID ref
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 attached to a router loopback address. 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"/>.</t> described in <xref target="RFC8402" format="default"/>.</dd>
<dt>P-Flag:</dt><dd>No-PHP
<t>P-Flag: no-PHP flag. If set, then the penultimate hop MUST (No Penultimate Hop-Popping) Flag. If set, then the penultimate hop <bcp14>MUST
NOT pop the Prefix-SID before delivering the packet to the NOT</bcp14> pop the Prefix-SID before delivering the packet to t
node that advertised the Prefix-SID.</t> he
node that advertised the Prefix-SID.</dd>
<t>E-Flag: Explicit-Null Flag. If set, any upstream neighbor <dt>E-Flag:</dt><dd>Explicit NULL Flag. If set, any upstream neigh
of the Prefix-SID originator MUST replace the Prefix-SID with bor
a Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 of the Prefix-SID originator <bcp14>MUST</bcp14> replace the Pre
for IPv6) before forwarding the packet.</t> fix-SID with
a Prefix-SID that has an Explicit NULL value (0 for IPv4 and 2
<t>V-Flag: Value flag. If set, then the Prefix-SID carries a for IPv6) before forwarding the packet.</dd>
value (instead of an index). By default the flag is UNSET.</t> <dt>V-Flag:</dt><dd>Value Flag. If set, then the Prefix-SID carrie
s a
<t>L-Flag: Local Flag. If set, then the value/index carried by value (instead of an index). By default, the flag is UNSET.</dd>
the Prefix-SID has local significance. By default the flag is <dt>L-Flag:</dt><dd>Local Flag. If set, then the value/index carri
UNSET.</t> ed by
the Prefix-SID has local significance. By default, the flag is
<t>Other bits: MUST be zero when originated and ignored when UNSET.</dd>
received.</t> <dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero when originate
</list></t> d and ignored when
received.</dd>
</dl>
</dd>
</dl>
</li>
</ul>
<ul empty="true">
<li><dl newline="false" spacing="normal">
<t>Algorithm: the router may use various algorithms when <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 these nodes. Algorithm identifiers are defined in <xref target="SRAL
target="SRALGOSUBTLV"/>. Examples of these algorithms are metric GOSUBTLV" format="default"/>. Examples of these algorithms are metric-based
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.</t> the prefix to which the Prefix-SID is associated.</dd>
</dl></li></ul>
<t>At origination, the Prefix-SID algorithm field MUST be set to 0 <ul empty="true">
or to any value advertised in the SR-Algorithm sub-TLV (<xref <li>
target="SRALGOSUBTLV"/>).</t> At origination, the Prefix-SID Algorithm field <bcp14>MUST</bcp14> be
set to 0
or to any value advertised in the SR-Algorithm sub-TLV (see <xref ta
rget="SRALGOSUBTLV" format="default"/>).</li>
<t>A router receiving a Prefix-SID from a remote node and with an <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 (<xref target="SRALGOSUBTLV"/>) MUST ignore SR-Algorithm sub-TLV (see <xref target="SRALGOSUBTLV" format="defaul
the Prefix-SID sub-TLV.</t> t"/>) <bcp14>MUST</bcp14> ignore
the Prefix-SID sub-TLV.</li>
<t>SID/Index/Label as defined in <xref target="VANDLFLAGS"/>.</t>
</list></t>
<t>When the Prefix SID is an index (the V-flag is not set) the value <li>SID/Index/Label as defined in <xref target="VANDLFLAGS" format="de
fault"/>.</li>
</ul>
<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 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. other levels, there may be some ambiguity (e.g., originating router vs.
L1L2 router) for which node a particular IP prefix serves as 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" title="Flags"> <section anchor="FLAGS" numbered="true" toc="default">
<section anchor="VANDLFLAGS" title="V and L Flags"> <name>Flags</name>
<t>The V-flag indicates whether the SID/Index/Label field is a <section anchor="VANDLFLAGS" numbered="true" toc="default">
<name>V-Flag and L-Flag</name>
<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-Flag and L-Flag are valid:</t>
<ul empty="true"><li>
<t>V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label <dl>
field is a 4 octet index defining the offset in the SID/Label <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"/>.</t> <xref target="SRCAPSUBTLV" format="default"/>.</dd>
<t>V-flag is set to 1 and L-flag is 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 V and L SID advertisement received with an invalid setting for the V-Flag an
flags MUST be ignored.</t> d
L-Flag <bcp14>MUST</bcp14> be ignored.</t>
</section> </section>
<section anchor="RANDNFLAGS" title="R and N Flags"> <section anchor="RANDNFLAGS" numbered="true" toc="default">
<t>The R-Flag MUST be set for prefixes that are not local to the <name>R-Flag and N-Flag</name>
router and either:<list style="hanging"> <t>The R-Flag <bcp14>MUST</bcp14> be set for prefixes that are not l
<t>advertised because of propagation (Level-1 into ocal to the
Level-2);</t> router and are advertised because of:</t>
<t>advertised because of leaking (Level-2 into Level-1);</t>
<t>advertised because of redistribution (e.g.: from another <ul empty="true">
protocol).</t> <li>propagation (Level-1 into Level-2);</li>
</list></t> <li>leaking (Level-2 into Level-1); or</li>
<li>redistribution (e.g., from another protocol).</li>
</ul>
<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 <bcp14
<t>The N-Flag is used in order to define a Node-SID. A router MAY >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:<list style="hanging"> met:</t>
<t>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
interfaces, e.g., a 'stable transport' loopback).</t>
<t>The prefix to which the Prefix-SID is attached has a Prefix <ul empty="true">
length of either /32 (IPv4) or /128 (IPv6).</t> <li>The prefix to which the Prefix-SID is attached is local to
</list></t> the router (i.e., the prefix is configured on one of the local
interfaces, e.g., a 'stable transport' loopback).</li>
<li>The prefix to which the Prefix-SID is attached has a Prefix
length of either /32 (IPv4) or /128 (IPv6).</li>
</ul>
<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=
<t>The Prefix Attributes Flags sub-TLV <xref target="RFC7794"/> "default"/>
also defines the N and R flags and with the same semantics of the also defines the N-Flag and R-Flag and with the same semantics of th
e
equivalent flags defined in this document. Whenever the Prefix equivalent flags defined in this document. Whenever the Prefix
Attributes 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-Flag and R-Flag advertised in that sub-TLV <bcp14>MUST</bcp
the values in a corresponding Prefix SID sub-TLV (if present) MUST 14> 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" title="E and P Flags"> <name>E-Flag and P-Flag</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-F
and P flags:<list style="symbols"> lag
<t>If the P-flag is not set then any upstream neighbor of the and P-Flag:</t>
Prefix-SID originator MUST pop the Prefix-SID. This is <ul spacing="normal">
equivalent to the penultimate hop popping mechanism used in <li>If the P-Flag is not set, then any upstream neighbor of the
the MPLS dataplane which improves performance of the ultimate Prefix-SID originator <bcp14>MUST</bcp14> pop the Prefix-SID. Th
is is
equivalent to the "penultimate hop-popping" mechanism used in
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.</t> unset, the received E-Flag is ignored.</li>
<li>
<t>If the P-flag is set then:<list style="symbols"> <t>If the P-Flag is set, then:</t>
<t>If the E-flag is not set then any upstream neighbor of <ul spacing="normal">
the Prefix-SID originator MUST keep the Prefix-SID on top <li>If the E-Flag is not set, then any upstream neighbor of
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 inter-domain 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).</t> another).</li>
<li>If the E-Flag is set, then any upstream neighbor of the
<t>If the E-flag is set then any upstream neighbor of the Prefix-SID originator <bcp14>MUST</bcp14> replace the Prefix
Prefix-SID originator MUST replace the PrefixSID with a -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.</t> bits.</li>
</list></t> </ul>
</list></t> </li>
</ul>
<t>When propagating (either from Level-1 to Level-2 or vice versa) <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" title="Prefix-SID Propagation"> <section anchor="PROPAGATION" numbered="true" toc="default">
<t>The Prefix-SID sub-TLV MUST be included when the associated <name>Prefix-SID Propagation</name>
<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
in <xref target="RANDNFLAGS"/> and <xref target="EANDPFLAGS"/>.</t> get="EANDPFLAGS" format="counter"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Adjacency Segment Identifier "> <name>Adjacency Segment Identifier</name>
<t>A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier <t>A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier (Adj
sub-TLV (Adj-SID sub-TLV).</t> -SID)
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"/> 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
below:</t>
<ul empty="true">
<li>TLV-22 (Extended IS reachability) <xref target="RFC5305" format="d
efault"/></li>
<li>TLV-222 (MT-ISN) <xref target="RFC5120" format="default"/></li>
<li>TLV-23 (IS Neighbor Attribute) <xref target="RFC5311" format="defa
ult"/></li>
<li>TLV-223 (MT IS Neighbor Attribute) <xref target="RFC5311" format="
default"/></li>
<li>TLV-141 (inter-AS reachability information) <xref target="RFC5316"
format="default"/></li>
</ul>
<t>Multiple Adj-SID sub-TLVs <bcp14>MAY</bcp14> be associated with a sin
gle
IS Neighbor.</t>
<t>IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs <section anchor="ADJSIDSUBTLV" numbered="true" toc="default">
below:<list style="hanging"> <name>Adjacency Segment Identifier (Adj-SID) Sub-TLV</name>
<t>TLV-22 (Extended IS reachability)<xref target="RFC5305"/></t>
<t>TLV-222 (Multitopology IS)<xref target="RFC5120"/></t>
<t>TLV-23 (IS Neighbor Attribute)<xref target="RFC5311"/></t>
<t>TLV-223 (Multitopology IS Neighbor Attribute)<xref
target="RFC5311"/></t>
<t>TLV-141 (inter-AS reachability information)<xref
target="RFC5316"/></t>
</list></t>
<t>Multiple Adj-SID sub-TLVs MAY be associated with a single
IS-neighbor.</t>
<section anchor="ADJSIDSUBTLV" <t>The following format is defined for the Adj-SID sub-TLV:</t>
title="Adjacency Segment Identifier (Adj-SID) Sub-TLV"> <artwork name="" type="" align="left" alt=""><![CDATA[
<t>The following format is defined for the Adj-SID sub-TLV:<figure>
<artwork><![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>
</figure><list style="hanging"> <dl newline="false" spacing="normal" indent="9">
<t>Type: 31</t> <dt>Type:</dt><dd>31</dd>
<dt>Length:</dt><dd>5 or 6 depending on size of the SID</dd>
<t>Length: 5 or 6 depending on size of the SID</t> <dt>Flags:</dt><dd><t>1-octet field of the following flags:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2
<t>Flags: 1 octet field of following flags: <figure> 3 4 5 6 7
<artwork><![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>
</figure> where: <list style="hanging"> <dl newline="false" spacing="normal" indent="9">
<t>F-Flag: Address-Family flag. If unset, then the Adj-SID
is used when forwarding IPv4 encapsulated traffic to the
neighbor. If set then the Adj-SID is used when forwarding
IPv6 encapsulated traffic to the neighbor.</t>
<t>B-Flag: Backup flag. If set, the Adj-SID is eligible for <dt>F-Flag:</dt><dd>Address-Family Flag. If unset, then the Adj-
protection (e.g.: using IPFRR or MPLS-FRR) as described in SID
<xref target="RFC8402"/>.</t> is used when forwarding IPv4-encapsulated traffic to the
neighbor. If set, then the Adj-SID is used when forwarding
IPv6-encapsulated traffic to the neighbor.</dd>
<t>V-Flag: Value flag. If set, then the Adj-SID carries a <dt>B-Flag:</dt><dd>Backup Flag. If set, the Adj-SID is eligible
value. By default the flag is SET.</t> for
protection (e.g., using IP Fast Reroute (IPFRR) or MPLS Fast R
eroute (MPLS-FRR)) as described in
<xref target="RFC8402" format="default"/>.</dd>
<t>L-Flag: Local Flag. If set, then the value/index carried <dt>V-Flag:</dt><dd>Value Flag. If set, then the Adj-SID carries
by the Adj-SID has local significance. By default the flag a
is SET.</t> value. By default, the flag is SET.</dd>
<t>S-Flag. Set flag. When set, the S-Flag indicates that the <dt>L-Flag:</dt><dd>Local Flag. If set, then the value/index car
Adj-SID refers to a set of adjacencies (and therefore MAY be ried
assigned to other adjacencies as well).</t> by the Adj-SID has local significance. By default, the flag
is SET.</dd>
<t>P-Flag. Persistent flag. When set, the P-Flag indicates <dt>S-Flag:</dt><dd>Set Flag. When set, the S-Flag indicates tha
t the
Adj-SID refers to a set of adjacencies (and therefore <bcp14>M
AY</bcp14> be
assigned to other adjacencies as well).</dd>
<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.</t> and/or interface flap.</dd>
<t>Other bits: MUST be zero when originated and ignored when <dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero when origina
received.</t> ted and ignored when
</list></t> received.</dd>
</dl>
</dd>
</dl>
</li>
</ul>
<ul empty="true">
<li><dl newline="false" spacing="normal" indent="9">
<t>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"/>.</t> is defined in <xref target="RFC8402" format="default"/>.</dd>
</dl>
</li>
</ul>
<t>SID/Index/Label as defined in <xref <ul empty="true">
target="VANDLFLAGS"/>.</t> <li>SID/Index/Label as defined in <xref target="VANDLFLAGS" format="defa
ult"/>.</li>
<t>An SR capable router MAY allocate an Adj-SID for each of its <li>An SR-capable router <bcp14>MAY</bcp14> allocate an Adj-SID for
adjacencies</t> each of its
adjacencies.</li>
<t>An SR capable router MAY allocate more than one Adj-SID to an <li>An SR-capable router <bcp14>MAY</bcp14> allocate more than one A
adjacency.</t> dj-SID to an
adjacency.</li>
<t>An SR capable router MAY allocate the same Adj-SID to <li>An SR-capable router <bcp14>MAY</bcp14> allocate the same Adj-SI
different adjacencies.</t> D to
different adjacencies.</li>
<t>When the P-flag is not set, the Adj-SID MAY be persistent. <li>When the P-Flag is not set, the Adj-SID <bcp14>MAY</bcp14> be pe
When the P-flag is set, the Adj-SID MUST be persistent.</t> rsistent.
When the P-Flag is set, the Adj-SID <bcp14>MUST</bcp14> be persist
ent.</li>
<t>Examples of use of the Adj-SID sub-TLV are described in <xref <li>Examples of Adj-SID sub-TLV use are described in <xref target="R
target="RFC8402"/>.</t> FC8402" format="default"/>.</li>
<t>The F-flag is used in order for the router to advertise the <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.</t> to.</li>
</list></t> </ul>
</section> </section>
<section anchor="LANADJSIDSUBTLV" <section anchor="LANADJSIDSUBTLV" numbered="true" toc="default">
title="Adjacency Segment Identifiers in LANs"> <name>Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV</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 <bcp14>MAY</bc
<t>When Segment Routing is used, each router in the LAN MAY 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
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 Adjacency Segment Identif
<t>The following new sub-TLV is defined: LAN-Adj-SID containing the ier (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:<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor System-ID (ID length octets) | | Neighbor System-ID (ID length octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>where:</t>
<ul empty="true"><li>
<dl newline="false" spacing="normal" indent="9">
where: ]]></artwork> <dt>Type:</dt><dd>32</dd>
</figure><list style="hanging">
<t>Type: 32</t>
<t>Length: variable.</t> <dt>Length:</dt><dd>Variable</dd>
<t>Flags: 1 octet field of following flags: <figure> <dt>Flags:</dt><dd><t> 1-octet field of the following flags:</t>
<artwork><![CDATA[
0 1 2 3 4 5 6 7 <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-Flag, B-Flag, V-Flag, L-Flag, S-Flag, and P-Flag a
</figure> where F, B, V, L, S and P flags are defined in <xref re defined in <xref target="ADJSIDSUBTLV" format="default"/>. </t>
target="ADJSIDSUBTLV"/>. Other bits: MUST be zero when </dd>
originated and ignored when received.</t> </dl>
</li>
</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>
<t>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"/>.</t> is defined in <xref target="RFC8402" format="default"/>.</dd>
<t>Neighbor System-ID: IS-IS System-ID of length "ID Length" as
defined in <xref target="ISO10589"/>.</t>
<t>SID/Index/Label as defined in <xref
target="VANDLFLAGS"/>.</t>
</list></t>
<t>Multiple LAN-Adj-SID sub-TLVs MAY be encoded.</t> <dt>Neighbor System-ID:</dt><dd>IS-IS System-ID of length "ID Length
" as
defined in <xref target="ISO10589" format="default"/>.</dd>
<t>Note that this sub-TLV MUST NOT appear in TLV 141.</t> <dt>SID/Index/Label:</dt><dd>As defined in <xref target="VANDLFLAGS"
format="default"/>.</dd>
</dl>
</li>
</ul>
<t>In case one TLV-22/23/222/223 (reporting the adjacency to the <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
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" title="SID/Label Sub-TLV"> <section anchor="SIDLABELSUBTLV" numbered="true" toc="default">
<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>
<ul empty="true">
<li>SR-Capabilities sub-TLV (<xref target="SRCAPSUBTLV" format="default"
/>)</li>
<li>SR Local Block sub-TLV (<xref target="SRLBSUBTLV" format="default"/>
)</li>
<li>SID/Label Binding TLV (<xref target="BINDINGTLV" format="default"/>)
</li>
<li>Multi-Topology SID/Label Binding TLV (<xref target="MTBINDINGTLV" fo
rmat="default"/>)</li>
</ul>
<t>SR-Capabilities Sub-TLV (<xref target="SRCAPSUBTLV"/>)</t> <t>Note that the codepoint used in all of the above cases is the
SID/Label sub-TLV codepoint specified in the new "sub-TLVs for
<t>SR Local Block Sub-TLV (<xref target="SRLBSUBTLV"/>)</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>SID/Label Binding TLV (<xref target="BINDINGTLV"/>)</t> sub-TLV has the following format: </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t>Multi-Topology SID/Label Binding TLV (<xref
target="MTBINDINGTLV"/>)</t>
<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 &ldquo;sub-TLVs for
TLV 149 and 150&rdquo; registry created by this document.</t>
<t>The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label
sub-TLV has the following format: <figure>
<artwork><![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>
</figure><list>
<t>Type: 1</t>
<t>Length: 3 or 4</t> <dt>Length:</dt><dd>3 or 4</dd>
<t>SID/Label: if 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
represent a MPLS label. If length is set to 4 then the value is a t bits
32 bit index</t> represent an MPLS label. If the length is set to 4, then the value i
</list></t> s a
32-bit index.</dd>
</dl>
</li>
</ul>
</section> </section>
<section anchor="BINDINGTLV" title="SID/Label Binding TLV"> <section anchor="BINDINGTLV" numbered="true" toc="default">
<t>The SID/Label Binding TLV MAY be originated by any router in an <name>SID/Label Binding TLV</name>
<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 Mapping Server (SRMS). The behavior of the SRMS is defined in <xref targ
target="I-D.ietf-spring-segment-routing-ldp-interop"/>.</t> 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 to advertise the ability to process traffic originally destined to SID indicating the ability of a node to process traffic originally desti
another IGP node. This behavior is defined in <xref ned to
target="RFC8402"/>.</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" <artwork name="" type="" align="left" alt=""><![CDATA[
title="SID/Label Binding TLV format">
<artwork><![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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Prefix (continued, variable) // // Prefix (continued, variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) | | Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> <t>where:</t>
</figure> <ul empty="true"><li>
<dl newline="false" spacing="normal" indent="12">
<t><list style="symbols"> <dt>Type:</dt><dd>149</dd>
<t>Type: 149</t> <dt>Length:</dt><dd>Variable</dd>
<dt>Flags:</dt><dd>1 octet</dd>
<t>Length: variable.</t> <dt>RESERVED:</dt><dd>1 octet (<bcp14>SHOULD</bcp14> be transmitted as
0 and <bcp14>MUST</bcp14> be
<t>1 octet of flags</t> ignored on receipt)</dd>
<dt>Range:</dt><dd>2 octets</dd>
<t>1 octet of RESERVED (SHOULD be transmitted as 0 and MUST be <dt>Prefix Length:</dt><dd>1 octet</dd>
ignored on receipt)</t> <dt>Prefix:</dt><dd>0-16 octets</dd></dl>
<t>sub-TLVs, where each sub-TLV consists of a sequence of:</t>
<t>2 octets of Range</t> <ul spacing="normal">
<li>1 octet of sub-TLV type</li>
<t>1 octet of Prefix Length</t> <li>1 octet of length of the value field of the sub-TLV</li>
<li>0-243 octets of value</li>
<t>0-16 octets of Prefix</t> </ul>
</li>
<t>sub-TLVs, where each sub-TLV consists of a sequence of: <list </ul>
style="symbols">
<t>1 octet of sub-TLV type</t>
<t>1 octet of length of the value field of the sub-TLV</t>
<t>0-243 octets of value</t>
</list></t>
</list></t>
<section title="Flags"> <section numbered="true" toc="default">
<t>Flags: 1 octet field of following flags:<figure> <name>Flags</name>
<artwork><![CDATA[ <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 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|F|M|S|D|A| | |F|M|S|D|A| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> <t> where: </t>
</figure> where: <list style="hanging"> <ul empty="true"><li>
<t>F-Flag: Address Family flag. If unset, then the Prefix <dl newline="false" spacing="normal" indent="9">
carries an IPv4 Prefix. If set then the Prefix carries an IPv6
Prefix.</t>
<t>M-Flag: Mirror Context flag. Set if the advertised SID <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
prefix.</dd>
<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"/>.</t> is described in <xref target="RFC8402" format="default"/>.</dd>
<t>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<
across the entire routing domain. If the S flag is not set, the /bcp14> be flooded
SID/Label Binding TLV MUST NOT be leaked between levels. This across the entire routing domain. If the S-Flag is not set, the
bit MUST NOT be altered during the TLV leaking.</t> SID/Label Binding TLV <bcp14>MUST NOT</bcp14> be leaked between le
vels. This
bit <bcp14>MUST NOT</bcp14> be altered during the TLV leaking.</dd
>
<t>D-Flag: when the SID/Label Binding TLV is leaked from level-2 <dt>D-Flag:</dt><dd>When the SID/Label Binding TLV is leaked from Le
to level-1, the D-Flag MUST be set. Otherwise, this flag MUST be vel-2
clear. SID/Label Binding TLVs with the D-Flag set MUST NOT be to Level-1, the D-Flag <bcp14>MUST</bcp14> be set. Otherwise, this
leaked from level-1 to level-2. This is to prevent TLV looping flag <bcp14>MUST</bcp14> be
across levels.</t> 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
across levels.</dd>
<t>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
cleared.</t> > be
cleared.</dd>
</dl>
</li>
</ul>
<t>An implementation may decide not to honor the S-flag in order <ul empty="true">
not to leak Binding TLV's between levels (for policy <li>An implementation may decide not to honor the S-Flag in order
reasons).</t> to not leak Binding TLVs between levels (for policy
reasons).</li></ul>
<t>Other bits: MUST be zero when originated and ignored when <ul empty="true"><li>
received.</t> <dl>
</list></t> <dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero when originated
</section> and ignored when
received.</dd>
</dl>
</li>
</ul>
<section title="Range"> </section>
<section numbered="true" toc="default">
<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,
be mapped into a Prefix-SID. In either case the prefix is the first 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
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 title="Prefix Length, Prefix"> <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 16, 3 octets for prefix length 17 up to 24 and 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, ...., 16 octets for prefix length 113 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 title="Mapping Server Prefix-SID"> <name>Mapping Server Prefix-SID</name>
<t>The Prefix-SID sub-TLV is defined in <xref <t>The Prefix-SID sub-TLV is defined in <xref target="PREFIXSIDSUBTLV"
target="PREFIXSIDSUBTLV"/> and contains the SID/index/label value 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
present in the SID/Label Binding TLV when the M-flag is clear. The ST</bcp14> be
Prefix-SID Sub-TLV MUST NOT be present when the M-flag is set.</t> present in the SID/Label Binding TLV when the M-Flag is clear. The
Prefix-SID sub-TLV <bcp14>MUST NOT</bcp14> be present when the M-Flag
<section title="Prefix-SID Flags"> is set.</t>
<t>The Prefix-SID flags are defined in <xref <section numbered="true" toc="default">
target="PREFIXSIDSUBTLV"/>. The Mapping Server MAY advertise a <name>Prefix-SID Flags</name>
mapping with the N flag set when the prefix being mapped is known <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
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=
<t>The other flags defined in <xref target="PREFIXSIDSUBTLV"/> are "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" <name>PHP Behavior when Using Mapping Server Advertisements</name>
title=" PHP Behavior when using Mapping Server Advertisements <t>As the Mapping Server does not specify the originator of a
"> prefix advertisement, it is not possible to determine PHP behavior
<t>As the mapping server does not specify the originator of a
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:<list style="symbols"> done. The required information consists of:</t>
<t>A prefix reachability advertisement for the prefix has been <ul spacing="normal">
received which includes the Prefix Attribute Flags sub-TLV <li>A prefix reachability advertisement for the prefix has been
<xref target="RFC7794"/>.</t> received, which includes the Prefix Attribute Flags sub-TLV
<xref target="RFC7794" format="default"/>.</li>
<t>X and R flags are both set to 0 in the Prefix Attribute <li>X-Flag and R-Flag are both set to 0 in the Prefix Attribute
Flags sub-TLV.</t> Flags sub-TLV.</li>
</list></t> </ul>
<t>In the absence of a Prefix Attribute Flags sub-TLV <xref target="
<t>In the absence of an Prefix Attribute Flags sub-TLV <xref RFC7794" format="default"/>, the A-Flag in the Binding TLV indicates that
target="RFC7794"/> 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 and 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 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 title="Prefix-SID Algorithm"> <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 the Algorithm field is described in <xref target="PREFIXSIDSUBTLV" f
target="PREFIXSIDSUBTLV"/>.</t> ormat="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="BSIDSUBTLV" numbered="true" toc="default">
<section anchor="BSIDSUBTLV" title="SID/Label Sub-TLV"> <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"/>. It MUST be present in defined in <xref target="SIDLABELSUBTLV" format="default"/>. It <bcp14
the SID/Label Binding TLV when the M-flag is set in the Flags field >MUST</bcp14> be present in
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">
<name>Example Encodings</name>
<t>Example 1: If the following IPv4 router addresses (loopback
addresses) need to be mapped into the corresponding Prefix-SID
indexes, then: </t>
<section anchor="BSIDEXAMPLE" title="Example Encodings"> <ul empty="true">
<t>Example 1: if the following IPv4 router addresses (loopback <li>Router-A: 192.0.2.1/32, Prefix-SID: Index 1</li>
addresses) need to be mapped into the corresponding Prefix SID <li>Router-B: 192.0.2.2/32, Prefix-SID: Index 2</li>
indexes. <figure suppress-title="true"> <li>Router-C: 192.0.2.3/32, Prefix-SID: Index 3</li>
<artwork><![CDATA[ <li>Router-D: 192.0.2.4/32, Prefix-SID: Index 4</li>
Router-A: 192.0.2.1/32, Prefix-SID: Index 1 </ul>
Router-B: 192.0.2.2/32, Prefix-SID: Index 2
Router-C: 192.0.2.3/32, Prefix-SID: Index 3 <artwork name="" type="" align="left" alt=""><![CDATA[
Router-D: 192.0.2.4/32, Prefix-SID: Index 4
]]></artwork>
</figure> <figure suppress-title="true">
<artwork><![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
</figure></t> the corresponding Prefix-SID indexes, then: </t>
<t>Example-2: If the following IPv4 prefixes need to be mapped into <ul empty="true">
the corresponding Prefix-SID indexes: <figure suppress-title="true"> <li>10.1.1/24, Prefix-SID: Index 51</li>
<artwork><![CDATA[ <li>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 </ul>
10.1.7/24, Prefix-SID: Index 57
]]></artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
</figure> <figure suppress-title="true">
<artwork><![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
</figure></t> the corresponding Prefix-SID indexes, then: </t>
<t>Example-3: If the following IPv6 prefixes need to be mapped into <ul empty="true">
the corresponding Prefix-SID indexes: <figure suppress-title="true"> <li>2001:db8:1/48, Prefix-SID: Index 151</li>
<artwork><![CDATA[ <li>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 </ul>
2001:db8:4/48, Prefix-SID: Index 154
]]></artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
</figure> <figure suppress-title="true">
<artwork><![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>
</figure></t>
<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>
<ul empty="true"><li>
<dl newline="false" spacing="normal" indent="12">
<t>For example if a router wants to advertise the following ranges: <dt>Range 16:</dt><dd>{ 192.0.2.1-15, Index 1-15 }</dd>
<list style="hanging">
<t>Range 16: { 192.0.2.1-15, Index 1-15 }</t>
<t>Range 6: { 192.0.2.22-27, Index 22-27 }</t> <dt>Range 6:</dt><dd>{ 192.0.2.22-27, Index 22-27 }</dd>
<t>Range 41: { 192.0.2.44-84, Index 80-120 }</t> <dt>Range 41:</dt><dd>{ 192.0.2.44-84, Index 80-120 }</dd>
</list> A router would need to advertise three instances of the </dl>
</li>
</ul>
<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" <name>Multi-Topology SID/Label Binding TLV</name>
title="Multi-Topology SID/Label Binding TLV">
<t>The Multi-Topology SID/Label Binding TLV allows the support of <t>The Multi-Topology SID/Label Binding TLV allows the support of
M-ISIS as defined in <xref target="RFC5120"/>. 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"/> with the difference consisting defined in <xref target="BINDINGTLV" format="default"/> with the differe
of a Multitopology Identifier (MTID) as defined here below:</t> nce consisting
of a Multi-topology Identifier (MT ID) as defined here below:</t>
<figure anchor="MTBINDINGTLVFIG" <artwork name="" type="" align="left" alt=""><![CDATA[
title="Multi-Topology SID/Label Binding TLV format">
<artwork><![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> <t>where: </t>
</figure> <ul empty="true"><li>
<dl newline="false" spacing="normal" indent="9">
<t>where: <list style="hanging"> <dt>Type:</dt><dd>150</dd>
<t>Type: 150</t>
<t>Length: variable</t> <dt>Length:</dt><dd>Variable</dd>
</dl>
<t>MTID is the multitopology identifier defined as: <figure <t>MT ID is the Multi-topology Identifier defined as:</t>
anchor="MTIDFIG" suppress-title="true">
<artwork><![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>
</figure><list style="hanging"> <dl newline="false" spacing="normal" indent="9">
<t>RESVD: reserved bits. MUST be reset on transmission and
ignored on receive.</t>
<t>MTID: a 12-bit field containing the non-zero ID of the <dt>RESVD:</dt><dd>Reserved bits. <bcp14>MUST</bcp14> be reset on
topology being announced. The TLV MUST be ignored if the ID is transmission and
ignored on receive.</dd>
<dt>MT ID:</dt><dd>A 12-bit field containing the non-zero ID of th
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.</t> unicast topology.</dd>
</list></t>
<t>The other fields and Sub-TLVs are defined in <xref </dl>
target="BINDINGTLV"/>.</t> </li>
</list></t> </ul>
</section> </li>
</section> </ul>
<section title="Router Capabilities"> <ul empty="true"><li>
<t>This section defines sub-TLVs which are inserted into the IS-IS <t>The other fields and sub-TLVs are defined in <xref target="BINDINGT
Router Capability TLV-242 that is defined in <xref LV" format="default"/>.</t>
target="RFC7981"/>.</t> </li></ul>
<section anchor="SRCAPSUBTLV" title="SR-Capabilities Sub-TLV"> </section>
<t>Segment Routing requires each router to advertise its SR data-plane </section>
<section numbered="true" toc="default">
<name>Router Capabilities</name>
<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>
<section anchor="SRCAPSUBTLV" numbered="true" toc="default">
<name>SR-Capabilities Sub-TLV</name>
<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
boundaries. Therefore Router Capability TLV distribution flags are set throughout the level and <bcp14>MUST NOT</bcp14> be advertised across le
accordingly, i.e., the S flag in the Router Capability TLV <xref vel
target="RFC7981"/> MUST be unset.</t> boundaries. Therefore, Router Capability TLV distribution flags are set
accordingly, i.e., the S-Flag in the Router Capability TLV <xref target=
<t>The SR Capabilities sub-TLV has following format:<figure> "RFC7981" format="default"/> <bcp14>MUST</bcp14> be unset.</t>
<artwork><![CDATA[ 0 1 2 <t>The SR-Capabilities sub-TLV has the following format:</t>
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 | Flags | | Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range | | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID/Label Sub-TLV (variable) // // SID/Label Sub-TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure><list style="hanging"> <ul empty="true"><li>
<t>Type: 2</t> <dl newline="false" spacing="normal" indent="9">
<dt>Type:</dt><dd>2</dd>
<t>Length: variable.</t> <dt>Length:</dt><dd>Variable</dd>
<t>Flags: 1 octet of flags. The following are defined: <figure> <dt>Flags:</dt><dd><t>1 octet of flags. The following are defined: </t
<artwork><![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>
</figure>where: <list style="hanging">
<t>I-Flag: MPLS IPv4 flag. If set, then the router is capable
of processing SR MPLS encapsulated IPv4 packets on all
interfaces.</t>
<t>V-Flag: MPLS IPv6 flag. If set, then the router is capable </dd></dl>
of processing SR MPLS encapsulated IPv6 packets on all </li>
interfaces.</t> </ul>
</list></t> <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
interfaces.</dd>
<t>One or more SRGB Descriptor entries, each of which have the <dt>V-Flag:</dt><dd>MPLS IPv6 Flag. If set, then the router is cap
following format:<list style="hanging"> able
<t>Range: 3 octets.</t> of processing SR-MPLS-encapsulated IPv6 packets on all
interfaces.</dd>
</dl>
</li></ul></li></ul>
<t>SID/Label sub-TLV (as defined in <xref <ul empty="true"><li>
target="SIDLABELSUBTLV"/>).</t> <t>One or more Segment Routing Global Block (SRGB) Descriptor entrie
</list></t> s, each of which have the
</list></t> following format:</t>
<t>SID/Label sub-TLV contains the first value of the SRGB while the <ul empty="true"><li>
range contains the number of SRGB elements. The range value MUST be <dl newline="false" spacing="normal" indent="9">
higher than 0.</t> <dt>Range:</dt><dd>3 octets</dd>
<dt>SID/Label sub-TLV:</dt><dd>MPLS label as defined in <xref targ
et="SIDLABELSUBTLV" format="default"/></dd>
</dl>
</li>
</ul>
</li>
</ul>
<t>The SR-Capabilities sub-TLV MAY be advertised in an LSP of any <t>The SID/Label sub-TLV contains the first value of the SRGB while the
number but a router MUST NOT advertise more than one SR-Capabilities range contains the number of SRGB elements. The range value <bcp14>MUST<
/bcp14> be
higher than 0.</t>
<t>The SR-Capabilities 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 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 same originator <bcp14>SHOULD</bcp14> select the first advertisement in
numbered LSP.</t> the lowest-numbered
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
blackhole / misdirect some traffic during the IGP convergence. In black hole / misdirect some traffic during the IGP convergence. In
particular, if a range which 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 <bcp14>MUST</bcp14> ensure the order is unchan
<t>The originating router MUST ensure the order is unchanged after a 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 <bcp14>MUST NOT</bcp14> advertise overlapping
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>
<t>The originating router MUST NOT advertise overlapping ranges.</t> <t>Here follows an example of the advertisement of multiple ranges:</t>
<t>When a router receives multiple overlapping ranges, it MUST conform
to the procedures defined in <xref
target="I-D.ietf-spring-segment-routing-mpls"/>.</t>
<t>Here follows an example of advertisement of multiple ranges:<figure <ul empty="true" spacing="normal">
anchor="SRGBEXAMPLE" suppress-title="true"> <li>
<artwork><![CDATA[ <ul empty="true" spacing="normal">
The originating router advertises following ranges: <li>The originating router advertises the following ranges:</li>
SR-Cap: range: 100, SID value: 100 <li>SR-Cap: range: 100, SID value: 100 </li>
SR-Cap: range: 100, SID value: 1000 <li>SR-Cap: range: 100, SID value: 1000</li>
SR-Cap: range: 100, SID value: 500 <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>
index=0 means label 100 <artwork name="" type="" align="left" alt=""><![CDATA[
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>
</figure></t>
</section>
<section anchor="SRALGOSUBTLV" title="SR-Algorithm Sub-TLV"> </section>
<section anchor="SRALGOSUBTLV" numbered="true" toc="default">
<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 Shortest Path First (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="I-D.ietf-ospf-segment-routing-extensions"/>. defined in <xref target="RFC8665" format="default"/>.
The following values have been defined:<list> The following values have been defined:</t>
<t>0: Shortest Path First (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.</t> the SPF path with a different path based on local policy.</dd>
<dt>1:</dt><dd>Strict SPF algorithm based on link
<t>1: Strict Shortest Path First (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.</t> 1.</dd>
</list></t> </dl>
</li>
</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 <bcp14>MUST NOT</bcp14> be a
<t>The SR-Algorithm sub-TLV is optional. It MUST NOT be advertsied 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
advertisement in the lowest numbered LSP.</t> ect the first
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, this implies that the only algorithm supported by routers sub-TLV, it implies that algorithm 0 is the only algorithm supported by
supporting the extensions defined in this document is Algorithm 0.</t> the routers
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: <figure> <t>The SR-Algorithm sub-TLV has the following format: </t>
<artwork><![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>
</figure> where: <list style="hanging"> <ul empty="true"><li>
<t>Type: 19</t> <dl newline="false" spacing="normal" indent="12">
<t>Length: variable.</t> <dt>Type:</dt><dd>19</dd>
<t>Algorithm: 1 octet of algorithm</t> <dt>Length:</dt><dd>Variable</dd>
</list></t>
</section>
<section anchor="SRLBSUBTLV" title="SR Local Block Sub-TLV"> <dt>Algorithm:</dt><dd>1 octet of algorithm</dd>
<t>The SR Local Block (SRLB) Sub-TLV contains the range of labels the </dl></li></ul>
node has reserved for local SIDs. Local SIDs are used, e.g., for </section>
Adjacency-SIDs, and may also be allocated by components other than the <section anchor="SRLBSUBTLV" numbered="true" toc="default">
<name>SR Local Block Sub-TLV</name>
<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
Adj-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 are the local order for such applications or controllers to know what Local
SIDs available in the router, it is required that the router SIDs are available in the router, it is required that the router
advertises its SRLB.</t> advertises its SRLB.</t>
<t>The SRLB sub-TLV is used for this purpose and has following
<t>The SRLB Sub-TLV is used for this purpose and has following format:</t>
format:<figure> <artwork name="" type="" align="left" alt=""><![CDATA[ 0
<artwork><![CDATA[ 0 1 2 1 2 3
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | | Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range | | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID/Label Sub-TLV (variable) // // SID/Label Sub-TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure><list style="hanging"> <ul empty="true"><li>
<t>Type: 22</t> <dl newline="false" spacing="normal" indent="9">
<dt>Type:</dt><dd>22</dd>
<t>Length: variable.</t>
<t>Flags: 1 octet of flags. None are defined at this stage.</t> <dt>Length:</dt><dd>Variable</dd>
<dt>Flags:</dt><dd>1 octet of flags. None are defined at this stage.</
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:<list style="hanging"> following format:</t>
<t>Range: 3 octets.</t>
<t>SID/Label sub-TLV (as defined in <xref
target="SIDLABELSUBTLV"/>).</t>
</list></t>
</list></t>
<t>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
higher than 0.</t>
<t>The SRLB sub-TLV MAY be advertised in an LSP of any number but a
router MUST NOT advertise more than one SRLB sub-TLV. A router
receiving multiple SRLB sub-TLVs, from the same originator, SHOULD
select the first advertisement in the lowest numbered LSP.</t>
<t>The originating router MUST NOT advertise overlapping ranges.</t> <ul empty="true"><li>
<dl newline="false" spacing="normal" indent="9">
<t>When a router receives multiple overlapping ranges, it MUST conform <dt>Range:</dt><dd>3 octets</dd>
to the procedures defined in <xref
target="I-D.ietf-spring-segment-routing-mpls"/>.</t>
<dt>SID/Label sub-TLV:</dt><dd>MPLS label as defined in <xref targ
et="SIDLABELSUBTLV" format="default"/></dd>
</dl>
</li>
</ul>
</li>
</ul>
<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 <bcp14>MUST<
/bcp14> be
higher than 0.</t>
<t>The SRLB sub-TLV <bcp14>MAY</bcp14> be advertised in an LSP of any nu
mber, but a
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>
<t>The originating router <bcp14>MUST NOT</bcp14> advertise overlapping
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>
<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 in order 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 Adj-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 which are outside the scope of this document.</t>
<t>A router advertising the SRLB sub-TLV may also have other label <t>A router advertising the SRLB sub-TLV may also have other label
ranges, outside the SRLB, for its local allocation purposes which are ranges, outside the SRLB, for its local allocation purposes that are
NOT advertised in the SRLB. For example, it is possible that an NOT advertised in the SRLB. For example, it is possible that an
Adjacency-SID is allocated using a local label not part of the Adj-SID is allocated using a local label not part of the
SRLB.</t> SRLB.</t>
</section> </section>
<section anchor="SRMSPREFSUBTLV" numbered="true" toc="default">
<section anchor="SRMSPREFSUBTLV" title="SRMS Preference Sub-TLV"> <name>SRMS Preference Sub-TLV</name>
<t>The Segment Routing Mapping Server (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 following format:<figure> <artwork name="" type="" align="left" alt=""><![CDATA[ 0
<artwork><![CDATA[ 0 1 2 1 2 3
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Preference | | Type | Length | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure><list style="hanging"> <ul empty="true"><li>
<t>Type: 24</t> <dl newline="false" spacing="normal" indent="13">
<dt>Type:</dt><dd>24</dd>
<t>Length: 1.</t>
<t>Preference: 1 octet. Unsigned 8 bit SRMS preference.</t> <dt>Length:</dt><dd>1</dd>
</list></t>
<t>The SRMS Preference sub-TLV MAY be advertised in an LSP of any <dt>Preference:</dt><dd>1 octet and unsigned 8-bit SRMS preference.</d
number but a router MUST NOT advertise more than one SRMS Preference d>
</dl>
</li>
</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
lowest numbered LSP.</t> t in the
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 described in <xref target="RFC8661" format="default"/>.</t>
target="I-D.ietf-spring-segment-routing-ldp-interop"/></t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>Per this document, IANA has allocated the following TLVs and
sub-TLVs.</t>
<section numbered="true" toc="default">
<name>Sub-TLVs for Types 22, 23, 25, 141, 222, and 223</name>
<t>This document makes the following registrations in the "Sub-TLVs
for TLV 22, 23, 25, 141, 222, and 223" registry.</t>
<section anchor="IANA" title="IANA Considerations"> <table anchor="IANA_table_1" align="left">
<t>This document requests allocation for the following TLVs and <thead>
Sub-TLVs.</t> <tr>
<th align='center'>Type</th>
<section title="Sub TLVs for Type 22,23,25,141,222, and 223"> <th align='left'>Description</th>
<t>This document makes the following registrations in the "sub-TLVs <th align='center'>22</th>
for TLV 22, 23, 25, 141, 222 and 223" registry.</t> <th align='center'>23</th>
<th align='center'>25</th>
<t><figure> <th align='center'>141</th>
<artwork><![CDATA[Type Description 22 23 25 <th align='center'>222</th>
141 222 223 <th align='center'>223</th>
31 Adjacency Segment Identifier y y n y y y </tr>
32 LAN Adjacency Segment Identifier y y n y y y </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>
]]></artwork>
</figure></t>
</section> </section>
<section title="Sub TLVs for Type 135,235,236 and 237"> <section numbered="true" toc="default">
<t>This document makes the following registrations in the "sub-TLVs <name>Sub-TLVs for Types 135, 235, 236, and 237</name>
for TLV 135,235,236 and 237" registry.</t> <t>This document makes the following registrations in the "Sub-TLVs
for TLV 135, 235, 236, and 237" registry.</t>
<figure> <table anchor="IANA_table_2" align="left">
<artwork><![CDATA[Type Description 135 235 236 <thead>
237 <tr>
3 Prefix Segment Identifier y y y y <th align='center'>Type</th>
<th align='left'>Description</th>
<th align='center'>135</th>
<th align='center'>235</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>
]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Sub TLVs for Type 242"> <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>
<figure> <table anchor="IANA_table_3" align="left">
<artwork><![CDATA[Type Description <thead>
2 Segment Routing Capability <tr>
19 Segment Routing Algorithm <th align='center'>Type</th>
22 Segment Routing Local Block (SRLB) <th align='left'>Description</th>
24 Segment Routing Mapping Server Preference </tr>
(SRMS Preference) </thead>
<tbody>
]]></artwork> <tr>
</figure> <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>
<t/>
</section> </section>
<section numbered="true" toc="default">
<section title="New TLV Codepoint and Sub-TLV registry"> <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>
<t><figure> <table anchor="IANA_table_4" align="left">
<artwork><![CDATA[Value Name IIH LSP SN <thead>
P Purge <tr>
149 Segment Identifier/Label Binding n y n n <th align='center'>Value</th>
150 Multi-Topology Segment Identifier n y n n <th align='left'>Name</th>
/Label Binding <th align='center'>IIH</th>
<th align='center'>LSP</th>
]]></artwork> <th align='center'>SNP</th>
</figure></t> <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><figure> <dl>
<artwork><![CDATA[Name: sub-TLVs for TLVs 149 and 150 <dt>Name:</dt>
Registration Procedure: Expert Review <dd>Sub-TLVs for TLVs 149 and 150</dd>
<dt>Registration Procedure:</dt>
Type Description <dd>Expert Review <xref target="RFC8126" format="default"/></dd>
0 Reserved </dl>
1 SID/Label
2 Unassigned
3 Prefix SID
4-255 Unassigned
]]></artwork> <table anchor="IANA_table_5" align="left">
</figure></t> <thead>
<tr>
<th align='center'>Type</th>
<th align='center'>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">0</td>
<td align="left">Reserved</td>
</tr>
<tr>
<td align="center">1</td>
<td align="left">SID/Label</td>
</tr>
<tr>
<td align="center">2</td>
<td align="left">Unassigned</td>
</tr>
<tr>
<td align="center">3</td>
<td align="left">Prefix Segment Identifier</td>
</tr>
<tr>
<td align="center">4-255</td>
<td align="left">Unassigned</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<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 which will be used to program the MPLS data plane carries information that will be used to program the MPLS data plane
[RFC3031]. In general, the same types of attacks 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
<t>Existing security extensions as described in [RFC5304] and [RFC5310] mat="default"/>
apply to these segment routing extensions.</t> and <xref target="RFC5310" format="default"/> apply to these Segment Ro
uting extensions.</t>
</section> </section>
</middle>
<back>
<section anchor="Acknowledgements" title="Acknowledgements"> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3031.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5304.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5310.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5120.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7981.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7794.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.
xml"/>
<reference anchor="ISO10589">
<front>
<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
the protocol for providing the connectionless-mode network service
(ISO 8473)</title>
<seriesInfo name="ISO/IEC 10589:2002," value="Second Edition"/>
<author>
<organization abbrev="ISO">International Organization for Standard
ization</organization>
</author>
<date month="November" year="2002"/>
</front>
</reference>
<!--draft-ietf-ospf-segment-routing-extensions">; companion document RFC
8665 -->
<reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8
665">
<front>
<title>OSPF Extensions for Segment Routing</title>
<seriesInfo name="DOI" value="10.17487/RFC8665"/>
<seriesInfo name="RFC" value="8665"/>
<author initials="P" surname="Psenak" fullname="Peter Psenak" role="
editor">
<organization/>
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi" ro
le="editor">
<organization/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
>
<organization/>
</author>
<author initials="H" surname="Gredler" fullname="Hannes Gredler">
<organization/>
</author>
<author initials="R" surname="Shakir" fullname="Rob Shakir">
<organization/>
</author>
<author initials="W" surname="Henderickx" fullname="Wim Henderickx">
<organization/>
</author>
<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
<organization/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
<!--draft-ietf-spring-segment-routing-mpls">; companion document RFC 866
0-->
<reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8
660">
<front>
<title>Segment Routing with the MPLS Data Plane</title>
<seriesInfo name="DOI" value="10.17487/RFC8660"/>
<seriesInfo name="RFC" value="8660"/>
<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" ro
le="editor">
<organization/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
role="editor">
<organization/>
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization/>
</author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene">
<organization/>
</author>
<author initials="S" surname="Litkowski" fullname="Stephane Litkowsk
i">
<organization/>
</author>
<author initials="R" surname="Shakir" fullname="Rob Shakir">
<organization/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
<!--draft-ietf-spring-segment-routing-ldp-interop">; companion document
RFC 8661-->
<reference anchor="RFC8661" target="https://www.rfc-editor.org/info/rfc8
661">
<front>
<title>Segment Routing MPLS Interworking with LDP</title>
<seriesInfo name="DOI" value="10.17487/RFC8661"/>
<seriesInfo name="RFC" value="8661"/>
<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" ro
le="editor">
<organization/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
role="editor">
<organization/>
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization/>
</author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene">
<organization/>
</author>
<author initials="S" surname="Litkowski" fullname="Stephane Litkowsk
i">
<organization/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5305.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5308.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5311.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5316.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7855.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
xml"/>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<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" title="Contributors"> <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 co-authors:</t> of this document and should be considered as coauthors:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[Stephane Litkowski
<figure>
<artwork><![CDATA[Stephane Litkowski
Orange Orange
FR France
Email: stephane.litkowski@orange.com]]></artwork>
Email: stephane.litkowski@orange.com
<artwork name="" type="" align="left" alt=""><![CDATA[
Jeff Tantsura Jeff Tantsura
Apstra, Inc. Apstra, Inc.
Email: jefftant@gmail.com]]></artwork>
Email: jefftant@gmail.com <artwork name="" type="" align="left" alt=""><![CDATA[
Peter Psenak Peter Psenak
Cisco Systems Inc. Cisco Systems Inc.
US United States of America
Email: ppsenak@cisco.com]]></artwork>
Email: ppsenak@cisco.com
<artwork name="" type="" align="left" alt=""><![CDATA[
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
DE Germany
Email: Martin.Horneffer@telekom.de]]></artwork>
Email: Martin.Horneffer@telekom.de
<artwork name="" type="" align="left" alt=""><![CDATA[
Wim Henderickx Wim Henderickx
Nokia Nokia
BE Belgium
Email: wim.henderickx@nokia.com]]></artwork>
Email: wim.henderickx@nokia.com
<artwork name="" type="" align="left" alt=""><![CDATA[
Edward Crabbe Edward Crabbe
Oracle Oracle
US United States of America
Email: edward.crabbe@oracle.com]]></artwork>
Email: edward.crabbe@oracle.com
<artwork name="" type="" align="left" alt=""><![CDATA[
Rob Shakir Rob Shakir
Google Google
UK United Kingdom
Email: robjs@google.com]]></artwork>
Email: robjs@google.com
<artwork name="" type="" align="left" alt=""><![CDATA[
Igor Milojevic Igor Milojevic
Individual Individual
RS Serbia
Email: milojevicigor@gmail.com]]></artwork>
Email: milojevicigor@gmail.com
<artwork name="" type="" align="left" alt=""><![CDATA[
Saku Ytti Saku Ytti
TDC TDC
FI Finland
Email: saku@ytti.fi]]></artwork>
Email: saku@ytti.fi
Steven Luong
Cisco Systems Inc.
US
Email: sluong@cisco.com]]></artwork>
</figure>
</section> </section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.211
9.xml"?>
<reference anchor="ISO10589">
<front>
<title>Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode Network Service
(ISO 8473)</title>
<author>
<organization abbrev="ISO">International Organization for
Standardization</organization>
</author>
<date month="Nov" year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
</reference>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.303
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.530
4.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.531
0.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.512
0.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.798
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.779
4.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.817
4.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.840
2.xml"?>
<?rfc include="reference.I-D.ietf-ospf-segment-routing-extensions.xml"?>
<?rfc include="reference.I-D.ietf-spring-segment-routing-mpls.xml"?>
<?rfc include="reference.I-D.ietf-spring-segment-routing-ldp-interop.xml"?
>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.530
5.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.530
8.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.531
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.531
6.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.785
5.xml"?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 317 change blocks. 
1002 lines changed or deleted 1287 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/