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

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

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 81741C14F5FD; Wed, 3 Apr 2024 16:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9yxXYpJbnQmZ; Wed, 3 Apr 2024 16:22:47 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E125CC14F5F6; Wed, 3 Apr 2024 16:22:39 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4V914V4QJwznkT4; Thu, 4 Apr 2024 01:22:34 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4V914V3YnZzknHm; Thu, 4 Apr 2024 01:22:34 +0200 (CEST)
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/rtg-dir/v1jtygtmx_BcbgC6RVpwVLzoOUI>
Subject: [RTG-DIR] RtgDir Early review: draft-ietf-mpls-mna-fwk-06.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2024 23:22:50 -0000

I have been selected to do a routing directorate “early” review of this draft.

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


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.


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

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


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

    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


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.


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 

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].


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. 


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.

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.

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.

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.

"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.


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",
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.


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".


Would be esier for readers to read the definitions here given how few those are.


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


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     |                                  |


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	    +--------------+---------------+----------------------------------+


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)


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.


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.


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.


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.


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.


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.


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).


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.


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.


Same concern as last comment.

258	   A solution must specify the order that network actions are to be
259	   applied to the packet.


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 ?


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.


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.


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.


Should this not always be "MNA solution" instead of "MNA" in this paragraph ?


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.


"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.


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.


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.


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.


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.


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


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.


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


"...of the available bits (all except S-bit) within the..." ??
Is that correct understanding ? If so, would be nice to write for reconfirmation by

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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


Maybe call this "operational considerations". 


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


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.


   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.


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


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.


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.


"MPLS label stack" here hould be "MPLS header" (as mentioned above) because it could
include PSD.


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.


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!