idnits 2.17.1 draft-decraene-spring-srv6-vlsid-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 : ---------------------------------------------------------------------------- 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 (March 9, 2020) is 1509 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 283 -- Looks like a reference, but probably isn't: '1' on line 283 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-06 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-10 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-03 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: September 10, 2020 Bloomberg 6 Z. Li 7 C. Li 8 Huawei Technologies 9 March 9, 2020 11 SRv6 vSID: Network Programming extension for variable length SIDs 12 draft-decraene-spring-srv6-vlsid-03 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 September 10, 2020. 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. A node requiring a larger vSIDs length. . . . . . . . . . . . 12 71 7.1. Allocating a larger locator to a node. . . . . . . . . . 12 72 7.2. Combining k vSIDs to identify a behavior. . . . . . . . . 12 73 8. Inter Routing Domains . . . . . . . . . . . . . . . . . . . . 13 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 77 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 78 13. Changes / Authors Notes . . . . . . . . . . . . . . . . . . . 15 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 14.2. Informative References . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 The Segment Routing (SR) architecture is defined RFC 8402 [RFC8402]. 88 IPv6 Segment Routing Header (SRH) is defined 89 [I-D.ietf-6man-segment-routing-header]. 91 SRv6 Network Programming is defined 92 [I-D.ietf-spring-srv6-network-programming]. 94 The reader is expected to be familiar with the three above documents 95 which define Segment Routing over the IPv6 data-plane (SRv6). 97 SRv6 is flexible and powerful, but in some uses cases, when a large 98 number of SIDs are required, the size of the SRH/SID may be seen as 99 too large both for some dataplane processors and traffic overhead. 101 The goal of this document is to propose a solution which reduces the 102 size of the SRv6 header when a high number of SIDs is required with 103 minimal changes to the SRv6 architecture, signaling, SRH and data 104 plane processing. 106 This document extends SRH and SRv6 Network Programming to allow for 107 SIDs of variable length, from 1 up to 128 bits. In a way, this is a 108 generalization of SRv6 for any (v)SID length, where 128-bits SIDs is 109 a special case. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 117 appear in all capitals, as shown here. 119 2. Overview 121 In a nutshell, SRv6 variable length SIDs (SRv6 vSIDs) proposes to: 123 o define one SRv6 SIDs prefix dedicated to SRv6 vSIDs and called 124 SRv6 vSIDs prefix; 126 o define the vSID as the SRv6 SID minus the vSIDs prefix: SRv6 SID:= 127 SRv6 vSIDs prefix + SRv6 vSID; 129 o encode, in the Segment List of the SRH, only the vSIDs. 131 In other words, 128-bits SRv6 SIDs are kept unchanged for signaling, 132 configuration and SR policies. In the data plane, this proposal 133 compresses the encoding of SRv6 SIDs in the SRH by not encoding the 134 SRv6 vSIDs prefixes which are redundant across vSIDs. 136 The use of the destination address in the IPv6 header is unchanged. 137 The IPv6 destination address still contains the current/next 128-bits 138 SRv6 SID. As a consequence, the IPv6 destination address already 139 indicates the SRv6 vSID prefix and there is no extend the SRH to 140 carry it. 142 In a way, this is similar to SR-MPLS RFC 8660 [RFC8660]: 144 o For SR-MPLS: SR-MPLS Label:= SRGB + Index 146 o For SRv6 vSID: SRv6 SID := SRv6 vSID prefix + SRv6 vSID 148 One difference compared to SR-MPLS is that lowest bits of the SRv6 149 vSID prefix are zero which allows for an easier operation in the data 150 plane. Indeed,the addition of the vSID may be replaced by a copy of 151 the vSID bits. Another difference is that the motivation to offset 152 to a zero base index/vSID is different. 154 Except for the Segment List using (shorter) vSIDs, the format of the 155 SRH is unchanged. The length of the vSIDs is defined to be 128 bits 156 minus the length of the vSIDs prefix. It is variable but its length 157 does not need to be encoded in the SRH header. Indeed the vSIDs 158 length only needs to be known by the SR Segment Endpoint Node 159 processing it. As per section 4.3 of 160 [I-D.ietf-6man-segment-routing-header], the SR node identifies its 161 local SID by performing a longest-prefix-match lookup on the packet 162 IPv6 destination address. This identifies the SID and its 163 properties, such as the SR endpoint behavior but also the length of 164 the vSIDs. 166 3. SRv6 Variable Length SIDs 168 An SRv6 vSID deployment choose one length 'L' of vSIDs and an 169 associated SRv6 vSIDs prefix. 171 0 (bits) vSIDs 128 172 Length 174 +--------------------------------------------------------------+ 175 | SRv6 SID | 176 +--------------------------------------------------------------+ 178 +--------------------------------------------------------------+ 179 | SRv6 vSIDs prefix | vSID | 180 +--------------------------------------------------------------+ 182 Figure 1: SRv6 SID:= SRv6 vSIDs prefix + SRv6 vSID 184 An SRv6 vSID deployment may use multiple SRv6 vSIDs prefixes. Each 185 prefix may have its own vSIDs length. 187 As per section 3.1 of [I-D.ietf-spring-srv6-network-programming], an 188 SRv6 SID can be represented as 'B:N:FUNCT:ARG'. Where 'B' is the 189 SRv6 SID prefix, N is the identifier of the parent node N, FUNCT is 190 the function of the SID of length 128-S. 192 If SRv6 vSIDs are to identify global segments, the SRv6 vSIDs prefix 193 would typically be 'B' while the vSID would be 'N:FUNCT:ARG'. 195 If SRv6 vSIDs are to only identify local segments, there is no need 196 to globally route toward a node hence the 'N' may have a size of 197 zero. This may be interesting for a deployment using both 128-bits 198 SRv6 SIDs and very short SRv6 vSIDs. Such SRv6 vSIDs could be used 199 when a strictly routed path is needed and encoded as a list of 200 adjacency SIDs. Given that the number of local adjacency SIDs is 201 independent of the size of the SR domain, and typically below 255, 202 one could use 8-bits vSIDs which would allow encoding 16 vSIDs within 203 a single 128-bits SRv6 SID hence provides a very effective SRH 204 compression. 206 This documents mandates that the length of the vSIDs be a multiple of 207 8-bits, up to 128 bits included, in order to provide octet alignment 208 in the SRH Segment List. However this specifications is written to 209 work for any bit granularity from 1 to 128 bits. This allows for a 210 future document to define a new profile with a higher granularity 211 (e.g. 1 bit, 4 bits, 16 bits, or an integer fraction 128-bits) 212 depending on hardware capabilities and flexibility requirements. 214 3.1. Encoding vSIDs in the SRH 216 As per section 2 of [I-D.ietf-6man-segment-routing-header], the 217 Segment Routing Header (SRH) is defined as follows: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Last Entry | Flags | Tag | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 | Segment List[0] (128 bits IPv6 address) | 228 | | 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 | | 233 ... 234 | | 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 | Segment List[n] (128 bits IPv6 address) | 239 | | 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 // // 243 // Optional Type Length Value objects (variable) // 244 // // 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 2: SRH with 128-bits SRv6 SID 249 When vSIDs are used, there are encoded in the Segment List of the 250 Segment Routing Header (SRH). 252 vSIDs are encoded back to back using their native length. There is 253 no padding between SIDs and there is no specific alignment of the 254 SID. 256 In a SRH, all vSIDs have the same vSIDs length 'L' and the same SRv6 257 vSIDs prefix. 259 If the Segment List[n] does not end on a octet boundary, then padding 260 bits MUST be added up to the next octet boundary. Those padding bits 261 MUST be set to 0 when sent and ignored on receipt. 263 TLVs starts on next octet boundary. 265 As defined in [I-D.ietf-6man-segment-routing-header], padding TLVs 266 are used to pad the SRH to a multiple of 8 octets. As vSIDs may be 267 of any size, not necessarily a multiple of 8 octets, the support of 268 padding TLVs are REQUIRED. 270 The fields 'Segments Left' and 'Last Entry" keep their meaning but 271 refers to vSIDs of length L. 273 The following diagram illustrates an example of SRH with vSIDs of 274 sixteen bits: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Last Entry | Flags | Tag | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Segment List[0] | Segment List[1] | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | ..... ..... | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Segment List[n] | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 // // 290 // Optional Type Length Value objects (variable) // 291 // // 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 3: SRH with SRv6 vSIDs with 16-bits vSIDs 296 3.2. SRv6 vSIDs Network Programming 298 This section defines the extension to SRv6 Network Programming using 299 the "End" Endpoint behavior but is applicable to all SID behaviors. 301 The processing takes as an argument the length L of the vSIDs. This 302 length L is a property of the vSID and is given as a result of the 303 lookup on the IPv6 destination address which identifies the SRv6 SID 304 and its properties. The properties include the Endpoint behavior and 305 the length L of the vSIDs. 307 When N receives a packet whose IPv6 DA is S and S is a local vSID of 308 length L, the lines S08 and S14 of the End processing which were, as 309 per section 4.1 of [I-D.ietf-spring-srv6-network-programming]: 311 S08. max_LE = (Hdr Ext Len / 2) - 1 313 [...] 314 S14. Update IPv6 DA with Segment List[Segments Left] 316 are replaced by the following: 318 S08. max_LE = (Hdr Ext Len * 64 / L) - 1 320 [...] 322 S14. Copy Segment List[Segments Left] from the SRH to the L lowest 323 order bits of the destination address of the IPv6 header. 325 Note: S14. Taking into consideration that the Segment List is a list 326 of vSIDs of length L bits 328 4. Benefits 330 SRv6 vSID is believed to have the following benefits: 332 o Aligned with SRv6: SR architecture, SRv6 Network Programming. 334 o Reduced SID hence reduced header length. 336 o Flexible SID length, to accommodate for various deployment models, 337 network sizes, SRv6 usages. 339 * A typical vSIDs length could be 32 bits. Compared to SR-MPLS 340 (which has a 20 bits SID) it is larger and more scalable. 341 Compared to SRv6 (which has a 128 bits SID) it's four times 342 more compact. 344 * Other SID length are possible: 16 bits would be 8 times more 345 compact than SRv6 SID and 2 times more compact the SR-MPLS shim 346 header and large enough for most deployments; 8 bits would be 347 16 (respectively 4) more compact than SRv6 SID (respectively 348 SR-MPLS shim header) and could fit some specific deployments 349 (e.g. local adjacency SID only). 351 o Using SRv6 header (SRH) with no additional fields. 353 o No requirement for additional IPv6 addressing space: a /64 per 354 router is more than enough. A /96 per router is the typical 355 requirement. 357 5. Illustrations 359 This section illustrates the usage of SRv6 vSIDs through two 360 examples. The first example uses global segments with a vSIDs 361 locator been globally routable. The second example uses local 362 segments only with a vSIDs locator commom to all SR end nodes hence 363 not been able to locate a specific SR end node. Global and local 364 segments are defined as per RFC 8402 [RFC8402] section 2. 366 5.1. Global vSIDs 368 In this example vSIDs are used for global SIDs and are used alone 369 without 128-bits SRv6 SIDs. 371 The SR domain has the following caracteristics: 373 o 1 000 SR endpoints nodes; 375 o network diameter is 10; 377 o vSIDs are chosen to be 32-bits long; 379 o each SRv6 node is allocated a /108 to allocate its vSIDs from. 380 This allows for 4 096 (2^^12) locators 1 million (2^^20) local 381 functions on each SR node; 383 o the SR domain and the SRv6 vSIDs prefix is allocated: 384 2001:DB8::/96; 386 o node N is allocated 2001:DB8:0:0:0:0:N/108; 388 Some metrics of this SR domain: 390 o An SR policy encoding a strictly routed path using only Adjacency 391 SIDs would need ten 32-bits vSIDs resulting in a total of 40 392 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 393 would require 160 octets; 395 o An SR policy using strictly routed path using four (node) SIDs 396 would need four 32-bits vSIDs resulting in a total of 16 octets in 397 the SRH. In contrast the use of 128-bits SRv6 SIDs would require 398 64 octets and the use of 20-bits SR-MPLS SID would require 16 399 octets; 401 o The IGP advertises 1 000 SRv6 locators to be installed in the IPv6 402 FIB of all IGP nodes (as per regular SRv6 and SR-MPLS); 404 o The IPv6 address space is one /108 per SR node for a total of one 405 /96 for the whole SR domain. 407 5.2. Local vSIDs 409 In this example vSIDs are used only for local SIDs, such as adjacency 410 SIDs. vSIDs are used in complement with 128-bits SRv6 SIDs. 412 The SR domain has the following caracteristics: 414 o 10 000 SR endpoints nodes; 416 o network diameter is 30; 418 o SRv6 SIDs: 420 * each SRv6 node is allocated a /64 to allocate its 128-bits SIDs 421 from; 423 * SRv6 prefix: 2001:DB8::/48 (i.e., 65535 /64, allowing for 424 growth or multiple SR routing algorithms); 426 * node N is allocated 2001:DB8:0:N/64; 428 o SRv6 vSIDs 430 * local vSIDs are chosen to be 8-bits in length. They are used 431 for adjacency SIDs hence allow for 255 Adjacency SIDs per node; 433 * SRv6 vSIDs prefix is allocated 2001:DB8:0:FFFF::/120; 435 Some metrics of this SR domain: 437 o An SR policy encoding a strictly routed path using only adjacency 438 SIDs would need thirty 8-bits vSIDs resulting in a total of 32 439 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 440 would require 480 octets and the use of 20-bits SR-MPLS SID would 441 require 120 octets; 443 o The IGP advertises 10 000 SRv6 locators to be installed in the 444 IPv6 FIB of all IGP nodes (as per regular SRv6 or SR-MPLS); 446 o The IPv6 address space is one /64 per SR node for a total of one 447 /48 for the whole SR domain. 449 6. Signaling vSIDs length 451 Control plane extensions are required to signal the length of the 452 vSIDs. 454 6.1. Signaling vSIDs length in IS-IS 456 SRv6 SIDs are advertised in IS-IS as per 457 [I-D.ietf-lsr-isis-srv6-extensions]. 459 This document defines a new sub-TLV called vSIDs Length' that MAY be 460 advertised in the locator entries of the SRv6 Locator TLV. The 461 format is the following: 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Type | Length | Flags | vSIDs Length | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Figure 4: IS-IS vSIDs Length sub-TLV 471 Type: TBD1. 473 Length: 2. 475 Flags: 1 octet. No flags are currently defined. MUST be set to zero 476 when sent and ignored when received. 478 vSIDs Length: length of the vSIDs in bits. This applies for all SIDs 479 of this locator. 481 The SRv6 vSIDs prefix is not advertised but can be computed. The 482 SRv6 vSIDs prefix is the 'vSIDs Length' first bits of the Locator. 483 It's length is 128 - 'vSIDs Length'. 485 The vSIDs Length MUST be between 1 and 128. If this restriction is 486 not met, the Locator entry MUST be ignored. 488 When the vSIDs Length sub-TLV is not present, the vSIDs length is 489 defined to be 128 (regular SRv6 SID length). 491 Note: there are multiple choices to advertise the vSIDs Length. 492 E.g., as a Sub-Sub-TLV of SRv6 End SID, SRv6 End.X SID or SRv6 LAN 493 End.X SID TLVs; as a property of the SR node. Alternatively the size 494 of the vSIDs prefix can be advertised in the Locator Block length 'LB 495 length' of the SRv6 SID Structure Sub-Sub-TLV defined in 497 [I-D.ietf-lsr-isis-srv6-extensions] with the additional specification 498 of a new SRv6 vSIDs capability/flag. ( The finale encoding choice is 499 postponed to a future version of this document. 501 7. A node requiring a larger vSIDs length. 503 One SR Endpoint node may need a larger vSIDs space. This may 504 especially be the case when at the same time: 506 o the vSIDs Length is chosen to be small in order to optimize for 507 the size of the SRH header. Indeed, for topological/routing 508 instructions, the number of SIDs in the SRH may be high in some 509 use cases, up to the network diameter, calling for small vSIDs. 511 o one vSID is a service instruction and the number of service SIDs 512 may be high, requiring a SID longer than a vSIDs Length. 514 This section defines two solutions to increase the vSIDs length on a 515 node requiring a vSIDs space larger than other nodes. 517 7.1. Allocating a larger locator to a node. 519 In order to increase the vSIDs length on a node, a simple option is 520 to allocate multiple locators of a larger locator to this node, 521 within the SRv6 vSIDs prefix. As per 522 [I-D.ietf-spring-srv6-network-programming], a locator may be 523 represented as B:N where B is the SRv6 SID block (IPv6 subnet 524 allocated for SRv6 SIDs by the operator) and N is the identifier of 525 the parent node instantiating the SID. Following this format, 526 multiple node identifiers Ns may be allocated to a node. Allocating 527 'k' identifiers increase the vSIDs space of that node by 'k'. 529 7.2. Combining k vSIDs to identify a behavior. 531 When an SR Endpoint node needs more SIDs than allowed by the vSIDs 532 Length, it MAY combine two (resp. N) vSIDs of length L to 533 effectively benefit from a vSID of length 2*L (resp. N*L). This is 534 a local choice of this SR Endpoint. Nothing specific is required in 535 the SRH which only contains those 2 (resp. N) SIDs instead of a 536 single one. 538 Note that when two vSIDs are combined, the first vSID may be seen as 539 having the role of a "Context SID" identifying a context specific SID 540 space/table, with the second SID been looked up in this context 541 specific table. This is similar to the Context-Specific Label space 542 defined in the section 3 of RFC 5331 [RFC5331]. 544 This section defines the extension to SRv6 Network Programming 545 allowing for a SID behavior "End.DT6" to be encoded with 'k' vSID. 546 This is equally applicable to others SID behaviors. 548 The processing takes as an argument the vSIDs Length 'L', and the 549 number of vSIDs 'k'. 'L' and 'k' are a property of the vSID and are 550 given as a result of the lookup of the IPv6 destination address which 551 identifies the SRv6 SID and its properties. The properties include 552 the Endpoint behavior, the length L of the vSIDs and the number 'k' 553 of vSIDs used to encode this behavior in the SRH. 555 When N receives a packet destined to S and S is a local End.DT6 SID 556 encoded with 'k' vSIDs, N does the following processing: 558 When N receives a packet whose IPv6 DA is S and S is a local End.DT6 559 vSID of length L and encoded with 'k' vSIDs the line S02 of the 560 End.DT6 processing which was, as per section 4.6 of 561 [I-D.ietf-spring-srv6-network-programming]: 563 S02. If (Segments Left != 0) { 565 is replaced by the following: 567 S02. If (Segments Left != k - 1) { 569 When processing the Upper-layer header of a packet, the lines S04-S05 570 which were: 572 S04. Remove the outer IPv6 Header with all its extension headers 574 S05. Set the packet's associated FIB table to T 576 are replaced by the following: 578 S04a. Read the k-1 next vSIDs 580 S04b. Remove the outer IPv6 Header with all its extension headers 582 S05. Set the packet's associated FIB table to the one identified by 583 the concatenation of the k-1 next vSIDs 585 8. Inter Routing Domains 587 Some SRv6 traffic may need to cross multiple routing domains, such as 588 differents Autonomous Systems (ASes) or different routing areas. 589 Different routing domains may use different addressing schema making 590 it difficult to find a common SRv6 vSIDs prefix. 592 This section defines an optional solution and SID behavior allowing 593 for the use of different SRv6 vSIDs prefixes between routing domains. 595 The solution requires a new SID behavior, called "Endpoint with 596 cross-connect to an array of layer-3 adjacencies and SRv6 vSIDs 597 Prefix Swap" (End.XvPS for short) allowing for this transition of 598 SRv6 vSIDs prefix between two routing domains. 600 End.XvPS is a variant of End.X, performing both "End.X Layer-3 Cross- 601 Connect" and the translation of the SRv6 vSIDs prefix between the two 602 routing domains. 604 The processing takes as an argument the vSIDs length L and the prefix 605 P2 of the SRv6 vSIDs prefix in the second domain. Those two 606 parameters are a property of the (received) vSID and are given as a 607 result of the lookup on the IPv6 destination address which identifies 608 the SRv6 SID and its properties. 610 When N receives a packet whose IPv6 DA is S and S is a End.XvPS SID 611 behavior, with a local vSID length L, and a remote/next SRv6 vSIDs 612 prefix P2, the line S14 of the End processing which was, as per 613 section 4.1 of [I-D.ietf-spring-srv6-network-programming]: 615 S14. Update IPv6 DA with Segment List[Segments Left] 617 is replaced by the following: 619 S14. Copy Segment List[Segments Left] from the SRH to the L lowest 620 order bits of the destination address of the IPv6 header and copy the 621 SRv6 vSIDs prefix P2 to the 128-L highest order bits of the 622 destination address. 624 Note: the way the SRv6 vSIDs prefix P2 of the next routing domain is 625 known is out of scope of this document. As examples, they could be 626 learnt via configuration or using a signaling protocol either with 627 the peer domain of with a 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, all vSID MUST have the same vSID 631 length 'L' and within a routing domain, the same SRv6 vSID 632 prefix.Between routing domaines, separated with the End.XvPS 633 behavior, 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 and Francois Clad for 656 their review and comments. 658 12. Contributors 660 Daniel Voyer 662 Bell Canada 664 Canada 666 Email: daniel.voyer@bell.ca 668 13. Changes / Authors Notes 670 [RFC Editor: Please remove this section before publication] 672 00: Initial version. 674 01: 676 o Removal of the vSID Size TLV; addition of the IS-IS extension; 677 addition of the SR header length check in the pseudo code. 679 o Addition of the IS-IS extension; 681 o Addition of the SR header length check in the pseudo code. 683 02: 685 o Change of terminology (VLSID changed to vSID); 686 o Swapping the two examples in section 'Illustrations'.; 688 o Addition of two solutions to provide more vSID space to some nodes 689 in section 'Node requiring a larger vSID length'; 691 o Addition of a solution for crossing routing domains using 692 differents SRv6 vSID prefixes and/or different vSID length; 694 14. References 696 14.1. Normative References 698 [I-D.ietf-6man-segment-routing-header] 699 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 700 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 701 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 702 progress), October 2019. 704 [I-D.ietf-lsr-isis-srv6-extensions] 705 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 706 Z. Hu, "IS-IS Extension to Support Segment Routing over 707 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-06 708 (work in progress), March 2020. 710 [I-D.ietf-spring-srv6-network-programming] 711 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 712 Matsushima, S., and Z. Li, "SRv6 Network Programming", 713 draft-ietf-spring-srv6-network-programming-10 (work in 714 progress), February 2020. 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, 718 DOI 10.17487/RFC2119, March 1997, 719 . 721 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 722 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 723 May 2017, . 725 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 726 Decraene, B., Litkowski, S., and R. Shakir, "Segment 727 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 728 July 2018, . 730 14.2. Informative References 732 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 733 Filsfils, C., Camarillo, P., Cai, D., Voyer, D., Meilik, 734 I., Patel, K., Henderickx, W., Jonnalagadda, P., and D. 735 Melman, "Network Programming extension: SRv6 uSID 736 instruction", draft-filsfils-spring-net-pgm-extension- 737 srv6-usid-03 (work in progress), February 2020. 739 [I-D.li-spring-compressed-srv6-np] 740 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 741 Guichard, J., Cong, L., and S. Peng, "Compressed SRv6 742 Network Programming", draft-li-spring-compressed- 743 srv6-np-02 (work in progress), February 2020. 745 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 746 Label Assignment and Context-Specific Label Space", 747 RFC 5331, DOI 10.17487/RFC5331, August 2008, 748 . 750 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 751 Decraene, B., Litkowski, S., and R. Shakir, "Segment 752 Routing with the MPLS Data Plane", RFC 8660, 753 DOI 10.17487/RFC8660, December 2019, 754 . 756 Authors' Addresses 758 Bruno Decraene 759 Orange 761 Email: bruno.decraene@orange.com 763 Robert Raszuk 764 Bloomberg 766 Email: robert@raszuk.net 768 Zhenbin Li 769 Huawei Technologies 771 Email: lizhenbin@huawei.com 772 Cheng Li 773 Huawei Technologies 775 Email: chengli13@huawei.com