idnits 2.17.1 draft-decraene-spring-srv6-vlsid-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (February 5, 2020) is 1541 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 278 -- Looks like a reference, but probably isn't: '1' on line 278 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-04 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-08 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-02 == Outdated reference: A later version (-02) exists of draft-li-spring-compressed-srv6-np-01 Summary: 0 errors (**), 0 flaws (~~), 6 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: August 8, 2020 Bloomberg 6 February 5, 2020 8 SRv6 vSID: Network Programming extension for variable length SIDs 9 draft-decraene-spring-srv6-vlsid-02 11 Abstract 13 This document proposes an extension to Segment Routing IPv6 (SRv6) 14 Network Programming to allow for SRv6 Segment Identifier (SID) of 15 smaller variable length. The use of smaller SRv6 SID reduces the 16 size the SRv6 Header (SRH). This reduces the overhead for both the 17 traffic volume and the network processor. It is a straightforward 18 extension to the SRv6 Network Programming model and its SRH 19 encapsulation. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 8, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. SRv6 Variable Length SIDs . . . . . . . . . . . . . . . . . . 4 59 3.1. Encoding vSIDs in the SRH . . . . . . . . . . . . . . . . 5 60 3.2. SRv6 vSIDs Network Programming . . . . . . . . . . . . . 7 61 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.1. Global vSIDs . . . . . . . . . . . . . . . . . . . . . . 9 64 5.2. Local vSIDs . . . . . . . . . . . . . . . . . . . . . . . 10 65 6. Signaling vSIDs length . . . . . . . . . . . . . . . . . . . 11 66 6.1. Signaling vSIDs length in IS-IS . . . . . . . . . . . . . 11 67 7. A node requiring a larger vSIDs length. . . . . . . . . . . . 12 68 7.1. Allocating a larger locator to a node. . . . . . . . . . 12 69 7.2. Combining k vSIDs to identify a behavior. . . . . . . . . 12 70 8. Inter Routing Domains . . . . . . . . . . . . . . . . . . . . 13 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 74 12. Changes / Authors Notes . . . . . . . . . . . . . . . . . . . 15 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 77 13.2. Informative References . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 The Segment Routing (SR) architecture is defined RFC 8402 [RFC8402]. 84 IPv6 Segment Routing Header (SRH) is defined 85 [I-D.ietf-6man-segment-routing-header]. 87 SRv6 Network Programming is defined 88 [I-D.ietf-spring-srv6-network-programming]. 90 The reader is expected to be familiar with the three above documents 91 which define Segment Routing over the IPv6 data-plane (SRv6). 93 SRv6 is flexible and powerful, but in some uses cases, when a large 94 number of SIDs are required, the size of the SRH/SID may be seen as 95 too large both for some dataplane processors and traffic overhead. 97 The goal of this document is to propose a solution which reduces the 98 size of the SRv6 header when a high number of SIDs is required with 99 minimal changes to the SRv6 architecture, signaling, SRH and data 100 plane processing. 102 This document extends SRH and SRv6 Network Programming to allow for 103 SIDs of variable length, from 1 up to 128 bits. In a way, this is a 104 generalization of SRv6 for any (v)SID length, where 128-bits SIDs is 105 a special case. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 113 appear in all capitals, as shown here. 115 2. Overview 117 In a nutshell, SRv6 variable length SIDs (SRv6 vSIDs) proposes to: 119 o define one SRv6 SIDs prefix dedicated to SRv6 vSIDs and called 120 SRv6 vSIDs prefix; 122 o define the vSID as the SRv6 SID minus the vSIDs prefix: SRv6 SID:= 123 SRv6 vSIDs prefix + SRv6 vSID; 125 o encode, in the Segment List of the SRH, only the vSIDs. 127 In other words, 128-bits SRv6 SIDs are kept unchanged for signaling, 128 configuration and SR policies. In the data plane, this proposal 129 compresses the encoding of SRv6 SIDs in the SRH by not encoding the 130 SRv6 vSIDs prefixes which are redundant across vSIDs. 132 The use of the destination address in the IPv6 header is unchanged. 133 The IPv6 destination address still contains the current/next 128-bits 134 SRv6 SID. As a consequence, the IPv6 destination address already 135 indicates the SRv6 vSID prefix and there is no extend the SRH to 136 carry it. 138 In a way, this is similar to SR-MPLS RFC 8660 [RFC8660]: 140 o For SR-MPLS: SR-MPLS Label:= SRGB + Index 142 o For SRv6 vSID: SRv6 SID := SRv6 vSID prefix + SRv6 vSID 143 One difference compared to SR-MPLS is that lowest bits of the SRv6 144 vSID prefix are zero which allows for an easier operation in the data 145 plane. Indeed,the addition of the vSID may be replaced by a copy of 146 the vSID bits. Another difference is that the motivation to offset 147 to a zero base index/vSID is different. 149 Except for the Segment List using (shorter) vSIDs, the format of the 150 SRH is unchanged. The length of the vSIDs is defined to be 128 bits 151 minus the length of the vSIDs prefix. It is variable but its length 152 does not need to be encoded in the SRH header. Indeed the vSIDs 153 length only needs to be known by the SR Segment Endpoint Node 154 processing it. As per section 4.3 of 155 [I-D.ietf-6man-segment-routing-header], the SR node identifies its 156 local SID by performing a longest-prefix-match lookup on the packet 157 IPv6 destination address. This identifies the SID and its 158 properties, such as the SR endpoint behavior but also the length of 159 the vSIDs. 161 3. SRv6 Variable Length SIDs 163 An SRv6 vSID deployment choose one length 'L' of vSIDs and an 164 associated SRv6 vSIDs prefix. 166 0 (bits) vSIDs 128 167 Length 169 +--------------------------------------------------------------+ 170 | SRv6 SID | 171 +--------------------------------------------------------------+ 173 +--------------------------------------------------------------+ 174 | SRv6 vSIDs prefix | vSID | 175 +--------------------------------------------------------------+ 177 Figure 1: SRv6 SID:= SRv6 vSIDs prefix + SRv6 vSID 179 An SRv6 vSID deployment may use multiple SRv6 vSIDs prefixes. Each 180 prefix may have its own vSIDs length. 182 As per section 3.1 of [I-D.ietf-spring-srv6-network-programming], an 183 SRv6 SID can be represented as 'B:N:FUNCT:ARG'. Where 'B' is the 184 SRv6 SID prefix, N is the identifier of the parent node N, FUNCT is 185 the function of the SID of length 128-S. 187 If SRv6 vSIDs are to identify global segments, the SRv6 vSIDs prefix 188 would typically be 'B' while the vSID would be 'N:FUNCT:ARG'. 190 If SRv6 vSIDs are to only identify local segments, there is no need 191 to globally route toward a node hence the 'N' may have a size of 192 zero. This may be interesting for a deployment using both 128-bits 193 SRv6 SIDs and very short SRv6 vSIDs. Such SRv6 vSIDs could be used 194 when a strictly routed path is needed and encoded as a list of 195 adjacency SIDs. Given that the number of local adjacency SIDs is 196 independent of the size of the SR domain, and typically below 255, 197 one could use 8-bits vSIDs which would allow encoding 16 vSIDs within 198 a single 128-bits SRv6 SID hence provides a very effective SRH 199 compression. 201 This documents mandates that the length of the vSIDs be a multiple of 202 8-bits, up to 128 bits included, in order to provide octet alignment 203 in the SRH Segment List. However this specifications is written to 204 work for any bit granularity from 1 to 128 bits. This allows for a 205 future document to define a new profile with a higher granularity 206 (e.g. 1 bit, 4 bits, 16 bits, or an integer fraction 128-bits) 207 depending on hardware capabilities and flexibility requirements. 209 3.1. Encoding vSIDs in the SRH 211 As per section 2 of [I-D.ietf-6man-segment-routing-header], the 212 Segment Routing Header (SRH) is defined as follows: 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Last Entry | Flags | Tag | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | | 222 | Segment List[0] (128 bits IPv6 address) | 223 | | 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 | | 228 ... 229 | | 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 | Segment List[n] (128 bits IPv6 address) | 234 | | 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 // // 238 // Optional Type Length Value objects (variable) // 239 // // 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 2: SRH with 128-bits SRv6 SID 244 When vSIDs are used, there are encoded in the Segment List of the 245 Segment Routing Header (SRH). 247 vSIDs are encoded back to back using their native length. There is 248 no padding between SIDs and there is no specific alignment of the 249 SID. 251 In a SRH, all vSIDs have the same vSIDs length 'L' and the same SRv6 252 vSIDs prefix. 254 If the Segment List[n] does not end on a octet boundary, then padding 255 bits MUST be added up to the next octet boundary. Those padding bits 256 MUST be set to 0 when sent and ignored on receipt. 258 TLVs starts on next octet boundary. 260 As defined in [I-D.ietf-6man-segment-routing-header], padding TLVs 261 are used to pad the SRH to a multiple of 8 octets. As vSIDs may be 262 of any size, not necessarily a multiple of 8 octets, the support of 263 padding TLVs are REQUIRED. 265 The fields 'Segments Left' and 'Last Entry" keep their meaning but 266 refers to vSIDs of length L. 268 The following diagram illustrates an example of SRH with vSIDs of 269 sixteen bits: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Last Entry | Flags | Tag | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Segment List[0] | Segment List[1] | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | ..... ..... | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Segment List[n] | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 // // 285 // Optional Type Length Value objects (variable) // 286 // // 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 3: SRH with SRv6 vSIDs with 16-bits vSIDs 291 3.2. SRv6 vSIDs Network Programming 293 This section defines the extension to SRv6 Network Programming using 294 the "End" Endpoint behavior but is applicable to all SID behaviors. 296 The processing takes as an argument the length L of the vSIDs. This 297 length L is a property of the vSID and is given as a result of the 298 lookup on the IPv6 destination address which identifies the SRv6 SID 299 and its properties. The properties include the Endpoint behavior and 300 the length L of the vSIDs. 302 When N receives a packet whose IPv6 DA is S and S is a local vSID of 303 length L, the lines S08 and S14 of the End processing which were, as 304 per section 4.1 of [I-D.ietf-spring-srv6-network-programming]: 306 S08. max_LE = (Hdr Ext Len / 2) - 1 308 [...] 309 S14. Update IPv6 DA with Segment List[Segments Left] 311 are replaced by the following: 313 S08. max_LE = (Hdr Ext Len * 64 / L) - 1 315 [...] 317 S14. Copy Segment List[Segments Left] from the SRH to the L lowest 318 order bits of the destination address of the IPv6 header. 320 Note: S14. Taking into consideration that the Segment List is a list 321 of vSIDs of length L bits 323 4. Benefits 325 SRv6 vSID is believed to have the following benefits: 327 o Aligned with SRv6: SR architecture, SRv6 Network Programming. 329 o Reduced SID hence reduced header length. 331 o Flexible SID length, to accommodate for various deployment models, 332 network sizes, SRv6 usages. 334 * A typical vSIDs length could be 32 bits. Compared to SR-MPLS 335 (which has a 20 bits SID) it is larger and more scalable. 336 Compared to SRv6 (which has a 128 bits SID) it's four times 337 more compact. 339 * Other SID length are possible: 16 bits would be 8 times more 340 compact than SRv6 SID and 2 times more compact the SR-MPLS shim 341 header and large enough for most deployments; 8 bits would be 342 16 (respectively 4) more compact than SRv6 SID (respectively 343 SR-MPLS shim header) and could fit some specific deployments 344 (e.g. local adjacency SID only). 346 o Using SRv6 header (SRH) with no additional fields. 348 o No requirement for additional IPv6 addressing space: a /64 per 349 router is more than enough. A /96 per router is the typical 350 requirement. 352 5. Illustrations 354 This section illustrates the usage of SRv6 vSIDs through two 355 examples. The first example uses global segments with a vSIDs 356 locator been globally routable. The second example uses local 357 segments only with a vSIDs locator commom to all SR end nodes hence 358 not been able to locate a specific SR end node. Global and local 359 segments are defined as per RFC 8402 [RFC8402] section 2. 361 5.1. Global vSIDs 363 In this example vSIDs are used for global SIDs and are used alone 364 without 128-bits SRv6 SIDs. 366 The SR domain has the following caracteristics: 368 o 1 000 SR endpoints nodes; 370 o network diameter is 10; 372 o vSIDs are chosen to be 32-bits long; 374 o each SRv6 node is allocated a /108 to allocate its vSIDs from. 375 This allows for 4 096 (2^^12) locators 1 million (2^^20) local 376 functions on each SR node; 378 o the SR domain and the SRv6 vSIDs prefix is allocated: 379 2001:DB8::/96; 381 o node N is allocated 2001:DB8:0:0:0:0:N/108; 383 Some metrics of this SR domain: 385 o An SR policy encoding a strictly routed path using only Adjacency 386 SIDs would need ten 32-bits vSIDs resulting in a total of 40 387 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 388 would require 160 octets; 390 o An SR policy using strictly routed path using four (node) SIDs 391 would need four 32-bits vSIDs resulting in a total of 16 octets in 392 the SRH. In contrast the use of 128-bits SRv6 SIDs would require 393 64 octets and the use of 20-bits SR-MPLS SID would require 16 394 octets; 396 o The IGP advertises 1 000 SRv6 locators to be installed in the IPv6 397 FIB of all IGP nodes (as per regular SRv6 and SR-MPLS); 399 o The IPv6 address space is one /108 per SR node for a total of one 400 /96 for the whole SR domain. 402 5.2. Local vSIDs 404 In this example vSIDs are used only for local SIDs, such as adjacency 405 SIDs. vSIDs are used in complement with 128-bits SRv6 SIDs. 407 The SR domain has the following caracteristics: 409 o 10 000 SR endpoints nodes; 411 o network diameter is 30; 413 o SRv6 SIDs: 415 * each SRv6 node is allocated a /64 to allocate its 128-bits SIDs 416 from; 418 * SRv6 prefix: 2001:DB8::/48 (i.e., 65535 /64, allowing for 419 growth or multiple SR routing algorithms); 421 * node N is allocated 2001:DB8:0:N/64; 423 o SRv6 vSIDs 425 * local vSIDs are chosen to be 8-bits in length. They are used 426 for adjacency SIDs hence allow for 255 Adjacency SIDs per node; 428 * SRv6 vSIDs prefix is allocated 2001:DB8:0:FFFF::/120; 430 Some metrics of this SR domain: 432 o An SR policy encoding a strictly routed path using only adjacency 433 SIDs would need thirty 8-bits vSIDs resulting in a total of 32 434 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 435 would require 480 octets and the use of 20-bits SR-MPLS SID would 436 require 120 octets; 438 o The IGP advertises 10 000 SRv6 locators to be installed in the 439 IPv6 FIB of all IGP nodes (as per regular SRv6 or SR-MPLS); 441 o The IPv6 address space is one /64 per SR node for a total of one 442 /48 for the whole SR domain. 444 6. Signaling vSIDs length 446 Control plane extensions are required to signal the length of the 447 vSIDs. 449 6.1. Signaling vSIDs length in IS-IS 451 SRv6 SIDs are advertised in IS-IS as per 452 [I-D.ietf-lsr-isis-srv6-extensions]. 454 This document defines a new sub-TLV called vSIDs Length' that MAY be 455 advertised in the locator entries of the SRv6 Locator TLV. The 456 format is the following: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type | Length | Flags | vSIDs Length | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 4: IS-IS vSIDs Length sub-TLV 466 Type: TBD1. 468 Length: 2. 470 Flags: 1 octet. No flags are currently defined. MUST be set to zero 471 when sent and ignored when received. 473 vSIDs Length: length of the vSIDs in bits. This applies for all SIDs 474 of this locator. 476 The SRv6 vSIDs prefix is not advertised but can be computed. The 477 SRv6 vSIDs prefix is the 'vSIDs Length' first bits of the Locator. 478 It's length is 128 - 'vSIDs Length'. 480 The vSIDs Length MUST be between 1 and 128. If this restriction is 481 not met, the Locator entry MUST be ignored. 483 When the vSIDs Length sub-TLV is not present, the vSIDs length is 484 defined to be 128 (regular SRv6 SID length). 486 Note: there are multiple choices to advertise the vSIDs Length. 487 E.g., as a Sub-Sub-TLV of SRv6 End SID, SRv6 End.X SID or SRv6 LAN 488 End.X SID TLVs; as a property of the SR node. Alternatively the size 489 of the vSIDs prefix can be advertised in the Locator Block length 'LB 490 length' of the SRv6 SID Structure Sub-Sub-TLV defined in 492 [I-D.ietf-lsr-isis-srv6-extensions] with the additional specification 493 of a new SRv6 vSIDs capability/flag. ( The finale encoding choice is 494 postponed to a future version of this document. 496 7. A node requiring a larger vSIDs length. 498 One SR Endpoint node may need a larger vSIDs space. This may 499 especially be the case when at the same time: 501 o the vSIDs Length is chosen to be small in order to optimize for 502 the size of the SRH header. Indeed, for topological/routing 503 instructions, the number of SIDs in the SRH may be high in some 504 use cases, up to the network diameter, calling for small vSIDs. 506 o one vSID is a service instruction and the number of service SIDs 507 may be high, requiring a SID longer than a vSIDs Length. 509 This section defines two solutions to increase the vSIDs length on a 510 node requiring a vSIDs space larger than other nodes. 512 7.1. Allocating a larger locator to a node. 514 In order to increase the vSIDs length on a node, a simple option is 515 to allocate multiple locators of a larger locator to this node, 516 within the SRv6 vSIDs prefix. As per 517 [I-D.ietf-spring-srv6-network-programming], a locator may be 518 represented as B:N where B is the SRv6 SID block (IPv6 subnet 519 allocated for SRv6 SIDs by the operator) and N is the identifier of 520 the parent node instantiating the SID. Following this format, 521 multiple node identifiers Ns may be allocated to a node. Allocating 522 'k' identifiers increase the vSIDs space of that node by 'k'. 524 7.2. Combining k vSIDs to identify a behavior. 526 When an SR Endpoint node needs more SIDs than allowed by the vSIDs 527 Length, it MAY combine two (resp. N) vSIDs of length L to 528 effectively benefit from a vSID of length 2*L (resp. N*L). This is 529 a local choice of this SR Endpoint. Nothing specific is required in 530 the SRH which only contains those 2 (resp. N) SIDs instead of a 531 single one. 533 Note that when two vSIDs are combined, the first vSID may be seen as 534 having the role of a "Context SID" identifying a context specific SID 535 space/table, with the second SID been looked up in this context 536 specific table. This is similar to the Context-Specific Label space 537 defined in the section 3 of RFC 5331 [RFC5331]. 539 This section defines the extension to SRv6 Network Programming 540 allowing for a SID behavior "End.DT6" to be encoded with 'k' vSID. 541 This is equally applicable to others SID behaviors. 543 The processing takes as an argument the vSIDs Length 'L', and the 544 number of vSIDs 'k'. 'L' and 'k' are a property of the vSID and are 545 given as a result of the lookup of the IPv6 destination address which 546 identifies the SRv6 SID and its properties. The properties include 547 the Endpoint behavior, the length L of the vSIDs and the number 'k' 548 of vSIDs used to encode this behavior in the SRH. 550 When N receives a packet destined to S and S is a local End.DT6 SID 551 encoded with 'k' vSIDs, N does the following processing: 553 When N receives a packet whose IPv6 DA is S and S is a local End.DT6 554 vSID of length L and encoded with 'k' vSIDs the line S02 of the 555 End.DT6 processing which was, as per section 4.6 of 556 [I-D.ietf-spring-srv6-network-programming]: 558 S02. If (Segments Left != 0) { 560 is replaced by the following: 562 S02. If (Segments Left != k - 1) { 564 When processing the Upper-layer header of a packet, the lines S04-S05 565 which were: 567 S04. Remove the outer IPv6 Header with all its extension headers 569 S05. Set the packet's associated FIB table to T 571 are replaced by the following: 573 S04a. Read the k-1 next vSIDs 575 S04b. Remove the outer IPv6 Header with all its extension headers 577 S05. Set the packet's associated FIB table to the one identified by 578 the concatenation of the k-1 next vSIDs 580 8. Inter Routing Domains 582 Some SRv6 traffic may need to cross multiple routing domains, such as 583 differents Autonomous Systems (ASes) or different routing areas. 584 Different routing domains may use different size and addressing 585 schema making it difficult to find an optimal vSIDs length for all 586 routing domains, and/or to find a common SRv6 vSIDs prefix. 588 This section defines an optional solution and SID behavior allowing 589 for a SRH to contain vSIDs of different length and different SRv6 590 vSIDs prefixes. 592 The solution requires a new SID behavior, called "Endpoint with 593 cross-connect to an array of layer-3 adjacencies and SRv6 vSIDs 594 Prefix Swap" (End.XvPS for short) allowing for this transition of 595 SRv6 vSIDs prefix and vSIDs length between two routing domains. 597 End.XvPS is a variant of End.X, performing both "End.X Layer-3 Cross- 598 Connect" and the translation of the SRv6 vSIDs prefix between the two 599 routing domains. 601 The processing takes as an argument the vSIDs length L1 in the first 602 domain, the vSIDs length L2 in the second domain, and the prefix P2 603 of the SRv6 vSIDs prefix in the second domain. Those three 604 parameters are a property of the (received) vSID and are given as a 605 result of the lookup on the IPv6 destination address which identifies 606 the SRv6 SID and its properties. 608 When N receives a packet whose IPv6 DA is S and S is a End.XvPS SID 609 behavior, with a local vSID length L1, a remote/next vSID length L2, 610 and a remote/next SRv6 vSIDs prefix P2, the line S14 of the End 611 processing which was, as per section 4.1 of 612 [I-D.ietf-spring-srv6-network-programming]: 614 S14. Update IPv6 DA with Segment List[Segments Left] 616 is replaced by the following: 618 S14. Copy Segment List[Segments Left] from the SRH to the L2 lowest 619 order bits of the destination address of the IPv6 header and copy the 620 SRv6 vSIDs prefix P2 to the 128-L2 highest order bits of the 621 destination address. 623 Note: the way the vSID parameters (vSIDs length L2, SRv6 vSIDs prefix 624 P2) of the next routing domain are known is out of scope of this 625 document. As examples, they could be learnt via configuration or 626 using a signaling protocol either with the peer domain of with a 627 central controler (e.g. PCE). 629 When End.XvPS SID behavior is used, the restriction on the SRH is 630 relaxed and becomes: in a SRH, in each routing domain, all vSID MUST 631 have the same vSID length 'L' and the same SRv6 vSID prefix.Between 632 routing domaines, separated with the End.XvPS behavior, vSID lengths 633 and SRv6 vSID prefixes may be different. 635 9. IANA Considerations 637 TBD. 639 10. Security Considerations 641 This document does not change the security considerations of SRv6. 642 Please refers to RFC 8402 [RFC8402], 643 [I-D.ietf-6man-segment-routing-header] and 644 [I-D.ietf-spring-srv6-network-programming] for existing security 645 consideration. 647 11. Acknowledgements 649 This document has been inspired by the work of the SPRING WG and in 650 particular the work done in 651 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] and 652 [I-D.li-spring-compressed-srv6-np]. The authors would like to 653 acknowledge the authors of these two documents. 655 The authors would like to thank Joel Halpern for his review and 656 comments. 658 12. Changes / Authors Notes 660 [RFC Editor: Please remove this section before publication] 662 00: Initial version. 664 01: Removal of the vSID Size TLV; addition of the IS-IS extension; 665 addition of the SR header length check in the pseudo code. 667 Addition of the IS-IS extension; 669 Addition of the SR header length check in the pseudo code. 671 02: Change of terminology (VLSID changed to vSID); 673 Swapping the two examples in section 'Illustrations'.; 675 Addition of two solutions to provide more vSID space to some nodes in 676 section 'Node requiring a larger vSID length'; 678 Addition of a solution for crossing routing domains using differents 679 SRv6 vSID prefixes and/or different vSID length; 681 13. References 683 13.1. Normative References 685 [I-D.ietf-6man-segment-routing-header] 686 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 687 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 688 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 689 progress), October 2019. 691 [I-D.ietf-lsr-isis-srv6-extensions] 692 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 693 Z. Hu, "IS-IS Extension to Support Segment Routing over 694 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-04 695 (work in progress), January 2020. 697 [I-D.ietf-spring-srv6-network-programming] 698 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 699 Matsushima, S., and Z. Li, "SRv6 Network Programming", 700 draft-ietf-spring-srv6-network-programming-08 (work in 701 progress), January 2020. 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, 705 DOI 10.17487/RFC2119, March 1997, 706 . 708 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 709 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 710 May 2017, . 712 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 713 Decraene, B., Litkowski, S., and R. Shakir, "Segment 714 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 715 July 2018, . 717 13.2. Informative References 719 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 720 Filsfils, C., Camarillo, P., Cai, D., Jiang, Z., Voyer, 721 D., Shawky, A., Leymann, N., Steinberg, D., Zandi, S., 722 Dawra, G., Meilik, I., Uttaro, J., Jalil, L., So, N., 723 Fiumano, M., and M. Khaddam, "Network Programming 724 extension: SRv6 uSID instruction", draft-filsfils-spring- 725 net-pgm-extension-srv6-usid-02 (work in progress), August 726 2019. 728 [I-D.li-spring-compressed-srv6-np] 729 Li, Z., Li, C., Xie, C., Voyer, D., LEE, K., Tian, H., 730 Zhao, F., Guichard, J., Cong, L., and S. Peng, "Compressed 731 SRv6 Network Programming", draft-li-spring-compressed- 732 srv6-np-01 (work in progress), January 2020. 734 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 735 Label Assignment and Context-Specific Label Space", 736 RFC 5331, DOI 10.17487/RFC5331, August 2008, 737 . 739 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 740 Decraene, B., Litkowski, S., and R. Shakir, "Segment 741 Routing with the MPLS Data Plane", RFC 8660, 742 DOI 10.17487/RFC8660, December 2019, 743 . 745 Authors' Addresses 747 Bruno Decraene 748 Orange 750 Email: bruno.decraene@orange.com 752 Robert Raszuk 753 Bloomberg 755 Email: robert@raszuk.net