Early Review of draft-ietf-mpls-mna-fwk-06
review-ietf-mpls-mna-fwk-06-rtgdir-early-eckert-2024-04-03-00
| Request | Review of | draft-ietf-mpls-mna-fwk-06 |
|---|---|---|
| Requested revision | 06 (document currently at 07) | |
| Type | Early Review | |
| Team | Routing Area Directorate (rtgdir) | |
| Deadline | 2024-04-05 | |
| Requested | 2024-03-05 | |
| Requested by | Tarek Saad | |
| Authors | Loa Andersson , Stewart Bryant , Matthew Bocci , Tony Li | |
| I-D last updated | 2024-04-03 | |
| Completed reviews |
Rtgdir Early review of -06
by Toerless Eckert
(diff)
|
|
| Comments |
In prep for WG last call. |
|
| Assignment | Reviewer | Toerless Eckert |
| State | Completed | |
| Request | Early review on draft-ietf-mpls-mna-fwk by Routing Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/rtg-dir/v1jtygtmx_BcbgC6RVpwVLzoOUI | |
| Reviewed revision | 06 (document currently at 07) | |
| Result | Has issues | |
| Completed | 2024-04-03 |
review-ietf-mpls-mna-fwk-06-rtgdir-early-eckert-2024-04-03-00
I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-fwk-06 The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this review request was marked by the working group chairs as "In prep for WG last call", my focus for the review was to determine whether the document is ready to be published. Please consider my comments as if they are early last-call comments. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Document: draft-ietf-mpls-mna-fwk-06 Reviewer: Toerless Eckert Review Date: date Intended Status: Informational Summary: This document is on the right path (has issues). I have a few textual mayor/minor concerns that would be good to get attention before it is submitted to the IESG. Most issues are about missing/unclear text/ explanations. Technically it is primarily PSD requirements and definitions that i think are missing. In addition, there is a range of textual nits. General: 1.1 Not having seriously looked at MNA for the past two ? years, this started as a cold read, so there may be more comments directed at explaining aspects of the technology than may look reasonable to those in the WG who have spent a lot of time on this during the past few years. Hopefully this is seen as helpful. 1.2 I recently managed to observe a meeting in which third parties who attempted to implement proposed solutions where also unclear about core aspects, such as what degree of lookahead into the stack for sub-stacks is assumed to be required, and i can not find this explained in this framework (nor the requirements document). >From my little experience i gather that some pre-existing special label functionality does require more lookahead to find them in the label stack than being directly below the TOS LSE, and i don't think this option is written into rfc3031, which is the only relevant reference mentioned here. So i think some text about the expected supported methods to find a NAS would be welcome text to make readers better understand expectations against NAS. Including the appropriate references if it is based on prior mechanisms. 2. The framework document does not explain unambiguously whether a single packet or a single network was supposed to support the simultaneous deployment/use of only one or multiple MNA solutions. Technially, the provisions described in the framework do seem to allow supporting to operate more than one solution at the same time by use of different NSI for different MNA solution substacks. Reading draft-ietf-mpls-mna-requirements it sounds a bit as if only one solution is assumed to be deployed at one time, but that of course does not make it clear that the framework expects the same limitation too. Aka: please explain explicitly. I do suggest possible text further below. 3. Framework re. requirements document 3.1 It is quite unclear to solution designers which of the requirements document requirements are left unchallenged by the framework and which are replaced/superceeded by more detailled reqiurements from this framework document. It would be a lot better IMHO if solution designers would only have to refer to requirements from this framework document but not have to read the requirements document as well. Aka: Add a section to the framework document, inherit all the requirements from the requirements document, delete all the ones that are superceeded by the more refined requirements/ definitions from the framewokr document, and then review the remaining ones and see what to do about them - keep unchanged or refine/add-explanations from framework view etc.. pp. This is ultimately the check if the framework is considered to be complete against the requirements document, and i don't think a reviewer of the framework document should do the first run for this - but rather the authors by doing this cut & check. Worst case, if something like this is not done, how would developers of solutions address inconsistencies between framework and requirements document ? Or know what to do about requirements assumed to be unaffected by the framework if those are not clear to developers how to translate into a solution ? I have comments about specific requiremnts further down in this review. It would also be good to make the required reading consistent with the requirements document. E.g.: it mentions rfc3031/rfc3032 and then starts to hand-wave about extensions - making it difficult to undersstand which of those extensions migh be relevant. This framework document does only mention rfc3031/rfc3032 in passing but not in the main text. 3.2 I tried to validate if this document meets the requirement listed in the requirements document, and stumbled across the following points in the requirements document: 50. In-stack ancillary data MUST only be inserted in conjunction with an operation conforming to [RFC3031]. 51. Post-stack ancillary data MUST only be inserted in conjunction with an operation conforming to [RFC3031]. I am guessing that this does not apply to the initial construction of the label stack on the ingress LSR ? It would be good to say so explicitly. Also, RFC3031 only seems to define "operations" as something derived from LSR state, aka: NHLFE. And network actions for example do not necessarily require NHLFE (but often could be stateless alternatives). But network actions are also referred to as "operation" in the framework draft. Aka: requirement 50/51 can be read as if a network action itself indicated by a Network SubStack can not modify the MPLS Label Stack unless it has NHLFE associated with it. 6. Solutions MUST NOT require an implementation to support in-stack ancillary data, unless the implementation chooses to support a network action that uses in-stack ancillary data. 7. Solutions MUST NOT require an implementation to support post- stack ancillary data, unless the implementation chooses to support a network action that uses post-stack ancillary data. These two requirements seem like NOPs, or at least i can not come up with an idea how to violate them. Maybe some example would help. 3.3 There are requirements i do not agree with, but i guess those comments would need to go to the requirements do last call, but just in case, consider as comments: 36. If there is post-stack ancillary data, there MUST be an indication of its presence in the label stack. I think this requirement can be in contradiction to requirement 8, 9: 8. The design of any MNA solution MUST minimise the amount of processing required to parse the label stack at an LSR. 9. Solutions MUST minimize any additions to the size of the MPLS label stack. 3.4 This requirement may be mis-worded / unclear: 46. Any MNA solution specification MUST describe whether it can coexist with existing post-stack data mechanisms e.g. control words and G-ACH, and if so how this coexistence operates. When i called the DetNet control word a part of MPLS in the DetNet WG in IETF 119, Greg Mirsky educated me on the microphone that this has nothing to do with MPLS, aka: the PseudoWire or DetNet control words are not any more MPLS Post Stack Data than IP IP/IPv6 packet header following the MPLS label stack are. I don't know about G-ACH, but it would certainly be prudent to have a clear understanding if or what actually does constitute proper current (pre MNA) "MPLS post stack data". And doing so in this framework document might be a good place. So far, my review assumes that there really is no pre-existing proper MPLS PSD. 4. It would be nice if the framework could venture to provide some MPLS WG agreed upon estimates of future growth requirements for MNA solutions, or else solutions will come up with either over or underscaled encodings and reviewers can not really vet how good a solution proposal is. Aka: Total of N actions that need to be encodeable N1 actions requring no further parameters N2 actions requiring 8 bit parameters N3 actions requiring 32 bit parameters N4 actions requiring 64 bit parameters worst case substack: M actions, one with 8, one with 32 bit one with 64 bit parameters Just as an idea, of course i do not know for any of these parameters the right numbers, but without the framework providing any such bounds its not sufficient for 5. Apologies for likely many typo's in my review comments. I did not want to do a full spell checker review run for the draft itself too. Detailled review: The following is the idnits numbered draft text with review comments inserted. I kept the whole draft so that readers of this review can do so with only the review text (but not a second window for the original draft). --- 2 MPLS Working Group L. Andersson 3 Internet-Draft Huawei Technologies 4 Intended status: Informational S. Bryant 5 Expires: 27 July 2024 University of Surrey 5GIC 6 M. Bocci 7 Nokia 8 T. Li 9 Juniper Networks 10 24 January 2024 12 MPLS Network Actions Framework nit: I always like for abbreviations to be included in the title, so people trying to find the document belonging to the title will find it in e.g.: rfc-index.txt or other places only including the title. Aka suggest to change to: MPLS Network Actions (MNA) Framework or Framework for MPLS Network Actions (MNA) 13 draft-ietf-mpls-mna-fwk-06 15 Abstract 17 This document specifies an architectural framework for the MPLS 18 Network Actions (MNA) technologies. MNA technologies are used to nit: I would suggest to add [ RFC-Editor: Please add "MNA - MPLS Network Action" to RFC Abbreviations List ] so your new TLA is recognized there. Somewhere in the document where you like it. 19 indicate actions for Label Switched Paths (LSPs) and/or MPLS packets 20 and to transfer data needed for these actions. nit: A bit more explanatory introduction of what "action" on the LSP or packet means would be nice. Maybe something like: ... to indicate actions that impact the forwarding or other processing (such as monitoring) of the packet along the Label Switched Path (LSP) of the packet or that impact the packet content itself. 22 The document provides the foundation for the development of a common 23 set of network actions and information elements supporting additional 24 operational models and capabilities of MPLS networks. Some of these 25 actions are defined in existing MPLS specifications, while others 26 require extensions to existing specifications to meet the 27 requirements found in "Requirements for MPLS Network Actions". 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 July 2024. 46 Copyright Notice 48 Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.2. Partial Processing . . . . . . . . . . . . . . . . . . . 7 70 2.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.3.1. Readable Label Depth . . . . . . . . . . . . . . . . 8 72 2.4. State . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1. The MNA Label . . . . . . . . . . . . . . . . . . . . . . 9 75 3.1.1. Existing Base SPL . . . . . . . . . . . . . . . . . . 9 76 3.1.2. New Base SPL . . . . . . . . . . . . . . . . . . . . 9 77 3.1.3. New Extended SPL . . . . . . . . . . . . . . . . . . 9 78 3.1.4. User-Defined Label . . . . . . . . . . . . . . . . . 10 79 3.2. TC and TTL . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.2.1. TC and TTL retained . . . . . . . . . . . . . . . . . 10 81 3.2.2. TC and TTL Repurposed . . . . . . . . . . . . . . . . 10 82 3.3. Length of the NAS . . . . . . . . . . . . . . . . . . . . 11 83 3.3.1. Last/Continuation Bits . . . . . . . . . . . . . . . 11 84 3.3.2. Length Field . . . . . . . . . . . . . . . . . . . . 11 85 3.4. Encoding of Scopes . . . . . . . . . . . . . . . . . . . 12 86 3.5. Encoding a Network Action . . . . . . . . . . . . . . . . 12 87 3.5.1. Bit Catalogs . . . . . . . . . . . . . . . . . . . . 12 88 3.5.2. Operation Codes . . . . . . . . . . . . . . . . . . . 12 89 3.6. Encoding of Post-Stack Data . . . . . . . . . . . . . . . 13 90 3.6.1. First Nibble Considerations . . . . . . . . . . . . . 13 91 4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 5. Definition of a Network Action . . . . . . . . . . . . . . . 14 93 6. Management Considerations . . . . . . . . . . . . . . . . . . 15 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 99 10.2. Informative References . . . . . . . . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 102 1. Introduction 104 This document specifies an architectural framework for the MPLS 105 Network Actions (MNA) technologies. MNA technologies are used to 106 indicate actions for Label Switched Paths (LSPs) and/or MPLS packets 107 and to transfer data needed for these actions. 109 The document provides the foundation for the development of a common 110 set of network actions and information elements supporting additional 111 operational models and capabilities of MPLS networks. Some of these 112 actions are defined in existing MPLS specifications, while others 113 require extensions to existing specifications to meet the 114 requirements found in [I-D.ietf-mpls-mna-requirements]. nit: I am somewhat confused about the above text. Let me ask whether the following text is a correct (if not better) rewrite of the goal of this document and its relationship to requirements and solutions: ... This document provides the architectural framework for the development of complementary and/or competing solutions for operational models and capabilities of MPLS which are called "MPLS Network Actions" (MNA). MNA solutions derived from this framework are intended to support all or a subset of the requirements found in [I-D.ietf-mpls-mna-requirements]. In additions, MNA solutions may also support actions for which prior solutions have been defined through existing MPLS specification, for example to make it easier to combine existing and new actions in the same MPLS packet. The MNA framework ... 116 Forwarding actions are instructions to MPLS routers to apply 117 additional actions when forwarding a packet. nit: Given how the term "forwarding action" is used in a lot more IP/IPv6 RFCs than MPLS RFCs, it is somewhat irritating to define the unqualified "forwarding action" to be something that means MPLS. Suggest to remove MPLS and then add a sentence scoping it to MPLS, e.g.: For MPLS forwarding, this term was introduced via rfc6639 and rfc8402. In this document, all use of forwarding actions refers to MPLS forwarding actions. 117 These might include 118 load-balancing a packet given its entropy, whether or not to perform 119 fast reroute on a failure, and whether or not a packet has metadata 120 relevant to the forwarding decisions along the path. nit: Suggest to avoid introducing unnecessary additional terms (forwarding decisions) without wanting to spend the space for a reference or definition. suggest: s/forwarding decisions/forwarding actions/ 122 This document generalizes the concept of "forwarding actions" into 123 "network actions" to include any action that an MPLS router is 124 requested to take on the packet. That includes any forwarding 125 action, but may include other operations (such as security functions, 126 OAM procedures, etc.) that are not directly related to forwarding of 127 the packet. minor: I am not so happy with a term as broad as "network action". Are failures/recoveries of components and resulting re-routing, change of link-speeds and the like network actions even before i look into specific traffic ? The term itself makes me think they are, but i think your definition of "network actions" likely not. Maybe "network traffic actions" may be better. And/or scoping the definition to "operations triggered by network traffic or its absence". 129 MNA technologies may use the Label, Traffic Class (TC), and Time to 130 Live (TTL) fields in an MPLS LSE for an alternative purpose. nit: LSE - expand before first use (No (*) in RFC editor abbreviation list). Please browse through all abbreviations and check for expansion on first use, i may not have been complete. nit: "alternative purpose" took a while to click for me what it is supposed to meant. I first thought that the fields themselves keep their semantic, but that the action itself would do something new with them, such as routing based on TC. maybe: MNA technologies may define new semantics for the Label, Traffic Class (TC), and Time to Live (TTL) fields in an MPLS LSE ( ... to leverage their space in the label stack when not needed for their original purpose). 132 1.1. Requirement Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. These words may also appear in this 139 document in lower case as plain English words, absent their normative 140 meanings. 142 Although this is an Informative document, these conventions are 143 applied to achieve clarity in the requirements that are presented. minor: Why then is this document only informational ? An added justification here in the text would be helpfull. "This document is informational only even though it raises normative language requirements against work referring to it because ...." 145 1.2. Terminology 147 1.2.1. Normative Definitions 149 This document adopts the definitions of the following terms and 150 abbreviations from [I-D.ietf-mpls-mna-requirements] as normative: 151 "Network Action", "Network Action Indication (NAI)", "Ancillary Data 152 (AD)", and "Scope". nit: Would be esier for readers to read the definitions here given how few those are. minor: Not happy about term "as normative" when the document is informational. 154 In addition, this document also defines the following terms: 156 * Network Action Sub-Stack (NAS): A set of related, contiguous Label nit: Abbreviation would be easier to remember if it was NASS Also less obvioust TLA overload. How many Terrabytes does your NAS have ? 157 Stack Entries (LSEs) in the MPLS label stack for carrying 158 information related to network actions. The Label, TC, and TTL 159 values in the LSEs in the NAS may be redefined, but the meaning of 160 the S bit is unchanged. 162 * Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS 163 contains a special label that indicates the start of the NAS. 165 1.2.2. Abbreviations 167 +==============+===============+==================================+ 168 | Abbreviation | Meaning | Reference | 169 +==============+===============+==================================+ 170 | AD | Ancillary | [I-D.ietf-mpls-mna-requirements] | 171 | | Data | | 172 +--------------+---------------+----------------------------------+ 173 | bSPL | Base Special | [RFC9017] | 174 | | Purpose Label | | 175 +--------------+---------------+----------------------------------+ 176 | ECMP | Equal Cost | | 177 | | Multipath | | nit: Maybe RFC3272 as reference. 178 +--------------+---------------+----------------------------------+ 179 | eSPL | Extended | [RFC9017] | 180 | | Special | | 181 | | Purpose Label | | 182 +--------------+---------------+----------------------------------+ 183 | HBH | Hop by hop | In the MNA context, this | 184 | | | document. | 185 +--------------+---------------+----------------------------------+ 186 | I2E | Ingress to | In the MNA context, this | 187 | | Egress | document. | 188 +--------------+---------------+----------------------------------+ 189 | ISD | In-stack data | [I-D.ietf-mpls-mna-requirements] | 190 +--------------+---------------+----------------------------------+ 191 | LSE | Label Stack | [RFC3032] | 192 | | Entry | | 193 +--------------+---------------+----------------------------------+ 194 | MNA | MPLS Network | [I-D.ietf-mpls-mna-requirements] | 195 | | Actions | | 196 +--------------+---------------+----------------------------------+ 197 | NAI | Network | [I-D.ietf-mpls-mna-requirements] | 198 | | Action | | 199 | | Indicator | | 200 +--------------+---------------+----------------------------------+ 201 | NAS | Network | This document | 202 | | Action Sub- | | 203 | | Stack | | 204 +--------------+---------------+----------------------------------+ 205 | PSD | Post-stack | [I-D.ietf-mpls-mna-requirements] | 206 | | data | and Section 3.6 | 207 +--------------+---------------+----------------------------------+ 208 | RLD | Readable | This document | 209 | | Label Depth | | 210 +--------------+---------------+----------------------------------+ 211 | SPL | Special | [RFC9017] | 212 | | Purpose Label | | 213 +--------------+---------------+----------------------------------+ nit: Misses NSI. 215 Table 1: Abbreviations 217 2. Structure nit: It would be lovely to include an ASCII graphics of a NAS. And highlight accordingly that the S-bit is maintained to make this more obvious. 219 An MNA solution specifies one or more actions to apply to an MPLS nit: network actions ? (also any further occurrance below) mayor: This is where i as a reader started wondering whether a network or packet is supposed to support only one or multiple MNA solutions. Aka: please clarify here or earlier. 220 packet. These actions and their parameters may be carried in sub- 221 stacks within the MPLS label stack and/or possibly post-stack data. minor: The requirements draft sounded as if both ISD and PSD are optional, whereas this sentence sounds as if only PSD was optional in the framework. If this is a conscious choice the discrepancy should be explained somewhere. nit: reference for post-stack data would be good, or definition. 222 A solution must specify where in the label stack the network actions 223 sub-stacks occur, if and how frequently they should be replicated 224 within the label stack, and how the network action sub-stack and 225 post-stack data are encoded. mayor: This is where one wonder about single versus multiple solution PSD in a single packet or network, so again, please make sure the expectation against that are explicitly describe here or earlier. 227 A network action sub-stack contains: 229 * Network Action Sub-Stack Indicator: The first LSE in the NAS 230 contains a label with special semantics, called the MNA label, 231 that is used to indicate the start of a network action sub-stack. nit: Further up in the document you introduce this LSE with the abbreviation NSI. Here you do not use the term NSI but introduce the redundant term MNA label that you then re-use i think 3 times in the document. I suggest you eliminate the redundant term MNA label and only use NSI. Alas, the term MNA label was also introduced / used by the requirements document, but that makes the unnecessary term redundancy not any more useful. Ultimately i think users of this work would prefer to use a TLA like NSI instead of MNA label. nit: Would be helpful to readers to add the following comment to unconfuse whether special semantics is just another term for special purpose. Suggested text: possible relationship between special semantics and Special Purpose Labels (SPL) is discussed in section 3.1). 233 * Network Action Indicators: Optionally, a set of indicators that 234 describes the set of network actions. If the set of indicators is 235 not in the sub-stack, a solution could encode them in post-stack 236 data. A network action is said to be present if there is an 237 indicator in the packet that invokes the action. minor: This text leaves me to wonder if such an action indicator if encoded ISD would have to be one or more additional LSE, or if it could be encoded also as part of the NASS Indicator LSE. Maybe that question is answered later, but here it leaves the reader think of the text being ambiguous/incomplete. 239 * In-Stack Data: A set of zero or more LSEs that carry ancillary 240 data for the network actions that are present. Network action 241 indicators are not considered ancillary data. nit: Introduce on first use term ISD here. Also check capitalization of term (inconsistent capitalization of Data across document). nit: previously you talked about "parameters" for network actions, now you talk about "ancillary data". So now i wonder what the parameters are and how they differ from the ancillary data. Eliminate redundant term if it's just that. 243 Each network action present in the network action sub-stack may have 244 zero or more LSEs of in-stack data. The ordering of the in-stack 245 data LSEs corresponds to the ordering of the network action 246 indicators. The encoding of the in-stack data, if any, for a network 247 action must be specified in the document that defines the network 248 action. minor: This (ordering) sounds as if each LSE can only belong to one action, but it would certainly be useful to share LSE across actions. For example a solution could define multiple actions but also a common authorization ticket LSE applying to the other actions. Aka: There may be a more complex relationship between multiple actions and their parameters in a single solution than a 1:1 mapping between action and in-stack-data for them. 250 Certain network actions may also specify that data is carried after 251 the label stack. This is called post-stack data. The encoding of 252 the post-stack data, if any, for a network action must be specified 253 in the document that defines the network action. If multiple network 254 actions are present and have post-stack data, the ordering of their 255 post-stack data corresponds to the ordering of the network action 256 indicators. minor: Same concern as last comment. 258 A solution must specify the order that network actions are to be 259 applied to the packet. minor: Usually in MPLS i would expect that stack order is execution order. It would be nice to include a simple reasoning (or even example) how MNA becomes better by that not being implied. Yes, i understand now, order of bits in an encoding for example, but on cold read that's not immediately obviously, so would be could to elaborate. 261 2.1. Scopes 263 A network action may need to be processed by every node along the 264 path, or some subset of the nodes along its path. Some of the scopes 265 that an action may have are: 267 * Hop-by-hop (HBH): Every node along the path will perform the 268 action. 270 * Ingress-to-Egress (I2E): Only the last node on the path will 271 perform the action. nit: Why is this called I2E if it only applies to egress ? minor: how would you distinguish between actions only on a) ingress, b) ingress/egress c) egress only For example consider DetNet PREOF. ingress needs to create control word with sequence number, egresss does duplicate elimination based on control word sequence number (this was actually defined by PALs for psuedowire, but never used with exactly this expensive action, but only simple switchover). In any case, are these two separate actions, one ingress, one egress ? Or one ingress/egress action.. Explanations to that end would be useful in this framework. 273 * Select: Only specific nodes along the path will perform the 274 action. 276 If a solution supports the select scope, it must describe how it 277 specifies the set of nodes to perform the actions. minor: I wonder if i am implying what is supposed to be allowed or if i am overimagining: Performing of action may be based on a combination of ISD/PSD encoding and/or LSR configuration/state. If any of this freedom is meant to be excluded, please write so. Else it would be reconfirming to include the above. 279 This framework does not place any constraints on the scope or the 280 ancillary data for a network action. Any network action may appear 281 in any scope or combination of scopes, may have no ancillary data, 282 and may require in-stack data, and/or post-stack data. Some 283 combinations may be sub-optimal, but this framework does not place 284 any limitations on an MNA solution. A specific MNA solution may 285 define such constraints. 287 2.2. Partial Processing 289 As described in [RFC3031], legacy devices that do not recognize the 290 MNA label will discard the packet if the top label is the MNA label. 292 Devices that do recognize the MNA label might not implement all of 293 the network actions that are present. A solution must specify how 294 unrecognized network actions that are present should be handled. 296 One alternative is that an implementation should stop processing 297 network actions when it encounters an unrecognized network action. 298 Subsequent present network actions would not be applied. The result 299 is dependent on the solution's order of operations. 301 Another alternative is that an implementation should drop any packet 302 that contains any unrecognized present network actions. 304 A third alternative is that an implementation should perform all 305 recognized present network actions, but ignore all unrecognized 306 present network actions. 308 Other alternatives may also be possible and should be specified by 309 the solution. 311 In some solutions, an indication may be provided in the packet or in 312 the action as to how the forwarder should proceed if it does not 313 recognize the action. Where an action needs to be processed at every 314 hop, it is recommended that care be taken not to construct an LSP 315 that traverses nodes that do not support that action. It is 316 recognised that in some circumstances it may not be possible to 317 construct an LSP that avoids such nodes, such as when a network is 318 re-converging following a failure or when IPFRR [RFC5714] is taking 319 place. minor: IMHO another strong reason to have a framework level definition for how to determine end-of-PSD without having to be able to parse the whole ISD. 321 2.3. Signaling 323 A node that wishes to make use of MNA and apply network actions to a 324 packet must understand the nodes that the packet will transit and 325 whether or not the nodes support MNA and the network actions that are 326 to be invoked. nit: Should this not always be "MNA solution" instead of "MNA" in this paragraph ? minor: Why ? Aka: there are all type of cases where good or baad things happen if this is not the case. For example, i should be able to build an action that happens for each hop, but if the hop doesn't support the action, it ignores it, right ? And thats may be a good thing - or maybe not. I would suggest rephrase to something like: Various networking functions such as (nonwithstanding) diagnostics, operations, orchestration and instantiation of network services may need to understand exactly which nodes support which actions to determine which actions and parameters to invoke on which node, which optimal encoding to use and what results to expect. 326 to be invoked. These capabilities are presumed to be signaled by 327 protocols that are out-of-scope for this document and are presumed to 328 have per-network action granularity. If a solution requires 329 alternate signaling, it must specify so explicitly. nit: "alternate signaling" meaning what ? The prior sentence allows all signaling, it only expects some specific granularity, so if anything was alternate it would be degree of granularity ?? Something like: The signalings should allow to indicate all differences in support and configuration of the MNA solution that can be of interest to any of the aforementioned functions. 331 2.3.1. Readable Label Depth 333 [RFC8662] introduced the concept of Entropy Readable Label Depth 334 (ERLD). Readable Label Depth (RLD) is the same concept, but 335 generalized and not specifically associated with the Entropy Label 336 (EL) or MNA. Readable Label Depth is defined as the number of LSEs, 337 starting from the top of the stack, that a router can read in an 338 incoming MPLS packet with no performance impact. 340 ERLD is not redundant with respect to RLD because ERLD specifically 341 specifies a value of zero if a system does not support the Entropy 342 Label. Since a system could reasonably support MNA or other MPLS 343 functions and need to advertise an RLD value but not support the 344 Entropy Label, another advertised value is required. nit: I would move all mentioning of ERLD from 333-338 to the beginning of 334, and make that paragraph a "Note:" 346 A node that pushes an NAS onto the label stack is responsible for 347 ensuring that all nodes that are expected to process the NAS will 348 have the entire NAS within their RLD. A node SHOULD use signaling 349 (e.g., [RFC9088], [RFC9089]) to determine this. minor/Q: Any requirements against nodes if a NASS can only be read partially by a node because it's too deep ? "All Hell Breaks Loose" ? 351 Per [RFC8662], a node that does not support EL will advertise a value 352 of zero for its ERLD, so advertising ERLD alone does not suffice in 353 all cases. A node MAY advertise both ERLD and RLD. minor: Is this trying to say something/different from 333-338, or is this just redundant ? If not redundant, please rephrase because i can't see a difference. Else delete. 355 RLD is advertised by an IGP MSD-Type value of (TBA) and MAY be 356 advertised as a Node MSD, Link MSD, or both. minor: I guess the allocation of a single MSD-Type means that there can only be a single MSD solution be deployed at the same time, or else they would need to be implemented with the same RLD... Aka: If we do want to allow specification of more than one MNA solution, then i think there should be a per-MNA-solution RLD and the MNA solution should reques the RLD MSD-Type. 358 An MNA node MUST use the RLD determined by selecting the first 359 advertised non-zero value from: 361 * The RLD advertised for the link. 363 * The RLD advertised for the node. 365 * The non-zero ERLD for the node. minor: Why would we ever trust the ERLD to be an authoritative replacement for RLD ? An MNA solution requires new forwarding plane firmware (AFAIK quite expensive), but we don't want to expect the vendor to also implement the IGP MSD-Type in the control plane ? That's just unnecessary case permutation complexity and guesswork. Heck, didn't the draft state that the supported actions etc. would need to be implemented in the protocol (i assume also IGP) ??? Aka: suggest to remove 365. KISS. 367 2.4. State 369 A network action can affect the state stored in the network. This 370 implies that a packet may affect how subsequent packets are handled. 371 In particular, one packet may affect subsequent packets in the same 372 LSP. 374 3. Encoding 376 Several possible ways to encode NAIs have been proposed. In this 377 section, we enumerate the possibilities and some considerations for nit: s/enumerate the possibilities/summarize the options proposed/ ?? 378 the various alternatives. In this section, we enumerate the 379 possibilities and some considerations for the various alternatives. nit: duplicate text ?! 381 When network actions are carried in the MPLS label stack, then 382 regardless of their type, they are represented by a set of LSEs 383 termed a network action sub-stack (NAS). An NAS consists of a 384 special label, optionally followed by LSEs that specify which network 385 actions are to be performed on the packet and the in-stack ancillary 386 data for each indicated network action. Different network actions 387 may be placed together in one NAS or may be carried in different sub- 388 stacks. 390 [I-D.ietf-mpls-mna-requirements] requires that a solution not add 391 unnecessary LSEs to the sub-stack (Section 3.1, requirement 9). 392 Accordingly, solutions should also make efficient use of the bits nit: "...of the available bits (all except S-bit) within the..." ?? Is that correct understanding ? If so, would be nice to write for reconfirmation by readers... 393 within the sub-stack, as inefficient use of the bits could result in 394 the addition of unnecessary LSEs. 396 3.1. The MNA Label 398 The first LSE in a network action sub-stack contains a special label 399 that indicates a network action sub-stack. A solution has several 400 choices for this special label. 402 3.1.1. Existing Base SPL 404 A solution may reuse an existing Base SPL (bSPL). If it elects to do 405 so, it must explain how the usage is backward compatible, including 406 in the case where there is ISD. minor: Are NASS considered to be ISD (or at least part of the NASS) ? If not, then that would be good to define upfront somewhere. But when ISD also includes some of NASS, but you mean pre-NASS ISD, then maybe s/ISD/non MNA solution introduced ISD/ (or legacy ISD, or whatever seems most accurately explanatory). 408 If an existing inactive bSPL is selected and its usage would not be 409 backward compatible, then it must first be retired per [RFC7274] and 410 then reallocated. 412 3.1.2. New Base SPL 414 A solution may select a new bSPL. suggestion: I would just ask for allocation of e.g.: 3 bSPL as configurable. Not really that difficult to match consistent configuration of bSPL semantic through control plane between adjacent SLR and not sending MPLS pckets to a neighbor with inconsistent config. That way a network could use up to three new bSPL based specs, MNA or other new semantics in parallel, as long as it's ok. to expect full hop-by-hop configuration consistency. Just as one option. But no idea how important partial MNA deployments are. But it would be good to explore exit strategies from shrinking bSPL space other than increasing label stack size. 416 3.1.3. New Extended SPL 418 A solution may select a new eSPL. If it elects to do so, it must 419 address the requirement for the minimal number of LSEs. 421 3.1.4. User-Defined Label 423 A solution may allow the network operator to define the label that 424 indicates the network action sub-stack. This creates management 425 overhead for the network operator to coordinate the use of this label 426 across all nodes on the path using management or signaling protocols. 427 The user-defined label could be network-wide or LSP-specific. If a 428 solution elects to use a user-defined label, the solution should 429 justify this overhead. minor: isn't the problem rather that it may be unclear whether the same label could be configured across different vendors ? If there is sufficient understanding that this can always be possible, it would be good to point to that. My understanding was that the whole label->SID mapping was because there is no consistent use of MPLS label space across vendors. minor: If there is no multi-vendor "finding common label" issue, then i think the rest is not really a problem. I would simply add a requirement for an IETF standards based YANG model for the configuration of the user-defined label before such an MNA solution can become standard. 431 3.2. TC and TTL 433 In the first LSE of the network action sub-stack, only the 20 bits of 434 Label Value and the Bottom of Stack bit are significant for MNA 435 purposes; the TC field (3 bits) and the TTL (8 bits) are not used. nit: The way its written i think it's logically a bit self contradictory. If you would assign TC/TTL to something in the MNA encoding then it would become "significant to MNA purposes". I think instead of "significant for MNA purposes" it should be "used for the NAI". 436 This could leave 11 bits that could be used for MNA purposes. 438 3.2.1. TC and TTL retained 440 If the solution elects to retain the TC and TTL fields, then the 441 first LSE of the network action sub-stack would appear as: 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Label | TC |S| TTL | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Label: Label value, 20 bits 449 TC: Traffic Class, 3 bits 450 S: Bottom of Stack, 1 bit 451 TTL: Time To Live 453 Further LSEs would be needed to encode NAIs. If a solution elects to 454 retain these fields, it must address the requirement for the minimal 455 number of LSEs. 457 3.2.2. TC and TTL Repurposed 459 If the solution elects to reuse the TC and TTL fields, then the first 460 LSE of the network action sub-stack would appear as: 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Label |x x x|S|x x x x x x x x| 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Label: Label value, 20 bits 468 x: Bit available for use in solution definition 469 S: Bottom of Stack, 1 bit 471 The solution may use more LSEs to contain NAIs. If a solution elects 472 to use more LSEs it must address the requirement for the minimal 473 number of LSEs. 475 3.3. Length of the NAS 477 A solution must have a mechanism (such as an indication of the length 478 of the NAS) to enable an implementation to find the end of the NAS. 479 This must be easily processed even by implementations that do not 480 understand the full contents of the NAS. Two options are described 481 below, other solutions may be possible. 483 3.3.1. Last/Continuation Bits 485 A solution may use a bit per LSE to indicate whether the NAS 486 continues into the next LSE or not. The bit may indicate 487 continuation by being set or by being clear. The overhead of this 488 approach is one bit per LSE and has the advantage that it can 489 effectively encode an arbitrarily sized NAS. This approach is 490 efficient if the NAS is small. 492 3.3.2. Length Field 494 A solution may opt to have a fixed size length field at a fixed 495 location within the NAS. The fixed size of the length field may not 496 be large enough to support all possible NAS contents. This approach 497 may be more efficient if the NAS is longer but not longer than can be 498 described by the length field. 500 Advice from hardware designers advocates a length field as this 501 minimizes branching in the logic. minor: Does that not depend on encoding ? and FPE ? Aka: If i have action1, action1-parameter, action2, axction2-parameter, ... then continuation bit might be easier to parse this, but if i have action-set, action1-parameter, action2-parameter, then a length field might be better. Aka: make sure you're not providing one-sided guidance. 503 3.4. Encoding of Scopes 505 A solution may choose to explicitly encode the scope of the actions 506 contained in a network action sub-stack. A solution may also choose 507 to have the scope encoded implicitly, based on the actions present in 508 the network action sub-stack. This choice may have performance nit: So lets say i have one type of action called FOO, but i do create two actions out of it, one would be "FOO-on-every-LSR" and the other "FOO-only-on-explicitly-configured-LSR-for-FOO". Which of the two described options would that be ? In other words: i am not sure i do understand the disctinction completely. 508 the network action sub-stack. This choice may have performance 509 implications as an implementation might have to parse the network 510 actions that are present in a network action sub-stack only to 511 discover that there are no actions for it to perform. nit: Without an example, it is not clear to me what the most obvious encoding option based choice would be to minimize the need to parse network actions unnecessarily. Aka: if you can, please insert such an example. 513 Solutions need to consider the order of scoped NAIs and their 514 associated AD within individual sub-stacks and the order of per-scope 515 sub-stacks so that network actions and the AD can be most readily 516 found and not need be processed by nodes that are not required to 517 handle those actions. nit: IMHO, 513-517 would make a better start than conclusion of this section. 519 3.5. Encoding a Network Action 521 Two options for encoding NAIs are described below, other solutions 522 may be possible. Any solution should allow the encoding of an 523 arbitrary number of NAIs. 525 3.5.1. Bit Catalogs 527 A solution may opt to encode the set of network actions as a list of 528 bits, sometimes known as a catalog. The solution must provide a 529 mechanism to determine how many LSEs are devoted to the catalog when 530 the NAIs are carried in-stack. A set bit in the catalog would 531 indicate that the corresponding network action is present. 533 Catalogs are efficient if the number of present network actions is 534 relatively high and if the size of the necessary catalog is small. 535 For example, if the first 16 actions are all present, a catalog can 536 encode this in 16 bits. However, if the number of possible actions 537 is large, then a catalog can become inefficient. Selecting only one 538 action that is the 256th action would require a catalog of 256 bits, 539 which would require more than one LSE when the NAIs are carried in- 540 stack. 542 A solution may include a bit remapping mechanism so that a given 543 domain may optimize for its commonly used actions. 545 3.5.2. Operation Codes 547 A solution may opt to encode the set of present network actions as a 548 list of operation codes (opcodes). Each opcode is a fixed number of 549 bits. The size of the opcode bounds the number of network actions 550 that the solution can support. 552 Opcodes are efficient if there are only one or two active network 553 actions. For example, if an opcode is 8 bits, then two active 554 network actions could be encoded in 16 bits. However, if 16 actions 555 are required, then opcodes would consume 128 bits. Opcodes are 556 efficient at encoding a large number of possible actions. If only 557 the 256th action is to be selected, that still requires 8 bits. 559 3.6. Encoding of Post-Stack Data 561 A solution may carry some NAI and AD as PSD. For ease of parsing, 562 all AD should be co-located with its NAI. minor: If i am not mistaken, today, the only component that is considered to be part of an "MPLS header" is the "MPLS label stack". E.g.: a pseudo-wire header including it's control word is considered to be it's own header. And in result, one has never needed or wanted to use the term "MPLS header", but could always refer to "MPLS label stack". With the introduction of (even optional) PSD, this changes. And in result i think this document should at an appropriate place (maybe earlier than here) introduce the term "MPLS header" (or any other/better term) to refer to the combination of MPLS label stack plus PSD. Which it effectively refers to in places, but only calls it MPLS label stack. 564 If there are multiple instances of post-stack data, they should occur 565 in the same order as their relevant network action sub-stacks and 566 then in the same order as their relevant network actions occur within 567 the network action sub-stacks. mayor: I don't think this is sufficient. The framework needs a definition that allows packet parsers to skip across PSD, and it needs a framework definition for how multiple different solutions could share PSD space. Even if there is only one solution supposed to be useable in one packet. This is not different from what the framework does for ISD: The parser can skip across the label stack using the S-Bit, and the different NAS indicator methods defined in this document introduce the ability to mix & match different solution ISD together with the extraction of Readable Label Depth from all LSR to even create label stacks (whether or not this is a requirement is as mentioned elsewhere unclear from the doc). If skipping beyond PSD with a simple method from the framework is not included, then the whole parsing with PSD would becomes more fragile. Being able to parse beyond PSD must not be dependent on network wide MNA solution configuration but from framework specification (IMHO). And i also do not see a way to mix two solutions without having an equvalent previously known structure like the NAS indicator labels. I don't think one wants to repeat the use of S-Bit for within PSD though. One of the big benefits of PSD over ISD would be to easier have contiguous parameters of 32 bits or longer without being interrupted by the S-Bits. I would suggest to consider including something like the following as PSD separators for the framework: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PSDcod | Rsv |Total PSD len | Next Hdr | Next Hdr len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aka: PSDcod would be something no 0, 4, 6 to most easily recognize PSD for ECMP and other purposes (aka: first Nibble). Total PSD len would allow to skip with one lookup beyond all PSD blocks for for operations such as ECMP that would want to do this in the presence of PSD. Next Hdr would be a new registry that could include both registration points for MNA solution PSD (one or more per solution) as well as existing next-headers, and Next Hdr len would be those headers/PSD (sub-headers) len. Just an example and to demonstrate what seem to be the salient info fields needs: First Nibble compatibility, single length field to skip all PSD, and ability to chain different solution PSD. And likely make it fit into 32 bits. 569 3.6.1. First Nibble Considerations 571 The first nibble after the label stack has been used to convey 572 information in certain cases [RFC4385]. A consolidated view of first 573 nibble uses is provided in [I-D.ietf-mpls-1stnibble]. 575 For example, in [RFC4928] this nibble is investigated to find out if 576 it has the value "4" or "6". If it is not, it is assumed that the 577 packet payload is not IPv4 or IPv6, and Equal Cost Multipath (ECMP) 578 is not performed. 580 It should be noted that this is an inexact method. For example, an 581 Ethernet Pseudowire without a control word might have "4" or "6" in 582 the first nibble and thus will be ECMP'ed. 584 Nevertheless, the method is implemented and deployed, it is used 585 today and will be for the foreseeable future. 587 The use of the first nibble for BIER is specified in [RFC8296]. BIER 588 sets the first nibble to 5. The same is true for a BIER payload as 588 sets the first nibble to 5. The same is true for a BIER payload as 589 for any use of the first nibble: it is not possible to conclude that 590 the payload is BIER even if the first nibble is set to 5 because an 591 Ethernet pseudowire without a control word might begin with a 5. 592 However, the BIER approach meets the design goal of [RFC8296] to 593 determine that the payload is IPv4, IPv6 or a pseudowire using a 594 control word. 596 [RFC4385] allocates 0b0000 for the pseudowire control word and 0b0001 597 as the control word for the pseudowire Associated Channel Header 598 (ACH). 600 A PSD solution should specify the contents of the first nibble, the 601 actions to be taken for the value, and the interaction with post- 602 stack data used concurrently by other MPLS applications. nit: I would move 600-602 after 585. Then reconsider why the text about BIER, 587-594 exists, because it reads confusingly. I think you want to say that a PSD solution that wants to avoid for pre-existing ECMP to occur and/or that does not want to get confused with a Pseudowire header with control word should use a Nibble value other then 0, 4 or 6 - and one example of a mechanism that does already apply this logic is the BIER encapsulation of RFC8296. And leave it with that. But i am not sure if this BIER encapsulation is the most easy to understand example approach given how it was heavily tweaked around MPLS (making the last LSE of the MPLS label stack the first 32 bit of its own header), buit through its doc evolution started also to claiming and that it is an MPLS and non-MPLS solution and calling the label BIFT-ID instead of showing the label field, and hence making it severely confusing why those Nibble bits are there to the non-expert reader. If there is another, more simpler example using a desirable the Nibble approach than BIER, maybe replace the text with such an example. minor: I think the PSD section is jumping into details before making a fundamental statement like: PSD is a new (optional) element of the MPLS header and hence extending the MPLS header beyond the BoS LSE. In result, an MNA specification using PSD needs to specify how current deployed (and layer violating) MPLS functions that inspect and operate on data beyond BoS LSE (heuristically!) are supposed to operate in the presence of the new PSD. Then you have a better context of bringing up the example of ECMP and may recommend for PSD to inhibit the ECMP function through an appropriate choice of Nibble. But likewise, if these layer violating existing functions are considered valuable, then the PSD solution should also include an explanation how to parse to the end of the MPLS header, aka: beyond the end of PSD. And/or specify a mechanism for a PSD encoding to allow/prohibit for that to happen (because it may be undesired by the desired packet processing). 604 4. Semantics 606 For MNA to be consistent across implementations and predictable in 607 operational environments, its semantics need to be entirely 608 predictable. An MNA solution MUST specify a deterministic order for 609 processing each of the Network Actions in a packet. Each network 610 action must specify how it interacts with all other previously 611 defined network actions. Private network actions MUST be included in 612 the ordering of network actions, but the interactions of private 613 actions with other actions are outside of the scope of this document. minor: First and only use of "Private (network action)". Aka: explain a bit of what you think a Private network action is (such as some different type of specification ?), or else remove the last sentence. 615 5. Definition of a Network Action 617 Network actions should be defined in a document and must contain: 619 * Name: The name of the network action. 621 * Network Action Indicator: The bit position or opcode that 622 indicates that the network action is active. 624 * Scope: The document should specify which nodes should perform the 625 network action as described in Section 2.1. 627 * State: The document should specify if the network action can 628 modify state in the network, and if so, the state that may be 629 modified and its side effects. 631 * Required/Optional: The document should specify whether a node is 632 required to perform the network action. 634 * In-Stack Data: The number of LSEs of in-stack data, if any, and 635 its encoding. If this is of a variable length, then the solution 636 must specify how an implementation can determine this length 637 without implementing the network action. 639 * Post-Stack Data: The encoding of post-stack data, if any. If this 640 is of a variable length, then the solution must specify how an 641 implementation can determine this length without implementing the 642 network action. 644 A solution should create an IANA registry for network actions. 646 6. Management Considerations 648 Network operators will need to be cognizant of which network actions 649 are supported by which nodes and will need to ensure that this is 650 signaled. Some solutions may require network-wide configuration to 651 synchronize the use of the labels that indicate the start of an NAS. 652 Solution documents must make clear what management considerations 653 apply to the solutions they are describing. Solutions documents must 654 describe mechanisms for performing network diagnostics in the 655 presence of MNAs. nit: Maybe call this "operational considerations". minor: I would love to see a requirement that all MNA solution must have a YANG specification of all the parameters required to build MNA label stacks through them. Aka: including the use of labels that indicate the start of a NAS as well as any other parameters, including (but not limited to) as network actions supported by nodes supporting (a subset of) the MNA solution. I also think that would be a good replacement for 648-651. I don't think we should be happy with just "CLI" network wide configuration, and we should also not end up in a hodgepodge of protocol solutions for signaling. One solution promoting to only use e.g.: IGP, the other only YANG. Aka: make YANG mandatory to specify and let other signaling options be subject to downstream decisions. 657 7. Security Considerations minor: It would be good to go through the security related requirements in the requirements document and determine how to explicitly refer to them and address them in this document. E.g.: 12. The design of any network action solution MUST NOT expose information that is not already exposed to the PE to the LSRs. It MUST NOT expose any information that a user of any service using the LSP considers confidential [RFC6973] [RFC3552] . 13. Network action solutions MUST NOT expose information considered confidential to the user of the MPLS-based service [RFC6973] to the LSRs. Could be discussed in the security section as follows: Network Actions introduce the generic challenge of moving potentially sensitive information from NHLFE to label stacks. In an MPLS network without hop-by-hop encryption, the sensitive information caried in sub stacks or PSD is likely a lot easier to exploit than whats only in LSR NHLFE state (and assumingly signalled via encrypted control plane). Deployments requring such higher confidentiality of MPLS packets because of MNA need to accordingly put stronger emphasis on per-hop encryption of MPLS packets (or other forms of confidentiality). pointing to IMHO a higher need for hop-by-hop encryption if/when such sensitive 14. Solution specifications MUST document any new security considerations that they introduce. As mentionined initially, inherit into this framework text. 659 An analysis of the security of MPLS systems is provided in [RFC5920], 660 which also notes that the MPLS forwarding plane has no built-in 661 security mechanisms. 663 Central to the security of MPLS networks is operational security of 664 the network; something that operators of MPLS networks are well 665 versed in. The deployment of link-level security (e.g., [MACsec]) 666 prevents the covert acquisition of the label stack for an attack. 667 This is particularly important in the case of a network deploying 668 MNA, because the MNA information may be sensitive. Thus the 669 confidentiality and authentication achieved through the use of link- 670 level security is particularly advantageous. 672 Some additional proposals to add encryption to the MPLS forwarding 673 plane have been suggested [I-D.ietf-mpls-opportunistic-encrypt], but 674 no mechanisms have been agreed upon at the time of publication of 675 this document. [I-D.ietf-mpls-opportunistic-encrypt] offers hop-by- 676 hop security that encrypts the label stack and is functionally 677 equivalent to that provided by [MACsec]. Alternatively, it also 678 offers end-to-end encryption of the MPLS payload with no 679 cryptographic integrity protection of the MPLS headers. 681 Particular care would be needed when introducing any end-to-end 682 security mechanism to allow an in-stack MNA solution that needed to 683 employ on-path modification of the MNA data, or where post-stack MNA 684 data needed to be examined on-path. minor: This makes it sound as if this is a new MNA challenge, whereas AFAIK the same problem exists already since day 1 for the MPLS label stack. So, unless i am not mistaken, it would help to clarify that MNA simply shares this challenge with MPLS itself. 686 A cornerstone of MPLS security is to protect the network from 687 processing MPLS labels originated outside the network. 689 Operators have considerable experience in excluding raw MPLS-encoded nit: What is a raw MPLS-encoded packet ? Either just say MPLS packet or define the term/difference. 690 packets at the network boundaries for example, by excluding all MPLS 691 packets and all packets that are revealed to be carrying an MPLS 692 packet as the payload of IP tunnels. Where such packets are accepted 693 into an MPLS network from an untrusted third party, non-MPLS packets 694 are immediately encapsulated in an MPLS label stack specified by the 695 MPLS network operator and raw-MPLS packets have additional label 696 stack entries imported as specified by the MPLS network operator. 697 Thus, it is difficult for an attacker to pass a raw MPLS-encoded 698 packet into a network or to present any instructions to the network 699 forwarding system. 701 Within a single well-managed domain, an adjacent domain may be 702 considered to be trusted provided that it is sufficiently shielded 703 from third-party traffic ingress and third-party traffic observation. 704 In such a situation, no new security vulnerabilities are introduced 705 by MNA. mayor: But there is no requirement specified so far that such collaborating MPLS domains would need consistent configuration of e.g.: NAS start label, so there may be no malicious attack, but it just wouldn't work. Not to speak of knowing inter-domain thr supported actions. Unless the solution just attempts to MPLS-tunnel through the collaborating MPLS domain, which still wouldn't necessarily work in the presence of axctions with lookahead or PSD unless all that is consistent... Maybe put a paragraph to this extend into the management/operational considerations section given how its not about (intentional) attack vectors... 707 In some inter-domain applications (including carrier's carrier) where 708 a first network's MPLS traffic is encapsulated directly over a second 709 MPLS network by simply pushing additional MPLS LSEs, the contents of 710 the first network's payload and label stack may be visible to the 711 forwarders in the second network. Historically this has been benign, 712 and indeed useful for ECMP. However, if the first network's traffic 713 has MNA information this may be exposed to MNA-capable forwarders 714 causing unpredictable behaviour or modification of the customer MPLS 715 label stack or MPLS payload. This is an increased vulnerability 716 introduced by MNA that SHOULD be addressed in any MNA solution. 718 Several mitigations are available to an operator: 720 a) Reject all incoming packets containing MNA information that do not 721 come from a trusted network. Note that it may be acceptable to 722 accept and process MNA information from a trusted network. 724 b) Fully encapsulate the inbound packet in a new additional MPLS 725 label stack such that the forwarder finds a BoS bit imposed by the 726 carrier network and only finds MNA information added by the carrier 727 network. minor: "MPLS label stack" here hould be "MPLS header" (as mentioned above) because it could include PSD. minor: In fact, one type of PSD could simply be an indication "end of MPLS header" (along the above described First Nibble options). Maybe we would even want to make it a requirement in this document for MNA solutions to include text about how to "fully encapsulate" an MPLS header when usingthat MNA solution. This does not have to be PSD based, but if it is not PSD based, then the MNA solution would have to describe how any of the other options would work with the ECMP and other post-stack legacy behavior. I'd certainly be in favor of providing a clear MPLS header separation from following data via PSD to potentially avoid running into these legacy compatibility issues. 729 A mitigation that we reject as unsafe is having the ingress LSR push 730 sufficient additional labels such that any MNA information received 731 in packets entering the network from a third-party network is made 732 inaccessible due to it being below the RLD. This is unsafe in the 733 presence of an overly conservative RLD value which can result in the 734 third-party MNA information becoming visible to and acted on by an 735 MNA forwarder in the carrier network. minor: Not quite sure about the wording here. I guess the point is that the RLD is only a guarantee that the LSR can at least look as deep as RLD, but it is no guarantee that the LSR will not be able to look deeper ?? If so, then say so. Maybe even revisit the initial text about RLD in this spec (337 ff). E.g.: add that RLD is just a minimum guarantee, and that the LSR may be able to look deeper (but just not consistently enough to guarantee it). If instead RLD is really meant to be a very accurate depth (min = max), then the above text makes no sense to me. However i full agree that we should never simply concatenate MPLS label stacks between non-trusting domains. Besides it wouldn't work with PSD on the out MPLS header anyhow. 737 8. IANA Considerations 739 This document requests that IANA allocate a code point from the "IGP 740 MSD-Types" registry in the "Interior Gateway Protocol (IGP) 741 Parameters" namespace for "Readable Label Depth", referencing this 742 document. 744 9. Acknowledgements 746 This document is the result of work started in MPLS Open Design Team, 747 with participation by the MPLS, PALS, and DETNET working groups. 749 The authors would like to thank Adrian Farrel for his contributions 750 and to John Drake and Jie Dong for their comments. 752 10. References 754 10.1. Normative References 756 [I-D.ietf-mpls-mna-requirements] 757 Bocci, M., Bryant, S., and J. Drake, "Requirements for 758 Solutions that Support MPLS Network Actions", Work in 759 Progress, Internet-Draft, draft-ietf-mpls-mna- 760 requirements-08, 11 December 2023, 761 <https://datatracker.ietf.org/doc/html/draft-ietf-mpls- 762 mna-requirements-08>. 764 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 765 Requirement Levels", BCP 14, RFC 2119, 766 DOI 10.17487/RFC2119, March 1997, 767 <https://www.rfc-editor.org/info/rfc2119>. 769 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 770 Label Switching Architecture", RFC 3031, 771 DOI 10.17487/RFC3031, January 2001, 772 <https://www.rfc-editor.org/info/rfc3031>. 774 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 775 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 776 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 777 <https://www.rfc-editor.org/info/rfc3032>. 779 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 780 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 781 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 782 February 2006, <https://www.rfc-editor.org/info/rfc4385>. 784 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 785 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 786 <https://www.rfc-editor.org/info/rfc5920>. 788 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 789 and Retiring Special-Purpose MPLS Labels", RFC 7274, 790 DOI 10.17487/RFC7274, June 2014, 791 <https://www.rfc-editor.org/info/rfc7274>. 793 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 794 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 795 May 2017, <https://www.rfc-editor.org/info/rfc8174>. 797 [RFC9017] Andersson, L., Kompella, K., and A. Farrel, "Special- 798 Purpose Label Terminology", RFC 9017, 799 DOI 10.17487/RFC9017, April 2021, 800 <https://www.rfc-editor.org/info/rfc9017>. 802 10.2. Informative References 804 [I-D.ietf-mpls-opportunistic-encrypt] 805 Farrel, A. and S. Farrell, "Opportunistic Security in MPLS 806 Networks", Work in Progress, Internet-Draft, draft-ietf- 807 mpls-opportunistic-encrypt-03, 28 March 2017, 808 <https://datatracker.ietf.org/doc/html/draft-ietf-mpls- 809 opportunistic-encrypt-03>. 811 [I-D.ietf-mpls-1stnibble] 812 Kompella, K., Bryant, S., Bocci, M., Mirsky, G., 813 Andersson, L., and J. Dong, "IANA Registry for the First 814 Nibble Following a Label Stack", Work in Progress, 815 Internet-Draft, draft-ietf-mpls-1stnibble-02, 5 July 2023, 816 <https://datatracker.ietf.org/doc/html/draft-ietf-mpls- 817 1stnibble-02>. 819 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 820 Cost Multipath Treatment in MPLS Networks", BCP 128, 821 RFC 4928, DOI 10.17487/RFC4928, June 2007, 822 <https://www.rfc-editor.org/info/rfc4928>. 824 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 825 RFC 5714, DOI 10.17487/RFC5714, January 2010, 826 <https://www.rfc-editor.org/info/rfc5714>. 828 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 829 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 830 for Bit Index Explicit Replication (BIER) in MPLS and Non- 831 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 832 2018, <https://www.rfc-editor.org/info/rfc8296>. 834 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 835 Shakir, R., and J. Tantsura, "Entropy Label for Source 836 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 837 DOI 10.17487/RFC8662, December 2019, 838 <https://www.rfc-editor.org/info/rfc8662>. 840 [RFC9088] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 841 and M. Bocci, "Signaling Entropy Label Capability and 842 Entropy Readable Label Depth Using IS-IS", RFC 9088, 843 DOI 10.17487/RFC9088, August 2021, 844 <https://www.rfc-editor.org/info/rfc9088>. 846 [RFC9089] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 847 and M. Bocci, "Signaling Entropy Label Capability and 848 Entropy Readable Label Depth Using OSPF", RFC 9089, 849 DOI 10.17487/RFC9089, August 2021, 850 <https://www.rfc-editor.org/info/rfc9089>. 852 [MACsec] IEEE Computer Society, "IEEE 802.1AE Media Access Control 853 (MAC) Security", August 2006. 855 Authors' Addresses 857 Loa Andersson 858 Huawei Technologies 859 Email: loa@pi.nu 861 Stewart Bryant 862 University of Surrey 5GIC 863 Email: sb@stewartbryant.com 865 Matthew Bocci 866 Nokia 867 Email: matthew.bocci@nokia.com 869 Tony Li 870 Juniper Networks 871 Email: tony.li@tony.li Thanks a lot folks!