draft-ietf-isis-segment-routing-extensions-22.txt   draft-ietf-isis-segment-routing-extensions-23.txt 
IS-IS for IP Internets S. Previdi, Ed. IS-IS for IP Internets S. Previdi, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track L. Ginsberg, Ed. Intended status: Standards Track L. Ginsberg, Ed.
Expires: June 16, 2019 C. Filsfils Expires: September 30, 2019 C. Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
A. Bashandy A. Bashandy
Individual Individual
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
B. Decraene B. Decraene
Orange Orange
December 13, 2018 March 29, 2019
IS-IS Extensions for Segment Routing IS-IS Extensions for Segment Routing
draft-ietf-isis-segment-routing-extensions-22 draft-ietf-isis-segment-routing-extensions-23
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 draft describes the necessary 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.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 16, 2019. This Internet-Draft will expire on September 30, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3
2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4
2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8 2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8
2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 9 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 8
2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9
2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 11 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 10
2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 13 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 12
2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 14 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 13
2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 17 2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 15
2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 18 2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 15
2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 19 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 16
2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 19 2.4.6. Example Encodings . . . . . . . . . . . . . . . . . . 16
3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 20 2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 18
3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 20 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 19
3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 19
3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22
3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 24 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 23
3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 25 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 25
4. Non backward compatible changes with prior versions of this 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
document . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 25
4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 26 4.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 26
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 4.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 27
5.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 26 4.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 28
5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 27 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 27 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 28 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . 31
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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
do not require any additional signaling (other than the regular IGP). do not require any additional signaling (other than the regular IGP).
For example, when used in MPLS networks, SR paths do not require any For example, when used in MPLS networks, SR paths do not require any
LDP or RSVP-TE signaling. Still, SR can interoperate in the presence LDP or RSVP-TE signaling. Still, SR can interoperate in the presence
of LSPs established with RSVP or LDP. of LSPs established with RSVP or LDP.
There are additional segment types, e.g., Binding SID defined in There are additional segment types, e.g., Binding SID defined in
[RFC8402]. This draft also defines an advertisement for one type of [RFC8402]. This draft also defines an advertisement for one type of
BindingSID: the Mirror Context segment. Binding SID: the Mirror Context segment.
This draft describes the necessary IS-IS extensions that need to be This draft describes the necessary 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.
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].
2. Segment Routing Identifiers 2. Segment Routing Identifiers
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 (SID). This document defines the IS-IS encodings
for the IGP-Prefix-SID, the IGP-Adjacency-SID, the IGP-LAN-Adjacency- for the IGP-Prefix Segment, the IGP-Adjacency Segment, the IGP-LAN-
SID and the Binding-SID. 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 sub-TLV
(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). The 'Prefix SID' MUST carry IGP domain (when the L-flag is not set).
an index (when the V-flag is not set) that determines the actual SID/
label value inside the set of all advertised SID/label ranges of a
given router. A receiving router uses the index to determine the
actual SID/label value in order to construct forwarding state to a
particular destination router.
In many use-cases a 'stable transport' IP Address is overloaded as an
identifier of a given node. Because the IP Prefixes may be re-
advertised into other levels there may be some ambiguity (e.g.
Originating router vs. L1L2 router) for which node a particular IP
prefix serves as identifier. The Prefix-SID sub-TLV contains the
necessary flags to disambiguate IP Prefix to node mappings.
Furthermore if a given node has several 'stable transport' IP
addresses there are flags to differentiate those among other IP
Prefixes advertised from a given node.
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 (Multitopology 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 (Multitopology IPv6 IP Reachability) defined in [RFC5120].
Binding-TLV and Multi-Topology Binding-TLV defined in Section 2.4 Binding-TLV and Multi-Topology Binding-TLV defined in Section 2.4
and Section 2.5 respectively. and Section 2.5 respectively.
When the IP Reachability TLV is propagated across level boundaries,
the Prefix-SID sub-TLV SHOULD be kept.
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: TBD, suggested value 3 Type: 3
Length: variable. 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 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:
skipping to change at page 6, line 18 skipping to change at page 5, line 42
Other bits: MUST be zero when originated and ignored when Other bits: MUST be zero when originated and ignored when
received. 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. Algorithms identifiers are defined in Section 3.2. nodes. Algorithms 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 First
(SPF), various sorts of Constrained SPF, etc. The algorithm field (SPF), various sorts of Constrained SPF, etc. The algorithm field
of the Prefix-SID contains the identifier of the algorithm the of the Prefix-SID contains the identifier of the algorithm the
router has used in order to compute the reachability of the prefix router uses to compute the reachability of the prefix to which the
to which the Prefix-SID is associated. 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 (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 (Section 3.2) MUST ignore the Prefix-SID sub-
TLV. 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
used to determine the actual label value inside the set of all
advertised label ranges of a given router. This allows a receiving
router to construct forwarding state to a particular destination
router.
In many use-cases a 'stable transport' address is overloaded as an
identifier of a given node. Because Prefixes may be re-advertised
into other levels there may be some ambiguity (e.g. Originating
router vs. L1L2 router) for which node a particular IP prefix serves
as identifier. The Prefix-SID sub-TLV contains the necessary flags
to disambiguate Prefix to node mappings. Furthermore if a given node
has several 'stable transport' addresses there are flags to
differentiate those among other Prefixes advertised from a given
node.
2.1.1. Flags 2.1.1. Flags
2.1.1.1. V and L Flags 2.1.1.1. V and L Flags
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.
skipping to change at page 7, line 15 skipping to change at page 7, line 4
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 V and L flags MUST
be ignored. be ignored.
2.1.1.2. R and N Flags 2.1.1.2. R and N Flags
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 either:
advertised because of propagation (Level-1 into Level-2); advertised because of propagation (Level-1 into Level-2);
advertised because of leaking (Level-2 into Level-1); advertised because of leaking (Level-2 into Level-1);
advertised because of redistribution (e.g.: from another advertised because of redistribution (e.g.: from another
protocol). 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. The R-bit MUST be set only for prefixes that are not local to R bit.
the router and advertised by the router because of propagation and/or
leaking.
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 MUST have a Prefix The prefix to which the Prefix-SID is attached has a Prefix length
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).
[RFC7794] also defines the N and R flags and with the same semantics The Prefix Attributes Flags sub-TLV [RFC7794] also defines the N and
of the equivalent flags defined in this document. There will be a R flags and with the same semantics of the equivalent flags defined
transition period where both sets of flags will be used and in this document. Whenever the Prefix Attributes Flags sub-TLV is
eventually only the flags of the Prefix Attributes will remain. present for a given prefix the values of the N and R flags advertised
During the transition period implementations supporting the N and R in that sub-TLV MUST be used and the values in a corresponding Prefix
flags defined in this document and the N and R flags defined in SID sub-TLV (if present) MUST be ignored.
[RFC7794] MUST advertise and parse all flags. In case the received
flags have different values, the value of the flags defined in
[RFC7794] prevails.
2.1.1.3. E and P Flags 2.1.1.3. E and P Flags
When calculating the outgoing label for the prefix, the router MUST
take into account E and P flags advertised by the next-hop router, if
next-hop router advertised the SID for the prefix. This MUST be done
regardless of next-hop router contributing to the best path to the
prefix or not.
When propagating (either from Level-1 to Level-2 or vice versa) a
reachability advertisement originated by another IS-IS speaker, the
router MUST set the P-flag and MUST clear the E-flag of the related
Prefix-SIDs.
The following behavior is associated with the settings of the E and P The following behavior is associated with the settings of the E and P
flags: flags:
o If the P-flag is not set then any upstream neighbor of the Prefix- o If the P-flag is not set then any upstream neighbor of the Prefix-
SID originator MUST pop the Prefix-SID. This is equivalent to the SID originator MUST pop the Prefix-SID. This is equivalent to the
penultimate hop popping mechanism used in the MPLS dataplane which penultimate hop popping mechanism used in the MPLS dataplane which
improves performance of the ultimate hop. MPLS EXP bits of the improves performance of the ultimate hop. MPLS EXP bits of the
Prefix-SID are not preserved to the ultimate hop (the Prefix-SID Prefix-SID are not preserved to the ultimate hop (the Prefix-SID
being removed). If the P-flag is unset the received E-flag is being removed). If the P-flag is unset the received E-flag is
ignored. ignored.
skipping to change at page 8, line 47 skipping to change at page 8, line 17
another) or at an inter-domain border router (prefix another) or at an inter-domain border router (prefix
propagation from one domain to another). propagation 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 PrefixSID 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.
2.1.2. Prefix-SID Propagation When propagating (either from Level-1 to Level-2 or vice versa) a
reachability advertisement originated by another IS-IS speaker, the
The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV router MUST set the P-flag and MUST clear the E-flag of the related
gets propagated across level boundaries. Prefix-SIDs.
The level-1-2 router that propagates the Prefix-SID sub-TLV between 2.1.2. Prefix-SID Propagation
levels MUST set the R-flag.
If the Prefix-SID contains a global index (L and V flags unset) and The Prefix-SID sub-TLV MUST be included when the associated Prefix
it is propagated as such (with L and V flags unset), the value of the Reachability TLV is propagated across level boundaries.
index MUST be preserved when propagated between levels.
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 MAY change the setting of the L and V flags in case a local levels maintains the content (flags and SID) except as noted in
label value is encoded in the Prefix-SID instead of the received Section 2.1.1.2 and Section 2.1.1.3.
value.
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 sub-
TLV (Adj-SID sub-TLV). 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.
skipping to change at page 10, line 15 skipping to change at page 9, line 23
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: TBD, suggested value 31 Type: 31
Length: variable. Length: 5 or 6 depending on size of the SID
Flags: 1 octet field of following flags: Flags: 1 octet field of 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 refers F-Flag: Address-Family flag. If unset, then the Adj-SID is
to an adjacency with outgoing IPv4 encapsulation. If set then used when forwarding IPv4 encapsulated traffic to the neighbor.
the Adj-SID refers to an adjacency with outgoing IPv6 If set then the Adj-SID is used when forwarding IPv6
encapsulation. 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 for
protection (e.g.: using IPFRR or MPLS-FRR) as described in protection (e.g.: using IPFRR or MPLS-FRR) as described in
[RFC8355]. [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 value.
By default the flag is SET. 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 carried by
the Adj-SID has local significance. By default the flag is the Adj-SID has local significance. By default the flag is
SET. SET.
S-Flag. Set flag. When set, the S-Flag indicates that the S-Flag. Set flag. When set, the S-Flag indicates that the
Adj-SID refers to a set of adjacencies (and therefore MAY be Adj-SID refers to a set of adjacencies (and therefore MAY be
skipping to change at page 11, line 15 skipping to change at page 10, line 23
Other bits: MUST be zero when originated and ignored when Other bits: MUST be zero when originated and ignored when
received. 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 is
defined in [RFC8402]. 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 and SHOULD set the B-Flag when the adjacency is adjacencies
eligible for protection (IP or MPLS).
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.
skipping to change at page 11, line 46 skipping to change at page 11, line 5
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 part of the TLV
advertising the adjacency to the DIS (e.g.: TLV-22). advertising the adjacency to the DIS (e.g.: TLV-22).
The following new sub-TLV is defined: LAN-Adj-SID (Type: TBD, The following new sub-TLV is defined: LAN-Adj-SID containing the set
suggested value 32) containing the set of Adj-SIDs the router of Adj-SIDs the router assigned to each of its LAN neighbors.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System-ID (6 octets) | | Neighbor System-ID (ID length octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Type: TBD, suggested value 32 Type: 32
Length: variable. Length: variable.
Flags: 1 octet field of following flags: Flags: 1 octet field of 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 F, B, V, L, S and P flags are defined in Section 2.2.1.
Other bits: MUST be zero when originated and ignored when Other bits: MUST be zero when originated and ignored when
received. 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 is
defined in [RFC8402]. defined in [RFC8402].
System-ID: 6 octets of IS-IS System-ID of length "ID Length" as Neighbor System-ID: 6 octets of IS-IS System-ID of length "ID
defined in [ISO10589]. Length" as defined in [ISO10589].
SID/Index/Label as defined in Section 2.1.1.1. SID/Index/Label as defined in Section 2.1.1.1.
Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Note that this sub-TLV Multiple LAN-Adj-SID sub-TLVs MAY be encoded.
MUST NOT appear in TLV 141.
When the P-flag is not set, the LAN-Adj-SID MAY be persistent. When Note that this sub-TLV MUST NOT appear in TLV 141.
the P-flag is set, the LAN-Adj-SID MUST be persistent.
In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) In case one TLV-22/23/222/223 (reporting the adjacency to the DIS)
can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple
advertisements of the adjacency to the DIS MUST be used and all advertisements of the adjacency to the DIS MUST be used and all
advertisements MUST have the same metric. 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-SID each reconstructing the LAN topology as well as the set of Adj-SID each
router uses for each of its neighbors. router uses for each of its neighbors.
A label is encoded in 3 octets (in the 20 rightmost bits).
An index is encoded in 4 octets.
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 code point used in all of the above cases is the SID/
Label Sub-TLV code point assigned by IANA in the "sub-TLVs for TLV Label Sub-TLV code point specified in the new "sub-TLVs for TLV 149
149 and 150" registry. 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 a 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: TBD, suggested value 1 Type: 1
Length: variable Length: 3 or 4
SID/Label: if length is set to 3 then the 20 rightmost bits SID/Label: if length is set to 3 then the 20 rightmost bits
represent a MPLS label. represent a MPLS label. If length is set to 4 then the valu eis 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]. [I-D.ietf-spring-segment-routing-ldp-interop].
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 to advertise the ability to process traffic originally destined to
another IGP node. This behavior is defined in [RFC8402]. another IGP node. This behavior is defined in [RFC8402].
The SID/Label Binding TLV has Type TBD (suggested value 149), and has The SID/Label Binding TLV has the following format:
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) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubTLVs (variable) | | Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SID/Label Binding TLV format Figure 1: SID/Label Binding TLV format
o Type: TBD, suggested value 149 o Type: 149
o Length: variable. o Length: variable.
o 1 octet of flags o 1 octet of flags
o 1 octet of RESERVED o 1 octet of RESERVED
o 2 octets of Range o 2 octets of Range
o 1 octet of Prefix Length o 1 octet of Prefix Length
skipping to change at page 15, line 27 skipping to change at page 14, line 27
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|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 an
IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix. 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 the M flag is corresponds to a mirrored context. The use of a mirrored context
described in [RFC8402]. 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 across
the entire routing domain. If the S flag is not set, the SID/ the entire routing domain. If the S flag is not set, the SID/
Label Binding TLV MUST NOT be leaked between levels. This bit Label Binding TLV MUST NOT be leaked between levels. This bit
MUST NOT be altered during the TLV leaking. 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 bit MUST be set. Otherwise, this bit MUST be level-1, the D-Flag MUST be set. Otherwise, this flag MUST be
clear. SID/Label Binding TLVs with the D bit set MUST NOT be clear. SID/Label Binding TLVs with the D-Flag set MUST NOT be
leaked from level-1 to level-2. This is to prevent TLV looping leaked from level-1 to level-2. This is to prevent TLV looping
across levels. 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 prefixes and
SIDs advertised in the SID/Label Binding TLV are directly SIDs advertised in the SID/Label Binding TLV are directly
connected to their originators. The mechanisms through which the connected to their originators. The mechanisms through which the
originator of the SID/Label Binding TLV can figure out if a prefix originator of the SID/Label Binding TLV can figure out if a prefix
is attached or not are outside the scope of this document (e.g.: is attached or not are outside the scope of this document (e.g.:
through explicit configuration). If the Binding TLV is leaked to through explicit configuration). If the Binding TLV is leaked to
other areas/levels the A-flag MUST be cleared. 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 not
to leak Binding TLV's between levels (for policy reasons). In all to leak Binding TLV's between levels (for policy reasons).
cases, the D flag MUST always be set by any router leaking the
Binding TLV from level-2 into level-1 and MUST be checked when
propagating the Binding TLV from level-1 into level-2. If the D
flag is set, the Binding TLV MUST NOT be propagated into level-2.
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 number of addresses that need to be mapped into a Prefix-SID and the range field MUST be set to the number of addresses that need to
the starting value of the Prefix-SID range. be mapped into a Prefix-SID. In either case the prefix is the first
address to which a SID is to be assigned.
Example 1: if the following router addresses (loopback addresses) 2.4.3. Prefix Length, Prefix
need to be mapped into the corresponding Prefix SID indexes.
The 'Prefix' represents the Forwarding equivalence class at the tail-
end of the advertised path. The 'Prefix' does not need to correspond
to a routable prefix of the originating node.
The 'Prefix Length' field contains the length of the prefix in bits.
Only the most significant octets of the Prefix are encoded (i.e., 1
octet for prefix length 1 up to 8, 2 octets for prefix length 9 to
16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix
length 25 up to 32, ...., 16 octets for prefix length 113 up to 128).
2.4.4. Mapping Server Prefix-SID
The Prefix-SID sub-TLV is defined in Section 2.1 and contains the
SID/index/label value associated with the prefix and range. The
Prefix-SID Sub-TLV MUST be present in the SID/Label Binding TLV when
the M-flag is clear. The Prefix-SID Sub-TLV MUST NOT be present when
the M-flag is set.
2.4.4.1. Prefix-SID Flags
The Prefix-SID flags are defined in Section 2.1. The Mapping Server
MAY advertise a mapping with the N flag set when the prefix being
mapped is known in the link-state topology with a mask length of 32
(IPv4) or 128 (IPv6) and when the prefix represents a node. The
mechanisms through which the operator defines that a prefix
represents a node are outside the scope of this document (typically
it will be through configuration).
The other flags defined in Section 2.1 are not used by the Mapping
Server and MUST be ignored at reception.
2.4.4.2. PHP Behavior when using Mapping Server Advertisements
As the mapping server does not specify the originator of a prefix
advertisement it is not possible to determine PHP behavior solely
based on the Mapping Server Advertisement. However, if additional
information is available PHP behavior may safely be done. The
required information consists of:
o A prefix reachability advertisement for the prefix has been
received which includes the Prefix Attribute Flags sub-TLV
[RFC7794].
o X and R flags are both set to 0 in the Prefix Attribute Flags sub-
TLV.
In the absence of an Prefix Attribute Flags sub-TLV [RFC7794] the A
flag in the binding TLV indicates that the originator of a prefix
reachability advertisement is directly connected to the prefix and
thus PHP MUST be done by the neighbors of the router originating the
prefix reachability advertisement. Note that A-flag is only valid in
the original area in which the Binding TLV is advertised.
2.4.4.3. Prefix-SID Algorithm
The algorithm field contains the identifier of the algorithm
associated with the SIDs for the prefix(es) in the range. Use of the
algorithm field is described in Section 2.1.
2.4.5. SID/Label Sub-TLV
The SID/Label sub-TLV (Type: 1) contains the SID/Label value as
defined in Section 2.3. It MUST be present in the SID/Label Binding
TLV when the M-flag is set in the Flags field of the parent TLV.
2.4.6. Example Encodings
Example 1: if the following IPv4 router addresses (loopback
addresses) need to be mapped into the corresponding Prefix SID
indexes.
Router-A: 192.0.2.1/32, Prefix-SID: Index 1 Router-A: 192.0.2.1/32, Prefix-SID: Index 1
Router-B: 192.0.2.2/32, Prefix-SID: Index 2 Router-B: 192.0.2.2/32, Prefix-SID: Index 2
Router-C: 192.0.2.3/32, Prefix-SID: Index 3 Router-C: 192.0.2.3/32, Prefix-SID: Index 3
Router-D: 192.0.2.4/32, Prefix-SID: Index 4 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| | 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 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:
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.2/24, Prefix-SID: Index 52
10.1.3/24, Prefix-SID: Index 53 10.1.3/24, Prefix-SID: Index 53
10.1.4/24, Prefix-SID: Index 54 10.1.4/24, Prefix-SID: Index 54
10.1.5/24, Prefix-SID: Index 55 10.1.5/24, Prefix-SID: Index 55
10.1.6/24, Prefix-SID: Index 56 10.1.6/24, Prefix-SID: Index 56
10.1.7/24, Prefix-SID: Index 57 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| | 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
corresponding Prefix-SID indexes:
2001:DB8:1/48, Prefix-SID: Index 151
2001:DB8:2/48, Prefix-SID: Index 152
2001:DB8:3/48, Prefix-SID: Index 153
2001:DB8:4/48, Prefix-SID: Index 154
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |1|0|0|0|0| | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 4 | 48 | 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0xD | 0xB8 | 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1 |Prefix-SID Type| sub-TLV Length| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.4.3. Prefix Length, Prefix
The 'Prefix' represents the Forwarding equivalence class at the tail-
end of the advertised path. The 'Prefix' does not need to correspond
to a routable prefix of the originating node.
The 'Prefix Length' field contains the length of the prefix in bits.
Only the most significant octets of the Prefix are encoded. (i.e., 1
octet for prefix length 1 up to 8, 2 octets for prefix length 9 to
16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix
length 25 up to 32, ...., 16 octets for prefix length 113 up to 128).
2.4.4. Mapping Server Prefix-SID
The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1
and contains the SID/index/label value associated with the prefix and
range. The Prefix-SID SubTLV MUST be present in the SID/Label
Binding TLV unless the M-flag is set in the Flags field of the parent
TLV.
A node receiving an SRMS entry for a prefix MUST check the existence
of such prefix in its link-state database prior to consider and use
the associated SID.
2.4.4.1. Prefix-SID Flags
The Prefix-SID flags are defined in Section 2.1. The Mapping Server
MAY advertise a mapping with the N flag set when the prefix being
mapped is known in the link-state topology with a mask length of 32
(IPv4) or 128 (IPv6) and when the prefix represents a node. The
mechanisms through which the operator defines that a prefix
represents a node are outside the scope of this document (typically
it will be through configuration).
The other flags defined in Section 2.1 are not used by the Mapping
Server and MUST be ignored at reception.
2.4.4.2. PHP Behavior when using Mapping Server Advertisements
As the mapping server does not specify the originator of a prefix
advertisement it is not possible to determine PHP behavior solely
based on the Mapping Server Advertisement. However, if additional
information is available PHP behavior may safely be done. The
required information consists of:
o A prefix reachability advertisement for the prefix has been
received which includes the Extended Reachability Attribute Flags
sub-TLV ([RFC7794]).
o X and R flags are both set to 0 in the Extended Reachability
Attribute Flags sub-TLV.
In the absence of an Extended Reachability Attribute Flags sub-TLV
([RFC7794]) the A flag in the binding TLV indicates that the
originator of a prefix reachability advertisement is directly
connected to the prefix and thus PHP MUST be done by the neighbors of
the router originating the prefix reachability advertisement. Note
that A-flag is only valid in the original area in which the Binding
TLV is advertised.
2.4.4.3. Prefix-SID Algorithm
The algorithm field contains the identifier of the algorithm the
router MUST use in order to compute reachability to the range of
prefixes. Use of the algorithm field is described in Section 2.1.
2.4.5. SID/Label Sub-TLV
The SID/Label sub-TLV (Type: TBD, suggested value 1) contains the
SID/Label value as defined in Section 2.3. It MUST be present in the
SID/Label Binding TLV when the M-flag is set in the Flags field of
the parent TLV.
2.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 M-ISIS
as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV
has the same format as the SID/Label Binding TLV defined in has the same format as the SID/Label Binding TLV defined in
Section 2.4 with the difference consisting of a Multitopology Section 2.4 with the difference consisting of a Multitopology
Identifier (MTID) as defined here below: Identifier (MTID) 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 | MTID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED | Range | | Flags | RESERVED | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix (variable) // | Prefix Length | Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubTLVs (variable) | | Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Multi-Topology SID/Label Binding TLV format Figure 2: Multi-Topology SID/Label Binding TLV format
where: where:
Type: TBD, suggested value 150 Type: 150
Length: variable Length: variable
MTID is the multitopology identifier defined as: MTID is the multitopology 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 | MTID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 4 skipping to change at page 19, line 32
Length: variable Length: variable
MTID is the multitopology identifier defined as: MTID is the multitopology 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 | MTID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 MTID: a 12-bit field containing the non-zero ID of the topology
being announced. The TLV MUST be ignored if the ID is zero. being announced. The TLV MUST be ignored if the ID is zero.
This is to ensure the consistent view of the standard unicast This is to ensure the consistent view of the standard unicast
topology. topology.
The other fields and SubTLVs 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 which are inserted into the IS-IS
Router Capability TLV-242 that is defined in [RFC7981]. Router Capability TLV-242 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 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: TBD, suggested value 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| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 22, line 5 skipping to change at page 21, line 32
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
blackhole / misdirect some traffic during the IGP convergence. In blackhole / 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 which 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 same after a graceful The originating router MUST ensure the order is unchanged after a
restart (using checkpointing, non-volatile storage or any other graceful restart (using checkpointing, non-volatile storage or any
mechanism) in order to guarantee the same order before and after GR. 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 [I-D.ietf-spring-segment-routing-mpls].
Here follows an example of advertisement of multiple ranges: Here follows an example of advertisement of multiple ranges:
The originating router advertises following ranges: The originating router advertises following ranges:
SR-Cap: range: 100, SID value: 100 SR-Cap: range: 100, SID value: 100
skipping to change at page 22, line 44 skipping to change at page 22, line 33
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 Shortest Path First (SPF), various
sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV (Type: TBD, sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the
suggested value 19) allows the router to advertise the algorithms router to advertise the algorithms that the router is currently
that the router is currently using. Algorithm values are defined in using. Algorithm values are defined in the "IGP Algorithm Type"
the "IGP Algorithm Type" registry defined in registry defined in [I-D.ietf-ospf-segment-routing-extensions]. The
[I-D.ietf-ospf-segment-routing-extensions]. The following values following values have been defined:
have been defined:
0: Shortest Path First (SPF) algorithm based on link metric. This 0: Shortest Path First (SPF) algorithm based on link metric. This
is the well-known shortest path algorithm as computed by the IS-IS is the well-known shortest path algorithm as computed by the IS-IS
Decision process. Consistent with the deployed practice for link- Decision process. Consistent with the deployed practice for link-
state protocols, algorithm 0 permits any node to overwrite the SPF state 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 Shortest Path First (SPF) algorithm based on link
metric. The algorithm is identical to algorithm 0 but algorithm 1 metric. The algorithm is identical to algorithm 0 but algorithm 1
requires that all nodes along the path will honor the SPF routing requires that all nodes along the path will honor the SPF routing
decision. Local policy MUST NOT alter the forwarding decision decision. Local policy MUST NOT alter the forwarding decision
computed by algorithm 1 at the node claiming to support algorithm computed by algorithm 1 at the node claiming to support algorithm
1. 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 MAY only appear a single The SR-Algorithm sub-TLV is optional. It MUST NOT be advertsied more
time inside the Router Capability TLV. than once at a given level. A router receiving multiple SR-Algorithm
sub-TLVs from the same originator SHOULD select the first
advertisement in the lowest numbered LSP.
When the originating router does not advertise the SR-Algorithm sub- When the originating router does not advertise the SR-Algorithm sub-
TLV, then all the Prefix-SIDs advertised by the router MUST have TLV, this implies that the only algorithm supported by routers
algorithm field set to 0. Any receiving router MUST assume SPF supporting the extensions defined in this document is Algorithm 0.
algorithm (i.e., Shortest Path First).
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 algorithm 1 MAY be present. then algorithm 0 MUST be present while non-zero algorithms MAY be
present.
The SR-Algorithm sub-TLV has 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: TBD, suggested value 19 Type: 19
Length: variable. Length: variable.
Algorithm: 1 octet of algorithm Section 2.1 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 other components than Adjacency-SIDs, and may also be allocated by other components than
IS-IS protocol. As an example, an application or a controller may the IS-IS protocol. As an example, an application or a controller
instruct the router to allocate a specific local SID. Therefore, in may instruct the router to allocate a specific local SID. Therefore,
order for such applications or controllers to know what are the local in order for such applications or controllers to know what are the
SIDs available in the router, it is required that the router local SIDs available in the router, it is required that the router
advertises its SRLB. advertises its SRLB.
The SRLB Sub-TLV is used for that purpose and has following format: The SRLB Sub-TLV is used for that 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: TBD, suggested value 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.
skipping to change at page 25, line 6 skipping to change at page 24, line 44
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.
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 in order to avoid
collision between allocation instructions. collision 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 Adjacency-SID. However, the
reporting of allocated local SIDs may also be done through other reporting of allocated local SIDs may also be done through other
means and protocols which mechanisms are outside the scope of this means and protocols which mechanisms are outside the scope of this
document. document.
skipping to change at page 25, line 36 skipping to change at page 25, line 26
particular source. particular source.
The SRMS Preference sub-TLV has following format: The SRMS Preference sub-TLV 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 | Preference | | Type | Length | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD, suggested value 24. Type: 24
Length: 1. Length: 1.
Preference: 1 octet. Unsigned 8 bit SRMS preference. Preference: 1 octet. 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 number
but a router MUST NOT advertise more than one SRMS Preference sub- but a router MUST NOT advertise more than one SRMS Preference sub-
TLV. A router receiving multiple SRMS Preference sub-TLVs, from the TLV. A router receiving multiple SRMS Preference sub-TLVs, from the
same originator, SHOULD select the first advertisement in the lowest same originator, SHOULD select the first advertisement in the lowest
numbered LSP. 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 [I-D.ietf-spring-segment-routing-ldp-interop]
4. Non backward compatible changes with prior versions of this document 4. IANA Considerations
This section describes the changes that have been applied to this
document that are not backward compatible with previous versions.
4.1. Encoding of Multiple SRGBs
Version -04 of this document introduced a change in Section 3.1
regarding the encoding method for multiple SRGBs in the SR-Cap SubTLV
and made the support of multiple SRGBs REQUIRED.
The modified method consists of having a single SR-Cap Sub-TLV where
all SRGBs are encoded. In previous versions (prior to version -04)
of this document it was allowed to have multiple occurrences of the
SR-Cap Sub-TLV.
At the time of writing this document, no existing implementations are
affected by the change since no implementations actually (i.e., at
the time of updating this document) encode multiple SRGBs anyway.
5. IANA Considerations
This documents request allocation for the following TLVs and subTLVs. This documents request allocation for the following TLVs and Sub-
TLVs.
5.1. Sub TLVs for Type 22,23,25,141,222, and 223 4.1. Sub TLVs for Type 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: TBD (suggested value 31) Type: 31
Description: Adjacency Segment Identifier Description: Adjacency Segment Identifier
TLV 22: yes TLV 22: yes
TLV 23: yes TLV 23: yes
TLV 25: no TLV 25: no
TLV 141: yes TLV 141: yes
TLV 222: yes TLV 222: yes
TLV 223: yes TLV 223: yes
Reference: This document (Section 2.2.1) Reference: This document (Section 2.2.1)
Type: TBD (suggested value 32)
Type: 32
Description: LAN Adjacency Segment Identifier Description: LAN Adjacency Segment Identifier
TLV 22: yes TLV 22: yes
TLV 23: yes TLV 23: yes
TLV 25: no TLV 25: no
TLV 141: yes TLV 141: yes
TLV 222: yes TLV 222: yes
TLV 223: yes TLV 223: yes
Reference: This document (Section 2.2.2) Reference: This document (Section 2.2.2)
5.2. Sub TLVs for Type 135,235,236 and 237 4.2. Sub TLVs for Type 135,235,236 and 237
This document makes the following registrations in the "sub-TLVs for This document makes the following registrations in the "sub-TLVs for
TLV 135,235,236 and 237" registry. TLV 135,235,236 and 237" registry.
Type: TBD (suggested value 3) Type: 3
Description: Prefix Segment Identifier Description: Prefix Segment Identifier
TLV 135: yes TLV 135: yes
TLV 235: yes TLV 235: yes
TLV 236: yes TLV 236: yes
TLV 237: yes TLV 237: yes
Reference: This document (Section 2.1) Reference: This document (Section 2.1)
5.3. Sub TLVs for Type 242 4.3. Sub TLVs for Type 242
This document makes the following registrations in the "sub-TLVs for This document makes the following registrations in the "sub-TLVs for
TLV 242" registry. TLV 242" registry.
Type: TBD (suggested value 2) Type: 2
Description: Segment Routing Capability Description: Segment Routing Capability
Reference: This document (Section 3.1) Reference: This document (Section 3.1)
Type: TBD (suggested value 19) Type: 19
Description: Segment Routing Algorithm Description: Segment Routing Algorithm
Reference: This document (Section 3.2) Reference: This document (Section 3.2)
Type: TBD (suggested value 22) Type: 22
Description: Segment Routing Local Block (SRLB) Description: Segment Routing Local Block (SRLB)
Reference: This document (Section 3.3) Reference: This document (Section 3.3)
Type: TBD (suggested value 24) Type: 24
Description: Segment Routing Mapping Server Preference (SRMS Description: Segment Routing Mapping Server Preference (SRMS
Preference) Preference)
Reference: This document (Section 3.4) Reference: This document (Section 3.4)
5.4. New TLV Codepoint and Sub-TLV registry 4.4. New TLV Codepoint and Sub-TLV registry
This document registers the following TLV: This document registers the following TLV:
Type: TBD (suggested value 149) Type: 149
name: Segment Identifier / Label Binding name: Segment Identifier / Label Binding
IIH: no IIH: no
LSP: yes LSP: yes
SNP: no SNP: no
Purge: no Purge: no
Reference: This document (Section 2.4) Reference: This document (Section 2.4)
Type: TBD (suggested value 150) Type: 150
name: Multi-Topology Segment Identifier / Label Binding name: Multi-Topology Segment Identifier / Label Binding
IIH: no IIH: no
LSP: yes LSP: yes
SNP: no SNP: no
Purge: no Purge: no
Reference: This document (Section 2.5) Reference: This document (Section 2.5)
skipping to change at page 29, line 22 skipping to change at page 28, line 45
Reference: This document (Section 2.5) Reference: This document (Section 2.5)
This document creates the following sub-TLV Registry: This document creates the following sub-TLV Registry:
Registry: sub-TLVs for TLV 149 and 150 Registry: sub-TLVs for TLV 149 and 150
Registration Procedure: Expert review Registration Procedure: Expert review
Reference: This document (Section 2.4) Reference: This document (Section 2.4)
Type: TBD, suggested value 1 Type: 1
Description: SID/Label Description: SID/Label
Reference: This document (Section 2.4.5) Reference: This document (Section 2.4.5)
Type: 3
Type: TBD, suggested value 3
Description: Prefix-SID Description: Prefix-SID
Reference: This document (Section 2.1) Reference: This document (Section 2.1)
6. 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 which 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 types 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. Existing security extensions as described in [RFC5304] and isolate. Existing security extensions as described in [RFC5304] and
[RFC5310] apply to these segment routing extensions. [RFC5310] apply to these segment routing extensions.
7. Acknowledgements 6. Acknowledgements
We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre
Francois and Jesper Skrivers for their contribution to the content of Francois and Jesper Skrivers for their contribution to the content of
this document. this document.
8. Contributors 7. Contributors
The following people gave a substantial contribution to the content The following people gave a substantial contribution to the content
of this document and should be considered as co-authors: of this document and should be considered as co-authors:
Stephane Litkowski Stephane Litkowski
Orange Orange
FR FR
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
skipping to change at page 31, line 22 skipping to change at page 30, line 42
FI FI
Email: saku@ytti.fi Email: saku@ytti.fi
Steven Luong Steven Luong
Cisco Systems Inc. Cisco Systems Inc.
US US
Email: sluong@cisco.com Email: sluong@cisco.com
9. References 8. References
8.1. Normative References
9.1. Normative References
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-27 (work in progress), December 2018. routing-extensions-27 (work in progress), December 2018.
[I-D.ietf-spring-segment-routing-ldp-interop] [I-D.ietf-spring-segment-routing-ldp-interop]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and
S. Litkowski, "Segment Routing interworking with LDP", S. Litkowski, "Segment Routing interworking with LDP",
draft-ietf-spring-segment-routing-ldp-interop-15 (work in draft-ietf-spring-segment-routing-ldp-interop-15 (work in
progress), September 2018. progress), September 2018.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-18 data plane", draft-ietf-spring-segment-routing-mpls-19
(work in progress), December 2018. (work in progress), March 2019.
[ISO10589] [ISO10589]
International Organization for Standardization, International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain "Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO/ connectionless-mode Network Service (ISO 8473)", ISO/
IEC 10589:2002, Second Edition, Nov 2002. IEC 10589:2002, Second Edition, Nov 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 33, line 10 skipping to change at page 32, line 37
[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>.
9.2. Informative References 8.2. Informative References
[RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M.
Shand, "Simplified Extension of Link State PDU (LSP) Space Shand, "Simplified Extension of Link State PDU (LSP) Space
for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009,
<https://www.rfc-editor.org/info/rfc5311>. <https://www.rfc-editor.org/info/rfc5311>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
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>.
[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R.
Shakir, "Resiliency Use Cases in Source Packet Routing in
Networking (SPRING) Networks", RFC 8355,
DOI 10.17487/RFC8355, March 2018,
<https://www.rfc-editor.org/info/rfc8355>.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi (editor)
Huawei Huawei
IT IT
Email: stefano@previdi.net Email: stefano@previdi.net
Les Ginsberg (editor) Les Ginsberg (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 108 change blocks. 
311 lines changed or deleted 272 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/