idnits 2.17.00 (12 Aug 2021) /tmp/idnits19868/draft-li-spring-compressed-srv6-np-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 22 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 (February 25, 2020) is 809 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 496 -- Looks like a reference, but probably isn't: '1' on line 385 == Outdated reference: draft-ietf-6man-segment-routing-header has been published as RFC 8754 == Outdated reference: A later version (-18) exists of draft-ietf-lsr-isis-srv6-extensions-05 == Outdated reference: A later version (-13) exists of draft-ietf-pce-segment-routing-ipv6-03 == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgpls-srv6-ext-02 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-01 == Outdated reference: A later version (-17) exists of draft-ietf-idr-segment-routing-te-policy-08 == Outdated reference: draft-ietf-spring-srv6-network-programming has been published as RFC 8986 == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-01 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group Z. Li 3 Internet-Draft C. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: August 28, 2020 C. Xie 6 China Telecom 7 K. LEE 8 LG U+ 9 H. Tian 10 F. Zhao 11 CAICT 12 J. Guichard 13 Futurewei Technologies 14 C. Li 15 China Telecom 16 S. Peng 17 Huawei Technologies 18 February 25, 2020 20 Compressed SRv6 Network Programming 21 draft-li-spring-compressed-srv6-np-02 23 Abstract 25 Segment Routing can be applied to the IPv6 data plane by leveraging a 26 new type of Routing Extension Header, called Segment Routing Header 27 (SRH). However, the overhead introduced by SRH may be a challenge 28 for existing hardware, which may influence on the forwarding 29 performance and the payload efficiency. 31 This document defines a compressed SRv6 network programming mechanism 32 in order to reduce the overhead of SRv6 by introducing the Compressed 33 Segment Identifier (C-SID) and the Compressed SRH (C-SRH). The C-SRH 34 can be a new Routing Header or an enhancement of SRH. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on August 28, 2020. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 73 3. Compressed SID (C-SID) . . . . . . . . . . . . . . . . . . . 4 74 4. Compressed Segment Routing Header (C-SRH) . . . . . . . . . . 5 75 5. C-SRH Processing . . . . . . . . . . . . . . . . . . . . . . 10 76 6. Control Plane Consideration . . . . . . . . . . . . . . . . . 13 77 7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 14 78 7.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 15 79 7.2. Compressed SRv6 Forwarding Example . . . . . . . . . . . 15 80 8. Inter-domain Routing Using C-SRH . . . . . . . . . . . . . . 17 81 9. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 84 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 85 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 88 14.2. Informative References . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 Segment routing (SR) [RFC8402] is a source routing paradigm that 94 explicitly indicates the forwarding path for packets at the ingress 95 node by inserting an ordered list of instructions, called segments. 97 When segment routing is deployed on the IPv6 data plane, it is called 98 SRv6 [I-D.ietf-6man-segment-routing-header].An SRv6 Segment ID (SID) 99 is a 128-bit value, and it can be represented as LOC:FUNCT where LOC 100 is the L most significant bits and FUNCT is the 128-L least 101 significant bits [I-D.ietf-spring-srv6-network-programming]. L is 102 called the locator length and is flexible. Each network operator is 103 free to use the locator length it chooses. The LOC part of the SID 104 is routable and leads to the node which instantiates that SID. 106 For support of SR, a new routing header called Segment Routing Header 107 (SRH), which contains a list of SIDs and other information, has been 108 defined in [I-D.ietf-6man-segment-routing-header]. In use cases like 109 Traffic Engineering, an ordered SID List with multiple SIDs is 110 inserted into the SRH to steer packets along an explicit path. 112 However, the overhead of SIDs (16 bytes per SID) may be a challenge 113 for existing hardware processing, as the size of the SRH may affect 114 the forwarding performance. When the packet is small, the payload 115 efficiency is not ideal due to the large overhead of the SRH. When 116 the packet is large, the overhead of the SRH may cause the packet to 117 be dropped due to PMTU [RFC8200]. 119 This document defines a compressed SRv6 network programming mechanism 120 in order to reduce the overhead of SRv6 by introducing the Compressed 121 Segment Identifier (C-SID) and the Compressed SRH (C-SRH). The C-SRH 122 can be a new Routing Header or an enhancement of SRH, in either case, 123 compatibility with the existing SRH is maintained. 125 2. Terminology 127 This document makes use of the terms defined in 128 [I-D.ietf-6man-segment-routing-header], [RFC8402] and [RFC8200], and 129 the reader is assumed to be familiar with that terminology. This 130 document introduces the following new terms: 132 C-SRH: Compressed Segment Routing Header 134 C-SID: Compressed Segment Identifier 136 C-Tag: Compressed Tag 138 2.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 3. Compressed SID (C-SID) 148 This document defines a Compressed SID (C-SID) to carry the last 16 - 149 N bytes of the original SRv6 SID, where N is the length of the common 150 prefix among SIDs in the SID list. N is calculated by comparing the 151 difference of each SID with other SIDs on the SID list. 153 The common prefix part contains the common part of all Locators in 154 the SID list, while the C-SID contains the different part, if any, of 155 all Locators and the Function ID of an SRv6 SID. Generally, in an 156 SRv6 domain, the common prefix can be the SRv6 SID block as per 157 [I-D.ietf-spring-srv6-network-programming], and the C-SID consists of 158 the Node ID and Function ID. 160 The IPv6 DA contains a 128-bits (16 Bytes) SRv6 SID, and it can be 161 separated into two parts: the common prefix among all SIDs, and the 162 current C-SID on the SID list. 164 0 N 16 bytes 165 +--------------------------------------------------------------+ 166 | Common Prefix | C-SID | 167 +--------------------------------------------------------------+ 168 |<----------------- Locator ------------------->|<-FunctionID->| 169 |<--->| 170 | 171 Different part of Locator 173 Figure 1. C-SID in IPv6 DA 175 In this way, the common prefix is carried by the IPv6 DA only, and 176 the SIDs in the SID list will not carry the common prefix, but only 177 the last 16 - N bytes of the original SRv6 SID. 179 Therefore, this document does not define any new SRv6 segment types. 181 Editor's Note: A C-SID can be a fixed length value, such as 32 bits, 182 and actually authors suggest 32 bits. 184 Also, the C-SID does not have to be the last part of SRv6 SID. An 185 SRv6 SID may contains three parts: Common prefix, C-SID and argument. 186 By default, the argument is 0, and it is treated as padding. The 187 format is shown in Figure 2. 189 In this case, operators can allocate a appropriate length common 190 prefix for their networks. 192 For example, the Common Prefix is A::/48, the C-SID is a 32 bits 193 value, and the argument can be 48 bits zero, then only the 80 194 bits(Common prefix + C-SID) are used for routing, and only the C-SIDs 195 will be carried in the SRH and updated to DA. 197 0 Variable Length 32 bits 128 bits 198 +--------------------------------------------------------------+ 199 | Common Prefix | C-SID | Argument | 200 +--------------------------------------------------------------+ 201 |<-------- Locator ---------------->|<-FuctID->|<---Argument-->| 202 |<--->| 203 | 204 Different part of Locator 206 Figure 2. 32 bits C-SID in IPv6 DA 208 4. Compressed Segment Routing Header (C-SRH) 210 In order to carry the C-SID, this document defines the Compressed 211 Segment Routing Header (C-SRH). 213 The C-SRH can be a new Routing Header (with new Routing Type (TBD)) 214 or an enhancement of the SRH (Note: the latter is preferred in this 215 document). 217 The C-SRH provides a more efficient encoding mechanism for SRv6, and 218 is compatible with the existing SRv6 architecture. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Next Header | Hdr Ext Len | Routing Type | Segments Left| 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Last Entry |E| Flag | C-Tag | Tag | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Segment List[0](16 or 16 - C-Tag bytes) | 228 . ... . 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Segment List[1](16 - C-Tag bytes) | 231 . ... . 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | ... | 234 . ... . 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Segment List[n](16 - C-Tag bytes) | 237 . ... . 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Optional Padding to align with 64 bits Boundary ... 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 // // 242 // Optional Type Length Value objects (variable) // 243 // // 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 3. Compressed Segment Routing Header 248 where: 250 o Next Header: Defined in [RFC8200] 252 o Hdr Ext Len: Defined in [RFC8200] 254 o Routing Type: 4 when C-SRH is an enhancement of SRH, or new type 255 (TBD) when C-SRH is a new Routing Header. 257 o Segments Left: Defined in [RFC8200] 259 o Last Entry: contains the index (zero based), in the Segment List, 260 of the last element of the Segment List. 262 o Flags: 264 0 1 2 3 4 5 6 7 265 +-+-+-+-+-+-+-+-+ 266 |E|U U U U U U U| 267 +-+-+-+-+-+-+-+-+ 269 U: Unused and for future use. MUST be 0 on transmission and 270 ignored on receipt. 272 E: Exclude flag, set when the last SID is excluded in compression. 274 1: the last SID is excluded in compression, and it is a 16 275 bytes (128 bits) value 277 0: the last SID is included in compression, and it is a 278 16 - C-Tag bytes value 280 o C-Tag: 4-bit unsigned integer to indicate the length of the common 281 prefix. Therefore, the length of the C-SID in C-SRH is 16 - C-Tag 282 bytes except the last segment if and only if the E-flag is set. 283 When the C-Tag is 0, the length of C-SIDs in C-SRH is 16 bytes, 284 which is compatible with the existing SRH 285 [I-D.ietf-6man-segment-routing-header]. 287 o Tag: 12 bits value to tag a packet as part of a class or group of 288 packets, e.g., packets sharing the same set of properties as per 289 [I-D.ietf-6man-segment-routing-header]. 291 o Segment List[0]: 16 bytes (128 bits ) IPv6 address when E-flag is 292 set, and last 16 - C-Tag bytes of SID when E-flag is unset. 294 o Segment List[n]: a compressed SRv6 SID, which is the last 16 - 295 C-Tag bytes value of the original nth SRv6 SID. The Segment List 296 is encoded starting from the last segment of the SR Policy, i.e., 297 the first element of the segment list (Segment List [0]) contains 298 the last segment of the SR Policy, the second element contains the 299 penultimate segment of the SR Policy and so on. 301 o Type Length Value (TLV) are described in 302 [I-D.ietf-6man-segment-routing-header]. 304 In some use cases, the last SID may be a normal SID, which has a 305 different prefix against all other SIDs, so it can be excluded in 306 C-SID generation for better compression. 308 The E-flag indicates whether the last SID is excluded in compression. 309 When E-flag is set, Segment List[0] will carry the original SID, 310 otherwise, it carries the compressed SID, i.e. the last 16 - C-Tag 311 bytes of the original Segment List[0]. 313 Padding is needed after the SID List[Last entry] to align with 64 314 bits. 316 Editor's Note: The authors had consided that there are some 317 mechanisms to indicate compression, authors would like to have the 318 comments from the working group, to see which option is the best, so 319 welcome to send your comments. 321 1. Option 1: Compression Tag: C-tag in SRH 323 * Compression tag indicates the length of Common prefix 324 explicitly. 326 * Indicate the length of C-SID as well, if the length of C-SID 327 is a well-known length value. 329 * No need to modify the control plane to distribute new type of 330 SIDs. 332 * SRH is modified, some bits are needed. 334 * A SID can be used for normal SRv6 routing or Compression SRv6 335 routing. 337 * New SID space for compression is optional. 339 2. Option 2: Compression Flag: C-flag in SRH 341 * C-flag indicates compression, and the length of common prefix 342 is learned from the control plane or configuration. 344 * Indicate the length of C-SID as well, if the length of C-SID 345 is a well-known length value. 347 * Need to distribute the length of Common prefix or configure it 348 in the SRv6 domain. 350 * SRH is modified, a bit in flag for indicating compression is 351 needed. 353 * A SID can be used for normal SRv6 routing or Compression SRv6 354 routing. 356 * New SID space for compression is optional. 358 3. Option 3: Compression Flavor/SID/Locator/SID Space: C Flavor/C 359 Type in Control plane 361 * New compression type of SIDs or SIDs with C flavor, they 362 should be distributed via control plane, such as IGP. 364 * The format of SID should be distributed via control plane, 365 such as the length of common prefix. 367 * SRH is not modified. 369 * C-SID is used for compression SRv6 routing only. 371 * New SID space for compression is required. 373 The format of C-SRH of Option 2 and 3 are shown below. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Next Header | Hdr Ext Len | Routing Type | Segments Left| 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Last Entry |C| Flag | Tag | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Segment List[0](N bytes) | 383 . ... . 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Segment List[1] (N bytes) | 386 . ... . 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | ... | 389 . ... . 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Segment List[n](N bytes) | 392 . ... . 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Optional Padding to align with 64 bits Boundary ... 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 // // 397 // Optional Type Length Value objects (variable) // 398 // // 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Figure 4. Compressed Segment Routing Header with C-flag 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Next Header | Hdr Ext Len | Routing Type | Segments Left| 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Last Entry | Flag | Tag | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Segment List[0](N bytes) | 411 . ... . 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Segment List[1](N bytes) | 414 . ... . 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | ... | 417 . ... . 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Segment List[N](N bytes) | 420 . ... . 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Optional Padding to align with 64 bits Boundary ... 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 // // 425 // Optional Type Length Value objects (variable) // 426 // // 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 5. C-SRH without changing Common header of SRH 431 5. C-SRH Processing 433 The compressed SID List can be generated by the ingress node by 434 comparing the SIDs to get the C-Tag value according to the length of 435 the common prefix. The compressed SID List can also be generated by 436 a Controller and be sent to the ingress node, and the necessary 437 protocol extensions for this are outside the scope of this document. 438 (Note: The former is preferred in this document) 440 When the ingress node applies SRv6 policy to packets, a C-SRH can be 441 encapsulated in a new IPv6 header (Encapsulation Mode). The first 442 SID is carried along with the common prefix in the DA, and the 443 remaining C-SIDs are carried in the SID List of the C-SRH. The last 444 SID is inserted according to the E-flag. 446 When an SRv6 endpoint node receives the packet, the node will follow 447 the same processing procedure as with an SRH, that is, to inspect 448 whether the DA is a local SID or not, if yes, then process the SID 449 according to its function. Otherwise, it will perform regular IPv6 450 forwarding. 452 When the DA is a local SID, then the node will process the C-SRH and 453 the C-SIDs, and the current C-SID on the segment-list will replace 454 the last 16 - C-Tag bytes of the IPv6 DA. 456 Regarding the last SID, if the E-flag is set, the entire 128 bits of 457 Segment List[0] is updated to IPv6 DA. Otherwise, the C-SID will be 458 updated to replace the last 16 - C-Tag bytes of IPv6 DA. After 459 updating the IPv6 DA, the packet will be forwarded accordingly. 461 The pseudo code of C-SRH processing is shown below. 463 Editor's Note: The pseudo code will be updated when the options of 464 Compression SRv6 NP are converged. 466 01. When a C-SRH is processed { 467 02. If Segments Left is equal to zero { 468 03. Proceed to process the next header in the packet, 469 whose type is identified by the Next Header field in 470 the Routing header. 471 04. } 472 05. Else { 473 06. If local configuration requires TLV processing { 474 07. Perform TLV processing 475 08 //If E-flag is unset: 476 09. // TLV begins at SID length + Padding Length 477 10. // SID Length = Last Entry * (16 - C-Tag) 478 11. // Padding Length = 8 - Last Entry * (16 - C-Tag)%8 479 12. //Else: 480 // TLV begins at SID length + Padding Length 481 13. // SID Length = Last Entry * (16 - C-Tag) + C-Tag 482 14. If (Segments Left is greater than (Last Entry+1)) { 483 15. Send an ICMP Parameter Problem, Code 0, message to 484 the Source Address, pointing to the Segments Left 485 field, and discard the packet. 486 16. } 487 17. Else { 488 18. Decrement Segments Left by 1. 489 19. if Segments Left > 0 or Segments Left = 0 and E-flag = 0: 490 20. // Update the C-SID to the DA 491 21. Copy Segment List[Segments Left] from the SRH to 492 replace the last 16 - C-Tag bytes of 493 destination address of the IPv6 header. 494 22. else: 495 23. // Segment Left = 0 and E-flag = 1 496 // Segment List[0] is a 16 bytes value. 497 24. Copy Segment List[Segments Left] from the SRH to 498 destination address of the IPv6 header. 499 25. If the IPv6 Hop Limit is less than or equal to 1 { 500 26. Send an ICMP Time Exceeded -- Hop Limit Exceeded in 501 Transit message to the Source Address and discard 502 the packet. 503 27. } 504 28. Else { 505 29. Decrement the Hop Limit by 1 506 30. Resubmit the packet to the IPv6 module for 507 transmission to the new destination. 508 31. } 509 32. } 510 33. } 511 34. } 513 6. Control Plane Consideration 515 Editor's note: Control Plane consideration will be described in 516 separate drafts in the future. Note that, some extensions may be not 517 needed in some Compression options. 519 For indicating compression, the node should advertise the 520 capabilities of SRv6 compression via control plane. A C-flag should 521 be added in: 523 o SRv6 Capabilities sub-TLV in IS-IS 524 [I-D.ietf-lsr-isis-srv6-extensions] 526 o SRv6-Capabilities TLV in OSPF 527 [I-D.li-ospf-ospfv3-srv6-extensions], 529 o OPEN Object/PATH-SETUP-TYPE-CAPABILITIES TLV/SRv6 Capabilities 530 sub-TLV in PCEP [I-D.ietf-pce-segment-routing-ipv6] 532 For distributing the C-SID in control plane, the C-flag should be 533 added to the following TLV or sub-TLV in IGP/BGP/BGP-LS and PCEP. 535 o IS-IS [I-D.ietf-lsr-isis-srv6-extensions]: 537 * SRv6 Locator TLV, when C-flag is set, the Locator Block length 538 is less than 96 if the C-SID is a 32 bits value. 540 * SRv6 END.X/ LAN END.X sub-TLV 542 o OSPF [I-D.li-ospf-ospfv3-srv6-extensions] 544 * SRv6 Locator TLV, when C-flag is set, the Locator Block length 545 is less than 96 if the C-SID is a 32 bits value. 547 * SRv6 END.X/ LAN END.X sub-TLV , when C-flag is set, the Locator 548 Block length is less than 96 if the C-SID is a 32 bits value. 550 o BGP [I-D.ietf-bess-srv6-services] 552 * SRv6 SID Information sub-TLV, when C-flag is set, the Locator 553 Block length is less than 96 if the C-SID is a 32 bits value. 555 o BGP-LS [I-D.ietf-idr-bgpls-srv6-ext] 557 * SRv6 Link Attributes: SRv6 END.X SID TLV/LAN END.X SID TLV, 558 when C-flag is set, the Locator Block length is less than 96 if 559 the C-SID is a 32 bits value. 561 * SRv6 Prefix Attributes: SRv6 Locator TLV, when C-flag is set, 562 the Locator Block length is less than 96 if the C-SID is a 32 563 bits value. 565 * SRv6 SID Attributes: SRv6 Endpoint Function TLV, when C-flag is 566 set, the Locator Block length is less than 96 if the C-SID is a 567 32 bits value. 569 * SRv6 SID Attributes: SRv6 BGP Peer Node SID TLV, when C-flag is 570 set, the Locator Block length is less than 96 if the C-SID is a 571 32 bits value. 573 For distributing SRv6 Policy with compression SIDs, a C-flag should 574 be added in BGP and PCEP. 576 o BGP SR Policy [I-D.ietf-idr-segment-routing-te-policy] 578 * SRv6 Segment List sub-TLV, when C-flag is set, the Locator 579 Block length is less than 96 if the C-SID is a 32 bits value. 580 Candidate path and SR Policy level's extensions will be 581 described in the future revision. 583 * Segment sub-TLV, when C-flag is set, the Locator Block length 584 is less than 96 if the C-SID is a 32 bits value. The entire 585 SID is still carried in the SR Policy, while the C-flag will 586 indicate this is a compression SID with C-SID. 588 + Type 2: SRv6 SID 590 + Type 9: IPv6 Node addr with opt SRv6 SID 592 + Type 10: IPv6 addr+intf ID for Local and remote pair for 593 SRv6 with opt SID 595 o PCEP 597 * PATH-SETUP-TYPE TLV [RFC8408]: When PST is 2, the the C-flag 598 indicates the SID list of the Path should be Compression SID. 600 * SRv6 ERO Subobject [I-D.ietf-pce-segment-routing-ipv6] 602 * SRv6 RRO Subobject [I-D.ietf-pce-segment-routing-ipv6] 604 7. Illustration 606 This section describes a simple example to illustrate the usage of 607 C-SID. Similar to [I-D.filsfils-spring-srv6-net-pgm-illustration], 608 in order to ease the reading of the example, we introduce a simple 609 reference diagram and simplified SID allocations. 611 Editor's note: the following part will be updated accordingly when 612 the compression option is converged in WG. 614 7.1. Reference Diagram 616 Nodes 1 - 8 are SRv6 enabled nodes within the network domain. 618 Nodes CE1, CE2, and CE3 are outside the domain. 620 CE1 and CE2 are tenants of VPN 10. 622 Nodes 1 and 8 act as PE respectively to nodes CE1 and CE3. 624 All the links within the domain have the same IGP metric. 626 The IGP metric shortest-path from 1 to 8 is 1-2-7-8, while the 627 latency-metric shortest-path from 1 to 8 is 1-2-3-4-5-6-7-8. 629 CE2 630 \ 631 4------5 632 | | 633 +-----3------6 634 | | / | 635 | | / | 636 | |/ | 637 Tenant10 CE1---1-----2------7---8---CE3 Tenant10 with 638 IPv4 20/8 640 Figure 3: Reference topology 642 7.2. Compressed SRv6 Forwarding Example 644 This section describes a simple example to show how efficiently C-SRH 645 can reduce the overhead of SRv6. 647 In order to ease the reading of the example, it is better to 648 introduce a simplified SID allocation schema. We assume: 650 o B::/112 is dedicated to the internal SRv6 SID space, which is the 651 common prefix. Therefore, the C-SID is a 16-bit value. 653 o A locator expressed in 120 bits and a function expressed in 8 654 bits. 656 o Node k has B::0k/120 for its local SID space. Its SIDs will be 657 explicitly allocated from that block. 659 o Node k advertises B::0k/120 in its IGP. 661 o Function 01 represents the End function with PSP support. 663 o B::0k01 represents the End function with PSP support allocated by 664 node K, such as B::0601 represents the End function with PSP 665 support allocated by node 6. 667 o B::0810 is an END.DT4 SID initiated by node 8, which is associated 668 with the VRF10. 670 In SRH based SRv6, the PE 1 encapsulates the packets from CE1 to CE3 671 in an outer IPv6 header with DA = B::0201 and SRH (B::0810, B::0701, 672 B::0601, B::0501, B::0401, B::0301, B::0201; SL=6; NH=4). 674 675 follows the latency-metric shortest-path. The total length of SRH is 676 8+16*7=120 bytes. 678 In Compressed SRv6, PE 1 encapsulates the packets from CE1 to CE3 in 679 an outer IPv6 header with DA = B::0201 and C-SRH (0810, 0701, 0601, 680 0501, 0401, 0301, 0201, SL=6; NH=4) with E-flag unset. The C-Tag is 681 14, since the length of the common prefix is 112 bits. Therefore, 682 the total length of C-SRH is 8 + (16-14)*7 = 22 bytes, reducing the 683 encapsulation overhead by 98 bytes (81.7% less overhead than SRH) or 684 87.5% reduction in SIDs overhead. 686 The packet leaves node 1 to node 2 according to the FIB associated 687 with the IPv6 DA B::0201. The packet can be presented as: 689 (A::1, B::0201) 690 (0810, 0701, 0601, 0501, 0401, 0301, 0201, SL=6; NH=4) 691 (CE1, CE3) 693 When 2 receives the packet, 2 matches B::0201 in its "My SID Table" 694 and executes the END function behavior to update the IPv6 DA. Since 695 the updated SL is greater than 0, and the C-Tag is 14, then it copies 696 the C-SID that is a 2 bytes value to replace the last 2 bytes of the 697 IPv6 DA, and then forwards the packet according to the new IPv6 DA 698 B::0301. The packet can be presented as: 700 (A::1, B::0301) 701 (0810, 0701, 0601, 0501, 0401, 0301, 0201, SL=5; NH=4) 702 (CE1, CE3) 704 Like node 2, the nodes 3, 4, 5, and 6 perform the END function 705 behavior to update the IPv6 DA with the corresponding C-SID and then 706 forward the packet by looking up the IPv6 DA in their FIB 707 accordingly. Therefore, the packet leaving node 6 can be presented 708 as: 710 (A::1, B::0701) 711 (0810, 0701, 0601, 0501, 0401, 0301, 0201, SL=1; NH=4) 712 (CE1, CE3) 714 When 7 receives the packet, 7 matches B::0701 in its "My SID Table" 715 and executes the END function behavior to update the IPv6 DA. Since 716 the updated SL is 0 and E-flag is unset, then it copies the C-SID 717 that is a 2 bytes value to replace the last 2 bytes of the IPv6 DA. 718 Also, the C-SRH is popped since the B::0701 is an END SID with PSP 719 flavor. Node 7 then performs a lookup on the updated IPv6 DA B::0810 720 to forward the packet along the shortest path to node 8. The packet 721 can be presented as: 723 (A::1, B::0810) 724 (CE1, CE3) 726 When 8 receives the packet, 8 matches B::0810 in its "My SID Table" 727 and executes the END.DT4 function behavior to sends the IP packet 728 (CE1, CE3) to its VPN destination. 730 This example illustrates the procedure of C-SRH based SRv6 731 forwarding, and shows that the longer the common prefix, the more the 732 SRv6 overhead can be reduced. More benefits are described in section 733 7. 735 8. Inter-domain Routing Using C-SRH 737 Considering privacy and security of SRv6 domain, when SRv6 is used 738 for inter-domain routing, the detailed SIDs will not be leaked 739 between domains, and the Binding SID [RFC8402] SHOULD be used. The 740 typical inter-domain using SRv6 is illustrated in Figure 4. 742 When receiving the packet from CE1 to CE2, the Ingress node of SRv6 743 domain A can generate an SRv6 packet with SID List . 746 BSID1 is bound to an SR Policy, which contains a list of SID list in 747 SRv6 Domain B, for example [B1::1, B2::1, B3::1, B4::1, B5::1]. 749 Similarly, BSID2 is bound to an SR Policy in SRv6 Domian C, for 750 example [C1::1, C2::1, C3::1, C4::1, C5::1]. 752 VPN1 SID can be an END.DT4 SID associated with CE2. 754 In this way, the SIDs should be inserted at the ingress node are 755 reduced from 11 to 3. 757 BSID1 BSID2 VPN1 758 +---------+ +---------+ +---------+ 759 | | | | | | 760 CE1---*---------*----------*-*-*-*-*-*--------*-*-*-*-*-*---CE2 761 | | | | | | 762 +---------+ +---------+ +---------+ 763 SRv6 Domain A SRv6 Domain B SRv6 Domain C 765 (A1::1,BSID1) 766 (VPN1,BSID2,BSID1) 767 (CE1, CE2) 769 Figure 4.SRv6 Inter-domain Routing using BSID 771 Normally, when a BSID is processed , a new IPv6 and SRH will be added 772 to the packet, and the SRH carries the SID list representing the sub- 773 path of this domain. C-SRH can be used to carry Compressed SID list 774 within the SRv6 domain for reducing the overhead of SRv6. 776 In this way, a Binding SID can be associated with an SR Policy, which 777 contains a C-SID list to be carried by a C-SRH. 779 Therefore, in inter-domain SRv6 routing, C-SRH can be used in each 780 domain, while the SRH is used for inter-domian. In addition, if the 781 common prefixs of SIDs in SRH can be compressed, C-SRH can be used 782 for carring these SIDs as well. 784 9. Benefits 786 1. Seamless integration with SRv6 Network Programming 788 o No new type (Functions, such as END) of SRv6 SIDs is defined. 789 A C-SID is a sub-set of an SRv6 SID. 791 o Does not redefine the IPv6 address space nor requires any 792 specific IPv6 space. 794 2. Support for full set of SRv6 functionalities 795 o Full set of SRv6 functionality (BE, Loose TE and Strict TE, etc.) 796 are supported without any extra route advertisements. 798 o Function ID information is maintained. 800 3. Control-Plane friendly 802 o No need to make any extensions in Control-Plane to 803 advertise new type of SIDs or binding information. 805 o No indexed mapping table is required 807 o No routing extension is required. 809 o No new route advertisement is required if without new Locators 811 4. Hardware-friendly 813 o Hardware has the mature capability to overwrite the IPv6 DA. 815 o Avoids any extra lookup in indexed mapping table 817 5. Efficient MTU overhead 819 o C-SRH has the smallest MTU overhead among alternative solutions 820 (VxLAN with SR-MPLS, CRH, uSID), when all the Segment endpoint 821 nodes information is maintained in the packet. 823 6. Scalable SR TE 825 o 8 C-SIDs can be carried in 128 bits when C-SID is 16 bits value 827 o 16 Segment endpoint nodes (1 in DA and 16 in C-SRH including 828 the one in DA) in 40 bytes of overhead. 829 o T.Encaps with a C-SRH of 40 bytes (8 fixed + 2 * 16 830 bytes) 832 o ALL C-SIDs are maintained in C-SRH, which can be used 833 for recording the explicit routing path. 835 7. Saving IPv6 address 837 o Very limited IPv6 address are needed for SID space. Longer 838 Common Prefix means smaller IPv6 address burning and 839 smaller overhead of SRv6. 841 o Very easy to meet the requirement of C-SRH since any operator 842 or person can offer a 112/, 80/ or even 64/ prefix. 844 10. IANA Considerations 846 TBD 848 11. Security Considerations 850 TBD 852 12. Contributors 854 Zhibo Hu 855 Huawei Technologies 856 huzhibo@huawei.com 858 Zhongzheng Wang 859 Huawei Technologies 860 wangzhongzhen@huawei.com 862 Bing Liu 863 Huawei Technologies 864 remy.liubing@huawei.com 866 Yang Xia 867 Huawei Technologies 868 yolanda.xia@huawei.com 870 Jianwei Mao 871 Huawei Technologies 872 MaoJianwei@huawei.com 874 13. Acknowledgements 876 14. References 878 14.1. Normative References 880 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 881 Requirement Levels", BCP 14, RFC 2119, 882 DOI 10.17487/RFC2119, March 1997, 883 . 885 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 886 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 887 May 2017, . 889 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 890 (IPv6) Specification", STD 86, RFC 8200, 891 DOI 10.17487/RFC8200, July 2017, 892 . 894 [I-D.ietf-6man-segment-routing-header] 895 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 896 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 897 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 898 progress), October 2019. 900 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 901 Decraene, B., Litkowski, S., and R. Shakir, "Segment 902 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 903 July 2018, . 905 [I-D.ietf-lsr-isis-srv6-extensions] 906 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 907 Z. Hu, "IS-IS Extension to Support Segment Routing over 908 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-05 909 (work in progress), February 2020. 911 [I-D.li-ospf-ospfv3-srv6-extensions] 912 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 913 "OSPFv3 Extensions for SRv6", draft-li-ospf- 914 ospfv3-srv6-extensions-07 (work in progress), November 915 2019. 917 [I-D.ietf-pce-segment-routing-ipv6] 918 Negi, M., Li, C., Sivabalan, S., Kaladharan, P., and Y. 919 Zhu, "PCEP Extensions for Segment Routing leveraging the 920 IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-03 921 (work in progress), October 2019. 923 [I-D.ietf-idr-bgpls-srv6-ext] 924 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 925 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 926 State Extensions for SRv6", draft-ietf-idr-bgpls- 927 srv6-ext-02 (work in progress), January 2020. 929 [I-D.ietf-bess-srv6-services] 930 Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, 931 S., and J. Rabadan, "SRv6 BGP based Overlay services", 932 draft-ietf-bess-srv6-services-01 (work in progress), 933 November 2019. 935 [I-D.ietf-idr-segment-routing-te-policy] 936 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 937 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 938 Routing Policies in BGP", draft-ietf-idr-segment-routing- 939 te-policy-08 (work in progress), November 2019. 941 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 942 Hardwick, "Conveying Path Setup Type in PCE Communication 943 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 944 July 2018, . 946 14.2. Informative References 948 [I-D.ietf-spring-srv6-network-programming] 949 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 950 Matsushima, S., and Z. Li, "SRv6 Network Programming", 951 draft-ietf-spring-srv6-network-programming-10 (work in 952 progress), February 2020. 954 [I-D.filsfils-spring-srv6-net-pgm-illustration] 955 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 956 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 957 J. Leddy, "Illustrations for SRv6 Network Programming", 958 draft-filsfils-spring-srv6-net-pgm-illustration-01 (work 959 in progress), August 2019. 961 Authors' Addresses 963 Zhenbin Li 964 Huawei Technologies 965 Huawei Campus, No. 156 Beiqing Rd. 966 Beijing 100095 967 China 969 Email: lizhenbin@huawei.com 971 Cheng Li 972 Huawei Technologies 973 Huawei Campus, No. 156 Beiqing Rd. 974 Beijing 100095 975 China 977 Email: chengli13@huawei.com 979 Chongfeng Xie 980 China Telecom 981 China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District 982 Beijing 983 China 985 Email: xiechf.bri@chinatelecom.cn 987 Kihoon LEE 988 LG U+ 989 71, Magokjungang 8-ro, Gangseo-gu 990 Seoul 991 Republic of Korea 993 Email: soho8416@lguplus.co.kr 995 Hui Tian 996 CAICT 997 Beijing 998 China 1000 Email: tianhui@caict.ac.cn 1002 Feng Zhao 1003 CAICT 1004 Beijing 1005 China 1007 Email: zhaofeng@caict.ac.cn 1009 James N Guichard 1010 Futurewei Technologies 1011 2330 Central Express Way 1012 Santa Clara 1013 USA 1015 Email: james.n.guichard@huawei.com 1017 Cong Li 1018 China Telecom 1019 China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District 1020 Beijing 1021 China 1023 Email: licong.bri@chinatelecom.cn 1025 Shuping Peng 1026 Huawei Technologies 1027 Huawei Campus, No. 156 Beiqing Rd. 1028 Beijing 100095 1029 China 1031 Email: pengshuping@huawei.com