draft-ietf-isis-segment-routing-extensions-20.txt   draft-ietf-isis-segment-routing-extensions-21.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: May 12, 2019 C. Filsfils Expires: June 6, 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
November 8, 2018 December 3, 2018
IS-IS Extensions for Segment Routing IS-IS Extensions for Segment Routing
draft-ietf-isis-segment-routing-extensions-20 draft-ietf-isis-segment-routing-extensions-21
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 May 12, 2019. This Internet-Draft will expire on June 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . 8 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 9
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 . . . . . . . . 11
2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 13 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 13
2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 14 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 14
2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 18 2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 17
2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 18 2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 18
2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 19 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 19
2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 19 2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 19
3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 20 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 20
3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 20 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 20
3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 23 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22
3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 24 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 24
3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 26 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 25
4. Non backward compatible changes with prior versions of this 4. Non backward compatible changes with prior versions of this
document . . . . . . . . . . . . . . . . . . . . . . . . . . 26 document . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 26 4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 26
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
5.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 27 5.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 26
5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 28 5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 27
5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 28 5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 27
5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 29 5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . 32 9.1. Normative References . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 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
skipping to change at page 6, line 29 skipping to change at page 6, line 29
to which the Prefix-SID is associated. 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 (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: according to the V and L flags, it contains SID/Index/Label as defined in Section 2.1.1.1.
either:
* A 4 octet index defining the offset in the SID/Label space 2.1.1. Flags
advertised by this router using the encodings defined in
Section 3.1. In this case the V and L flags MUST be unset.
* A 3 octet local label where the 20 rightmost bits are used for 2.1.1.1. V and L Flags
encoding the label value. In this case the V and L flags MUST
be set.
2.1.1. Flags The V-flag indicates whether the SID/Index/Label field is a value or
an index.
2.1.1.1. R and N Flags The L-Flag indicates whether the value/index in the SID/Index/Label
field has local or global significance.
The following settings for V and L flags are valid:
V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label field
is a 4 octet index defining the offset in the SID/Label space
advertised by this router using the encodings defined in Section 3.1.
V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label field
is a 3 octet local label where the 20 rightmost bits are used for
encoding the label value.
All other combinations of V-flag and L-flag are invalid and any SID
advertisement received with an invalid setting for V and L flags MUST
be ignored.
2.1.1.2. R and N Flags
The R-Flag MUST be set for prefixes that are not local to the router 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).
skipping to change at page 7, line 35 skipping to change at page 8, line 5
[RFC7794] also defines the N and R flags and with the same semantics [RFC7794] also defines the N and R flags and with the same semantics
of the equivalent flags defined in this document. There will be a of the equivalent flags defined in this document. There will be a
transition period where both sets of flags will be used and transition period where both sets of flags will be used and
eventually only the flags of the Prefix Attributes will remain. eventually only the flags of the Prefix Attributes will remain.
During the transition period implementations supporting the N and R During the transition period implementations supporting the N and R
flags defined in this document and the N and R flags defined in flags defined in this document and the N and R flags defined in
[RFC7794] MUST advertise and parse all flags. In case the received [RFC7794] MUST advertise and parse all flags. In case the received
flags have different values, the value of the flags defined in flags have different values, the value of the flags defined in
[RFC7794] prevails. [RFC7794] prevails.
2.1.1.2. E and P Flags 2.1.1.3. E and P Flags
When calculating the outgoing label for the prefix, the router MUST 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 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 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 regardless of next-hop router contributing to the best path to the
prefix or not. prefix or not.
When propagating (either from Level-1 to Level-2 or vice versa) a When propagating (either from Level-1 to Level-2 or vice versa) a
reachability advertisement originated by another IS-IS speaker, the reachability advertisement originated by another IS-IS speaker, the
router MUST set the P-flag and MUST clear the E-flag of the related router MUST set the P-flag and MUST clear the E-flag of the related
skipping to change at page 10, line 36 skipping to change at page 11, line 12
the Adj-SID is persistently allocated, i.e., the Adj-SID value the Adj-SID is persistently allocated, i.e., the Adj-SID value
remains consistent across router restart and/or interface flap. 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 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 [I-D.ietf-spring-segment-routing]. defined in [I-D.ietf-spring-segment-routing].
SID/Index/Label: according to the V and L flags, it contains SID/Index/Label as defined in Section 2.1.1.1.
either:
* A 3 octet local label where the 20 rightmost bits are used for
encoding the label value. In this case the V and L flags MUST
be set.
* A 4 octet index defining the offset in the SID/Label space
advertised by this router using the encodings defined in
Section 3.1. In this case V and L flags MUST be unset.
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 and SHOULD set the B-Flag when the adjacency is
eligible for protection (IP or MPLS). 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.
skipping to change at page 12, line 45 skipping to change at page 12, line 45
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 [I-D.ietf-spring-segment-routing]. defined in [I-D.ietf-spring-segment-routing].
System-ID: 6 octets of IS-IS System-ID of length "ID Length" as System-ID: 6 octets of IS-IS System-ID of length "ID Length" as
defined in [ISO10589]. defined in [ISO10589].
SID/Index/Label: according to the V and L flags, it contains SID/Index/Label as defined in Section 2.1.1.1.
either:
* A 3 octet local label where the 20 rightmost bits are used for
encoding the label value. In this case the V and L flags MUST
be set.
* A 4 octet index defining the offset in the SID/Label space
advertised by this router using the encodings defined in
Section 3.1. In this case V and L flags MUST be unset.
Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Note that this sub-TLV Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Note that this sub-TLV
MUST NOT appear in TLV 141. MUST NOT appear in TLV 141.
When the P-flag is not set, the LAN-Adj-SID MAY be persistent. When When the P-flag is not set, the LAN-Adj-SID MAY be persistent. When
the P-flag is set, the LAN-Adj-SID MUST be persistent. 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
skipping to change at page 32, line 22 skipping to change at page 31, line 30
Email: sluong@cisco.com Email: sluong@cisco.com
9. References 9. References
9.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-25 (work in progress), April 2018. routing-extensions-26 (work in progress), November 2018.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018. in progress), January 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-15 data plane", draft-ietf-spring-segment-routing-mpls-16
(work in progress), October 2018. (work in progress), November 2018.
[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
 End of changes. 20 change blocks. 
53 lines changed or deleted 48 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/