idnits 2.17.1 draft-kompella-mpls-mspl4fa-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 date (February 22, 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-bestbar-teas-ns-packet-01 ** Downref: Normative reference to an Informational draft: draft-bestbar-teas-ns-packet (ref. 'I-D.bestbar-teas-ns-packet') == Outdated reference: A later version (-06) exists of draft-gandhi-mpls-ioam-sr-05 == Outdated reference: A later version (-04) exists of draft-kompella-mpls-nffrr-01 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 Summary: 1 error (**), 0 flaws (~~), 5 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: August 26, 2021 Juniper Networks 6 I. Meilik 7 Broadcom 8 February 22, 2021 10 Multi-purpose Special Purpose Label for Forwarding Actions 11 draft-kompella-mpls-mspl4fa-00 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 August 26, 2021. 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. Slice Selector . . . . . . . . . . . . . . . . . . . . . 3 65 2. Multi-purpose bSPL: the Forwarding Actions Indicator . . . . 3 66 2.1. The FAI bSPL . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Issues to be Resolved . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Preventing FAI From Reaching Top of Stack . . . . . . . . 7 69 3.2. Repeating the FAI at "Readable Stack Depth" . . . . . . . 8 70 3.3. First Nibble Issues . . . . . . . . . . . . . . . . . . . 8 71 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 8.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 Network slicing is an important ongoing effort both for network 83 design, as well as for standardization, in particular at the IETF 84 [I-D.nsdt-teas-ns-framework]. A key issue is identifying which slice 85 a packet belongs to, by means of a "slice selector" carried in the 86 packet header. [I-D.bestbar-teas-ns-packet] describes several such 87 methods for MPLS networks, of which the Global Identifier for Slice 88 Selector (GISS) is one of the more practical solutions. This 89 document shows how to realize the GISS using a base special purpose 90 label (bSPL). 92 Base Special Purpose Labels are a precious commodity; there are only 93 16 such values, of which 8 have already been allocated. There are 94 currently five requests for bSPLs that the authors are aware of; this 95 document proposes another use case for a bSPL, in all consuming 96 nearly all the remaining values. Therefore, this document also 97 suggests a method whereby a single bSPL can be used for all the 98 purposes currently documented. This leads to perhaps the more 99 valuable long-term contribution of this document: an approach to the 100 definition and use of bSPLs (and SPLs in general) whereby a single 101 value can be used for multiple purposes, and provide a flexible and 102 efficient means of carrying associated data. 104 1.1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 1.2. Slice Selector 114 In MPLS networks, a GISS is a data plane construct identifying 115 packets belonging to a slice aggregate (the set of packets that 116 belong to the slice). The GISS dictates forwarding actions for the 117 slice aggregate: QoS behavior and next hop selection. The purpose of 118 the GISS is detailed in [I-D.bestbar-teas-ns-packet]. To embed a 119 GISS in a label stack, one must preface it with a bSPL identifying it 120 as such. For reasons that will become apparent, this bSPL is called 121 the Forwarding Actions Indicator (FAI). 123 2. Multi-purpose bSPL: the Forwarding Actions Indicator 125 This document proposes the use of a single bSPL to tell routers one 126 or more forwarding actions they should take on a packet, e.g.: 128 o to treat a packet according to its slice, given its GISS; 130 o to load balance a packet, given its entropy; 132 o whether or not to perform fast reroute on a failure 133 [I-D.kompella-mpls-nffrr]; 135 o whether or not the packet has a Flow ID; 137 o to update statistics based on the path identifier 138 [I-D.hegde-spring-traffic-accounting-for-sr-paths]; 140 o to view/update OAM metadata; 141 [I-D.cheng-mpls-inband-pm-encapsulation], 142 [I-D.gandhi-mpls-ioam-sr], other approaches. 144 o to reassemble a fragmented packet 145 [I-D.zzhang-tsvwg-generic-transport-functions]; 147 o and perhaps other functions in the future. 149 This bSPL is called the "Forwarding Actions Indicator" (FAI). The 150 FAI uses the label's TC bits and TTL field to inform the forwarding 151 plane of the required actions. Each of these actions may have 152 associated data, the Forwarding Actions Data (FAD). The FAD may be 153 carried in the Label Stack (LS FAD) or in the payload (PL FAD). 155 2.1. The FAI bSPL 157 The design of the bSPL hinges on a key insight: for labels not at the 158 top of the label stack, the only bits that a forwarding engine looks 159 at are the label value field (to compute entropy and identify SPLs) 160 and the End of Stack (S) bit (to know when the label stack ends). 161 [If you know of a forwarding engine that looks at other bits of 162 labels below the top of stack, please contact the authors.] This 163 means that for a bSPL that will never appear at the top of stack, the 164 TC bits and the TTL bits can be used to carry additional information. 165 Furthermore, for the LS FAD, the entire 4-octet label word, the S bit 166 excepted, can be used to carry data. We use this technique to make 167 the FAI bSPL multipurpose, and to make the FAD words compact and 168 efficient. 170 0 1 2 3 171 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 172 TC S TTL 173 ----- --------------- 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | (previous forwarding label | TC |0| TTL | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Forwarding Actions Indicator |H|E G|S|N|F|Q|O A M|P f| 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | LS Forwarding Actions Data |S| | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | More LS FAD and/or other labels |S| | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Bottom of stack label |1| | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 |b b b b| Payload (potentially, PL FAD) | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Payload | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 1: Format for FAI, LS FAD and PL FAD 192 The FAI's label value MUST be the IANA allocated value. The S bit 193 MUST be reflect whether the label stack ends at this label or not. 195 The TC and TTL bits are used as flags, defined as follows: 197 H: if set, the FAI is followed by a Forwarding Actions Header (FAH). 199 EG: this is a 2-bit flag indicating whether the LS FAD carries 200 Entropy and/or GISS information. 202 S: MUST be set if the FAI is the end of stack, and clear otherwise. 204 N: If set, do not do fast reroute (NFFRR). 206 F: If set, the LS has a Flow ID. 208 Q: if set, the payload contains Opaque data. 210 OAM: a 3-bit field that specifies what type(s) of OAM is carried in 211 the in the label stack and/or payload. 213 P: If set, the PL FAD contains a Path Identifier. 215 F: If set, the payload contains a Fragmentation Header. 217 The EG field is used as follows: 219 00: No Entropy or GISS present 221 01: LS FAD 0 contains 16 bits of Entropy in the high order 16 bits 222 and 15 bits of GISS in the low order 16 bits (S bit excepted). 224 10: LS FAD 0 contains 20 bits of Entropy in the high order 20 bits 225 and 11 bits of GISS in the low order 12 bits (S bit excepted). 227 11: LS FAD 0 contains the 31-bit Entropy; LS FAD 1 contains the 228 31-bit GISS. In LS FAD 0, the S bit MUST be 0; the packet 229 forwarding engine may choose to use this as part of the Entropy, 230 as it doesn't affect the outcome. In LS FAD 1, the S bit may be 0 231 or 1. 233 Here's how the LS FAD is parsed. One must keep track of the S bit to 234 know when the stack ends. It is an error if the label stack ends 235 while there are more PL FAD words to process. 237 1. Set NL ("next label") to the first 4-octet word of the LS FAD. 238 Set PL ("payload") to the first 4-octet word of the payload. 240 2. Process H: if set, (TBD); otherwise, NL is unchanged. 242 3. Process EG: 244 1. If EG is 00, NL is unchanged. 246 2. If EG is 01 or 10, NL contains both GISS and Entropy. 247 Increment NL. 249 3. If EG is 11, NL contains GISS; NL+1 contains Entropy. 250 Increment NL by 2. 252 4. Process N. NL is unchanged. 254 5. Process F: 256 1. If F is set, NL contains the Flow ID; increment NL. 258 6. Process Q: 260 1. If set, (TBD); otherwise, NL is unchanged. 262 7. NL now points at next label in the stack. 264 A similar procedure applies to parsing the PL; details will be 265 forthcoming when the OAM field is better defined. 267 0 1 2 3 268 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 269 TC S TTL 270 ----- --------------- 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Tunnel Label-1 | MBZ |0| MBZ | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Tunnel Label-2 | MBZ |0| MBZ | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Forwarding Actions Indicator |0|0 1|0|1|0|0|0 0 0|0 1| 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Entropy | GISS ... |0| ... | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | VPN Label |MBZ |1| MBZ | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |b b b b| Fragmentation Header ... | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | real payload starts ... 286 H = 0; ignore. 287 EG = 01: LS FAD 0 contains Entropy + GISS. 288 N = 1: NFFRR is set. 289 F = 0: No Flow ID. 290 Q = 0: ignore. 291 OAM = 0; ignore. 292 P = 0: no Path Identifier in payload. 293 F = 1: Fragmentation Header is present. 295 Figure 2: Example of FAI + LS FAD + PL FAD 297 The real payload starts after the Fragmentation Header. 299 3. Issues to be Resolved 301 3.1. Preventing FAI From Reaching Top of Stack 303 As was said earlier, the FAI MUST NOT be at the top of stack, since 304 its TC and TTL bits have been repurposed. There are two ways to 305 prevent this. If an LSR X pops a label and encounters an FAI, X can 306 pop the FAI and all LS FAD words. To do that, it must be able to 307 parse the FAI to determine how many LS FAD words there exist. This 308 can be used in conjunction with Section 3.2. However, there are 309 cases when it is desired to preserve the FAI+FAD until the egress. 310 In this case, X should push an explicit NULL (label value 0 or 2) 311 onto the stack above the FAI, with the correct TC and TTL values. 313 Other options will be pursued. 315 3.2. Repeating the FAI at "Readable Stack Depth" 317 For LSRs which cannot parse the entire label stack, or would prefer 318 not to unless needed, it is possible to repeat the FAI at "readable 319 stack depth", say every 4 labels. In the above case, the FAI+LS FAD 320 can be repeated every 4 labels; or a truncated version, just the FAD 321 with GE set to 00 can be used. Only the last FAI would contain the 322 full information, reducing the burden on the label stack. However, 323 in this case, LSRs that don't process the whole stack may not load 324 balance less effectively, and potentially not adhere to the slice 325 service level objectives. 327 Other options will be described in future versions of this document. 329 3.3. First Nibble Issues 331 The first nibble of the first word of the payload SHOULD NOT be 0x4 332 or 0x6, as legacy LSRs may use the heuristic that this indicates a 333 payload of IPv4/IPPv6. iOAM data has a first nibble of 0x1. 334 However, if there is no iOAM data, the first nibble of the Path 335 Identifier, if any, else that of the Fragmentation Header, MUST NOT 336 be 0x4 or 0x6. However, it is inefficient to have to address this 337 issue for every type of PL FAD, as it may be the first word in the 338 payload. A future version of this document will propose an 339 alternative solution. 341 It is unclear when a Control Word may be present as the first word of 342 the payload; this is sometimes signaled and sometimes configured. 343 When it is present, the above issue is moot. 345 4. Contributors 347 Many thanks to Colby Barth, Chandra Ramachandran and Srihari Sangli 348 for their contributions to this draft. 350 5. Acknowledgments 352 We'd like to acknowledge the helpful discussions with Swamy SRK. 354 6. IANA Considerations 356 If this draft is deemed useful and adopted as a WG document, the 357 authors request the allocation of a bSPL for the FAI. We suggest the 358 early allocation of label 8 for this. 360 7. Security Considerations 362 A malicious or compromised LSR can insert the FAI and associated data 363 into a label stack, preventing (for example) FRR from occurring. If 364 so, protection will not kick in for failures that could have been 365 protected, and there will be unnecessary packet loss. Similarly, 366 inserting or removing a Fragmentation Header means that a packet's 367 contents cannot be accurately reconstructed. Inserting or changing a 368 GISS means that the packet will be misclassified, perhaps leaving or 369 entering a high-value slice and causing damage. 371 8. References 373 8.1. Normative References 375 [I-D.bestbar-teas-ns-packet] 376 Saad, T., Beeram, V., Wen, B., Ceccarelli, D., Halpern, 377 J., Peng, S., Chen, R., and X. Liu, "Realizing Network 378 Slices in IP/MPLS Networks", draft-bestbar-teas-ns- 379 packet-01 (work in progress), December 2020. 381 [I-D.cheng-mpls-inband-pm-encapsulation] 382 Cheng, W., Min, X., Zhou, T., Dong, X., and Y. Peleg, 383 "Encapsulation For MPLS Performance Measurement with 384 Alternate Marking Method", draft-cheng-mpls-inband-pm- 385 encapsulation-04 (work in progress), September 2020. 387 [I-D.gandhi-mpls-ioam-sr] 388 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 389 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 390 OAM Data", draft-gandhi-mpls-ioam-sr-05 (work in 391 progress), January 2021. 393 [I-D.hegde-spring-traffic-accounting-for-sr-paths] 394 Hegde, S., "Traffic Accounting for MPLS Segment Routing 395 Paths", draft-hegde-spring-traffic-accounting-for-sr- 396 paths-02 (work in progress), October 2018. 398 [I-D.kompella-mpls-nffrr] 399 Kompella, K. and W. Lin, "No Further Fast Reroute", draft- 400 kompella-mpls-nffrr-01 (work in progress), November 2020. 402 [I-D.zzhang-tsvwg-generic-transport-functions] 403 Zhang, Z., Bonica, R., and K. Kompella, "Generic Transport 404 Functions", draft-zzhang-tsvwg-generic-transport- 405 functions-00 (work in progress), November 2020. 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, 409 DOI 10.17487/RFC2119, March 1997, 410 . 412 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 413 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 414 May 2017, . 416 8.2. Informative References 418 [I-D.nsdt-teas-ns-framework] 419 Gray, E. and J. Drake, "Framework for Transport Network 420 Slices", draft-nsdt-teas-ns-framework-04 (work in 421 progress), July 2020. 423 Authors' Addresses 425 Kireeti Kompella 426 Juniper Networks 427 1133 Innovation Way 428 Sunnyvale, CA 94089 429 United States 431 Email: kireeti.ietf@gmail.com 433 Vishnu Pavan Beeram 434 Juniper Networks 435 1133 Innovation Way 436 Sunnyvale, CA 94089 437 United States 439 Email: vbeeram@juniper.net 441 Tarek Saad 442 Juniper Networks 443 1133 Innovation Way 444 Sunnyvale, CA 94089 445 United States 447 Email: tsaad@juniper.net 448 Israel Meilik 449 Broadcom 451 Email: israel.meilik@broadcom.com