idnits 2.17.1 draft-decraene-spring-srv6-vlsid-05.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 (February 22, 2021) is 1158 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 271 -- Looks like a reference, but probably isn't: '1' on line 271 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-11 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-08 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: August 26, 2021 NTT Network Innovations 6 Z. Li 7 C. Li 8 Huawei Technologies 9 February 22, 2021 11 SRv6 vSID: Network Programming extension for variable length SIDs 12 draft-decraene-spring-srv6-vlsid-05 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 August 26, 2021. 41 Copyright Notice 43 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. Global vSIDs . . . . . . . . . . . . . . . . . . . . . . 8 67 5.2. Local vSIDs . . . . . . . . . . . . . . . . . . . . . . . 9 68 6. Optional extensions . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. A node requiring a larger vSIDs length. . . . . . . . . . 10 70 6.2. Inter Routing Domains with the End.XvPS behavior . . . . 12 71 6.3. NSIDs flavor . . . . . . . . . . . . . . . . . . . . . . 13 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 75 10. Changes / Authors Notes . . . . . . . . . . . . . . . . . . . 14 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 11.2. Informative References . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 The Segment Routing (SR) architecture is defined RFC 8402 [RFC8402]. 85 IPv6 Segment Routing Header (SRH) is defined RFC 8754 [RFC8754]. 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 RFC 8754 [RFC8754], the SR node 155 identifies its local SID by performing a longest-prefix-match lookup 156 on the packet IPv6 destination address. This identifies the SID and 157 its properties, such as the SR endpoint behavior but also the length 158 of the vSIDs. 160 3. SRv6 Variable Length SIDs 162 An SRv6 vSID deployment choose one length 'L' of vSIDs and an 163 associated SRv6 vSIDs prefix. 165 0 (bits) vSIDs 128 166 Length 168 +--------------------------------------------------------------+ 169 | SRv6 SID | 170 +--------------------------------------------------------------+ 172 +--------------------------------------------------------------+ 173 | SRv6 vSIDs prefix | vSID | 174 +--------------------------------------------------------------+ 176 Figure 1: SRv6 SID:= SRv6 vSIDs prefix + SRv6 vSID 178 An SRv6 vSID deployment may use multiple SRv6 vSIDs prefixes. Each 179 prefix may have its own vSIDs length. 181 As per section 3.1 of [I-D.ietf-spring-srv6-network-programming], an 182 SRv6 SID can be represented as 'B:N:FUNCT:ARG'. Where 'B' is the 183 SRv6 SID prefix, N is the identifier of the parent node N, FUNCT is 184 the function of the SID of length 128-S. 186 For SRv6 vSIDs, the SRv6 prefix is 'B' of length LB as advertised in 187 the SRv6 SID Structure Sub-Sub-TLV defined in 188 [I-D.ietf-lsr-isis-srv6-extensions]. The vSID length for vSIDs of 189 this block is computed as 128 - LB. The vSID includes 'N:FUNCT:ARG'. 191 In order to simplify implementations, the length of the vSIDs MUST be 192 a multiple of 8-bits, up to 128 bits included, in order to provide 193 octet alignment in the SRH Segment List. However this specifications 194 is written to work for any bit granularity from 1 to 128 bits. This 195 allows for a future document to define a new profile with a higher 196 granularity (e.g. 1 bit, 4 bits, 16 bits, or an integer fraction 197 128-bits) depending on hardware capabilities and flexibility 198 requirements. To allow some implementations to be further 199 simplified, a specific profile 'Profile-32' is created restricting 200 the vSID length to be 32-bits. 202 3.1. Encoding vSIDs in the SRH 204 As per section 2 of RFC 8754 [RFC8754], the Segment Routing Header 205 (SRH) is defined as follows: 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Last Entry | Flags | Tag | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 | Segment List[0] (128 bits IPv6 address) | 216 | | 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 | | 221 ... 222 | | 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 | Segment List[n] (128 bits IPv6 address) | 227 | | 228 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 // // 231 // Optional Type Length Value objects (variable) // 232 // // 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2: SRH with 128-bits SRv6 SID 237 When vSIDs are used, there are encoded in the Segment List of the 238 Segment Routing Header (SRH). 240 vSIDs are encoded back to back using their native length. There is 241 no padding between SIDs and there is no specific alignment of the 242 SID. 244 In a SRH, all vSIDs MUST have the same vSIDs length 'L' and the same 245 SRv6 vSIDs prefix. 247 If the Segment List[n] does not end on a octet boundary, then padding 248 bits MUST be added up to the next octet boundary. Those padding bits 249 MUST be set to 0 when sent and ignored on receipt. 251 TLVs starts on next octet boundary. 253 As defined in RFC 8754 [RFC8754], padding TLVs are used to pad the 254 SRH to a multiple of 8 octets. As vSIDs may be of any size, not 255 necessarily a multiple of 8 octets, the support of padding TLVs are 256 REQUIRED. 258 The fields 'Segments Left' and 'Last Entry" keep their meaning but 259 refers to vSIDs of length L. 261 The following diagram illustrates an example of SRH with vSIDs of 262 sixteen bits: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Last Entry | Flags | Tag | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Segment List[0] | Segment List[1] | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | ..... ..... | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Segment List[n] | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 // // 278 // Optional Type Length Value objects (variable) // 279 // // 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 3: SRH with SRv6 vSIDs with 16-bits vSIDs 284 3.2. SRv6 vSIDs Network Programming 286 This section defines a flavor for Endpoint behaviors. It defined 287 below using the "End" Endpoint behavior but is applicable to all SID 288 behaviors. 290 The processing takes as an argument the length L of the vSIDs. This 291 length L is a property of the vSID and is given as a result of the 292 lookup on the IPv6 destination address which identifies the SRv6 SID 293 and its properties. The properties include the Endpoint behavior and 294 the length L of the vSIDs. 296 When N receives a packet whose IPv6 DA is S and S is a local vSID of 297 length L, the lines S08 and S14 of the End processing which were, as 298 per section 4.1 of [I-D.ietf-spring-srv6-network-programming]: 300 S08. max_LE = (Hdr Ext Len / 2) - 1 302 [...] 304 S14. Update IPv6 DA with Segment List[Segments Left] 306 are replaced by the following: 308 S08. max_LE = (Hdr Ext Len * 64 / L) - 1 310 [...] 312 S14. Copy Segment List[Segments Left] from the SRH to the L lowest 313 order bits of the destination address of the IPv6 header. 315 Note: S14. Taking into consideration that the Segment List is a list 316 of vSIDs of length L bits 318 4. Benefits 320 SRv6 vSID is believed to have the following benefits: 322 o Aligned with SRv6: SR architecture, SRv6 Network Programming. 324 o Reduced SID hence reduced header length. 326 o Flexible SID length, to accommodate for various deployment models, 327 network sizes, SRv6 usages. 329 * A typical vSIDs length could be 32 bits. Compared to SR-MPLS 330 (which has a 20 bits SID) it is larger and more scalable. 332 Compared to SRv6 (which has a 128 bits SID) it's four times 333 more compact. 335 * Other SID length are possible: 16 bits would be 8 times more 336 compact than SRv6 SID and 2 times more compact the SR-MPLS shim 337 header and large enough for most deployments; 8 bits would be 338 16 (respectively 4) more compact than SRv6 SID (respectively 339 SR-MPLS shim header) and could fit some specific deployments 340 (e.g. local adjacency SID only). 342 o Using SRv6 header (SRH) with no additional fields. 344 o No requirement for additional IPv6 addressing space: a /64 per 345 router is more than enough. A /96 per router is the typical 346 requirement. 348 5. Illustrations 350 This section illustrates the usage of SRv6 vSIDs through two 351 examples. The first example uses global segments with a vSIDs 352 locator been globally routable. The second example uses local 353 segments only with a vSIDs locator commom to all SR end nodes hence 354 not been able to locate a specific SR end node. Global and local 355 segments are defined as per RFC 8402 [RFC8402] section 2. 357 5.1. Global vSIDs 359 In this example vSIDs are used for global SIDs and are used alone 360 without 128-bits SRv6 SIDs. 362 The SR domain has the following characteristics: 364 o 1 000 SR endpoints nodes; 366 o network diameter is 10; 368 o vSIDs are chosen to be 32-bits long; 370 o each SRv6 node is allocated a /108 to allocate its vSIDs from. 371 This allows for 4 096 (2^^12) locators 1 million (2^^20) local 372 functions on each SR node; 374 o the SR domain and the SRv6 vSIDs prefix is allocated: 375 2001:DB8::/96; 377 o node N is allocated 2001:DB8:0:0:0:0:N/108; 378 Some metrics of this SR domain: 380 o An SR policy encoding a strictly routed path using only Adjacency 381 SIDs would need ten 32-bits vSIDs resulting in a total of 40 382 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 383 would require 160 octets; 385 o An SR policy using strictly routed path using four (node) SIDs 386 would need four 32-bits vSIDs resulting in a total of 16 octets in 387 the SRH. In contrast the use of 128-bits SRv6 SIDs would require 388 64 octets and the use of 20-bits SR-MPLS SID would require 16 389 octets; 391 o The IGP advertises 1 000 SRv6 locators to be installed in the IPv6 392 FIB of all IGP nodes (as per regular SRv6 and SR-MPLS); 394 o The IPv6 address space is one /108 per SR node for a total of one 395 /96 for the whole SR domain. 397 5.2. Local vSIDs 399 If SRv6 vSIDs only identifies local segments, with no needs for 400 global segments, there is no need for a global route toward a node 401 hence the 'N' may have a size of zero. This may be interesting for a 402 deployment using both 128-bits SRv6 SIDs and very short SRv6 vSIDs. 403 Such SRv6 vSIDs could be used when a strictly routed path is needed 404 and encoded as a list of adjacency SIDs. Given that the number of 405 local adjacency SIDs is independent of the size of the SR domain, and 406 typically below 255, one could use 8-bits vSIDs which would allow 407 encoding 16 vSIDs within a single 128-bits SRv6 SID hence provides a 408 very effective SRH compression. 410 In this example vSIDs are used only for local SIDs, such as adjacency 411 SIDs. vSIDs are used in complement with 128-bits SRv6 SIDs. 413 The SR domain has the following caracteristics: 415 o 10 000 SR endpoints nodes; 417 o network diameter is 30; 419 o SRv6 SIDs: 421 * each SRv6 node is allocated a /64 to allocate its 128-bits SIDs 422 from; 424 * SRv6 prefix: 2001:DB8::/48 (i.e., 65535 /64, allowing for 425 growth or multiple SR routing algorithms); 427 * node N is allocated 2001:DB8:0:N/64; 429 o SRv6 vSIDs 431 * local vSIDs are chosen to be 8-bits in length. They are used 432 for adjacency SIDs hence allow for 255 Adjacency SIDs per node; 434 * SRv6 vSIDs prefix is allocated 2001:DB8:0:FFFF::/120; 436 Some metrics of this SR domain: 438 o An SR policy encoding a strictly routed path using only adjacency 439 SIDs would need thirty 8-bits vSIDs resulting in a total of 32 440 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 441 would require 480 octets and the use of 20-bits SR-MPLS SID would 442 require 120 octets; 444 o The IGP advertises 10 000 SRv6 locators to be installed in the 445 IPv6 FIB of all IGP nodes (as per regular SRv6 or SR-MPLS); 447 o The IPv6 address space is one /64 per SR node for a total of one 448 /48 for the whole SR domain. 450 6. Optional extensions 452 6.1. A node requiring a larger vSIDs length. 454 One SR Endpoint node may need a larger vSIDs space. This may 455 especially be the case when at the same time: 457 o the vSIDs Length is chosen to be small in order to optimize for 458 the size of the SRH header. Indeed, for topological/routing 459 instructions, the number of SIDs in the SRH may be high in some 460 use cases, up to the network diameter, calling for small vSIDs. 462 o one vSID is a service instruction and the number of service SIDs 463 may be high, requiring a SID longer than a vSIDs Length. 465 This section defines two solutions to increase the vSIDs length on a 466 node requiring a vSIDs space larger than other nodes. 468 6.1.1. Allocating a shorter locator to a node. 470 In order to increase the vSIDs length on a node, a simple option is 471 to allocate multiple locators of a larger locator to this node, 472 within the SRv6 vSIDs prefix. As per 473 [I-D.ietf-spring-srv6-network-programming], a locator may be 474 represented as B:N where B is the SRv6 SID block (IPv6 subnet 475 allocated for SRv6 SIDs by the operator) and N is the identifier of 476 the parent node instantiating the SID. Following this format, 477 multiple node identifiers Ns may be allocated to a node. Allocating 478 'k' identifiers increase the vSIDs space of that node by 'k'. 480 6.1.2. Combining k vSIDs to identify a behavior. 482 When an SR Endpoint node needs more SIDs than allowed by the vSIDs 483 Length, it MAY combine two (resp. N) vSIDs of length L to 484 effectively benefit from a vSID of length 2*L (resp. N*L). This is 485 a local choice of this SR Endpoint. Nothing specific is required in 486 the SRH which only contains those 2 (resp. N) SIDs instead of a 487 single one. 489 Note that when two vSIDs are combined, the first vSID may be seen as 490 having the role of a "Context SID" identifying a context specific SID 491 space/table, with the second SID been looked up in this context 492 specific table. This is similar to the Context-Specific Label space 493 defined in the section 3 of RFC 5331 [RFC5331]. 495 This section defines the extension to SRv6 Network Programming 496 allowing for a SID behavior "End.DT6" to be encoded with 'k' vSID. 497 This is equally applicable to others SID behaviors. 499 The processing takes as an argument the vSIDs length 'L', and the 500 number of vSIDs 'k'. 'L' and 'k' are a property of the vSID and are 501 given as a result of the lookup of the IPv6 destination address which 502 identifies the SRv6 SID and its properties. The properties include 503 the Endpoint behavior, the length L of the vSIDs and the number 'k' 504 of vSIDs used to encode this behavior in the SRH. 506 When N receives a packet destined to S and S is a local End.DT6 SID 507 encoded with 'k' vSIDs, N does the following processing: 509 When N receives a packet whose IPv6 DA is S and S is a local End.DT6 510 vSID of length L and encoded with 'k' vSIDs the line S02 of the 511 End.DT6 processing which was, as per section 4.6 of 512 [I-D.ietf-spring-srv6-network-programming]: 514 S02. If (Segments Left != 0) { 515 is replaced by the following: 517 S02. If (Segments Left != k - 1) { 519 When processing the Upper-layer header of a packet, the lines S04-S05 520 which were: 522 S04. Remove the outer IPv6 Header with all its extension headers 524 S05. Set the packet's associated FIB table to T 526 are replaced by the following: 528 S04a. Read the k-1 next vSIDs 530 S04b. Remove the outer IPv6 Header with all its extension headers 532 S05. Set the packet's associated FIB table to the one identified by 533 the concatenation of the k-1 next vSIDs 535 6.2. Inter Routing Domains with the End.XvPS behavior 537 Some SRv6 traffic may need to cross multiple routing domains, such as 538 differents Autonomous Systems (ASes) or different routing areas. 539 Different routing domains may use different addressing schema making 540 it difficult to find a common SRv6 vSIDs prefix. 542 This section defines an optional solution and SID behavior allowing 543 for the use of different SRv6 vSIDs prefixes between routing domains. 545 The solution requires a new SID behavior, called "Endpoint with 546 cross-connect to an array of layer-3 adjacencies and SRv6 vSIDs 547 Prefix Swap" (End.XvPS for short) allowing for this transition of 548 SRv6 vSIDs prefix between two routing domains. 550 End.XvPS is a variant of End.X, performing both "End.X Layer-3 Cross- 551 Connect" and the translation of the SRv6 vSIDs prefix between the two 552 routing domains. 554 The processing takes as an argument the vSIDs length L and the prefix 555 P2 of the SRv6 vSIDs prefix in the second domain. Those two 556 parameters are a property of the (received) vSID and are given as a 557 result of the lookup on the IPv6 destination address which identifies 558 the SRv6 SID and its properties. 560 When N receives a packet whose IPv6 DA is S and S is a End.XvPS SID 561 behavior, with a local vSID length L, and a remote/next SRv6 vSIDs 562 prefix P2, the line S14 of the End processing which was, as per 563 section 4.1 of [I-D.ietf-spring-srv6-network-programming]: 565 S14. Update IPv6 DA with Segment List[Segments Left] 567 is replaced by the following: 569 S14. Copy Segment List[Segments Left] from the SRH to the L lowest 570 order bits of the destination address of the IPv6 header and copy the 571 SRv6 vSIDs prefix P2 to the 128-L highest order bits of the 572 destination address. 574 Note: the way the SRv6 vSIDs prefix P2 of the next routing domain is 575 known is out of scope of this document. As examples, they could be 576 learnt via configuration or using a signaling protocol either with 577 the peer domain of with a central controler (e.g. PCE). 579 When End.XvPS SID behavior is used, the restriction on the SRH is 580 relaxed and becomes: in a SRH, all vSID MUST have the same vSID 581 length 'L' and within a routing domain, the same SRv6 vSID 582 prefix.Between routing domaines, separated with the End.XvPS 583 behavior, SRv6 vSID prefixes may be different. 585 6.3. NSIDs flavor 587 The NSIDs flavors is a variant of the End, End.X and End.XvPS 588 behaviors. 590 The NSIDs flavors copy N vVSID from the SRH to the IPv6 destination 591 address. 593 When N receives a packet whose IPv6 DA is S and S is a NSIDs flavor, 594 with a local vSID length L, and a local paramater N, the lines S09, 595 S13 and S14 of the End processing which was, as per section 4.1 of 596 [I-D.ietf-spring-srv6-network-programming]: 598 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 600 S13. Decrement Segments Left by 1 602 S14. Update IPv6 DA with Segment List[Segments Left] 604 are replaced by the following: 606 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) or 607 (Segments Left < = N){ 609 S13. Decrement Segments Left by N 610 S14. Copy N Segments List[Segments Left+N-1]...List[Segments Left] 611 from the SRH to the N*L lowest order bits of the destination address 612 of the IPv6 header. 614 Note that if N=128/L, a complete IPv6 address is copied. This is 615 useful when the next SR node is an SRv6 PE requiring its 128-bits 616 SIDs in the IPv6 destination address. This is also useful for inter 617 domain scenarios where both domains use unrelated address spaces and 618 hence use two different SRv6 vSIDs prefixes. 620 7. Security Considerations 622 This document does not change the security considerations of SRv6. 623 Please refers to RFC 8402 [RFC8402], RFC 8754 [RFC8754] and 624 [I-D.ietf-spring-srv6-network-programming] for existing security 625 consideration. 627 8. Acknowledgements 629 This document has been inspired by the work of the SPRING WG and in 630 particular the work done in 631 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] and 632 [I-D.li-spring-compressed-srv6-np]. The authors would like to 633 acknowledge the authors of these two documents. 635 The authors would like to thank Joel Halpern and Francois Clad for 636 their review and comments. 638 9. Contributors 640 Daniel Voyer 642 Bell Canada 644 Canada 646 Email: daniel.voyer@bell.ca 648 10. Changes / Authors Notes 650 [RFC Editor: Please remove this section before publication] 652 00: Initial version. 654 01: 656 o Removal of the vSID Size TLV; addition of the IS-IS extension; 657 addition of the SR header length check in the pseudo code. 659 o Addition of the IS-IS extension; 661 o Addition of the SR header length check in the pseudo code. 663 02: 665 o Change of terminology (VLSID changed to vSID); 667 o Swapping the two examples in section 'Illustrations'.; 669 o Addition of two solutions to provide more vSID space to some nodes 670 in section 'Node requiring a larger vSID length'; 672 o Addition of a solution for crossing routing domains using 673 different SRv6 vSID prefixes and/or different vSID length; 675 03: 677 o Minor updates in section 'Inter Routing Domains' 679 04: 681 o Creating of a profile only supporting vSID of length 32-bits. 683 o Addition of the NSIDs flavor. 685 05: 687 o Editorial changes. 689 o Removal of the IGP signaling extension. The size of the SRv6 690 block is advertised in the existing SRv6 SID Structure Sub-Sub- 691 TLV. 693 11. References 695 11.1. Normative References 697 [I-D.ietf-lsr-isis-srv6-extensions] 698 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 699 Z. Hu, "IS-IS Extension to Support Segment Routing over 700 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11 701 (work in progress), October 2020. 703 [I-D.ietf-spring-srv6-network-programming] 704 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 705 Matsushima, S., and Z. Li, "SRv6 Network Programming", 706 draft-ietf-spring-srv6-network-programming-28 (work in 707 progress), December 2020. 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, 711 DOI 10.17487/RFC2119, March 1997, 712 . 714 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 715 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 716 May 2017, . 718 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 719 Decraene, B., Litkowski, S., and R. Shakir, "Segment 720 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 721 July 2018, . 723 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 724 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 725 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 726 . 728 11.2. Informative References 730 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 731 Filsfils, C., Camarillo, P., 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", draft-filsfils-spring- 735 net-pgm-extension-srv6-usid-08 (work in progress), 736 November 2020. 738 [I-D.li-spring-compressed-srv6-np] 739 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 740 Guichard, J., Cong, L., and S. Peng, "Compressed SRv6 741 Network Programming", draft-li-spring-compressed- 742 srv6-np-02 (work in progress), February 2020. 744 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 745 Label Assignment and Context-Specific Label Space", 746 RFC 5331, DOI 10.17487/RFC5331, August 2008, 747 . 749 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 750 Decraene, B., Litkowski, S., and R. Shakir, "Segment 751 Routing with the MPLS Data Plane", RFC 8660, 752 DOI 10.17487/RFC8660, December 2019, 753 . 755 Authors' Addresses 757 Bruno Decraene 758 Orange 760 Email: bruno.decraene@orange.com 762 Robert Raszuk 763 NTT Network Innovations 764 940 Stewart Dr 765 Sunnyvale, CA 94085 766 USA 768 Email: robert@raszuk.net 770 Zhenbin Li 771 Huawei Technologies 773 Email: lizhenbin@huawei.com 775 Cheng Li 776 Huawei Technologies 778 Email: chengli13@huawei.com