IS-IS for IP Internets S. Previdi, Ed.
Internet-Draft Huawei
Intended status: Standards Track L. Ginsberg, Ed.
Expires: September 30, 2019 C. Filsfils
Cisco Systems, Inc.
A. Bashandy
Individual
H. Gredler
RtBrick Inc.
B. Decraene
Orange
March 29, 2019
IS-IS Extensions for Segment Routingdraft-ietf-isis-segment-routing-extensions-23
Abstract
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).
This draft describes the necessary IS-IS extensions that need to be
introduced for Segment Routing operating on an MPLS data-plane.
Requirements Language
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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Previdi, et al. Expires September 30, 2019 [Page 1]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
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).
N-Flag: Node-SID flag. 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
[RFC8402].
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.
E-Flag: Explicit-Null Flag. If set, any upstream neighbor of
the Prefix-SID originator MUST replace the Prefix-SID with a
Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for
IPv6) before forwarding the packet.
V-Flag: Value flag. If set, then the Prefix-SID carries a
value (instead of an index). By default the flag is UNSET.
L-Flag: Local Flag. If set, then the value/index carried by
the Prefix-SID has local significance. By default the flag is
UNSET.
Other bits: MUST be zero when originated and ignored when
received.
Algorithm: the router may use various algorithms when calculating
reachability to other nodes or to prefixes attached to these
nodes. Algorithms identifiers are defined in Section 3.2.
Examples of these algorithms are metric based Shortest Path First
(SPF), various sorts of Constrained SPF, etc. The algorithm field
of the Prefix-SID contains the identifier of the algorithm the
router uses to compute the reachability of the prefix to which the
Prefix-SID is associated.
At origination, the Prefix-SID algorithm field MUST be set to 0 or
to any value advertised in the SR-Algorithm sub-TLV (Section 3.2).
A router receiving a Prefix-SID from a remote node and with an
algorithm value that such remote node has not advertised in the
SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub-
TLV.
Previdi, et al. Expires September 30, 2019 [Page 5]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
SID/Index/Label as defined in Section 2.1.1.1.
When the Prefix SID is an index (the V-flag is not set) the value is
used to determine the actual label value inside the set of all
advertised label ranges of a given router. This allows a receiving
router to construct forwarding state to a particular destination
router.
In many use-cases a 'stable transport' address is overloaded as an
identifier of a given node. Because Prefixes may be re-advertised
into other levels there may be some ambiguity (e.g. Originating
router vs. L1L2 router) for which node a particular IP prefix serves
as identifier. The Prefix-SID sub-TLV contains the necessary flags
to disambiguate Prefix to node mappings. Furthermore if a given node
has several 'stable transport' addresses there are flags to
differentiate those among other Prefixes advertised from a given
node.
2.1.1. Flags2.1.1.1. V and L Flags
The V-flag indicates whether the SID/Index/Label field is a value or
an index.
The L-Flag indicates whether the value/index in the SID/Index/Label
field has local or global significance.
The following settings for V and L flags are valid:
V-flag is set to 0 and L-flag is set to 0: 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 Section 3.1.
V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label field
is a 3 octet local label where the 20 rightmost bits are used for
encoding the label value.
All other combinations of V-flag and L-flag are invalid and any SID
advertisement received with an invalid setting for V and L flags MUST
be ignored.
2.1.1.2. R and N Flags
The R-Flag MUST be set for prefixes that are not local to the router
and either:
advertised because of propagation (Level-1 into Level-2);
Previdi, et al. Expires September 30, 2019 [Page 6]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
advertised because of leaking (Level-2 into Level-1);
advertised because of redistribution (e.g.: from another
protocol).
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 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:
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).
The prefix to which the Prefix-SID is attached has a Prefix length
of either /32 (IPv4) or /128 (IPv6).
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).
The Prefix Attributes Flags sub-TLV [RFC7794] also defines the N and
R flags and with the same semantics of the equivalent flags defined
in this document. Whenever the Prefix Attributes 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 the values in a corresponding Prefix
SID sub-TLV (if present) MUST be ignored.
2.1.1.3. E and P Flags
The following behavior is associated with the settings of the E and P
flags:
o If the P-flag is not set then any upstream neighbor of the Prefix-
SID originator MUST pop the Prefix-SID. This is equivalent to the
penultimate hop popping mechanism used in the MPLS dataplane which
improves performance of the ultimate 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 unset the received E-flag is
ignored.
o If the P-flag is set then:
* If the E-flag is not set then any upstream neighbor of the
Prefix-SID originator MUST keep the Prefix-SID on top of the
stack. This is useful when, e.g., the originator of the
Previdi, et al. Expires September 30, 2019 [Page 7]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
Prefix-SID must stitch the incoming packet into a continuing
MPLS LSP to the final destination. This could occur at an
inter-area border router (prefix propagation from one area to
another) or at an inter-domain border router (prefix
propagation from one domain to another).
* If the E-flag is set then any upstream neighbor of the Prefix-
SID originator MUST replace the PrefixSID with a Prefix-SID
having an Explicit-NULL value. This is useful, e.g., when the
originator of the Prefix-SID is the final destination for the
related prefix and the originator wishes to receive the packet
with the original EXP bits.
When propagating (either from Level-1 to Level-2 or vice versa) a
reachability advertisement originated by another IS-IS speaker, the
router MUST set the P-flag and MUST clear the E-flag of the related
Prefix-SIDs.
2.1.2. Prefix-SID Propagation
The Prefix-SID sub-TLV MUST be included when the associated Prefix
Reachability TLV is propagated across level boundaries.
The level-1-2 router that propagates the Prefix-SID sub-TLV between
levels maintains the content (flags and SID) except as noted in
Section 2.1.1.2 and Section 2.1.1.3.
2.2. Adjacency Segment Identifier
A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub-
TLV (Adj-SID sub-TLV).
The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment
Routing IGP-Adjacency-SID as defined in [RFC8402] with flags and
fields that may be used, in future extensions of Segment Routing, for
carrying other types of SIDs.
IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs
below:
TLV-22 (Extended IS reachability)[RFC5305]
TLV-222 (Multitopology IS)[RFC5120]
TLV-23 (IS Neighbor Attribute)[RFC5311]
TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311]
Previdi, et al. Expires September 30, 2019 [Page 8]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
S-Flag. Set flag. When set, the S-Flag indicates that the
Adj-SID refers to a set of adjacencies (and therefore MAY be
assigned to other adjacencies as well).
P-Flag. Persistent flag. When set, the P-Flag indicates that
the Adj-SID is persistently allocated, i.e., the Adj-SID value
remains consistent across router restart and/or interface flap.
Other bits: MUST be zero when originated and ignored when
received.
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 [RFC8402].
SID/Index/Label as defined in Section 2.1.1.1.
An SR capable router MAY allocate an Adj-SID for each of its
adjacencies
An SR capable router MAY allocate more than one Adj-SID to an
adjacency.
An SR capable router MAY allocate the same Adj-SID to different
adjacencies.
When the P-flag is not set, the Adj-SID MAY be persistent. When
the P-flag is set, the Adj-SID MUST be persistent.
Examples of use of the Adj-SID sub-TLV are described in [RFC8402].
The F-flag is used in order for the router to advertise the
outgoing encapsulation of the adjacency the Adj-SID is attached
to.
2.2.2. Adjacency Segment Identifiers in LANs
In LAN subnetworks, the Designated Intermediate System (DIS) is
elected and originates the Pseudonode-LSP (PN-LSP) including all
neighbors of the DIS.
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).
Previdi, et al. Expires September 30, 2019 [Page 10]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
Note that this sub-TLV MUST NOT appear in TLV 141.
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 and all
advertisements MUST have the same metric.
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.
2.3. SID/Label Sub-TLV
The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs
defined in this document:
SR-Capabilities Sub-TLV (Section 3.1)
SR Local Block Sub-TLV (Section 3.3)
SID/Label Binding TLV (Section 2.4)
Multi-Topology SID/Label Binding TLV (Section 2.5)
Note that the code point used in all of the above cases is the SID/
Label Sub-TLV code point specified in the new "sub-TLVs for TLV 149
and 150" registry created by this document.
The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label
sub-TLV has the following format:
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:
Type: 1
Length: 3 or 4
Previdi, et al. Expires September 30, 2019 [Page 12]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
o sub-TLVs, where each sub-TLV consists of a sequence of:
* 1 octet of sub-TLV type
* 1 octet of length of the value field of the sub-TLV
* 0-243 octets of value
2.4.1. Flags
Flags: 1 octet field of following flags:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|M|S|D|A| |
+-+-+-+-+-+-+-+-+
where:
F-Flag: Address Family flag. If unset, then the Prefix carries an
IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix.
M-Flag: Mirror Context flag. Set if the advertised SID
corresponds to a mirrored context. The use of a mirrored context
is described in [RFC8402].
S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across
the entire routing domain. If the S flag is not set, the SID/
Label Binding TLV MUST NOT be leaked between levels. This bit
MUST NOT be altered during the TLV leaking.
D-Flag: when the SID/Label Binding TLV is leaked from level-2 to
level-1, the D-Flag MUST be set. Otherwise, this flag MUST be
clear. SID/Label Binding TLVs with the D-Flag set MUST NOT be
leaked from level-1 to level-2. This is to prevent TLV looping
across levels.
A-Flag: Attached flag. The originator of the SID/Label Binding
TLV MAY set the A bit in order to signal that the prefixes and
SIDs advertised in the SID/Label Binding TLV are directly
connected to their originators. The mechanisms through 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 document (e.g.:
through explicit configuration). If the Binding TLV is leaked to
other areas/levels the A-flag MUST be cleared.
An implementation may decide not to honor the S-flag in order not
to leak Binding TLV's between levels (for policy reasons).
Previdi, et al. Expires September 30, 2019 [Page 14]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
Other bits: MUST be zero when originated and ignored when
received.
2.4.2. Range
The 'Range' field provides the ability to specify a range of
addresses and their associated Prefix SIDs. This advertisement
supports the SRMS functionality. 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 advertisements > 1,
the range field MUST 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.
2.4.3. Prefix Length, Prefix
The 'Prefix' represents the Forwarding equivalence class at the tail-
end of the advertised path. The 'Prefix' does not need to correspond
to a routable prefix of the originating node.
The 'Prefix Length' field contains the length of the prefix in 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 length 9 to
16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix
length 25 up to 32, ...., 16 octets for prefix length 113 up to 128).
2.4.4. Mapping Server Prefix-SID
The Prefix-SID sub-TLV is defined in Section 2.1 and contains the
SID/index/label value associated with the prefix and range. The
Prefix-SID Sub-TLV MUST be present in the SID/Label Binding TLV when
the M-flag is clear. The Prefix-SID Sub-TLV MUST NOT be present when
the M-flag is set.
2.4.4.1. Prefix-SID Flags
The Prefix-SID flags are defined in Section 2.1. The Mapping Server
MAY 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 (IPv6) and when the prefix represents a node. The
mechanisms through which the operator defines that a prefix
represents a node are outside the scope of this document (typically
it will be through configuration).
The other flags defined in Section 2.1 are not used by the Mapping
Server and MUST be ignored at reception.
Previdi, et al. Expires September 30, 2019 [Page 15]

