draft-ietf-isis-segment-routing-extensions-25.txt   rfc8667.txt 
IS-IS for IP Internets S. Previdi, Ed. Internet Engineering Task Force (IETF) S. Previdi, Ed.
Internet-Draft Huawei Request for Comments: 8667 Huawei Technologies
Intended status: Standards Track L. Ginsberg, Ed. Category: Standards Track L. Ginsberg, Ed.
Expires: November 20, 2019 C. Filsfils ISSN: 2070-1721 C. Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
A. Bashandy A. Bashandy
Arrcus Arrcus
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
B. Decraene B. Decraene
Orange Orange
May 19, 2019 December 2019
IS-IS Extensions for Segment Routing IS-IS Extensions for Segment Routing
draft-ietf-isis-segment-routing-extensions-25
Abstract Abstract
Segment Routing (SR) allows for a flexible definition of end-to-end Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are topological sub-paths, called "segments". These segments are
advertised by the link-state routing protocols (IS-IS and OSPF). advertised by the link-state routing protocols (IS-IS and OSPF).
This draft describes the necessary IS-IS extensions that need to be This document describes the IS-IS extensions that need to be
introduced for Segment Routing operating on an MPLS data-plane. 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on November 20, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8667.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 2. Segment Routing Identifiers
2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Prefix Segment Identifier (Prefix-SID) Sub-TLV
2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8 2.1.1. Flags
2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 8 2.1.2. Prefix-SID Propagation
2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 2.2. Adjacency Segment Identifier
2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 10 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV
2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 12 2.2.2. Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV
2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 13 2.3. SID/Label Sub-TLV
2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. SID/Label Binding TLV
2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.1. Flags
2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 15 2.4.2. Range
2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 15 2.4.3. Prefix Length, Prefix
2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 16 2.4.4. Mapping Server Prefix-SID
2.4.6. Example Encodings . . . . . . . . . . . . . . . . . . 16 2.4.5. SID/Label Sub-TLV
2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 18 2.4.6. Example Encodings
3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 19 2.5. Multi-Topology SID/Label Binding TLV
3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 19 3. Router Capabilities
3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22 3.1. SR-Capabilities Sub-TLV
3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 23 3.2. SR-Algorithm Sub-TLV
3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 25 3.3. SR Local Block Sub-TLV
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 3.4. SRMS Preference Sub-TLV
4.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 26 4. IANA Considerations
4.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 26 4.1. Sub-TLVs for Types 22, 23, 25, 141, 222, and 223
4.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 26 4.2. Sub-TLVs for Types 135, 235, 236, and 237
4.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 26 4.3. Sub-TLVs for Type 242
5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 4.4. New TLV Codepoint and Sub-TLV Registry
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 5. Security Considerations
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 6. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 29 6.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 30 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Contributors
Authors' Addresses
1. Introduction 1. Introduction
Segment Routing (SR) allows for a flexible definition of end-to-end Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are topological sub-paths, called "segments". These segments are
advertised by the link-state routing protocols (IS-IS and OSPF). advertised by the link-state routing protocols (IS-IS and OSPF).
Prefix segments represent an ECMP-aware shortest-path to a prefix (or Prefix segments represent an ECMP-aware shortest path to a prefix (or
a node), as per the state of the IGP topology. Adjacency segments a node), as per the state of the IGP topology. Adjacency segments
represent a hop over a specific adjacency between two nodes in the represent a hop over a specific adjacency between two nodes in the
IGP. A prefix segment is typically a multi-hop path while an 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 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 control plane can be applied to both IPv6 and MPLS data planes and
does not require any additional signaling (other than the regular does not require any additional signaling (other than the regular
IGP). For example, when used in MPLS networks, SR paths do not IGP). For example, when used in MPLS networks, SR paths do not
require any LDP or RSVP-TE signaling. Still, SR can interoperate in require any LDP or RSVP-TE signaling. Still, SR can interoperate in
the presence of LSPs established with RSVP or LDP. the presence of Label Switched Paths (LSPs) established with RSVP or
LDP.
There are additional segment types, e.g., Binding SID defined in There are additional segment types, e.g., the Binding SID as defined
[RFC8402]. This document also defines an advertisement for one type in [RFC8402]. This document also defines an advertisement for one
of Binding SID: the Mirror Context segment. type of Binding SID: the Mirror Context segment.
This draft describes the necessary IS-IS extensions that need to be This document describes the IS-IS extensions that need to be
introduced for Segment Routing operating on an MPLS data-plane. introduced for Segment Routing operating on an MPLS data plane.
The Segment Routing architecture is described in [RFC8402]. The Segment Routing architecture is described in [RFC8402]. Segment
Routing use cases are described in [RFC7855].
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 2. Segment Routing Identifiers
The Segment Routing architecture [RFC8402] defines different types of The Segment Routing architecture [RFC8402] defines different types of
Segment Identifiers (SID). This document defines the IS-IS encodings Segment Identifiers (SIDs). This document defines the IS-IS
for the IGP-Prefix Segment, the IGP-Adjacency Segment, the IGP-LAN- encodings for the IGP-Prefix Segment, the IGP-Adjacency Segment, the
Adjacency Segment and the Binding Segment. IGP-LAN-Adjacency Segment, and the Binding Segment.
2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 2.1. Prefix Segment Identifier (Prefix-SID) Sub-TLV
A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV A new IS-IS sub-TLV is defined: the Prefix Segment Identifier
(Prefix-SID sub-TLV). (Prefix-SID) sub-TLV.
The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as
defined in [RFC8402]. The 'Prefix SID' MUST be unique within a given defined in [RFC8402]. The 'Prefix-SID' MUST be unique within a given
IGP domain (when the L-flag is not set). IGP domain (when the L-Flag is not set).
A Prefix-SID sub-TLV is associated to a prefix advertised by a node A Prefix-SID sub-TLV is associated to a prefix advertised by a node
and MAY be present in any of the following TLVs: and MAY be present in any of the following TLVs:
TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. TLV-135 (Extended IPv4 reachability) defined in [RFC5305].
TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. TLV-235 (Multi-topology IPv4 Reachability) defined in [RFC5120].
TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. TLV-236 (IPv6 IP Reachability) defined in [RFC5308].
TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120]. TLV-237 (Multi-topology IPv6 IP Reachability) defined in
[RFC5120].
Binding-TLV and Multi-Topology Binding-TLV defined in Section 2.4 The Binding TLV and Multi-Topology Binding TLV are defined in
and Section 2.5 respectively. Sections 2.4 and 2.5, respectively.
The Prefix-SID sub-TLV has the following format: The Prefix-SID sub-TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Algorithm | | Type | Length | Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Index/Label (variable) | | SID/Index/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Type: 3 Type: 3
Length: 5 or 6 depending on the size of the SID (described below) Length: 5 or 6 depending on the size of the SID (described below)
Flags: 1 octet field of following flags: Flags: 1-octet field of the following flags:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|R|N|P|E|V|L| | |R|N|P|E|V|L| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
where: where:
R-Flag: Re-advertisement flag. If set, then the prefix to R-Flag: Re-advertisement Flag. If set, then the prefix
which this Prefix-SID is attached, has been propagated by the to which this Prefix-SID is attached has been
router either from another level (i.e., from level-1 to level-2 propagated by the router from either another
or the opposite) or from redistribution (e.g.: from another level (i.e., from Level-1 to Level-2 or the
protocol). opposite) or redistribution (e.g., from another
protocol).
N-Flag: Node-SID flag. If set, then the Prefix-SID refers to N-Flag: Node-SID Flag. If set, then the Prefix-SID
the router identified by the prefix. Typically, the N-Flag is refers to the router identified by the prefix.
set on Prefix-SIDs attached to a router loopback address. The Typically, the N-Flag is set on Prefix-SIDs that
N-Flag is set when the Prefix-SID is a Node-SID as described in are attached to a router loopback address. The
[RFC8402]. 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 P-Flag: No-PHP (No Penultimate Hop-Popping) Flag. If
pop the Prefix-SID before delivering the packet to the node set, then the penultimate hop MUST NOT pop the
that advertised the Prefix-SID. 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 E-Flag: Explicit NULL Flag. If set, any upstream
the Prefix-SID originator MUST replace the Prefix-SID with a neighbor of the Prefix-SID originator MUST
Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for replace the Prefix-SID with a Prefix-SID that
IPv6) before forwarding the packet. has 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 V-Flag: Value Flag. If set, then the Prefix-SID carries
value (instead of an index). By default the flag is UNSET. a value (instead of an index). By default, the
flag is UNSET.
L-Flag: Local Flag. If set, then the value/index carried by L-Flag: Local Flag. If set, then the value/index
the Prefix-SID has local significance. By default the flag is carried by the Prefix-SID has local
UNSET. significance. By default, the flag is UNSET.
Other bits: MUST be zero when originated and ignored when Other bits: MUST be zero when originated and ignored
received. when received.
Algorithm: the router may use various algorithms when calculating Algorithm: the router may use various algorithms when calculating
reachability to other nodes or to prefixes attached to these reachability to other nodes or to prefixes attached to these
nodes. Algorithm identifiers are defined in Section 3.2. nodes. Algorithm identifiers are defined in Section 3.2.
Examples of these algorithms are metric based Shortest Path First Examples of these algorithms are metric-based Shortest Path
(SPF), various sorts of Constrained SPF, etc. The algorithm field First (SPF), various sorts of Constrained SPF, etc. The
of the Prefix-SID contains the identifier of the algorithm the Algorithm field of the Prefix-SID contains the identifier of
router uses to compute the reachability of the prefix to which the the algorithm the router uses to compute the reachability of
Prefix-SID is associated. the prefix to which the Prefix-SID is associated.
At origination, the Prefix-SID algorithm field MUST be set to 0 or 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). to any value advertised in the SR-Algorithm sub-TLV (see
Section 3.2).
A router receiving a Prefix-SID from a remote node and with an A router receiving a Prefix-SID from a remote node and with an
algorithm value that such remote node has not advertised in the algorithm value that such remote node has not advertised in the
SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- SR-Algorithm sub-TLV (see Section 3.2) MUST ignore the Prefix-SID
TLV. sub-TLV.
SID/Index/Label as defined in Section 2.1.1.1. 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 When the Prefix-SID is an index (and the V-Flag is not set), the
used to determine the actual label value inside the set of all value is used to determine the actual label value inside the set of
advertised label ranges of a given router. This allows a receiving all advertised label ranges of a given router. This allows a
router to construct forwarding state to a particular destination receiving router to construct the forwarding state to a particular
router. destination router.
In many use-cases a 'stable transport' address is overloaded as an In many use cases, a 'stable transport' address is overloaded as an
identifier of a given node. Because Prefixes may be re-advertised identifier of a given node. Because Prefixes may be re-advertised
into other levels there may be some ambiguity (e.g. Originating into other levels, there may be some ambiguity (e.g., originating
router vs. L1L2 router) for which node a particular IP prefix serves router vs. L1L2 router) for which node a particular IP prefix serves
as identifier. The Prefix-SID sub-TLV contains the necessary flags as the identifier. The Prefix-SID sub-TLV contains the necessary
to disambiguate Prefix to node mappings. Furthermore if a given node flags to disambiguate Prefix-to-node mappings. Furthermore, if a
has several 'stable transport' addresses there are flags to given node has several 'stable transport' addresses, there are flags
differentiate those among other Prefixes advertised from a given to differentiate those among other Prefixes advertised from a given
node. node.
2.1.1. Flags 2.1.1. Flags
2.1.1.1. V and L Flags 2.1.1.1. V-Flag and L-Flag
The V-flag indicates whether the SID/Index/Label field is a value or The V-Flag indicates whether the SID/Index/Label field is a value or
an index. an index.
The L-Flag indicates whether the value/index in the SID/Index/Label The L-Flag indicates whether the value/index in the SID/Index/Label
field has local or global significance. field has local or global significance.
The following settings for V and L flags are valid: The following settings for V-Flag and L-Flag are valid:
V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label field The V-Flag and L-Flag are set to 0: The SID/Index/Label field is
is a 4 octet index defining the offset in the SID/Label space a 4-octet index defining the offset in the SID/Label space
advertised by this router using the encodings defined in Section 3.1. 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 The V-Flag and L-Flag are set to 1: The SID/Index/Label field is
is a 3 octet local label where the 20 rightmost bits are used for a 3-octet local label where the 20 rightmost bits are used for
encoding the label value. encoding the label value.
All other combinations of V-flag and L-flag are invalid and any SID 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 advertisement received with an invalid setting for the V-Flag and
be ignored. L-Flag MUST be ignored.
2.1.1.2. R and N Flags 2.1.1.2. R-Flag and N-Flag
The R-Flag MUST be set for prefixes that are not local to the router The R-Flag MUST be set for prefixes that are not local to the router
and either: and are advertised because of:
advertised because of propagation (Level-1 into Level-2); propagation (Level-1 into Level-2);
advertised because of leaking (Level-2 into Level-1);
advertised because of redistribution (e.g.: from another leaking (Level-2 into Level-1); or
protocol).
redistribution (e.g., from another protocol).
In the case where a Level-1-2 router has local interface addresses In the case where a Level-1-2 router has local interface addresses
configured in one level, it may also propagate these addresses into 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 the other level. In such case, the Level-1-2 router MUST NOT set the
R bit. R bit.
The N-Flag is used in order to define a Node-SID. A router MAY set 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 N-Flag only if all of the following conditions are met:
The prefix to which the Prefix-SID is attached is local to the 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 router (i.e., the prefix is configured on one of the local
interfaces, e.g., a 'stable transport' loopback). interfaces, e.g., a 'stable transport' loopback).
The prefix to which the Prefix-SID is attached has a Prefix length The prefix to which the Prefix-SID is attached has a Prefix length
of either /32 (IPv4) or /128 (IPv6). of either /32 (IPv4) or /128 (IPv6).
The router MUST ignore the N-Flag on a received Prefix-SID if the 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). prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6).
The Prefix Attributes Flags sub-TLV [RFC7794] also defines the N and The Prefix Attribute Flags sub-TLV [RFC7794] also defines the N-Flag
R flags and with the same semantics of the equivalent flags defined and R-Flag and with the same semantics of the equivalent flags
in this document. Whenever the Prefix Attributes Flags sub-TLV is defined in this document. Whenever the Prefix Attribute Flags sub-
present for a given prefix the values of the N and R flags advertised TLV is present for a given prefix, the values of the N-Flag and
in that sub-TLV MUST be used and the values in a corresponding Prefix R-Flag advertised in that sub-TLV MUST be used, and the values in a
SID sub-TLV (if present) MUST be ignored. corresponding Prefix-SID sub-TLV (if present) MUST be ignored.
2.1.1.3. E and P Flags 2.1.1.3. E-Flag and P-Flag
The following behavior is associated with the settings of the E and P The following behavior is associated with the settings of the E-Flag
flags: and P-Flag:
o If the P-flag is not set then any upstream neighbor of the Prefix- * If the P-Flag is not set, then any upstream neighbor of the
SID originator MUST pop the Prefix-SID. This is equivalent to the Prefix-SID originator MUST pop the Prefix-SID. This is equivalent
penultimate hop popping mechanism used in the MPLS dataplane which to the "penultimate hop-popping" mechanism used in the MPLS data
improves performance of the ultimate hop. MPLS EXP bits of the plane, which improves performance of the ultimate hop. MPLS EXP
Prefix-SID are not preserved to the ultimate hop (the Prefix-SID bits of the Prefix-SID are not preserved to the ultimate hop (the
being removed). If the P-flag is unset the received E-flag is Prefix-SID being removed). If the P-Flag is unset, the received
ignored. E-Flag is ignored.
o If the P-flag is set then: * If the P-Flag is set, then:
* If the E-flag is not set then any upstream neighbor of the - 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 Prefix-SID originator MUST keep the Prefix-SID on top of the
stack. This is useful when, e.g., the originator of the stack. This is useful when, e.g., the originator of the
Prefix-SID must stitch the incoming packet into a continuing Prefix-SID must stitch the incoming packet into a continuing
MPLS LSP to the final destination. This could occur at an MPLS LSP to the final destination. This could occur at an
inter-area border router (prefix propagation from one area to inter-area border router (prefix propagation from one area to
another) or at an inter-domain border router (prefix another) or at an interdomain border router (prefix propagation
propagation from one domain to another). from one domain to another).
* If the E-flag is set then any upstream neighbor of the Prefix- - If the E-Flag is set, then any upstream neighbor of the Prefix-
SID originator MUST replace the PrefixSID with a Prefix-SID SID originator MUST replace the Prefix-SID with a Prefix-SID
having an Explicit-NULL value. This is useful, e.g., when the having an Explicit NULL value. This is useful, e.g., when the
originator of the Prefix-SID is the final destination for the originator of the Prefix-SID is the final destination for the
related prefix and the originator wishes to receive the packet related prefix and the originator wishes to receive the packet
with the original EXP bits. with the original EXP bits.
When propagating (either from Level-1 to Level-2 or vice versa) a When propagating (from either Level-1 to Level-2 or Level-2 to Level-
reachability advertisement originated by another IS-IS speaker, the 1) a reachability advertisement originated by another IS-IS speaker,
router MUST set the P-flag and MUST clear the E-flag of the related the router MUST set the P-Flag and MUST clear the E-Flag of the
Prefix-SIDs. related Prefix-SIDs.
2.1.2. Prefix-SID Propagation 2.1.2. Prefix-SID Propagation
The Prefix-SID sub-TLV MUST be included when the associated Prefix The Prefix-SID sub-TLV MUST be included when the associated Prefix
Reachability TLV is propagated across level boundaries. Reachability TLV is propagated across level boundaries.
The level-1-2 router that propagates the Prefix-SID sub-TLV between The Level-1-2 router that propagates the Prefix-SID sub-TLV between
levels maintains the content (flags and SID) except as noted in levels maintains the content (flags and SID), except as noted in
Section 2.1.1.2 and Section 2.1.1.3. Sections 2.1.1.2 and 2.1.1.3.
2.2. Adjacency Segment Identifier 2.2. Adjacency Segment Identifier
A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier
TLV (Adj-SID sub-TLV). (Adj-SID) sub-TLV.
The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment
Routing IGP-Adjacency-SID as defined in [RFC8402] with flags and Routing IGP-Adjacency-SID as defined in [RFC8402] with flags and
fields that may be used, in future extensions of Segment Routing, for fields that may be used, in future extensions of Segment Routing, for
carrying other types of SIDs. carrying other types of SIDs.
IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs IS-IS adjacencies are advertised using one of the IS Neighbor TLVs
below: below:
TLV-22 (Extended IS reachability)[RFC5305] TLV-22 (Extended IS reachability) [RFC5305]
TLV-222 (Multitopology IS)[RFC5120] TLV-222 (MT-ISN) [RFC5120]
TLV-23 (IS Neighbor Attribute)[RFC5311] TLV-23 (IS Neighbor Attribute) [RFC5311]
TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311] TLV-223 (MT IS Neighbor Attribute) [RFC5311]
TLV-141 (inter-AS reachability information)[RFC5316]
Multiple Adj-SID sub-TLVs MAY be associated with a single IS- TLV-141 (inter-AS reachability information) [RFC5316]
neighbor.
Multiple Adj-SID sub-TLVs MAY be associated with a single IS
Neighbor.
2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV
The following format is defined for the Adj-SID sub-TLV: The following format is defined for the Adj-SID sub-TLV:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Weight | | Type | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Type: 31 Type: 31
Length: 5 or 6 depending on size of the SID Length: 5 or 6 depending on size of the SID
Flags: 1 octet field of following flags: Flags: 1-octet field of the following flags:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|F|B|V|L|S|P| | |F|B|V|L|S|P| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
where: where:
F-Flag: Address-Family flag. If unset, then the Adj-SID is F-Flag: Address-Family Flag. If unset, then the Adj-SID
used when forwarding IPv4 encapsulated traffic to the neighbor. is used when forwarding IPv4-encapsulated
If set then the Adj-SID is used when forwarding IPv6 traffic to the neighbor. If set, then the Adj-
encapsulated traffic to the neighbor. SID is used when forwarding IPv6-encapsulated
traffic to the neighbor.
B-Flag: Backup flag. If set, the Adj-SID is eligible for B-Flag: Backup Flag. If set, the Adj-SID is eligible
protection (e.g.: using IPFRR or MPLS-FRR) as described in for protection (e.g., using IP Fast Reroute
[RFC8402]. (IPFRR) or MPLS Fast Reroute (MPLS-FRR)) as
described in [RFC8402].
V-Flag: Value flag. If set, then the Adj-SID carries a value. V-Flag: Value Flag. If set, then the Adj-SID carries a
By default the flag is SET. value. By default, the flag is SET.
L-Flag: Local Flag. If set, then the value/index carried by L-Flag: Local Flag. If set, then the value/index
the Adj-SID has local significance. By default the flag is carried by the Adj-SID has local significance.
SET. By default, the flag is SET.
S-Flag. Set flag. When set, the S-Flag indicates that the S-Flag: Set Flag. When set, the S-Flag indicates that
Adj-SID refers to a set of adjacencies (and therefore MAY be the Adj-SID refers to a set of adjacencies (and
assigned to other adjacencies as well). therefore MAY be assigned to other adjacencies
as well).
P-Flag. Persistent flag. When set, the P-Flag indicates that P-Flag: Persistent Flag. When set, the P-Flag indicates
the Adj-SID is persistently allocated, i.e., the Adj-SID value that the Adj-SID is persistently allocated,
remains consistent across router restart and/or interface flap. 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 Other bits: MUST be zero when originated and ignored
received. when received.
Weight: 1 octet. The value represents the weight of the Adj-SID Weight: 1 octet. The value represents the weight of the Adj-SID
for the purpose of load balancing. The use of the weight is for the purpose of load balancing. The use of the weight
defined in [RFC8402]. is defined in [RFC8402].
SID/Index/Label as defined in Section 2.1.1.1. SID/Index/Label as defined in Section 2.1.1.1.
An SR capable router MAY allocate an Adj-SID for each of its An SR-capable router MAY allocate an Adj-SID for each of its
adjacencies adjacencies.
An SR capable router MAY allocate more than one Adj-SID to an An SR-capable router MAY allocate more than one Adj-SID to an
adjacency. adjacency.
An SR capable router MAY allocate the same Adj-SID to different An SR-capable router MAY allocate the same Adj-SID to different
adjacencies. adjacencies.
When the P-flag is not set, the Adj-SID MAY be persistent. When 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. the P-Flag is set, the Adj-SID MUST be persistent.
Examples of use of the Adj-SID sub-TLV are described in [RFC8402]. Examples of Adj-SID sub-TLV use are described in [RFC8402].
The F-flag is used in order for the router to advertise the The F-Flag is used in order for the router to advertise the
outgoing encapsulation of the adjacency the Adj-SID is attached outgoing encapsulation of the adjacency the Adj-SID is attached
to. to.
2.2.2. Adjacency Segment Identifiers in LANs 2.2.2. Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV
In LAN subnetworks, the Designated Intermediate System (DIS) is In LAN subnetworks, the Designated Intermediate System (DIS) is
elected and originates the Pseudonode-LSP (PN-LSP) including all elected and originates the Pseudonode LSP (PN LSP) including all
neighbors of the DIS. neighbors of the DIS.
When Segment Routing is used, each router in the LAN MAY advertise 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 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 only advertises one adjacency to the DIS (and doesn't advertise any
other adjacency), each router advertises the set of Adj-SIDs (for 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 each of its neighbors) inside a newly defined sub-TLV that is a part
advertising the adjacency to the DIS (e.g.: TLV-22). of the TLV advertising the adjacency to the DIS (e.g., TLV-22).
The following new sub-TLV is defined: LAN-Adj-SID containing the set The following new sub-TLV is defined: LAN Adjacency Segment
of Adj-SIDs the router assigned to each of its LAN neighbors. 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: The format of the LAN-Adj-SID sub-TLV is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Weight | | Type | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 28 skipping to change at line 509
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Type: 32 Type: 32
Length: variable. Length: Variable
Flags: 1 octet field of following flags: Flags: 1-octet field of the following flags:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|F|B|V|L|S|P| | |F|B|V|L|S|P| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
where F, B, V, L, S and P flags are defined in Section 2.2.1. where the F-Flag, B-Flag, V-Flag, L-Flag, S-Flag, and
Other bits: MUST be zero when originated and ignored when P-Flag are defined in Section 2.2.1.
received.
Weight: 1 octet. The value represents the weight of the Adj-SID Other bits: MUST be zero when originated and ignored when
for the purpose of load balancing. The use of the weight is received.
defined in [RFC8402].
Neighbor System-ID: IS-IS System-ID of length "ID Length" as Weight: 1 octet. The value represents the weight of the Adj-
defined in [ISO10589]. 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. Neighbor System-ID: IS-IS System-ID of length "ID Length" as
defined in [ISO10589].
SID/Index/Label: As defined in Section 2.1.1.1.
Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Multiple LAN-Adj-SID sub-TLVs MAY be encoded.
Note that this sub-TLV MUST NOT appear in TLV 141. 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) In case TLV-22, TLV-23, TLV-222, or TLV-223 (reporting the adjacency
can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple to the DIS) can't contain the whole set of LAN-Adj-SID sub-TLVs,
advertisements of the adjacency to the DIS MUST be used and all multiple advertisements of the adjacency to the DIS MUST be used, and
advertisements MUST have the same metric. all advertisements MUST have the same metric.
Each router within the level, by receiving the DIS PN LSP as well as 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 the non-PN LSP of each router in the LAN, is capable of
reconstructing the LAN topology as well as the set of Adj-SIDs each reconstructing the LAN topology as well as the set of Adj-SIDs each
router uses for each of its neighbors. router uses for each of its neighbors.
2.3. SID/Label Sub-TLV 2.3. SID/Label Sub-TLV
The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs
defined in this document: defined in this document:
SR-Capabilities Sub-TLV (Section 3.1) SR-Capabilities sub-TLV (Section 3.1)
SR Local Block Sub-TLV (Section 3.3) SR Local Block sub-TLV (Section 3.3)
SID/Label Binding TLV (Section 2.4) SID/Label Binding TLV (Section 2.4)
Multi-Topology SID/Label Binding TLV (Section 2.5) Multi-Topology SID/Label Binding TLV (Section 2.5)
Note that the code point used in all of the above cases is the SID/ Note that the codepoint used in all of the above cases is the SID/
Label Sub-TLV code point specified in the new "sub-TLVs for TLV 149 Label sub-TLV codepoint specified in the new "sub-TLVs for TLV 149
and 150" registry created by this document. and 150" registry created by this document.
The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label The SID/Label sub-TLV contains a SID or an MPLS label. The SID/Label
sub-TLV has the following format: sub-TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label (variable) | | SID/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Type: 1 Type: 1
Length: 3 or 4 Length: 3 or 4
SID/Label: if length is set to 3 then the 20 rightmost bits
represent a MPLS label. If length is set to 4 then the value is a SID/Label: If the length is set to 3, then the 20 rightmost bits
32 bit index represent an MPLS label. If the length is set to 4,
then the value is a 32-bit index.
2.4. SID/Label Binding TLV 2.4. SID/Label Binding TLV
The SID/Label Binding TLV MAY be originated by any router in an IS-IS 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. domain. There are multiple uses of the SID/Label Binding TLV.
The SID/Label Binding TLV may be used to advertise prefixes to SID/ The SID/Label Binding TLV may be used to advertise prefixes to SID/
Label mappings. This functionality is called the Segment Routing Label mappings. This functionality is called the Segment Routing
Mapping Server (SRMS). The behavior of the SRMS is defined in 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 The SID/Label Binding TLV may also be used to advertise a Mirror SID
to advertise the ability to process traffic originally destined to indicating the ability of a node to process traffic originally
another IGP node. This behavior is defined in [RFC8402]. destined to another IGP node. This behavior is defined in [RFC8402].
The SID/Label Binding TLV has the following format: The SID/Label Binding TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range | Prefix Length | Prefix | | Range | Prefix Length | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Prefix (continued, variable) // // Prefix (continued, variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) | | Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SID/Label Binding TLV format where:
o Type: 149 Type: 149
o Length: variable. Length: Variable
o 1 octet of flags Flags: 1 octet
o 1 octet of RESERVED (SHOULD be transmitted as 0 and MUST be RESERVED: 1 octet (SHOULD be transmitted as 0 and MUST be
ignored on receipt) ignored on receipt)
o 2 octets of Range Range: 2 octets
o 1 octet of Prefix Length Prefix Length: 1 octet
o 0-16 octets of Prefix Prefix: 0-16 octets
o sub-TLVs, where each sub-TLV consists of a sequence of:
* 1 octet of sub-TLV type sub-TLVs, where each sub-TLV consists of a sequence of:
* 1 octet of length of the value field of the sub-TLV - 1 octet of sub-TLV type
* 0-243 octets of value - 1 octet of length of the value field of the sub-TLV
- 0-243 octets of value
2.4.1. Flags 2.4.1. Flags
Flags: 1 octet field of following flags: Flags: 1-octet field of the following flags:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|F|M|S|D|A| | |F|M|S|D|A| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
where: where:
F-Flag: Address Family flag. If unset, then the Prefix carries an F-Flag: Address-Family Flag. If unset, then the prefix carries
IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix. an IPv4 prefix. If set, then the prefix carries an IPv6
prefix.
M-Flag: Mirror Context flag. Set if the advertised SID M-Flag: Mirror Context Flag. Set if the advertised SID
corresponds to a mirrored context. The use of a mirrored context corresponds to a mirrored context. The use of a mirrored
is described in [RFC8402]. context is described in [RFC8402].
S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded
the entire routing domain. If the S flag is not set, the SID/ across the entire routing domain. If the S-Flag is not
Label Binding TLV MUST NOT be leaked between levels. This bit set, the SID/Label Binding TLV MUST NOT be leaked between
MUST NOT be altered during the TLV leaking. 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 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 Level-1, the D-Flag MUST be set. Otherwise, this flag
clear. SID/Label Binding TLVs with the D-Flag set MUST NOT be MUST be clear. SID/Label Binding TLVs with the D-Flag
leaked from level-1 to level-2. This is to prevent TLV looping set MUST NOT be leaked from Level-1 to Level-2. This is
across levels. to prevent TLV looping across levels.
A-Flag: Attached flag. The originator of the SID/Label Binding 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 TLV MAY set the A bit in order to signal that the
SIDs advertised in the SID/Label Binding TLV are directly prefixes and SIDs advertised in the SID/Label Binding TLV
connected to their originators. The mechanisms through which the are directly connected to their originators. The
originator of the SID/Label Binding TLV can figure out if a prefix mechanisms through which the originator of the SID/Label
is attached or not are outside the scope of this document (e.g.: Binding TLV can figure out if a prefix is attached or not
through explicit configuration). If the Binding TLV is leaked to are outside the scope of this document (e.g., through
other areas/levels the A-flag MUST be cleared. 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 An implementation may decide not to honor the S-Flag in order to
to leak Binding TLV's between levels (for policy reasons). not leak Binding TLVs between levels (for policy reasons).
Other bits: MUST be zero when originated and ignored when Other bits: MUST be zero when originated and ignored when
received. received.
2.4.2. Range 2.4.2. Range
The 'Range' field provides the ability to specify a range of The 'Range' field provides the ability to specify a range of
addresses and their associated Prefix SIDs. This advertisement addresses and their associated Prefix-SIDs. This advertisement
supports the SRMS functionality. It is essentially a compression supports the SRMS functionality. It is essentially a compression
scheme to distribute a continuous Prefix and their continuous, scheme to distribute a continuous prefix and their continuous,
corresponding SID/Label Block. If a single SID is advertised then corresponding SID/Label Block. If a single SID is advertised, then
the range field MUST be set to one. For range advertisements > 1, 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 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 be mapped into a Prefix-SID. In either case, the prefix is the first
address to which a SID is to be assigned. address to which a SID is to be assigned.
2.4.3. Prefix Length, Prefix 2.4.3. Prefix Length, Prefix
The 'Prefix' represents the Forwarding equivalence class at the tail- The 'Prefix' represents the Forwarding Equivalence Class at the tail
end of the advertised path. The 'Prefix' does not need to correspond end of the advertised path. The 'Prefix' does not need to correspond
to a routable prefix of the originating node. to a routable prefix of the originating node.
The 'Prefix Length' field contains the length of the prefix in bits. 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 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 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 4 octets for prefix 16, 3 octets for prefix length 17 up to 24, 4 octets for prefix
length 25 up to 32, ...., 16 octets for prefix length 113 up to 128). length 25 up to 32, ...., and 16 octets for prefix length 113 up to
128).
2.4.4. Mapping Server Prefix-SID 2.4.4. Mapping Server Prefix-SID
The Prefix-SID sub-TLV is defined in Section 2.1 and contains the 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 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 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 clear. The Prefix-SID sub-TLV MUST NOT be present when
the M-flag is set. the M-Flag is set.
2.4.4.1. Prefix-SID Flags 2.4.4.1. Prefix-SID Flags
The Prefix-SID flags are defined in Section 2.1. The Mapping Server 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 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 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 (IPv4) or 128 (IPv6) and when the prefix represents a node. The
mechanisms through which the operator defines that a prefix mechanisms through which the operator defines that a prefix
represents a node are outside the scope of this document (typically represents a node are outside the scope of this document (typically
it will be through configuration). it will be through configuration).
The other flags defined in Section 2.1 are not used by the Mapping The other flags defined in Section 2.1 are not used by the Mapping
Server and MUST be ignored at reception. Server and MUST be ignored at reception.
2.4.4.2. PHP Behavior when using Mapping Server Advertisements 2.4.4.2. PHP Behavior when Using Mapping Server Advertisements
As the mapping server does not specify the originator of a prefix As the Mapping Server does not specify the originator of a prefix
advertisement it is not possible to determine PHP behavior solely advertisement, it is not possible to determine PHP behavior solely
based on the Mapping Server Advertisement. However, if additional based on the Mapping Server Advertisement. However, if additional
information is available PHP behavior may safely be done. The information is available, PHP behavior may safely be done. The
required information consists of: required information consists of:
o A prefix reachability advertisement for the prefix has been * A prefix reachability advertisement for the prefix has been
received which includes the Prefix Attribute Flags sub-TLV received, which includes the Prefix Attribute Flags sub-TLV
[RFC7794]. [RFC7794].
o X and R flags are both set to 0 in the Prefix Attribute Flags sub- * X-Flag and R-Flag are both set to 0 in the Prefix Attribute Flags
TLV. sub-TLV.
In the absence of an Prefix Attribute Flags sub-TLV [RFC7794] the A In the absence of a Prefix Attribute Flags sub-TLV [RFC7794], the
flag in the binding TLV indicates that the originator of a prefix A-Flag in the Binding TLV indicates that the originator of a prefix
reachability advertisement is directly connected to the prefix and reachability advertisement is directly connected to the prefix; thus,
thus PHP MUST be done by the neighbors of the router originating the PHP MUST be done by the neighbors of the router originating the
prefix reachability advertisement. Note that A-flag is only valid in prefix reachability advertisement. Note that the A-Flag is only
the original area in which the Binding TLV is advertised. valid in the original area in which the Binding TLV is advertised.
2.4.4.3. Prefix-SID Algorithm 2.4.4.3. Prefix-SID Algorithm
The algorithm field contains the identifier of the algorithm The Algorithm field contains the identifier of the algorithm
associated with the SIDs for the prefix(es) in the range. Use of the associated with the SIDs for the prefix(es) in the range. Use of the
algorithm field is described in Section 2.1. Algorithm field is described in Section 2.1.
2.4.5. SID/Label Sub-TLV 2.4.5. SID/Label Sub-TLV
The SID/Label sub-TLV (Type: 1) contains the SID/Label value as 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 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. TLV when the M-Flag is set in the Flags field of the parent TLV.
2.4.6. Example Encodings 2.4.6. Example Encodings
Example 1: if the following IPv4 router addresses (loopback Example 1: If the following IPv4 router addresses (loopback
addresses) need to be mapped into the corresponding Prefix SID addresses) need to be mapped into the corresponding Prefix-SID
indexes. 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
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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |0|0|0|0|0| | RESERVED | | Type | Length |0|0|0|0|0| | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 4 | 32 | 192 | | Range = 4 | 32 | 192 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2 | 1 |Prefix-SID Type| | 0 | 2 | 1 |Prefix-SID Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV Length| Flags | Algorithm | | | Sub-TLV Length| Flags | Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example-2: If the following IPv4 prefixes need to be mapped into the Example 2: If the following IPv4 prefixes need to be mapped into the
corresponding Prefix-SID indexes: corresponding Prefix-SID indexes, then:
10.1.1/24, Prefix-SID: Index 51 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.2/24, Prefix-SID: Index 52
10.1.4/24, Prefix-SID: Index 54
10.1.5/24, Prefix-SID: Index 55 10.1.3/24, Prefix-SID: Index 53
10.1.6/24, Prefix-SID: Index 56
10.1.7/24, Prefix-SID: Index 57 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |0|0|0|0|0| | RESERVED | | Type | Length |0|0|0|0|0| | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 7 | 24 | 10 | | Range = 7 | 24 | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 1 |Prefix-SID Type| sub-TLV Length| | 1 | 1 |Prefix-SID Type| Sub-TLV Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | | | Flags | Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 51 | | 51 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example-3: If the following IPv6 prefixes need to be mapped into the Example 3: If the following IPv6 prefixes need to be mapped into the
corresponding Prefix-SID indexes: corresponding Prefix-SID 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
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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |1|0|0|0|0| | RESERVED | | Type | Length |1|0|0|0|0| | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 4 | 48 | 0x20 | | Range = 4 | 48 | 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x0d | 0xb8 | 0x00 | | 0x01 | 0x0d | 0xb8 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 |Prefix-SID Type| sub-TLV Length| Flags | | 0x01 |Prefix-SID Type| Sub-TLV Length| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | 0 | | Algorithm | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 151 | | 151 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
It is not expected that a network operator will be able to keep fully It is not expected that a network operator will be able to keep fully
continuous Prefix / SID/Index mappings. In order to support continuous Prefix/SID/Index mappings. In order to support
noncontinuous mapping ranges an implementation MAY generate several noncontinuous mapping ranges, an implementation MAY generate several
instances of Binding TLVs. instances of Binding TLVs.
For example if a router wants to advertise the following ranges: For example, if a router wants to advertise the following ranges:
Range 16: { 192.0.2.1-15, Index 1-15 } Range 16: { 192.0.2.1-15, Index 1-15 }
Range 6: { 192.0.2.22-27, Index 22-27 } Range 6: { 192.0.2.22-27, Index 22-27 }
Range 41: { 192.0.2.44-84, Index 80-120 } Range 41: { 192.0.2.44-84, Index 80-120 }
A router would need to advertise three instances of the Binding TLV. a router would need to advertise three instances of the Binding TLV.
2.5. Multi-Topology SID/Label Binding TLV 2.5. Multi-Topology SID/Label Binding TLV
The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS The Multi-Topology SID/Label Binding TLV allows the support of Multi-
as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV Topology IS-IS (M-ISIS) as defined in [RFC5120]. The Multi-Topology
has the same format as the SID/Label Binding TLV defined in SID/Label Binding TLV has the same format as the SID/Label Binding
Section 2.4 with the difference consisting of a Multitopology TLV defined in Section 2.4 with the difference consisting of a Multi-
Identifier (MTID) as defined here below: topology Identifier (MT ID) as defined here below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MTID | | Type | Length | MT ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED | Range | | Flags | RESERVED | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix (variable) // | Prefix Length | Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) | | Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Multi-Topology SID/Label Binding TLV format
where: where:
Type: 150 Type: 150
Length: variable Length: Variable
MTID is the multitopology identifier defined as: MT ID is the Multi-topology Identifier defined as:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESVD | MTID | | RESVD | MT ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RESVD: reserved bits. MUST be reset on transmission and RESVD: Reserved bits. MUST be reset on transmission and
ignored on receive. ignored on receive.
MTID: a 12-bit field containing the non-zero ID of the topology MT ID: A 12-bit field containing the non-zero ID of the
being announced. The TLV MUST be ignored if the ID is zero. topology being announced. The TLV MUST be ignored if
This is to ensure the consistent view of the standard unicast the ID is zero. This is to ensure the consistent view
topology. of the standard unicast topology.
The other fields and Sub-TLVs are defined in Section 2.4. The other fields and sub-TLVs are defined in Section 2.4.
3. Router Capabilities 3. Router Capabilities
This section defines sub-TLVs which are inserted into the IS-IS This section defines sub-TLVs that are inserted into the IS-IS Router
Router Capability TLV-242 that is defined in [RFC7981]. Capability that is defined in [RFC7981].
3.1. SR-Capabilities Sub-TLV 3.1. SR-Capabilities Sub-TLV
Segment Routing requires each router to advertise its SR data-plane Segment Routing requires each router to advertise its SR data plane
capability and the range of MPLS label values it uses for Segment capability and the range of MPLS label values it uses for Segment
Routing in the case where global SIDs are allocated (i.e., global Routing in the case where global SIDs are allocated (i.e., global
indexes). Data-plane capabilities and label ranges are advertised indexes). Data plane capabilities and label ranges are advertised
using the newly defined SR-Capabilities sub-TLV. using the newly defined SR-Capabilities sub-TLV.
The Router Capability TLV specifies flags that control its The Router Capability TLV specifies flags that control its
advertisement. The SR Capabilities sub-TLV MUST be propagated advertisement. The SR-Capabilities sub-TLV MUST be propagated
throughout the level and MUST NOT be advertised across level throughout the level and MUST NOT be advertised across level
boundaries. Therefore Router Capability TLV distribution flags are boundaries. Therefore, Router Capability TLV distribution flags are
set accordingly, i.e., the S flag in the Router Capability TLV set accordingly, i.e., the S-Flag in the Router Capability TLV
[RFC7981] MUST be unset. [RFC7981] MUST be unset.
The SR Capabilities sub-TLV has following format: The SR-Capabilities sub-TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | | Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range | | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID/Label Sub-TLV (variable) // // SID/Label Sub-TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 Type: 2
Length: variable. Length: Variable
Flags: 1 octet of flags. The following are defined: Flags: 1 octet of flags. The following are defined:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|I|V| | |I|V| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
where: where:
I-Flag: MPLS IPv4 flag. If set, then the router is capable of I-Flag: MPLS IPv4 Flag. If set, then the router is capable of
processing SR MPLS encapsulated IPv4 packets on all interfaces. processing SR-MPLS-encapsulated IPv4 packets on all
interfaces.
V-Flag: MPLS IPv6 flag. If set, then the router is capable of V-Flag: MPLS IPv6 Flag. If set, then the router is capable of
processing SR MPLS encapsulated IPv6 packets on all interfaces. processing SR-MPLS-encapsulated IPv6 packets on all
interfaces.
One or more SRGB Descriptor entries, each of which have the One or more Segment Routing Global Block (SRGB) Descriptor
following format: entries, each of which have the following format:
Range: 3 octets. Range: 3 octets
SID/Label sub-TLV (as defined in Section 2.3). SID/Label sub-TLV: MPLS label as defined in Section 2.3
SID/Label sub-TLV contains the first value of the SRGB while the The SID/Label sub-TLV contains the first value of the SRGB while the
range contains the number of SRGB elements. The range value MUST be range contains the number of SRGB elements. The range value MUST be
higher than 0. higher than 0.
The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number The SR-Capabilities sub-TLV MAY be advertised in an LSP of any
but a router MUST NOT advertise more than one SR-Capabilities sub- number, but a router MUST NOT advertise more than one SR-Capabilities
TLV. A router receiving multiple SR-Capabilities sub-TLVs from the sub-TLV. A router receiving multiple SR-Capabilities sub-TLVs from
same originator SHOULD select the first advertisement in the lowest the same originator SHOULD select the first advertisement in the
numbered LSP. lowest-numbered LSP.
When multiple SRGB Descriptors are advertised the entries define an When multiple SRGB Descriptors are advertised, the entries define an
ordered set of ranges on which a SID index is to be applied. For ordered set of ranges on which a SID index is to be applied. For
this reason changing the order in which the descriptors are this reason, changing the order in which the descriptors are
advertised will have a disruptive effect on forwarding. advertised will have a disruptive effect on forwarding.
When a router adds a new SRGB Descriptor to an existing SR- When a router adds a new SRGB Descriptor to an existing SR-
Capabilities sub-TLV the new Descriptor SHOULD add the newly Capabilities sub-TLV, the new descriptor SHOULD add the newly
configured block at the end of the sub-TLV and SHOULD NOT change the configured block at the end of the sub-TLV and SHOULD NOT change the
order of previously advertised blocks. Changing the order of the order of previously advertised blocks. Changing the order of the
advertised descriptors will create label churn in the FIB and advertised descriptors will create label churn in the FIB and black
blackhole / misdirect some traffic during the IGP convergence. In hole / misdirect some traffic during the IGP convergence. In
particular, if a range which is not the last is extended it's particular, if a range that is not the last is extended, it's
preferable to add a new range rather than extending the previously preferable to add a new range rather than extending the previously
advertised range. advertised range.
The originating router MUST ensure the order is unchanged after a The originating router MUST ensure the order is unchanged after a
graceful restart (using checkpointing, non-volatile storage or any graceful restart (using checkpointing, non-volatile storage, or any
other mechanism). other mechanism).
The originating router MUST NOT advertise overlapping ranges. The originating router MUST NOT advertise overlapping ranges.
When a router receives multiple overlapping ranges, it MUST conform When a router receives multiple overlapping ranges, it MUST conform
to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. to the procedures defined in [RFC8660].
Here follows an example of advertisement of multiple ranges: Here follows an example of the advertisement of multiple ranges:
The originating router advertises the following ranges:
The originating router advertises following ranges:
SR-Cap: range: 100, SID value: 100 SR-Cap: range: 100, SID value: 100
SR-Cap: range: 100, SID value: 1000 SR-Cap: range: 100, SID value: 1000
SR-Cap: range: 100, SID value: 500 SR-Cap: range: 100, SID value: 500
The receiving routers concatenate the ranges in the received The receiving routers concatenate the ranges in the received order
order and build the SRGB as follows: and build the SRGB as follows:
SRGB = [100, 199] SRGB = [100, 199]
[1000, 1099] [1000, 1099]
[500, 599] [500, 599]
The indexes span multiple ranges: The indexes span multiple ranges:
index=0 means label 100 index 0 means label 100
... ...
index 99 means label 199 index 99 means label 199
index 100 means label 1000 index 100 means label 1000
index 199 means label 1099 index 199 means label 1099
... ...
index 200 means label 500 index 200 means label 500
... ...
3.2. SR-Algorithm Sub-TLV 3.2. SR-Algorithm Sub-TLV
The router may use various algorithms when calculating reachability The router may use various algorithms when calculating reachability
to other nodes or to prefixes attached to these nodes. Examples of to other nodes or to prefixes attached to these nodes. Examples of
these algorithms are metric based Shortest Path First (SPF), various these algorithms are metric-based SPF, various sorts of Constrained
sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the SPF, etc. The SR-Algorithm sub-TLV allows the router to advertise
router to advertise the algorithms that the router is currently the algorithms that the router is currently using. Algorithm values
using. Algorithm values are defined in the "IGP Algorithm Type" are defined in the "IGP Algorithm Type" registry defined in
registry defined in [I-D.ietf-ospf-segment-routing-extensions]. The [RFC8665]. The following values have been defined:
following values have been defined:
0: Shortest Path First (SPF) algorithm based on link metric. This 0: SPF algorithm based on link metric. This is the well-known
is the well-known shortest path algorithm as computed by the IS-IS shortest path algorithm as computed by the IS-IS Decision
Decision process. Consistent with the deployed practice for link- Process. Consistent with the deployed practice for link-state
state protocols, algorithm 0 permits any node to overwrite the SPF protocols, algorithm 0 permits any node to overwrite the SPF
path with a different path based on local policy. path with a different path based on local policy.
1: Strict Shortest Path First (SPF) algorithm based on link 1: Strict SPF algorithm based on link metric. The algorithm is
metric. The algorithm is identical to algorithm 0 but algorithm 1 identical to algorithm 0, but algorithm 1 requires that all
requires that all nodes along the path will honor the SPF routing nodes along the path will honor the SPF routing decision.
decision. Local policy MUST NOT alter the forwarding decision Local policy MUST NOT alter the forwarding decision computed by
computed by algorithm 1 at the node claiming to support algorithm algorithm 1 at the node claiming to support algorithm 1.
1.
The Router Capability TLV specifies flags that control its The Router Capability TLV specifies flags that control its
advertisement. The SR-Algorithm MUST be propagated throughout the advertisement. The SR-Algorithm MUST be propagated throughout the
level and MUST NOT be advertised across level boundaries. Therefore level and MUST NOT be advertised across level boundaries. Therefore,
Router Capability TLV distribution flags are set accordingly, i.e., Router Capability TLV distribution flags are set accordingly, i.e.,
the S flag MUST be unset. the S-Flag MUST be unset.
The SR-Algorithm sub-TLV is optional. It MUST NOT be advertsied more The SR-Algorithm sub-TLV is optional. It MUST NOT be advertised more
than once at a given level. A router receiving multiple SR-Algorithm than once at a given level. A router receiving multiple SR-Algorithm
sub-TLVs from the same originator SHOULD select the first sub-TLVs from the same originator SHOULD select the first
advertisement in the lowest numbered LSP. advertisement in the lowest-numbered LSP.
When the originating router does not advertise the SR-Algorithm sub- When the originating router does not advertise the SR-Algorithm sub-
TLV, this implies that the only algorithm supported by routers TLV, it implies that algorithm 0 is the only algorithm supported by
supporting the extensions defined in this document is Algorithm 0. the routers that support the extensions defined in this document.
When the originating router does advertise the SR-Algorithm sub-TLV, When the originating router does advertise the SR-Algorithm sub-TLV,
then algorithm 0 MUST be present while non-zero algorithms MAY be then algorithm 0 MUST be present while non-zero algorithms MAY be
present. present.
The SR-Algorithm sub-TLV has the following format: The SR-Algorithm sub-TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Type: 19 Type: 19
Length: variable. Length: Variable
Algorithm: 1 octet of algorithm Algorithm: 1 octet of algorithm
3.3. SR Local Block Sub-TLV 3.3. SR Local Block Sub-TLV
The SR Local Block (SRLB) Sub-TLV contains the range of labels the The SR Local Block (SRLB) sub-TLV contains the range of labels the
node has reserved for local SIDs. Local SIDs are used, e.g., for node has reserved for Local SIDs. Local SIDs are used, e.g., for
Adjacency-SIDs, and may also be allocated by components other than Adj-SIDs, and may also be allocated by components other than the IS-
the IS-IS protocol. As an example, an application or a controller IS protocol. As an example, an application or a controller may
may instruct the router to allocate a specific local SID. Therefore, instruct the router to allocate a specific Local SID. Therefore, in
in order for such applications or controllers to know what are the order for such applications or controllers to know what Local SIDs
local SIDs available in the router, it is required that the router are available in the router, it is required that the router
advertises its SRLB. advertises its SRLB.
The SRLB Sub-TLV is used for this purpose and has following format: The SRLB sub-TLV is used for this purpose and has following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | | Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range | | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID/Label Sub-TLV (variable) // // SID/Label Sub-TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 22 Type: 22
Length: variable. Length: Variable
Flags: 1 octet of flags. None are defined at this stage. Flags: 1 octet of flags. None are defined at this stage.
One or more SRLB Descriptor entries, each of which have the One or more SRLB Descriptor entries, each of which have the
following format: following format:
Range: 3 octets. Range: 3 octets
SID/Label sub-TLV (as defined in Section 2.3). SID/Label sub-TLV: MPLS label as defined in Section 2.3
SID/Label sub-TLV contains the first value of the SRLB while the The SID/Label sub-TLV contains the first value of the SRLB while the
range contains the number of SRLB elements. The range value MUST be range contains the number of SRLB elements. The range value MUST be
higher than 0. higher than 0.
The SRLB sub-TLV MAY be advertised in an LSP of any number but a 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 router MUST NOT advertise more than one SRLB sub-TLV. A router
receiving multiple SRLB sub-TLVs, from the same originator, SHOULD receiving multiple SRLB sub-TLVs, from the same originator, SHOULD
select the first advertisement in the lowest numbered LSP. select the first advertisement in the lowest-numbered LSP.
The originating router MUST NOT advertise overlapping ranges. The originating router MUST NOT advertise overlapping ranges.
When a router receives multiple overlapping ranges, it MUST conform When a router receives multiple overlapping ranges, it MUST conform
to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. to the procedures defined in [RFC8660].
It is important to note that each time a SID from the SRLB is It is important to note that each time a SID from the SRLB is
allocated, it should also be reported to all components (e.g.: allocated, it should also be reported to all components (e.g.,
controller or applications) in order for these components to have an controller or applications) in order for these components to have an
up-to-date view of the current SRLB allocation and in order to avoid up-to-date view of the current SRLB allocation and to avoid collision
collision between allocation instructions. between allocation instructions.
Within the context of IS-IS, the reporting of local SIDs is done Within the context of IS-IS, the reporting of Local SIDs is done
through IS-IS Sub-TLVs such as the Adjacency-SID. However, the through IS-IS sub-TLVs such as the Adj-SID. However, the reporting
reporting of allocated local SIDs may also be done through other of allocated Local SIDs may also be done through other means and
means and protocols which are outside the scope of this document. protocols that are outside the scope of this document.
A router advertising the SRLB sub-TLV may also have other label A router advertising the SRLB sub-TLV may also have other label
ranges, outside the SRLB, for its local allocation purposes which are ranges, outside the SRLB, for its local allocation purposes that are
NOT advertised in the SRLB. For example, it is possible that an NOT advertised in the SRLB. For example, it is possible that an Adj-
Adjacency-SID is allocated using a local label not part of the SRLB. SID is allocated using a local label not part of the SRLB.
3.4. SRMS Preference Sub-TLV 3.4. SRMS Preference Sub-TLV
The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used The SRMS Preference sub-TLV is used in order to associate a
in order to associate a preference with SRMS advertisements from a preference with SRMS advertisements from a particular source.
particular source.
The SRMS Preference sub-TLV has following format: The SRMS Preference sub-TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Preference | | Type | Length | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 24 Type: 24
Length: 1. Length: 1
Preference: 1 octet. Unsigned 8 bit SRMS preference. Preference: 1 octet and unsigned 8-bit SRMS preference.
The SRMS Preference sub-TLV MAY be advertised in an LSP of any number The SRMS Preference sub-TLV MAY be advertised in an LSP of any
but a router MUST NOT advertise more than one SRMS Preference sub- number, but a router MUST NOT advertise more than one SRMS Preference
TLV. A router receiving multiple SRMS Preference sub-TLVs, from the sub-TLV. A router receiving multiple SRMS Preference sub-TLVs, from
same originator, SHOULD select the first advertisement in the lowest the same originator, SHOULD select the first advertisement in the
numbered LSP. lowest-numbered LSP.
The use of the SRMS Preference during the SID selection process is The use of the SRMS preference during the SID selection process is
described in [I-D.ietf-spring-segment-routing-ldp-interop] described in [RFC8661].
4. IANA Considerations 4. IANA Considerations
This document requests allocation for the following TLVs and Sub- Per this document, IANA has allocated the following TLVs and sub-
TLVs. TLVs.
4.1. Sub TLVs for Type 22,23,25,141,222, and 223 4.1. Sub-TLVs for Types 22, 23, 25, 141, 222, and 223
This document makes the following registrations in the "sub-TLVs for This document makes the following registrations in the "Sub-TLVs for
TLV 22, 23, 25, 141, 222 and 223" registry. TLV 22, 23, 25, 141, 222, and 223" registry.
Type Description 22 23 25 141 222 223 +------+--------------------+----+----+----+-----+-----+-----+
---- -------------------------------- --- --- --- --- --- --- | Type | Description | 22 | 23 | 25 | 141 | 222 | 223 |
31 Adjacency Segment Identifier y y n y y y +======+====================+====+====+====+=====+=====+=====+
32 LAN Adjacency Segment Identifier y y n y y y | 31 | Adjacency Segment | y | y | n | y | y | y |
| | Identifier | | | | | | |
+------+--------------------+----+----+----+-----+-----+-----+
| 32 | LAN Adjacency | y | y | n | y | y | y |
| | Segment Identifier | | | | | | |
+------+--------------------+----+----+----+-----+-----+-----+
4.2. Sub TLVs for Type 135,235,236 and 237 Table 1
This document makes the following registrations in the "sub-TLVs for 4.2. Sub-TLVs for Types 135, 235, 236, and 237
TLV 135,235,236 and 237" registry.
Type Description 135 235 236 237 This document makes the following registrations in the "Sub-TLVs for
---- ------------------------- --- --- --- --- TLV 135, 235, 236, and 237" registry.
3 Prefix Segment Identifier y y y y
4.3. Sub TLVs for Type 242 +------+---------------------------+-----+-----+-----+-----+
| Type | Description | 135 | 235 | 236 | 237 |
+======+===========================+=====+=====+=====+=====+
| 3 | Prefix Segment Identifier | y | y | y | y |
+------+---------------------------+-----+-----+-----+-----+
This document makes the following registrations in the "sub-TLVs for Table 2
4.3. Sub-TLVs for Type 242
This document makes the following registrations in the "Sub-TLVs for
TLV 242" registry. TLV 242" registry.
Type Description +------+------------------------------------+
---- ----------- | Type | Description |
2 Segment Routing Capability +======+====================================+
19 Segment Routing Algorithm | 2 | Segment Routing Capability |
22 Segment Routing Local Block (SRLB) +------+------------------------------------+
24 Segment Routing Mapping Server Preference | 19 | Segment Routing Algorithm |
(SRMS Preference) +------+------------------------------------+
| 22 | Segment Routing Local Block (SRLB) |
+------+------------------------------------+
| 24 | Segment Routing Mapping Server |
| | Preference (SRMS Preference) |
+------+------------------------------------+
4.4. New TLV Codepoint and Sub-TLV registry Table 3
4.4. New TLV Codepoint and Sub-TLV Registry
This document registers the following TLV: This document registers the following TLV:
Value Name IIH LSP SNP Purge +-------+----------------------------+-----+-----+-----+-------+
----- --------------------------------- --- --- --- ----- | Value | Name | IIH | LSP | SNP | Purge |
149 Segment Identifier/Label Binding n y n n +=======+============================+=====+=====+=====+=======+
150 Multi-Topology Segment Identifier n y n n | 149 | Segment Identifier / Label | n | y | n | n |
/Label Binding | | Binding | | | | |
+-------+----------------------------+-----+-----+-----+-------+
| 150 | Multi-Topology Segment | n | y | n | n |
| | Identifier / Label Binding | | | | |
+-------+----------------------------+-----+-----+-----+-------+
Table 4
This document creates the following sub-TLV Registry: This document creates the following sub-TLV Registry:
Name: sub-TLVs for TLVs 149 and 150 Name: Sub-TLVs for TLVs 149 and 150
Registration Procedure: Expert Review
Type Description Registration Procedure: Expert Review [RFC8126]
---- -----------
0 Reserved +-------+---------------------------+
1 SID/Label | Type | Description |
2 Unassigned +=======+===========================+
3 Prefix SID | 0 | Reserved |
4-255 Unassigned +-------+---------------------------+
| 1 | SID/Label |
+-------+---------------------------+
| 2 | Unassigned |
+-------+---------------------------+
| 3 | Prefix Segment Identifier |
+-------+---------------------------+
| 4-255 | Unassigned |
+-------+---------------------------+
Table 5
5. Security Considerations 5. Security Considerations
With the use of the extensions defined in this document, IS-IS With the use of the extensions defined in this document, IS-IS
carries information which will be used to program the MPLS data plane carries information that will be used to program the MPLS data plane
[RFC3031]. In general, the same types of attacks that can be carried [RFC3031]. In general, the same type of attacks that can be carried
out on the IP/IPv6 control plane can be carried out on the MPLS out on the IP/IPv6 control plane can be carried out on the MPLS
control plane resulting in traffic being misrouted in the respective control plane, resulting in traffic being misrouted in the respective
data planes. However, the latter may be more difficult to detect and data planes. However, the latter may be more difficult to detect and
isolate. isolate.
Existing security extensions as described in [RFC5304] and [RFC5310] Existing security extensions as described in [RFC5304] and [RFC5310]
apply to these segment routing extensions. 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
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] 6. References
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] 6.1. Normative References
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] [ISO10589] International Organization for Standardization,
International Organization for Standardization, "Information technology -- Telecommunications and
"Intermediate system to Intermediate system intra-domain information exchange between systems -- Intermediate
routeing information exchange protocol for use in system to Intermediate system intra-domain routeing
conjunction with the protocol for providing the information exchange protocol for use in conjunction with
connectionless-mode Network Service (ISO 8473)", ISO/ the protocol for providing the connectionless-mode network
IEC 10589:2002, Second Edition, Nov 2002. service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
November 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
skipping to change at page 30, line 39 skipping to change at line 1354
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
8.2. Informative References [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 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>. 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008, DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>. <https://www.rfc-editor.org/info/rfc5308>.
[RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M.
skipping to change at page 31, line 16 skipping to change at line 1397
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <https://www.rfc-editor.org/info/rfc5316>. December 2008, <https://www.rfc-editor.org/info/rfc5316>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>. 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 Authors' Addresses
Stefano Previdi (editor) Stefano Previdi (editor)
Huawei Huawei Technologies
IT Italy
Email: stefano@previdi.net Email: stefano@previdi.net
Les Ginsberg (editor) Les Ginsberg (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
USA United States of America
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Ahmed Bashandy Ahmed Bashandy
Arrcus Arrcus
Email: abashandy.ietf@gmail.com Email: abashandy.ietf@gmail.com
Hannes Gredler Hannes Gredler
RtBrick Inc. RtBrick Inc.
skipping to change at page 32, line 4 skipping to change at line 1487
Ahmed Bashandy Ahmed Bashandy
Arrcus Arrcus
Email: abashandy.ietf@gmail.com Email: abashandy.ietf@gmail.com
Hannes Gredler Hannes Gredler
RtBrick Inc. RtBrick Inc.
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
Bruno Decraene Bruno Decraene
Orange Orange
FR France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
 End of changes. 258 change blocks. 
663 lines changed or deleted 719 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/