idnits 2.17.1 draft-decraene-spring-srv6-vlsid-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (7 March 2022) is 753 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 269 -- Looks like a reference, but probably isn't: '1' on line 269 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-18 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-12 Summary: 1 error (**), 0 flaws (~~), 4 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: 8 September 2022 NTT Network Innovations 6 Z. Li 7 C. Li 8 Huawei Technologies 9 7 March 2022 11 SRv6 vSID: Network Programming extension for variable length SIDs 12 draft-decraene-spring-srv6-vlsid-07 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 8 September 2022. 41 Copyright Notice 43 Copyright (c) 2022 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 (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. SRv6 Variable Length SIDs . . . . . . . . . . . . . . . . . . 4 61 3.1. Encoding vSIDs in the SRH . . . . . . . . . . . . . . . . 5 62 3.2. SRv6 vSIDs Network Programming . . . . . . . . . . . . . 7 63 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Global vSIDs . . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. Local vSIDs . . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Optional extensions . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. A node requiring a larger vSIDs length. . . . . . . . . . 10 69 6.2. Inter Routing Domains with the End.XvPS behavior . . . . 12 70 6.3. NSIDs flavor . . . . . . . . . . . . . . . . . . . . . . 13 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 73 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 74 10. Changes / Authors Notes . . . . . . . . . . . . . . . . . . . 14 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 11.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 RFC 8754 [RFC8754]. 86 SRv6 Network Programming is defined RFC 8986 [RFC8986]. 88 The reader is expected to be familiar with the three above documents 89 which define Segment Routing over the IPv6 data-plane (SRv6). 91 SRv6 is flexible and powerful, but in some uses cases, when a large 92 number of SIDs are required, the size of the SRH/SID may be seen as 93 too large both for some dataplane processors and traffic overhead. 95 The goal of this document is to propose a solution which reduces the 96 size of the SRv6 header when a high number of SIDs is required with 97 minimal changes to the SRv6 architecture, signaling, SRH and data 98 plane processing. 100 This document extends SRH and SRv6 Network Programming to allow for 101 SIDs of variable length, from 1 up to 128 bits. In a way, this is a 102 generalization of SRv6 for any (v)SID length, where 128-bits SIDs is 103 a special case. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 111 appear in all capitals, as shown here. 113 2. Overview 115 In a nutshell, SRv6 variable length SIDs (SRv6 vSIDs) proposes to: 117 * define one SRv6 SIDs prefix dedicated to SRv6 vSIDs and called 118 SRv6 vSIDs prefix; 120 * define the vSID as the SRv6 SID minus the vSIDs prefix: SRv6 SID:= 121 SRv6 vSIDs prefix + SRv6 vSID; 123 * encode, in the Segment List of the SRH, only the vSIDs. 125 In other words, 128-bits SRv6 SIDs are kept unchanged for signaling, 126 configuration and SR policies. In the data plane, this proposal 127 compresses the encoding of SRv6 SIDs in the SRH by not encoding the 128 SRv6 vSIDs prefixes which are redundant across vSIDs. 130 The use of the destination address in the IPv6 header is unchanged. 131 The IPv6 destination address still contains the current/next 128-bits 132 SRv6 SID. As a consequence, the IPv6 destination address already 133 indicates the SRv6 vSID prefix and there is no extend the SRH to 134 carry it. 136 In a way, this is similar to SR-MPLS RFC 8660 [RFC8660]: 138 * For SR-MPLS: SR-MPLS Label:= SRGB + Index 140 * For SRv6 vSID: SRv6 SID := SRv6 vSID prefix + SRv6 vSID 141 One difference compared to SR-MPLS is that lowest bits of the SRv6 142 vSID prefix are zero which allows for an easier operation in the data 143 plane. Indeed,the addition of the vSID may be replaced by a copy of 144 the vSID bits. Another difference is that the motivation to offset 145 to a zero base index/vSID is different. 147 Except for the Segment List using (shorter) vSIDs, the format of the 148 SRH is unchanged. The length of the vSIDs is defined to be 128 bits 149 minus the length of the vSIDs prefix. It is variable but its length 150 does not need to be encoded in the SRH header. Indeed the vSIDs 151 length only needs to be known by the SR Segment Endpoint Node 152 processing it. As per section 4.3 of RFC 8754 [RFC8754], the SR node 153 identifies its local SID by performing a longest-prefix-match lookup 154 on the packet IPv6 destination address. This identifies the SID and 155 its properties, such as the SR endpoint behavior but also the length 156 of the vSIDs. 158 3. SRv6 Variable Length SIDs 160 An SRv6 vSID deployment choose one length 'L' of vSIDs and an 161 associated SRv6 vSIDs prefix. 163 0 (bits) vSIDs 128 164 Length 166 +--------------------------------------------------------------+ 167 | SRv6 SID | 168 +--------------------------------------------------------------+ 170 +--------------------------------------------------------------+ 171 | SRv6 vSIDs prefix | vSID | 172 +--------------------------------------------------------------+ 174 Figure 1: SRv6 SID:= SRv6 vSIDs prefix + SRv6 vSID 176 An SRv6 vSID deployment may use multiple SRv6 vSIDs prefixes. Each 177 prefix may have its own vSIDs length. 179 As per section 3.1 of RFC 8986 [RFC8986], an SRv6 SID can be 180 represented as 'B:N:FUNCT:ARG'. Where 'B' is the SRv6 SID prefix, N 181 is the identifier of the parent node N, FUNCT is the function of the 182 SID of length 128-S. 184 For SRv6 vSIDs, the SRv6 prefix is 'B' of length LB as advertised in 185 the SRv6 SID Structure Sub-Sub-TLV defined in 186 [I-D.ietf-lsr-isis-srv6-extensions]. The vSID length for vSIDs of 187 this block is computed as 128 - LB. The vSID includes 'N:FUNCT:ARG'. 189 In order to simplify implementations, the length of the vSIDs MUST be 190 a multiple of 8-bits, up to 128 bits included, in order to provide 191 octet alignment in the SRH Segment List. However this specifications 192 is written to work for any bit granularity from 1 to 128 bits. This 193 allows for a future document to define a new profile with a higher 194 granularity (e.g. 1 bit, 4 bits, 16 bits, or an integer fraction 195 128-bits) depending on hardware capabilities and flexibility 196 requirements. To allow some implementations to be further 197 simplified, a specific profile 'Profile-32' is created restricting 198 the vSID length to be 32-bits. 200 3.1. Encoding vSIDs in the SRH 202 As per section 2 of RFC 8754 [RFC8754], the Segment Routing Header 203 (SRH) is defined as follows: 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Last Entry | Flags | Tag | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | | 213 | Segment List[0] (128 bits IPv6 address) | 214 | | 215 | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | | 218 | | 219 ... 220 | | 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | 224 | Segment List[n] (128 bits IPv6 address) | 225 | | 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 // // 229 // Optional Type Length Value objects (variable) // 230 // // 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 2: SRH with 128-bits SRv6 SID 235 When vSIDs are used, there are encoded in the Segment List of the 236 Segment Routing Header (SRH). 238 vSIDs are encoded back to back using their native length. There is 239 no padding between SIDs and there is no specific alignment of the 240 SID. 242 In a SRH, all vSIDs MUST have the same vSIDs length 'L' and the same 243 SRv6 vSIDs prefix. 245 If the Segment List[n] does not end on a octet boundary, then padding 246 bits MUST be added up to the next octet boundary. Those padding bits 247 MUST be set to 0 when sent and ignored on receipt. 249 TLVs starts on next octet boundary. 251 As defined in RFC 8754 [RFC8754], padding TLVs are used to pad the 252 SRH to a multiple of 8 octets. As vSIDs may be of any size, not 253 necessarily a multiple of 8 octets, the support of padding TLVs are 254 REQUIRED. 256 The fields 'Segments Left' and 'Last Entry" keep their meaning but 257 refers to vSIDs of length L. 259 The following diagram illustrates an example of SRH with vSIDs of 260 sixteen bits: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Last Entry | Flags | Tag | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Segment List[0] | Segment List[1] | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | ..... ..... | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Segment List[n] | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 // // 276 // Optional Type Length Value objects (variable) // 277 // // 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 3: SRH with SRv6 vSIDs with 16-bits vSIDs 282 3.2. SRv6 vSIDs Network Programming 284 This section defines a flavor for Endpoint behaviors. It defined 285 below using the "End" Endpoint behavior but is applicable to all SID 286 behaviors. 288 The processing takes as an argument the length L of the vSIDs. This 289 length L is a property of the vSID and is given as a result of the 290 lookup on the IPv6 destination address which identifies the SRv6 SID 291 and its properties. The properties include the Endpoint behavior and 292 the length L of the vSIDs. 294 When N receives a packet whose IPv6 DA is S and S is a local vSID of 295 length L, the lines S08 and S14 of the End processing which were, as 296 per section 4.1 of RFC 8986 [RFC8986]: 298 S08. max_LE = (Hdr Ext Len / 2) - 1 300 [...] 302 S14. Update IPv6 DA with Segment List[Segments Left] 304 are replaced by the following: 306 S08. max_LE = (Hdr Ext Len * 64 / L) - 1 308 [...] 310 S14. Copy Segment List[Segments Left] from the SRH to the L lowest 311 order bits of the destination address of the IPv6 header. 313 Note: S14. Taking into consideration that the Segment List is a list 314 of vSIDs of length L bits 316 4. Benefits 318 SRv6 vSID is believed to have the following benefits: 320 * Aligned with SRv6: SR architecture, SRv6 Network Programming. 322 * Reduced SID hence reduced header length. 324 * Flexible SID length, to accommodate for various deployment models, 325 network sizes, SRv6 usages. 327 - A typical vSIDs length could be 32 bits. Compared to SR-MPLS 328 (which has a 20 bits SID) it is larger and more scalable. 329 Compared to SRv6 (which has a 128 bits SID) it's four times 330 more compact. 332 - Other SID length are possible: 16 bits would be 8 times more 333 compact than SRv6 SID and 2 times more compact the SR-MPLS shim 334 header and large enough for most deployments; 8 bits would be 335 16 (respectively 4) more compact than SRv6 SID (respectively 336 SR-MPLS shim header) and could fit some specific deployments 337 (e.g. local adjacency SID only). 339 * Using SRv6 header (SRH) with no additional fields. 341 * No requirement for additional IPv6 addressing space: a /64 per 342 router is more than enough. A /96 per router is the typical 343 requirement. 345 5. Illustrations 347 This section illustrates the usage of SRv6 vSIDs through two 348 examples. The first example uses global segments with a vSIDs 349 locator been globally routable. The second example uses local 350 segments only with a vSIDs locator commom to all SR end nodes hence 351 not been able to locate a specific SR end node. Global and local 352 segments are defined as per RFC 8402 [RFC8402] section 2. 354 5.1. Global vSIDs 356 In this example vSIDs are used for global SIDs and are used alone 357 without 128-bits SRv6 SIDs. 359 The SR domain has the following characteristics: 361 * 1 000 SR endpoints nodes; 363 * network diameter is 10; 365 * vSIDs are chosen to be 32-bits long; 367 * each SRv6 node is allocated a /108 to allocate its vSIDs from. 368 This allows for 4 096 (2^^12) locators 1 million (2^^20) local 369 functions on each SR node; 371 * the SR domain and the SRv6 vSIDs prefix is allocated: 372 2001:DB8::/96; 374 * node N is allocated 2001:DB8:0:0:0:0:N/108; 375 Some metrics of this SR domain: 377 * An SR policy encoding a strictly routed path using only Adjacency 378 SIDs would need ten 32-bits vSIDs resulting in a total of 40 379 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 380 would require 160 octets; 382 * An SR policy using strictly routed path using four (node) SIDs 383 would need four 32-bits vSIDs resulting in a total of 16 octets in 384 the SRH. In contrast the use of 128-bits SRv6 SIDs would require 385 64 octets and the use of 20-bits SR-MPLS SID would require 16 386 octets; 388 * The IGP advertises 1 000 SRv6 locators to be installed in the IPv6 389 FIB of all IGP nodes (as per regular SRv6 and SR-MPLS); 391 * The IPv6 address space is one /108 per SR node for a total of one 392 /96 for the whole SR domain. 394 5.2. Local vSIDs 396 If SRv6 vSIDs only identifies local segments, with no needs for 397 global segments, there is no need for a global route toward a node 398 hence the 'N' may have a size of zero. This may be interesting for a 399 deployment using both 128-bits SRv6 SIDs and very short SRv6 vSIDs. 400 Such SRv6 vSIDs could be used when a strictly routed path is needed 401 and encoded as a list of adjacency SIDs. Given that the number of 402 local adjacency SIDs is independent of the size of the SR domain, and 403 typically below 255, one could use 8-bits vSIDs which would allow 404 encoding 16 vSIDs within a single 128-bits SRv6 SID hence provides a 405 very effective SRH compression. 407 In this example vSIDs are used only for local SIDs, such as adjacency 408 SIDs. vSIDs are used in complement with 128-bits SRv6 SIDs. 410 The SR domain has the following caracteristics: 412 * 10 000 SR endpoints nodes; 414 * network diameter is 30; 416 * SRv6 SIDs: 418 - each SRv6 node is allocated a /64 to allocate its 128-bits SIDs 419 from; 421 - SRv6 prefix: 2001:DB8::/48 (i.e., 65535 /64, allowing for 422 growth or multiple SR routing algorithms); 424 - node N is allocated 2001:DB8:0:N/64; 426 * SRv6 vSIDs 428 - local vSIDs are chosen to be 8-bits in length. They are used 429 for adjacency SIDs hence allow for 255 Adjacency SIDs per node; 431 - SRv6 vSIDs prefix is allocated 2001:DB8:0:FFFF::/120; 433 Some metrics of this SR domain: 435 * An SR policy encoding a strictly routed path using only adjacency 436 SIDs would need thirty 8-bits vSIDs resulting in a total of 32 437 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 438 would require 480 octets and the use of 20-bits SR-MPLS SID would 439 require 120 octets; 441 * The IGP advertises 10 000 SRv6 locators to be installed in the 442 IPv6 FIB of all IGP nodes (as per regular SRv6 or SR-MPLS); 444 * The IPv6 address space is one /64 per SR node for a total of one 445 /48 for the whole SR domain. 447 6. Optional extensions 449 6.1. A node requiring a larger vSIDs length. 451 One SR Endpoint node may need a larger vSIDs space. This may 452 especially be the case when at the same time: 454 * the vSIDs Length is chosen to be small in order to optimize for 455 the size of the SRH header. Indeed, for topological/routing 456 instructions, the number of SIDs in the SRH may be high in some 457 use cases, up to the network diameter, calling for small vSIDs. 459 * one vSID is a service instruction and the number of service SIDs 460 may be high, requiring a SID longer than a vSIDs Length. 462 This section defines two solutions to increase the vSIDs length on a 463 node requiring a vSIDs space larger than other nodes. 465 6.1.1. Allocating a shorter locator to a node. 467 In order to increase the vSIDs length on a node, a simple option is 468 to allocate multiple locators of a larger locator to this node, 469 within the SRv6 vSIDs prefix. As per RFC 8986 [RFC8986], a locator 470 may be represented as B:N where B is the SRv6 SID block (IPv6 subnet 471 allocated for SRv6 SIDs by the operator) and N is the identifier of 472 the parent node instantiating the SID. Following this format, 473 multiple node identifiers Ns may be allocated to a node. Allocating 474 'k' identifiers increase the vSIDs space of that node by 'k'. 476 6.1.2. Combining k vSIDs to identify a behavior. 478 When an SR Endpoint node needs more SIDs than allowed by the vSIDs 479 Length, it MAY combine two (resp. N) vSIDs of length L to 480 effectively benefit from a vSID of length 2*L (resp. N*L). This is 481 a local choice of this SR Endpoint. Nothing specific is required in 482 the SRH which only contains those 2 (resp. N) SIDs instead of a 483 single one. 485 Note that when two vSIDs are combined, the first vSID may be seen as 486 having the role of a "Context SID" identifying a context specific SID 487 space/table, with the second SID been looked up in this context 488 specific table. This is similar to the Context-Specific Label space 489 defined in the section 3 of RFC 5331 [RFC5331]. 491 This section defines the extension to SRv6 Network Programming 492 allowing for a SID behavior "End.DT6" to be encoded with 'k' vSID. 493 This is equally applicable to others SID behaviors. 495 The processing takes as an argument the vSIDs length 'L', and the 496 number of vSIDs 'k'. 'L' and 'k' are a property of the vSID and are 497 given as a result of the lookup of the IPv6 destination address which 498 identifies the SRv6 SID and its properties. The properties include 499 the Endpoint behavior, the length L of the vSIDs and the number 'k' 500 of vSIDs used to encode this behavior in the SRH. 502 When N receives a packet destined to S and S is a local End.DT6 SID 503 encoded with 'k' vSIDs, N does the following processing: 505 When N receives a packet whose IPv6 DA is S and S is a local End.DT6 506 vSID of length L and encoded with 'k' vSIDs the line S02 of the 507 End.DT6 processing which was, as per section 4.6 of RFC 8986 508 [RFC8986]: 510 S02. If (Segments Left != 0) { 512 is replaced by the following: 514 S02. If (Segments Left != k - 1) { 516 When processing the Upper-layer header of a packet, the lines S04-S05 517 which were: 519 S04. Remove the outer IPv6 Header with all its extension headers 521 S05. Set the packet's associated FIB table to T 523 are replaced by the following: 525 S04a. Read the k-1 next vSIDs 527 S04b. Remove the outer IPv6 Header with all its extension headers 529 S05. Set the packet's associated FIB table to the one identified by 530 the concatenation of the k-1 next vSIDs 532 6.2. Inter Routing Domains with the End.XvPS behavior 534 Some SRv6 traffic may need to cross multiple routing domains, such as 535 differents Autonomous Systems (ASes) or different routing areas. 536 Different routing domains may use different addressing schema making 537 it difficult to find a common SRv6 vSIDs prefix. 539 This section defines an optional solution and SID behavior allowing 540 for the use of different SRv6 vSIDs prefixes between routing domains. 542 The solution requires a new SID behavior, called "Endpoint with 543 cross-connect to an array of layer-3 adjacencies and SRv6 vSIDs 544 Prefix Swap" (End.XvPS for short) allowing for this transition of 545 SRv6 vSIDs prefix between two routing domains. 547 End.XvPS is a variant of End.X, performing both "End.X Layer-3 Cross- 548 Connect" and the translation of the SRv6 vSIDs prefix between the two 549 routing domains. 551 The processing takes as an argument the vSIDs length L and the prefix 552 P2 of the SRv6 vSIDs prefix in the second domain. Those two 553 parameters are a property of the (received) vSID and are given as a 554 result of the lookup on the IPv6 destination address which identifies 555 the SRv6 SID and its properties. 557 When N receives a packet whose IPv6 DA is S and S is a End.XvPS SID 558 behavior, with a local vSID length L, and a remote/next SRv6 vSIDs 559 prefix P2, the line S14 of the End processing which was, as per 560 section 4.1 of RFC 8986 [RFC8986]: 562 S14. Update IPv6 DA with Segment List[Segments Left] 564 is replaced by the following: 566 S14. Copy Segment List[Segments Left] from the SRH to the L lowest 567 order bits of the destination address of the IPv6 header and copy the 568 SRv6 vSIDs prefix P2 to the 128-L highest order bits of the 569 destination address. 571 Note: the way the SRv6 vSIDs prefix P2 of the next routing domain is 572 known is out of scope of this document. As examples, they could be 573 learnt via configuration or using a signaling protocol either with 574 the peer domain of with a central controler (e.g. PCE). 576 When End.XvPS SID behavior is used, the restriction on the SRH is 577 relaxed and becomes: in a SRH, all vSID MUST have the same vSID 578 length 'L' and within a routing domain, the same SRv6 vSID 579 prefix.Between routing domaines, separated with the End.XvPS 580 behavior, SRv6 vSID prefixes may be different. 582 6.3. NSIDs flavor 584 The NSIDs flavors is a variant of the End, End.X and End.XvPS 585 behaviors. 587 The NSIDs flavors copy N vVSID from the SRH to the IPv6 destination 588 address. 590 When N receives a packet whose IPv6 DA is S and S is a NSIDs flavor, 591 with a local vSID length L, and a local paramater N, the lines S09, 592 S13 and S14 of the End processing which was, as per section 4.1 of 593 RFC 8986 [RFC8986]: 595 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 597 S13. Decrement Segments Left by 1 599 S14. Update IPv6 DA with Segment List[Segments Left] 601 are replaced by the following: 603 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) or 604 (Segments Left < = N){ 606 S13. Decrement Segments Left by N 607 S14. Copy N Segments List[Segments Left+N-1]...List[Segments Left] 608 from the SRH to the N*L lowest order bits of the destination address 609 of the IPv6 header. 611 Note that if N=128/L, a complete IPv6 address is copied. This is 612 useful when the next SR node is an SRv6 PE requiring its 128-bits 613 SIDs in the IPv6 destination address. This is also useful for inter 614 domain scenarios where both domains use unrelated address spaces and 615 hence use two different SRv6 vSIDs prefixes. 617 7. Security Considerations 619 This document does not change the security considerations of SRv6. 620 Please refers to RFC 8402 [RFC8402], RFC 8754 [RFC8754] and RFC 8986 621 [RFC8986] for existing security consideration. 623 8. Acknowledgements 625 This document has been inspired by the work of the SPRING WG and in 626 particular the work done in 627 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] and 628 [I-D.li-spring-compressed-srv6-np]. The authors would like to 629 acknowledge the authors of these two documents. 631 The authors would like to thank Joel Halpern and Francois Clad for 632 their review and comments. 634 9. Contributors 636 Daniel Voyer 638 Bell Canada 640 Canada 642 Email: daniel.voyer@bell.ca 644 10. Changes / Authors Notes 646 [RFC Editor: Please remove this section before publication] 648 00: Initial version. 650 01: 652 * Removal of the vSID Size TLV; addition of the IS-IS extension; 653 addition of the SR header length check in the pseudo code. 655 * Addition of the IS-IS extension; 657 * Addition of the SR header length check in the pseudo code. 659 02: 661 * Change of terminology (VLSID changed to vSID); 663 * Swapping the two examples in section 'Illustrations'.; 665 * Addition of two solutions to provide more vSID space to some nodes 666 in section 'Node requiring a larger vSID length'; 668 * Addition of a solution for crossing routing domains using 669 different SRv6 vSID prefixes and/or different vSID length; 671 03: 673 * Minor updates in section 'Inter Routing Domains' 675 04: 677 * Creating of a profile only supporting vSID of length 32-bits. 679 * Addition of the NSIDs flavor. 681 05: 683 * Editorial changes. 685 * Removal of the IGP signaling extension. The size of the SRv6 686 block is advertised in the existing SRv6 SID Structure Sub-Sub- 687 TLV. 689 06-07: refresh. 691 11. References 693 11.1. Normative References 695 [I-D.ietf-lsr-isis-srv6-extensions] 696 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 697 Z. Hu, "IS-IS Extensions to Support Segment Routing over 698 IPv6 Dataplane", Work in Progress, Internet-Draft, draft- 699 ietf-lsr-isis-srv6-extensions-18, 20 October 2021, 700 . 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 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 718 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 719 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 720 . 722 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 723 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 724 (SRv6) Network Programming", RFC 8986, 725 DOI 10.17487/RFC8986, February 2021, 726 . 728 11.2. Informative References 730 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 731 Filsfils, C., Garvia, P. C., Cai, D., Voyer, D., Meilik, 732 I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman, 733 D., Liu, Y., and J. Guichard, "Network Programming 734 extension: SRv6 uSID instruction", Work in Progress, 735 Internet-Draft, draft-filsfils-spring-net-pgm-extension- 736 srv6-usid-12, 13 December 2021, 737 . 740 [I-D.li-spring-compressed-srv6-np] 741 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 742 Guichard, J. N., Li, C., and S. Peng, "Compressed SRv6 743 Network Programming", Work in Progress, Internet-Draft, 744 draft-li-spring-compressed-srv6-np-02, 25 February 2020, 745 . 748 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 749 Label Assignment and Context-Specific Label Space", 750 RFC 5331, DOI 10.17487/RFC5331, August 2008, 751 . 753 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 754 Decraene, B., Litkowski, S., and R. Shakir, "Segment 755 Routing with the MPLS Data Plane", RFC 8660, 756 DOI 10.17487/RFC8660, December 2019, 757 . 759 Authors' Addresses 761 Bruno Decraene 762 Orange 763 Email: bruno.decraene@orange.com 765 Robert Raszuk 766 NTT Network Innovations 767 940 Stewart Dr 768 Sunnyvale, CA 94085 769 United States of America 770 Email: robert@raszuk.net 772 Zhenbin Li 773 Huawei Technologies 774 Email: lizhenbin@huawei.com 776 Cheng Li 777 Huawei Technologies 778 Email: chengli13@huawei.com