idnits 2.17.1 draft-andersson-mpls-mna-fwk-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (26 May 2022) is 673 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group L. Andersson 3 Internet-Draft Bronze Dragon Consulting 4 Intended status: Informational S. Bryant 5 Expires: 27 November 2022 University of Surrey 5GIC 6 M. Bocci 7 Nokia 8 T. Li 9 Juniper Networks 10 26 May 2022 12 MPLS Network Actions Framework 13 draft-andersson-mpls-mna-fwk-02 15 Abstract 17 This document specifies an architectural framework for the MPLS 18 Network Actions (MNA) technologies. MNA technologies are used to 19 indicate actions for Label Switched Paths (LSPs) and/or MPLS packets 20 and to transfer data needed for these actions. 22 The document describes a common set of network actions and 23 information elements supporting additional operational models and 24 capabilities of MPLS networks. Some of these actions are defined in 25 existing MPLS specifications, while others require extensions to 26 existing specifications to meet the requirements found in 27 "Requirements for MPLS Network Action Indicators and Ancillary Data". 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 27 November 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2.1. Normative Definitions . . . . . . . . . . . . . . . . 4 66 1.2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . 4 67 2. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.2. Partial Processing . . . . . . . . . . . . . . . . . . . 7 70 2.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.4. Positioning . . . . . . . . . . . . . . . . . . . . . . . 8 72 2.5. State . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.1. The MNA Label . . . . . . . . . . . . . . . . . . . . . . 8 75 3.1.1. Existing Base SPL . . . . . . . . . . . . . . . . . . 8 76 3.1.2. New Base SPL . . . . . . . . . . . . . . . . . . . . 8 77 3.1.3. New Extended SPL . . . . . . . . . . . . . . . . . . 9 78 3.1.4. User-Defined Label . . . . . . . . . . . . . . . . . 9 79 3.2. TC and TTL . . . . . . . . . . . . . . . . . . . . . . . 9 80 3.2.1. TC and TTL retained . . . . . . . . . . . . . . . . . 9 81 3.2.2. TC and TTL Repurposed . . . . . . . . . . . . . . . . 9 82 3.3. Length of the NAS . . . . . . . . . . . . . . . . . . . . 10 83 3.3.1. Last/Continuation Bits . . . . . . . . . . . . . . . 10 84 3.3.2. Length Field . . . . . . . . . . . . . . . . . . . . 10 85 3.4. Encoding of Scopes . . . . . . . . . . . . . . . . . . . 10 86 3.5. Encoding a Network Action . . . . . . . . . . . . . . . . 11 87 3.5.1. Bit Catalogs . . . . . . . . . . . . . . . . . . . . 11 88 3.5.2. Operation Codes . . . . . . . . . . . . . . . . . . . 11 89 3.6. Encoding of Post-Stack Data . . . . . . . . . . . . . . . 12 90 3.6.1. First Nibble Considerations . . . . . . . . . . . . . 12 91 4. Definition of a Network Action . . . . . . . . . . . . . . . 13 92 5. Management Considerations . . . . . . . . . . . . . . . . . . 13 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 96 9. Editorial attic . . . . . . . . . . . . . . . . . . . . . . . 14 97 9.1. Process Note on E2E . . . . . . . . . . . . . . . . . . . 14 98 9.2. Concepts used in this Framework . . . . . . . . . . . . . 15 99 9.3. LSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 9.4. MPLS Forwarding model . . . . . . . . . . . . . . . . . . 16 101 9.4.1. Orginal Model . . . . . . . . . . . . . . . . . . . . 16 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 104 10.2. Informative References . . . . . . . . . . . . . . . . . 17 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 107 1. Introduction 109 This document specifies an architectural framework for the MPLS 110 Network Actions (MNA) technologies. MNA technologies are used to 111 indicate actions for LSPs and/or MPLS packets and to transfer data 112 needed for these actions. 114 The document describes a common set of network actions and 115 information elements supporting additional operational models and 116 capabilities of MPLS networks. Some of these actions are defined in 117 existing MPLS specifications, while others require extensions to 118 existing specifications to meet the requirements found in 119 [I-D.ietf-mpls-miad-mna-requirements]. 121 Forwarding actions are instructions to MPLS routers to apply 122 additional actions when forwarding a packet. These might include 123 load-balancing a packet given its entropy, whether or not to perform 124 fast reroute on a failure, and whether or not a packet has metadata 125 relevant to the forwarding decisions along the path. 127 This document generalizes the concept of "forwarding actions" into 128 "network actions" to include any action that an MPLS router is 129 requested to take on the packet. That includes any forwarding 130 action, but may include other operations (such as security functions, 131 OAM procedures, etc.) that are not directly related to forwarding of 132 the packet. 134 1.1. Requirement Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 1.2. Terminology 144 1.2.1. Normative Definitions 146 * Ancillary Data (AD): Data relating to the MPLS packet that may be 147 used to affect the forwarding or other processing of that packet, 148 or resulting from the processing of the packet, either at an Label 149 Edge Router (LER) [RFC4221] or Label Switching Router (LSR). This 150 data may be encoded within a network action sub-stack (see below) 151 (in-stack data), and/or after the bottom of the label stack (post- 152 stack data). 154 * Network Action: An operation to be performed on a packet. A 155 network action may affect router state, packet forwarding, or it 156 may affect the packet in some other way. A network action is said 157 to be present if there is an indicator in the packet that invokes 158 the action. 160 * Network Action Indication (NAI): An indication in the packet that 161 a certain network action is to be perfomed. There may be 162 associated ancillary data in the packet. 164 * Network Action Sub-Stack (NAS): A set of related, contiguous Label 165 Stack Entries (LSEs) in the label stack. The first LSE is the 166 Network Action Sub-stack Indicator. The TC and TTL values in the 167 sub-stack may be redefined. The label field in the second and 168 following LSE may be redefined. Solutions MUST NOT redefine the S 169 bit. See Section 3.1 through Section 3.5. 171 * Network Action Sub-Stack Indicator (NSI): An LSE that contains a 172 special label that indicates the start of a Network Action Sub- 173 stack. 175 * Scope: The set of nodes that should perform a given action. 177 1.2.2. Abbreviations 179 +==============+===========+=======================================+ 180 | Abbreviation | Meaning | Reference | 181 +==============+===========+=======================================+ 182 | AD | Ancillary | [I-D.ietf-mpls-miad-mna-requirements] | 183 | | Data | | 184 +--------------+-----------+---------------------------------------+ 185 | bSPL | Base | [RFC9017] | 186 | | Special | | 187 | | Purpose | | 188 | | Label | | 189 +--------------+-----------+---------------------------------------+ 190 | ECMP | Equal | | 191 | | Cost | | 192 | | Multipath | | 193 +--------------+-----------+---------------------------------------+ 194 | eSPL | Extended | [RFC9017] | 195 | | Special | | 196 | | Purpose | | 197 | | Label | | 198 +--------------+-----------+---------------------------------------+ 199 | HBH | Hop by | In the MNA context, this document. | 200 | | hop | | 201 +--------------+-----------+---------------------------------------+ 202 | I2E | Ingress | In the MNA context, this document. | 203 | | to Egress | | 204 +--------------+-----------+---------------------------------------+ 205 | ISD | In stack | [I-D.ietf-mpls-miad-mna-requirements] | 206 | | data | | 207 +--------------+-----------+---------------------------------------+ 208 | LSE | Label | [RFC3032] | 209 | | Stack | | 210 | | Entry | | 211 +--------------+-----------+---------------------------------------+ 212 | MNA | MPLS | This documnent | 213 | | Network | | 214 | | Actions | | 215 +--------------+-----------+---------------------------------------+ 216 | NAI | Network | [I-D.ietf-mpls-miad-mna-requirements] | 217 | | Action | | 218 | | Indicator | | 219 +--------------+-----------+---------------------------------------+ 220 | NAS | Network | This document | 221 | | Action | | 222 | | Sub-Stack | | 223 +--------------+-----------+---------------------------------------+ 224 | PSD | Post | [I-D.ietf-mpls-miad-mna-requirements] | 225 | | stack | and Section 3.6 | 226 | | data | | 227 +--------------+-----------+---------------------------------------+ 228 | SPL | Special | [RFC9017] | 229 | | Purpose | | 230 | | Label | | 231 +--------------+-----------+---------------------------------------+ 233 Table 1: Abbreviations 235 2. Structure 237 An MNA solution is envisioned as a set of network action sub-stacks 238 that indicate the network actions being invoked, plus possible post- 239 stack data. A solution must specify where in the label stack the 240 network actions sub-stacks occur, if and how frequently they should 241 be replicated, and how network action sub-stack and post-stack data 242 are encoded. 244 A network action sub-stack contains: 246 * Label: A special label is used to indicate the start of a network 247 action sub-stack. 249 * Indicators: A set of indicators that describes the set of network 250 actions. 252 * In-Stack Data: A set of zero or more LSEs that carry ancillary 253 data for the present network actions. 255 Each network action present in the network action sub-stack may have 256 zero or more LSEs of in-stack data. The ordering of the in-stack 257 data LSEs corresponds to the ordering of the network action 258 indicators. The encoding of the in-stack data, if any, for a network 259 action must be specified in the document that defines the network 260 action. 262 Certain network actions may also specify that data is carried after 263 the label stack. This is called post-stack data. The encoding of 264 the post-stack data, if any, for a network action must be specified 265 in the document that defines the network action. If multiple network 266 actions are present and have post-stack data, the ordering of their 267 post-stack data corresponds to the ordering of the network action 268 indicators. 270 A solution must specify the order that network actions are to be 271 applied to the packet. 273 2.1. Scopes 275 A network action may need to be processed by every node along the 276 path, or some subset of the nodes along its path. Some of the scopes 277 that an action may have are: 279 * Hop-by-hop (HBH): Every node along the path will perform the 280 action. 282 * Ingress-to-Egress (I2E): Only the last node on the path will 283 perform the action. 285 * Select: Only specific nodes along the path will perform the 286 action. 288 If a solution supports the select scope, it must describe how it 289 specifies the set of nodes to perform the actions. 291 2.2. Partial Processing 293 Legacy devices that do not recognize the MNA label will discard the 294 packet as described in [RFC3031]. 296 Devices that do recognize the MNA label may not implement all of the 297 present network actions. A solution must specify how unrecognized 298 present network actions should be handled. 300 One alternative is that an implementation should stop processing 301 network actions when it encounters an unrecognized network action. 302 Subsequent present network actions would not be applied. The result 303 is dependent on the solution's order of operations. 305 Another alternative is that an implementation should drop any packet 306 that contains any unrecognized present network actions. 308 A third alternative is that an implementation should perform all 309 recognized present network actions, but ignore all unrecognized 310 present network actions. 312 Other alternatives may also be possible and should be specified by 313 the solution. 315 2.3. Signaling 317 A node that wishes to make use of MNA and apply network actions to a 318 packet must understand the nodes that the packet will transit and 319 whether or not the nodes support MNA and the network actions that are 320 to be invoked. These capabilities are presumed to be signaled by 321 protocols that are out-of-scope for this document and are presumed to 322 have per-network action granularity. If a solution requires 323 alternate signaling, it must specify so explicitly. 325 A node that pushes a NAS onto the label stack is responsible for 326 determining that all nodes that should process the NAS will have the 327 NAS within its Readable Label Depth (RLD). A node should use 328 signaling (e.g., [RFC9088]) to determine this. 330 2.4. Positioning 332 A network action sub-stack should never occur at the top of the MPLS 333 label stack. A node that is responsible for popping a forwarding 334 label immediately above a network action sub-stack must also pop any 335 network action sub-stacks that immediately follow. 337 2.5. State 339 A network action can affect state in the network. This implies that 340 a packet may affect how subsequent packets are handled. 342 3. Encoding 344 Several possibilities to carry NAI's have been discussed in MNA 345 drafts and in the MPLS Open DT. In this section, we enumerate the 346 possibilities and some considerations for the various alternatives. 348 All types of network actions are represented in the MPLS label stack 349 by a set of LSEs termed a network action sub-stack (NAS). An NAS 350 consists of a special label, followed by LSEs that specify which 351 network actions are to be performed on the packet, and the in-stack 352 ancillary data for each indicated network action. 354 [I-D.ietf-mpls-miad-mna-requirements] requires that a solution not 355 add unnecessary LSEs to the sub-stack (Section 3.1, requirement 6). 356 Accordingly, solutions should also make efficient use of the bits 357 within the sub-stack, as inefficient use of the bits will result in 358 the addition of unnecessary LSEs. 360 3.1. The MNA Label 362 The first LSE in a network action sub-stack contains a special label 363 that indicates a network action sub-stack. A solution has several 364 choices for this special label. 366 3.1.1. Existing Base SPL 368 A solution may reuse an existing Base SPL (bSPL). If it elects to do 369 so, it must explain how the usage is backwards compatible, including 370 in the case where there is ISD. 372 3.1.2. New Base SPL 374 A solution may select a new bSPL. 376 3.1.3. New Extended SPL 378 A solution may select a new eSPL. If it elects to do so, it must 379 address the requirement for the minimal number of LSEs. 381 3.1.4. User-Defined Label 383 A solution may allow the network operator to define the label that 384 indicates the network action sub-stack. This creates management 385 overhead for the network operator to coordinate the use of this label 386 across all nodes on the path using management or signaling protocols. 387 If a solution elects to use a user-defined label, the solution should 388 justify this overhead. 390 3.2. TC and TTL 392 In the first LSE of the network action sub-stack, only the 20 bits of 393 Label Value and the Bottom of Stack bit are significant, the TC field 394 (3 bits) and the TTL (8 bits) are not used. This leaves 11 bits that 395 could be used for other purposes. 397 3.2.1. TC and TTL retained 399 If the solution elects to retain the TC and TTL field, then the first 400 LSE of the network action sub-stack would appear as: 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Label | TC |S| TTL | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Label: Label value, 20 bits 408 TC: Traffic Class, 3 bits 409 S: Bottom of Stack, 1 bit 410 TTL: Time To Live 412 Further LSEs would be needed to encode NAIs. If a solution elects to 413 retain these fields, it must address the requirement for the minimal 414 number of LSEs. 416 3.2.2. TC and TTL Repurposed 418 If the solution elects to reuse the TC and TTL field, then the first 419 LSE of the network action sub-stack would appear as: 421 0 1 2 3 422 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Label |x x x|S|x x x x x x x x| 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Label: Label value, 20 bits 427 x: Bit available for solution definition 428 S: Bottom of Stack, 1 bit 430 The solution may use more LSEs to contain NAIs. 432 3.3. Length of the NAS 434 A solution must have a mechanism to indicate the length of the NAS. 435 This must be easily processed even by implementations that do not 436 understand the full contents of the NAS. Two options are described 437 below, other solutions may be possible. 439 3.3.1. Last/Continuation Bits 441 A solution may use a bit per LSE to indicate whether the NAS 442 continues into the next LSE or not. The bit may indicate 443 continuation by being set or by being clear. The overhead of this 444 approach is one bit per LSE and has the advantage that it can 445 effectively encode an arbitrarily sized NAS. This approach is 446 efficient if the NAS is small. 448 3.3.2. Length Field 450 A solution may opt to have a fixed size length field at a fixed 451 location within the NAS. The fixed size of the length field may not 452 be large enough to support all possible NAS contents. This approach 453 may be more efficient if the NAS is longer, but not longer than can 454 be described by the length field. 456 Advice from hardware designers advocates a length field as this 457 minimizes branching in the logic. 459 3.4. Encoding of Scopes 461 A solution may choose to explicitly encode the scope of the actions 462 contained in a network action sub-stack. A solution may also choose 463 to have the scope encoded implicitly, based on the actions present in 464 the network action sub-stack. This choice may have performance 465 implications as an implementation might have to parse the network 466 actions that are present in a network action sub-stack only to 467 discover that there are no actions for it to perform. 469 Solutions need to consider the order of scoped NAIs and their 470 associated AD within individual sub-stacks and the order of per-scope 471 sub-stacks in order that network actions and the AD can be most 472 readily found and not need to processed by nodes that are not 473 required to handle those actions. 475 3.5. Encoding a Network Action 477 Two options for encoding NAIs are described below, other solutions 478 may be possible. Any solution should allow encoding of an arbitrary 479 number of NAIs. 481 3.5.1. Bit Catalogs 483 A solution may opt to encode the set of network actions as a list of 484 bits, sometimes known as a catalog. The solution must provide a 485 mechanism to determine how many LSEs are devoted to the catalog. A 486 set bit in the catalog would indicate that the corresponding network 487 action is present. 489 Catalogs are efficient if the number of present network actions is 490 relatively high and if the size of the necessary catalog is small. 491 For example, if the first 16 actions are all present, a catalog can 492 encode this in 16 bits. However, if the number of possible actions 493 is large, then a catalog can become inefficient. Selecting only one 494 action that is the 256th action would require a catalog of 256 bits, 495 which would require more than one LSE. 497 3.5.2. Operation Codes 499 A solution may opt to encode the set of present network actions as a 500 list of operation codes (opcodes). Each opcode is a fixed number of 501 bits. The size of the opcode bounds the number of network actions 502 that the solution can support. 504 Opcodes are efficient if there are only one or two active network 505 actions. For example, if an opcode is 8 bits, then two active 506 network actions could be encoded in in 16 bits. However, if there 507 are 16 actions required, then opcodes would consume 128 bits. 508 Opcodes are efficient at encoding a large number of possible actions. 509 If only the 256th action is to be selected, that still requires 8 510 bits. 512 3.6. Encoding of Post-Stack Data 514 If there are multiple instances of post-stack data, they should occur 515 in the same order as their relevant network action sub-stacks and 516 then in the same order as their relevant network functions occur 517 within the network action sub-stacks. 519 3.6.1. First Nibble Considerations 521 The first nibble after the label stack has been used to convey 522 information in certain cases. 524 For example, in [RFC4928] this nibble is investigated to find out if 525 it has the value "4" or "6", if it is not, it is assumed that the 526 packet payload is not IPv4 or IPv6 and Equal Cost Multipath (ECMP) is 527 not performed. 529 It should be noted that this is an inexact method, for example an 530 Ethernet Pseudowire without a control word might have "4" or "6" in 531 the first nibble and thus will be ECMP'ed. 533 Nevertheless, the method is implemented and deployed, it is used 534 today and will be for the foreseeable future. 536 The use of the first nibble for BIER is specified in [RFC8296]. Bier 537 sets the first nibble to 5. The same is true for BIER payload, as 538 for any use of the first nibble, it is not possible from the first 539 nibble itself being set to 5, conclude that the payload is BIER. 540 However, it achieves the design goal of [RFC8296], to exclude that 541 the payload is IPv4, IPv6 or a pseudowire. 543 There are possibly more examples, they will be added if we find that 544 they further highlight the issue with using the first nibble. 546 [Ed. Outstanding comments from Adrian: 548 Shouldn't we include RFC4385 for 0b0000 for the PW control word and 549 0b0001 for the PW ACH? 551 This section is all very well, but it doesn't give any direction to 552 the solution developer for what they should do with the first nibble 553 in the post stack data. 555 Is it also relevant to note that there may be other post-stack 556 information that comes before the payload (such as the PW control 557 word, and that the solution must consider the location of the post- 558 stack data in relaiton to that (e.g., immeidately after the LSE with 559 the S bit set) etc.] 561 4. Definition of a Network Action 563 Network actions should be defined in a document and must contain: 565 * Name: The name of the network action. 567 * Network Action Indicator: The bit position or opcode that 568 indicates that the network action is active. 570 * Scope: The document should specify which nodes should perform the 571 network action. The action may apply to each transit node (HBH), 572 only the egress node that pops the final label off of the label 573 stack, or specific nodes along the label switched path. 575 * State: The document should specify if the network action can 576 modify state in the network, and if so, the state that may be 577 modified and its side-effects. 579 * Required/Optional: The document should specify whether a node is 580 required to perform the network action. 582 * In-Stack Data: The number of LSEs of in-stack data and its 583 encoding. If this is of a variable length, then the solution must 584 specify how an implementation can determine this length without 585 implementing the network action. 587 * Post-Stack Data: The encoding of post-stack data, if any. If this 588 is of a variable length, then the solution must specify how an 589 implementation can determine this length without implementing the 590 network action. 592 A solution should create an IANA registry for network actions. 594 5. Management Considerations 596 Network operators will need to be cognizant of which network actions 597 are supported by which nodes and will need to ensure that this is 598 signalled appropriately. Some solutions may require network-wide 599 configuration to synchronize the use of the labels that indicate the 600 start of an NAS. Solution documents must make clear what management 601 considerations apply to the solutions they are describing. Solutions 602 documents must describe mechanisms for performing network diagnostics 603 in the presence of MNAs. 605 6. Security Considerations 607 The forwarding plane is insecure. If an adversary can affect the 608 forwarding plane, then they can inject data, remove data, corrupt 609 data, or modify data. MNA additionally allows an adversary to make 610 packets perform arbitrary network actions. 612 Link-level security mechanisms can help mitigate some on-link 613 attacks, but does nothing to preclude hostile nodes. 615 End-to-end encryption of an LSP can help provide security, but would 616 make it impossible to process post-stack data. 618 7. IANA Considerations 620 This document does not make any allocations of code points from IANA 621 registries. 623 As long as the "does not make any allocations ..." from IANA is true, 624 this pragraph shoukd be removed by the RFC-Editor. If it turns out 625 that we will need to do IANA allocation, a proper IANA section will 626 be added. 628 8. Acknowledgements 630 This document is the result of work started in MPLS Open Desgign 631 Team, with participation by the MPLS, PALS and DETNET working groups. 633 The authors would like to thank Adrian Farrel for his contributions 634 and to John Drake for his comments. 636 9. Editorial attic 638 This section contains old material that will be discarded before 639 publication, assuming we don't find it useful between now and then. 641 9.1. Process Note on E2E 643 There has been some discussion on the of the E2E abbreviation. 1. In 644 a mail to the MPLS Working group mailing list Joel Halpern pointed 645 out that the abbreviation E2E has been used in several different 646 meanings. Joel suggested to use another abbreviation. 648 1. Some variants has been proposed, for example. 650 * Ingress to Egress (I2E); alernative abbreviation (i2e) 652 * Egress 653 * LSP Ingress to LSP Egress (LI2LE) 655 * Egress (because the Ingress has already done its thing) 657 * Ultimate Hop 659 * Destination 661 * Start-to-End 663 * Last-LSR 665 * Head to Tail 667 In a few days (counting from the publication date of this document) 668 the working group chairs will take an initiative to poll the working 669 groups for consensus on this. 671 9.2. Concepts used in this Framework 673 +=============+====================+===========+======+ 674 | Concept | Meaning | Reference | Note | 675 +=============+====================+===========+======+ 676 | E2E concept | E2E in MNA context | this | - | 677 | | is defined in... | document | | 678 +-------------+--------------------+-----------+------+ 679 | concept | free text | this | - | 680 | | | document | | 681 +-------------+--------------------+-----------+------+ 683 Table 2: Concepts 685 Not complete, help appreciated. [Ed. This section is planned for 686 removal as it seems unhelpful so far.] 688 9.3. LSE 690 An individual LSE has the following format [RFC3032]: 692 0 1 2 3 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Label | TC |S| TTL | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Label: Label Value, 20 bits 699 TC: Traffic Class, 3 bits 700 S: Bottom of Stack, 1 bit 701 TTL: Time to Live, 8 bits 703 Figure 1: A Label Stack Entry (LSE) 705 9.4. MPLS Forwarding model 707 This is section here to basically to have a place holder where to 708 discuss the development of the MPLS forwrding model. It might be 709 removed. [Ed. So far, it adds no value. Wave bye-bye.] 711 9.4.1. Orginal Model 713 +-----------------------------------------------------------------+ 714 | | 715 | +---------------------+ | 716 | | +------------+ | | 717 | | | MPLS Label | LSE | | 718 | | +---|--------+ | | 719 | +-----|---------------+ | 720 | | | 721 | | +----------------------+ | 722 | | | FIB | | 723 | | | | | 724 | | | +------------+ | +----------------------+ | 725 | +------->|FIB Entry |-----+-->|Forwarding Code | | 726 | | +------------+ | | +----------------------+ | 727 | +----------------------| | | 728 | | | +----------------------+ | 729 | +-->|Forwarding Parameters | | 730 | +----------------------+ | 731 | | 732 | | 733 | LSE = Label Stack Entry (what many people call a label) | 734 | FIB = Forwarding Information (date)Base | 735 +-----------------------------------------------------------------+ 737 Figure 2: MPLS Original Forwarding Model 739 10. References 740 10.1. Normative References 742 [I-D.ietf-mpls-miad-mna-requirements] 743 Bocci, M. and S. Bryant, "Requirements for MPLS Network 744 Action Indicators and MPLS Ancillary Data", Work in 745 Progress, Internet-Draft, draft-ietf-mpls-miad-mna- 746 requirements-00, 5 May 2022, 747 . 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, 752 DOI 10.17487/RFC2119, March 1997, 753 . 755 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 756 Label Switching Architecture", RFC 3031, 757 DOI 10.17487/RFC3031, January 2001, 758 . 760 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 761 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 762 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 763 . 765 [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol 766 Label Switching (MPLS) Management Overview", RFC 4221, 767 DOI 10.17487/RFC4221, November 2005, 768 . 770 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 771 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 772 May 2017, . 774 [RFC9017] Andersson, L., Kompella, K., and A. Farrel, "Special- 775 Purpose Label Terminology", RFC 9017, 776 DOI 10.17487/RFC9017, April 2021, 777 . 779 [RFC9088] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 780 and M. Bocci, "Signaling Entropy Label Capability and 781 Entropy Readable Label Depth Using IS-IS", RFC 9088, 782 DOI 10.17487/RFC9088, August 2021, 783 . 785 10.2. Informative References 787 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 788 Cost Multipath Treatment in MPLS Networks", BCP 128, 789 RFC 4928, DOI 10.17487/RFC4928, June 2007, 790 . 792 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 793 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 794 for Bit Index Explicit Replication (BIER) in MPLS and Non- 795 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 796 2018, . 798 Authors' Addresses 800 Loa Andersson 801 Bronze Dragon Consulting 802 Email: loa@pi.nu 804 Stewart Bryant 805 University of Surrey 5GIC 806 Email: sb@stewartbryant.com 808 Matthew Bocci 809 Nokia 810 Email: matthew.bocci@nokia.com 812 Tony Li 813 Juniper Networks 814 Email: tony.li@tony.li