One document matched: draft-previdi-isis-segment-routing-extensions-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-previdi-isis-segment-routing-extensions-04"
ipr="trust200902">
<front>
<title abbrev="IS-IS Extensions for Segment Routing">IS-IS Extensions for
Segment Routing</title>
<author fullname="Stefano Previdi" initials="S." role="editor"
surname="Previdi">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Via Del Serafico, 200</street>
<city>Rome</city>
<code>00142</code>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street/>
<city>Brussels</city>
<region/>
<code/>
<country>BE</country>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</author>
<author fullname="Ahmed Bashandy" initials="A." surname="Bashandy">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170, West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>bashandy@cisco.com</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<code>94089</code>
<region>CA</region>
<country>US</country>
</postal>
<email>hannes@juniper.net</email>
</address>
</author>
<author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
<organization>Orange</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country>FR</country>
</postal>
<email>stephane.litkowski@orange.com</email>
</address>
</author>
<date day="21" month="October" year="2013"/>
<area>Routing</area>
<workgroup>IS-IS for IP Internets</workgroup>
<keyword>MPLS</keyword>
<keyword>SID</keyword>
<keyword>IGP</keyword>
<keyword>IS-IS</keyword>
<keyword>Label advertisement</keyword>
<keyword>Segment Routing</keyword>
<abstract>
<t>Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are advertised
by the link-state routing protocols (IS-IS and OSPF).</t>
<t>This draft describes the necessary IS-IS extensions that need to be
introduced for Segment Routing.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are advertised
by the link-state routing protocols (IS-IS and OSPF). Two types of
segments are defined, Prefix segments and Adjacency segments. Prefix
segments represent an ecmp-aware shortest-path to a prefix, as per 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
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
and MPLS data-planes, and do not require any additional signaling (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 interoperate
in the presence of LSPs established with RSVP or LDP.</t>
<t>This draft describes the necessary IS-IS extensions that need to be
introduced for Segment Routing.</t>
<t>Segment Routing architecture is described in <xref
target="I-D.filsfils-rtgwg-segment-routing"/>.</t>
<t>Segment Routing use cases are described in <xref
target="I-D.filsfils-rtgwg-segment-routing-use-cases"/>.</t>
</section>
<section title="Segment Routing Identifiers">
<t>Segment Routing architecture (<xref
target="I-D.filsfils-rtgwg-segment-routing"/>) defines different types
of Segment Identifiers (SID). This document defines the IS-IS encodings
for the IGP-Prefix-SID, the IGP-Adjacency-SID, the IGP-LAN-Adjacency-SID
and the Binding-SID.</t>
<section anchor="SIDLABEL" title="SID/Label Sub-TLV">
<t>The SID/Label Sub-TLV is present in multiple Sub-TLVs defined in
this document and contains a SID or a MPLS Label. The SID/Label
Sub-TLV has the following format: <figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:</artwork>
</figure><list>
<t>Type: 1</t>
<t>Length: variable (3 or 4)</t>
<t>SID/Label: if length is set to 3 then the 20 rightmost bits
represent a MPLS label. If length is 4 then the value represents a
32 bits SID.</t>
</list></t>
</section>
<section anchor="PREFIXSIDSUBTLV"
title="Prefix Segment Identifier (Prefix-SID Sub-TLV)">
<t>A new IS-IS Sub-TLV is defined: the Prefix Segment Identifier
Sub-TLV (Prefix-SID Sub-TLV).</t>
<t>The Prefix-SID Sub-TLV carries the Segment Routing IGP-Prefix-SID
as defined in <xref target="I-D.filsfils-rtgwg-segment-routing"/>. The
'Prefix SID' must be unique within a given IGP domain. The 'Prefix
SID' is an index to determine the actual SID/label value inside the
set of all advertised SID/label ranges of a given router. A receiving
router uses the index to determine the actual SID/label value in order
to construct forwarding state to a particular destination router.</t>
<t>In many use-cases a 'stable transport' IP Address is overloaded as
an identifier of a given node. Because the IP Prefixes may be
re-advertised into other levels there may be some ambiguity (e.g.
Originating router vs. L1L2 router) for which node a particular IP
prefix serves as identifier. The Prefix-SID Sub-TLV contains the
necessary flags to dissambiguate IP Prefix to node mappings.
Furthermore if a given node has several 'stable transport' IP adresses
there are flags to differentiate those among other IP Prefixes
advertised from a given node.</t>
<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">
<t>TLV-135 (IPv4) defined in <xref target="RFC5305"/>.</t>
<t>TLV-235 (MT-IPv4) defined in <xref target="RFC5120"/>.</t>
<t>TLV-236 (IPv6) defined in <xref target="RFC5308"/>.</t>
<t>TLV-237 (MT-IPv6) defined in <xref target="RFC5120"/>.</t>
</list></t>
<t>The Index inside the Prefix-SID Sub-TLV MUST be preserved when an
IP Reachability TLV gets propagated across level boundaries.</t>
<t>The Prefix-SID Sub-TLV has the following format:<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:</artwork>
</figure><list style="hanging">
<t>Type: 3</t>
<t>Length: variable.</t>
<t>Flags: 1 octet field of following flags: <figure>
<artwork>
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R|N|P| |
+-+-+-+-+-+-+-+-+
</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. Optional and, if set, then the
Prefix-SID refers to the router identified by the prefix.
Typically, the N-Flag is set on Prefix-SIDs attached to a
router loopback address. The N-Flag is set when the Prefix-SID
is a Node-SID as described in <xref
target="I-D.filsfils-rtgwg-segment-routing"/>.</t>
<t>P-Flag: no-PHP flag. If set, then the penultimate hop MUST
NOT pop the Prefix-SID before delivering the packet to the
node that advertised the Prefix-SID.</t>
<t>Other bits: MUST be zero when originated and ignored when
received.</t>
</list></t>
<t>Algorithm: the router may use various algorithms when
calculating reachability to other nodes or to prefixes attached to
these nodes. Examples of these algorithms are metric based
Shortest Path First (SPF), various sorts of Constrained SPF, etc.
The Algorithm field allows a router to advertise algorithms that
router is currently using. SR-Algorithm TLV has following
structure: one octet identifying the algorithm to which the
Prefix-SID is associated. Currently, the following value has been
defined: <list style="hanging">
<t>0: Shortest Path First (SPF) algorithm based on link
metric.</t>
<t>Definitions and use of algorithms in Segment Routing are
described in <xref
target="I-D.filsfils-rtgwg-segment-routing"/></t>
</list></t>
<t>SID/Index: 32 bit index defining the offset in the SID/Label
space advertised by this router using the encodings defined in
<xref target="SR-CAP"/>.</t>
</list></t>
<t>Multiple Prefix-SIDs Sub-TLVs MAY appear on the same prefix in
which case each SID is encoded as a separate Sub-TLV. When multiple
Prefix-SID Sub-TLVs are present, the receiving router MUST use the
first encoded SID and MAY use the subsequent ones.</t>
<t>The No-PHP flag MUST be set on the Prefix-SIDs associated with
reachability advertisements which were originated by other routers and
leaked (either from Level-1 to Level-2 or vice versa).</t>
<t>The R-Flag MUST be set for prefixes that are not local to the
router and either:<list style="hanging">
<t>advertised because of propagation (Level-1 into Level-2);</t>
<t>advertised because of leaking (Level-2 into Level-1);</t>
<t>advertised because redistribution (e.g.: from another
protocol).</t>
</list></t>
<t>In the case where a Level-1-2 router has local interface addresses
configured in one level, it may also propagate these addresses into
the other level. In such case, the Level-1-2 router MUST NOT set the R
bit. The R-bit MUST be set only for prefixes that are not local to the
router and advertised by the router because of propagation and/or
leaking.</t>
<t>The N-Flag is used in order to define a Node-SID. A router MAY set
the N-Flag only if all of the following conditions are met:<list
style="hanging">
<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.: 'stable transport' loopback).</t>
<t>The prefix to which the Prefix-SID is attached MUST have a
Prefix length of either /32 (IPv4) or /128 (IPv6).</t>
</list></t>
<t>The router MUST ignore the N-Flag on a received Prefix-SID if the
prefix has a Prefix length different than /32 (IPv4) or /128
(IPv6).</t>
<t>The router behavior determined by the P, R and N flags are
described in <xref target="I-D.filsfils-rtgwg-segment-routing"/>.</t>
</section>
<section title="Adjacency Segment Identifier (Adj-SID) Sub-TLV">
<t>A new IS-IS Sub-TLV is defined: the Adjacency Segment Identifier
Sub-TLV (Adj-SID Sub-TLV).</t>
<t>The Adj-SID Sub-TLV is an optional Sub-TLV carrying the Segment
Routing IGP-Adjacency-SID as defined in <xref
target="I-D.filsfils-rtgwg-segment-routing"/> with flags and fields
that may be used, in future extensions of Segment Routing, for
carrying other types of SIDs.</t>
<t>IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs
below:<list style="hanging">
<t>TLV-22 <xref target="RFC5305"/></t>
<t>TLV-222 <xref target="RFC5120"/></t>
<t>TLV-23 <xref target="RFC5311"/></t>
<t>TLV-223 <xref target="RFC5311"/></t>
<t>TLV-141 <xref target="RFC5316"/></t>
</list></t>
<t>Multiple Adj-SID Sub-TLVs MAY be associated with a single
IS-neighbor. Examples where more than one Adj-SID may be used per
IS-neighbor are described in <xref
target="I-D.filsfils-rtgwg-segment-routing-use-cases"/>.</t>
<section anchor="ADJSIDSUBTLV"
title="Adjacency Segment Identifier (Adj-SID) Sub-TLV">
<t>The following format is defined for the Adj-SID Sub-TLV:<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label Sub-TLV (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:</artwork>
</figure><list style="hanging">
<t>Type: 31</t>
<t>Length: variable.</t>
<t>Flags: 1 octet field of following flags: <figure>
<artwork>
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+
|F|B| |
+-+-+-+-+-+-+-+
</artwork>
</figure> where: <list style="hanging">
<t>F-Flag: Address-Family flag. If unset, then the Adj-SID
refers to an adjacency with outgoing IPv4 encapsulation. If
set then the Adj-SID refers to an adjacency with outgoing
IPv6 encapsulation.</t>
<t>B-Flag: Backup flag. If set, the Adj-SID refers to an
adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as
described in <xref
target="I-D.filsfils-rtgwg-segment-routing-use-cases"/>.</t>
<!-- HG: can we say that it MAY be optional to encode the actual Backup path using a Binding TLV ?
The Binding TLV would have the same SID/Label value than the Adj-SID and it MUST only
contain a Backup-ERO list (no Primary ERO).
-->
<t>Other bits: MUST be zero when originated and ignored when
received.</t>
</list></t>
<t>Weight: 1 octet. The value represents the weight of the
Adj-SID for the purpose of load balancing. The use of the weight
is defined in <xref
target="I-D.filsfils-rtgwg-segment-routing"/>.</t>
<t>SID/Label Sub-TLV: contains the SID/Label value as defined in
<xref target="SIDLABEL"/>.</t>
<t>An SR capable router MAY allocate an Adj-SID for each of its
adjacencies and SHOULD set the B-Flag when the adjacency is
protected by a FRR mechanism (IP or MPLS) as described in <xref
target="I-D.filsfils-rtgwg-segment-routing-use-cases"/>.</t>
<t>The F-flag is used in order for the router to advertise the
outgoing encapsulation of the adjacency the Adj-SID is attached
to. Use cases of the use of the F-flag are described in <xref
target="I-D.filsfils-rtgwg-segment-routing-use-cases"/>.</t>
</list></t>
</section>
<section title="Adjacency Segment Identifiers in LANs">
<t>In LAN subnetworks, the Designated Intermediate System (DIS) is
elected and originates the Pseudonode-LSP (PN-LSP) including all
neighbors of the DIS.</t>
<t>When Segment Routing is used, each router in the LAN MAY
advertise the Adj-SID of each of its neighbors. Since, on LANs, each
router only advertises one adjacency to the DIS (and doesn't
advertise any other adjacency), each router advertises the set of
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.:
TLV-22).</t>
<t>The following new Sub-TLV is defined: LAN-Adj-SID (Type 32) containing the
set of Adj-SIDs the router assigned to each of its LAN
neighbors.</t>
<t>The format of the LAN-Adj-SID Sub-TLV is as follows:<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System-ID (6 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label Sub-TLV (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: </artwork>
</figure><list style="hanging">
<t>Type: 32</t>
<t>Length: variable.</t>
<t>Flags: 1 octet field of following flags: <figure>
<artwork>
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+
|F|B| |
+-+-+-+-+-+-+-+
</artwork>
</figure> where: <list style="hanging">
<t>F-Flag: Address Family flag. If unset, then the Adj-SID
refers to an adjacency with outgoing IPv4 encapsulation. If
set then the Adj-SID refers to an adjacency with outgoing
IPv6 encapsulation.</t>
<t>B-Flag: Backup flag. If set, the LAN-Adj-SID refers to an
adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as
described in <xref
target="I-D.filsfils-rtgwg-segment-routing-use-cases"/>.</t>
<t>Other bits: MUST be zero when originated and ignored when
received.</t>
</list></t>
<t>Weight: 1 octet. The value represents the weight of the
Adj-SID for the purpose of load balancing. The use of the weight
is defined in <xref
target="I-D.filsfils-rtgwg-segment-routing"/>.</t>
<t>System-ID: 6 octets of IS-IS System-ID of length "ID Length"
as defined in <xref target="ISO10589"/>.</t>
<t>SID/Label Sub-TLV: contains the SID/Label value as defined in
<xref target="SIDLABEL"/>.</t>
</list></t>
<t>Multiple LAN-Adj-SID Sub-TLVs MAY be encoded.</t>
<t>In case one TLV-22/23/222/223 (reporting the adjacency to the
DIS) can't contain the whole set of LAN-Adj-SID Sub-TLVs, multiple
advertisements of the adjacency to the DIS MUST be used, MUST have
the same metric and SHOULD be inserted within the same LSP
fragment.</t>
<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
reconstructing the LAN topology as well as the set of Adj-SID each
router uses for each of its neighbors.</t>
</section>
</section>
<section anchor="BINDING-TLV" title="SID/Label Binding TLV">
<t>The SID/Label Binding TLV MAY be originated by any router in an
IS-IS domain. The router may advertise a SID/Label binding to a FEC
along with at least a single 'nexthop style' anchor. The protocol
supports more than one 'nexthop style' anchor to be attached to a
SID/Label binding, which results into a simple path description
language. In analogy to RSVP the terminology for this is called an
'Explicit Route Object' (ERO). Since ERO style path notation allows to
anchor SID/label bindings to to both link and node IP addresses any
label switched path, can be described. Furthermore also SID/Label
Bindings from external protocols can get easily re-advertised.</t>
<t>The SID/Label Binding TLV may be used for advertising SID/Label
Bindings and their associated Primary and Backup paths. In one single
TLV either a primary ERO Path, a backup ERO Path or both are
advertised. If a router wants to advertise multiple parallel paths
then it can generate several TLVs for the same Prefix/FEC. Each
occurence of a Binding TLV with respect with a given FEC Prefix has
accumulating and not canceling semantics. Due the space constraints in
the 8-Bit IS-IS TLVs an originating router MAY encode a primary ERO
path in one SID/Label Binding TLV and the backup ERO path in a second
SID/Label Binding TLV. Note that the FEC Prefix and SID/Label Sub-TLV
MUST be identical in both TLVs.</t>
<t>The SID/Label Binding TLV has type TBA and has the following
format:</t>
<figure anchor="SID-MPLS-Binding-TLV-figure"
title="SID/Label Binding TLV format">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range | Prefix Length | FEC Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// FEC Prefix (continued, variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional subTLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="symbols">
<t>Type: 149</t>
<t>Length: variable.</t>
<t>1 octet of flags</t>
<t>1 octet of Prefix length</t>
<t>0-16 octets of FEC Prefix</t>
<t>2 octets of Range</t>
<t>sub-TLVs, where each sub-TLV consists of a sequence of: <list
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-255 octets of value</t>
</list></t>
</list></t>
<section title="Flags">
<t>Flags: 1 octet field of following flags:<figure>
<artwork>
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|M|X|S| |
+-+-+-+-+-+-+-+-+
</artwork>
</figure> where: <list style="hanging">
<t>F-Flag: Address Family flag. If unset, then the Prefix FEC
carries an IPv4 Prefix. If set then the Prefix FEC carries an
IPv6 Prefix.</t>
<t>M-Flag: Mirror Context flag. Set if the advertised SID/path
corresponds to a mirrored context.</t>
<t>X-Flag: Index flag. Set if the value of the SID/Label Sub-TLV
carries an index. Unset if the value of the SID/Label Sub-TLV
carries a local SID/Label.</t>
<t>S-Flag: subTLV present 'S' flag: Set if there are subTLVs
present.</t>
<t>Other bits: MUST be zero when originated and ignored when
received.</t>
</list></t>
</section>
<section title="Weight">
<t>Weight: 1 octet: The value represents the weight of the path for
the purpose of load balancing. The use of the weight is defined in
<xref target="I-D.filsfils-rtgwg-segment-routing"/>.</t>
</section>
<section title="Range">
<t>The 'Range' field provides the ability to specify a range of
addresses and their associated Prefix SIDs. It is essentially a
compression scheme to distribute a continuous Prefix and their
continuous, corresponding SID/Label Block. If a single SID is
advertised then the range field MUST be set to one. For range
advertisments > 1, the number of addresses that need to be mapped
into a Prefix-SID and the starting value of the Prefix-SID
range.</t>
<t>Example 1: if the following router addresses (loopback addresses)
need to be mapped into the corresponding Prefix SID indexes. <figure
suppress-title="true">
<artwork>
Router-A: 192.0.2.1/32, Prefix-SID: Index 1
Router-B: 192.0.2.2/32, Prefix-SID: Index 2
Router-C: 192.0.2.3/32, Prefix-SID: Index 3
Router-D: 192.0.2.4/32, Prefix-SID: Index 4
</artwork>
</figure> <figure suppress-title="true">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |0|0|1|1| | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 4 | /32 | 192 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .0 | .2 | .1 | Sub-TLV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Length| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t>Example-2: If the following prefixes need to be mapped into the
corresponding Prefix-SID indexes: <figure suppress-title="true">
<artwork>
10.1.1/24, Prefix-SID: Index 51
10.1.2/24, Prefix-SID: Index 52
10.1.3/24, Prefix-SID: Index 53
10.1.4/24, Prefix-SID: Index 54
10.1.5/24, Prefix-SID: Index 55
10.1.6/24, Prefix-SID: Index 56
10.1.7/24, Prefix-SID: Index 57
</artwork>
</figure> <figure suppress-title="true">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |0|0|1|1| | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 7 | /24 | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .1 | .1 | Sub-TLV Type | Sub-TLV Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 51 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t>It is not expected that a network operator will be able to keep
fully continuous FEC Prefix / SID/Index mappings. In order to
support noncontinuous mapping ranges an implementation MAY generate
several instances of Binding TLVs.</t>
<t>For example if a router wants to advertise the following ranges:
<list style="hanging">
<t>Range 16: { 192.168.1.1-15, Index 1-15 }</t>
<t>Range 6: { 192.168.1.22-27, Index 22-27 }</t>
<t>Range 41: { 192.168.1.44-84, Index 80-120 }</t>
</list> A router would need to advertise three instances of the
Binding TLV.</t>
</section>
<section title="Prefix Length, Prefix">
<t>The 'FEC Prefix' represents the Forwarding equivalence class at
the tail-end of the advertised path. The 'FEC Prefix' does not need
to correspond to a routable prefix of the originating node.</t>
<t>The 'Prefix Length' field contains the length of the prefix in
bits. Only the most significant octets of the Prefix FEC are
encoded. I.e. 1 octet for FEC prefix length 1 up to 8, 2 octets for
FEC prefix length 9 to 16, 3 octets for FEC prefix length 17 up to
24 and 4 octets for FEC prefix length 25 up to 32, ...., 16 octets
for FEC prefix length 113 up to 128.</t>
</section>
<section title="SID/Label Sub-TLV">
<t>The SID/Label Sub-TLV (Type 1) contains the SID/Label value as defined in
<xref target="SIDLABEL"/>. It MUST be present in every SID/Label
Binding TLV.</t>
</section>
<!-- begin ERO Metric subTLV -->
<section anchor="METRICTLV" title="ERO Metric sub-TLV">
<t>ERO Metric sub-TLV (Type 2) is a Sub-TLV of the SID/Label Binding TLV.</t>
<t>The ERO Metric sub-TLV carries the cost of an ERO path. It is
used to compare the cost of a given source/destination path. A
router SHOULD advertise the ERO Metric sub-TLV. The cost of the ERO
Metric sub-TLV SHOULD be set to the cumulative IGP or TE path cost
of the advertised ERO. Since manipulation of the Metric field may
attract or distract traffic from and to the advertised segment it
MAY be manually overridden. <figure
title="ERO Metric sub-TLV format">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure> where: <list style="hanging">
<t>Type: 2</t>
<t>Length: 4</t>
<t>Metric: 4 bytes</t>
</list></t>
</section>
<!-- end ERO metric subTLV -->
<section title="IPv4 ERO subTLV">
<t>The IPv4 ERO subTLV (Type 3) describes a path segment using
IPv4 address style of encoding. Its semantics have been borrowed
from <xref target="RFC3209"/>.</t>
<t>The 'L' bit in the Flags is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'</t>
<figure anchor="IPv4-ERO-subTLV-figure"
title="IPv4 ERO subTLV format">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved | IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<!-- end IPv4 ERO subtLV -->
<section title="IPv6 ERO subTLV">
<t>The IPv6 ERO subTLV (Type 4) describes a path segment using
IPv6 Address style of encoding. Its semantics have been borrowed
from <xref target="RFC3209"/>.</t>
<t>The 'L' bit in the Flags is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'</t>
<figure anchor="IPv6-ERO-subTLV-figure"
title="IPv6 ERO subTLV format">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved | IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<!-- end IPv6 ERO subtLV -->
<section title="Unnumbered Interface ID ERO subTLV">
<t>The appearance and semantics of the 'Unnumbered Interface ID'
have been borrowed from <xref target="RFC3477"> Section
4</xref>.</t>
<t>The Unnumbered Interface-ID ERO subTLV (Type 5) describes a
path segment that spans over an unnumbered interface. Unnumbered
interfaces are referenced using the interface index. Interface
indices are assigned local to the router and therefore not unique
within a domain. All elements in an ERO path need to be unique
within a domain and hence need to be disambiguated using a domain
unique Router-ID.</t>
<t>The 'Router-ID' field contains the router ID of the router which
has assigned the 'Interface ID' field. Its purpose is to
disambiguate the 'Interface ID' field from other routers in the
domain.</t>
<t>IS-IS supports two Router-ID formats:</t>
<t><list style="symbols">
<t><xref target="RFC5305">(TLV 134, 32-Bit format)</xref></t>
<t><xref target="RFC6119">(TLV 140, 128-Bit format)</xref></t>
</list></t>
<t>The actual Router-ID format gets derived from the 'Length'
field.</t>
<t><list style="symbols">
<t>For 32-Bit Router-ID width the subTLV length is set to 8
octets.</t>
<t>For 128-Bit Router-ID width the subTLV length is set to 20
octets.</t>
</list></t>
<t>The 'Interface ID' is the identifier assigned to the link by the
router specified by the router ID.</t>
<t>The 'L' bit in the Flags is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'</t>
<figure anchor="Unnumbered-Interface-ID-ERO-subTLV-figure"
title="Unnumbered Interface ID ERO subTLV format">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Router ID (32 or 128 bits) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<!-- end Unnumbered Interface ID ERO subtLV -->
<section title="IPv4 Backup ERO subTLV">
<t>The IPv4 Backup ERO subTLV (Type 6) describes a Backup path
segment using IPv4 Address style of encoding. Its appearance and
semantics have been borrowed from <xref target="RFC3209"/>.</t>
<t>The 'L' bit in the Flags is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'</t>
<figure anchor="IPv4-Backup-ERO-subTLV-figure"
title="IPv4 Backup ERO subTLV format">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved | IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<!-- end IPv4 Backup ERO subtLV -->
<section title="IPv6 Backup ERO subTLV">
<t>The IPv6 Backup ERO subTLV (Type 7) describes a Backup path
segment using IPv6 Address style of encoding. Its appearance and
semantics have been borrowed from <xref target="RFC3209"/>.</t>
<t>The 'L' bit in the Flags is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'</t>
<figure anchor="IPv6-Backup-ERO-subTLV-figure"
title="IPv6 Backup ERO subTLV format">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved | IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<!-- end IPv6 Backup ERO subtLV -->
<section title="Unnumbered Interface ID Backup ERO subTLV">
<t>The appearance and semantics of the 'Unnumbered Interface ID'
have been borrowed from <xref target="RFC3477"> Section
4</xref>.</t>
<t>The Unnumbered Interface-ID Backup ERO subTLV (Type 8)
describes a Backup LSP path segment that spans over an unnumbered
interface. Unnumbered interfaces are referenced using the interface
index. Interface indices are assigned local to the router and
therefore not unique within a domain. All elements in an ERO path
need to be unique within a domain and hence need to be disambiguated
using a domain unique Router-ID.</t>
<t>The 'Router-ID' field contains the router ID of the router which
has assigned the 'Interface ID' field. Its purpose is to
disambiguate the 'Interface ID' field from other routers in the
domain.</t>
<t>IS-IS supports two Router-ID formats:</t>
<t><list style="symbols">
<t><xref target="RFC5305">(TLV 134, 32-Bit format)</xref></t>
<t><xref target="RFC6119">(TLV 140, 128-Bit format)</xref></t>
</list></t>
<t>The actual Router-ID format gets derived from the 'Length'
field.</t>
<t><list style="symbols">
<t>For 32-Bit Router-ID width the subTLV length is set to 8
octets.</t>
<t>For 128-Bit Router-ID width the subTLV length is set to 20
octets.</t>
</list></t>
<t>The 'Interface ID' is the identifier assigned to the link by the
router specified by the router ID.</t>
<t>The 'L' bit in the Flags is a one-bit attribute. If the L bit is
set, then the value of the attribute is 'loose.' Otherwise, the
value of the attribute is 'strict.'</t>
<figure anchor="Unnumbered-Interface-ID-Backup-ERO-subTLV-figure"
title="Unnumbered Interface ID Backup ERO subTLV format">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Router ID (32 or 128 bits) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<!-- end Unnumbered Interface ID Backup ERO subtLV -->
<section title="Prefix ERO and Prefix Backup ERO subTLV path semantics">
<t>All 'ERO' and 'Backup ERO' information represents an ordered set
which describes the segments of a path. The last ERO subTLV
describes the segment closest to the egress point of the path.
Contrary the first ERO subTLV describes the first segment of a path.
If a router extends or stitches a label switched path it MUST
prepend the new segments path information to the ERO list. The same
ordering applies for the Backup ERO labels. An implementation SHOULD
first encode all primary path EROs followed by the bypass EROs.</t>
</section>
</section>
</section>
<section title="Router Capabilities">
<section anchor="SR-CAP" title="SR-Capabilities Sub-TLV">
<t>Segment Routing requires each router to advertise its SR data-plane
capability and the range of SID/Label values it uses for Segment
Routing. Data-plane capabilities and SID/Label ranges are advertised
using the newly defined SR-Capabilities Sub-TLV inserted into the
IS-IS Router Capability TLV-242 that is defined in <xref
target="RFC4971"/>.</t>
<t>The Router Capability TLV specifies flags that control its
advertisement. The SR Capabilities Sub-TLV MUST be propagated
throughout the level and need not to be advertised across level
boundaries. Therefore Router Capability TLV distribution flags MUST be
set accordingly, i.e.: the S flag MUST be unset.</t>
<t>The SR Capabilities Sub-TLV (Type 2) is optional, MAY appear multiple times
inside the Router Capability TLV and has following format: <figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range (cont.) | SID/Label Sub-TLV (variable size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure> where: <list style="hanging">
<t>Type: 2</t>
<t>Length: variable.</t>
<t>Flags: 1 octet of flags. The following are defined: <figure>
<artwork>
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|I|V| |
+-+-+-+-+-+-+-+-+
</artwork>
</figure>where: <list style="hanging">
<t>I-Flag: IPv4 flag. If set, then the router is capable of
outgoing IPv4 encapsulation on all interfaces.</t>
<t>V-Flag: IPv6 flag. If set, then the router is capable of
outgoing IPv6 encapsulation on all interfaces.</t>
</list></t>
<t>Range: 2 octets value defining the number of values of the
range from the starting value defined in the SID/Label
Sub-TLV.</t>
<t>SID/Label Sub-TLV: SID/Label value as defined in <xref
target="SIDLABEL"/>.</t>
</list></t>
<t>If multiple occurrence of the SR-Capabilities Sub-TLV are
advertised by the same router, only the Flags in the first occurrence
of the Sub-TLV are to be taken into account.</t>
</section>
<section anchor="SR-ALGO" title="SR-Algorithm Sub-TLV">
<t>The router may use various algorithms when calculating reachability
to other nodes or to prefixes attached to these nodes. Examples of
these algorithms are metric based Shortest Path First (SPF), various
sorts of Constrained SPF, etc. The SR-Algorithm Sub-TLV (Type 15) allows the
router to advertise the algorithms that the router is currently using.
The following value has been defined:<list>
<t>0: Shortest Path First (SPF) algorithm based on link
metric.</t>
</list>The SR-Algorithm Sub-TLV is inserted into the IS-IS Router
Capability TLV-242 that is defined in <xref target="RFC4971"/>.</t>
<t>The Router Capability TLV specifies flags that control its
advertisement. The SR-Algorithm MUST be propagated throughout the
level and need not to be advertised across level boundaries. Therefore
Router Capability TLV distribution flags MUST be set accordingly,
i.e.: the S flag MUST be unset.</t>
<t>The SR-Algorithm Sub-TLV is optional, it MAY only appear a single
time inside the Router Capability TLV. If the SID-Label Capability
Sub-TLV is advertised then the SR-Algorithm Sub-TLV MUST also be
advertised.</t>
<t>It has following format: <figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure> where: <list style="hanging">
<t>Type: 15</t>
<t>Length: variable.</t>
<t>Algorithm: 1 octet of algorithm <xref
target="PREFIXSIDSUBTLV"/></t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This documents request allocation for the following TLVs and subTLVs.
</t>
<?rfc needLines="18" ?>
<texttable anchor="iana_table" title="IANA allocations">
<ttcol align="center">PDU</ttcol>
<ttcol align="left">TLV</ttcol>
<ttcol align="left">subTLV</ttcol>
<ttcol align="left">Type</ttcol>
<ttcol align="left">subType</ttcol>
<ttcol align="right">#Occurence</ttcol>
<c>LSP</c>
<c>IS Neighbor</c>
<c></c>
<c>22, 23, 222, 223</c>
<c></c>
<c>>=0</c>
<c></c>
<c></c>
<c>SID/Label</c>
<c></c>
<c>31</c>
<c>>0</c>
<c></c>
<c></c>
<c>LAN SID/Label</c>
<c></c>
<c>32</c>
<c>>0</c>
<c>LSP</c>
<c>IP reachability</c>
<c></c>
<c>135, 235, 236, 237</c>
<c></c>
<c>>=0</c>
<c></c>
<c></c>
<c>SID/Label</c>
<c></c>
<c>3</c>
<c>>0</c>
<c>LSP</c>
<c>SID/MPLS Binding</c>
<c></c>
<c>149</c>
<c></c>
<c>>=0</c>
<c></c>
<c></c>
<c>SID/Label</c>
<c></c>
<c>1</c>
<c>>0</c>
<c></c>
<c></c>
<c>ERO Metric</c>
<c></c>
<c>2</c>
<c>1</c>
<c></c>
<c></c>
<c>IPv4 ERO</c>
<c></c>
<c>3</c>
<c>>=0</c>
<c></c>
<c></c>
<c>IPv6 ERO</c>
<c></c>
<c>4</c>
<c>>=0</c>
<c></c>
<c></c>
<c>Unnumbered Interface ID ERO</c>
<c></c>
<c>5</c>
<c>>=0</c>
<c></c>
<c></c>
<c>IPv4 Backup ERO</c>
<c></c>
<c>6</c>
<c>>=0</c>
<c></c>
<c></c>
<c>IPv6 Backup ERO</c>
<c></c>
<c>7</c>
<c>>=0</c>
<c></c>
<c></c>
<c>Unnumbered Interface ID Backup ERO</c>
<c></c>
<c>8</c>
<c>>=0</c>
<c>LSP</c>
<c>Router Capability</c>
<c></c>
<c>242</c>
<c></c>
<c>>=0</c>
<c></c>
<c></c>
<c>SR Capability</c>
<c></c>
<c>2</c>
<c>>=0</c>
<c></c>
<c></c>
<c>SR Algorithm</c>
<c></c>
<c>15</c>
<c>1</c>
</texttable>
<t>
The SID/MPLS Binding TLV requires a new sub-registry.
Type value 149 has been assigned, with a starting sub-TLV
value of 1, range from 1-255, and managed by Expert Review.
</t>
</section>
<section anchor="Manageability" title="Manageability Considerations">
<t>TBD</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
<section anchor="Contributors" title="Contributors">
<t>The following people gave a substantial contribution to the content
of this document: Martin Horneffer, Bruno Decraene, Igor Milojevic, Rob
Shakir, Saku Ytti and Wim Henderickx.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>We would like to thank Les Ginsberg, Dave Ward, Dan Frost, Stewart
Bryant and Pierre Francois for their contribution to the content of this
document.</t>
<t>Many thanks to Yakov Rekhter and Ina Minei for their contribution on
earlier incarnations of the "Binding / MPLS Label TLV" in <xref
target="I-D.gredler-isis-label-advertisement"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.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>
<!-- HG -->
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3477.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6119.xml"?>
<!-- HG -->
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5120.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5308.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4971.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5311.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5316.xml"?>
<?rfc ?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-filsfils-rtgwg-segment-routing-00.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-filsfils-rtgwg-segment-routing-use-cases-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gredler-isis-label-advertisement-03.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:34:01 |