[mpls] RtgDir Early review: draft-ietf-mpls-mna-fwk-06.txt

Toerless Eckert <tte@cs.fau.de> Wed, 03 April 2024 23:22 UTC

Date: Thu, 04 Apr 2024 01:22:34 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: mpls-chairs@ietf.org, draft-ietf-mpls-mna-fwk@ietf.org
Cc: rtg-dir@ietf.org, mpls@ietf.org
Message-ID: <Zg3kupJ9jovwpzbY@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/i2C1J6siaeFB55IBOdsqtfm38AY>
Subject: [mpls] RtgDir Early review: draft-ietf-mpls-mna-fwk-06.txt
Precedence: list

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

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!

[mpls] RtgDir Early review: draft-ietf-mpls-mna-f… Toerless Eckert
Re: [mpls] RtgDir Early review: draft-ietf-mpls-m… Tony Li
Re: [mpls] RtgDir Early review: draft-ietf-mpls-m… Loa Andersson
Re: [mpls] RtgDir Early review: draft-ietf-mpls-m… Loa Andersson