idnits 2.17.1 draft-decraene-spring-srv6-vlsid-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 11, 2020) is 1323 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 284 -- Looks like a reference, but probably isn't: '1' on line 284 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-08 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-18 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-07 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Decraene 3 Internet-Draft Orange 4 Intended status: Standards Track R. Raszuk 5 Expires: March 15, 2021 Bloomberg 6 Z. Li 7 C. Li 8 Huawei Technologies 9 September 11, 2020 11 SRv6 vSID: Network Programming extension for variable length SIDs 12 draft-decraene-spring-srv6-vlsid-04 14 Abstract 16 This document proposes an extension to Segment Routing IPv6 (SRv6) 17 Network Programming to allow for SRv6 Segment Identifier (SID) of 18 smaller variable length. The use of smaller SRv6 SID reduces the 19 size the SRv6 Header (SRH). This reduces the overhead for both the 20 traffic volume and the network processor. It is a straightforward 21 extension to the SRv6 Network Programming model and its SRH 22 encapsulation. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 15, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. SRv6 Variable Length SIDs . . . . . . . . . . . . . . . . . . 4 62 3.1. Encoding vSIDs in the SRH . . . . . . . . . . . . . . . . 5 63 3.2. SRv6 vSIDs Network Programming . . . . . . . . . . . . . 7 64 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.1. Global vSIDs . . . . . . . . . . . . . . . . . . . . . . 9 67 5.2. Local vSIDs . . . . . . . . . . . . . . . . . . . . . . . 10 68 6. Signaling vSIDs length . . . . . . . . . . . . . . . . . . . 11 69 6.1. Signaling vSIDs length in IS-IS . . . . . . . . . . . . . 11 70 7. Optional extensions . . . . . . . . . . . . . . . . . . . . . 12 71 7.1. A node requiring a larger vSIDs length. . . . . . . . . . 12 72 7.2. Inter Routing Domains with the End.XvPS behavior . . . . 14 73 7.3. NSIDs flavor . . . . . . . . . . . . . . . . . . . . . . 15 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 77 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 78 12. Changes / Authors Notes . . . . . . . . . . . . . . . . . . . 16 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 81 13.2. Informative References . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 The Segment Routing (SR) architecture is defined RFC 8402 [RFC8402]. 88 IPv6 Segment Routing Header (SRH) is defined RFC 8754 [RFC8754]. 90 SRv6 Network Programming is defined 91 [I-D.ietf-spring-srv6-network-programming]. 93 The reader is expected to be familiar with the three above documents 94 which define Segment Routing over the IPv6 data-plane (SRv6). 96 SRv6 is flexible and powerful, but in some uses cases, when a large 97 number of SIDs are required, the size of the SRH/SID may be seen as 98 too large both for some dataplane processors and traffic overhead. 100 The goal of this document is to propose a solution which reduces the 101 size of the SRv6 header when a high number of SIDs is required with 102 minimal changes to the SRv6 architecture, signaling, SRH and data 103 plane processing. 105 This document extends SRH and SRv6 Network Programming to allow for 106 SIDs of variable length, from 1 up to 128 bits. In a way, this is a 107 generalization of SRv6 for any (v)SID length, where 128-bits SIDs is 108 a special case. 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 116 appear in all capitals, as shown here. 118 2. Overview 120 In a nutshell, SRv6 variable length SIDs (SRv6 vSIDs) proposes to: 122 o define one SRv6 SIDs prefix dedicated to SRv6 vSIDs and called 123 SRv6 vSIDs prefix; 125 o define the vSID as the SRv6 SID minus the vSIDs prefix: SRv6 SID:= 126 SRv6 vSIDs prefix + SRv6 vSID; 128 o encode, in the Segment List of the SRH, only the vSIDs. 130 In other words, 128-bits SRv6 SIDs are kept unchanged for signaling, 131 configuration and SR policies. In the data plane, this proposal 132 compresses the encoding of SRv6 SIDs in the SRH by not encoding the 133 SRv6 vSIDs prefixes which are redundant across vSIDs. 135 The use of the destination address in the IPv6 header is unchanged. 136 The IPv6 destination address still contains the current/next 128-bits 137 SRv6 SID. As a consequence, the IPv6 destination address already 138 indicates the SRv6 vSID prefix and there is no extend the SRH to 139 carry it. 141 In a way, this is similar to SR-MPLS RFC 8660 [RFC8660]: 143 o For SR-MPLS: SR-MPLS Label:= SRGB + Index 145 o For SRv6 vSID: SRv6 SID := SRv6 vSID prefix + SRv6 vSID 147 One difference compared to SR-MPLS is that lowest bits of the SRv6 148 vSID prefix are zero which allows for an easier operation in the data 149 plane. Indeed,the addition of the vSID may be replaced by a copy of 150 the vSID bits. Another difference is that the motivation to offset 151 to a zero base index/vSID is different. 153 Except for the Segment List using (shorter) vSIDs, the format of the 154 SRH is unchanged. The length of the vSIDs is defined to be 128 bits 155 minus the length of the vSIDs prefix. It is variable but its length 156 does not need to be encoded in the SRH header. Indeed the vSIDs 157 length only needs to be known by the SR Segment Endpoint Node 158 processing it. As per section 4.3 of RFC 8754 [RFC8754], the SR node 159 identifies its local SID by performing a longest-prefix-match lookup 160 on the packet IPv6 destination address. This identifies the SID and 161 its properties, such as the SR endpoint behavior but also the length 162 of the vSIDs. 164 3. SRv6 Variable Length SIDs 166 An SRv6 vSID deployment choose one length 'L' of vSIDs and an 167 associated SRv6 vSIDs prefix. 169 0 (bits) vSIDs 128 170 Length 172 +--------------------------------------------------------------+ 173 | SRv6 SID | 174 +--------------------------------------------------------------+ 176 +--------------------------------------------------------------+ 177 | SRv6 vSIDs prefix | vSID | 178 +--------------------------------------------------------------+ 180 Figure 1: SRv6 SID:= SRv6 vSIDs prefix + SRv6 vSID 182 An SRv6 vSID deployment may use multiple SRv6 vSIDs prefixes. Each 183 prefix may have its own vSIDs length. 185 As per section 3.1 of [I-D.ietf-spring-srv6-network-programming], an 186 SRv6 SID can be represented as 'B:N:FUNCT:ARG'. Where 'B' is the 187 SRv6 SID prefix, N is the identifier of the parent node N, FUNCT is 188 the function of the SID of length 128-S. 190 If SRv6 vSIDs are to identify global segments, the SRv6 vSIDs prefix 191 would typically be 'B' while the vSID would be 'N:FUNCT:ARG'. 193 If SRv6 vSIDs are to only identify local segments, there is no need 194 to globally route toward a node hence the 'N' may have a size of 195 zero. This may be interesting for a deployment using both 128-bits 196 SRv6 SIDs and very short SRv6 vSIDs. Such SRv6 vSIDs could be used 197 when a strictly routed path is needed and encoded as a list of 198 adjacency SIDs. Given that the number of local adjacency SIDs is 199 independent of the size of the SR domain, and typically below 255, 200 one could use 8-bits vSIDs which would allow encoding 16 vSIDs within 201 a single 128-bits SRv6 SID hence provides a very effective SRH 202 compression. 204 In order to simplify implementations, the length of the vSIDs MUST be 205 a multiple of 8-bits, up to 128 bits included, in order to provide 206 octet alignment in the SRH Segment List. However this specifications 207 is written to work for any bit granularity from 1 to 128 bits. This 208 allows for a future document to define a new profile with a higher 209 granularity (e.g. 1 bit, 4 bits, 16 bits, or an integer fraction 210 128-bits) depending on hardware capabilities and flexibility 211 requirements. To allow some implemementations to be further 212 simplified, a specific profile 'Profile-32' is created restricting 213 the vSID lengh to be 32-bits. 215 3.1. Encoding vSIDs in the SRH 217 As per section 2 of RFC 8754 [RFC8754], the Segment Routing Header 218 (SRH) is defined as follows: 220 0 1 2 3 221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Last Entry | Flags | Tag | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 | Segment List[0] (128 bits IPv6 address) | 229 | | 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 | | 234 ... 235 | | 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 | Segment List[n] (128 bits IPv6 address) | 240 | | 241 | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 // // 244 // Optional Type Length Value objects (variable) // 245 // // 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 2: SRH with 128-bits SRv6 SID 250 When vSIDs are used, there are encoded in the Segment List of the 251 Segment Routing Header (SRH). 253 vSIDs are encoded back to back using their native length. There is 254 no padding between SIDs and there is no specific alignment of the 255 SID. 257 In a SRH, all vSIDs have the same vSIDs length 'L' and the same SRv6 258 vSIDs prefix. 260 If the Segment List[n] does not end on a octet boundary, then padding 261 bits MUST be added up to the next octet boundary. Those padding bits 262 MUST be set to 0 when sent and ignored on receipt. 264 TLVs starts on next octet boundary. 266 As defined in RFC 8754 [RFC8754], padding TLVs are used to pad the 267 SRH to a multiple of 8 octets. As vSIDs may be of any size, not 268 necessarily a multiple of 8 octets, the support of padding TLVs are 269 REQUIRED. 271 The fields 'Segments Left' and 'Last Entry" keep their meaning but 272 refers to vSIDs of length L. 274 The following diagram illustrates an example of SRH with vSIDs of 275 sixteen bits: 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Last Entry | Flags | Tag | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Segment List[0] | Segment List[1] | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | ..... ..... | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Segment List[n] | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 // // 291 // Optional Type Length Value objects (variable) // 292 // // 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 3: SRH with SRv6 vSIDs with 16-bits vSIDs 297 3.2. SRv6 vSIDs Network Programming 299 This section defines the extension to SRv6 Network Programming using 300 the "End" Endpoint behavior but is applicable to all SID behaviors. 302 The processing takes as an argument the length L of the vSIDs. This 303 length L is a property of the vSID and is given as a result of the 304 lookup on the IPv6 destination address which identifies the SRv6 SID 305 and its properties. The properties include the Endpoint behavior and 306 the length L of the vSIDs. 308 When N receives a packet whose IPv6 DA is S and S is a local vSID of 309 length L, the lines S08 and S14 of the End processing which were, as 310 per section 4.1 of [I-D.ietf-spring-srv6-network-programming]: 312 S08. max_LE = (Hdr Ext Len / 2) - 1 314 [...] 315 S14. Update IPv6 DA with Segment List[Segments Left] 317 are replaced by the following: 319 S08. max_LE = (Hdr Ext Len * 64 / L) - 1 321 [...] 323 S14. Copy Segment List[Segments Left] from the SRH to the L lowest 324 order bits of the destination address of the IPv6 header. 326 Note: S14. Taking into consideration that the Segment List is a list 327 of vSIDs of length L bits 329 4. Benefits 331 SRv6 vSID is believed to have the following benefits: 333 o Aligned with SRv6: SR architecture, SRv6 Network Programming. 335 o Reduced SID hence reduced header length. 337 o Flexible SID length, to accommodate for various deployment models, 338 network sizes, SRv6 usages. 340 * A typical vSIDs length could be 32 bits. Compared to SR-MPLS 341 (which has a 20 bits SID) it is larger and more scalable. 342 Compared to SRv6 (which has a 128 bits SID) it's four times 343 more compact. 345 * Other SID length are possible: 16 bits would be 8 times more 346 compact than SRv6 SID and 2 times more compact the SR-MPLS shim 347 header and large enough for most deployments; 8 bits would be 348 16 (respectively 4) more compact than SRv6 SID (respectively 349 SR-MPLS shim header) and could fit some specific deployments 350 (e.g. local adjacency SID only). 352 o Using SRv6 header (SRH) with no additional fields. 354 o No requirement for additional IPv6 addressing space: a /64 per 355 router is more than enough. A /96 per router is the typical 356 requirement. 358 5. Illustrations 360 This section illustrates the usage of SRv6 vSIDs through two 361 examples. The first example uses global segments with a vSIDs 362 locator been globally routable. The second example uses local 363 segments only with a vSIDs locator commom to all SR end nodes hence 364 not been able to locate a specific SR end node. Global and local 365 segments are defined as per RFC 8402 [RFC8402] section 2. 367 5.1. Global vSIDs 369 In this example vSIDs are used for global SIDs and are used alone 370 without 128-bits SRv6 SIDs. 372 The SR domain has the following caracteristics: 374 o 1 000 SR endpoints nodes; 376 o network diameter is 10; 378 o vSIDs are chosen to be 32-bits long; 380 o each SRv6 node is allocated a /108 to allocate its vSIDs from. 381 This allows for 4 096 (2^^12) locators 1 million (2^^20) local 382 functions on each SR node; 384 o the SR domain and the SRv6 vSIDs prefix is allocated: 385 2001:DB8::/96; 387 o node N is allocated 2001:DB8:0:0:0:0:N/108; 389 Some metrics of this SR domain: 391 o An SR policy encoding a strictly routed path using only Adjacency 392 SIDs would need ten 32-bits vSIDs resulting in a total of 40 393 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 394 would require 160 octets; 396 o An SR policy using strictly routed path using four (node) SIDs 397 would need four 32-bits vSIDs resulting in a total of 16 octets in 398 the SRH. In contrast the use of 128-bits SRv6 SIDs would require 399 64 octets and the use of 20-bits SR-MPLS SID would require 16 400 octets; 402 o The IGP advertises 1 000 SRv6 locators to be installed in the IPv6 403 FIB of all IGP nodes (as per regular SRv6 and SR-MPLS); 405 o The IPv6 address space is one /108 per SR node for a total of one 406 /96 for the whole SR domain. 408 5.2. Local vSIDs 410 In this example vSIDs are used only for local SIDs, such as adjacency 411 SIDs. vSIDs are used in complement with 128-bits SRv6 SIDs. 413 The SR domain has the following caracteristics: 415 o 10 000 SR endpoints nodes; 417 o network diameter is 30; 419 o SRv6 SIDs: 421 * each SRv6 node is allocated a /64 to allocate its 128-bits SIDs 422 from; 424 * SRv6 prefix: 2001:DB8::/48 (i.e., 65535 /64, allowing for 425 growth or multiple SR routing algorithms); 427 * node N is allocated 2001:DB8:0:N/64; 429 o SRv6 vSIDs 431 * local vSIDs are chosen to be 8-bits in length. They are used 432 for adjacency SIDs hence allow for 255 Adjacency SIDs per node; 434 * SRv6 vSIDs prefix is allocated 2001:DB8:0:FFFF::/120; 436 Some metrics of this SR domain: 438 o An SR policy encoding a strictly routed path using only adjacency 439 SIDs would need thirty 8-bits vSIDs resulting in a total of 32 440 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 441 would require 480 octets and the use of 20-bits SR-MPLS SID would 442 require 120 octets; 444 o The IGP advertises 10 000 SRv6 locators to be installed in the 445 IPv6 FIB of all IGP nodes (as per regular SRv6 or SR-MPLS); 447 o The IPv6 address space is one /64 per SR node for a total of one 448 /48 for the whole SR domain. 450 6. Signaling vSIDs length 452 Control plane extensions are required to signal the length of the 453 vSIDs. 455 6.1. Signaling vSIDs length in IS-IS 457 SRv6 SIDs are advertised in IS-IS as per 458 [I-D.ietf-lsr-isis-srv6-extensions]. 460 This document defines a new sub-TLV called vSIDs Length' that MAY be 461 advertised in the locator entries of the SRv6 Locator TLV. The 462 format is the following: 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Type | Length | Flags | vSIDs Length | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 4: IS-IS vSIDs Length sub-TLV 472 Type: TBD1. 474 Length: 2. 476 Flags: 1 octet. No flags are currently defined. MUST be set to zero 477 when sent and ignored when received. 479 vSIDs Length: length of the vSIDs in bits. This applies for all SIDs 480 of this locator. 482 The SRv6 vSIDs prefix is not advertised but can be computed. The 483 SRv6 vSIDs prefix is the 'vSIDs Length' first bits of the Locator. 484 It's length is 128 - 'vSIDs Length'. 486 The vSIDs Length MUST be between 1 and 128. If this restriction is 487 not met, the Locator entry MUST be ignored. 489 When the vSIDs Length sub-TLV is not present, the vSIDs length is 490 defined to be 128 (regular SRv6 SID length). 492 Note: there are multiple choices to advertise the vSIDs Length. 493 E.g., as a Sub-Sub-TLV of SRv6 End SID, SRv6 End.X SID or SRv6 LAN 494 End.X SID TLVs; as a property of the SR node. Alternatively the size 495 of the vSIDs prefix can be advertised in the Locator Block length 'LB 496 length' of the SRv6 SID Structure Sub-Sub-TLV defined in 498 [I-D.ietf-lsr-isis-srv6-extensions] with the additional specification 499 of a new SRv6 vSIDs capability/flag. ( The finale encoding choice is 500 postponed to a future version of this document. 502 7. Optional extensions 504 7.1. A node requiring a larger vSIDs length. 506 One SR Endpoint node may need a larger vSIDs space. This may 507 especially be the case when at the same time: 509 o the vSIDs Length is chosen to be small in order to optimize for 510 the size of the SRH header. Indeed, for topological/routing 511 instructions, the number of SIDs in the SRH may be high in some 512 use cases, up to the network diameter, calling for small vSIDs. 514 o one vSID is a service instruction and the number of service SIDs 515 may be high, requiring a SID longer than a vSIDs Length. 517 This section defines two solutions to increase the vSIDs length on a 518 node requiring a vSIDs space larger than other nodes. 520 7.1.1. Allocating a shorter locator to a node. 522 In order to increase the vSIDs length on a node, a simple option is 523 to allocate multiple locators of a larger locator to this node, 524 within the SRv6 vSIDs prefix. As per 525 [I-D.ietf-spring-srv6-network-programming], a locator may be 526 represented as B:N where B is the SRv6 SID block (IPv6 subnet 527 allocated for SRv6 SIDs by the operator) and N is the identifier of 528 the parent node instantiating the SID. Following this format, 529 multiple node identifiers Ns may be allocated to a node. Allocating 530 'k' identifiers increase the vSIDs space of that node by 'k'. 532 7.1.2. Combining k vSIDs to identify a behavior. 534 When an SR Endpoint node needs more SIDs than allowed by the vSIDs 535 Length, it MAY combine two (resp. N) vSIDs of length L to 536 effectively benefit from a vSID of length 2*L (resp. N*L). This is 537 a local choice of this SR Endpoint. Nothing specific is required in 538 the SRH which only contains those 2 (resp. N) SIDs instead of a 539 single one. 541 Note that when two vSIDs are combined, the first vSID may be seen as 542 having the role of a "Context SID" identifying a context specific SID 543 space/table, with the second SID been looked up in this context 544 specific table. This is similar to the Context-Specific Label space 545 defined in the section 3 of RFC 5331 [RFC5331]. 547 This section defines the extension to SRv6 Network Programming 548 allowing for a SID behavior "End.DT6" to be encoded with 'k' vSID. 549 This is equally applicable to others SID behaviors. 551 The processing takes as an argument the vSIDs Length 'L', and the 552 number of vSIDs 'k'. 'L' and 'k' are a property of the vSID and are 553 given as a result of the lookup of the IPv6 destination address which 554 identifies the SRv6 SID and its properties. The properties include 555 the Endpoint behavior, the length L of the vSIDs and the number 'k' 556 of vSIDs used to encode this behavior in the SRH. 558 When N receives a packet destined to S and S is a local End.DT6 SID 559 encoded with 'k' vSIDs, N does the following processing: 561 When N receives a packet whose IPv6 DA is S and S is a local End.DT6 562 vSID of length L and encoded with 'k' vSIDs the line S02 of the 563 End.DT6 processing which was, as per section 4.6 of 564 [I-D.ietf-spring-srv6-network-programming]: 566 S02. If (Segments Left != 0) { 568 is replaced by the following: 570 S02. If (Segments Left != k - 1) { 572 When processing the Upper-layer header of a packet, the lines S04-S05 573 which were: 575 S04. Remove the outer IPv6 Header with all its extension headers 577 S05. Set the packet's associated FIB table to T 579 are replaced by the following: 581 S04a. Read the k-1 next vSIDs 583 S04b. Remove the outer IPv6 Header with all its extension headers 585 S05. Set the packet's associated FIB table to the one identified by 586 the concatenation of the k-1 next vSIDs 588 7.2. Inter Routing Domains with the End.XvPS behavior 590 Some SRv6 traffic may need to cross multiple routing domains, such as 591 differents Autonomous Systems (ASes) or different routing areas. 592 Different routing domains may use different addressing schema making 593 it difficult to find a common SRv6 vSIDs prefix. 595 This section defines an optional solution and SID behavior allowing 596 for the use of different SRv6 vSIDs prefixes between routing domains. 598 The solution requires a new SID behavior, called "Endpoint with 599 cross-connect to an array of layer-3 adjacencies and SRv6 vSIDs 600 Prefix Swap" (End.XvPS for short) allowing for this transition of 601 SRv6 vSIDs prefix between two routing domains. 603 End.XvPS is a variant of End.X, performing both "End.X Layer-3 Cross- 604 Connect" and the translation of the SRv6 vSIDs prefix between the two 605 routing domains. 607 The processing takes as an argument the vSIDs length L and the prefix 608 P2 of the SRv6 vSIDs prefix in the second domain. Those two 609 parameters are a property of the (received) vSID and are given as a 610 result of the lookup on the IPv6 destination address which identifies 611 the SRv6 SID and its properties. 613 When N receives a packet whose IPv6 DA is S and S is a End.XvPS SID 614 behavior, with a local vSID length L, and a remote/next SRv6 vSIDs 615 prefix P2, the line S14 of the End processing which was, as per 616 section 4.1 of [I-D.ietf-spring-srv6-network-programming]: 618 S14. Update IPv6 DA with Segment List[Segments Left] 620 is replaced by the following: 622 S14. Copy Segment List[Segments Left] from the SRH to the L lowest 623 order bits of the destination address of the IPv6 header and copy the 624 SRv6 vSIDs prefix P2 to the 128-L highest order bits of the 625 destination address. 627 Note: the way the SRv6 vSIDs prefix P2 of the next routing domain is 628 known is out of scope of this document. As examples, they could be 629 learnt via configuration or using a signaling protocol either with 630 the peer domain of with a central controler (e.g. PCE). 632 When End.XvPS SID behavior is used, the restriction on the SRH is 633 relaxed and becomes: in a SRH, all vSID MUST have the same vSID 634 length 'L' and within a routing domain, the same SRv6 vSID 635 prefix.Between routing domaines, separated with the End.XvPS 636 behavior, SRv6 vSID prefixes may be different. 638 7.3. NSIDs flavor 640 The NSIDs flavors is a variant of the End, End.X and End.XvPS 641 behaviors. 643 The NSIDs flavors copy N vVSID from the SRH to the IPv6 destination 644 address. 646 When N receives a packet whose IPv6 DA is S and S is a NSIDs flavor, 647 with a local vSID length L, and a local paramater N, the lines S09, 648 S13 and S14 of the End processing which was, as per section 4.1 of 649 [I-D.ietf-spring-srv6-network-programming]: 651 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 653 S13. Decrement Segments Left by 1 655 S14. Update IPv6 DA with Segment List[Segments Left] 657 are replaced by the following: 659 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) or 660 (Segments Left < = N){ 662 S13. Decrement Segments Left by N 664 S14. Copy N Segments List[Segments Left+N-1]...List[Segments Left] 665 from the SRH to the N*L lowest order bits of the destination address 666 of the IPv6 header. 668 Note that if N=128/L, a complete IPv6 address is copied. This is 669 useful when the next SR node is an SRv6 PE requiring its 128-bits 670 SIDs in the IPv6 destination address. This is also useful for inter 671 domain scenarios where both domains use unrelated address spaces and 672 hence use two different SRv6 vSIDs prefixes. 674 8. IANA Considerations 676 TBD. 678 9. Security Considerations 680 This document does not change the security considerations of SRv6. 681 Please refers to RFC 8402 [RFC8402], RFC 8754 [RFC8754] and 683 [I-D.ietf-spring-srv6-network-programming] for existing security 684 consideration. 686 10. Acknowledgements 688 This document has been inspired by the work of the SPRING WG and in 689 particular the work done in 690 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] and 691 [I-D.li-spring-compressed-srv6-np]. The authors would like to 692 acknowledge the authors of these two documents. 694 The authors would like to thank Joel Halpern and Francois Clad for 695 their review and comments. 697 11. Contributors 699 Daniel Voyer 701 Bell Canada 703 Canada 705 Email: daniel.voyer@bell.ca 707 12. Changes / Authors Notes 709 [RFC Editor: Please remove this section before publication] 711 00: Initial version. 713 01: 715 o Removal of the vSID Size TLV; addition of the IS-IS extension; 716 addition of the SR header length check in the pseudo code. 718 o Addition of the IS-IS extension; 720 o Addition of the SR header length check in the pseudo code. 722 02: 724 o Change of terminology (VLSID changed to vSID); 726 o Swapping the two examples in section 'Illustrations'.; 728 o Addition of two solutions to provide more vSID space to some nodes 729 in section 'Node requiring a larger vSID length'; 731 o Addition of a solution for crossing routing domains using 732 differents SRv6 vSID prefixes and/or different vSID length; 734 03: 736 o Minor updates in section 'Inter Routing Domains' 738 04: 740 o Creating of a profile only supporting vSID of length 32-bits. 742 o Addition of the NSIDs flavor. 744 13. References 746 13.1. Normative References 748 [I-D.ietf-lsr-isis-srv6-extensions] 749 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 750 Z. Hu, "IS-IS Extension to Support Segment Routing over 751 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 752 (work in progress), April 2020. 754 [I-D.ietf-spring-srv6-network-programming] 755 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 756 Matsushima, S., and Z. Li, "SRv6 Network Programming", 757 draft-ietf-spring-srv6-network-programming-18 (work in 758 progress), August 2020. 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, 762 DOI 10.17487/RFC2119, March 1997, 763 . 765 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 766 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 767 May 2017, . 769 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 770 Decraene, B., Litkowski, S., and R. Shakir, "Segment 771 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 772 July 2018, . 774 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 775 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 776 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 777 . 779 13.2. Informative References 781 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 782 Filsfils, C., Camarillo, P., Cai, D., Voyer, D., Meilik, 783 I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman, 784 D., Liu, Y., and J. Guichard, "Network Programming 785 extension: SRv6 uSID instruction", draft-filsfils-spring- 786 net-pgm-extension-srv6-usid-07 (work in progress), May 787 2020. 789 [I-D.li-spring-compressed-srv6-np] 790 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 791 Guichard, J., Cong, L., and S. Peng, "Compressed SRv6 792 Network Programming", draft-li-spring-compressed- 793 srv6-np-02 (work in progress), February 2020. 795 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 796 Label Assignment and Context-Specific Label Space", 797 RFC 5331, DOI 10.17487/RFC5331, August 2008, 798 . 800 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 801 Decraene, B., Litkowski, S., and R. Shakir, "Segment 802 Routing with the MPLS Data Plane", RFC 8660, 803 DOI 10.17487/RFC8660, December 2019, 804 . 806 Authors' Addresses 808 Bruno Decraene 809 Orange 811 Email: bruno.decraene@orange.com 813 Robert Raszuk 814 Bloomberg 816 Email: robert@raszuk.net 818 Zhenbin Li 819 Huawei Technologies 821 Email: lizhenbin@huawei.com 822 Cheng Li 823 Huawei Technologies 825 Email: chengli13@huawei.com