Internet-Draft IS-IS Extensions for Segment Routing March 20192.4.4.2. PHP Behavior when using Mapping Server Advertisements
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 additional
information is available PHP behavior may safely be done. The
required information consists of:
o A prefix reachability advertisement for the prefix has been
received which includes the Prefix Attribute Flags sub-TLV
[RFC7794].
o X and R flags are both set to 0 in the Prefix Attribute Flags sub-
TLV.
In the absence of an Prefix Attribute Flags sub-TLV [RFC7794] the A
flag in the binding TLV indicates that the originator of a prefix
reachability advertisement is directly connected to the prefix and
thus PHP MUST be done by the neighbors of the router originating the
prefix reachability advertisement. Note that A-flag is only valid in
the original area in which the Binding TLV is advertised.
2.4.4.3. Prefix-SID Algorithm
The algorithm field contains the identifier of the algorithm
associated with the SIDs for the prefix(es) in the range. Use of the
algorithm field is described in Section 2.1.
2.4.5. SID/Label Sub-TLV
The SID/Label sub-TLV (Type: 1) contains the SID/Label value as
defined in Section 2.3. It MUST be present in the SID/Label Binding
TLV when the M-flag is set in the Flags field of the parent TLV.
2.4.6. Example Encodings
Example 1: if the following IPv4 router addresses (loopback
addresses) need to be mapped into the corresponding Prefix SID
indexes.
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
Previdi, et al. Expires September 30, 2019 [Page 16]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
SID/Label sub-TLV (as defined in Section 2.3).
SID/Label sub-TLV contains the first value of the SRGB while the
range contains the number of SRGB elements. The range value MUST be
higher than 0.
The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number
but a router MUST NOT advertise more than one SR-Capabilities sub-
TLV. A router receiving multiple SR-Capabilities sub-TLVs from the
same originator SHOULD select the first advertisement in the lowest
numbered LSP.
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 reason changing the order in which the descriptors are
advertised will have a disruptive effect on forwarding.
When a router adds a new SRGB Descriptor to an existing SR-
Capabilities sub-TLV the new Descriptor SHOULD add the newly
configured block at the end of the sub-TLV and SHOULD NOT change the
order of previously advertised blocks. Changing the order of the
advertised descriptors will create label churn in the FIB and
blackhole / misdirect some traffic during the IGP convergence. In
particular, if a range which is not the last is extended it's
preferable to add a new range rather than extending the previously
advertised range.
The originating router MUST ensure the order is unchanged after a
graceful restart (using checkpointing, non-volatile storage or any
other mechanism).
The originating router MUST NOT advertise overlapping ranges.
When a router receives multiple overlapping ranges, it MUST conform
to the procedures defined in [I-D.ietf-spring-segment-routing-mpls].
Here follows an example of advertisement of multiple ranges:
Previdi, et al. Expires September 30, 2019 [Page 21]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
The originating router advertises following ranges:
SR-Cap: range: 100, SID value: 100
SR-Cap: range: 100, SID value: 1000
SR-Cap: range: 100, SID value: 500
The receiving routers concatenate the ranges in the received
order and build the SRGB as follows:
SRGB = [100, 199]
[1000, 1099]
[500, 599]
The indexes span multiple ranges:
index=0 means label 100
...
index 99 means label 199
index 100 means label 1000
index 199 means label 1099
...
index 200 means label 500
...
3.2. SR-Algorithm Sub-TLV
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 allows the
router to advertise the algorithms that the router is currently
using. Algorithm values are defined in the "IGP Algorithm Type"
registry defined in [I-D.ietf-ospf-segment-routing-extensions]. The
following values have been defined:
0: Shortest Path First (SPF) algorithm based on link metric. This
is the well-known shortest path algorithm as computed by the IS-IS
Decision process. Consistent with the deployed practice for link-
state protocols, algorithm 0 permits any node to overwrite the SPF
path with a different path based on local policy.
1: Strict Shortest Path First (SPF) algorithm based on link
metric. The algorithm is identical to algorithm 0 but algorithm 1
requires that all nodes along the path will honor the SPF routing
decision. Local policy MUST NOT alter the forwarding decision
computed by algorithm 1 at the node claiming to support algorithm
1.
Previdi, et al. Expires September 30, 2019 [Page 22]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
The Router Capability TLV specifies flags that control its
advertisement. The SR-Algorithm MUST be propagated throughout the
level and MUST NOT be advertised across level boundaries. Therefore
Router Capability TLV distribution flags are set accordingly, i.e.,
the S flag MUST be unset.
The SR-Algorithm sub-TLV is optional. It MUST NOT be advertsied more
than once at a given level. A router receiving multiple SR-Algorithm
sub-TLVs from the same originator SHOULD select the first
advertisement in the lowest numbered LSP.
When the originating router does not advertise the SR-Algorithm sub-
TLV, this implies that the only algorithm supported by routers
supporting the extensions defined in this document is Algorithm 0.
When the originating router does advertise the SR-Algorithm sub-TLV,
then algorithm 0 MUST be present while non-zero algorithms MAY be
present.
The SR-Algorithm sub-TLV has the following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: 19
Length: variable.
Algorithm: 1 octet of algorithm
3.3. SR Local Block Sub-TLV
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
Adjacency-SIDs, and may also be allocated by other components than
the IS-IS protocol. As an example, an application or a controller
may instruct the router to allocate a specific local SID. Therefore,
in order for such applications or controllers to know what are the
local SIDs available in the router, it is required that the router
advertises its SRLB.
Previdi, et al. Expires September 30, 2019 [Page 23]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
The SRLB Sub-TLV is used for that purpose and has following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID/Label Sub-TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 22
Length: variable.
Flags: 1 octet of flags. None are defined at this stage.
One or more SRLB Descriptor entries, each of which have the
following format:
Range: 3 octets.
SID/Label sub-TLV (as defined in Section 2.3).
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.
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.
The originating router MUST NOT advertise overlapping ranges.
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.:
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
collision between allocation instructions.
Within the context of IS-IS, the reporting of local SIDs is done
through IS-IS Sub-TLVs such as the Adjacency-SID. However, the
reporting of allocated local SIDs may also be done through other
Previdi, et al. Expires September 30, 2019 [Page 24]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
means and protocols which mechanisms are outside the scope of this
document.
A router advertising the SRLB TLV may also have other label ranges,
outside the SRLB, for its local allocation purposes which are NOT
advertised in the SRLB. For example, it is possible that an
Adjacency-SID is allocated using a local label not part of the SRLB.
3.4. SRMS Preference Sub-TLV
The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used
in order to associate a preference with SRMS advertisements from a
particular source.
The SRMS Preference sub-TLV has following format:
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 | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 24
Length: 1.
Preference: 1 octet. Unsigned 8 bit SRMS preference.
The SRMS Preference sub-TLV MAY be advertised in an LSP of any number
but a router MUST NOT advertise more than one SRMS Preference sub-
TLV. A router receiving multiple SRMS Preference sub-TLVs, from the
same originator, SHOULD select the first advertisement in the lowest
numbered LSP.
The use of the SRMS Preference during the SID selection process is
described in [I-D.ietf-spring-segment-routing-ldp-interop]
4. IANA Considerations
This documents request allocation for the following TLVs and Sub-
TLVs.
4.1. Sub TLVs for Type 22,23,25,141,222, and 223
This document makes the following registrations in the "sub-TLVs for
TLV 22, 23, 25, 141, 222 and 223" registry.
Previdi, et al. Expires September 30, 2019 [Page 25]

Internet-Draft IS-IS Extensions for Segment Routing March 2019
Type: 3
Description: Prefix-SID
Reference: This document (Section 2.1)
5. Security Considerations
With the use of the extensions defined in this document, IS-IS
carries information which will be used to program the MPLS data plane
[RFC3031]. In general, the same types of attacks that can be carried
out on the IP/IPv6 control plane can be carried out on the MPLS
control plane resulting in traffic being misrouted in the respective
data planes. However, the latter may be more difficult to detect and
isolate. Existing security extensions as described in [RFC5304] and
[RFC5310] apply to these segment routing extensions.
6. Acknowledgements
We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre
Francois and Jesper Skrivers for their contribution to the content of
this document.
7. Contributors
The following people gave a substantial contribution to the content
of this document and should be considered as co-authors:
Stephane Litkowski
Orange
FR
Email: stephane.litkowski@orange.com
Jeff Tantsura
Apstra, Inc.
Email: jefftant@gmail.com
Peter Psenak
Cisco Systems Inc.
US
Email: ppsenak@cisco.com
Martin Horneffer
Deutsche Telekom
DE
Previdi, et al. Expires September 30, 2019 [Page 29]