idnits 2.17.1 draft-pl-spring-compr-path-recover-00.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 : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 34 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2020) is 1369 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) == Missing Reference: 'RFC8200' is mentioned on line 144, but not defined == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-07 -- No information found for draft-mirsky-6man-unified-id-sr - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.mirsky-6man-unified-id-sr' == Outdated reference: A later version (-07) exists of draft-decraene-spring-srv6-vlsid-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group Yao. Liu 3 Internet-Draft Shaofu. Peng 4 Intended status: Standards Track ZTE Corporation 5 Expires: December 30, 2020 June 28, 2020 7 SRv6 Compressed Path Recover Method 8 draft-pl-spring-compr-path-recover-00 10 Abstract 12 This document describes a path information recovery method for 13 compressed SRv6 segment lists. 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 December 30, 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Segment List Recover TLV . . . . . . . . . . . . . . . . . . 3 52 4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4.1. Shifting Method . . . . . . . . . . . . . . . . . . . . . 5 54 4.2. Stitching Method . . . . . . . . . . . . . . . . . . . . 7 55 4.3. Mapping Method . . . . . . . . . . . . . . . . . . . . . 8 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 60 7.2. Informative References . . . . . . . . . . . . . . . . . 9 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 63 1. Introduction 65 Segment routing (SR) [RFC8402] is a source routing paradigm that 66 explicitly indicates the forwarding path for packets at the ingress 67 node by inserting an ordered list of instructions, called 68 segments.Segment Routing can be deployed on the MPLS data plane by 69 encoding 32-bits SIDs in MPLS label stack [RFC8660]. It can also be 70 deployed on the IPv6 data plane by encoding a list of 128-bits SRv6 71 SIDs in IPv6 Segment Routing Extension Header (SRH)[RFC8754]. 73 Several proposals are introduced to reduce the overhead for both the 74 traffic volume and the network processor in SRv6. The main ideas of 75 them are basically to use a shorter ID associated with the complete 76 128 bit SID. The SRH does not carry complete path information after 77 compression, however, the transit and egress nodes may need to know 78 the complete SID information along the path in some scenarios such as 79 OAM. 81 This document describes a path information recovery method for 82 compressed SRv6 segment lists. 84 2. Overview 86 Several proposals are introduced to reduce the overhead for both the 87 traffic volume and the network processor in SRv6. The main ideas of 88 them are basically to use a shorter ID associated with the complete 89 128 bit SID. The method to establish such association could be 90 mapping,stitching, shifting, or translation. 92 Existing compression schemes use the 128 bit space as the carrier of 93 compressing SIDs. In the compressed SRH, the meaning of a 128 bit 94 segment may be: 96 a) an uncompressed SID 98 b) a unified prefix, followed by several short SIDs, and possibly 99 existing end marker or padding, which is generally set to value 0 101 c) short SIDs of the same type and length, possibly followed by end 102 marker or padding, which is generally set to value 0 104 So after receiving the SRv6 packets, the node or application cannot 105 obtain the complete path information according to segment list in SRH 106 any more. 108 3. Segment List Recover TLV 110 This document defines an SRH TLV called Segment List Recover TLV, 111 where, 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Type | Length | List ID | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | List Recover Info (optional) | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Figure 1: Segment List Recover TLV 123 List ID: 16 bits, identification of a complete path with local 124 significance. 126 List Recover Info: variable length. It provides auxiliary 127 information to recover the complete path information from the segment 128 list in the received SRH. 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 133 | Index | Range | BL | ST | count | Basic Compressed Description Unit 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 135 ~ ... ... ~ 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Figure 2: List Recover Info detailed structure 140 List Recover Info contains one or more Basic Compressed Description 141 Unit, where: 143 Index: 8-bit index, number of 128 bit unit remaining from the current 144 carrier, which is a bit like segments left([RFC8200], Section 4.4). 146 Index refers to the start of (consecutive) carrier(s) that contains 147 the compression information. If a segment list contains both 148 compressed carrier and complete SID, the index will skip the complete 149 SID. 151 Range: 8 bit.It indicates the number of consecutive 128-bit carrier 152 in the same format, starting from the carrier directed by the index. 154 In this way, if multiple consecutive carriers use the same format, 155 only one Basic Compressed Description Unit needs to be carried. 157 When range is set to 1, it indicates that the basic unit carries 158 informational of only one 128 bit carrier. 160 BL: It indicates the prefix length. When set to 0, it means that the 161 128 bit carrier does not carry prefix information but only contains 162 short SIDs. 164 ST:short SID type, 4 bits with following values: 166 0001: 32-bits SID 168 0010: 16-bits SID 170 Existing proposals mainly focus on the 16-bits and 32-bits short 171 SIDs, other values may be defined in the future. 173 count: 4 bits.It indicates the number of short SIDs in the 128 bit 174 carrier. 176 When the headend of the SR policy sends the SRv6 packet, it can 177 contain the TLV used to describe the above compression details in the 178 SRH.Upon receiving the above SRv6 packets, the transit node or egress 179 node can perform segment list restoration according to the TLV 180 carried in the SRH. 182 The restored SID list information can be used as an important 183 reference for constructing the reverse path, or used for displaying 184 to the user or for other OAM purposes. 186 This document provides two path restoration options: 188 a) The node locally maintains the mapping between the list ID and the 189 path information. Upon receiving the packet, the node identifies the 190 path corresponding to the SRH according to the list ID carried in the 191 SRH TLV. List Recover Info is not needed in this case. 193 b) According to the information carried in the list recover info, 194 combined with the segment list in the SRH, the node recovers the 195 complete path information. 197 It should be noticed that option b can't be used in reduced SRH. 199 4. Illustration 201 This section describes how to restore a complete path utilizing a 202 Segment List Recover TLV. 204 The current chapter focuses on option B combined with some 205 representative schemes. Option A will be discussed in the later 206 version. 208 4.1. Shifting Method 210 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] extends SRv6 211 Network Programming with a new type of SRv6 SID behavior. 213 A uSID carrier is a 128 bit SRv6 SID of format ....... 216 So the segment list may be encoded as figure 3 after compression. 218 It is consist of six 128-bit units. SID-1 is an uncompressed 128-bit 219 SID and is the first segment to be processed in the segment list. 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 222 | Block(64) | uSIDA(32) | uSIDB(32) | index=0 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 224 | Block(64) | uSIDA(32) | uSIDB(32) | index=1 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 226 | Block(32) | uSID7(32) | uSID8(32) | uSID9(32) | index=2 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 228 | Block(32) | uSID4(32) | uSID5(32) | uSID6(32) | index=3 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 230 | Block(32) | uSID1(32) | uSID2(32) | uSID3(32) | index=4 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 232 | SID-1(128 bit) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 235 Figure 3: segment list encoding example A 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type | Length | List ID=1 | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 242 | Index=4 | Range=3 | BL=32 |ST=0001|count=3| Basic Compressed Description Unit 1 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 244 | Index=1 | Range=2 | BL=64 |ST=0001|count=2| Basic Compressed Description Unit 2 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 247 Figure 4: Segment List Recover TLV encoding example A 249 Figure 4 shows the corresponding Segment List Recover TLV encoding of 250 the compressed segment list. 252 Basic Compressed Description Unit 1 has following components, where, 254 Index=4: It indicates that the compression information starting from 255 the 128-bit unit with index 4 is described in this Basic Compressed 256 Description Unit. 258 Range=3: It indicates that there are 3 128-bit unit of the same 259 structure described in this Basic Compressed Description Unit 261 BL=32: It indicates that the block length is 32 bit. 263 ST=0001: It indicates that the length of each short SID is 32 bit. 265 count=3: It indicates that this carrier contains 3 short SIDs. 267 The meaning of Basic Compressed Description Unit2 is similar, so it 268 will not be explained in details. 270 4.2. Stitching Method 272 The compression method of stitching is to extract the public prefix 273 information in the SIDs, the remaining part is short SID and stored 274 in SRH. The prefix and short SID are spliced into a complete 128-bit 275 address. 277 [I-D.decraene-spring-srv6-vlsid] and 278 [I-D.li-spring-compressed-srv6-np] use the stitching method. 279 Stitching is also one of the compression modes supported by 280 [I-D.mirsky-6man-unified-id-sr]. 282 Figure 5 shows a possible SRH encoding in stitching method. 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 285 | uncompressed SID(128 bit) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 287 | uSID1(32) | uSID2(32) | uSID3(32) | uSID4(32) | index=1 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 289 | uSID1(32) | uSID2(32) | uSID3(32) | uSID4(32) | index=2 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 291 | Block(96) | uSID1(32) | index=3 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 294 Figure 5: segment list encoding example B 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Length | List ID=1 | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 301 | Index=3 | Range=1 | BL=96 |ST=0001|count=1| Basic Compressed Description Unit 1 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 303 | Index=2 | Range=2 | BL=0 |ST=0001|count=4| Basic Compressed Description Unit 2 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 306 Figure 6: Segment List Recover TLV encoding example B 308 When restoring the path, the node will save the prefix used in the 309 current carrier, and stich the prefix, each short SID and possible 310 padding into a complete 128-bit address. If BL in the next Basic 311 Compressed Description Unit is not 0, it indicates that there's a new 312 prefix, and the node will replace the previous prefix with the new 313 prefix, and continue the processing. If BL is 0 as in unit 2 showed 314 in figure 6, the previous prefix will still be used. 316 SRH may also be used carry short SIDs without any prefix information. 317 In this case, when the node recovers segment list, it may obtain the 318 prefix from the source IP of the IPv6 header. 320 4.3. Mapping Method 322 In the mapping method, the short SID is no longer part of the 323 complete 128-bit address, unlike shifting or stitching. 325 Stitching is supported in [I-D.mirsky-6man-unified-id-sr]. 327 For the compression proposal using the mapping mode, option A can be 328 used to restore the segment list. 330 The node need to maintains the mapping between the list ID and the 331 path information. Upon receiving the packet, the node identifies the 332 path corresponding to the SRH according to the list ID carried in the 333 SRH TLV. The list ID can be assigned by a centralized controller or 334 by a node locally. 336 This will be further discussed in a future version of this document. 338 5. Security Considerations 340 The security requirements and mechanisms described in [RFC8402] and 341 [RFC8754] also apply to this document.This document does not 342 introduce any new security vulnerabilities. 344 6. IANA Considerations 346 TBD 348 7. References 350 7.1. Normative References 352 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 353 Filsfils, C., Camarillo, P., Cai, D., Voyer, D., Meilik, 354 I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman, 355 D., Liu, Y., and J. Guichard, "Network Programming 356 extension: SRv6 uSID instruction", draft-filsfils-spring- 357 net-pgm-extension-srv6-usid-07 (work in progress), May 358 2020. 360 [I-D.mirsky-6man-unified-id-sr] 361 Cheng, W., Mirsky, G., Peng, S., Aihua, L., Wan, X., and 362 C. Wei, "Unified Identifier in IPv6 Segment Routing 363 Networks", draft-mirsky-6man-unified-id-sr-06 (work in 364 progress), March 2020. 366 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 367 Decraene, B., Litkowski, S., and R. Shakir, "Segment 368 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 369 July 2018, . 371 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 372 Decraene, B., Litkowski, S., and R. Shakir, "Segment 373 Routing with the MPLS Data Plane", RFC 8660, 374 DOI 10.17487/RFC8660, December 2019, 375 . 377 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 378 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 379 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 380 . 382 7.2. Informative References 384 [I-D.decraene-spring-srv6-vlsid] 385 Decraene, B., Raszuk, R., Li, Z., and C. Li, "SRv6 vSID: 386 Network Programming extension for variable length SIDs", 387 draft-decraene-spring-srv6-vlsid-03 (work in progress), 388 March 2020. 390 [I-D.li-spring-compressed-srv6-np] 391 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 392 Guichard, J., Cong, L., and S. Peng, "Compressed SRv6 393 Network Programming", draft-li-spring-compressed- 394 srv6-np-02 (work in progress), February 2020. 396 Authors' Addresses 398 Liu Yao 399 ZTE Corporation 400 No. 50 Software Ave, Yuhuatai Distinct 401 Nanjing 402 China 404 Email: liu.yao71@zte.com.cn 406 Peng Shaofu 407 ZTE Corporation 408 No. 50 Software Ave, Yuhuatai Distinct 409 Nanjing 410 China 412 Email: peng.shaofu@zte.com.cn