idnits 2.17.1 draft-cl-spring-generalized-srv6-np-03.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 15, 2021) is 1110 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 1291, but no explicit reference was found in the text == Unused Reference: 'I-D.tian-spring-srv6-deployment-consideration' is defined on line 1298, but no explicit reference was found in the text == Unused Reference: 'I-D.lc-6man-generalized-srh' is defined on line 1313, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-03 == Outdated reference: A later version (-08) exists of draft-tian-spring-srv6-deployment-consideration-04 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-08 == Outdated reference: A later version (-03) exists of draft-lc-6man-generalized-srh-01 Summary: 1 error (**), 0 flaws (~~), 9 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 16, 2021 C. Li 6 Huawei Technologies 7 C. Xie 8 C. Li 9 China Telecom 10 H. Tian 11 F. Zhao 12 CAICT 13 March 15, 2021 15 Generalized SRv6 Network Programming 16 draft-cl-spring-generalized-srv6-np-03 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 16, 2021. 53 Copyright Notice 55 Copyright (c) 2021 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 [RFC8754]. For support of SR, a new routing header called 129 Segment Routing Header (SRH), which contains a list of SIDs and other 130 information, has been defined in [RFC8754]. In use cases like 131 Traffic Engineering, an ordered SID List with multiple SIDs is 132 inserted into the SRH to steer packets along an explicit path. 134 As the deployment of SRv6, some new requirements are proposed, such 135 as SRv6 compression, transporting over SR-MPLS/MPLS and IPv4 domains. 136 Therefore, it is necessary to consider other types of segments or 137 sub-paths in the end-to-end SRv6 network programming. 139 This document proposes Generalized Segment Routing over IPv6 (G-SRv6) 140 Networking Programming, which supports to encode multiple types of 141 Segments in a SRH, called Generalized SRH (G-SRH). These Segments 142 can be called Generalized Segment, and the ID can be Generalized 143 Segment Identifier (G-SID), which may include an SRv6 SID(128 bits), 144 C-SIDs, MPLS labels, or IPv4 tunnel information. 146 This document also defines the mechanisms of Generalized SRv6 147 Networking Programming and the requirements of related protocol 148 extensions of control plane and data plane. 150 2. Terminology 152 This document makes use of the terms defined in [RFC8754], [RFC8402] 153 and [RFC8200], and the reader is assumed to be familiar with that 154 terminology. This document introduces the following terms: 156 SRv6 SID: The 128-bit segment identifier is introduced in [RFC8986]. 157 It is always composed by locator, function and/or arguments. 159 C-SRv6: Compressed SRv6 Network Programming 161 Compressable SID: It is the 128-bit SRv6 SID which can be compressed. 162 It is composed by Common Prefix and Compressed Segment Identifier 163 (C-SID) and optional arguments. 165 Common Prefix: It is the same prefix shared by multiple Compressable 166 SIDs. 168 C-SID: Compressed Segment Identifier 169 [I-D.li-spring-compressed-srv6-np]. It is the remaining part of 170 Compressable SID removing Common Prefix and arguments. The 171 recommended length of C-SIDs is 32 bits. 173 C-SRH: Compressed Segment Routing Header. It is the enhanced SRH 174 used for C-SRv6. 176 G-SRv6: Generalized SRv6 Network Programming 178 G-SID: Generalized Segment Identifier. 180 G-SRH: Generalized Segment Routing Header. It is the enhanced SRH 181 used for G-SRv6. 183 Compression G-SID: It is the G-SID for encapsulating C-SIDs. 185 MPLS G-SID: It is the G-SID for encapsulating MPLS label stack 186 encapsulation information. 188 IPv4 G-SID: It is the G-SID for encapsulating IPv4 tunnel 189 information. 191 SRv6 Compression Sub-path: It is the path for crossing the SRv6 192 compression domain in the end-to-end G-SRv6 path. 194 SR-MPLS Sub-path: It is the path for crossing the SR-MPLS domain in 195 the end-to-end G-SRv6 path. 197 IPv4 Tunnel Sub-path: It is the IPv4 tunnel path for crossing the 198 IPv4 domain in the end-to-end G-SRv6 path. 200 2.1. Requirements Language 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 204 "OPTIONAL" in this document are to be interpreted as described in BCP 205 14 [RFC2119] [RFC8174] when, and only when, they appear in all 206 capitals, as shown here. 208 3. Requirements 210 This section describes the requirements of G-SRv6. 212 3.1. Crossing C-SRv6 Domains 214 The overhead of SIDs (16 bytes per SID) in SRH proposes challenges 215 for packet processing and payload efficiency. For addressing this 216 problem, some solutions are proposed. For example, 217 [I-D.li-spring-compressed-srv6-np] proposes Compressed SRv6 Network 218 programming(C-SRv6). 220 In an SRv6 domain, the SIDs will be allocated from an address block, 221 called SID space. For routing within an SRv6 domain, the SIDs may 222 have the same prefix (Common Prefix). 223 [I-D.li-spring-compressed-srv6-np] defines a compressed SID (C-SID) 224 to carry the different part of the original SRv6 SID in the SRH. The 225 format of a compressable SRv6 SID with 32 bit C-SID is shown in 226 Figure 1. The argument part is specified by use cases, and it is 227 zero by default. It is shared by the compressable SRv6 SIDs in a 228 C-SRv6 sub-path 229 0 Variable Length 32 bits 128 bits 230 +--------------------------------------------------------------+ 231 | Common Prefix | C-SID | Argument | 232 +--------------------------------------------------------------+ 233 |<-------- Locator ---------------->|<-FuncID->|<--Argument -->| 234 |<--->| 235 | 236 Different part of Locator 238 Figure 1. 32 bits C-SID in Compressable SRv6 SID 240 In C-SRv6, the common prefix can be carried by the first SID in the 241 IPv6 destination address, while only the C-SIDs of the original SIDs 242 are carried in the C-SRH. In this way, the overhead of SRv6 can be 243 reduced. 245 C-SRv6 can reduce the overhead of SRH. But the C-SRv6 requires that 246 all the SIDs of the SRv6 path to be the compressable SRv6 SID. The 247 limitation causes that it does not work in the following scenarios: 249 Scenario 1-1: 251 In a single domain owing to the incremental deployment there will be 252 the scenario in which some nodes can support C-SRv6 while others only 253 support SRv6. This causes that the end-to-end SRv6 path may be 254 composed by both SRv6 SIDs and Compressable SRv6 SIDs. In this case 255 C-SRv6 cannot work and SRH has to be used for the SRv6 path. 257 For example, as illustrated in Figure 2, a packet is forwarded along 258 the path A1->A2->A3->A4->A5->A6->A7, and the SRv6 SID list is 259 [A::1:1, A::2:1, A::3:1, A::4:1, A::5:1, A6::6:1, A::7:10]. All the 260 nodes along the path support compression except A6. In this case, 261 the SID list can not be compressed due to A6 does not support 262 compression. 264 (A::3:1) A3------A4 (A::4:1) 265 | | 266 (A::2:1) A2 A5 (A::5:1) 267 | | 268 Tenant10 CE1-----A0---A1------A6---A7-----CE3 Tenant10 with 269 (A::1:1)(A6::6:1) (A::7:10) IPv4 20/8 271 Figure 2. SRv6 Path with SRv6 SIDs and Compressable SIDs 273 Scenario 1-2: 275 In C-SRv6, Common Prefix must be designed for the Compressable SRv6 276 SIDs. But in the scenario of crossing multiple SRv6 domains, it is 277 very difficult to design the unified Common Prefix. It can be easy 278 to design its own Common Prefix in a single domain. Thus an SRv6 279 path crossing multiple domains may be composed by different groups of 280 Compressable SRv6 SIDs with different Common Prefixes, and they can 281 not be encoded in a single C-SRH. 283 For example, as illustrated in Figure 3, , a packet is forwarded 284 along the path A1->A2->A3->A4->B1->B2->B3->B4, and the SRv6 SID list 285 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]. 286 The Common Prefix of the sub-path A1->A2->A3->A4 is A and the Common 287 Prefix of the sub-path B1->B2->B3->B4 is B. But the end-to-end SRv6 288 path cannot be compressed in a single C-SRH. 290 A2-----A3 B2-----B3 291 | | | | 292 | | | | 293 | | | | 294 Tenant10 CE1---A0----A1-----A4----B1-----B4-----B0---CE3 Tenant10 with 295 IPv4 20/8 297 Figure 3. SRv6 Path Crossing Multiple SRv6 Compression Domains 299 For addressing above problems, a mechanism of encoding SRv6 SIDs and 300 SRv6 C-SIDs in any order in an SRH should be provided, which does not 301 require all the nodes along the path to support SRv6 compression. 303 3.2. Crossing SR-MPLS Domains 305 In SRv6, END.BM SID can be used for indicating an SR-MPLS Policy. 306 Therefore, when an SRv6 packet needs to travel an SR-MPLS path, the 307 associated END.BM SID should be encoded in the SID list. When the 308 packet arrives at the ingress node of the SR-MPLS path, an MPLS label 309 stack will be encapsulated to the packet according to the END.BM, and 310 the packet will be forwarded in the SR-MPLS domain based on the MPLS 311 labels. 313 End.BM hides the details of the SR-MPLS path, which brings benefits 314 on security and privacy. But it brings more network states to the 315 intermediate nodes of the SRv6 path. Also, when operators can manage 316 both the SRv6 networks and SR-MPLS networks, it can program an end- 317 to-end path under specific SLA assurance. If the existing SR-MPLS 318 path associated with END.BM can not meet the SLA requirement, then a 319 new END.BM SID should be configured and advertised among the 320 networks. This procedure increases the complexities of deploying 321 services. 323 For example, as illustrated in Figure 4, when a packet is sent from 324 CE1 to CE3, it may choose several paths in SR-MPLS domain, which 325 provide different SLA assurance. Therefore, state of multiple SR- 326 MPLS paths should be maintained at the node A1 and A2. 328 - SR-MPLS Path 1: A1->A4->A5 330 - SR-MPLS Path 2: A1->A2->A3->A6 332 - SR-MPLS Path 3: A1->A2->A3->A6->A5 334 - SR-MPLS Path 4: A2->A3->A6 336 - SR-MPLS Path 5: A2->A1->A4->A5 338 - SR-MPLS Path 6: A2->A1->A4->A5->A6 340 There will be more states of path should be maintained when the scale 341 of SR-MPLS domain is large. 343 B2-------A2----A3-----A6-------B3 344 | SRv6 | SR-MPLS | SRv6 | 345 | Domain | Domain | Domain | 346 | | | | 347 Tenant10 CE1---B1-------A1----A4-----A5-------B4---CE3 Tenant10 with 348 IPv4 20/8 350 Figure 4. SRv6 Path Crossing SR-MPLS Domains 352 In order to program SR-MPLS sub-path more flexible and reduce the 353 states on the intermediate nodes, a mechanism for encoding SRv6 SID 354 and MPLS labels should be provided. In this way, the ingress node of 355 the path can program the end-to-end path including the SRv6 sub-path 356 and the SR-MPLS sub-path, and no state of MPLS sub-path will be 357 maintained. 359 3.3. Crossing IPv4 Domains 361 In some scenarios such as SD-WAN an SRv6 packet may cross an IPv4 362 domain, and the SRv6 packets will be transported by the IPv6 over 363 IPv4 tunnel. Similar to SR-MPLS, there can be two options for 364 indicating the IPv4 tunnel. 366 o Option A: the IPv4 tunnel binding SID in SRH 368 o Option B: the IPv4 tunnel parameters in SRH 369 For IPv4 tunnel binding SID, the ingress node of IPv4 tunnel should 370 maintain the states of this tunnel. 372 For example, as illustrated in Figure 5, when a packet is sent from 373 CE1 to CE3, it may choose several paths in the IPv4 domain. 374 Therefore, state of multiple IPv4 tunnels should be maintained at the 375 node A1 and A2. 377 - IPv4 Tunnel 1: Source Address A1, Destination Address A5 379 - IPv4 Tunnel 2: Source Address A1, Destination Address A6 381 - IPv4 Tunnel 3: Source Address A2, Destination Address A5 383 - IPv4 Tunnel 4: Source Address A2, Destination Address A6 385 There will be more states of IPv4 tunnels should be maintained when 386 the scale of the IPv4 domain is large. 388 B2-------A2----A3-----A6-------B3 389 | SRv6 | IPv4 | SRv6 | 390 | Domain | Domain | Domain | 391 | | | | 392 Tenant10 CE1---B1-------A1----A4-----A5-------B4---CE3 Tenant10 with 393 IPv4 20/8 395 Figure 5. SRv6 Path Crossing IPv4 Domains 397 The second option can be adopted to carry the IPv4 tunnel information 398 explicitly in the SRH. At the ingress of the IPv4 tunnel, an IPv4 399 tunnel header will be encapsulated to the packet according to the 400 IPv4 tunnel information in the SRH. In order to support encoding 401 IPv4 tunnel information in SRH, new mechanisms are required. 403 4. Concept of Generalized SRv6 405 According to the requirements described above, this document proposes 406 Generalized SRv6, which supports to encode multiple types of Segment 407 ID in a single SRH for an end-to-end Generalized SRv6 path that 408 travels multiple types of networks, such as SRv6 domains, Compressed 409 SRv6 domains, SR-MPLS domains and IPv4 domains. 411 In order to support G-SRv6, this document proposes some enhancements 412 of SRH. This enhanced SRH is called Generalized SRH (G-SRH). The 413 Segments encoded in a G-SRH is called General Segments and its ID is 414 called Generalized SID (G-SID). A G-SID is a 128 bits value, and it 415 may contain: 417 o an SRv6 SID 419 o a compression G-SID 421 o an MPLS G-SID 423 o an IPv4 G-SID 425 4.1. SRv6 G-SID 427 SRv6 SID is a type of G-SID. A G-SID contains a single SRv6 SID, and 428 does not change anything of SRv6 SID. 430 4.2. Compression G-SID 432 As per [I-D.li-spring-compressed-srv6-np], a C-SID is a sub-set of a 433 compressable SRv6 SID, which can be used for routing the packets in 434 compressed SRv6 network programming. 436 A compression G-SID shown in Figure 6 may contains several C-SIDs and 437 optional padding. When C-SID is a 32 bits value, a compression G-SID 438 can consist of 4 C-SIDs. If the length of C-SIDs in a G-SID is less 439 than 128 bits, then padding is required. 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | C-SID 0 | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | C-SID 1 | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | C-SID 2 | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | C-SID 3 | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 (a) 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Padding | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Padding | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | C-SID 0 | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | C-SID 1 | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 (b) 467 Figure 6. Compression G-SID 469 4.3. MPLS G-SID 471 An MPLS G-SID shown in Figure 7 may contains 4 MPLS Label 472 Encapsulations, if number of MPLS Label Encapsulations is less than 473 4, then padding is required in G-SID for aligning with 128 bits. 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Label 0 | TC |S| TTL | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Label 1 | TC |S| TTL | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Label 2 | TC |S| TTL | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Label 3 | TC |S| TTL | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 (a) 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Padding | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Padding | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Label 0 | TC |1| TTL | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Label 1 | TC |S| TTL | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 (b) 501 Figure 7. MPLS G-SID 503 In order to indicate the MPLS G-SID, this document proposes a END.M 504 (End function with SR-MPLS path instantiation), this will be 505 described in section 6. 507 An MPLS G-SID appears after the END.M SID, and it can not be the last 508 G-SID in the G-SID list. 510 4.4. IPv4 G-SID 512 An IPv4 G-SID shown in Figure 8 contains 128 bits IPv4 tunnel related 513 information. The format of IPv4 G-SID is shown below. 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Type | Tunnel Parameters | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | IPv4 Src Address | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | IPv4 Dest Address | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Tunnel Parameters | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Figure 8. IPv4 G-SID 529 In order to indicate the IPv4 G-SID, this document proposes a END.4 530 (End function with IPv4 tunnel instantiation), this will be described 531 in section 7. The detailed encoding of IPv4 tunnel G-SID is also 532 described in section 7. 534 An IPv4 G-SID appears after the End.4 SID, and it can not be the last 535 G-SID in the G-SID list. 537 5. G-SRv6 for Crossing SRv6 Compression Domains 539 This section describes the mechanism of G-SRv6 for crossing SRv6 540 Compression Domains. 542 5.1. Mechanisms 544 The path for crossing SRv6 Compression Domain is called Compressed 545 SRv6 sub-path. It should be encoded in any location of a G-SRH. 546 There are following aspects should be considered in this mechanism: 548 o Compression SID indication 550 o C-SID length indication 552 o Start of C-SIDs indication 554 o End of C-SIDs indication 556 5.1.1. Compressable SID Indication 558 A new flavor can be introduced to indicate that an SRv6 SID is 559 compressable. There are two options for the definition of the 560 flavor: 562 o Option A: If the Compressable flavor is set for a specific SRv6 563 SID, it means that the SRv6 SID can be used as normal SRv6 SID and 564 also can be used as Compressable SRv6 SID. 566 o Option B: If the Compressable flavor is set for a specific SRv6 567 SID, it means that the SRv6 SID can only be used as Compressable 568 SRv6 SID. In this option, if an SRv6 SID is already allocated and 569 the compression requirement is proposed, a new SRv6 SID has to be 570 allocated as the Compressable SRv6 SID for the same function. 572 Though the Option B may use more SRv6 SIDs for the purpose of 573 compression, it has much advantages in the incremental deployment. 574 This document recommends the Option B. 576 5.1.2. C-SID Length Indication 578 Compresable SRv6 SID can be represented as Common Prefix + 579 C-SID+(Optional) Argument. There can be multiple options for the 580 length of C-SID as follows: 582 o Option A: a variable length in bytes 584 o Option B: optional length such as 16/32/64 bits 586 o Option C: only one option, 32 bits 588 Though the length of C-SID can be configured locally or advertised by 589 protocol extensions, the different length of C-SID will increase the 590 complexity of process of control plane and data plane which is not 591 necessary. This document recommends Option C which is a ideal 592 tradeoff between the compression and the enough space for node ID and 593 SRv6 Function. 595 5.1.3. Start of Compression Indication 597 In G-SRv6, if the SID list of an SRv6 sub-path consists of a list of 598 compressable SIDs, it can be programmed as follows: the first 599 compressable SID indicates the start of C-SRv6 sub-path, followed by 600 compressable G-SIDs, which includes C-SIDs and padding if the number 601 of (32 bits) C-SIDs is less than 4 in a G-SID. The format of 602 programmed SRv6 compression sub-path is shown in Figure 9. 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 . ... . 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Compression G-SID 1 | 610 | | 611 | | 612 | | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Compression G-SID 2 | 615 | | 616 | | 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Compressable SRv6 SID | 620 | | 621 | | 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Figure 9. G-SID list for SRv6 Compression Path 627 5.1.4. End of Compression Indication 629 Since C-SIDs and SRv6 SIDs can be encoded in any order in an SRH, a 630 mechanism for indicating the end of compression is needed. There are 631 mainly two options for the indication of the end of compression as 632 follows: 634 o Option A: an EOC (End of Compression) flavor is introduced when 635 advertise Compressable SRv6 SID. When the node determines the 636 IPv6 destination address of SRv6 packet is the Compresable SRv6 637 SID with EOC flavor, meaning the associated C-SID is the last 638 C-SID in the G-SID, and it will skip the G-SID in which the 639 corresponding C-SID located and read the following 128-bit SRv6 640 SID. 642 o Option B: an EOC C-SID is introduced in the G-SID to indicate the 643 end of the compression. The length of EOC C-SID is a 32 bits 644 value, and the it's value can be a well-known value such as 0 or a 645 node allocated value. If the number of C-SIDs in a Compression 646 G-SID is less than 4, the EOC can be used as the . If there are 4 647 C-SIDs in the last G-SID of Compressed SRv6 sub-path, it has to 648 insert a G-SID composed by 4 EOCs. 650 The different options for indication of end of compression are shown 651 in Figure 10. 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | C-SID 0 (EOC Flavor) | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | C-SID 1 (Non-EOC Flavor) | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | C-SID 2 (Non-EOC Flavor) | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | C-SID 3 (Non-EOC Flavor) | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 (a) Option A 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | | 667 | G-SID (MBZ) | 668 | | 669 | | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | C-SID 0 | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | C-SID 1 | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | C-SID 2 | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | C-SID 3 | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 (b) Option B 682 Figure 10. End of Compression Indication 684 5.1.5. Micro SID in G-SRv6 Compression 686 The Micro SID instruction is proposed at 687 [I-D.filsfils-spring-net-pgm-extension-srv6-usid], and it can be used 688 for forwarding SRv6 packets by shifting the IPv6 DA. The Micro SID 689 Carrier can be seen as a type of G-SID and can be directly used for 690 G-SRv6 as shown in Figure 11 (a). 692 The compressable SRv6 SID can also be used as the Micro SID and 693 encapsulated in the Micro SID Carrier. As shown in Figure 11 (b), 694 the first compressable SRv6 SID for the sub-path crossing SRv6 695 compression domain can be changed to a Micro SID carrier with the 696 locator block and multiple uSIDs which are also C-SIDs. Therefore, 697 multiple C-SIDs can be updated to the IPv6 DA in a single time. 699 After shifting the Micro SIDs in IPv6 DA and if the last Micro SID is 700 the C-SID without EOC flavor, the following multiple C-SIDs (Micro 701 segments) in the G-SID will be updated to the IPv6 DA instead of the 702 Micro SID carrier and the location of the C-SIDs in the G-SID is 703 recorded. If the rest C-SIDs in the current G-SID is less than the 704 C-SIDs should be copied to the IPv6 DA using as the Micro SID carrier 705 in a single time, only the rest C-SIDs will be copied to the IPv6 DA. 706 The next copy will begin with the first C-SID in the next G-SID. The 707 end of the C-SIDs shifting is indicated by a EOC flavor C-SID. When 708 an EOC flavor C-SID is processed, the next 128-bits G-SID will be 709 updated to the IPv6 DA. 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Block | uSID5(uN) | uSID6(uN) | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Block | uSID3(uN) | uSID4(uN) | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Block | uSID1(uN) | uSID2(uN) | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 (a) Original Micro SID carrier in G-SRv6 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | C-SID3(uN) | C-SID4(uN) | C-SID5(uN) | C-SID6(uN/EOC)| 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Block | C-SID1(uN) | C-SID2(uN) | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | 64 bits | 32 bits | 32 bits | 727 (b) C-SID(uN) in G-SRv6 729 Figure 11. Micro SID using in G-SRv6 731 In this mechanism, more SRH overhead can be reduced but it also 732 brings limitation of address planning and extra complexities. The 733 details will be discussed in the future version. 735 5.2. Illustration 737 According to the above mechanisms, the scenarios shown in the section 738 3.1 can be encoded as follows: 740 Scenario 1-1: 742 Assuming that 743 o A::1:1, A::2:1, A::3:1, A::4:1, A::5:1 are the Compressable SIDs. 745 o A::1:2, A::2:2, A::3:2, A::4:2, A::5:2 are the Compressable SIDs 746 with EOC flavor. 748 The programmed G-SRv6 path A1->A2->A3->A4->A5->A6->A7 is shown in 749 Figure 12: 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | A::7:10 | 755 | | 756 | | 757 | | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | A6::6:1 | 760 | | 761 | | 762 | | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | 5:2 | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | 4:1 | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | 3:1 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | 2:1 | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | A1::1:1 | 773 | | 774 | | 775 | | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 Figure 12. G-SRv6 Path for Scenario 1-1 780 Scenario 1-2: 782 The programmed G-SRv6 path A1->A2->A3->A4->B1->B2->B3->B4 is shown in 783 Figure 13: 785 0 1 2 3 786 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 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Padding | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | 4:2 | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | 3:1 | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | 2:1 | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | B::1:1 | 797 | | 798 | | 799 | | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Padding | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | 4:2 | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | 3:1 | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | 2:1 | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | A::1:1 | 810 | | 811 | | 812 | | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 Figure 13. G-SRv6 Path for Scenario 1-2 816 In reduced mode, the SID A::1:1 can be removed from the G-SRH. 818 The mechanism of indicating the C-SIDs within the G-SID will be 819 described in the document of G-SRH. 821 5.3. Effect on SRv6 823 G-SRv6 provides the flexibility of encoding SRv6 SID and SRv6 C-SID 824 in a single SRH, which supports to program an SRv6 path that consists 825 of compression capable and compression incapable nodes. In this 826 case, G-SRv6 solves the problem of SRv6 overhead with a limited 827 effect on SRv6. 829 o Independent with SRv6: G-SRv6 does not require that the SRv6 SID 830 Space has the common prefix for supporting compression. A new 831 address block can be allocated for compressable SID, and the 832 common prefix of Compressable SIDs can be configured with 833 appropriate length. 835 o Incremental upgrade: G-SRv6 does not require to upgrade all the 836 nodes along the path to support SRv6 compression, they can be 837 upgraded on demand to support compression. 839 5.4. Protocol Extensions Requirements 841 This section describes the protocol extension requirements. 843 5.4.1. Data Plane 845 REQ1-01: An SRv6 compression path can be represented as a G-SID list 846 consists of a compressable SRv6 SID and Compression G-SIDs. 848 REQ1-02: A Compression G-SID consists of at most 4 (32-bits) C-SIDs, 849 if the number of C-SID is less than 4, then padding is required to 850 align with 128 bits. 852 REQ1-03: If the first Compressable SID is copied to the IPv6 DA, then 853 the C-SIDs of the following G-SIDs should be read by the nodes along 854 the SRv6 compression sub-path and the C-SID part in IPv6 DA should be 855 replaced accordingly. 857 REQ1-04: The last C-SID in the G-SIDs for the SRv6 compression sub- 858 path should be the Compressable SRv6 SID with EOC flavor. 860 REQ1-05: When process the Compressalbe SRv6 SID with EOC flavor in 861 the IPv6 DA, the corresponding G-SID in the G-SRH should be skipped 862 and the IPv6 DA should be updated by the following SRv6 SID if 863 exists. 865 5.4.2. Control Plane 867 REQ1-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for 868 SRv6 compression capabilities 870 REQ1-12: ISIS/OSPF/BGP-LS/BGP extensions for advertising the 871 Compression flavor for Compressable SIDs. 873 REQ1-13: ISIS/OSPF/BGP-LS extensions for advertising the End-of- 874 compression(EOC) flavor for Compressable SIDs. 876 REQ1-14: ISIS/OSPF/BGP-LS/BGP extensions for advertising the format 877 of Compressable SIDs. 879 REQ1-21: BGP SRv6 Policy extensions for advertising the G-SRv6 for 880 SRv6 compression capabilities. 882 REQ1-22: BGP SR Policy extensions for programming a G-SRv6 path 883 combining with Compressable SRv6 SIDs and SRv6 SIDs. 885 REQ1-31: PCEP SRv6 Policy extensions for advertising the G-SRv6 for 886 SRv6 compression capabilities. 888 REQ1-32: PCEP SR Policy extension for programming a G-SRv6 path 889 combining with Compressable SRv6 SIDs and SRv6 SIDs. 891 REQ1-33: PCEP extensions for programming a G-SRv6 path combining with 892 Compressable SRv6 SIDs and SRv6 SIDs. 894 6. G-SRv6 for Crossing SR-MPLS Domain 896 This section describes the mechanism for encoding SRv6 SIDs and MPLS 897 G-SID in a single G-SRH. 899 6.1. Mechanisms 901 The path for crossing SR-MPLS domain is called SR-MPLS sub-path. It 902 can be encoded in any location of G-SRH. There are two aspects 903 should be considered in this mechanism: 905 o Start of MPLS G-SIDs indication 907 o End of MPLS G-SIDs indication 909 6.1.1. Start of MPLS G-SID Indication 911 In order to indicate the start of MPLS G-SIDs, new SRv6 SIDs types 912 should be defined. This document defines an SID function to indicate 913 the start of MPLS G-SIDs, called End.M ( End with MPLS labels). 915 An SR-MPLS sub-path can be encoded in the G-SRH as follows: 917 0 1 2 3 918 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 . ... . 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | MPLS G-SID 1 | 924 | | 925 | | 926 | | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | MPLS G-SID 2 | 929 | | 930 | | 931 | | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | End.M SRv6 SID | 934 | | 935 | | 936 | | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 Figure 14. SR-MPLS Sub-path Encoding in G-SRH 941 When a node processes an End.M SID, it copies the following MPLS 942 label stack encapsulation information of SR-MPLS sub-path in the MPLS 943 G-SIDs to the MPLS header, and set the IPv6 DA as the SRv6 SID 944 following the last MPLS G-SID of the SR-MPLS sub-path, and then 945 forward the packet according to the active MPLS label. 947 6.1.2. End of MPLS G-SID Indication 949 The S-bit in the MPLS label indicates the end of the MPLS label 950 within the current MPLS G-SIDs sub-list. 952 When the ingress node of the SR-MPLS sub-path reads the MPLS label 953 stack encapsulation information until the Label with S-bit set. If 954 the S-bit is set for the label encapsulation, it will skip the G-SID 955 in which the label locates and set the IPv6 DA of the SRv6 packet as 956 the SRv6 SID following the G-SID if exists. 958 6.2. Illustration 960 According to the above mechanisms, the scenarios shown in the section 961 3.2 can be encoded as follows: 963 Assuming that 964 o A::1:100 is the End.M SID allocated by the node A1 for crossing 965 SR-MPLS domain. 967 o Label 1001, 1002, 1003, 1004, 1005 and 1006 are allocated as the 968 node segment for A1/A2/A3/A4/A5/A6. 970 The programmed G-SRv6 path B1->A1->A2->A3->A6->A5->B4 is shown in 971 Figure 15: 973 0 1 2 3 974 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 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | B::4:1 | 977 | | 978 | | 979 | | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | 1005 | TC |1| TTL | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | 1006 | TC |0| TTL | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | 1003 | TC |0| TTL | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | 1002 | TC |0| TTL | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | A::1:100 (End.M) | 990 | | 991 | | 992 | | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | B::1:1 | 995 | | 996 | | 997 | | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 Figure 15. G-SRv6 Path for Sec 3.2 1002 6.3. Effect on SRv6 1004 G-SRv6 supports to program the SRv6 SID and SR-MPLS SID/MPLS label in 1005 a single G-SRH, which provides to encode the end-to-end G-SRv6 path 1006 across SRv6 domains and SR-MPLS/MPLS domains explicitly at the 1007 ingress node. However, it also brings complexities of network 1008 programming, so this document suggests to upgrade the SR-MPLS nodes 1009 to support SRv6. 1011 6.4. Protocol Extensions Requirements 1013 This section describes the protocol extension requirements of G-SRv6 1014 for MPLS G-SID. 1016 6.4.1. Data Plane 1018 REQ2-01: An MPLS path can be encoded in G-SRH as a series of G-SIDs 1019 including a 128-bit End.M SRv6 SID and a set of MPLS G-SIDs. 1021 REQ2-02: An MPLS G-SID can consist of up to 4 MPLS label/SR-MPLS SID, 1022 if the number of MPLS label/SR-MPLS SID is less than 4, padding is 1023 required to align with 128 bits. 1025 REQ2-03: An End.M SRv6 SID indicates the start of MPLS G-SID. 1027 REQ2-04: The SRv6 packet can be encapsulated with an outer MPLS 1028 header, and the MPLS header contains the MPLS labels carried by the 1029 MPLS G-SIDs. 1031 REQ2-05: When the label encapsulation with S-bit is set is read by 1032 the ingress node of the SR-MPLS sub-path, the corresponding G-SID 1033 should be skipped and the IPv6 DA should be updated by the following 1034 SRv6 SID if exists. 1036 6.4.2. Control Plane 1038 REQ2-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for 1039 MPLS capabilities 1041 REQ2-12: ISIS/OSPF/BGP-LS extensions for advertising the End.M SRv6 1042 SID. 1044 REQ2-21: BGP SR Policy extensions for advertising the G-SRv6 for MPLS 1045 capabilities 1047 REQ2-22: BGP SR Policy extensions for encoding G-SID list with SRv6 1048 SID and MPLS G-SID for G-SRv6 path. 1050 REQ2-31: PCEP SR Policy extensions for advertising the G-SRv6 for 1051 MPLS capabilities 1053 REQ2-31: PCEP SR Policy extensions for encoding G-SID list with SRv6 1054 SID and MPLS G-SID for G-SRv6 path. 1056 REQ2-33: PCEP extensions for encoding G-SID list with SRv6 SID and 1057 MPLS G-SID for G-SRv6 path. 1059 7. G-SRv6 for Crossing IPv4 Domain 1061 This section describes the mechanism of G-SRv6 for crossing IPv4 1062 domain. 1064 7.1. Mechanism 1066 The path for crossing IPv4 domain is called IPv4 tunnel sub-path. It 1067 should be encoded in any location of G-SRH. There are two aspects 1068 should be considered in this mechanism: 1070 o Start of IPv4 G-SID 1072 o IPv4 G-SID encoding 1074 7.1.1. Start of IPv4 G-SID Indication 1076 In order to indicate the start of IPv4 G-SIDs, new SRv6 SIDs types 1077 should be defined. 1079 This document defines an SID function to indicate the start of IPv4 1080 G-SIDs, called End.4( End with IPv4 tunnel). 1082 When a node processes the End.4 SID, it encapsulates an outer IPv4 1083 tunnel header for the SRv6 packet based on the tunnel information 1084 carried by the following IPv4 G-SID, and set the IPv6 DA as the SRv6 1085 SID following the IPv4 G-SID, and then forwards the packet according 1086 to the IPv4 DA. 1088 An IPv4 tunnel sub-path can be encoded in the G-SRH as follows: 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | IPv4 G-SID | 1094 | | 1095 | | 1096 | | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | SRv6 End.4 SID | 1099 | | 1100 | | 1101 | | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 Figure 16. IPv4 Tunnel Sub-path Encoding in G-SRH 1106 Also, this document proposes the END.B4 (End bound to an IPv4 tunnel) 1107 SID. A End.B4 is bound to an IPv4 tunnel. When the node receives a 1108 packet with End.B4 SID, the packet should be steered into the binding 1109 IPv4 tunnel. 1111 7.1.2. IPv4 G-SID encoding 1113 An IPv4 GID contains the IPv4 tunnel information including tunnel 1114 type, source IPv4 address, destination IPv4 address and tunnel 1115 parameters. Different types of IPv4 tunnels have specific 1116 parameters: 1118 o IPv4 UDP tunnel: the tunnel parameters includes source port and 1119 destination port. 1121 o IPv4 VXLAN tunnel: the tunnel parameters includes source port, 1122 destination port and VN ID. 1124 The detailed encapsulation formats for different types of IPv4 tunnel 1125 is out of scope of the document. 1127 7.2. Illustration 1129 According to the above mechanisms, the scenarios shown in the section 1130 3.3 can be encoded as follows: 1132 Assuming that 1134 o A::1:200 is the End.4 SID allocated by the node A1 for crossing 1135 IPv4 domain. 1137 The programmed G-SRv6 path B1->A1->A6->B4 is shown in Figure 17: 1139 0 1 2 3 1140 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 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | B::4:1 | 1143 | | 1144 | | 1145 | | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Type | Tunnel Parameters | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | IPv4 Src Address (A1) | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | IPv4 Dest Address (A6) | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Tunnel Parameters | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | A::1:200 (End.IP4) | 1156 | | 1157 | | 1158 | | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | B::1:1 | 1161 | | 1162 | | 1163 | | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 Figure 17. G-SRv6 Path for Sec 3.3 1168 7.3. Effect on SRv6 1170 G-SRv6 provides the capabilities for encoding IPv4 tunnel information 1171 and SRv6 SID within a single G-SRH, which brings benefits on end-to- 1172 end network programming on scenarios of packets traveling SRv6 1173 domains and IPv4 domains. However, it also brings new complexities, 1174 so this document suggests to upgrade the IPv4 nodes to support IPv6 1175 or SRv6. 1177 7.4. Protocol Extensions Requirements 1179 This section describes the protocol extension requirements of G-SRv6 1180 for IPv4 G-SID. 1182 7.4.1. Data Plane 1184 REQ3-01: An IPv4 tunnel can be encoded in G-SRH as series of G-SIDs 1185 including a 128 bit End.4 SRv6 SID and a set of IPv4 G-SIDs. 1187 REQ3-02: An IPv4 G-SID can consist of multiple IPv4 tunnel 1188 information, such as IPv4 source address and destination address of 1189 the tunnel endpoint. 1191 REQ3-03: An End.4 SRv6 SID indicates the start of IPv4 G-SID. 1193 REQ3-04: An End.B4 SRv6 SID indicates the IPv4 tunnel. 1195 REQ3-05: The SRv6 packet can be encapsulated with an outer IPv4 1196 tunnel header based on the parameters in the IPv4 G-SID. 1198 REQ3-06: After the tunnel information is read by the ingress node of 1199 the IPv4 tunnel sub-path, the corresponding G-SID should be skipped 1200 and the IPv6 DA should be updated by the following SRv6 SID if 1201 exists. 1203 7.4.2. Control Plane 1205 REQ3-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for 1206 IPv4 capabilities 1208 REQ3-12: ISIS/OSPF/BGP-LS extensions for advertising the End.4 SRv6 1209 SID. 1211 REQ3-13: ISIS/OSPF/BGP-LS extensions for advertising the End.B4 SRv6 1212 SID. 1214 REQ3-21: BGP SR Policy extensions for advertising the G-SRv6 for IPv4 1215 capabilities 1217 REQ3-22: BGP SR Policy extensions for encoding G-SID list with SRv6 1218 SID and IPv4 G-SID for G-SRv6 path. 1220 REQ3-31: PCEP SR Policy extensions for advertising the G-SRv6 for 1221 IPv4 capabilities 1223 REQ3-31: PCEP SR Policy extensions for encoding G-SID list with SRv6 1224 SID and IPv4 G-SID for G-SRv6 path. 1226 REQ3-33: PCEP extensions for encoding G-SID list with SRv6 SID and 1227 IPv4 G-SID for G-SRv6 path. 1229 8. IANA Considerations 1231 TBD 1233 9. Security Considerations 1235 TBD 1237 10. Contributors 1239 Zhibo Hu 1240 Huawei Technologies 1241 huzhibo@huawei.com 1243 Yang Xia 1244 Huawei Technologies 1245 yolanda.xia@huawei.com 1247 11. Acknowledgements 1249 12. References 1251 12.1. Normative References 1253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1254 Requirement Levels", BCP 14, RFC 2119, 1255 DOI 10.17487/RFC2119, March 1997, 1256 . 1258 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1259 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1260 May 2017, . 1262 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1263 (IPv6) Specification", STD 86, RFC 8200, 1264 DOI 10.17487/RFC8200, July 2017, 1265 . 1267 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1268 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1269 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1270 . 1272 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1273 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1274 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1275 July 2018, . 1277 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1278 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1279 (SRv6) Network Programming", RFC 8986, 1280 DOI 10.17487/RFC8986, February 2021, 1281 . 1283 [I-D.li-spring-compressed-srv6-np] 1284 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 1285 Guichard, J., Cong, L., and S. Peng, "Compressed SRv6 1286 Network Programming", draft-li-spring-compressed- 1287 srv6-np-02 (work in progress), February 2020. 1289 12.2. Informative References 1291 [I-D.filsfils-spring-srv6-net-pgm-illustration] 1292 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 1293 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 1294 J. Leddy, "Illustrations for SRv6 Network Programming", 1295 draft-filsfils-spring-srv6-net-pgm-illustration-03 (work 1296 in progress), September 2020. 1298 [I-D.tian-spring-srv6-deployment-consideration] 1299 Tian, H., Zhao, F., Xie, C., Li, T., Ma, J., Mwehair, R., 1300 Chingwena, E., Peng, S., Li, Z., and Y. Xiao, "SRv6 1301 Deployment Consideration", draft-tian-spring-srv6- 1302 deployment-consideration-04 (work in progress), January 1303 2021. 1305 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 1306 Filsfils, C., Camarillo, P., Cai, D., Voyer, D., Meilik, 1307 I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman, 1308 D., Liu, Y., and J. Guichard, "Network Programming 1309 extension: SRv6 uSID instruction", draft-filsfils-spring- 1310 net-pgm-extension-srv6-usid-08 (work in progress), 1311 November 2020. 1313 [I-D.lc-6man-generalized-srh] 1314 Li, Z., Li, C., Cheng, W., Xie, C., Cong, L., Tian, H., 1315 and F. Zhao, "Generalized Segment Routing Header", draft- 1316 lc-6man-generalized-srh-01 (work in progress), August 1317 2020. 1319 Authors' Addresses 1321 Weiqiang Cheng 1322 China Mobile 1324 Email: chengweiqiang@chinamobile.com 1326 Zhenbin Li 1327 Huawei Technologies 1328 Huawei Campus, No. 156 Beiqing Rd. 1329 Beijing 100095 1330 China 1332 Email: lizhenbin@huawei.com 1334 Cheng Li 1335 Huawei Technologies 1336 Huawei Campus, No. 156 Beiqing Rd. 1337 Beijing 100095 1338 China 1340 Email: c.l@huawei.com 1342 Chongfeng Xie 1343 China Telecom 1344 China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District 1345 Beijing 1346 China 1348 Email: xiechf@chinatelecom.cn 1350 Cong Li 1351 China Telecom 1352 China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District 1353 Beijing 1354 China 1356 Email: licong@chinatelecom.cn 1357 Hui Tian 1358 CAICT 1359 Beijing 1360 China 1362 Email: tianhui@caict.ac.cn 1364 Feng Zhao 1365 CAICT 1366 Beijing 1367 China 1369 Email: zhaofeng@caict.ac.cn