idnits 2.17.1 draft-chen-lsr-igp-shorter-srv6-extensions-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 8, 2020) is 1446 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 344, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-cheng-spring-shorter-srv6-sid-requirement-01 ** Downref: Normative reference to an Informational draft: draft-cheng-spring-shorter-srv6-sid-requirement (ref. 'I-D.cheng-spring-shorter-srv6-sid-requirement') == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-04 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-08 == Outdated reference: A later version (-15) exists of draft-ietf-lsr-ospfv3-srv6-extensions-00 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-15 == Outdated reference: A later version (-04) exists of draft-liu-idr-segment-routing-te-policy-complement-02 == Outdated reference: A later version (-10) exists of draft-mirsky-6man-unified-id-sr-06 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR WG Ran. Chen 3 Internet-Draft Shaofu. Peng 4 Intended status: Standards Track ZTE Corporation 5 Expires: November 9, 2020 May 8, 2020 7 IGP Extensions for Shorter SRv6 SID 8 draft-chen-lsr-igp-shorter-srv6-extensions-02 10 Abstract 12 This document describes the IGP extensions required to support the 13 Shorter SRv6 SIDs( Compressing SRv6 SIDs). 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on November 9, 2020. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Advertising Shorter SRv6 SIDs capabilities. . . . . . . . . . 2 51 2.1. IS-IS Extensions . . . . . . . . . . . . . . . . . . . . 2 52 2.2. OSPFv3 Extensions . . . . . . . . . . . . . . . . . . . . 4 53 3. Advertising SRv6 SID Structure Sub-Sub-TLV . . . . . . . . . 5 54 4. Advertising Endpoint Behaviors with U-Flavor . . . . . . . . 6 55 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 61 1. Introduction 63 Segment Routing [RFC8402] leverages the source routing paradigm. An 64 ingress node steers a packet through an ordered list of 65 instructions,called segments. 67 Segment Routing can be directly instantiated on the IPv6 data plane 68 through the use of the Segment Routing Header defined in [RFC8754]. 69 SRv6 refers to this SR instantiation on the IPv6 dataplane. 71 However, the size of the SRv6 SID presents a scalabilities challenge 72 to use topological instructions that define a strict explicitly 73 routed path in combination with service-based instructions. At the 74 same time, the size of the SRH/SID may be a challenge for some data 75 plane processors and traffic overhead. 76 [I-D.cheng-spring-shorter-srv6-sid-requirement] describes a list of 77 requirements for the use of a shortened identifier in a segment 78 routing network with the IPv6 data plane. 80 [I-D.mirsky-6man-unified-id-sr] proposed an extension of SRH that 81 enables the use of a shorter segment identifier in dataplane, such as 82 32-bits Label format SID or 32-bits IP address format SID. 84 This document defines extensions to IGP in order to to support the 85 Shorter SRv6 SIDs contained in SID list that installed in dataplane. 87 2. Advertising Shorter SRv6 SIDs capabilities. 89 2.1. IS-IS Extensions 91 A node indicates that it supports the SR Segment Endpoint Node 92 functionality as specified in [RFC8754] by advertising a new SRv6 93 Capabilities sub-TLV [I-D.ietf-lsr-isis-srv6-extensions] of the 94 router capabilities TLV [RFC7981]. 96 This document extensions the flags field in the SRv6 Capabilities 97 sub-TLV [I-D.ietf-lsr-isis-srv6-extensions] to indicate the node 98 supports the Shorter SRv6 SIDs. 100 0 1 2 3 101 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 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Type | Length | Flags |U| 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Optional sub-sub-TLVs... 107 Figure 1: U-Flag in SRv6 Capabilities sub-TLV 109 where 111 U: U-SID Encapsulation Capability. When the U flag is set, it 112 indicates that the node supports the encapsulate and decapsulate the 113 U-SID, that is to say, the SID list composed of multiple classic 128 114 bit SIDs can be compressed into an U-SID list containing multiple 115 shorter U-SIDs, which is encapsulated in SRH, or the shorter U-SID 116 can be obtained from SRH and restored to the classic 128 bit SID. 118 Optional sub-sub-TLVs: When the U flag is set, A new U-Domain sub- 119 sub-TLV is carried to describe which compression domain (U-Domain) 120 the node is in. If the U-Domain sub-sub-tlv is not carried, it is in 121 32-bit compression domain by default. Note that each node is always 122 in the classical 128 bit compression domain, without explicit 123 notification. 125 The format of the U-Domain sub-Sub-TLV is as below: 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | sub-Type=U-D | Length | Flags |M|S|T| 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 Figure 2:U-Domain sub-Sub-TLV 135 Three flags are currently defined in the U-Domain sub-Sub-TLV: 137 T: The node is in 32-bit compression domain. 139 S: The node is in 16-bit compression domain. 141 M: The node is in MPLS compression domain. 143 Note that the U-SID Encapsulation capability has nothing to do with 144 the type of compression domain the node is in. For example, an N1 145 node in a 128 bit compression domain has U-SID Encapsulation 146 capability, while an N2 node in the same domain may not have U-SID 147 Encapsulation capability. 149 2.2. OSPFv3 Extensions 151 The SRv6 Capabilities TLV is used by an OSPFv3 router to advertise 152 its SRv6 support along with its related capabilities for SRv6 153 functionality. This is an optional top level TLV of the OSPFv3 154 Router Information LSA [RFC7770] which MUST be advertised by an SRv6 155 enabled router. 157 This document extensions the flags field in the SRv6 Capabilities TLV 158 [I-D.ietf-lsr-ospfv3-srv6-extensions] to indicate the node supports 159 the Shorter SRv6 SIDs. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Flags |U| Reserved | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Sub-TLVs... 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 3: U-Flag in SRv6 Capabilities TLV 173 where 175 U: U-SID Encapsulation Capability. When the U flag is set, it 176 indicates that the node supports the encapsulate and decapsulate the 177 U-SID, that is to say, the SID list composed of multiple classic 128 178 bit SIDs can be compressed into an U-SID list containing multiple 179 shorter U-SIDs, which is encapsulated in SRH, or the shorter U-SID 180 can be obtained from SRH and restored to the classic 128 bit SID. 182 Sub-TLVs: When the U flag is set, A new U-Domain sub-TLV is carried 183 to describe which compression domain (U-Domain) the node is in. If 184 the U-Domain sub-tlv is not carried, it is in 32-bit compression 185 domain by default. Note that each node is always in the classical 186 128 bit compression domain, without explicit notification. 188 The format of the U-Domain sub-Sub-TLV is as below: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | sub-Type=U-D | Length | Flags |M|S|T| 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 4: U-Domain sub-TLV 198 Three flags are currently defined in the U-Domain sub-TLV: 200 T: The node is in 32-bit compression domain. 202 S: The node is in 16-bit compression domain. 204 M: The node is in MPLS compression domain. 206 Note that the U-SID Encapsulation capability has nothing to do with 207 the type of compression domain the node is in. For example, an N1 208 node in a 128 bit compression domain has U-SID Encapsulation 209 capability, while an N2 node in the same domain may not have U-SID 210 Encapsulation capability. 212 3. Advertising SRv6 SID Structure Sub-Sub-TLV 214 SRv6 SID Structure Sub-Sub-TLV is an optional Sub-Sub-TLV of SRv6 End 215 SID Sub-TLV, SRv6 End.U SID Sub-TLV ,and SRv6 LAN End.U SID Sub-TLV . 217 As discussed in [I-D.ietf-spring-srv6-network-programming], the node 218 with the SRv6 capability will maintain its local SID table. A Local 219 SID is generally composed of two parts, that is, LOC:FUNCT, or may 220 carry arguments at the same time, that is, LOC:FUNCT:ARGS. The 221 controller plane protocol can also use B:N to represent an LOC, where 222 B is SRv6 SID Locator Block and N to represent node N. In other 223 words, the structure of a complete SID is B:N:FUNCT:ARGS. 225 SRv6 SID Structure Sub-Sub-TLV [I-D.ietf-lsr-isis-srv6-extensions] or 226 SRv6 SID Structure Sub-TLV [I-D.ietf-lsr-ospfv3-srv6-extensions] is 227 used to advertise the length of each individual part of the SRv6 SID. 229 If a node advertised the compression domains which the node is in, it 230 SHOULD advertise the related SIDs with structure information, 231 otherwise the result optimized SID list will have to contain related 232 classical 128-bits SRv6 SID. 234 4. Advertising Endpoint Behaviors with U-Flavor 236 Endpoint behaviors are defined in 237 [I-D.ietf-spring-srv6-network-programming] 238 and[I-D.ietf-6man-spring-srv6-oam] . The codepoints for the Endpoint 239 behaviors are defined in the "SRv6 Endpoint Behaviors" registry 240 defined in [I-D.ietf-spring-srv6-network-programming]. For End, 241 End.X and End.T behaviors, they can also have PSP, USP and USD 242 variants. This document continues to extend the following new 243 flavors for End and End.X behaviors: 245 U32-Flavor: indicate the next SID is 32-bits IP address. 247 U16-Flavor: indicate the next SID is 16-bits IP address. 249 We can take regard the traditional behaviors that has not any 250 indication of next SID type as behaviors with U128-flavor. 252 To extend the above U related flavors for other endpoint behaviors, 253 such as VPN related SID and SFC related SID, is out the scope of this 254 document. 256 Note that a SID MUST NOT set two or more of the above flavors at the 257 same time, because these flavors is used to indicate the next SID 258 type in SRH, that is, the local SID entry must provide exact 259 indication for this purpose. 261 Each of the above U related flavors can be used combined with 262 existing PSP/USP/USD flavors. 264 5. Operations 266 Based on the IGP link-state database which contains U-SID 267 Encapsulation Capabilities and SID(s) per U-Flavors, a headend or 268 controller can firstly check which compression domains a computed SR 269 path crossed, then secondly select U-Flavor related SID to construct 270 an optimized E2E SID list. 272 The detailed description can refer to [I-D.mirsky-6man-unified-id-sr] 273 and [I-D.liu-idr-segment-routing-te-policy-complement]. 275 6. Security Considerations 277 Procedures and protocol extensions defined in this document do not 278 affect the security considerations discussed in [I-D.ietf-lsr-isis-sr 279 v6-extensions]and[I-D.ietf-lsr-ospfv3-srv6-extensions] . 281 7. IANA Considerations 283 TBD 285 8. Normative References 287 [I-D.cheng-spring-shorter-srv6-sid-requirement] 288 Cheng, W., Xie, C., Pang, R., Li, Z., Chen, R., Lijun, L., 289 Duan, X., and G. Mirsky, "Shorter SRv6 SID Requirements", 290 draft-cheng-spring-shorter-srv6-sid-requirement-01 (work 291 in progress), March 2020. 293 [I-D.ietf-6man-spring-srv6-oam] 294 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 295 Chen, "Operations, Administration, and Maintenance (OAM) 296 in Segment Routing Networks with IPv6 Data plane (SRv6)", 297 draft-ietf-6man-spring-srv6-oam-04 (work in progress), 298 March 2020. 300 [I-D.ietf-lsr-isis-srv6-extensions] 301 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 302 Z. Hu, "IS-IS Extension to Support Segment Routing over 303 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 304 (work in progress), April 2020. 306 [I-D.ietf-lsr-ospfv3-srv6-extensions] 307 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 308 "OSPFv3 Extensions for SRv6", draft-ietf-lsr- 309 ospfv3-srv6-extensions-00 (work in progress), February 310 2020. 312 [I-D.ietf-spring-srv6-network-programming] 313 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 314 Matsushima, S., and Z. Li, "SRv6 Network Programming", 315 draft-ietf-spring-srv6-network-programming-15 (work in 316 progress), March 2020. 318 [I-D.liu-idr-segment-routing-te-policy-complement] 319 Yao, L. and S. Peng, "BGP Extensions for Unified SID in TE 320 Policy", draft-liu-idr-segment-routing-te-policy- 321 complement-02 (work in progress), May 2020. 323 [I-D.mirsky-6man-unified-id-sr] 324 Cheng, W., Mirsky, G., Peng, S., Aihua, L., Wan, X., and 325 C. Wei, "Unified Identifier in IPv6 Segment Routing 326 Networks", draft-mirsky-6man-unified-id-sr-06 (work in 327 progress), March 2020. 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 335 S. Shaffer, "Extensions to OSPF for Advertising Optional 336 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 337 February 2016, . 339 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 340 for Advertising Router Information", RFC 7981, 341 DOI 10.17487/RFC7981, October 2016, 342 . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 349 Decraene, B., Litkowski, S., and R. Shakir, "Segment 350 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 351 July 2018, . 353 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 354 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 355 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 356 . 358 Authors' Addresses 360 Ran Chen 361 ZTE Corporation 362 No. 50 Software Ave, Yuhuatai Distinct 363 Nanjing 364 China 366 Email: chen.ran@zte.com.cn 368 Peng Shaofu 369 ZTE Corporation 370 No. 50 Software Ave, Yuhuatai Distinct 371 Nanjing 372 China 374 Email: peng.shaofu@zte.com.cn