--- 1/draft-ietf-isis-segment-routing-extensions-23.txt 2019-04-17 22:13:08.827304756 -0700 +++ 2/draft-ietf-isis-segment-routing-extensions-24.txt 2019-04-17 22:13:08.883306224 -0700 @@ -1,26 +1,26 @@ IS-IS for IP Internets S. Previdi, Ed. Internet-Draft Huawei Intended status: Standards Track L. Ginsberg, Ed. -Expires: September 30, 2019 C. Filsfils +Expires: October 19, 2019 C. Filsfils Cisco Systems, Inc. A. Bashandy - Individual + Arrcus H. Gredler RtBrick Inc. B. Decraene Orange - March 29, 2019 + April 17, 2019 IS-IS Extensions for Segment Routing - draft-ietf-isis-segment-routing-extensions-23 + draft-ietf-isis-segment-routing-extensions-24 Abstract Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data-plane. @@ -41,21 +41,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 30, 2019. + This Internet-Draft will expire on October 19, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -83,52 +83,52 @@ 2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 15 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 16 2.4.6. Example Encodings . . . . . . . . . . . . . . . . . . 16 2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 18 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 19 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 19 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 23 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 25 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 4.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 25 + 4.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 26 4.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 26 - 4.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 27 - 4.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 28 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 31 - 8.2. Informative References . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 + 4.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 26 + 4.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 26 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 + 8.2. Informative References . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Prefix segments represent an ECMP-aware shortest-path to a prefix (or a node), as per the state of the IGP topology. Adjacency segments represent a hop over a specific adjacency between two nodes in the IGP. A prefix segment is typically a multi-hop path while an adjacency segment, in most of the cases, is a one-hop path. SR's control-plane can be applied to both IPv6 and MPLS data-planes, and - do not require any additional signaling (other than the regular IGP). - For example, when used in MPLS networks, SR paths do not require any - LDP or RSVP-TE signaling. Still, SR can interoperate in the presence - of LSPs established with RSVP or LDP. + does not require any additional signaling (other than the regular + IGP). For example, when used in MPLS networks, SR paths do not + require any LDP or RSVP-TE signaling. Still, SR can interoperate in + the presence of LSPs established with RSVP or LDP. There are additional segment types, e.g., Binding SID defined in - [RFC8402]. This draft also defines an advertisement for one type of - Binding SID: the Mirror Context segment. + [RFC8402]. This document also defines an advertisement for one type + of Binding SID: the Mirror Context segment. This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data-plane. The Segment Routing architecture is described in [RFC8402]. Segment Routing use cases are described in [RFC7855]. 2. Segment Routing Identifiers @@ -211,21 +211,21 @@ L-Flag: Local Flag. If set, then the value/index carried by the Prefix-SID has local significance. By default the flag is UNSET. Other bits: MUST be zero when originated and ignored when received. Algorithm: the router may use various algorithms when calculating reachability to other nodes or to prefixes attached to these - nodes. Algorithms identifiers are defined in Section 3.2. + nodes. Algorithm identifiers are defined in Section 3.2. Examples of these algorithms are metric based Shortest Path First (SPF), various sorts of Constrained SPF, etc. The algorithm field of the Prefix-SID contains the identifier of the algorithm the router uses to compute the reachability of the prefix to which the Prefix-SID is associated. At origination, the Prefix-SID algorithm field MUST be set to 0 or to any value advertised in the SR-Algorithm sub-TLV (Section 3.2). A router receiving a Prefix-SID from a remote node and with an @@ -507,37 +507,37 @@ +-+-+-+-+-+-+-+-+ 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 received. Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in [RFC8402]. - Neighbor System-ID: 6 octets of IS-IS System-ID of length "ID - Length" as defined in [ISO10589]. + Neighbor System-ID: IS-IS System-ID of length "ID Length" as + defined in [ISO10589]. SID/Index/Label as defined in Section 2.1.1.1. Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Note that this sub-TLV MUST NOT appear in TLV 141. In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple advertisements of the adjacency to the DIS MUST be used and all advertisements MUST have the same metric. Each router within the level, by receiving the DIS PN LSP as well as the non-PN LSP of each router in the LAN, is capable of - reconstructing the LAN topology as well as the set of Adj-SID each + reconstructing the LAN topology as well as the set of Adj-SIDs each router uses for each of its neighbors. 2.3. SID/Label Sub-TLV The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs defined in this document: SR-Capabilities Sub-TLV (Section 3.1) SR Local Block Sub-TLV (Section 3.3) @@ -800,23 +800,23 @@ 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 | + | 0x01 | 0x0D | 0xB8 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x1 |Prefix-SID Type| sub-TLV Length| Flags | + | 0x01 |Prefix-SID Type| sub-TLV Length| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 151 | +-+-+-+-+-+-+-+-+ It is not expected that a network operator will be able to keep fully continuous Prefix / SID/Index mappings. In order to support noncontinuous mapping ranges an implementation MAY generate several instances of Binding TLVs. @@ -1054,28 +1054,28 @@ Type: 19 Length: variable. Algorithm: 1 octet of algorithm 3.3. SR Local Block Sub-TLV The SR Local Block (SRLB) Sub-TLV contains the range of labels the node has reserved for local SIDs. Local SIDs are used, e.g., for - Adjacency-SIDs, and may also be allocated by other components than + Adjacency-SIDs, and may also be allocated by components other than the IS-IS protocol. As an example, an application or a controller may instruct the router to allocate a specific local SID. Therefore, in order for such applications or controllers to know what are the local SIDs available in the router, it is required that the router advertises its SRLB. - The SRLB Sub-TLV is used for that purpose and has following format: + The SRLB Sub-TLV is used for this purpose and has following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -1099,35 +1099,37 @@ range contains the number of SRLB elements. The range value MUST be higher than 0. The SRLB sub-TLV MAY be advertised in an LSP of any number but a router MUST NOT advertise more than one SRLB sub-TLV. A router receiving multiple SRLB sub-TLVs, from the same originator, SHOULD select the first advertisement in the lowest numbered LSP. The originating router MUST NOT advertise overlapping ranges. + When a router receives multiple overlapping ranges, it MUST conform + to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. + It is important to note that each time a SID from the SRLB is allocated, it should also be reported to all components (e.g.: controller or applications) in order for these components to have an up-to-date view of the current SRLB allocation and in order to avoid collision between allocation instructions. Within the context of IS-IS, the reporting of local SIDs is done through IS-IS Sub-TLVs such as the Adjacency-SID. However, the reporting of allocated local SIDs may also be done through other - means and protocols which mechanisms are outside the scope of this - document. + means and protocols which are outside the scope of this document. - A router advertising the SRLB TLV may also have other label ranges, - outside the SRLB, for its local allocation purposes which are NOT - advertised in the SRLB. For example, it is possible that an + A router advertising the SRLB sub-TLV may also have other label + ranges, outside the SRLB, for its local allocation purposes which are + NOT advertised in the SRLB. For example, it is possible that an Adjacency-SID is allocated using a local label not part of the SRLB. 3.4. SRMS Preference Sub-TLV The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used in order to associate a preference with SRMS advertisements from a particular source. The SRMS Preference sub-TLV has following format: @@ -1147,173 +1149,90 @@ but a router MUST NOT advertise more than one SRMS Preference sub- TLV. A router receiving multiple SRMS Preference sub-TLVs, from the same originator, SHOULD select the first advertisement in the lowest numbered LSP. The use of the SRMS Preference during the SID selection process is described in [I-D.ietf-spring-segment-routing-ldp-interop] 4. IANA Considerations - This documents request allocation for the following TLVs and Sub- + This document requests allocation for the following TLVs and Sub- TLVs. 4.1. Sub TLVs for Type 22,23,25,141,222, and 223 This document makes the following registrations in the "sub-TLVs for TLV 22, 23, 25, 141, 222 and 223" registry. - Type: 31 - - Description: Adjacency Segment Identifier - - TLV 22: yes - - TLV 23: yes - - TLV 25: no - - TLV 141: yes - - TLV 222: yes - - TLV 223: yes - - Reference: This document (Section 2.2.1) - - Type: 32 - - Description: LAN Adjacency Segment Identifier - - TLV 22: yes - - TLV 23: yes - - TLV 25: no - - TLV 141: yes - - TLV 222: yes - - TLV 223: yes - - Reference: This document (Section 2.2.2) + Type Description 22 23 25 141 222 223 + ---- -------------------------------- --- --- --- --- --- --- + 31 Adjacency Segment Identifier y y n y y y + 32 LAN Adjacency Segment Identifier y y n y y y 4.2. Sub TLVs for Type 135,235,236 and 237 This document makes the following registrations in the "sub-TLVs for TLV 135,235,236 and 237" registry. - Type: 3 - - Description: Prefix Segment Identifier - - TLV 135: yes - TLV 235: yes - - TLV 236: yes - - TLV 237: yes - - Reference: This document (Section 2.1) + Type Description 135 235 236 237 + ---- ------------------------- --- --- --- --- + 3 Prefix Segment Identifier y y y y 4.3. Sub TLVs for Type 242 This document makes the following registrations in the "sub-TLVs for TLV 242" registry. - Type: 2 - - Description: Segment Routing Capability - - Reference: This document (Section 3.1) - - Type: 19 - - Description: Segment Routing Algorithm - - Reference: This document (Section 3.2) - - Type: 22 - - Description: Segment Routing Local Block (SRLB) - - Reference: This document (Section 3.3) - - Type: 24 - - Description: Segment Routing Mapping Server Preference (SRMS - Preference) - - Reference: This document (Section 3.4) + Type Description + ---- ----------- + 2 Segment Routing Capability + 19 Segment Routing Algorithm + 22 Segment Routing Local Block (SRLB) + 24 Segment Routing Mapping Server Preference + (SRMS Preference) 4.4. New TLV Codepoint and Sub-TLV registry This document registers the following TLV: - Type: 149 - - name: Segment Identifier / Label Binding - - IIH: no - - LSP: yes - - SNP: no - - Purge: no - - Reference: This document (Section 2.4) - - Type: 150 - - name: Multi-Topology Segment Identifier / Label Binding - - IIH: no - - LSP: yes - - SNP: no - - Purge: no - - Reference: This document (Section 2.5) + Value Name IIH LSP SNP Purge + ----- --------------------------------- --- --- --- ----- + 149 Segment Identifier/Label Binding n y n n + 150 Multi-Topology Segment Identifier n y n n + /Label Binding This document creates the following sub-TLV Registry: - Registry: sub-TLVs for TLV 149 and 150 - - Registration Procedure: Expert review - - Reference: This document (Section 2.4) - - Type: 1 - - Description: SID/Label - - Reference: This document (Section 2.4.5) - Type: 3 - - Description: Prefix-SID + Name: sub-TLVs for TLVs 149 and 150 + Registration Procedure: Expert Review - Reference: This document (Section 2.1) + Type Description + ---- ----------- + 0 Reserved + 1 SID/Label + 2 Unassigned + 3 Prefix SID + 4-255 Unassigned 5. Security Considerations With the use of the extensions defined in this document, IS-IS carries information which will be used to program the MPLS data plane [RFC3031]. In general, the same types of attacks that can be carried out on the IP/IPv6 control plane can be carried out on the MPLS control plane resulting in traffic being misrouted in the respective data planes. However, the latter may be more difficult to detect and - isolate. Existing security extensions as described in [RFC5304] and - [RFC5310] apply to these segment routing extensions. + isolate. + + Existing security extensions as described in [RFC5304] and [RFC5310] + apply to these segment routing extensions. 6. Acknowledgements We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre Francois and Jesper Skrivers for their contribution to the content of this document. 7. Contributors The following people gave a substantial contribution to the content @@ -1388,22 +1310,22 @@ [I-D.ietf-spring-segment-routing-ldp-interop] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and S. Litkowski, "Segment Routing interworking with LDP", draft-ietf-spring-segment-routing-ldp-interop-15 (work in progress), September 2018. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS - data plane", draft-ietf-spring-segment-routing-mpls-19 - (work in progress), March 2019. + data plane", draft-ietf-spring-segment-routing-mpls-21 + (work in progress), April 2019. [ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/ IEC 10589:2002, Second Edition, Nov 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -1419,28 +1341,20 @@ [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . - [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic - Engineering", RFC 5305, DOI 10.17487/RFC5305, October - 2008, . - - [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, - DOI 10.17487/RFC5308, October 2008, - . - [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, . @@ -1453,20 +1367,28 @@ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 8.2. Informative References + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, DOI 10.17487/RFC5305, October + 2008, . + + [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, + DOI 10.17487/RFC5308, October 2008, + . + [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. Shand, "Simplified Extension of Link State PDU (LSP) Space for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, . [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, . @@ -1479,36 +1401,35 @@ Authors' Addresses Stefano Previdi (editor) Huawei IT Email: stefano@previdi.net Les Ginsberg (editor) Cisco Systems, Inc. - IT + USA Email: ginsberg@cisco.com Clarence Filsfils Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Ahmed Bashandy - Individual + Arrcus Email: abashandy.ietf@gmail.com Hannes Gredler RtBrick Inc. Email: hannes@rtbrick.com - Bruno Decraene Orange FR Email: bruno.decraene@orange.com