idnits 2.17.1 draft-cl-spring-generalized-srv6-np-01.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 7 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2020) is 1507 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: 'I-D.filsfils-spring-srv6-net-pgm-illustration' is defined on line 1295, but no explicit reference was found in the text == Unused Reference: 'I-D.tian-spring-srv6-deployment-consideration' is defined on line 1302, but no explicit reference was found in the text == Unused Reference: 'I-D.lc-6man-generalized-srh' is defined on line 1315, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-12 == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-01 == Outdated reference: A later version (-08) exists of draft-tian-spring-srv6-deployment-consideration-01 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-04 == Outdated reference: A later version (-03) exists of draft-lc-6man-generalized-srh-00 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group W. Cheng 3 Internet-Draft China Mobile 4 Intended status: Standards Track Z. Li 5 Expires: September 10, 2020 C. Li 6 Huawei Technologies 7 C. Xie 8 C. Li 9 China Telecom 10 H. Tian 11 F. Zhao 12 CAICT 13 March 9, 2020 15 Generalized SRv6 Network Programming 16 draft-cl-spring-generalized-srv6-np-01 18 Abstract 20 As the deployment of SRv6, some new requirements are proposed, such 21 as SRv6 compression, transporting over SR-MPLS/MPLS and IPv4 domains. 22 Therefore, it is necessary to consider other types of segments or 23 sub-paths in the end-to-end SRv6 network programming. 25 This document proposes Generalized Segment Routing over IPv6 (G-SRv6) 26 Networking Programming, which supports to encode multiple types of 27 Segments in a SRH, called Generalized SRH (G-SRH). These Segments 28 can be called Generalized Segment, and the ID can be Generalized 29 Segment Identifier (G-SID), which may include an SRv6 SID(128 bits), 30 C-SIDs, MPLS labels, or IPv4 tunnel information. 32 This document also defines the mechanisms of Generalized SRv6 33 Networking Programming and the requirements of related protocol 34 extensions of control plane and data plane. 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 September 10, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 73 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Crossing C-SRv6 Domains . . . . . . . . . . . . . . . . . 5 75 3.2. Crossing SR-MPLS Domains . . . . . . . . . . . . . . . . 7 76 3.3. Crossing IPv4 Domains . . . . . . . . . . . . . . . . . . 8 77 4. Concept of Generalized SRv6 . . . . . . . . . . . . . . . . . 9 78 4.1. SRv6 G-SID . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.2. Compression G-SID . . . . . . . . . . . . . . . . . . . . 10 80 4.3. MPLS G-SID . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.4. IPv4 G-SID . . . . . . . . . . . . . . . . . . . . . . . 12 82 5. G-SRv6 for Crossing SRv6 Compression Domains . . . . . . . . 13 83 5.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 13 84 5.1.1. Compressable SID Indication . . . . . . . . . . . . . 13 85 5.1.2. C-SID Length Indication . . . . . . . . . . . . . . . 14 86 5.1.3. Start of Compression Indication . . . . . . . . . . . 14 87 5.1.4. End of Compression Indication . . . . . . . . . . . . 15 88 5.1.5. Micro SID in G-SRv6 Compression . . . . . . . . . . . 16 89 5.2. Illustration . . . . . . . . . . . . . . . . . . . . . . 17 90 5.3. Effect on SRv6 . . . . . . . . . . . . . . . . . . . . . 19 91 5.4. Protocol Extensions Requirements . . . . . . . . . . . . 20 92 5.4.1. Data Plane . . . . . . . . . . . . . . . . . . . . . 20 93 5.4.2. Control Plane . . . . . . . . . . . . . . . . . . . . 20 94 6. G-SRv6 for Crossing SR-MPLS Domain . . . . . . . . . . . . . 21 95 6.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 21 96 6.1.1. Start of MPLS G-SID Indication . . . . . . . . . . . 21 97 6.1.2. End of MPLS G-SID Indication . . . . . . . . . . . . 22 98 6.2. Illustration . . . . . . . . . . . . . . . . . . . . . . 22 99 6.3. Effect on SRv6 . . . . . . . . . . . . . . . . . . . . . 23 100 6.4. Protocol Extensions Requirements . . . . . . . . . . . . 24 101 6.4.1. Data Plane . . . . . . . . . . . . . . . . . . . . . 24 102 6.4.2. Control Plane . . . . . . . . . . . . . . . . . . . . 24 103 7. G-SRv6 for Crossing IPv4 Domain . . . . . . . . . . . . . . . 25 104 7.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 25 105 7.1.1. Start of IPv4 G-SID Indication . . . . . . . . . . . 25 106 7.1.2. IPv4 G-SID encoding . . . . . . . . . . . . . . . . . 26 107 7.2. Illustration . . . . . . . . . . . . . . . . . . . . . . 26 108 7.3. Effect on SRv6 . . . . . . . . . . . . . . . . . . . . . 27 109 7.4. Protocol Extensions Requirements . . . . . . . . . . . . 27 110 7.4.1. Data Plane . . . . . . . . . . . . . . . . . . . . . 28 111 7.4.2. Control Plane . . . . . . . . . . . . . . . . . . . . 28 112 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 114 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 115 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 116 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 117 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 118 12.2. Informative References . . . . . . . . . . . . . . . . . 30 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 121 1. Introduction 123 Segment routing (SR) [RFC8402] is a source routing paradigm that 124 explicitly indicates the forwarding path for packets at the ingress 125 node by inserting an ordered list of instructions, called segments. 127 When segment routing is deployed on the IPv6 data plane, it is called 128 SRv6 [I-D.ietf-6man-segment-routing-header]. For support of SR, a 129 new routing header called Segment Routing Header (SRH), which 130 contains a list of SIDs and other information, has been defined in 131 [I-D.ietf-6man-segment-routing-header]. In use cases like Traffic 132 Engineering, an ordered SID List with multiple SIDs is inserted into 133 the SRH to steer packets along an explicit path. 135 As the deployment of SRv6, some new requirements are proposed, such 136 as SRv6 compression, transporting over SR-MPLS/MPLS and IPv4 domains. 137 Therefore, it is necessary to consider other types of segments or 138 sub-paths in the end-to-end SRv6 network programming. 140 This document proposes Generalized Segment Routing over IPv6 (G-SRv6) 141 Networking Programming, which supports to encode multiple types of 142 Segments in a SRH, called Generalized SRH (G-SRH). These Segments 143 can be called Generalized Segment, and the ID can be Generalized 144 Segment Identifier (G-SID), which may include an SRv6 SID(128 bits), 145 C-SIDs, MPLS labels, or IPv4 tunnel information. 147 This document also defines the mechanisms of Generalized SRv6 148 Networking Programming and the requirements of related protocol 149 extensions of control plane and data plane. 151 2. Terminology 153 This document makes use of the terms defined in 154 [I-D.ietf-6man-segment-routing-header], [RFC8402] and [RFC8200], and 155 the reader is assumed to be familiar with that terminology. This 156 document introduces the following terms: 158 SRv6 SID: The 128-bit segment identifier is introduced in 159 [I-D.ietf-spring-srv6-network-programming]. It is always composed by 160 locator, function and/or arguments. 162 C-SRv6: Compressed SRv6 Network Programming 164 Compressable SID: It is the 128-bit SRv6 SID which can be compressed. 165 It is composed by Common Prefix and Compressed Segment Identifier 166 (C-SID) and optional arguments. 168 Common Prefix: It is the same prefix shared by multiple Compressable 169 SIDs. 171 C-SID: Compressed Segment Identifier 172 [I-D.li-spring-compressed-srv6-np]. It is the remaining part of 173 Compressable SID removing Common Prefix and arguments. The 174 recommended length of C-SIDs is 32 bits. 176 C-SRH: Compressed Segment Routing Header. It is the enhanced SRH 177 used for C-SRv6. 179 G-SRv6: Generalized SRv6 Network Programming 181 G-SID: Generalized Segment Identifier. 183 G-SRH: Generalized Segment Routing Header. It is the enhanced SRH 184 used for G-SRv6. 186 Compression G-SID: It is the G-SID for encapsulating C-SIDs. 188 MPLS G-SID: It is the G-SID for encapsulating MPLS label stack 189 encapsulation information. 191 IPv4 G-SID: It is the G-SID for encapsulating IPv4 tunnel 192 information. 194 SRv6 Compression Sub-path: It is the path for crossing the SRv6 195 compression domain in the end-to-end G-SRv6 path. 197 SR-MPLS Sub-path: It is the path for crossing the SR-MPLS domain in 198 the end-to-end G-SRv6 path. 200 IPv4 Tunnel Sub-path: It is the IPv4 tunnel path for crossing the 201 IPv4 domain in the end-to-end G-SRv6 path. 203 2.1. Requirements Language 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 207 "OPTIONAL" in this document are to be interpreted as described in BCP 208 14 [RFC2119] [RFC8174] when, and only when, they appear in all 209 capitals, as shown here. 211 3. Requirements 213 This section describes the requirements of G-SRv6. 215 3.1. Crossing C-SRv6 Domains 217 The overhead of SIDs (16 bytes per SID) in SRH proposes challenges 218 for packet processing and payload efficiency. For addressing this 219 problem, some solutions are proposed. For example, 220 [I-D.li-spring-compressed-srv6-np] proposes Compressed SRv6 Network 221 programming(C-SRv6). 223 In an SRv6 domain, the SIDs will be allocated from an address block, 224 called SID space. For routing within an SRv6 domain, the SIDs may 225 have the same prefix (Common Prefix). 226 [I-D.li-spring-compressed-srv6-np] defines a compressed SID (C-SID) 227 to carry the different part of the original SRv6 SID in the SRH. The 228 format of a compressable SRv6 SID with 32 bit C-SID is shown in 229 Figure 1. The argument part is specified by use cases, and it is 230 zero by default. It is shared by the compressable SRv6 SIDs in a 231 C-SRv6 sub-path 232 0 Variable Length 32 bits 128 bits 233 +--------------------------------------------------------------+ 234 | Common Prefix | C-SID | Argument | 235 +--------------------------------------------------------------+ 236 |<-------- Locator ---------------->|<-FuncID->|<--Argument -->| 237 |<--->| 238 | 239 Different part of Locator 241 Figure 1. 32 bits C-SID in Compressable SRv6 SID 243 In C-SRv6, the common prefix can be carried by the first SID in the 244 IPv6 destination address, while only the C-SIDs of the original SIDs 245 are carried in the C-SRH. In this way, the overhead of SRv6 can be 246 reduced. 248 C-SRv6 can reduce the overhead of SRH. But the C-SRv6 requires that 249 all the SIDs of the SRv6 path to be the compressable SRv6 SID. The 250 limitation causes that it does not work in the following scenarios: 252 Scenario 1-1: 254 In a single domain owing to the incremental deployment there will be 255 the scenario in which some nodes can support C-SRv6 while others only 256 support SRv6. This causes that the end-to-end SRv6 path may be 257 composed by both SRv6 SIDs and Compressable SRv6 SIDs. In this case 258 C-SRv6 cannot work and SRH has to be used for the SRv6 path. 260 For example, as illustrated in Figure 2, a packet is forwarded along 261 the path A1->A2->A3->A4->A5->A6->A7, and the SRv6 SID list is 262 [A::1:1, A::2:1, A::3:1, A::4:1, A::5:1, A6::6:1, A::7:10]. All the 263 nodes along the path support compression except A6. In this case, 264 the SID list can not be compressed due to A6 does not support 265 compression. 267 (A::3:1) A3------A4 (A::4:1) 268 | | 269 (A::2:1) A2 A5 (A::5:1) 270 | | 271 Tenant10 CE1-----A0---A1------A6---A7-----CE3 Tenant10 with 272 (A::1:1)(A6::6:1) (A::7:10) IPv4 20/8 274 Figure 2. SRv6 Path with SRv6 SIDs and Compressable SIDs 276 Scenario 1-2: 278 In C-SRv6, Common Prefix must be designed for the Compressable SRv6 279 SIDs. But in the scenario of crossing multiple SRv6 domains, it is 280 very difficult to design the unified Common Prefix. It can be easy 281 to design its own Common Prefix in a single domain. Thus an SRv6 282 path crossing multiple domains may be composed by different groups of 283 Compressable SRv6 SIDs with different Common Prefixes, and they can 284 not be encoded in a single C-SRH. 286 For example, as illustrated in Figure 3, , a packet is forwarded 287 along the path A1->A2->A3->A4->B1->B2->B3->B4, and the SRv6 SID list 288 is [A::1:1, A::2:1, A::3:1, A:4:1, B::1:1, B::2:1, B::3:1, B:4:1]. 289 The Common Prefix of the sub-path A1->A2->A3->A4 is A and the Common 290 Prefix of the sub-path B1->B2->B3->B4 is B. But the end-to-end SRv6 291 path cannot be compressed in a single C-SRH. 293 A2-----A3 B2-----B3 294 | | | | 295 | | | | 296 | | | | 297 Tenant10 CE1---A0----A1-----A4----B1-----B4-----B0---CE3 Tenant10 with 298 IPv4 20/8 300 Figure 3. SRv6 Path Crossing Multiple SRv6 Compression Domains 302 For addressing above problems, a mechanism of encoding SRv6 SIDs and 303 SRv6 C-SIDs in any order in an SRH should be provided, which does not 304 require all the nodes along the path to support SRv6 compression. 306 3.2. Crossing SR-MPLS Domains 308 In SRv6, END.BM SID can be used for indicating an SR-MPLS Policy. 309 Therefore, when an SRv6 packet needs to travel an SR-MPLS path, the 310 associated END.BM SID should be encoded in the SID list. When the 311 packet arrives at the ingress node of the SR-MPLS path, an MPLS label 312 stack will be encapsulated to the packet according to the END.BM, and 313 the packet will be forwarded in the SR-MPLS domain based on the MPLS 314 labels. 316 End.BM hides the details of the SR-MPLS path, which brings benefits 317 on security and privacy. But it brings more network states to the 318 intermediate nodes of the SRv6 path. Also, when operators can manage 319 both the SRv6 networks and SR-MPLS networks, it can program an end- 320 to-end path under specific SLA assurance. If the existing SR-MPLS 321 path associated with END.BM can not meet the SLA requirement, then a 322 new END.BM SID should be configured and advertised among the 323 networks. This procedure increases the complexities of deploying 324 services. 326 For example, as illustrated in Figure 4, when a packet is sent from 327 CE1 to CE3, it may choose several paths in SR-MPLS domain, which 328 provide different SLA assurance. Therefore, state of multiple SR- 329 MPLS paths should be maintained at the node A1 and A2. 331 - SR-MPLS Path 1: A1->A4->A5 333 - SR-MPLS Path 2: A1->A2->A3->A6 335 - SR-MPLS Path 3: A1->A2->A3->A6->A5 337 - SR-MPLS Path 4: A2->A3->A6 339 - SR-MPLS Path 5: A2->A1->A4->A5 341 - SR-MPLS Path 6: A2->A1->A4->A5->A6 343 There will be more states of path should be maintained when the scale 344 of SR-MPLS domain is large. 346 B2-------A2----A3-----A6-------B3 347 | SRv6 | SR-MPLS | SRv6 | 348 | Domain | Domain | Domain | 349 | | | | 350 Tenant10 CE1---B1-------A1----A4-----A5-------B4---CE3 Tenant10 with 351 IPv4 20/8 353 Figure 4. SRv6 Path Crossing SR-MPLS Domains 355 In order to program SR-MPLS sub-path more flexible and reduce the 356 states on the intermediate nodes, a mechanism for encoding SRv6 SID 357 and MPLS labels should be provided. In this way, the ingress node of 358 the path can program the end-to-end path including the SRv6 sub-path 359 and the SR-MPLS sub-path, and no state of MPLS sub-path will be 360 maintained. 362 3.3. Crossing IPv4 Domains 364 In some scenarios such as SD-WAN an SRv6 packet may cross an IPv4 365 domain, and the SRv6 packets will be transported by the IPv6 over 366 IPv4 tunnel. Similar to SR-MPLS, there can be two options for 367 indicating the IPv4 tunnel. 369 o Option A: the IPv4 tunnel binding SID in SRH 371 o Option B: the IPv4 tunnel parameters in SRH 372 For IPv4 tunnel binding SID, the ingress node of IPv4 tunnel should 373 maintain the states of this tunnel. 375 For example, as illustrated in Figure 5, when a packet is sent from 376 CE1 to CE3, it may choose several paths in the IPv4 domain. 377 Therefore, state of multiple IPv4 tunnels should be maintained at the 378 node A1 and A2. 380 - IPv4 Tunnel 1: Source Address A1, Destination Address A5 382 - IPv4 Tunnel 2: Source Address A1, Destination Address A6 384 - IPv4 Tunnel 3: Source Address A2, Destination Address A5 386 - IPv4 Tunnel 4: Source Address A2, Destination Address A6 388 There will be more states of IPv4 tunnels should be maintained when 389 the scale of the IPv4 domain is large. 391 B2-------A2----A3-----A6-------B3 392 | SRv6 | IPv4 | SRv6 | 393 | Domain | Domain | Domain | 394 | | | | 395 Tenant10 CE1---B1-------A1----A4-----A5-------B4---CE3 Tenant10 with 396 IPv4 20/8 398 Figure 5. SRv6 Path Crossing IPv4 Domains 400 The second option can be adopted to carry the IPv4 tunnel information 401 explicitly in the SRH. At the ingress of the IPv4 tunnel, an IPv4 402 tunnel header will be encapsulated to the packet according to the 403 IPv4 tunnel information in the SRH. In order to support encoding 404 IPv4 tunnel information in SRH, new mechanisms are required. 406 4. Concept of Generalized SRv6 408 According to the requirements described above, this document proposes 409 Generalized SRv6, which supports to encode multiple types of Segment 410 ID in a single SRH for an end-to-end Generalized SRv6 path that 411 travels multiple types of networks, such as SRv6 domains, Compressed 412 SRv6 domains, SR-MPLS domains and IPv4 domains. 414 In order to support G-SRv6, this document proposes some enhancements 415 of SRH. This enhanced SRH is called Generalized SRH (G-SRH). The 416 Segments encoded in a G-SRH is called General Segments and its ID is 417 called Generalized SID (G-SID). A G-SID is a 128 bits value, and it 418 may contain: 420 o an SRv6 SID 422 o a compression G-SID 424 o an MPLS G-SID 426 o an IPv4 G-SID 428 4.1. SRv6 G-SID 430 SRv6 SID is a type of G-SID. A G-SID contains a single SRv6 SID, and 431 does not change anything of SRv6 SID. 433 4.2. Compression G-SID 435 As per [I-D.li-spring-compressed-srv6-np], a C-SID is a sub-set of a 436 compressable SRv6 SID, which can be used for routing the packets in 437 compressed SRv6 network programming. 439 A compression G-SID shown in Figure 6 may contains several C-SIDs and 440 optional padding. When C-SID is a 32 bits value, a compression G-SID 441 can consist of 4 C-SIDs. If the length of C-SIDs in a G-SID is less 442 than 128 bits, then padding is required. 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | C-SID 0 | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | C-SID 1 | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | C-SID 2 | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | C-SID 3 | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 (a) 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Padding | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Padding | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | C-SID 0 | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | C-SID 1 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 (b) 470 Figure 6. Compression G-SID 472 4.3. MPLS G-SID 474 An MPLS G-SID shown in Figure 7 may contains 4 MPLS Label 475 Encapsulations, if number of MPLS Label Encapsulations is less than 476 4, then padding is required in G-SID for aligning with 128 bits. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Label 0 | TC |S| TTL | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Label 1 | TC |S| TTL | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Label 2 | TC |S| TTL | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Label 3 | TC |S| TTL | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 (a) 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Padding | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Padding | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Label 0 | TC |1| TTL | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Label 1 | TC |S| TTL | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 (b) 504 Figure 7. MPLS G-SID 506 In order to indicate the MPLS G-SID, this document proposes a END.M 507 (End function with SR-MPLS path instantiation), this will be 508 described in section 6. 510 An MPLS G-SID appears after the END.M SID, and it can not be the last 511 G-SID in the G-SID list. 513 4.4. IPv4 G-SID 515 An IPv4 G-SID shown in Figure 8 contains 128 bits IPv4 tunnel related 516 information. The format of IPv4 G-SID is shown below. 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Type | Tunnel Parameters | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | IPv4 Src Address | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | IPv4 Dest Address | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Tunnel Parameters | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 8. IPv4 G-SID 532 In order to indicate the IPv4 G-SID, this document proposes a END.4 533 (End function with IPv4 tunnel instantiation), this will be described 534 in section 7. The detailed encoding of IPv4 tunnel G-SID is also 535 described in section 7. 537 An IPv4 G-SID appears after the End.4 SID, and it can not be the last 538 G-SID in the G-SID list. 540 5. G-SRv6 for Crossing SRv6 Compression Domains 542 This section describes the mechanism of G-SRv6 for crossing SRv6 543 Compression Domains. 545 5.1. Mechanisms 547 The path for crossing SRv6 Compression Domain is called Compressed 548 SRv6 sub-path. It should be encoded in any location of a G-SRH. 549 There are following aspects should be considered in this mechanism: 551 o Compression SID indication 553 o C-SID length indication 555 o Start of C-SIDs indication 557 o End of C-SIDs indication 559 5.1.1. Compressable SID Indication 561 A new flavor can be introduced to indicate that an SRv6 SID is 562 compressable. There are two options for the definition of the 563 flavor: 565 o Option A: If the Compressable flavor is set for a specific SRv6 566 SID, it means that the SRv6 SID can be used as normal SRv6 SID and 567 also can be used as Compressable SRv6 SID. 569 o Option B: If the Compressable flavor is set for a specific SRv6 570 SID, it means that the SRv6 SID can only be used as Compressable 571 SRv6 SID. In this option, if an SRv6 SID is already allocated and 572 the compression requirement is proposed, a new SRv6 SID has to be 573 allocated as the Compressable SRv6 SID for the same function. 575 Though the Option B may use more SRv6 SIDs for the purpose of 576 compression, it has much advantages in the incremental deployment. 577 This document recommends the Option B. 579 5.1.2. C-SID Length Indication 581 Compresable SRv6 SID can be represented as Common Prefix + 582 C-SID+(Optional) Argument. There can be multiple options for the 583 length of C-SID as follows: 585 o Option A: a variable length in bytes 587 o Option B: optional length such as 16/32/64 bits 589 o Option C: only one option, 32 bits 591 Though the length of C-SID can be configured locally or advertised by 592 protocol extensions, the different length of C-SID will increase the 593 complexity of process of control plane and data plane which is not 594 necessary. This document recommends Option C which is a ideal 595 tradeoff between the compression and the enough space for node ID and 596 SRv6 Function. 598 5.1.3. Start of Compression Indication 600 In G-SRv6, if the SID list of an SRv6 sub-path consists of a list of 601 compressable SIDs, it can be programmed as follows: the first 602 compressable SID indicates the start of C-SRv6 sub-path, followed by 603 compressable G-SIDs, which includes C-SIDs and padding if the number 604 of (32 bits) C-SIDs is less than 4 in a G-SID. The format of 605 programmed SRv6 compression sub-path is shown in Figure 9. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 . ... . 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Compression G-SID 1 | 613 | | 614 | | 615 | | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Compression G-SID 2 | 618 | | 619 | | 620 | | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Compressable SRv6 SID | 623 | | 624 | | 625 | | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Figure 9. G-SID list for SRv6 Compression Path 630 5.1.4. End of Compression Indication 632 Since C-SIDs and SRv6 SIDs can be encoded in any order in an SRH, a 633 mechanism for indicating the end of compression is needed. There are 634 mainly two options for the indication of the end of compression as 635 follows: 637 o Option A: an EOC (End of Compression) flavor is introduced when 638 advertise Compressable SRv6 SID. When the node determines the 639 IPv6 destination address of SRv6 packet is the Compresable SRv6 640 SID with EOC flavor, meaning the associated C-SID is the last 641 C-SID in the G-SID, and it will skip the G-SID in which the 642 corresponding C-SID located and read the following 128-bit SRv6 643 SID. 645 o Option B: an EOC C-SID is introduced in the G-SID to indicate the 646 end of the compression. The length of EOC C-SID is a 32 bits 647 value, and the it's value can be a well-known value such as 0 or a 648 node allocated value. If the number of C-SIDs in a Compression 649 G-SID is less than 4, the EOC can be used as the . If there are 4 650 C-SIDs in the last G-SID of Compressed SRv6 sub-path, it has to 651 insert a G-SID composed by 4 EOCs. 653 The different options for indication of end of compression are shown 654 in Figure 10. 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | C-SID 0 (EOC Flavor) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | C-SID 1 (Non-EOC Flavor) | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | C-SID 2 (Non-EOC Flavor) | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | C-SID 3 (Non-EOC Flavor) | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 (a) Option A 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | | 670 | G-SID (MBZ) | 671 | | 672 | | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | C-SID 0 | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | C-SID 1 | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | C-SID 2 | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | C-SID 3 | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 (b) Option B 685 Figure 10. End of Compression Indication 687 5.1.5. Micro SID in G-SRv6 Compression 689 The Micro SID instruction is proposed at 690 [I-D.filsfils-spring-net-pgm-extension-srv6-usid], and it can be used 691 for forwarding SRv6 packets by shifting the IPv6 DA. The Micro SID 692 Carrier can be seen as a type of G-SID and can be directly used for 693 G-SRv6 as shown in Figure 11 (a). 695 The compressable SRv6 SID can also be used as the Micro SID and 696 encapsulated in the Micro SID Carrier. As shown in Figure 11 (b), 697 the first compressable SRv6 SID for the sub-path crossing SRv6 698 compression domain can be changed to a Micro SID carrier with the 699 locator block and multiple uSIDs which are also C-SIDs. Therefore, 700 multiple C-SIDs can be updated to the IPv6 DA in a single time. 702 After shifting the Micro SIDs in IPv6 DA and if the last Micro SID is 703 the C-SID without EOC flavor, the following multiple C-SIDs (Micro 704 segments) in the G-SID will be updated to the IPv6 DA instead of the 705 Micro SID carrier and the location of the C-SIDs in the G-SID is 706 recorded. If the rest C-SIDs in the current G-SID is less than the 707 C-SIDs should be copied to the IPv6 DA using as the Micro SID carrier 708 in a single time, only the rest C-SIDs will be copied to the IPv6 DA. 709 The next copy will begin with the first C-SID in the next G-SID. The 710 end of the C-SIDs shifting is indicated by a EOC flavor C-SID. When 711 an EOC flavor C-SID is processed, the next 128-bits G-SID will be 712 updated to the IPv6 DA. 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Block | uSID5(uN) | uSID6(uN) | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Block | uSID3(uN) | uSID4(uN) | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Block | uSID1(uN) | uSID2(uN) | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 (a) Original Micro SID carrier in G-SRv6 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | C-SID3(uN) | C-SID4(uN) | C-SID5(uN) | C-SID6(uN/EOC)| 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Block | C-SID1(uN) | C-SID2(uN) | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | 64 bits | 32 bits | 32 bits | 730 (b) C-SID(uN) in G-SRv6 732 Figure 11. Micro SID using in G-SRv6 734 In this mechanism, more SRH overhead can be reduced but it also 735 brings limitation of address planning and extra complexities. The 736 details will be discussed in the future version. 738 5.2. Illustration 740 According to the above mechanisms, the scenarios shown in the section 741 3.1 can be encoded as follows: 743 Scenario 1-1: 745 Assuming that 746 o A::1:1, A::2:1, A::3:1, A::4:1, A::5:1 are the Compressable SIDs. 748 o A::1:2, A::2:2, A::3:2, A::4:2, A::5:2 are the Compressable SIDs 749 with EOC flavor. 751 The programmed G-SRv6 path A1->A2->A3->A4->A5->A6->A7 is shown in 752 Figure 12: 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | A::7:10 | 758 | | 759 | | 760 | | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | A6::6:1 | 763 | | 764 | | 765 | | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | 5:2 | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | 4:1 | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | 3:1 | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | 2:1 | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | A1::1:1 | 776 | | 777 | | 778 | | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Figure 12. G-SRv6 Path for Scenario 1-1 783 Scenario 1-2: 785 The programmed G-SRv6 path A1->A2->A3->A4->B1->B2->B3->B4 is shown in 786 Figure 13: 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Padding | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | 4:2 | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | 3:1 | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | 2:1 | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | B::1:1 | 800 | | 801 | | 802 | | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Padding | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | 4:2 | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | 3:1 | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | 2:1 | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | A::1:1 | 813 | | 814 | | 815 | | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 Figure 13. G-SRv6 Path for Scenario 1-2 819 In reduced mode, the SID A::1:1 can be removed from the G-SRH. 821 The mechanism of indicating the C-SIDs within the G-SID will be 822 described in the document of G-SRH. 824 5.3. Effect on SRv6 826 G-SRv6 provides the flexibility of encoding SRv6 SID and SRv6 C-SID 827 in a single SRH, which supports to program an SRv6 path that consists 828 of compression capable and compression incapable nodes. In this 829 case, G-SRv6 solves the problem of SRv6 overhead with a limited 830 effect on SRv6. 832 o Independent with SRv6: G-SRv6 does not require that the SRv6 SID 833 Space has the common prefix for supporting compression. A new 834 address block can be allocated for compressable SID, and the 835 common prefix of Compressable SIDs can be configured with 836 appropriate length. 838 o Incremental upgrade: G-SRv6 does not require to upgrade all the 839 nodes along the path to support SRv6 compression, they can be 840 upgraded on demand to support compression. 842 5.4. Protocol Extensions Requirements 844 This section describes the protocol extension requirements. 846 5.4.1. Data Plane 848 REQ1-01: An SRv6 compression path can be represented as a G-SID list 849 consists of a compressable SRv6 SID and Compression G-SIDs. 851 REQ1-02: A Compression G-SID consists of at most 4 (32-bits) C-SIDs, 852 if the number of C-SID is less than 4, then padding is required to 853 align with 128 bits. 855 REQ1-03: If the first Compressable SID is copied to the IPv6 DA, then 856 the C-SIDs of the following G-SIDs should be read by the nodes along 857 the SRv6 compression sub-path and the C-SID part in IPv6 DA should be 858 replaced accordingly. 860 REQ1-04: The last C-SID in the G-SIDs for the SRv6 compression sub- 861 path should be the Compressable SRv6 SID with EOC flavor. 863 REQ1-05: When process the Compressalbe SRv6 SID with EOC flavor in 864 the IPv6 DA, the corresponding G-SID in the G-SRH should be skipped 865 and the IPv6 DA should be updated by the following SRv6 SID if 866 exists. 868 5.4.2. Control Plane 870 REQ1-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for 871 SRv6 compression capabilities 873 REQ1-12: ISIS/OSPF/BGP-LS/BGP extensions for advertising the 874 Compression flavor for Compressable SIDs. 876 REQ1-13: ISIS/OSPF/BGP-LS extensions for advertising the End-of- 877 compression(EOC) flavor for Compressable SIDs. 879 REQ1-14: ISIS/OSPF/BGP-LS/BGP extensions for advertising the format 880 of Compressable SIDs. 882 REQ1-21: BGP SRv6 Policy extensions for advertising the G-SRv6 for 883 SRv6 compression capabilities. 885 REQ1-22: BGP SR Policy extensions for programming a G-SRv6 path 886 combining with Compressable SRv6 SIDs and SRv6 SIDs. 888 REQ1-31: PCEP SRv6 Policy extensions for advertising the G-SRv6 for 889 SRv6 compression capabilities. 891 REQ1-32: PCEP SR Policy extension for programming a G-SRv6 path 892 combining with Compressable SRv6 SIDs and SRv6 SIDs. 894 REQ1-33: PCEP extensions for programming a G-SRv6 path combining with 895 Compressable SRv6 SIDs and SRv6 SIDs. 897 6. G-SRv6 for Crossing SR-MPLS Domain 899 This section describes the mechanism for encoding SRv6 SIDs and MPLS 900 G-SID in a single G-SRH. 902 6.1. Mechanisms 904 The path for crossing SR-MPLS domain is called SR-MPLS sub-path. It 905 can be encoded in any location of G-SRH. There are two aspects 906 should be considered in this mechanism: 908 o Start of MPLS G-SIDs indication 910 o End of MPLS G-SIDs indication 912 6.1.1. Start of MPLS G-SID Indication 914 In order to indicate the start of MPLS G-SIDs, new SRv6 SIDs types 915 should be defined. This document defines an SID function to indicate 916 the start of MPLS G-SIDs, called End.M ( End with MPLS labels). 918 An SR-MPLS sub-path can be encoded in the G-SRH as follows: 920 0 1 2 3 921 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 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 . ... . 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | MPLS G-SID 1 | 927 | | 928 | | 929 | | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | MPLS G-SID 2 | 932 | | 933 | | 934 | | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | End.M SRv6 SID | 937 | | 938 | | 939 | | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Figure 14. SR-MPLS Sub-path Encoding in G-SRH 944 When a node processes an End.M SID, it copies the following MPLS 945 label stack encapsulation information of SR-MPLS sub-path in the MPLS 946 G-SIDs to the MPLS header, and set the IPv6 DA as the SRv6 SID 947 following the last MPLS G-SID of the SR-MPLS sub-path, and then 948 forward the packet according to the active MPLS label. 950 6.1.2. End of MPLS G-SID Indication 952 The S-bit in the MPLS label indicates the end of the MPLS label 953 within the current MPLS G-SIDs sub-list. 955 When the ingress node of the SR-MPLS sub-path reads the MPLS label 956 stack encapsulation information until the Label with S-bit set. If 957 the S-bit is set for the label encapsulation, it will skip the G-SID 958 in which the label locates and set the IPv6 DA of the SRv6 packet as 959 the SRv6 SID following the G-SID if exists. 961 6.2. Illustration 963 According to the above mechanisms, the scenarios shown in the section 964 3.2 can be encoded as follows: 966 Assuming that 967 o A::1:100 is the End.M SID allocated by the node A1 for crossing 968 SR-MPLS domain. 970 o Label 1001, 1002, 1003, 1004, 1005 and 1006 are allocated as the 971 node segment for A1/A2/A3/A4/A5/A6. 973 The programmed G-SRv6 path B1->A1->A2->A3->A6->A5->B4 is shown in 974 Figure 15: 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | B::4:1 | 980 | | 981 | | 982 | | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | 1005 | TC |1| TTL | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | 1006 | TC |0| TTL | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | 1003 | TC |0| TTL | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | 1002 | TC |0| TTL | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | A::1:100 (End.M) | 993 | | 994 | | 995 | | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | B::1:1 | 998 | | 999 | | 1000 | | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 Figure 15. G-SRv6 Path for Sec 3.2 1005 6.3. Effect on SRv6 1007 G-SRv6 supports to program the SRv6 SID and SR-MPLS SID/MPLS label in 1008 a single G-SRH, which provides to encode the end-to-end G-SRv6 path 1009 across SRv6 domains and SR-MPLS/MPLS domains explicitly at the 1010 ingress node. However, it also brings complexities of network 1011 programming, so this document suggests to upgrade the SR-MPLS nodes 1012 to support SRv6. 1014 6.4. Protocol Extensions Requirements 1016 This section describes the protocol extension requirements of G-SRv6 1017 for MPLS G-SID. 1019 6.4.1. Data Plane 1021 REQ2-01: An MPLS path can be encoded in G-SRH as a series of G-SIDs 1022 including a 128-bit End.M SRv6 SID and a set of MPLS G-SIDs. 1024 REQ2-02: An MPLS G-SID can consist of up to 4 MPLS label/SR-MPLS SID, 1025 if the number of MPLS label/SR-MPLS SID is less than 4, padding is 1026 required to align with 128 bits. 1028 REQ2-03: An End.M SRv6 SID indicates the start of MPLS G-SID. 1030 REQ2-04: The SRv6 packet can be encapsulated with an outer MPLS 1031 header, and the MPLS header contains the MPLS labels carried by the 1032 MPLS G-SIDs. 1034 REQ2-05: When the label encapsulation with S-bit is set is read by 1035 the ingress node of the SR-MPLS sub-path, the corresponding G-SID 1036 should be skipped and the IPv6 DA should be updated by the following 1037 SRv6 SID if exists. 1039 6.4.2. Control Plane 1041 REQ2-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for 1042 MPLS capabilities 1044 REQ2-12: ISIS/OSPF/BGP-LS extensions for advertising the End.M SRv6 1045 SID. 1047 REQ2-21: BGP SR Policy extensions for advertising the G-SRv6 for MPLS 1048 capabilities 1050 REQ2-22: BGP SR Policy extensions for encoding G-SID list with SRv6 1051 SID and MPLS G-SID for G-SRv6 path. 1053 REQ2-31: PCEP SR Policy extensions for advertising the G-SRv6 for 1054 MPLS capabilities 1056 REQ2-31: PCEP SR Policy extensions for encoding G-SID list with SRv6 1057 SID and MPLS G-SID for G-SRv6 path. 1059 REQ2-33: PCEP extensions for encoding G-SID list with SRv6 SID and 1060 MPLS G-SID for G-SRv6 path. 1062 7. G-SRv6 for Crossing IPv4 Domain 1064 This section describes the mechanism of G-SRv6 for crossing IPv4 1065 domain. 1067 7.1. Mechanism 1069 The path for crossing IPv4 domain is called IPv4 tunnel sub-path. It 1070 should be encoded in any location of G-SRH. There are two aspects 1071 should be considered in this mechanism: 1073 o Start of IPv4 G-SID 1075 o IPv4 G-SID encoding 1077 7.1.1. Start of IPv4 G-SID Indication 1079 In order to indicate the start of IPv4 G-SIDs, new SRv6 SIDs types 1080 should be defined. 1082 This document defines an SID function to indicate the start of IPv4 1083 G-SIDs, called End.4( End with IPv4 tunnel). 1085 When a node processes the End.4 SID, it encapsulates an outer IPv4 1086 tunnel header for the SRv6 packet based on the tunnel information 1087 carried by the following IPv4 G-SID, and set the IPv6 DA as the SRv6 1088 SID following the IPv4 G-SID, and then forwards the packet according 1089 to the IPv4 DA. 1091 An IPv4 tunnel sub-path can be encoded in the G-SRH as follows: 1093 0 1 2 3 1094 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 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | IPv4 G-SID | 1097 | | 1098 | | 1099 | | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | SRv6 End.4 SID | 1102 | | 1103 | | 1104 | | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 Figure 16. IPv4 Tunnel Sub-path Encoding in G-SRH 1109 Also, this document proposes the END.B4 (End bound to an IPv4 tunnel) 1110 SID. A End.B4 is bound to an IPv4 tunnel. When the node receives a 1111 packet with End.B4 SID, the packet should be steered into the binding 1112 IPv4 tunnel. 1114 7.1.2. IPv4 G-SID encoding 1116 An IPv4 GID contains the IPv4 tunnel information including tunnel 1117 type, source IPv4 address, destination IPv4 address and tunnel 1118 parameters. Different types of IPv4 tunnels have specific 1119 parameters: 1121 o IPv4 UDP tunnel: the tunnel parameters includes source port and 1122 destination port. 1124 o IPv4 VXLAN tunnel: the tunnel parameters includes source port, 1125 destination port and VN ID. 1127 The detailed encapsulation formats for different types of IPv4 tunnel 1128 is out of scope of the document. 1130 7.2. Illustration 1132 According to the above mechanisms, the scenarios shown in the section 1133 3.3 can be encoded as follows: 1135 Assuming that 1137 o A::1:200 is the End.4 SID allocated by the node A1 for crossing 1138 IPv4 domain. 1140 The programmed G-SRv6 path B1->A1->A6->B4 is shown in Figure 17: 1142 0 1 2 3 1143 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 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | B::4:1 | 1146 | | 1147 | | 1148 | | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Type | Tunnel Parameters | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | IPv4 Src Address (A1) | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | IPv4 Dest Address (A6) | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Tunnel Parameters | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | A::1:200 (End.IP4) | 1159 | | 1160 | | 1161 | | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | B::1:1 | 1164 | | 1165 | | 1166 | | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 Figure 17. G-SRv6 Path for Sec 3.3 1171 7.3. Effect on SRv6 1173 G-SRv6 provides the capabilities for encoding IPv4 tunnel information 1174 and SRv6 SID within a single G-SRH, which brings benefits on end-to- 1175 end network programming on scenarios of packets traveling SRv6 1176 domains and IPv4 domains. However, it also brings new complexities, 1177 so this document suggests to upgrade the IPv4 nodes to support IPv6 1178 or SRv6. 1180 7.4. Protocol Extensions Requirements 1182 This section describes the protocol extension requirements of G-SRv6 1183 for IPv4 G-SID. 1185 7.4.1. Data Plane 1187 REQ3-01: An IPv4 tunnel can be encoded in G-SRH as series of G-SIDs 1188 including a 128 bit End.4 SRv6 SID and a set of IPv4 G-SIDs. 1190 REQ3-02: An IPv4 G-SID can consist of multiple IPv4 tunnel 1191 information, such as IPv4 source address and destination address of 1192 the tunnel endpoint. 1194 REQ3-03: An End.4 SRv6 SID indicates the start of IPv4 G-SID. 1196 REQ3-04: An End.B4 SRv6 SID indicates the IPv4 tunnel. 1198 REQ3-05: The SRv6 packet can be encapsulated with an outer IPv4 1199 tunnel header based on the parameters in the IPv4 G-SID. 1201 REQ3-06: After the tunnel information is read by the ingress node of 1202 the IPv4 tunnel sub-path, the corresponding G-SID should be skipped 1203 and the IPv6 DA should be updated by the following SRv6 SID if 1204 exists. 1206 7.4.2. Control Plane 1208 REQ3-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for 1209 IPv4 capabilities 1211 REQ3-12: ISIS/OSPF/BGP-LS extensions for advertising the End.4 SRv6 1212 SID. 1214 REQ3-13: ISIS/OSPF/BGP-LS extensions for advertising the End.B4 SRv6 1215 SID. 1217 REQ3-21: BGP SR Policy extensions for advertising the G-SRv6 for IPv4 1218 capabilities 1220 REQ3-22: BGP SR Policy extensions for encoding G-SID list with SRv6 1221 SID and IPv4 G-SID for G-SRv6 path. 1223 REQ3-31: PCEP SR Policy extensions for advertising the G-SRv6 for 1224 IPv4 capabilities 1226 REQ3-31: PCEP SR Policy extensions for encoding G-SID list with SRv6 1227 SID and IPv4 G-SID for G-SRv6 path. 1229 REQ3-33: PCEP extensions for encoding G-SID list with SRv6 SID and 1230 IPv4 G-SID for G-SRv6 path. 1232 8. IANA Considerations 1234 TBD 1236 9. Security Considerations 1238 TBD 1240 10. Contributors 1242 Zhibo Hu 1243 Huawei Technologies 1244 huzhibo@huawei.com 1246 Yang Xia 1247 Huawei Technologies 1248 yolanda.xia@huawei.com 1250 11. Acknowledgements 1252 12. References 1254 12.1. Normative References 1256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1257 Requirement Levels", BCP 14, RFC 2119, 1258 DOI 10.17487/RFC2119, March 1997, 1259 . 1261 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1262 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1263 May 2017, . 1265 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1266 (IPv6) Specification", STD 86, RFC 8200, 1267 DOI 10.17487/RFC8200, July 2017, 1268 . 1270 [I-D.ietf-6man-segment-routing-header] 1271 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1272 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1273 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 1274 progress), October 2019. 1276 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1277 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1278 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1279 July 2018, . 1281 [I-D.li-spring-compressed-srv6-np] 1282 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 1283 Guichard, J., Cong, L., and S. Peng, "Compressed SRv6 1284 Network Programming", draft-li-spring-compressed- 1285 srv6-np-02 (work in progress), February 2020. 1287 12.2. Informative References 1289 [I-D.ietf-spring-srv6-network-programming] 1290 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1291 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1292 draft-ietf-spring-srv6-network-programming-12 (work in 1293 progress), March 2020. 1295 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1296 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1297 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1298 J. Leddy, "Illustrations for SRv6 Network Programming", 1299 draft-filsfils-spring-srv6-net-pgm-illustration-01 (work 1300 in progress), August 2019. 1302 [I-D.tian-spring-srv6-deployment-consideration] 1303 Tian, H., Zhao, F., Xie, C., Li, T., Ma, J., Peng, S., Li, 1304 Z., and Y. Xiao, "SRv6 Deployment Consideration", draft- 1305 tian-spring-srv6-deployment-consideration-01 (work in 1306 progress), March 2020. 1308 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 1309 Filsfils, C., Camarillo, P., Cai, D., Voyer, D., Meilik, 1310 I., Patel, K., Henderickx, W., Jonnalagadda, P., and D. 1311 Melman, "Network Programming extension: SRv6 uSID 1312 instruction", draft-filsfils-spring-net-pgm-extension- 1313 srv6-usid-04 (work in progress), February 2020. 1315 [I-D.lc-6man-generalized-srh] 1316 Li, Z., Li, C., Cheng, W., Xie, C., Cong, L., Tian, H., 1317 and F. Zhao, "Generalized Segment Routing Header", draft- 1318 lc-6man-generalized-srh-00 (work in progress), February 1319 2020. 1321 Authors' Addresses 1323 Weiqiang Cheng 1324 China Mobile 1326 Email: chengweiqiang@chinamobile.com 1328 Zhenbin Li 1329 Huawei Technologies 1330 Huawei Campus, No. 156 Beiqing Rd. 1331 Beijing 100095 1332 China 1334 Email: lizhenbin@huawei.com 1336 Cheng Li 1337 Huawei Technologies 1338 Huawei Campus, No. 156 Beiqing Rd. 1339 Beijing 100095 1340 China 1342 Email: chengli13@huawei.com 1344 Chongfeng Xie 1345 China Telecom 1346 China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District 1347 Beijing 1348 China 1350 Email: xiechf.bri@chinatelecom.cn 1352 Cong Li 1353 China Telecom 1354 China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District 1355 Beijing 1356 China 1358 Email: licong.bri@chinatelecom.cn 1359 Hui Tian 1360 CAICT 1361 Beijing 1362 China 1364 Email: tianhui@caict.ac.cn 1366 Feng Zhao 1367 CAICT 1368 Beijing 1369 China 1371 Email: zhaofeng@caict.ac.cn