idnits 2.17.00 (12 Aug 2021) /tmp/idnits5181/draft-kompella-mpls-mspl4fa-02.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 document date (8 February 2022) is 95 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) == Outdated reference: A later version (-10) exists of draft-bestbar-teas-ns-packet-07 ** Downref: Normative reference to an Informational draft: draft-bestbar-teas-ns-packet (ref. 'I-D.bestbar-teas-ns-packet') Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS WG K. Kompella 3 Internet-Draft V.P. Beeram 4 Intended status: Standards Track T. Saad 5 Expires: 12 August 2022 Juniper Networks 6 I. Meilik 7 Broadcom 8 8 February 2022 10 Multi-purpose Special Purpose Label for Forwarding Actions 11 draft-kompella-mpls-mspl4fa-02 13 Abstract 15 The MPLS architecture introduced Special Purpose Labels (SPLs) to 16 indicate special forwarding actions and offered a few simple 17 examples, such as Router Alert. In the two decades since the 18 original architecture was crafted, the range, complexity and sheer 19 number of such actions has grown; in addition, there now is need for 20 "associated data" for some of the forwarding actions. Likewise, the 21 capabilities and scale of forwarding engines has also improved vastly 22 over the same time period. There is a pressing need to match the 23 needs with the capabilities to deliver the next generation of MPLS 24 architecture. 26 In this memo, we propose an alternate mechanism whereby a single SPL 27 can encode multiple forwarding actions and carry associated data, 28 some in the label stack and some after the label stack. This 29 proposal also solves the problem of scarcity of base SPLs. 31 This approach can immediately address several use cases: 33 * to carry a Slice Selector for IETF network slicing; 35 * to signal that further fast reroute may have harmful consequences; 37 * to indicate that there is relevant data after the label stack; 39 * among others. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 12 August 2022. 58 Copyright Notice 60 Copyright (c) 2022 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Revised BSD License text as 69 described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Revised BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 76 1.2. Revision History . . . . . . . . . . . . . . . . . . . . 3 77 1.2.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 4 78 1.2.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 4 79 1.3. Slice Selector . . . . . . . . . . . . . . . . . . . . . 5 80 2. Multi-purpose bSPL: the Forwarding Actions Indicator . . . . 5 81 2.1. The FAI bSPL . . . . . . . . . . . . . . . . . . . . . . 6 82 2.1.1. ISD vs PSD . . . . . . . . . . . . . . . . . . . . . 6 83 2.2. Format of the FAI bSPL . . . . . . . . . . . . . . . . . 6 84 2.2.1. Definitions of the FAI Flag Bits . . . . . . . . . . 7 85 2.2.2. Processing the FAI Flags and the ISD . . . . . . . . 9 86 2.2.3. Example of the FAI . . . . . . . . . . . . . . . . . 9 87 3. Issues to be Resolved . . . . . . . . . . . . . . . . . . . . 10 88 3.1. Preventing FAI From Reaching Top of Stack . . . . . . . . 10 89 3.2. Repeating the FAI at "Readable Stack Depth" . . . . . . . 11 90 3.3. PSD . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 92 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 97 8.2. Informative References . . . . . . . . . . . . . . . . . 13 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 100 1. Introduction 102 Base Special Purpose Labels (bSPLs) are a precious commodity; there 103 are only 16 such values, of which 8 have already been allocated. 104 There are currently five requests for bSPLs that the authors are 105 aware of; this document proposes another use case for a bSPL, in all 106 consuming nearly all the remaining values. This document suggests a 107 method whereby a single bSPL can be used for all the purposes 108 currently requested. This leads to perhaps the more valuable long- 109 term contribution of this document: an approach to the definition and 110 use of bSPLs (and SPLs in general) whereby a single value can be used 111 for multiple purposes, and provide a flexible yet efficient means of 112 carrying associated data. 114 1.1. Conventions and Definitions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 FAI: Forwarding Actions Indicator 124 FFB: Forwarding Flags Block 126 ISD: In-Stack Data 128 sISD: Standard ISD 130 uISD: User-Defined ISD 132 PSD: Post-Stack Data 134 SPL: Special-purpose label 136 bSPL: Base special-purpose label 138 1.2. Revision History 140 This section (to be removed before publication) offers highlights 141 from the draft's revision history. 143 1.2.1. Changes from -00 to -01 145 1. This section added. 147 2. Added a section discussing when data should be put in the LS FAD 148 vs in the PL FAD. 150 3. Tweaked the bits in the FAI. Added a field "edist". 152 4. Elaborated on the use of the H bit and the FAH data. 154 5. Updated the processing of the LS FAD. 156 6. Added processing of edist. 158 7. Updated the FAI example. 160 8. Updated the Issues section. 162 1.2.2. Changes from -01 to -02 164 1. Updated Abstract and Introduction to focus on FAI; moved 165 description of use cases to separate section. 167 2. Added terminology. 169 3. Changed terminology: LS FAD and PL FAD to ISD and PSD, 170 respectively. 172 4. Updated text on criteria for putting associated data in ISD. 174 5. Introduced the terms FAI Block, FFB Block, sISD Block and uISD 175 Block. Introduced an "end of block" bit, s. Updated flag bits; 176 updated processing of ISD. 178 6. Removed field edist. 180 7. Updated the section on preventing the FAI from reaching the Top 181 of Stack. 183 8. Updated the section on Readable Stack Depth 185 1.3. Slice Selector 187 Network slicing is an important ongoing effort both for network 188 design, as well as for standardization, in particular at the IETF 189 [I-D.nsdt-teas-ns-framework]. A key issue is identifying which slice 190 a packet belongs to, by means of a "slice selector" carried in the 191 packet header. [I-D.bestbar-teas-ns-packet] describes several such 192 methods for MPLS networks, of which the Global Identifier for Slice 193 Selector (GISS) is one of the more practical solutions. This 194 document shows how to realize the GISS using a base special purpose 195 label (bSPL). 197 In MPLS networks, a GISS is a data plane construct identifying 198 packets belonging to a slice aggregate (the set of packets that 199 belong to the slice). The GISS dictates forwarding actions for the 200 slice aggregate: QoS behavior and next hop selection. The purpose of 201 the GISS is detailed in [I-D.bestbar-teas-ns-packet]. To embed a 202 GISS in a label stack, one must preface it with a bSPL identifying it 203 as such. For reasons that will become apparent, this bSPL is called 204 the Forwarding Actions Indicator (FAI). 206 2. Multi-purpose bSPL: the Forwarding Actions Indicator 208 This document proposes the use of a single bSPL to tell routers one 209 or more forwarding actions they should take on a packet, e.g.: 211 * to treat a packet according to its slice, given its GISS; 213 * to load balance a packet, given its entropy; 215 * whether or not to perform fast reroute on a failure 216 [I-D.kompella-mpls-nffrr]; 218 * whether or not a packet has metadata relevant to intermediate hops 219 along the path; 221 * and perhaps other functions in the future. 223 This bSPL is called the "Forwarding Actions Indicator" (FAI). There 224 are other suggestions for this name, including "Network Functions 225 Indicator" and "Network Actions Indicator". We'll let WG consensus 226 determine the final choice of name, but for now, we'll continue to 227 use FAI. 229 The FAI uses the label's TC bits and TTL field to inform the 230 forwarding plane of the required actions. Each of these actions may 231 have associated data. This data may be carried in the label stack as 232 "In-Stack Data" (ISD) or after the label stack as "Post-Stack Data" 233 (PSD). 235 2.1. The FAI bSPL 237 The design of the bSPL hinges on two key insights: forwarding engines 238 do not interpret the TC bits or the TTL field for labels that are not 239 at the top of the label stack (ToS); nor do they do so for SPLs. For 240 non-ToS labels, the important bit fields are the label value field 241 (to compute entropy and identify SPLs) and the End of Stack (S) bit 242 (to know when the label stack ends). [If you know of a forwarding 243 engine that looks at other bit fields of labels below the ToS, please 244 contact the authors.] This means that for a bSPL that will never 245 appear at the ToS, the TC bits and the TTL bits can be used to carry 246 additional information. Furthermore, for the ISD, the entire 4-octet 247 label word, the S bit excepted, can be used to carry data. We use 248 this technique to make the FAI bSPL multipurpose, and to make the ISD 249 words compact and efficient. 251 2.1.1. ISD vs PSD 253 A pertinent question is when one should put data in the ISD versus in 254 the PSD. One alternative is to put all such data in the PSD. 255 However, this would mean that accessing such information would 256 require finding the End of Stack, and parsing the PSD. For certain 257 types of data, this would be a severe burden on the packet forwarding 258 engine. Examples of such data are the Entropy label (needed for 259 efficient load balancing) and the GISS (needed for accurate packet 260 forwarding). Having any of this data in the PSD would hurt 261 forwarding performance. 263 This memo suggests that data that is required for accurate and 264 optimal forwarding should be put in the ISD, and data that is 265 optional from a forwarding point of view should be put in the PSD. 266 Furthermore, each flag bit should have no more than one word of 267 associated ISD. The EG flag can thus have up to 2 words of 268 associated data. 270 By the above criteria, this memo suggests that in-situ OAM data and 271 the Flow ID be carried in the PSD. 273 2.2. Format of the FAI bSPL 274 0 1 2 3 275 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 276 TC b S TTL 277 ----- --------------- 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | (previous forwarding label | TC |0| TTL | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Forwarding Actions Indicator |s|u|0|0|h|N|E G|x|y|z|a| 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Forwarding Actions Header |0|0| | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Forwarding Actions Header |1|0| | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Standard In-Stack Data (sISD) |0|0| | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Last word of sISD |1|0| | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | User-defined ISD (uISD) |0|0| | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Last word of User-defined ISD |1|0| | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Other labels |0| | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | End of Stack label |1| | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |b b b b| Payload (potentially, PSD) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Payload | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 1: Format for FAI, ISD and PSD 306 The FAI's label value MUST be the IANA allocated value. The S bit 307 MUST be reflect whether the label stack ends at this label or not. 309 2.2.1. Definitions of the FAI Flag Bits 311 The TC and TTL bits are used as flags, defined as follows: 313 s: sISD is present (1) or not (0). 315 u: uISD is present (1) or not (0). 317 b: this is the "end of block" bit that indicates the end of the 318 Forwarding Flags Block and the end of the ISD Block. 320 S: MUST be set if the FAI is the end of stack, and clear otherwise. 322 h: If set, the PSD contains hop-by-hop information. Every node in 323 the path SHOULD attempt to process the hop-by-hop information, but 324 not at the expense of exceeding the processing time budget, which 325 could cause this (or other) packets to be dropped. If clear, no 326 hop-by-hop data exists in the PSD: either the PSD is empty, or it 327 contains only end-to-end data (to be processed by the egress). 329 N: If set, do not do fast reroute (NFFRR). 331 EG: this is a 2-bit flag indicating whether the ISD carries Entropy 332 and/or GISS information. 334 The FAI Block consists of a Forwarding Flags Block, an sISD Block and 335 a uISD Block. The two ISD Blocks are optional; their presence is 336 indicated by the s and u bits. Each of these three blocks end when 337 the b bit is set. 339 The Forwarding Flags Block extends from the FAI bSPL up to (and 340 including) the first label that has the b bit set. If the FFB 341 consists of just the bSPL, then its b bit must be set. 343 The sISD Block extends from the label after the FFB up to (and 344 including) the label with the b bit set. If there is no sISD, the s 345 bit in the FFB MUST be clear. 347 The uISD Block extends from the label after the sISD Block up to (and 348 including) the label with the b bit set. If there is no uISD, the u 349 bit in the FFB MUST be clear. 351 The EG field is used as follows: 353 00: No Entropy or GISS present 355 01: ISD 0 contains 16 bits of Entropy in the high order 16 bits and 356 14 bits of GISS in the low order 16 bits (S and b bits excepted). 358 10: ISD 0 contains 20 bits of Entropy in the high order 20 bits and 359 10 bits of GISS in the low order 12 bits (S and b bits excepted). 361 11: ISD 0 contains the 30-bit Entropy; ISD 1 contains the 30-bit 362 GISS. In ISD 0, the S and b bits MUST be 0; the packet forwarding 363 engine may choose to use the S and b bits as part of the Entropy, 364 as it doesn't affect the outcome. In ISD 1, the S bit may be 0 or 365 1. 367 2.2.2. Processing the FAI Flags and the ISD 369 Here's how the Standard ISD is parsed. One must keep track of the s 370 bit to know when the Standard ISD Block end, and the S bit to know 371 when the stack ends. The Standard ISD data appears in the order of 372 the corresponding flags. 374 It is an error if the label stack ends while there are more ISD words 375 to process. In particular, it is an error if the FAI's S bit is set, 376 but the b bit is clear. 378 1. If s and u are both 0, done: there is no associated ISD. 380 2. Set CL ("current label") to the FAI label. LL is the last label 381 (End of Stack); PL ("payload") is the first 4-octet word of the 382 payload. 384 3. While b is clear: 386 1. increment CL 388 4. Process N. CL is unchanged. 390 5. If s is set, Standard ISD is present: process standard flags. 392 1. Process EG: 394 2. If EG is 00, CL is unchanged. 396 3. If EG is 01 or 10, increment CL. CL now contains both GISS 397 and Entropy. 399 4. If EG is 11, CL+1 contains Entropy; CL+2 contains GISS. 400 Increment CL by 2. 402 5. Process other standard data-bearing flags; increment CL by 1 403 for each. 405 6. If u is set, uISD is present. 407 1. Process uISD until b is set. 409 Note that how the uISD is used is not defined here; this is up to the 410 user. All that is included here is how a forwarding engine can tell 411 where the uISD block ends. 413 2.2.3. Example of the FAI 414 0 1 2 3 415 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 416 TC b S TTL 417 ----- --------------- 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Tunnel Label-1 | TC |0| TTL | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Tunnel Label-2 | TC |0| TTL | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Forwarding Actions Indicator |1|1|1|0|1|1|0|1|0|0|0|0| 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Entropy | GISS ...|1|0| ... | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | VPN Label |TC |1| TTL | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 |b b b b| PSD | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | real payload starts ... 433 s = 1: there is standard ISD. 434 u = 0: there is no user-defined ISD. 435 N = 1: NFFRR is set. 436 EG = 01: ISD 0 contains Entropy + GISS. 437 h = 1: There is hop-by-hop PSD. 439 Figure 2: Example of FAI + ISD + hop-by-hop PSD 441 The real payload starts after the PSD. 443 3. Issues to be Resolved 445 This section captures issues to be resolved, in this memo and others. 446 As the issues are fixed, they should be removed from here; ideally, 447 this section should be empty before publication. 449 3.1. Preventing FAI From Reaching Top of Stack 451 As was said earlier, the FAI MUST NOT be at the top of stack, since 452 its TC and TTL bits have been repurposed. There are two ways to 453 prevent this. If an LSR X pops a label and the next label is the 454 FAI, X can pop the FAI and all ISD words. This version of the memo 455 introduces the "end-of-block" (s) bit, whereby a forwarding engine 456 that knows the FAI can detect the entire FAI block, even if it 457 doesn't know some of the flags. This can be used in conjunction with 458 Section 3.2. 460 In case it is desired to preserve the FAI+FAD until the egress, X 461 should push an explicit NULL (label value 0 or 2) onto the stack 462 above the FAI, with the correct TC and TTL values. 464 Other options may be pursued; however, we believe this is an adequate 465 resolution. 467 3.2. Repeating the FAI at "Readable Stack Depth" 469 For LSRs which cannot parse the entire label stack, or would prefer 470 not to unless needed, it is possible to repeat the FAI at "readable 471 stack depth" (rsd). Say the rsd is 10 labels, and the FAI block is 3 472 labels. Then, the FAI block can be repeated every 7 labels, allowing 473 all forwarding engines in the path to process it. When a forwarding 474 label is popped and the FAI block exposed, it is deleted in its 475 entirety, since the same (or potentially different) FAI block is 476 again within the rsd. 478 Note that the s or u bits set to 0 can be used to indicate that the 479 corresponding ISD is absent. Only the last FAI would contain the 480 full information, reducing the size of the label stack. However, in 481 this case, LSRs that don't process the whole stack may not load 482 balance less effectively, and potentially not adhere to the slice 483 service level objectives. 485 Other options will be described in future versions of this document. 487 3.3. PSD 489 The format of the PSD, whether or not a Control Word is present, and 490 handling of the first nibble, is outside the scope of this document. 491 The FAI will not contain details about the contents of the PSD, 492 besides the single flag on whether or not the PSD contains 493 information relevant to (most) intermediate hops. It is assumed that 494 another memo will document the format of the PSD, and that that memo 495 will provide a means of parsing the PSD (e.g., a TLV structure) and 496 thus determining its contents. 498 The PSD memo should also comment on the impact of processing the PSD 499 on forwarding performance, especially in the case of hop-by-hop info. 501 4. Contributors 503 Many thanks to Colby Barth, Chandra Ramachandran and Srihari Sangli 504 for their contributions to this draft. 506 5. Acknowledgments 508 We'd like to acknowledge the helpful discussions with Swamy SRK and 509 folks from the Broadcom team on the impacts to existing and future 510 forwarding engines. 512 The edist field was added thanks to Haoyu Song, who suggested the 513 optimization to find End of Stack. 515 6. IANA Considerations 517 If this draft is deemed useful and adopted as a WG document, the 518 authors request the allocation of a bSPL for the FAI. We suggest the 519 early allocation of label 8 for this. 521 7. Security Considerations 523 A malicious or compromised LSR can insert the FAI and associated data 524 into a label stack, preventing (for example) FRR from occurring. If 525 so, protection will not kick in for failures that could have been 526 protected, and there will be unnecessary packet loss. Similarly, 527 inserting or removing a Fragmentation Header means that a packet's 528 contents cannot be accurately reconstructed. Inserting or changing a 529 GISS means that the packet will be misclassified, perhaps leaving or 530 entering a high-value slice and causing damage. 532 8. References 534 8.1. Normative References 536 [I-D.bestbar-teas-ns-packet] 537 Saad, T., Beeram, V. P., Wen, B., Ceccarelli, D., Halpern, 538 J., Peng, S., Chen, R., Liu, X., Contreras, L. M., Rokui, 539 R., and L. Jalil, "Realizing Network Slices in IP/MPLS 540 Networks", Work in Progress, Internet-Draft, draft- 541 bestbar-teas-ns-packet-07, 11 January 2022, 542 . 545 [I-D.kompella-mpls-nffrr] 546 Kompella, K. and W. Lin, "No Further Fast Reroute", Work 547 in Progress, Internet-Draft, draft-kompella-mpls-nffrr-02, 548 12 July 2021, . 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, 553 DOI 10.17487/RFC2119, March 1997, 554 . 556 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 557 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 558 May 2017, . 560 8.2. Informative References 562 [I-D.nsdt-teas-ns-framework] 563 Gray, E. and J. Drake, "Framework for IETF Network 564 Slices", Work in Progress, Internet-Draft, draft-nsdt- 565 teas-ns-framework-05, 2 February 2021, 566 . 569 Authors' Addresses 571 Kireeti Kompella 572 Juniper Networks 573 1133 Innovation Way 574 Sunnyvale, CA 94089 575 United States 577 Email: kireeti.ietf@gmail.com 579 Vishnu Pavan Beeram 580 Juniper Networks 581 1133 Innovation Way 582 Sunnyvale, CA 94089 583 United States 585 Email: vbeeram@juniper.net 587 Tarek Saad 588 Juniper Networks 589 1133 Innovation Way 590 Sunnyvale, CA 94089 591 United States 593 Email: tsaad@juniper.net 594 Israel Meilik 595 Broadcom 597 Email: israel.meilik@broadcom.com