IS-IS for IP Internets
Internet Engineering Task Force (IETF) S. Previdi, Ed.
Internet-Draft
Request for Comments: 8667 Huawei
Intended status: Technologies
Category: Standards Track L. Ginsberg, Ed.
Expires: November 20, 2019
ISSN: 2070-1721 C. Filsfils
Cisco Systems, Inc.
A. Bashandy
Arrcus
H. Gredler
RtBrick Inc.
B. Decraene
Orange
May 19,
December 2019
IS-IS Extensions for Segment Routing
draft-ietf-isis-segment-routing-extensions-25
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 document 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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. data plane.
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 an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 20, 2019.
https://www.rfc-editor.org/info/rfc8667.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language
2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3
2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 (Prefix-SID) Sub-TLV
2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8
2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 8
2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9
2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 10 Identifier (LAN-Adj-SID) Sub-TLV
2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 12
2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 13
2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 15
2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 15
2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 16
2.4.6. Example Encodings . . . . . . . . . . . . . . . . . . 16
2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 18
3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 19
3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 19
3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22
3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 23
3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 25
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
4.1. Sub TLVs Sub-TLVs for Type 22,23,25,141,222, Types 22, 23, 25, 141, 222, and 223 . . . . . . . 26
4.2. Sub TLVs Sub-TLVs for Type 135,235,236 Types 135, 235, 236, and 237 . . . . . . . . . . 26
4.3. Sub TLVs Sub-TLVs for Type 242 . . . . . . . . . . . . . . . . . . 26
4.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 26 Registry
5. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1.
6.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2.
6.2. Informative References . . . . . . . . . . . . . . . . . 30
Acknowledgements
Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
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).
Prefix segments represent an ECMP-aware shortest-path shortest path to a prefix (or
a node), 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
control plane can be applied to both IPv6 and MPLS data-planes, data planes and
does 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 Label Switched Paths (LSPs) established with RSVP or
LDP.
There are additional segment types, e.g., the Binding SID as defined
in [RFC8402]. This document also defines an advertisement for one
type of Binding SID: the Mirror Context segment.
This draft document describes the necessary IS-IS extensions that need to be
introduced for Segment Routing operating on an MPLS data-plane. data plane.
The Segment Routing architecture is described in [RFC8402]. Segment
Routing use cases are described in [RFC7855].
1.1. 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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Segment Routing Identifiers
The Segment Routing architecture [RFC8402] defines different types of
Segment Identifiers (SID). (SIDs). This document defines the IS-IS
encodings for the IGP-Prefix Segment, the IGP-Adjacency Segment, the IGP-LAN-
Adjacency Segment
IGP-LAN-Adjacency Segment, and the Binding Segment.
2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) (Prefix-SID) Sub-TLV
A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV
(Prefix-SID sub-TLV).
(Prefix-SID) sub-TLV.
The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as
defined in [RFC8402]. The 'Prefix SID' 'Prefix-SID' MUST be unique within a given
IGP domain (when the L-flag L-Flag is not set).
A Prefix-SID sub-TLV is associated to a prefix advertised by a node
and MAY be present in any of the following TLVs:
TLV-135 (Extended IPv4 reachability) defined in [RFC5305].
TLV-235 (Multitopology (Multi-topology IPv4 Reachability) defined in [RFC5120].
TLV-236 (IPv6 IP Reachability) defined in [RFC5308].
TLV-237 (Multitopology (Multi-topology IPv6 IP Reachability) defined in
[RFC5120].
Binding-TLV
The Binding TLV and Multi-Topology Binding-TLV Binding TLV are defined in Section
Sections 2.4 and Section 2.5 2.5, respectively.
The Prefix-SID 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 | Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Index/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: 3
Length: 5 or 6 depending on the size of the SID (described below)
Flags: 1 octet 1-octet field of the following flags:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R|N|P|E|V|L| |
+-+-+-+-+-+-+-+-+
where:
R-Flag: Re-advertisement flag. Flag. If set, then the prefix
to which this Prefix-SID is attached, attached has been
propagated by the router either from either another
level (i.e., from level-1 Level-1 to level-2 Level-2 or the
opposite) or from redistribution (e.g.: (e.g., from another
protocol).
N-Flag: Node-SID flag. Flag. If set, then the Prefix-SID
refers to the router identified by the prefix.
Typically, the N-Flag is set on Prefix-SIDs that
are attached to a router loopback address. The
N-Flag is set when the Prefix-SID is a Node-SID
as described in [RFC8402].
P-Flag: no-PHP flag. No-PHP (No Penultimate Hop-Popping) 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 Explicit NULL Flag. If set, any upstream
neighbor of the Prefix-SID originator MUST
replace the Prefix-SID with a Prefix-SID having that
has an Explicit-NULL Explicit NULL value (0 for IPv4 and 2 for
IPv6) before forwarding the packet.
V-Flag: Value flag. Flag. If set, then the Prefix-SID carries
a value (instead of an index). By default 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 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. Algorithm identifiers are defined in Section 3.2.
Examples of these algorithms are metric based metric-based Shortest Path
First (SPF), various sorts of Constrained SPF, etc. The algorithm
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 Algorithm field MUST be set to 0 or
to any value advertised in the SR-Algorithm sub-TLV (Section (see
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 (see Section 3.2) MUST ignore the Prefix-SID sub-
TLV.
sub-TLV.
SID/Index/Label as defined in Section 2.1.1.1.
When the Prefix SID Prefix-SID is an index (the V-flag (and the V-Flag is not set) 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 the forwarding state to a particular
destination router.
In many use-cases use cases, a 'stable transport' address is overloaded as an
identifier of a given node. Because Prefixes may be re-advertised
into other levels levels, there may be some ambiguity (e.g. Originating (e.g., originating
router vs. L1L2 router) for which node a particular IP prefix serves
as the identifier. The Prefix-SID sub-TLV contains the necessary
flags to disambiguate Prefix to node Prefix-to-node mappings. Furthermore Furthermore, if a
given node has several 'stable transport' addresses addresses, there are flags
to differentiate those among other Prefixes advertised from a given
node.
2.1.1. Flags
2.1.1.1. V V-Flag and L Flags L-Flag
The V-flag 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 V-Flag and L flags L-Flag are valid:
V-flag is set to 0
The V-Flag and L-flag is L-Flag are set to 0: The SID/Index/Label field is
a 4 octet 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
The V-Flag and L-flag is L-Flag are set to 1: The SID/Index/Label field is
a 3 octet 3-octet local label where the 20 rightmost bits are used for
encoding the label value.
All other combinations of V-flag V-Flag and L-flag L-Flag are invalid invalid, and any SID
advertisement received with an invalid setting for V the V-Flag and L flags
L-Flag MUST be ignored.
2.1.1.2. R R-Flag and N Flags N-Flag
The R-Flag MUST be set for prefixes that are not local to the router
and either: are advertised because of of:
propagation (Level-1 into Level-2);
advertised because of
leaking (Level-2 into Level-1);
advertised because of or
redistribution (e.g.: (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 Attribute Flags sub-TLV [RFC7794] also defines the N N-Flag
and
R flags R-Flag and with the same semantics of the equivalent flags
defined in this document. Whenever the Prefix Attributes Attribute Flags sub-TLV sub-
TLV is present for a given prefix prefix, the values of the N N-Flag and R flags
R-Flag advertised in that sub-TLV MUST be used used, and the values in a
corresponding Prefix
SID Prefix-SID sub-TLV (if present) MUST be ignored.
2.1.1.3. E E-Flag and P Flags P-Flag
The following behavior is associated with the settings of the E E-Flag
and P
flags:
o P-Flag:
* If the P-flag P-Flag is not set set, then any upstream neighbor of the Prefix-
SID
Prefix-SID originator MUST pop the Prefix-SID. This is equivalent
to the
penultimate hop popping "penultimate hop-popping" mechanism used in the MPLS dataplane data
plane, 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 P-Flag is unset unset, the received E-flag
E-Flag is ignored.
o
* If the P-flag P-Flag is set set, then:
*
- If the E-flag E-Flag is not set 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
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 interdomain border router (prefix propagation
from one domain to another).
*
- If the E-flag E-Flag is set set, then any upstream neighbor of the Prefix-
SID originator MUST replace the PrefixSID Prefix-SID with a Prefix-SID
having an Explicit-NULL 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 (from either Level-1 to Level-2 or vice versa) Level-2 to Level-
1) a reachability advertisement originated by another IS-IS speaker,
the router MUST set the P-flag P-Flag and MUST clear the E-flag 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 Level-1-2 router that propagates the Prefix-SID sub-TLV between
levels maintains the content (flags and SID) SID), except as noted in
Section
Sections 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).
(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 IS Neighbor TLVs
below:
TLV-22 (Extended IS reachability)[RFC5305] reachability) [RFC5305]
TLV-222 (Multitopology IS)[RFC5120] (MT-ISN) [RFC5120]
TLV-23 (IS Neighbor Attribute)[RFC5311] Attribute) [RFC5311]
TLV-223 (Multitopology (MT IS Neighbor Attribute)[RFC5311] Attribute) [RFC5311]
TLV-141 (inter-AS reachability information)[RFC5316] information) [RFC5316]
Multiple Adj-SID sub-TLVs MAY be associated with a single IS-
neighbor. IS
Neighbor.
2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV
The following format is defined for the Adj-SID sub-TLV:
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/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: 31
Length: 5 or 6 depending on size of the SID
Flags: 1 octet 1-octet field of the following flags:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|B|V|L|S|P| |
+-+-+-+-+-+-+-+-+
where:
F-Flag: Address-Family flag. Flag. If unset, then the Adj-SID
is used when forwarding IPv4 encapsulated IPv4-encapsulated
traffic to the neighbor. If set set, then the Adj-SID Adj-
SID is used when forwarding IPv6
encapsulated IPv6-encapsulated
traffic to the neighbor.
B-Flag: Backup flag. Flag. If set, the Adj-SID is eligible
for protection (e.g.: (e.g., using IPFRR IP Fast Reroute
(IPFRR) or MPLS-FRR) MPLS Fast Reroute (MPLS-FRR)) as
described in [RFC8402].
V-Flag: Value flag. Flag. If set, then the Adj-SID carries a
value. By default default, the flag is SET.
L-Flag: Local Flag. If set, then the value/index
carried by the Adj-SID has local significance.
By default default, the flag is SET.
S-Flag.
S-Flag: Set flag. 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.
P-Flag: Persistent flag. 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 SR-capable router MAY allocate an Adj-SID for each of its
adjacencies
adjacencies.
An SR capable SR-capable router MAY allocate more than one Adj-SID to an
adjacency.
An SR capable SR-capable router MAY allocate the same Adj-SID to different
adjacencies.
When the P-flag P-Flag is not set, the Adj-SID MAY be persistent. When
the P-flag P-Flag is set, the Adj-SID MUST be persistent.
Examples of use of the Adj-SID sub-TLV use are described in [RFC8402].
The F-flag 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 Identifier (LAN-Adj-SID) Sub-TLV
In LAN subnetworks, the Designated Intermediate System (DIS) is
elected and originates the Pseudonode-LSP (PN-LSP) 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 that is a part
of the TLV advertising the adjacency to the DIS (e.g.: (e.g., TLV-22).
The following new sub-TLV is defined: LAN-Adj-SID LAN Adjacency Segment
Identifier (LAN-Adj-SID) containing the set of Adj-SIDs the router
assigned to each of its LAN neighbors.
The format of the LAN-Adj-SID sub-TLV is as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor System-ID (ID length octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: 32
Length: variable. Variable
Flags: 1 octet 1-octet field of the following flags:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|B|V|L|S|P| |
+-+-+-+-+-+-+-+-+
where F, B, V, L, S the F-Flag, B-Flag, V-Flag, L-Flag, S-Flag, and P flags
P-Flag are defined in Section 2.2.1.
Other bits: MUST be zero when originated and ignored when
received.
Weight: 1 octet. The value represents the weight of the Adj-SID Adj-
SID for the purpose of load balancing. The use of
the weight is defined in [RFC8402].
Neighbor System-ID: IS-IS System-ID of length "ID Length" as
defined in [ISO10589].
SID/Index/Label as
SID/Index/Label: As defined in Section 2.1.1.1.
Multiple LAN-Adj-SID sub-TLVs MAY be encoded.
Note that this sub-TLV MUST NOT appear in TLV 141.
In case one TLV-22/23/222/223 TLV-22, TLV-23, TLV-222, or TLV-223 (reporting the adjacency
to the DIS) can't contain the whole set of LAN-Adj-SID sub-TLVs,
multiple advertisements of the adjacency to the DIS MUST be used 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-SIDs 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 sub-TLV (Section 3.1)
SR Local Block Sub-TLV 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 codepoint used in all of the above cases is the SID/
Label Sub-TLV code point sub-TLV codepoint 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 an MPLS Label. 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
SID/Label: if If the length is set to 3 3, then the 20 rightmost bits
represent a an MPLS label. If the length is set to 4 4,
then the value is a
32 bit index 32-bit index.
2.4. SID/Label Binding TLV
The SID/Label Binding TLV MAY be originated by any router in an IS-IS
domain. There are multiple uses of the SID/Label Binding TLV.
The SID/Label Binding TLV may be used to advertise prefixes to SID/
Label mappings. This functionality is called the Segment Routing
Mapping Server (SRMS). The behavior of the SRMS is defined in
[I-D.ietf-spring-segment-routing-ldp-interop].
[RFC8661].
The SID/Label Binding TLV may also be used to advertise a Mirror SID
to advertise
indicating the ability of a node to process traffic originally
destined to another IGP node. This behavior is defined in [RFC8402].
The SID/Label Binding 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 | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range | Prefix Length | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Prefix (continued, variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SID/Label Binding TLV format
o
where:
Type: 149
o
Length: variable.
o Variable
Flags: 1 octet of flags
o
RESERVED: 1 octet of RESERVED (SHOULD be transmitted as 0 and MUST be
ignored on receipt)
o
Range: 2 octets of Range
o
Prefix Length: 1 octet of Prefix Length
o
Prefix: 0-16 octets of Prefix
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 1-octet field of the following flags:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|M|S|D|A| |
+-+-+-+-+-+-+-+-+
where:
F-Flag: Address Family flag. Address-Family Flag. If unset, then the Prefix prefix carries
an IPv4 Prefix. prefix. If set set, then the Prefix prefix carries an IPv6 Prefix.
prefix.
M-Flag: Mirror Context flag. 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 S-Flag is not
set, the SID/
Label SID/Label Binding TLV MUST NOT be leaked between
levels. This bit MUST NOT be altered during the TLV
leaking.
D-Flag: when When the SID/Label Binding TLV is leaked from level-2 Level-2 to
level-1,
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 Level-1 to level-2. Level-2. This is
to prevent TLV looping across levels.
A-Flag: Attached flag. 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.: (e.g., through
explicit configuration). If the Binding TLV is leaked to
other areas/levels areas/levels, the A-flag A-Flag MUST be cleared.
An implementation may decide not to honor the S-flag S-Flag in order not to
not leak Binding TLV's TLVs between levels (for policy reasons).
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. Prefix-SIDs. This advertisement
supports the SRMS functionality. It is essentially a compression
scheme to distribute a continuous Prefix prefix and their continuous,
corresponding SID/Label Block. If a single SID is advertised advertised, then
the range Range field MUST be set to one. For range advertisements > 1,
the range Range field MUST be set to the number of addresses that need to
be mapped into a Prefix-SID. In either case 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 Equivalence Class at the tail- 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 prefix are encoded (i.e., 1
octet for prefix length 1 up to 8, 2 octets for prefix length 9 to up
16, 3 octets for prefix length 17 up to 24 and 24, 4 octets for prefix
length 25 up to 32, ...., and 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
SID/Index/Label value associated with the prefix and range. The
Prefix-SID Sub-TLV sub-TLV MUST be present in the SID/Label Binding TLV when
the M-flag M-Flag is clear. The Prefix-SID Sub-TLV sub-TLV MUST NOT be present when
the M-flag M-Flag is set.
2.4.4.1. Prefix-SID Flags
The Prefix-SID flags Flags are defined in Section 2.1. The Mapping Server
MAY advertise a mapping with the N flag 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.
2.4.4.2. PHP Behavior when using Using Mapping Server Advertisements
As the mapping server Mapping Server does not specify the originator of a prefix
advertisement
advertisement, it is not possible to determine PHP behavior solely
based on the Mapping Server Advertisement. However, if additional
information is available available, PHP behavior may safely be done. The
required information consists of:
o
* A prefix reachability advertisement for the prefix has been
received
received, which includes the Prefix Attribute Flags sub-TLV
[RFC7794].
o X
* X-Flag and R flags R-Flag are both set to 0 in the Prefix Attribute Flags sub-
TLV.
sub-TLV.
In the absence of an a Prefix Attribute Flags sub-TLV [RFC7794] [RFC7794], the A
flag
A-Flag in the binding Binding TLV indicates that the originator of a prefix
reachability advertisement is directly connected to the prefix and
thus prefix; thus,
PHP MUST be done by the neighbors of the router originating the
prefix reachability advertisement. Note that A-flag the 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 Algorithm field contains the identifier of the algorithm
associated with the SIDs for the prefix(es) in the range. Use of the
algorithm
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 M-Flag is set in the Flags field of the parent TLV.
2.4.6. Example Encodings
Example 1: if If the following IPv4 router addresses (loopback
addresses) need to be mapped into the corresponding Prefix SID
indexes. Prefix-SID
indexes, then:
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
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|0|0|0| | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 4 | 32 | 192 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2 | 1 |Prefix-SID Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV Sub-TLV Length| Flags | Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example-2:
Example 2: If the following IPv4 prefixes need to be mapped into the
corresponding Prefix-SID indexes: indexes, then:
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
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|0|0|0| | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 7 | 24 | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 1 |Prefix-SID Type| sub-TLV Sub-TLV Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 51 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example-3:
Example 3: If the following IPv6 prefixes need to be mapped into the
corresponding Prefix-SID indexes: indexes, then:
2001:db8:1/48, Prefix-SID: Index 151
2001:db8:2/48, Prefix-SID: Index 152
2001:db8:3/48, Prefix-SID: Index 153
2001:db8:4/48, Prefix-SID: Index 154
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 |1|0|0|0|0| | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 4 | 48 | 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x0d | 0xb8 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 |Prefix-SID Type| sub-TLV Sub-TLV Length| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 151 |
+-+-+-+-+-+-+-+-+
It is not expected that a network operator will be able to keep fully
continuous Prefix / SID/Index Prefix/SID/Index mappings. In order to support
noncontinuous mapping ranges ranges, an implementation MAY generate several
instances of Binding TLVs.
For example example, if a router wants to advertise the following ranges:
Range 16: { 192.0.2.1-15, Index 1-15 }
Range 6: { 192.0.2.22-27, Index 22-27 }
Range 41: { 192.0.2.44-84, Index 80-120 }
A
a router would need to advertise three instances of the Binding TLV.
2.5. Multi-Topology SID/Label Binding TLV
The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS Multi-
Topology IS-IS (M-ISIS) as defined in [RFC5120]. The Multi-Topology
SID/Label Binding TLV has the same format as the SID/Label Binding
TLV defined in Section 2.4 with the difference consisting of a Multitopology Multi-
topology Identifier (MTID) (MT ID) as defined here below:
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 | MTID MT ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Multi-Topology SID/Label Binding TLV format
where:
Type: 150
Length: variable
MTID Variable
MT ID is the multitopology identifier Multi-topology Identifier defined as:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESVD | MTID MT ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RESVD: reserved Reserved bits. MUST be reset on transmission and
ignored on receive.
MTID: a
MT ID: A 12-bit field containing the non-zero ID of the
topology being announced. The TLV MUST be ignored if
the ID is zero. This is to ensure the consistent view
of the standard unicast topology.
The other fields and Sub-TLVs sub-TLVs are defined in Section 2.4.
3. Router Capabilities
This section defines sub-TLVs which that are inserted into the IS-IS Router
Capability TLV-242 that is defined in [RFC7981].
3.1. SR-Capabilities Sub-TLV
Segment Routing requires each router to advertise its SR data-plane data plane
capability and the range of MPLS label values it uses for Segment
Routing in the case where global SIDs are allocated (i.e., global
indexes). Data-plane Data plane capabilities and label ranges are advertised
using the newly defined SR-Capabilities sub-TLV.
The Router Capability TLV specifies flags that control its
advertisement. The SR Capabilities SR-Capabilities sub-TLV MUST be propagated
throughout the level and MUST NOT be advertised across level
boundaries. Therefore Therefore, Router Capability TLV distribution flags are
set accordingly, i.e., the S flag S-Flag in the Router Capability TLV
[RFC7981] MUST be unset.
The SR Capabilities SR-Capabilities 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 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID/Label Sub-TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2
Length: variable. Variable
Flags: 1 octet of flags. The following are defined:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|I|V| |
+-+-+-+-+-+-+-+-+
where:
I-Flag: MPLS IPv4 flag. Flag. If set, then the router is capable of
processing SR MPLS encapsulated SR-MPLS-encapsulated IPv4 packets on all
interfaces.
V-Flag: MPLS IPv6 flag. Flag. If set, then the router is capable of
processing SR MPLS encapsulated SR-MPLS-encapsulated IPv6 packets on all
interfaces.
One or more SRGB Segment Routing Global Block (SRGB) Descriptor
entries, each of which have the following format:
Range: 3 octets. octets
SID/Label sub-TLV (as sub-TLV: MPLS label as defined in Section 2.3). 2.3
The SID/Label sub-TLV contains the first value of the SRGB while the
range contains the number of SRGB elements. The range value MUST be
higher than 0.
The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number
number, but a router MUST NOT advertise more than one SR-Capabilities sub-
TLV.
sub-TLV. A router receiving multiple SR-Capabilities sub-TLVs from
the same originator SHOULD select the first advertisement in the lowest
numbered
lowest-numbered LSP.
When multiple SRGB Descriptors are advertised advertised, the entries define an
ordered set of ranges on which a SID index is to be applied. For
this reason 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 sub-TLV, the new Descriptor 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 black
hole / misdirect some traffic during the IGP convergence. In
particular, if a range which that is not the last is extended 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 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]. [RFC8660].
Here follows an example of the advertisement of multiple ranges:
The originating router advertises the 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
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), metric-based 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].
[RFC8665]. The following values have been defined:
0: Shortest Path First (SPF) SPF algorithm based on link metric. This is the well-known
shortest path algorithm as computed by the IS-IS Decision process.
Process. Consistent with the deployed practice for link-
state 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) SPF algorithm based on link metric. The algorithm is
identical to algorithm 0 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.
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 Therefore,
Router Capability TLV distribution flags are set accordingly, i.e.,
the S flag S-Flag MUST be unset.
The SR-Algorithm sub-TLV is optional. It MUST NOT be advertsied advertised 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 lowest-numbered LSP.
When the originating router does not advertise the SR-Algorithm sub-
TLV, this it implies that algorithm 0 is the only algorithm supported by
the routers
supporting that support the extensions defined in this document is Algorithm 0. document.
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. Variable
Algorithm: 1 octet of algorithm
3.3. SR Local Block Sub-TLV
The SR Local Block (SRLB) Sub-TLV sub-TLV contains the range of labels the
node has reserved for local Local SIDs. Local SIDs are used, e.g., for
Adjacency-SIDs,
Adj-SIDs, and may also be allocated by components other than the IS-IS IS-
IS protocol. As an example, an application or a controller may
instruct the router to allocate a specific local Local SID. Therefore, in
order for such applications or controllers to know what are the
local Local SIDs
are available in the router, it is required that the router
advertises its SRLB.
The SRLB Sub-TLV sub-TLV is used for this 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. 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. octets
SID/Label sub-TLV (as defined sub-TLV: MPLS label as defined in Section 2.3). 2.3
The SID/Label sub-TLV contains the first value of the SRLB while the
range contains the number of SRLB elements. The range value MUST be
higher than 0.
The SRLB sub-TLV MAY be advertised in an LSP of any number 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 lowest-numbered LSP.
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]. [RFC8660].
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.: (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 Local SIDs is done
through IS-IS Sub-TLVs sub-TLVs such as the Adjacency-SID. Adj-SID. However, the reporting
of allocated local Local SIDs may also be done through other means and
protocols which that are outside the scope of this document.
A router advertising the SRLB sub-TLV may also have other label
ranges, outside the SRLB, for its local allocation purposes which that are
NOT advertised in the SRLB. For example, it is possible that an
Adjacency-SID Adj-
SID is allocated using a local label not part of the SRLB.
3.4. SRMS Preference Sub-TLV
The Segment Routing Mapping Server (SRMS) 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 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 | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 24
Length: 1. 1
Preference: 1 octet. Unsigned 8 bit octet and unsigned 8-bit SRMS preference.
The SRMS Preference sub-TLV MAY be advertised in an LSP of any number
number, but a router MUST NOT advertise more than one SRMS Preference sub-
TLV.
sub-TLV. A router receiving multiple SRMS Preference sub-TLVs, from
the same originator, SHOULD select the first advertisement in the lowest
numbered
lowest-numbered LSP.
The use of the SRMS Preference preference during the SID selection process is
described in [I-D.ietf-spring-segment-routing-ldp-interop] [RFC8661].
4. IANA Considerations
This document requests allocation for
Per this document, IANA has allocated the following TLVs and Sub- sub-
TLVs.
4.1. Sub TLVs Sub-TLVs for Type 22,23,25,141,222, Types 22, 23, 25, 141, 222, and 223
This document makes the following registrations in the "sub-TLVs "Sub-TLVs for
TLV 22, 23, 25, 141, 222 222, and 223" registry.
+------+--------------------+----+----+----+-----+-----+-----+
| Type | Description | 22 | 23 | 25 | 141 | 222 | 223
---- -------------------------------- --- --- --- --- --- --- |
+======+====================+====+====+====+=====+=====+=====+
| 31 | Adjacency Segment Identifier | y | y | n | y | y | y |
| | Identifier | | | | | | |
+------+--------------------+----+----+----+-----+-----+-----+
| 32 | LAN Adjacency Segment Identifier | y | y | n | y | y | y |
| | Segment Identifier | | | | | | |
+------+--------------------+----+----+----+-----+-----+-----+
Table 1
4.2. Sub TLVs Sub-TLVs for Type 135,235,236 Types 135, 235, 236, and 237
This document makes the following registrations in the "sub-TLVs "Sub-TLVs for
TLV 135,235,236 135, 235, 236, and 237" registry.
+------+---------------------------+-----+-----+-----+-----+
| Type | Description | 135 | 235 | 236 | 237
---- ------------------------- --- --- --- --- |
+======+===========================+=====+=====+=====+=====+
| 3 | Prefix Segment Identifier | y | y | y | y |
+------+---------------------------+-----+-----+-----+-----+
Table 2
4.3. Sub TLVs Sub-TLVs for Type 242
This document makes the following registrations in the "sub-TLVs "Sub-TLVs for
TLV 242" registry.
+------+------------------------------------+
| Type | Description
---- ----------- |
+======+====================================+
| 2 | Segment Routing Capability |
+------+------------------------------------+
| 19 | Segment Routing Algorithm |
+------+------------------------------------+
| 22 | Segment Routing Local Block (SRLB) |
+------+------------------------------------+
| 24 | Segment Routing Mapping Server |
| | Preference (SRMS Preference) |
+------+------------------------------------+
Table 3
4.4. New TLV Codepoint and Sub-TLV registry Registry
This document registers the following TLV:
+-------+----------------------------+-----+-----+-----+-------+
| Value | Name | IIH | LSP | SNP | Purge
----- --------------------------------- --- --- --- ----- |
+=======+============================+=====+=====+=====+=======+
| 149 | Segment Identifier/Label Binding Identifier / Label | n | y | n | n |
| | Binding | | | | |
+-------+----------------------------+-----+-----+-----+-------+
| 150 | Multi-Topology Segment Identifier | n | y | n | n
/Label |
| | Identifier / Label Binding | | | | |
+-------+----------------------------+-----+-----+-----+-------+
Table 4
This document creates the following sub-TLV Registry:
Name: sub-TLVs Sub-TLVs for TLVs 149 and 150
Registration Procedure: Expert Review [RFC8126]
+-------+---------------------------+
| Type | Description
---- ----------- |
+=======+===========================+
| 0 | Reserved |
+-------+---------------------------+
| 1 | SID/Label |
+-------+---------------------------+
| 2 | Unassigned |
+-------+---------------------------+
| 3 | Prefix SID Segment Identifier |
+-------+---------------------------+
| 4-255 | Unassigned |
+-------+---------------------------+
Table 5
5. Security Considerations
With the use of the extensions defined in this document, IS-IS
carries information which that will be used to program the MPLS data plane
[RFC3031]. In general, the same types type of attacks that can be carried
out on the IP/IPv6 control plane can be carried out on the MPLS
control plane 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 Segment Routing extensions.
6. Acknowledgements
We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre
Francois References
6.1. Normative References
[ISO10589] International Organization for Standardization,
"Information technology -- Telecommunications 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
Email: Martin.Horneffer@telekom.de
Wim Henderickx
Nokia
BE
Email: wim.henderickx@nokia.com
Edward Crabbe
Oracle
US
Email: edward.crabbe@oracle.com
Rob Shakir
Google
UK
Email: robjs@google.com
Igor Milojevic
Individual
RS
Email: milojevicigor@gmail.com
Saku Ytti
TDC
FI
Email: saku@ytti.fi
Steven Luong
Cisco Systems Inc.
US
Email: sluong@cisco.com
8. References
8.1. Normative References
[I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-27 (work in progress), December 2018.
[I-D.ietf-spring-segment-routing-ldp-interop]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and
S. Litkowski, "Segment Routing interworking with LDP",
draft-ietf-spring-segment-routing-ldp-interop-15 (work in
progress), September 2018.
[I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-22
(work in progress), May 2019.
[ISO10589]
International Organization for Standardization,
"Intermediate
information exchange between systems -- 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 network
service (ISO 8473)", ISO/
IEC ISO/IEC 10589:2002, Second Edition, Nov
November 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
March 2016, <https://www.rfc-editor.org/info/rfc7794>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
8.2.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC8661] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., and S. Litkowski, "Segment Routing MPLS
Interworking with LDP", RFC 8661, DOI 10.17487/RFC8661,
December 2019, <https://www.rfc-editor.org/info/rfc8661>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>.
6.2. Informative References
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>.
[RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M.
Shand, "Simplified Extension of Link State PDU (LSP) Space
for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009,
<https://www.rfc-editor.org/info/rfc5311>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <https://www.rfc-editor.org/info/rfc5316>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
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.
Contributors
The following people gave a substantial contribution to the content
of this document and should be considered as coauthors:
Stephane Litkowski
Orange
France
Email: stephane.litkowski@orange.com
Jeff Tantsura
Apstra, Inc.
Email: jefftant@gmail.com
Peter Psenak
Cisco Systems Inc.
United States of America
Email: ppsenak@cisco.com
Martin Horneffer
Deutsche Telekom
Germany
Email: Martin.Horneffer@telekom.de
Wim Henderickx
Nokia
Belgium
Email: wim.henderickx@nokia.com
Edward Crabbe
Oracle
United States of America
Email: edward.crabbe@oracle.com
Rob Shakir
Google
United Kingdom
Email: robjs@google.com
Igor Milojevic
Individual
Serbia
Email: milojevicigor@gmail.com
Saku Ytti
TDC
Finland
Email: saku@ytti.fi
Authors' Addresses
Stefano Previdi (editor)
Huawei
IT Technologies
Italy
Email: stefano@previdi.net
Les Ginsberg (editor)
Cisco Systems, Inc.
USA
United States of America
Email: ginsberg@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Brussels
BE
Belgium
Email: cfilsfil@cisco.com
Ahmed Bashandy
Arrcus
Email: abashandy.ietf@gmail.com
Hannes Gredler
RtBrick Inc.
Email: hannes@rtbrick.com
Bruno Decraene
Orange
FR
France
Email: bruno.decraene@orange.com