idnits 2.17.1 draft-decraene-spring-srv6-vlsid-00.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 20, 2020) is 1529 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 230 -- Looks like a reference, but probably isn't: '1' on line 230 == 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 (~~), 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 January 20, 2020 5 Expires: July 23, 2020 7 SRv6 Network Programming extension: the Variable Length SID flavor 8 draft-decraene-spring-srv6-vlsid-00 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 23, 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 . . . . . . . . . . . . . . . . . . 3 57 3.1. VLSID encoding in the SRH . . . . . . . . . . . . . . . . 4 58 3.2. SRv6 VLSID behavior . . . . . . . . . . . . . . . . . . . 6 59 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.1. Local VLSIDs . . . . . . . . . . . . . . . . . . . . . . 8 62 5.2. Global VLSIDs . . . . . . . . . . . . . . . . . . . . . . 9 63 6. Signaling VLSID . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. Optional extensions . . . . . . . . . . . . . . . . . . . . . 10 65 7.1. VLSID Size TLV . . . . . . . . . . . . . . . . . . . . . 10 66 7.2. Combining VLSIDs on an SR Endpoint . . . . . . . . . . . 10 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 11. Changes / Author Notes . . . . . . . . . . . . . . . . . . . 12 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 12.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 The Segment Routing (SR) architecture is defined RFC 8402 [RFC8402]. 80 IPv6 Segment Routing Header (SRH) is defined 81 [I-D.ietf-6man-segment-routing-header]. 83 SRv6 Network Programming is defined 84 [I-D.ietf-spring-srv6-network-programming]. 86 The reader is expected to be familiar with the three above documents 87 which define Segment Routing over the IPv6 data-plane (SRv6). 89 SRv6 is flexible and powerful, but in some (uses) cases the size of 90 the SID may be seen as too large. This document proposes an 91 extension of SRv6 Network Programming to allow for SID of variable 92 length. This allows for the use of smaller SID if needed for a 93 specific deployment. 95 This document is aligned and does not change the SR architecture nor 96 the SRH. 98 1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 104 appear in all capitals, as shown here. 106 2. Overview 108 In a nutshell, SRv6 Variable Length SID (SRv6 VLSID) proposes to: 110 o define one SRv6 SID block dedicated to SRv6 VLSID and called SRv6 111 VLSID block; 113 o define the VLSID as the SRv6 SID minus the VLSID block: SRv6 SID:= 114 SRv6 VLSID block + SRv6 VLSID; 116 o encode in the Segment List of the SRH only the list of VLSIDs. 118 In other words, SRv6 VLSID proposes to compress the SIDs in the SRH 119 by not encoding the common SRv6 SID prefix (SRv6 VLSID block) in the 120 SRH Segment List. The SRv6 VLSID block is only encoded once, in the 121 IPv6 destination address. 123 The format of the SRH is unchanged. The length of the VLSID is 124 variable but its size does not need to be encoded in the SRH header. 125 Indeed the VLSID size only needs to be known by the SR Segment 126 Endpoint Node processing it. As per section 4.3 of 127 [I-D.ietf-6man-segment-routing-header], the SR node identifies its 128 local SID by performing a longest-prefix-match lookup on the packets 129 IPv6 destination address. This identifies the SID and its 130 properties, in particular the size of the VLSID. 132 3. SRv6 Variable Length SID 134 As per section 3.1 of [I-D.ietf-spring-srv6-network-programming], an 135 SRv6 SID can be represented as 'B:N:FUNCT'. Where 'B' is the SRv6 136 SID block, N is the identifier of the parent node N, FUNCT is the 137 function of the SID of size 128-S. 139 An SRv6 VLSID deployment choose one size 'L' of VLSID and an 140 associated SRv6 VLSID block. 142 0 (bits) 128 144 SRv6 SID: 145 +--------------------------------------------------------------+ 146 | B: SRv6 SID block | N: Node | FUNCT: Function | 147 +--------------------------------------------------------------+ 149 SRv6 VLSID SID: 150 +--------------------------------------------------------------+ 151 | SRv6 VLSID block (aka Common Prefix) | VLSID | 152 +--------------------------------------------------------------+ 154 Figure 1: SRv6 SID:= SRv6 VLSID block + SRv6 VLSID 156 An SRv6 VLSID deployment can use multiple SRv6 VLSID blocks. Each 157 block may have its own VLSID size. 159 If SRv6 VLSIDs are to identify global segments, the VLSID would 160 typically include both the Node part 'N' of the locator and the local 161 function 'FUNCT' locally instantiated on the node N. Hence the 162 format of the VLSID would be "N:FUNCT". 164 If SRv6 VLSIDs are to only identify local segments, the VLSID could 165 be chosen to only include the local function 'FUNCT' locally 166 instantiated on the node N. Hence the format of the VLSID would be 167 "FUNCT". This may be interesting for a deployment using both 168 128-bits SRv6 SIDs and very short SRv6 VLSIDs. Such SRv6 VLSIDs 169 could be used when a strictly routed path is needed and encoded as a 170 list of adjacency SIDs. Given that the number of local adjacency 171 SIDs is independent of the size of the SR domain, and typically below 172 255, one could use 8-bits VLSID which would allow encoding 16 VLSIDs 173 within a single 128-bits SRv6 SID hence provides a very effective SRH 174 compression. 176 Note: in the initial version of this document, the length of the 177 VLSID is assumed to be a multiple of 8-bits, up to 128 bits included, 178 in order to provide octet alignement in the SRH Segment List. In a 179 future version of this document, the granularity may changed (e.g. 1 180 bit, 4 bits, 16 bits, or an integer fraction of a 128-bits SRv6 SID) 181 depending on hardware capabilities and flexibility requirements. 182 Also, implementations profiles could be defined in order for an 183 implementation to support only one type/subset of granularity. 185 3.1. VLSID encoding in the SRH 187 As per section 2 of [I-D.ietf-6man-segment-routing-header], the 188 Segment Routing Header (SRH) is defined as follows: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Last Entry | Flags | Tag | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | 198 | Segment List[0] (128 bits IPv6 address) | 199 | | 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 | | 204 ... 205 | | 206 | | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 | Segment List[n] (128 bits IPv6 address) | 210 | | 211 | | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 // // 214 // Optional Type Length Value objects (variable) // 215 // // 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 2: SRH with 128-bits SRv6 SID 220 When VLSID are used, there are encoded in the Segment Routing Header 221 (SRH) as follows: 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Last Entry | Flags | Tag | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Segment List[0] (L bits VLSID)| Segment List[1] (L bits VLSID)| 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | ..... ..... | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Segment List[n] (L bits VLSID)| Padding bits | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 // // 237 // Optional Type Length Value objects (variable) // 238 // // 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 3: SRH with SRv6 VLSID (16-bits VLSID) 243 The fields 'Segments Left' and 'Last Entry" keeps their meaning but 244 refers to VLSID of size L. 246 In a SRH, all VLSID MUST have the same size 'L'. 248 In the Segment List, VLSID are encoded back to back using their 249 native size. There is no padding between SIDs. There is no 250 alignement of the SID except that each SID begins and ends on an 251 octet boundary. 253 The Segment List MUST be encoded as a multiple of 128-bits. If the 254 size of the VLSID multiplied by the number of segments in the SRH 255 Segment List is not a multiple of 128-bits, padding bits MUST be 256 added up to the next multiple of 128-bits. Those padding bits MUST 257 be set to 0 when sent and ignored on receipt. 259 3.2. SRv6 VLSID behavior 261 The VLSID behavior is a flavour of the endpoint behavior. 263 The behavior takes as an argument the size L of the VLSID. This size 264 L is a property of the VLSID and is given by the lookup on the IPv6 265 destination address which identifies the SRv6 SID and its properties. 266 As part of the properties, the SR endpoint learn that the SID is a 267 VLSID of size L. 269 When N receives a packet whose IPv6 DA is S and S is a local VLSID of 270 size L, the line S16 form the End processing which was, as per 271 section 4.1 of [I-D.ietf-spring-srv6-network-programming]: 273 S14. Update IPv6 DA with Segment List[Segments Left]. 275 is replaced by the following: 277 S14. Copy Segment List[Segments Left] from the SRH to the L lowest 278 order bits of the destination address of the IPv6 header. Taking 279 into consideration that the Segment List is a list of VLSIDs of size 280 L bits. 282 Note: lines S08 and S09 (checking for error in the SRH header) are 283 also to be updated. This is deferred to a future version of the 284 document. 286 4. Benefits 288 SRv6 Variable Length SID is believed to have the following benefits: 290 o Aligned with SRv6: SR architecture, SRv6 Network Programming. 292 o Reduced SID hence reduced header length. 294 o Flexible SID length, to accommodate for various deployment models, 295 network sizes, SRv6 usages. A typical VLSID length could be 32 296 bits. Compared to SR-MPLS (which has a 20 bits SID) it is larger 297 and more scalable. Compared to SRv6 (which has a 128 bits SID) 298 it's four times more compact. Other SID length are possible: 16 299 bits would be 8 times more compact than SRv6 SID and 2 times more 300 compact the SR-MPLS shim header and large enough for most 301 deployments; 8 bits would be 16 (respectively 4) more compact than 302 SRv6 SID (respectively SR-MPLS shim header) and could fit some 303 specific deployments (e.g. local adjacency SID only). 305 o Unchanged SRv6 header (SRH). 307 o No requirement for additional IPv6 addressing space: a /64 per 308 router is more than enough. A /96 per router is the typical 309 requirement. 311 5. Illustrations 313 This section illustrates the usage of SRv6 VLSIDs through two 314 examples. 316 5.1. Local VLSIDs 318 In this example VLSIDs are used only for local SIDs, such as 319 adjacency SIDS. VLSIDs are used in complement with 128-bits SRv6 320 SIDs. 322 The SR domain has the following caracteristics: 324 o 10 000 SR endpoints nodes; 326 o network diameter is 30; 328 o SRv6 SIDs: 330 * each SRv6 node is allocated a /64 to allocate its 128-bits SID 331 from; 333 * SRv6 block: 2001:DB8::/48 (i.e., 65535 /64, allowing for growth 334 or multiple SR routing algorithms); 336 * node N is allocated 2001:DB8:0:N/64; 338 o SRv6 VLSIDs 340 * local VLSIDs are chosen to be 8-bits in size. They are used 341 for adjacency SIDs hence allow for 255 Adjacency SIDs per node; 343 * SRv6 VLSID block is allocated 2001:DB8:0:FFFF::/120; 345 Some metric of this SR domain: 347 o An SR policy encoding a strictly routed path using only adjacency 348 SIDs would need 30 8-bits VLSIDs resulting in a total of 32 octets 349 in the SRH. In contrast the use of 128-bits SRv6 SIDs would 350 require 480 octets and the use of 20-bits SR-MPLS SID would 351 require 120 octets; 353 o The IGP advertises 10 000 SRv6 locators to be installed in the 354 IPv6 FIB of all IGP nodes (as per regular SRv6 and SR-MPLS); 356 o The IPv6 address space is one /64 per SR node for a total of one 357 /48 for the whole SR domain. 359 5.2. Global VLSIDs 361 In this example VLSIDs are used for global SIDs and are used alone 362 without 128-bits SRv6 SIDs. 364 The SR domain has the following caracteristics: 366 o 1 000 SR endpoints nodes; 368 o network diameter is 10; 370 o VLSID are chosen to be 32-bits long; 372 o each SRv6 node is allocated a /108 to allocate its VLSID from. 373 This allows for 4 096 (2^^12) locators 1 million (2^^20) local 374 functions on each SR node; 376 o the SR domain and the SRv6 VLSID block is allocated: 377 2001:DB8::/96; 379 o node N is allocated 2001:DB8:0:0:0:0:N/108; 381 Some metric of this SR domain: 383 o An SR policy encoding a strictly routed path using only Adjacency 384 SIDs would need 10 32-bits VLSIDs resulting in a total of 40 385 octets in the SRH. In contrast the use of 128-bits SRv6 SIDs 386 would require 160 octets; 388 o An SR policy using strictly routed path using 4 (node) SIDs would 389 need 4 32-bits VLSIDs resulting in a total of 16 octets in the 390 SRH. In contrast the use of 128-bits SRv6 SIDs would require 64 391 octets and the use of 20-bits SR-MPLS SID would require 16 octets; 393 o The IGP advertises 1 000 SRv6 locators to be installed in the IPv6 394 FIB of all IGP nodes (as per regular SRv6 and SR-MPLS); 396 o The IPv6 address space is one /108 per SR node for a total of one 397 /96 for the whole SR domain. 399 6. Signaling VLSID 401 Control plane extensions are required to signal the size of the 402 VLSID. This will be defined in a later version of this document. 403 Note for IGP the size of the VLSID could be advertised along the SID, 404 or the Locator, or as a property of the SR node. 406 7. Optional extensions 408 This section defines optional extension which may be supported by a 409 node. 411 7.1. VLSID Size TLV 413 Forwarding of an SRH containing VLSID does not require an SRH field 414 indicating the size of the VLSID. However in some cases, e.g., 415 packet parser like applications, it may be beneficial to know the 416 size of VLSID in order to correctly report the list of SIDs. 418 This section defines an SR TLV called 'VLSID Size' with the following 419 format: 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Type | Length | RESERVED | VLSID Size | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Where: 429 o Type: TBD1 (with the highest-order bit set to 1 as the TLV data 430 does not change en route). 432 o Length: 2. 434 o RESERVED: reserved for extensions. MUST be 0 on transmission and 435 ignored on receition. 437 o VLSID Size: size of the VLSID in bits. 439 VLSID Size MUST be between 8 and 128 included, and a multiple of 8. 440 In case of invalid number, the whole VLSID Size TLV MUST be ignored. 442 Alignment requirement: none. 444 7.2. Combining VLSIDs on an SR Endpoint 446 One SR Endpoint node may need more functions (SIDs) than allowed by 447 the size the FUNC field in the VLSID. This may especially be the 448 case when at the same time: 450 o the VLSID is choosen to be small in order to optimize for the size 451 of the SRH header. Indeed, for topological/routing instructions, 452 the number of SIDs may be high in some use cases, up to the 453 network diameter. 455 o one VLSID (e.g. the last one) is a service instruction and the 456 number of service SID may be high, requiring a SID longer than a 457 VLSID. 459 When an SR Endpoint node needs more functions (SIDs) than allowed by 460 the size the FUNC field in the VLSID, it MAY combine two (resp. N) 461 VLSID of size L to effectively benefit from a SID of size 2*L (resp. 462 N*L). This is a local choice of this SR Endpoint. Nothing specific 463 is required in the SRH which only contains those 2 (resp. N) SIDs. 465 When two VLSIDs are combined into one, the first VLSID may be seen as 466 having the role of a "Context SID" identifying a context specific SID 467 space/table, while the second SID is looked up in this context 468 specific table. This is similar to the Context-Specific Label space 469 defined in the section 3 of RFC 5331 [RFC5331]. 471 If the size of the VLSID is an integer fraction (N) of a 128-bit SRv6 472 SID, multiple (N) VLSIDs may be combined to encode a 128-bit SID. 473 This may be useful to encode an SRv6 service SID, for example to 474 provide a VPN service. (Even though the VPN SID may also choosen to 475 be encoded as a VLSID is the size of the VLSID is large enough). 477 8. IANA Considerations 479 TBD. 481 9. Security Considerations 483 This document does not change the security considerations of SRv6. 484 Please refers to RFC 8402 [RFC8402], 485 [I-D.ietf-6man-segment-routing-header] and 486 [I-D.ietf-spring-srv6-network-programming] for existing security 487 consideration. 489 10. Acknowledgements 491 This document has been inspired by the work of the SPRING WG and in 492 particular the work done in 493 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] and 494 [I-D.li-spring-compressed-srv6-np]. The author would like to 495 acknowledge the authors of these two documents. 497 11. Changes / Author Notes 499 [RFC Editor: Please remove this section before publication] 501 00: Initial version. 503 12. References 505 12.1. Normative References 507 [I-D.ietf-6man-segment-routing-header] 508 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 509 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 510 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 511 progress), October 2019. 513 [I-D.ietf-spring-srv6-network-programming] 514 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 515 Matsushima, S., and Z. Li, "SRv6 Network Programming", 516 draft-ietf-spring-srv6-network-programming-08 (work in 517 progress), January 2020. 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, 521 DOI 10.17487/RFC2119, March 1997, 522 . 524 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 525 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 526 May 2017, . 528 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 529 Decraene, B., Litkowski, S., and R. Shakir, "Segment 530 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 531 July 2018, . 533 12.2. Informative References 535 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 536 Filsfils, C., Camarillo, P., Cai, D., Jiang, Z., Voyer, 537 D., Shawky, A., Leymann, N., Steinberg, D., Zandi, S., 538 Dawra, G., Meilik, I., Uttaro, J., Jalil, L., So, N., 539 Fiumano, M., and M. Khaddam, "Network Programming 540 extension: SRv6 uSID instruction", draft-filsfils-spring- 541 net-pgm-extension-srv6-usid-02 (work in progress), August 542 2019. 544 [I-D.li-spring-compressed-srv6-np] 545 Li, Z., Li, C., Peng, S., Wang, Z., and B. Liu, 546 "Compressed SRv6 Network Programming", draft-li-spring- 547 compressed-srv6-np-00 (work in progress), July 2019. 549 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 550 Label Assignment and Context-Specific Label Space", 551 RFC 5331, DOI 10.17487/RFC5331, August 2008, 552 . 554 Author's Address 556 Bruno Decraene 557 Orange 559 Email: bruno.decraene@orange.com