idnits 2.17.1 draft-saad-mpls-miad-usecases-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 214: '...TF network slice MAY support the follo...' RFC 2119 keyword, line 245: '... MAY carry the same FAS in the MPLS ...' RFC 2119 keyword, line 364: '...tioned use cases MAY co-exist in the s...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 April 2022) is 737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-andersson-mpls-mna-fwk-00 == Outdated reference: A later version (-10) exists of draft-bestbar-teas-ns-packet-08 == Outdated reference: A later version (-05) exists of draft-decraene-mpls-slid-encoded-entropy-label-id-03 == Outdated reference: A later version (-12) exists of draft-gandhi-mpls-ioam-04 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-10 == Outdated reference: A later version (-03) exists of draft-kompella-mpls-mspl4fa-02 == Outdated reference: A later version (-04) exists of draft-kompella-mpls-nffrr-02 == Outdated reference: A later version (-08) exists of draft-li-apn-problem-statement-usecases-06 == Outdated reference: A later version (-03) exists of draft-li-mpls-enhanced-vpn-vtn-id-02 == Outdated reference: A later version (-03) exists of draft-lm-mpls-sfc-path-verification-02 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group T. Saad 3 Internet-Draft Juniper Networks 4 Intended status: Informational K. Makhijani 5 Expires: 22 October 2022 H. Song 6 Futurewei Technologies 7 G. Mirsky 8 Ericsson 9 20 April 2022 11 Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data 12 draft-saad-mpls-miad-usecases-02 14 Abstract 16 This document presents a number of use cases that have a common need 17 for encoding network action indicators and associated ancillary data 18 inside MPLS packets. There has been significant recent interest in 19 extending the MPLS data plane to carry such indicators and ancillary 20 data to address a number of use cases that are described in this 21 document. 23 The use cases described in this document are not an exhaustive set, 24 but rather the ones that are actively discussed by members of the 25 IETF MPLS, PALS and DETNET working groups participating in the MPLS 26 Open Design Team. 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 22 October 2022. 45 Copyright Notice 47 Copyright (c) 2022 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 (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 64 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. No Further Fastreroute . . . . . . . . . . . . . . . . . 3 66 2.2. In-situ OAM . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Network Slicing . . . . . . . . . . . . . . . . . . . . . 4 68 2.3.1. Global Identifier as Flow-Aggregate Selector . . . . 5 69 2.3.2. Forwarding Label as a Flow-Aggregate Selector . . . . 6 70 2.4. Delay Budgets for Time-Bound Applications . . . . . . . . 6 71 2.4.1. Stack Based Methods for Latency Control . . . . . . . 7 72 2.5. NSH-based Service Function Chaining . . . . . . . . . . . 7 73 2.6. Network Programming . . . . . . . . . . . . . . . . . . . 7 74 2.7. Application Aware Networking . . . . . . . . . . . . . . 8 75 3. Co-existence of Usecases . . . . . . . . . . . . . . . . . . 8 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 79 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 80 8. Informative References . . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 This document describes important cases that require carrying 86 additional ancillary data within the MPLS packets, as well as means 87 to indicate the ancillary data is present, and a specific action 88 needs to be performed on the packet. 90 These use cases have been identified by the MPLS Working Group Open 91 Design Team working on defining MPLS Network Actions for the MPLS 92 data plane. The MPLS Ancillary Data (AD) can be classified as: 94 * implicit, or "no-data" associated with a Network Action (NA) 95 indicator, 97 * residing within the MPLS label stack and referred to as In Stack 98 Data (ISD), and 100 * residing after the Bottom of MPLS label Stack (BoS) and referred 101 to as Post Stack Data (PSD). 103 The use cases described in this document will be used to assist in 104 identifying requirements and issues to be considered for future 105 resolution by the working group. 107 1.1. Terminology 109 The following terminology is used in the document: 111 IETF Network Slice: 112 a well-defined composite of a set of endpoints, the connectivity 113 requirements between subsets of these endpoints, and associated 114 requirements; the term 'network slice' in this document refers to 115 'IETF network slice' as defined in 116 [I-D.ietf-teas-ietf-network-slices]. 118 Time-Bound Networking: 119 Networks that transport time-bounded traffic. 121 1.2. Acronyms and Abbreviations 123 ISD: In-stack data 125 PSD: Post-stack data 127 MNA: MPLS Network Action 129 NAI: Network Action Indicator 131 AD: Ancillary Data 133 2. Use Cases 135 2.1. No Further Fastreroute 137 MPLS Fast Reroute (FRR) [RFC4090], [RFC5286] and [RFC7490] is a 138 useful and widely deployed tool for minimizing packet loss in the 139 case of a link or node failure. 141 Several cases exist where, once FRR has taken place in an MPLS 142 network and resulted in rerouting a packet away from the failure, a 143 second FRR that impacts the same packet to rerouting is not helpful, 144 and may even be disruptive. 146 For example, in such a case, the packet may continue to loop until 147 its TTL expires. This can lead to link congestion and further packet 148 loss. Thus, the attempt to prevent a packet from being dropped may 149 instead affect many other packets. A proposal to address this is 150 presented in [I-D.kompella-mpls-nffrr]. 152 2.2. In-situ OAM 154 In-situ Operations, Administration, and Maintenance (IOAM) may record 155 operational and telemetry information within the packet while the 156 packet traverses a particular path in a network domain. 158 The term "in-situ" refers to the fact that the IOAM data fields are 159 added to the data packets rather than being sent within the probe 160 packets specifically dedicated to OAM or Performance Measurement 161 (PM). 163 IOAM can run in two modes Edge-to-Edge (E2E) and Hop-by-Hop (HbH). 164 In E2E mode, only the encapsulating and decapsulating nodes will 165 process IOAM data fields. In HbH mode, the encapsulating and 166 decapsulating nodes as well as intermediate IOAM-capable nodes 167 process IOAM data fields. 169 The IOAM data fields are defined in [I-D.ietf-ippm-ioam-data], and 170 can be used for various use-cases of OAM and PM. 172 [I-D.gandhi-mpls-ioam-sr] defines how IOAM data fields are 173 transported using the MPLS data plane encapsulations, including 174 Segment Routing (SR) with MPLS data plane (SR-MPLS). 176 The IOAM data may be added after the bottom of the MPLS label stack. 177 The IOAM data fields can be of fixed or incremental size as defined 178 in [I-D.ietf-ippm-ioam-data]. [I-D.gandhi-mpls-ioam] describes the 179 applicability of IOAM to MPLS dataplane. The encapsulating MPLS node 180 needs to know if the decapsulating MPLS node can process the IOAM 181 data before adding it in the packet. In HbH IOAM mode, nodes that 182 are capable of processing IOAM will intercept and process the IOAM 183 data accordingly. The presence of IOAM header and optional IOAM data 184 will betransparent to nodes that do not support or do not participate 185 in the IOAM process. 187 2.3. Network Slicing 189 [I-D.ietf-teas-ietf-network-slices] specifies the definition of an 190 IETF Network Slice. It further discusses the general framework for 191 requesting and operating IETF Network Slices, their characteristics, 192 and the necessary system components and interfaces. 194 Multiple network slices can be realized on top of a single physical 195 network. 197 In order to overcome scale challenges, IETF Network Slices may be 198 aggregated into groups according to similar characteristics. The 199 slice aggregate [I-D.bestbar-teas-ns-packet] is a construct that 200 comprises of the traffic flows of one or more IETF Network Slices of 201 similar characteristics. 203 A router that requires forwarding of a packet that belongs to a slice 204 aggregate may have to decide on the forwarding action to take based 205 on selected next-hop(s), and the forwarding treatment (e.g., 206 scheduling and drop policy) to enforce based on the associated per- 207 hop behavior. 209 The routers in the network that forward traffic over links that are 210 shared by multiple slice aggregates need to identify the slice 211 aggregate packets in order to enforce the associated forwarding 212 action and treatment. 214 An IETF network slice MAY support the following key features: 216 1. A Slice Selector 218 2. A Network Resource Partition associated with a slice aggregate. 220 3. A Path selection criteria 222 4. Verification that per slice Slice Level Objectives (SLOs) are 223 being met. This may be done by active measurements (inferred) or 224 by using hybrid measurement methods, e.g., IOAM. 226 5. Additionally, there is an on-going discussion on using Service 227 Functions (SFs) with network slices. This may require insertion 228 of an NSH. 230 6. For multi-domain scenarios, a packet that traverses multiple 231 domains may encode different identifiers within each domain. 233 2.3.1. Global Identifier as Flow-Aggregate Selector 235 A Global Identifier as a Flow-Aggregate Selector (G-FAS) can be 236 encoded in the MPLS packet as defined in [I-D.kompella-mpls-mspl4fa], 237 [I-D.li-mpls-enhanced-vpn-vtn-id], and 238 [I-D.decraene-mpls-slid-encoded-entropy-label-id]. The G-FAS is used 239 to associate the packets belonging to Slice-Flow Aggregate to the 240 underlying Network Resource Partition (NRP) as described in 241 [I-D.bestbar-teas-ns-packet]. 243 The G-FAS can be encoded within an MPLS label carried in the packet's 244 MPLS label stack. All packets that belong to the same flow aggregate 245 MAY carry the same FAS in the MPLS label stack. 247 When MPLS packets carry a G-FAS, MPLS LSRs use the forwarding label 248 to select the forwarding next-hop(s), and use the G-FAS in the MPLS 249 packet to infer the specific forwarding treatment that needs to be 250 applied on the packet. 252 2.3.2. Forwarding Label as a Flow-Aggregate Selector 254 [RFC3031] states in Section 2.1 that: 'Some routers analyze a 255 packet's network layer header not merely to choose the packet's next 256 hop, but also to determine a packet's "precedence" or "class of 257 service"'. 259 It is possible by assigning a unique MPLS forwarding label to each 260 flow aggregate (FEC) to distinguish the packets forwarded to the same 261 destination. from other flow aggregates. In this case, LSRs can use 262 the top forwarding label to infer both the forwarding action and the 263 forwarding treatment to be invoked on the packets. 265 2.4. Delay Budgets for Time-Bound Applications 267 The routers in a network can perform two distinct functions on 268 incoming packets, namely forwarding (where the packet should be sent) 269 and scheduling (when the packet should be sent). IEEE-802.1 Time 270 Sensitive Networking (TSN) and Deterministic Networking provide 271 several mechanisms for scheduling under the assumption that routers 272 are time-synchronized. The most effective mechanisms for delay 273 minimization involve per-flow resource allocation. 275 Segment Routing (SR) is a forwarding paradigm that allows encoding 276 forwarding instructions in the packet in a stack data structure, 277 rather than being programmed into the routers. The SR instructions 278 are contained within a packet in the form of a First-in First-out 279 stack dictating the forwarding decisions of successive routers. 280 Segment routing may be used to choose a path sufficiently short to be 281 capable of providing a bounded end-to-end latency but does not 282 influence the queueing of individual packets in each router along 283 that path. 285 When carried over the MPLS data plane, a solution is required to 286 enable the delivery of such packets that can be delivered to their 287 final destination by a given time budget. 289 2.4.1. Stack Based Methods for Latency Control 291 One efficient data structure for inserting local deadlines into the 292 headers is a "stack", similar to that used in Segment Routing to 293 carry forwarding instructions. The number of deadline values in the 294 stack equals the number of routers the packet needs to traverse in 295 the network, and each deadline value corresponds to a specific 296 router. The Top-of-Stack (ToS) corresponds to the first router's 297 deadline while the Bottom-of-Stack (BoS) refers to the last's. All 298 local deadlines in the stack are later or equal to the current time 299 (upon which all routers agree), and times closer to the ToS are 300 always earlier or equal to times closer to the BoS. 302 The ingress router inserts the deadline stack into the packet 303 headers; no other router needs to be aware of the requirements of the 304 time-bound flows. Hence admitting a new flow only requires updating 305 the information base of the ingress router. 307 MPLS LSRs that expose the Top of Stack (ToS) label can also inspect 308 the associated "deadline" carried in the packet (either in MPLS stack 309 as ISD or after BoS as PSD). 311 2.5. NSH-based Service Function Chaining 313 [RFC8595] describes how Service Function Chaining (SFC) can be 314 realized in an MPLS network by emulating the NSH by using only MPLS 315 label stack elements. 317 The approach in [RFC8595] introduces some limitations that are 318 discussed in [I-D.lm-mpls-sfc-path-verification]. This approach, 319 however, can benefit from the framework introduced with MNA 320 [I-D.andersson-mpls-mna-fwk]. 322 For example, it may be possible to extend NSH emulation using MPLS 323 labels [RFC8595] to support the functionality of NSH Context Headers, 324 whether fixed or variable-length. One of the use cases could support 325 Flow ID [I-D.ietf-sfc-nsh-tlv] that may be used for load-balancing 326 among Service Function Forwarders (SFFs) and/or the Service Function 327 (SF) within the same SFP. 329 2.6. Network Programming 331 In SR, an ingress node steers a packet through an ordered list of 332 instructions, called "segments". Each one of these instructions 333 represents a function to be called at a specific location in the 334 network. A function is locally defined on the node where it is 335 executed and may range from simply moving forward in the segment list 336 to any complex user-defined behavior. 338 Network Programming combines Segment Routing (SR) functions to 339 achieve a networking objective that goes beyond mere packet routing. 341 It may be desirable to encode a pointer to function and its arguments 342 within an MPLS packet transport header. For example, in MPLS we can 343 encode the FUNC::ARGs within the label stack or after the Bottom of 344 Stack to support the equivalent of FUNC::ARG in SRv6 as described in 345 [RFC8986]. 347 2.7. Application Aware Networking 349 Application-aware Networking (APN) as described in 350 [I-D.li-apn-problem-statement-usecases] allows application-aware 351 information (i.e., APN attributes) including APN identification (ID) 352 and/or APN parameters (e.g. network performance requirements) to be 353 encapsulated at network edge devices and carried in packets 354 traversing an APN domain. 356 The APN data is carried in packets to facilitate service 357 provisioning, and be used to perform fine-granularity traffic 358 steering and network resource adjustment. To support APN in MPLS 359 networks, mechanisms are needed to carry such APN data in MPLS 360 encapsulated packets. 362 3. Co-existence of Usecases 364 Two or more of the aforementioned use cases MAY co-exist in the same 365 packet. This may require the presence of multiple ancilary data 366 (whether In-stack or Post-stack ancillary data) to be present in the 367 same MPLS packet. 369 For example, IOAM may provide key functions along with network 370 slicing to help ensure that critical network slice SLOs are being met 371 by the network provider. In this case, IOAM is able to collect key 372 performance measurement parameters of network slice traffic flows as 373 it traverses the transport network. 375 4. IANA Considerations 377 This document has no IANA actions. 379 5. Security Considerations 381 This document introduces no new security considerations. 383 6. Acknowledgement 385 The authors gratefully acknowledge the input of the members of the 386 MPLS Open Design Team. 388 7. Contributors 390 The following individuals contributed to this document: 392 Loa Andersson 393 Bronze Dragon Consulting 394 Email: loa@pi.nu 396 8. Informative References 398 [I-D.andersson-mpls-mna-fwk] 399 Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS 400 Network Actions Framework", Work in Progress, Internet- 401 Draft, draft-andersson-mpls-mna-fwk-00, 4 April 2022, 402 . 405 [I-D.bestbar-teas-ns-packet] 406 Saad, T., Beeram, V. P., Dong, J., Wen, B., Ceccarelli, 407 D., Halpern, J., Peng, S., Chen, R., Liu, X., Contreras, 408 L. M., Rokui, R., and L. Jalil, "Realizing Network Slices 409 in IP/MPLS Networks", Work in Progress, Internet-Draft, 410 draft-bestbar-teas-ns-packet-08, 2 February 2022, 411 . 414 [I-D.decraene-mpls-slid-encoded-entropy-label-id] 415 Decraene, B., Filsfils, C., Henderickx, W., Saad, T., 416 Beeram, V. P., and L. Jalil, "Using Entropy Label for 417 Network Slice Identification in MPLS networks.", Work in 418 Progress, Internet-Draft, draft-decraene-mpls-slid- 419 encoded-entropy-label-id-03, 11 February 2022, 420 . 423 [I-D.gandhi-mpls-ioam] 424 Gandhi, R., Ali, Z., Brockners, F., Wen, B., Decraene, B., 425 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 426 OAM Data", Work in Progress, Internet-Draft, draft-gandhi- 427 mpls-ioam-04, 2 March 2022, 428 . 431 [I-D.gandhi-mpls-ioam-sr] 432 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 433 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 434 OAM Data", Work in Progress, Internet-Draft, draft-gandhi- 435 mpls-ioam-sr-06, 18 February 2021, 436 . 439 [I-D.ietf-ippm-ioam-data] 440 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 441 for In-situ OAM", Work in Progress, Internet-Draft, draft- 442 ietf-ippm-ioam-data-17, 13 December 2021, 443 . 446 [I-D.ietf-sfc-nsh-tlv] 447 Wei, Y., Elzur, U., Majee, S., Pignataro, C., and D. E. 448 Eastlake, "Network Service Header (NSH) Metadata Type 2 449 Variable-Length Context Headers", Work in Progress, 450 Internet-Draft, draft-ietf-sfc-nsh-tlv-15, 20 April 2022, 451 . 454 [I-D.ietf-teas-ietf-network-slices] 455 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 456 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 457 Network Slices", Work in Progress, Internet-Draft, draft- 458 ietf-teas-ietf-network-slices-10, 27 March 2022, 459 . 462 [I-D.kompella-mpls-mspl4fa] 463 Kompella, K., Beeram, V. P., Saad, T., and I. Meilik, 464 "Multi-purpose Special Purpose Label for Forwarding 465 Actions", Work in Progress, Internet-Draft, draft- 466 kompella-mpls-mspl4fa-02, 9 February 2022, 467 . 470 [I-D.kompella-mpls-nffrr] 471 Kompella, K. and W. Lin, "No Further Fast Reroute", Work 472 in Progress, Internet-Draft, draft-kompella-mpls-nffrr-02, 473 12 July 2021, . 476 [I-D.li-apn-problem-statement-usecases] 477 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z., 478 and G. Mishra, "Problem Statement and Use Cases of 479 Application-aware Networking (APN)", Work in Progress, 480 Internet-Draft, draft-li-apn-problem-statement-usecases- 481 06, 7 March 2022, . 484 [I-D.li-mpls-enhanced-vpn-vtn-id] 485 Li, Z. and J. Dong, "Carrying Virtual Transport Network 486 Identifier in MPLS Packet", Work in Progress, Internet- 487 Draft, draft-li-mpls-enhanced-vpn-vtn-id-02, 7 March 2022, 488 . 491 [I-D.lm-mpls-sfc-path-verification] 492 Yao, L. and G. Mirsky, "MPLS-based Service Function 493 Path(SFP) Consistency Verification", Work in Progress, 494 Internet-Draft, draft-lm-mpls-sfc-path-verification-02, 21 495 February 2021, . 498 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 499 Label Switching Architecture", RFC 3031, 500 DOI 10.17487/RFC3031, January 2001, 501 . 503 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 504 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 505 DOI 10.17487/RFC4090, May 2005, 506 . 508 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 509 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 510 DOI 10.17487/RFC5286, September 2008, 511 . 513 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 514 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 515 RFC 7490, DOI 10.17487/RFC7490, April 2015, 516 . 518 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 519 Forwarding Plane for Service Function Chaining", RFC 8595, 520 DOI 10.17487/RFC8595, June 2019, 521 . 523 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 524 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 525 (SRv6) Network Programming", RFC 8986, 526 DOI 10.17487/RFC8986, February 2021, 527 . 529 Authors' Addresses 531 Tarek Saad 532 Juniper Networks 533 Email: tsaad@juniper.net 535 Kiran Makhijani 536 Futurewei Technologies 537 Email: kiranm@futurewei.com 539 Haoyu Song 540 Futurewei Technologies 541 Email: haoyu.song@futurewei.com 543 Greg Mirsky 544 Ericsson 545 Email: gregimirsky@gmail.com