idnits 2.17.1 draft-decraene-spring-srv6-vlsid-01.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 (January 24, 2020) is 1548 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 259 -- Looks like a reference, but probably isn't: '1' on line 259 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-08 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-02 == Outdated reference: A later version (-02) exists of draft-li-spring-compressed-srv6-np-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Decraene 3 Internet-Draft Orange 4 Intended status: Standards Track January 24, 2020 5 Expires: July 27, 2020 7 SRv6 Network Programming extension: the Variable Length SID flavor 8 draft-decraene-spring-srv6-vlsid-01 10 Abstract 12 This document proposes an extension to Segment Routing IPv6 (SRv6) 13 Network Programming to allow for SRv6 Segment Identifier (SID) of 14 variable length. The use of smaller SRv6 SID reduces the size the 15 SRv6 Header (SRH). This reduces the overhead for both the traffic 16 volume and the network processor. This document is aligned with the 17 SR architecture and does not change the SRH. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 27, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. SRv6 Variable Length SID . . . . . . . . . . . . . . . . . . 4 57 3.1. VLSID encoding in the SRH . . . . . . . . . . . . . . . . 5 58 3.2. SRv6 VLSID behavior . . . . . . . . . . . . . . . . . . . 6 59 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5.1. Local VLSIDs . . . . . . . . . . . . . . . . . . . . . . 8 62 5.2. Global VLSIDs . . . . . . . . . . . . . . . . . . . . . . 9 63 6. Signaling VLSID . . . . . . . . . . . . . . . . . . . . . . . 9 64 6.1. Signaling VLSID size in IS-IS . . . . . . . . . . . . . . 10 65 7. Combining VLSIDs on an SR Endpoint . . . . . . . . . . . . . 10 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 69 11. Changes / Author Notes . . . . . . . . . . . . . . . . . . . 12 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 12.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 The Segment Routing (SR) architecture is defined RFC 8402 [RFC8402]. 79 IPv6 Segment Routing Header (SRH) is defined 80 [I-D.ietf-6man-segment-routing-header]. 82 SRv6 Network Programming is defined 83 [I-D.ietf-spring-srv6-network-programming]. 85 The reader is expected to be familiar with the three above documents 86 which define Segment Routing over the IPv6 data-plane (SRv6). 88 SRv6 is flexible and powerful, but in some (uses) cases the size of 89 the SID may be seen as too large. This document proposes an 90 extension of SRv6 Network Programming to allow for SID of variable 91 length. This allows for the use of smaller SID if needed for a 92 specific deployment. 94 This document is aligned and does not change the SR architecture nor 95 the SRH. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 103 appear in all capitals, as shown here. 105 2. Overview 107 In a nutshell, SRv6 Variable Length SID (SRv6 VLSID) proposes to: 109 o define one SRv6 SID block dedicated to SRv6 VLSID and called SRv6 110 VLSID block; 112 o define the VLSID as the SRv6 SID minus the VLSID block: SRv6 SID:= 113 SRv6 VLSID block + SRv6 VLSID; 115 o encode in the Segment List of the SRH only the list of VLSIDs. 117 In other words, SRv6 VLSID proposes to compress the SIDs in the SRH 118 by not encoding the common SRv6 SID prefix (SRv6 VLSID block) in the 119 SRH Segment List. The SRv6 VLSID block is only encoded once, in the 120 IPv6 destination address. 122 In a way, this is similar to SR-MPLS RFC 8660 [RFC8660]: 124 o For SR-MPLS: SR-MPLS Label:= SRGB + Index 126 o For SRv6 VLSID: SRv6 SID := SRv6 VLSID block + SRv6 VLSID 128 One difference compared to SR-MPLS is that lowest bits of the SRv6 129 VLSID block are defined to be zero. This allows for an easier 130 operation in the data plane as the addition of the VLSID may be 131 replaced by a copy of the VLSID byte(s). Another difference is that 132 the motivation to offset to a zero base index/VLSID is different. 134 The format of the SRH is unchanged. The length of the VLSID is 135 variable but its size does not need to be encoded in the SRH header. 136 Indeed the VLSID size only needs to be known by the SR Segment 137 Endpoint Node processing it. As per section 4.3 of 138 [I-D.ietf-6man-segment-routing-header], the SR node identifies its 139 local SID by performing a longest-prefix-match lookup on the packets 140 IPv6 destination address. This identifies the SID and its 141 properties, in particular the size of the VLSID. 143 3. SRv6 Variable Length SID 145 As per section 3.1 of [I-D.ietf-spring-srv6-network-programming], an 146 SRv6 SID can be represented as 'B:N:FUNCT'. Where 'B' is the SRv6 147 SID block, N is the identifier of the parent node N, FUNCT is the 148 function of the SID of size 128-S. 150 An SRv6 VLSID deployment choose one size 'L' of VLSID and an 151 associated SRv6 VLSID block. 153 0 (bits) 128 155 SRv6 SID: 156 +--------------------------------------------------------------+ 157 | B: SRv6 SID block | N: Node | FUNCT: Function | 158 +--------------------------------------------------------------+ 160 SRv6 VLSID SID: 161 +--------------------------------------------------------------+ 162 | SRv6 VLSID block (aka Common Prefix) | VLSID | 163 +--------------------------------------------------------------+ 165 Figure 1: SRv6 SID:= SRv6 VLSID block + SRv6 VLSID 167 An SRv6 VLSID deployment can use multiple SRv6 VLSID blocks. Each 168 block may have its own VLSID size. 170 If SRv6 VLSIDs are to identify global segments, the VLSID would 171 typically include both the Node part 'N' of the locator and the local 172 function 'FUNCT' locally instantiated on the node N. Hence the 173 format of the VLSID would be "N:FUNCT". 175 If SRv6 VLSIDs are to only identify local segments, the VLSID could 176 be chosen to only include the local function 'FUNCT' locally 177 instantiated on the node N. Hence the format of the VLSID would be 178 "FUNCT". This may be interesting for a deployment using both 179 128-bits SRv6 SIDs and very short SRv6 VLSIDs. Such SRv6 VLSIDs 180 could be used when a strictly routed path is needed and encoded as a 181 list of adjacency SIDs. Given that the number of local adjacency 182 SIDs is independent of the size of the SR domain, and typically below 183 255, one could use 8-bits VLSID which would allow encoding 16 VLSIDs 184 within a single 128-bits SRv6 SID hence provides a very effective SRH 185 compression. 187 Note: in the initial version of this document, the length of the 188 VLSID is assumed to be a multiple of 8-bits, up to 128 bits included, 189 in order to provide octet alignement in the SRH Segment List. In a 190 future version of this document, the granularity may changed (e.g. 1 191 bit, 4 bits, 16 bits, or an integer fraction of a 128-bits SRv6 SID) 192 depending on hardware capabilities and flexibility requirements. 193 Also, implementations profiles could be defined in order for an 194 implementation to support only one type/subset of granularity. 196 3.1. VLSID encoding in the SRH 198 As per section 2 of [I-D.ietf-6man-segment-routing-header], the 199 Segment Routing Header (SRH) is defined as follows: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Last Entry | Flags | Tag | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 | Segment List[0] (128 bits IPv6 address) | 210 | | 211 | | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | 214 | | 215 ... 216 | | 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 | Segment List[n] (128 bits IPv6 address) | 221 | | 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 // // 225 // Optional Type Length Value objects (variable) // 226 // // 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Figure 2: SRH with 128-bits SRv6 SID 231 When VLSID are used, there are encoded in the Segment List of the 232 Segment Routing Header (SRH). 234 VLSID are encoded back to back using their native size. There is no 235 padding between SIDs. There is no alignement of the SID except that 236 each SID begins and ends on an octet boundary. 238 In a SRH, all VLSID MUST have the same size 'L'. 240 The Segment List MUST be encoded as a multiple of 128-bits. If the 241 size of the VLSID multiplied by the number of segments in the SRH 242 Segment List is not a multiple of 128 bits, then padding bits MUST be 243 added up to the next multiple of 128 bits. Those padding bits MUST 244 be set to 0 when sent and ignored on receipt. 246 The fields 'Segments Left' and 'Last Entry" keep their meaning but 247 refers to VLSID of size L. 249 The following diagramm illustrates an example with VLSID of sixteen 250 bits: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Last Entry | Flags | Tag | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Segment List[0] (L bits VLSID)| Segment List[1] (L bits VLSID)| 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | ..... ..... | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Segment List[n] (L bits VLSID)| Padding bits | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 // // 266 // Optional Type Length Value objects (variable) // 267 // // 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 3: SRH with SRv6 VLSID with 16-bits VLSID 272 3.2. SRv6 VLSID behavior 274 The VLSID behavior is a flavour of the endpoint behavior. 276 The behavior takes as an argument the size L of the VLSID. This size 277 L is a property of the VLSID and is given by the lookup on the IPv6 278 destination address which identifies the SRv6 SID and its properties. 279 As part of the properties, the SR endpoint learn that the SID is a 280 VLSID of size L. 282 When N receives a packet whose IPv6 DA is S and S is a local VLSID of 283 size L, the line S16 form the End processing which was, as per 284 section 4.1 of [I-D.ietf-spring-srv6-network-programming]: 286 S08. max_LE = (Hdr Ext Len / 2) - 1 288 [...] 290 S14. Update IPv6 DA with Segment List[Segments Left] 292 are replaced by the following: 294 S08. max_LE = (Hdr Ext Len * 64 / VLSID) - 1 296 [...] 298 S14. Copy Segment List[Segments Left] from the SRH to the L lowest 299 order bits of the destination address of the IPv6 header. 301 Note: S14. Taking into consideration that the Segment List is a list 302 of VLSIDs of size L bits 304 4. Benefits 306 SRv6 Variable Length SID is believed to have the following benefits: 308 o Aligned with SRv6: SR architecture, SRv6 Network Programming. 310 o Reduced SID hence reduced header length. 312 o Flexible SID length, to accommodate for various deployment models, 313 network sizes, SRv6 usages. 315 * A typical VLSID length could be 32 bits. Compared to SR-MPLS 316 (which has a 20 bits SID) it is larger and more scalable. 317 Compared to SRv6 (which has a 128 bits SID) it's four times 318 more compact. 320 * Other SID length are possible: 16 bits would be 8 times more 321 compact than SRv6 SID and 2 times more compact the SR-MPLS shim 322 header and large enough for most deployments; 8 bits would be 323 16 (respectively 4) more compact than SRv6 SID (respectively 324 SR-MPLS shim header) and could fit some specific deployments 325 (e.g. local adjacency SID only). 327 o Unchanged SRv6 header (SRH). 329 o No requirement for additional IPv6 addressing space: a /64 per 330 router is more than enough. A /96 per router is the typical 331 requirement. 333 5. Illustrations 335 This section illustrates the usage of SRv6 VLSIDs through two 336 examples. 338 5.1. Local VLSIDs 340 In this example VLSIDs are used only for local SIDs, such as 341 adjacency SIDS. VLSIDs are used in complement with 128-bits SRv6 342 SIDs. 344 The SR domain has the following caracteristics: 346 o 10 000 SR endpoints nodes; 348 o network diameter is 30; 350 o SRv6 SIDs: 352 * each SRv6 node is allocated a /64 to allocate its 128-bits SID 353 from; 355 * SRv6 block: 2001:DB8::/48 (i.e., 65535 /64, allowing for growth 356 or multiple SR routing algorithms); 358 * node N is allocated 2001:DB8:0:N/64; 360 o SRv6 VLSIDs 362 * local VLSIDs are chosen to be 8-bits in size. They are used 363 for adjacency SIDs hence allow for 255 Adjacency SIDs per node; 365 * SRv6 VLSID block is allocated 2001:DB8:0:FFFF::/120; 367 Some metrics of this SR domain: 369 o An SR policy encoding a strictly routed path using only adjacency 370 SIDs would need 30 8-bits VLSIDs resulting in a total of 32 octets 371 in the SRH. In contrast the use of 128-bits SRv6 SIDs would 372 require 480 octets and the use of 20-bits SR-MPLS SID would 373 require 120 octets; 375 o The IGP advertises 10 000 SRv6 locators to be installed in the 376 IPv6 FIB of all IGP nodes (as per regular SRv6 and SR-MPLS); 378 o The IPv6 address space is one /64 per SR node for a total of one 379 /48 for the whole SR domain. 381 5.2. Global VLSIDs 383 In this example VLSIDs are used for global SIDs and are used alone 384 without 128-bits SRv6 SIDs. 386 The SR domain has the following caracteristics: 388 o 1 000 SR endpoints nodes; 390 o network diameter is 10; 392 o VLSID are chosen to be 32-bits long; 394 o each SRv6 node is allocated a /108 to allocate its VLSID from. 395 This allows for 4 096 (2^^12) locators 1 million (2^^20) local 396 functions on each SR node; 398 o the SR domain and the SRv6 VLSID block is allocated: 399 2001:DB8::/96; 401 o node N is allocated 2001:DB8:0:0:0:0:N/108; 403 Some metrics of this SR domain: 405 o An SR policy encoding a strictly routed path using only Adjacency 406 SIDs would need 10 32-bits VLSIDs resulting in a total of 40 407 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 408 would require 160 octets; 410 o An SR policy using strictly routed path using 4 (node) SIDs would 411 need 4 32-bits VLSIDs resulting in a total of 16 octets in the 412 SRH. In contrast the use of 128-bits SRv6 SIDs would require 64 413 octets and the use of 20-bits SR-MPLS SID would require 16 octets; 415 o The IGP advertises 1 000 SRv6 locators to be installed in the IPv6 416 FIB of all IGP nodes (as per regular SRv6 and SR-MPLS); 418 o The IPv6 address space is one /108 per SR node for a total of one 419 /96 for the whole SR domain. 421 6. Signaling VLSID 423 Control plane extensions are required to signal the size of the 424 VLSID. This will be defined in a later version of this document. 426 Note for IGP the size of the VLSID could be advertised along the SID, 427 or the Locator, or as a property of the SR node. 429 6.1. Signaling VLSID size in IS-IS 431 SRv6 SIDs are advertised in IS-IS as per 432 [I-D.ietf-lsr-isis-srv6-extensions]. 434 This document defines an new sub-TLV called VLSID Size' that MAY be 435 advertised in the locator entries of the SRv6 Locator TLV. The 436 format is the following: 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type | Length | Flags | VLSID Size | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Figure 4: IS-IS VLSID Size sub-TLV 446 Type: TBD1. 448 Length: 2. 450 Flags: 1 octet. No flags are currently defined. 452 VLSID Size: Size of the VLSID in bits. This applies for all SIDs of 453 this locator. 455 The SRv6 VLSID block is not advertised but can be computed. The SRv6 456 VLSID block is the 'VLSID Size' first bits of the Locator. It's size 457 is 128 - 'VLSID Size'. 459 Note: alternatively the VLSID Size could be advertised as a Sub-Sub- 460 TLV of SRv6 End SID or SRv6 End.X SID or SRv6 LAN End.X SID TLVs. 461 The encoding choice is postponed to a future version of this 462 document. 464 7. Combining VLSIDs on an SR Endpoint 466 One SR Endpoint node may need more functions (SIDs) than allowed by 467 the size the FUNC field in the VLSID. This may especially be the 468 case when at the same time: 470 o the VLSID is choosen to be small in order to optimize for the size 471 of the SRH header. Indeed, for topological/routing instructions, 472 the number of SIDs may be high in some use cases, up to the 473 network diameter. 475 o one VLSID (e.g. the last one) is a service instruction and the 476 number of service SID may be high, requiring a SID longer than a 477 VLSID. 479 When an SR Endpoint node needs more functions (SIDs) than allowed by 480 the size the FUNC field in the VLSID, it MAY combine two (resp. N) 481 VLSIDs of size L to effectively benefit from a SID of size 2*L (resp. 482 N*L). This is a local choice of this SR Endpoint using two (resp. 483 N) VLSIDs instead of one. Nothing specific is required in the SRH 484 which only contains those 2 (resp. N) SIDs. 486 When two VLSIDs are combined, the first VLSID may be seen as having 487 the role of a "Context SID" identifying a context specific SID space/ 488 table, while the second SID is looked up in this context specific 489 table. This is similar to the Context-Specific Label space defined 490 in the section 3 of RFC 5331 [RFC5331]. 492 8. IANA Considerations 494 TBD. 496 9. Security Considerations 498 This document does not change the security considerations of SRv6. 499 Please refers to RFC 8402 [RFC8402], 500 [I-D.ietf-6man-segment-routing-header] and 501 [I-D.ietf-spring-srv6-network-programming] for existing security 502 consideration. 504 10. Acknowledgements 506 This document has been inspired by the work of the SPRING WG and in 507 particular the work done in 508 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] and 509 [I-D.li-spring-compressed-srv6-np]. The author would like to 510 acknowledge the authors of these two documents. 512 The author would like to thank Joel Halpern for his review and 513 comments. 515 11. Changes / Author Notes 517 [RFC Editor: Please remove this section before publication] 519 00: Initial version. 521 01: Removal of the VLSID Size TLV; addition of the IS-IS extension; 522 addition of the SR header length check in the pseudo code. 524 12. References 526 12.1. Normative References 528 [I-D.ietf-6man-segment-routing-header] 529 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 530 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 531 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 532 progress), October 2019. 534 [I-D.ietf-lsr-isis-srv6-extensions] 535 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 536 Z. Hu, "IS-IS Extension to Support Segment Routing over 537 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-03 538 (work in progress), October 2019. 540 [I-D.ietf-spring-srv6-network-programming] 541 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 542 Matsushima, S., and Z. Li, "SRv6 Network Programming", 543 draft-ietf-spring-srv6-network-programming-08 (work in 544 progress), January 2020. 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, 548 DOI 10.17487/RFC2119, March 1997, 549 . 551 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 552 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 553 May 2017, . 555 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 556 Decraene, B., Litkowski, S., and R. Shakir, "Segment 557 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 558 July 2018, . 560 12.2. Informative References 562 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 563 Filsfils, C., Camarillo, P., Cai, D., Jiang, Z., Voyer, 564 D., Shawky, A., Leymann, N., Steinberg, D., Zandi, S., 565 Dawra, G., Meilik, I., Uttaro, J., Jalil, L., So, N., 566 Fiumano, M., and M. Khaddam, "Network Programming 567 extension: SRv6 uSID instruction", draft-filsfils-spring- 568 net-pgm-extension-srv6-usid-02 (work in progress), August 569 2019. 571 [I-D.li-spring-compressed-srv6-np] 572 Li, Z., Li, C., Peng, S., Wang, Z., and B. Liu, 573 "Compressed SRv6 Network Programming", draft-li-spring- 574 compressed-srv6-np-00 (work in progress), July 2019. 576 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 577 Label Assignment and Context-Specific Label Space", 578 RFC 5331, DOI 10.17487/RFC5331, August 2008, 579 . 581 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 582 Decraene, B., Litkowski, S., and R. Shakir, "Segment 583 Routing with the MPLS Data Plane", RFC 8660, 584 DOI 10.17487/RFC8660, December 2019, 585 . 587 Author's Address 589 Bruno Decraene 590 Orange 592 Email: bruno.decraene@orange.com