Skip to main content

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 14)
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)
Rtgdir Last Call review of -11 by Donald E. Eastlake 3rd (diff)
Secdir Last Call review of -11 by Catherine Meadows (diff)
Genart Last Call review of -12 by Jouni Korhonen (diff)
Secdir Last Call review of -12 by Catherine Meadows (diff)
Tsvart Last Call review of -12 by Joerg Ott (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 14)
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!