idnits 2.17.1 draft-kompella-mpls-mspl4fa-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 date (July 12, 2021) is 1017 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-02 ** Downref: Normative reference to an Informational draft: draft-bestbar-teas-ns-packet (ref. 'I-D.bestbar-teas-ns-packet') == Outdated reference: A later version (-04) exists of draft-kompella-mpls-nffrr-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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. Beeram 4 Intended status: Standards Track T. Saad 5 Expires: January 13, 2022 Juniper Networks 6 I. Meilik 7 Broadcom 8 July 12, 2021 10 Multi-purpose Special Purpose Label for Forwarding Actions 11 draft-kompella-mpls-mspl4fa-01 13 Abstract 15 A Slice Selector is packet metadata that dictates the packet's 16 forwarding handling in order to conform to its slice requirements. 17 There are multiple proposals for carrying slice selectors in MPLS 18 networks. One of the more practical proposals is the "Global 19 Identifier for Slice Selector" (GISS). Global uniqueness requires 20 the GISS label be identified as such, via a special purpose label 21 (ideally a base special purpose label (bSPL)). However, bSPLs are a 22 precious commodity, and there are many requests for them. This 23 document serves two purposes: to define a bSPL for carrying a GISS, 24 and to show how this bSPL can consolidate many current requests for 25 special purpose labels while carrying associated data compactly and 26 efficiently. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 13, 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Revision History . . . . . . . . . . . . . . . . . . . . 3 65 1.2.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 3 66 1.3. Slice Selector . . . . . . . . . . . . . . . . . . . . . 4 67 2. Multi-purpose bSPL: the Forwarding Actions Indicator . . . . 4 68 2.1. The FAI bSPL . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1.1. LS FAD vs PL FAD . . . . . . . . . . . . . . . . . . 5 70 2.2. Format of the FAI bSPL . . . . . . . . . . . . . . . . . 5 71 2.2.1. Definitions of the FAI Flag Bits . . . . . . . . . . 6 72 2.2.2. Processing the FAI Flags and the LS FAD . . . . . . . 7 73 2.2.3. Example of the FAI . . . . . . . . . . . . . . . . . 8 74 3. Issues to be Resolved . . . . . . . . . . . . . . . . . . . . 9 75 3.1. Preventing FAI From Reaching Top of Stack . . . . . . . . 9 76 3.2. Repeating the FAI at "Readable Stack Depth" . . . . . . . 10 77 3.3. PL FAD . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 79 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 8.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Network slicing is an important ongoing effort both for network 90 design, as well as for standardization, in particular at the IETF 91 [I-D.nsdt-teas-ns-framework]. A key issue is identifying which slice 92 a packet belongs to, by means of a "slice selector" carried in the 93 packet header. [I-D.bestbar-teas-ns-packet] describes several such 94 methods for MPLS networks, of which the Global Identifier for Slice 95 Selector (GISS) is one of the more practical solutions. This 96 document shows how to realize the GISS using a base special purpose 97 label (bSPL). 99 Base Special Purpose Labels are a precious commodity; there are only 100 16 such values, of which 8 have already been allocated. There are 101 currently five requests for bSPLs that the authors are aware of; this 102 document proposes another use case for a bSPL, in all consuming 103 nearly all the remaining values. Therefore, this document also 104 suggests a method whereby a single bSPL can be used for all the 105 purposes currently documented. This leads to perhaps the more 106 valuable long-term contribution of this document: an approach to the 107 definition and use of bSPLs (and SPLs in general) whereby a single 108 value can be used for multiple purposes, and provide a flexible and 109 efficient means of carrying associated data. 111 1.1. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 1.2. Revision History 121 This section (to be removed before publication) highlights the 122 draft's revision history. 124 1.2.1. Changes from -00 to -01 126 1. This section added. 128 2. Added a section discussing when data should be put in the LS FAD 129 vs in the PL FAD. 131 3. Tweaked the bits in the FAI. Added a field "edist". 133 4. Elaborated on the use of the H bit and the FAH data. 135 5. Updated the processing of the LS FAD. 137 6. Added processing of edist. 139 7. Updated the FAI example. 141 8. Updated the Issues section. 143 1. 145 1.3. Slice Selector 147 In MPLS networks, a GISS is a data plane construct identifying 148 packets belonging to a slice aggregate (the set of packets that 149 belong to the slice). The GISS dictates forwarding actions for the 150 slice aggregate: QoS behavior and next hop selection. The purpose of 151 the GISS is detailed in [I-D.bestbar-teas-ns-packet]. To embed a 152 GISS in a label stack, one must preface it with a bSPL identifying it 153 as such. For reasons that will become apparent, this bSPL is called 154 the Forwarding Actions Indicator (FAI). 156 2. Multi-purpose bSPL: the Forwarding Actions Indicator 158 This document proposes the use of a single bSPL to tell routers one 159 or more forwarding actions they should take on a packet, e.g.: 161 o to treat a packet according to its slice, given its GISS; 163 o to load balance a packet, given its entropy; 165 o whether or not to perform fast reroute on a failure 166 [I-D.kompella-mpls-nffrr]; 168 o whether or not a packet has a Flow ID; 170 o whether or not a packet has metadata relevant to intermediate hops 171 along the path; 173 o a faster way of finding the End of Stack; 175 o and perhaps other functions in the future. 177 This bSPL is called the "Forwarding Actions Indicator" (FAI). The 178 FAI uses the label's TC bits and TTL field to inform the forwarding 179 plane of the required actions. Each of these actions may have 180 associated data, the Forwarding Actions Data (FAD). The FAD may be 181 carried in the Label Stack (LS FAD) or in the payload (PL FAD). 183 2.1. The FAI bSPL 185 The design of the bSPL hinges on a key insight: forwarding engines do 186 not interpret the TC bits or the TTL field for labels that are not at 187 the top of the label stack (ToS). For non-ToS labels, the important 188 bit fields are the label value field (to compute entropy and identify 189 SPLs) and the End of Stack (S) bit (to know when the label stack 190 ends). [If you know of a forwarding engine that looks at other bit 191 fields of labels below the ToS, please contact the authors.] This 192 means that for a bSPL that will never appear at the ToS, the TC bits 193 and the TTL bits can be used to carry additional information. 194 Furthermore, for the LS FAD, the entire 4-octet label word, the S bit 195 excepted, can be used to carry data. We use this technique to make 196 the FAI bSPL multipurpose, and to make the LS FAD words compact and 197 efficient. 199 2.1.1. LS FAD vs PL FAD 201 A pertinent question is whether one should put non-label data in the 202 label stack. The alternative is to put all such data in the PL FAD. 203 However, this would mean that accessing such information would 204 require finding the End of Stack, and parsing the PL FAD. For 205 certain types of data, this would be a severe burden on the packet 206 forwarding engine. Examples of such data are the Entropy label 207 (needed for efficient load balancing), the GISS (needed for accurate 208 packet forwarding) and the Flow ID (needed for telemetry). Having 209 any of this data in the PL FAD would hurt forwarding performance. 211 This memo will document criteria for when data should be in the LS 212 FAD versus in the PL FAD. 214 2.2. Format of the FAI bSPL 215 0 1 2 3 216 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 217 TC S TTL 218 ----- --------------- 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | (previous forwarding label | TC |0| TTL | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Forwarding Actions Indicator |H|A|N|S|E G|F|h| edist | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | LS Forwarding Actions Header |S| | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | LS Forwarding Actions Data |S| | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | More LS FAD and/or other labels |S| | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | End of Stack label |1| | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |b b b b| Payload (potentially, PL FAD) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Payload | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 1: Format for FAI, LS FAD and PL FAD 239 The FAI's label value MUST be the IANA allocated value. The S bit 240 MUST be reflect whether the label stack ends at this label or not. 242 2.2.1. Definitions of the FAI Flag Bits 244 The TC and TTL bits are used as flags, defined as follows: 246 H: if set, the FAI is followed by a Forwarding Actions Header (FAH). 248 A: Associated data (LS FAD) is present (1) or not (0). 250 N: If set, do not do fast reroute (NFFRR). 252 S: MUST be set if the FAI is the end of stack, and clear otherwise. 254 EG: this is a 2-bit flag indicating whether the LS FAD carries 255 Entropy and/or GISS information. 257 F: If set, the LS FAD has a Flow ID. 259 h: If set, the PL FAD contains hop-by-hop information. Every node in 260 the path SHOULD attempt to process the hop-by-hop information, but 261 not at the expense of exceeding the processing time budget, which 262 could cause this (or other) packets to be dropped. 264 edist: ("distance to End of Stack") a 4-bit field that indicates how 265 many 4-octets labels to skip to reach End of Stack. 267 The FAH consists of a single 4-octet word, and is used if more FAD 268 flags are needed. As these bits are defined, processing of the 269 associated data MUST also be defined. The format of the FAH is TBD. 271 The EG field is used as follows: 273 00: No Entropy or GISS present 275 01: LS FAD 0 contains 16 bits of Entropy in the high order 16 bits 276 and 15 bits of GISS in the low order 16 bits (S bit excepted). 278 10: LS FAD 0 contains 20 bits of Entropy in the high order 20 bits 279 and 11 bits of GISS in the low order 12 bits (S bit excepted). 281 11: LS FAD 0 contains the 31-bit Entropy; LS FAD 1 contains the 282 31-bit GISS. In LS FAD 0, the S bit MUST be 0; the packet 283 forwarding engine may choose to use this as part of the Entropy, 284 as it doesn't affect the outcome. In LS FAD 1, the S bit may be 0 285 or 1. 287 2.2.2. Processing the FAI Flags and the LS FAD 289 Here's how the LS FAD is parsed. One must keep track of the S bit to 290 know when the stack ends. The LS FAD data appears in the order of 291 the corresponding flags. 293 It is an error if the label stack ends while there are more LS FAD 294 words to process. In particular, it is an error if the FAI's S bit 295 is set, but the H flag is set, or the A flag is set and any of EG or 296 F or edist is non-zero. 298 It is not an error if H, A, N, EG, F and h are all zero; however, in 299 that case, it's not clear what purpose the FAI serves. 301 1. Set CL ("current label") to the FAI label. LL is the last label 302 (End of Stack); PL ("payload") is the first 4-octet word of the 303 payload. 305 2. Process H: 307 1. If set, increment CL; process the FAH. 309 2. Otherwise, CL is unchanged. 311 3. If A is 0, done: there is no associated LS FAD. 313 4. Process N. CL is unchanged. 315 5. Process EG: 317 1. If EG is 00, CL is unchanged. 319 2. If EG is 01 or 10, increment CL. CL now contains both GISS 320 and Entropy. 322 3. If EG is 11, CL+1 contains Entropy; CL+2 contains GISS. 323 Increment CL by 2. 325 6. Process F: 327 1. If F is set; increment CL. CL contains the Flow ID. 329 7. Process edist: 331 1. LL = CL + edist 333 2. while LL's S bit == 0, LL++ 335 3. PL = LL+1 337 The edist field is used to expedite reaching the PL FAD (e.g., to 338 process hop-by-hop information). A forwarding engine can skip 339 forward edist 4-octet words, i.e., CL += edist. This word MUST be a 340 label, which may or may not have S = 1. If not, keep parsing until a 341 label with S = 1 is hit; this is the End of Stack. PL FAD follows 342 this label. 344 Details for parsing the PL FAD are outside the scope of this memo, 345 and will be addressed in the document describing its format. 347 2.2.3. Example of the FAI 348 0 1 2 3 349 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 350 TC S TTL 351 ----- --------------- 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Tunnel Label-1 | TC |0| TTL | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Tunnel Label-2 | TC |0| TTL | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Forwarding Actions Indicator |0|1|1|0|0 1|0|1|0 0 0 1| 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Entropy | GISS ... |0| ... | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | VPN Label |TC |1| TTL | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 |b b b b| PL FAD | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | real payload starts ... 367 H = 0; no FAH. 368 A = 1: there is LS FAD. 369 N = 1: NFFRR is set. 370 EG = 01: LS FAD 0 contains Entropy + GISS. 371 F = 0: No Flow ID. 372 h = 1: There is hop-by-hop PL FAD. 373 edist = 1: one more label to End of Stack. 375 Figure 2: Example of FAI + LS FAD + hop-by-hop PL FAD 377 The real payload starts after the PL FAD. 379 3. Issues to be Resolved 381 This section captures issues to be resolved, in this memo and others. 382 As the issues are fixed, they should be removed from here; ideally, 383 this section should be empty before publication. 385 3.1. Preventing FAI From Reaching Top of Stack 387 As was said earlier, the FAI MUST NOT be at the top of stack, since 388 its TC and TTL bits have been repurposed. There are two ways to 389 prevent this. If an LSR X pops a label and encounters an FAI, X can 390 pop the FAI and all LS FAD words. To do that, it must be able to 391 parse the FAI to determine how many LS FAD words there exist. This 392 can be used in conjunction with Section 3.2. However, there are 393 cases when it is desired to preserve the FAI+FAD until the egress. 394 In this case, X should push an explicit NULL (label value 0 or 2) 395 onto the stack above the FAI, with the correct TC and TTL values. 397 Other options will be pursued. 399 3.2. Repeating the FAI at "Readable Stack Depth" 401 For LSRs which cannot parse the entire label stack, or would prefer 402 not to unless needed, it is possible to repeat the FAI at "readable 403 stack depth", say every 4 labels. In the above case, the FAI+LS FAD 404 can be repeated every 4 labels; or a truncated version, just the FAI 405 with A set to 0 can be used. Only the last FAI would contain the 406 full information, reducing the burden on the label stack. However, 407 in this case, LSRs that don't process the whole stack may not load 408 balance less effectively, and potentially not adhere to the slice 409 service level objectives. 411 Other options will be described in future versions of this document. 413 3.3. PL FAD 415 The format of the PL FAD, whether or not a Control Word is present, 416 and handling of the first nibble, is outside the scope of this 417 document. The FAI will not contain details about the contents of the 418 PL FAD, besides the single flag on whether or not the PL FAD contains 419 information relevant to (most) intermediate hops. It is assumed that 420 another memo will document the format of the PL FAD, and that this 421 memo will provide a means of parsing the PL FAD (e.g., a TLV 422 structure) and thus determining its contents. 424 The PL FAD memo should also comment on the impact of processing the 425 PL FAD on forwarding performance, especially in the case of hop-by- 426 hop info. 428 4. Contributors 430 Many thanks to Colby Barth, Chandra Ramachandran and Srihari Sangli 431 for their contributions to this draft. 433 5. Acknowledgments 435 We'd like to acknowledge the helpful discussions with Swamy SRK and 436 folks from the Broadcom team on the impacts to existing and future 437 forwarding engines. 439 The edist field was added thanks to Haoyu Song, who suggested the 440 optimization to find End of Stack. 442 6. IANA Considerations 444 If this draft is deemed useful and adopted as a WG document, the 445 authors request the allocation of a bSPL for the FAI. We suggest the 446 early allocation of label 8 for this. 448 7. Security Considerations 450 A malicious or compromised LSR can insert the FAI and associated data 451 into a label stack, preventing (for example) FRR from occurring. If 452 so, protection will not kick in for failures that could have been 453 protected, and there will be unnecessary packet loss. Similarly, 454 inserting or removing a Fragmentation Header means that a packet's 455 contents cannot be accurately reconstructed. Inserting or changing a 456 GISS means that the packet will be misclassified, perhaps leaving or 457 entering a high-value slice and causing damage. 459 8. References 461 8.1. Normative References 463 [I-D.bestbar-teas-ns-packet] 464 Saad, T., Beeram, V. P., Wen, B., Ceccarelli, D., Halpern, 465 J., Peng, S., Chen, R., Liu, X., and L. M. Contreras, 466 "Realizing Network Slices in IP/MPLS Networks", draft- 467 bestbar-teas-ns-packet-02 (work in progress), February 468 2021. 470 [I-D.kompella-mpls-nffrr] 471 Kompella, K. and W. Lin, "No Further Fast Reroute", draft- 472 kompella-mpls-nffrr-01 (work in progress), November 2020. 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, 476 DOI 10.17487/RFC2119, March 1997, 477 . 479 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 480 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 481 May 2017, . 483 8.2. Informative References 485 [I-D.nsdt-teas-ns-framework] 486 Gray, E. and J. Drake, "Framework for IETF Network 487 Slices", draft-nsdt-teas-ns-framework-05 (work in 488 progress), February 2021. 490 Authors' Addresses 492 Kireeti Kompella 493 Juniper Networks 494 1133 Innovation Way 495 Sunnyvale, CA 94089 496 United States 498 Email: kireeti.ietf@gmail.com 500 Vishnu Pavan Beeram 501 Juniper Networks 502 1133 Innovation Way 503 Sunnyvale, CA 94089 504 United States 506 Email: vbeeram@juniper.net 508 Tarek Saad 509 Juniper Networks 510 1133 Innovation Way 511 Sunnyvale, CA 94089 512 United States 514 Email: tsaad@juniper.net 516 Israel Meilik 517 Broadcom 519 Email: israel.meilik@broadcom.com