idnits 2.17.1 draft-li-spring-srv6-ssid-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 is 1 instance of too long lines in the document, the longest one being 1 character 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 15, 2020) is 1442 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) -- Looks like a reference, but probably isn't: '0' on line 313 -- Looks like a reference, but probably isn't: '1' on line 315 == Unused Reference: 'I-D.draft-li-spring-compressed-srv6-np' is defined on line 476, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-15 -- No information found for draft-li-spring-compressed-SRv6-np - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.draft-li-spring-compressed-srv6-np' Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Li 3 Internet-Draft Z. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: November 16, 2020 May 15, 2020 7 Short SID for SRv6 8 draft-li-spring-srv6-ssid-00 10 Abstract 12 Segment Routing enables an operator or an application to specify a 13 packet processing program. When Segment Routing is applied to IPv6 14 data plane, the list of IPv6 SIDs in SRH makes overhead a big 15 challenge. 17 This document proposes Short SID (SSID) and Short SRH (SSRH), and the 18 operations with SSRH. The proposed solution tries to reduce the 19 overhead of SRv6 without defining new routing header. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and 25 "OPTIONAL" in this document are to be interpreted as described in BCP 26 14 [RFC2119] [RFC8174] when, and only when, they appear in all 27 capitals, as shown here. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 16, 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Short SID (SSID) . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Short SRH (SSRH) . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Operations with Short SRH . . . . . . . . . . . . . . . . . . 8 68 5.1. Ingress Node . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 9 70 5.3. Egress Node . . . . . . . . . . . . . . . . . . . . . . . 9 71 6. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8. Cross-domain Operation . . . . . . . . . . . . . . . . . . . 11 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 12. Normative References . . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Segment Routing [RFC8402] enables an operator or an application to 83 specify a packet processing program. SRv6 applies Segment Routing to 84 IPv6 data plane. A new routing header for IPv6, which is called 85 Segment Routing Header (SRH) [RFC8754] is defined to carry 128-bit 86 SIDs. 88 One big challenge for SRv6 is the overhead. We can explain why the 89 overhead should not be ignored in two scenarios. The first one is 90 long distance or large scale transmission such as end-to-end TE path. 91 It is hard for Network Processor to process the SRv6 packet if SRH 92 contains too many SIDs and the forwarding performance may be 93 affected. The second one is the scenario like IoT deployment, where 94 the payload is small and the energy on the device is limited. The 95 size of SRH may be bigger than the payload which may affect the pay 96 load efficiency and cause extra energy consumption. 98 This document proposes a short SID mechanism in order to reduce the 99 overhead of SRv6 by introducing Short SID (SSID). SSID contains 100 Short Node Identifier (SNID) and Short Function Identifier (SFID). 101 We consider SNID and SFID as two separate objects and compress them 102 separately. The mechanism defines no new routing header and can stay 103 compatibility with the existing SRH. 105 2. Terminology 107 The definitions of the SRv6 terms, such as SRv6, SID, SRH, locator 108 and function can be found in [RFC8754], [RFC8402], 109 [I-D.draft-ietf-spring-srv6-network-programming]. 111 This document introduces the following new terms: 113 SSID: Short Segment Identifier. 115 SNID: Short Node Identifier. 117 SFID: Short Function Identifier. 119 SSRH: Short Segment Routing Header. 121 3. Short SID (SSID) 123 The IPv6 DA contains 16 bytes SRv6 SID and can be separated into three 124 parts: locator, function, and argument. As for the argument, we 125 consider it as the accessory of function. This document omits 126 argument to make the description of SSID clear and simple. More 127 details will be contained in the next version of this document. 129 This document proposes a short SID mechanism in order to reduce the 130 overhead of SRv6. We compress locator and function separately. The 131 locator is compressed by abstracting common prefix which is only 132 carried in DA and the remaining part is SNID. The function is 133 compressed by setting the function ID allocation rules at the node 134 and only carry the valid bits in the SSRH. 136 Then the IPv6 DA can be separated into three parts: P-bytes common 137 prefix, N-bytes SNID, and F-bytes SFID. 139 0 16 bytes 140 +-----------------+--------+-------+--------+ 141 | Common Prefix | SNID | 0..0 | SFID | 142 +-----------------+--------+-------+--------+ 143 |<--------Locator--------->|<---Function--->| 145 0 16 bytes 146 +-----------------+--------+--------+-------+ 147 | Common Prefix | SNID | SFID | 0..0 | 148 +-----------------+--------+--------+-------+ 149 |<--------Locator--------->|<---Function--->| 151 Figure 1: IPv6 DA 153 The definition of common prefix in this document is similar with [I- 154 D.draft-li-spring-compressed-srv6-np]. The common prefix is the 155 common part among SIDs in the SID list. P is calculated by comparing 156 the difference of each SID with other SIDs on the SID list. 158 The remaining part in locator is called SNID. That is, locator is 159 consist of SNID and common prefix. In some cases common prefix can 160 be the SRv6 SID block in 161 [I-D.draft-ietf-spring-srv6-network-programming]. 163 The function part of the SRv6 SID is an opaque identification of a 164 local behavior bound to the SID, which is locally defined on the node 165 where it is executed. This document requires that the identifier 166 value of function is defined from 1. That is, if there are three 167 functions on the node, the function identifier should be: 01, 10, and 168 11. F is calculated by comparing the difference of each function ID 169 with other function IDs on the SID list. That is, F is the longest 170 bits of the valid bits among the function IDs. Then we can get the 171 F-bit SFID. In most cases, one byte is enough for coding the SFID. 173 The SFID can be the last part of SRv6 SID or after the SNID. SNID 174 and SFID form the SSID, which is carried in the SRH. 176 +----------+----------+ 177 | SNID | SFID | 178 +----------+----------+ 179 |<--------SSID------->| 181 Figure 2: SSID 183 For example, the common prefix is A::/48, the SNID is a 16 bits 184 value, and the SFID is a 8 bits value. Then the SSID, which is 185 carried in the SRH, is 24 bits. 187 0 6 8 15 16 bytes 188 +-------------------+-------+-----------------------+----+ 189 | Common Prefix | SNID | 0...0 |SFID| 190 +-------------------+-------+-----------------------+----+ 192 0 6 8 9 16 bytes 193 +-------------------+-------+----+-----------------------+ 194 | Common Prefix | SNID |SFID| 0...0 | 195 +-------------------+-------+----+-----------------------+ 197 Figure 3: 24 bits SSID in IPv6 DA 199 4. Short SRH (SSRH) 201 This document defines Short Segment Routing Header (SSRH) to carry 202 SSID. SSRH is not a new routing header type but a segment routing 203 header that is indicated by flag bit. SSRH can stay compatibility 204 with the existing SRH. 206 0 1 2 3 207 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 208 +---------------+---------------+---------------+---------------+ 209 | Next Header | Hdr Ext Len | Routing Type | Segment Left | 210 +---------------------------------------------------------------+ 211 | Last Entry |S|L| Flags |Pre Len|SNIDLen|SFIDLen| Tag | 212 +---------------------------------------------------------------+ 213 | Segment List[0] | . 214 +-------------------------------+---------------+---------------+ 215 . Segment List[1] | ... | 216 +-------------------------------+-------------------------------+ 217 | ... ... | 218 +-----------------------------------------------+---------------+ 219 | Segment List[n] | 220 +-----------------------------------------------+---------------+ 221 // // 222 // Optional Type Length Value objects (variable) // 223 // // 224 +---------------------------------------------------------------+ 226 Figure 4: Short Segment Routing Header 228 where: 230 o Next Header: Defined in [RFC8200] 232 o Hdr Ext Len: Defined in [RFC8200] 234 o Routing Type: 4 236 o Segment Left: Defined in [RFC8200] 238 o Last Entry: Contains the index (zero based), in the Segment List, 239 of the last element of the Segment List 241 o Flags: 8 bits of flags 243 0 1 2 3 4 5 6 7 244 +---------------+ 245 |S|L|U|U|U|U|U|U| 246 +---------------+ 248 U: Unused and for future use. Must be 0 on transmission and ignored 249 on receipt. 251 S: Short flag, set when the SRH carries the SSIDs. 253 1: the SRH carries SSIDs, the node should conduct corresponding 254 processing of SSRH. 256 0: the SRH carries normal 128-bit SIDs. 258 L: Length flag, set when S flag is 1 and the length of common prefix, 259 SNID, and SFID is carried in the SSRH. 261 1: the SSRH carries the length of common prefix, SNID, and SFID. The 262 processing of SSRH should be based on the length values. 264 0: the SSRH does not carries the length of common prefix, SNID, and 265 SFID. The length values can be configured by the control plane or by 266 predefined recommended values (e.g., the length of common prefix is 267 48 bits, the length of SNID is 16 bits, and the length of SFID is 8 268 bits). 270 o Pre Len: 4-bit unsigned integer, length of common prefix carried 271 in DA. 273 o SNID Len: 4-bit unsigned integer, length of SNIDs carried in SSRH. 275 o SFID Len: 4-bit unsigned integer, length of SFIDs carried in SSRH. 277 o Tag: 4-bit value to tag a packet as part of a class or group of 278 packets, e.g., packets sharing the same set of properties. When 279 Tag is not used at the source, it MUST be set to zero on 280 transmission. 282 o Segment List[0...n]: a list of Short SIDs and the length of SSID 283 is defined by SNID Len and SFID Len or by control plane or by 284 predefined configuration. 286 o TLV: Type Length Value (TLV) is described in [RFC8754]. 288 This document does not define new routing type. Instead, the S-flag 289 is used to indicate that the SRH contains SSID and the node should 290 conduct the corresponding operations with SSRH. 292 The Pre Len, SNID Len and SFID Len indicate how many bytes the common 293 prefix, SNID and SFID have and enable the ingress node to use 294 variable length. 296 Fixed length can also be used and the SSRH does not have to carry 297 length values. 299 1. The length of common prefix, SNID and SFID may be informed by 300 control plane. 302 2. The length of common prefix, SNID and SFID may be configured in 303 the protocol stack. 48-bit common prefix, 16-bit SNID, and 8-bit 304 FID are recommended and the SSRH only need to carry 24-bit SSID. 306 0 1 2 3 307 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 308 +---------------+---------------+---------------+---------------+ 309 | Next Header | Hdr Ext Len | Routing Type | Segment Left | 310 +-----------------------------------------------+---------------+ 311 | Last Entry |1|0| Flags | Tag | 312 +-------------------------------+---------------+---------------+ 313 | Segment List[0] | . 314 +-------------------------------+---------------+---------------+ 315 . Segment List[1] | ... | 316 +-------------------------------+-------------------------------+ 317 | ... ... | 318 +-----------------------------------------------+---------------+ 319 | Segment List[n] | 320 +-----------------------------------------------+---------------+ 321 // // 322 // Optional Type Length Value objects (variable) // 323 // // 324 +---------------------------------------------------------------+ 326 Figure 5: Short Segment Routing Header with length values in packet 328 5. Operations with Short SRH 330 5.1. Ingress Node 332 The SR domain ingress router has to insert SRH to the IPv6 packet and 333 if the domain supports SSRH, the S-flag should be set. If the length 334 of common prefix, SNID, and SFID are based on the length value 335 carried in the packet, the L-flag is set. If the length of common 336 prefix, SNID, and SFID are determined by the control plane or pre- 337 configuration, the L-flag is not set. 339 If the length values are carried in the SSRH, the ingress router has 340 to compare the SID list that steers the packet through the domain and 341 calculate the length values. The common prefix is the longest common 342 part (in byte) among the SID locators and the length of common prefix 343 is acquired. 345 There are two options to put the SFID in the SRv6 SID. 347 1. Option 1: the SFID is at the end of the SRv6 SID. There are 348 consequent zero bits between locator and SFID and the length of 349 locator can be acquired. Then the length of SNID can be 350 calculated. The length of SFID that should be carried in the 351 SSRH is the longest length among the SFIDs of the SIDs. These 352 length values are written in the SSRH. 354 2. Option 2: the SFID is after the locator of the SRv6 SID. The end 355 of SRv6 SID is padded with zero bits. The SNID and the SFID 356 cannot be separated clearly. The total length of SNID and SFID 357 can be calculated after the length of common prefix is acquired. 358 Either of the SNID Len filed or SFID Len filed can be used to 359 carry the total length of SNID and SFID. 361 The SSID is consist of SNID and SFID. Every SIDs in the SID list are 362 compressed into SSIDs which are written in the SSRH Segment List 363 successively. 365 5.2. Transit Node 367 The transit nodes in the SR domain have to update the IPv6 DA before 368 they forward the packets. The basic SRH operations are defined in 369 [RFC8754], the only difference is how to update the IPv6 DA. The 370 common prefix in the DA stays unchanged along the path in the domain. 371 The SNID and SFID need to be updated. The length of common prefix, 372 SNID, and SFID can be acquired via in-packet value, or pre- 373 configuration, or control plane. 375 If the method for locating SFID in the SRv6 SID is Option 1, then the 376 SNID is copied to the location after common prefix of the DA and the 377 SFID is copied to the end of the DA when updating the IPv6 DA. 379 If the method for locating SFID in the SRv6 SID is Option 2, then the 380 SNID and the SFID are copied to the location after common prefix 381 together. 383 5.3. Egress Node 385 No new operation is defined in this document at the egress node. 387 6. Control Plane 389 The length of the common prefix, SNID, and SFID can be carried in the 390 packet and no control plane extension is needed. While the length 391 values can also be configured by control plane. Control plane (such 392 as IS-IS) extensions are required to signal the length values. The 393 detailed definitions of the extension will be described in the next 394 version of this document. 396 7. Illustration 398 As illustrated in Figure 6, nodes A - F are SRv6 enabled nodes within 399 the network domain. A is the ingress router and B is the egress 400 router. A packet is forwarded along the path A-B-E-F-C-D, and the 401 SRv6 SID list contains the SID of E, F, and D, which is 403 [2001:DB8:B:5::1 405 2001:DB8:B:6::1 407 2001:DB8:B:4::2] 409 +---+ +---+ 410 | E +------+ F | 411 +-+-+ +-+-+ 412 | | 413 | | 414 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 415 |CE1+------+ A +------+ B +------+ C +------+ D +------+CE2| 416 +---+ +---+ +---+ +---+ +---+ +---+ 418 Figure 6: Illustration Topology 420 The flag field of SRH is 422 11000000 424 which means SSRH is enabled and the length values are carried in the 425 packet. 427 The common prefix is 2001:DB8:B::/56 and the length is 7 bytes. The 428 SNIDs of E, F and D are 5, 6 and 4 and the length is 1 bytes. The 429 SFIDs of E, F and D are 1, 1 and 2 and the length is 1 bytes. The 430 SSID in the SSRH is 2 bytes. The SSRH is 432 0 1 2 3 433 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 434 +---------------+---------------+---------------+---------------+ 435 | Next Header | Hdr Ext Len | Routing Type | Segment Left | 436 +---------------------------------------------------------------+ 437 | Last Entry |1 1 0 0 0 0 0 0|0 1 1 1|0 0 0 1|0 0 0 1| Tag | 438 +---------------------------------------------------------------+ 439 |0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 1|0 0 0 0 0 1 1 0|0 0 0 0 0 0 0 1| 440 +---------------------------------------------------------------+ 441 |0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0| 442 +---------------------------------------------------------------+ 443 // // 444 // Optional Type Length Value objects (variable) // 445 // // 446 +---------------------------------------------------------------+ 448 Figure 7: Illustration SSRH 450 8. Cross-domain Operation 452 TBD. 454 9. Security Considerations 456 TBD. 458 10. IANA Considerations 460 IANA is requested to allocated one bit in Segment Routing Header 461 Flags to indicate that the STH contains SSID and the node should 462 conduct the corresponding operations with SSRH. 464 11. Acknowledgements 466 TBD. 468 12. Normative References 470 [I-D.draft-ietf-spring-srv6-network-programming] 471 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 472 Matsushima, S., and Z. Li, "SRv6 Network Programming", 473 draft-ietf-spring-srv6-network-programming-15 (work in 474 prograss) , March 2020. 476 [I-D.draft-li-spring-compressed-srv6-np] 477 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 478 Guichard, J., Li, C., and S. Peng, "Compressed SRv6 479 Network Programming", draft-li-spring-compressed- 480 SRv6-np-02 (work in prograss) , February 2020. 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, 484 DOI 10.17487/RFC2119, March 1997, 485 . 487 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 488 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 489 May 2017, . 491 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 492 (IPv6) Spectification", RFC 8200 , July 2017. 494 [RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 495 Litkowski, S., and R. Shakir, "Segment Routing 496 Architecture", RFC 8402 , July 2018. 498 [RFC8754] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 499 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 500 (SRH)", RFC 8754 , March 2020. 502 Authors' Addresses 504 Taixin Li 505 Huawei Technologies 506 No. 156 Beiqing Rd 507 Beijing 100095 508 China 510 Email: litaixin@huawei.com 512 Zhe Chen 513 Huawei Technologies 514 No. 156 Beiqing Rd 515 Beijing 100095 516 China 518 Email: chenzhe17@huawei.com