MPLS Network Action (MNA) Sub-Stack Specification including In-Stack Network Actions and Data
draft-ietf-mpls-mna-hdr-21

[Ballot discuss]
Thank you for the work put into this document and its revised -20. This work looks very similar to the IPv6 extensions headers and to SRv6 Network Programming. So, as INT AD and working with IPv6 extension headers for 15+ years, I am afraid that I have some real concerns about this document. And, as usual, I will be happy to stand corrected.

Thanks for addressing all other blocking DISCUSS and non-blocking COMMENT point (see https://mailarchive.ietf.org/arch/msg/mpls/U303kD5kcFD0DOwboBWIHOpxtPQ/)

The -20 is in much better shape and more readable (especially section 3).

BUT here is still one remaining blocking DISCUSS point (see below).

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

### Section 7 (and now content of section 8)

`If the NAS is to be processed by a downstream MNA-capable node, then the entire NAS MUST be placed so that it is within RLD by the time the packet reaches the downstream MNA-capable node` is missing a normative reference on how a node knows about the RLD of the downstream node.

The section 8 in -20 has a new paragraph:

`The encapsulating node MAY learn about RLD of the nodes in the path via signalling. The work in-progress document [I-D.liu-lsr-mpls-inspection-msd] defines the mechanism to signal MPLS RLD.`

The MAY here is the issue. Why not "The encapsulating node MUST learn about RLD of the nodes in the path." ? Again, my IPv6 experience leads me to consider the proposed system as really fragile.

I also fear that the informative reference [I-D.liu-lsr-mpls-inspection-msd] is an individual draft expired since March 2024...

[Ballot comment]
Thank you to the authors and the WG for their work on this document.

This document introduces a significant change to the decades-old MPLS architecture; by incorporating concepts similar to IPv6 extension headers (HBH, DOH, RH) while allowing for arbitrary insertion/removal (push/pop) and "selective hop" processing that exists in MPLS. It also attempts to address backward compatibility through label entry encoding, identifying mutable/immutable bits for load-balancing purposes, and using multiple copies of options to account for Readable Label Depth (RLD) limitations. The challenges associated with such options are well-known; even within a router-centric MPLS environment, this adds considerable complexity to an architecture that is loved for being as simple and fast.

I recognize the significant effort, both technical and in consensus-building, that has gone into this work. Out of respect for the WG consensus, I am balloting ABSTAIN despite my questions, doubts, and concerns regarding the approach and choices made.

Please find my detailed review comments below. I hope they are helpful, should the authors and the WG wish, to improve the document.

The comments are inline in the idnits output of v18 of the document. Please look for the tag  at the end to ensure you have received the full review.


23   the MPLS packet or perform user-defined operations.  This document
24   addresses the requirements for In-stack network actions and In-stack
25   data found in RFC 9613.

Suggest to remove the last sentence of the abstract. I am suggesting
some editorial changes so that RFC9613 can become an informative reference.


127   The solution specified in this document addresses the requirements
128   for In-stack network action and In-stack data (ISD) found in
129   [RFC9613].

Suggest:
The requirements for In-stack network action and In-stack data (ISD) are
described in [RFC9613].

139 2.1.  Requirements Language

141   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
142   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
143   document are to be interpreted as described in [RFC2119] [RFC8174]
144   when, and only when, they appear in all capitals, as shown here.

Please fix the BCP14 template

157       +--------------+-----------------------------+---------------+
158       | BOS          | Bottom Of Stack            | [RFC3032]    |

The BOS acronym is not defined in RFC3032 but that field is defined
there.

170       +--------------+-----------------------------+---------------+
171       | LSE          | Label Stack Entry          | [RFC3032]    |

Same as previous comment - LSE acronym is not defined in RFC3032.

270   *  IHS (2 bits): The scope of all the network actions in this sub-
271       stack.  See Section 5.3.

I see the term "sub-stack" used without the "MNA" or "NA" prefix in a
few places in the document. I would suggest using the NAS acronym instead of
"sub-stack" in such places or prefix MNA before the "sub-stack" for clarity.
There is frequent use of the term "MNA sub-stack" and I wonder why all of them
could not be replaced by "NAS" for consistency?

323   NOTE: A Format A and a Format B LSE MUST be present when a Format C
324   LSE is carried in the NAS.

Please remove "NOTE:" since that is generally used in an informative
manner but this is normative text. Same applies in a few other places in the
document.

328   LSE Format D is used to encode additional data that did not fit in
329   the LSE with the preceding opcode.

The preceding opcode here imply LSE Format B or LSE Format C with its
opcode, but it could as well be another LSE Format D that does not carry an
opcode? Can this be clarified? Perhaps ... that did not fit in the previous
LSE Formats B, C, or D?

355 5.  The MNA Sub-Stack

357   The MNA Sub-Stack begins with a Format A LSE (Section 4.1).  The

Perhaps .. MUST begin with ... ?

358   label value of the LSE contains the MNA bSPL (value TBA) to indicate
359   the presence of the MNA Sub-Stack.

There is some very good text explaining the design of Format A that is
in the section 11. Perhaps consider moving it in here and then provide a pointer
to section 11 for the reader to understand how it helps backwards compatibility?

361   The TC and TTL values of the Format A LSE retain their semantics as
362   defined in [RFC3032] and [RFC5462].  The TTL and TC values in the
363   Format A LSE are copied from the forwarding label at the top of the

copied by who? Can you clarify that this is to be done by the node
pushing that NAS? Please also clarify what is meant by "top of the label stack".
If the node pushing a NAS were to also push another forwarding LSE on top of
the NAS, is the TTL/TC copied from that LSE or the LSE that was at the top of
the stack when the packet arrived at that node? Also, please consider moving
this discussion of TTL/TC into the appropriate sub-section(s) of section 9?

364   label stack.  The penultimate node on the path copies the TTL and TC

You mean the "penultimate node" doing PHP? Or perhaps a node doing pop
in general? Also, consider moving into section 9?

365   values from the preceding LSE to the next LSE on the label stack,
366   overwriting the TTL and TC values of the next LSE, as specified in
367   Section 3.5 of [RFC3443] and Section 2.6.3 of [RFC3270] in the
368   Uniform Mode LSPs.  If the node performing this copy is not aware of
369   MNA, this could overwrite the values in the first LSE of the MNA sub-
370   stack.

The first LSE if the NAS is not clear. I am assuming it is a Format A
LSE? And if so, I fail to see the issue. In other words, I am not understanding
the intent of this text.

380   A NAS MAY contain more Format C (Section 4.3) and Format D
381   (Section 4.4) LSEs, up to the length encoded in the NASL value.  All
382   Format D LSEs MUST follow a Format C or B LSE and be included in that
383   LSE's NAL value.

What would be good here is some text describing the thought process behind
these 3 types (B, C & D) of formats and how they can be used in combination of each
other. Then put a reference to the examples so the reader can validate understanding
based on those illustrations. One aspect that is not clear is that the AD for an
opcode can span across more than one Format D.

398   The label value (most significant 20 bits) in one or more consecutive
399   LSEs is commonly used for load balancing data flows in an ECMP
400   environment.  Modifying the first 20 bits in an LSE might alter a
401   packet's path and result in out-of-order delivery of packets
402   belonging to a given flow.  To maintain the stability of deployed
403   services in ECMP environments that rely on label value information
404   for load-balancing, care must be taken when encoding network action
405   data in the given LSE.  If the network action data may differ among
406   packets in the same flow or change during forwarding across the MPLS
407   network, it MUST NOT be placed in the most significant 20 bits of a
408   Format B LSE (Section 4.2), a Format C LSE (Section 4.3), or a Format
409   D LSE (Section 4.4).  Thus, the available bits for data that can
410   change by a transit node or differ among packets of the same flow in
411   Format A and Format B LSEs are 0, Format C LSE is 7 (bits 20-22 and
412   25-28) and Format D LSE is 11 (bits 20-22 and 24-31).

This aspect is not just for the AD but also for the construction of
the NAS (along with its opcodes). If all the packets of the flow are not subject
to the same NAS imposition and encoding, then we have a similar problem. I am
thinking of some OAM operation where the network action is not to be performed
on all packets but some (a sample) of them. Another possibly more important
aspect is why not just use the post-stack solution/option in the case of
mutable information or where things are changing within a flow? Isn't that
simpler as opposed to this complicated working with bits?

464   The egress node is included in the HBH scope.  This implies that the
465   penultimate node MUST NOT remove a HBH NAS.  The egress node MAY
466   receive a NAS at the top of the label stack as discussed in
467   Section 10.

s/MAY/may - also I don't see the connect to section 10. Then again, why
just the egress node, even an intermediate node could receive a NAS at the top
of the label stack.

469   An I2E scope NAS, if present, MUST be encoded after any HBH or
470   Select-scope NASes.  This makes it easier for the transit nodes to
471   process a NAS with HBH or Select scope.

Is the packet dropped if this "MUST" is violated?


496   When a packet with an unknown Network Action is dropped, the node
497   SHOULD maintain a local counter for this event, and MAY send a rate-
498   limited notification to the operator.

What is an "unknown Network Action" - is it an unknown opcode, the
reserved IHS value, anything else? Can this be specified?

510 6.  Special Opcodes

512   Below are the special opcodes defined to build a basic In-stack MNA
513   solution and has been assigned through IANA registry (Section 15.4).
514   In future, additional special opcodes can be defined and their code-
515   points assigned from the "Network Action Opcodes" IANA registry
516   (Section 15.4).

I don't see the registry differentiating between "special" and "usual"
opcodes. Can we say "Initial" opcodes? But then I don't know what "special"
opcodes in the future indicate ...

518 6.1.  bSPL Protection

520   Opcode: 0
521   Purpose: Legacy implementations may scan the label stack looking for
522   bSPL values.  As long as the opcode field is non-zero, an LSE cannot
523   be misinterpreted as containing a bSPL.  Opcode 0 is therefore
524   reserved and is not used.

Can we put "Reserved (not to be used)" in the IANA registry entry too?

534   LSE Formats: B, C, D

536   Data: The data field carries Network Action Indicators, which should
537   be evaluated from the most significant bit to the least significant
538   bit.  If this opcode is used with LSE Format B only, then up to 13
539   flags may be carried.  If this opcode is used with LSE Format C only,
540   then up to 20 flags may be carried.  Format D LSEs can be used with
541   format C LSEs to encode more than 20 flags.  Flags are assigned from
542   the "Network Action Flags Without Ancillary Data" registry
543   (Section 15.3).  If flags need to be evaluated in a different order,
544   multiple LSEs using this opcode may be used to specify the requested
545   order.  The Flag-Based Network Action Indicators MUST follow the
546   procedure for data specified in Section 5.2.

As I understand, the bit position depends on the sequence of the
LSE entries with opcode 1. It is not clear that all LSEs in the NAS with opcode
1 need to be contiguous - one of the examples shows when multiple LSEs with
opcode 1 can be present in the same NAS - please clarify in this normative text.
If the LSE Format B is used for another opcode and it is followed by LSE Format
C with opcode 1, then the bit 0 would be the MSB of that Format C LSE entry's AD.
Can we have B with opcode 1, D, and then C with opcode 1? I see too many
permutations and combinations that can become very complex unless there is a
very simple and prescriptive method for encoding of this opcode?


550 6.3.  No-Operation Opcode

552   Opcode: 2

554   Purpose: This opcode is reserved to indicate that this opcode does
555   not perform any Network Action and MUST be skipped.

Then why have it in the first place? What is the real purpose behind
this? E.g., in IPv6 options headers we have PAD options which are no-op but
they serve a purpose of alignment. Is it because it is mandatory to have an
LSE Format B after A and then what if the action needed actually needs LSE
Format C but we need to put a Format B with no-op opcode to follow the rules?
This may not be super obvious to a reader, if this was the motivation.
Suggest to explain why/when it is used and then perhaps put a reference to
one of the examples where this is used.

561 6.4.  Extension Opcode

563   Opcode: 127
564   Purpose: This opcode is reserved to extend the current opcode range
565   beyond 127 in future.  If this opcode is not supported, then the
566   packet with the opcode 127 MUST be dropped regardless of the setting
567   of the U bit.  Use of this opcode is outside the scope of this
568   document.

How can one support this opcode when it is unspecified? Why not make
this "Reserved (for future use)" and indicate that packets with this set are
to be dropped?

570 7.  NAS placement in the Label Stack

572   The node adding a NAS to the label stack places a copy of the NAS
573   where the relevant nodes can read it.  Each downstream node along the
574   path has a Readable Label Depth (RLD).  If the NAS is to be processed
575   by a downstream MNA-capable node, then the entire NAS MUST be placed
576   so that it is within RLD by the time the packet reaches the
577   downstream MNA-capable node.

579   If the label stack is deep, several copies of the NAS may need to be
580   encoded in the label stack.

Consider that the action is to set certain information in the HBH header
as it traverses the LSP. How is this information conveyed from the top most NAS to
its copies further below? Or, can such actions be only placed in a single copy
in the label stack?

587   A NAS MUST NOT appear at the top of the stack after popping the
588   forwarding label on an MNA-incapable node on the path.

The above is not clear - who is popping the label here? Is it the
node before the MNA-incapable node - in this case there is an issue? Or, is it
the MNA-incapable node - in which case there is no issue unless the node
after it is also MNA-incapable and it cannot do anything about it.


598   forwarding label and before the next forwarding label.  It could be
599   inserted before or after a HBH NAS.  Note that the case of a NAS with
600   Select scope with MPLS label swap operation (for example, with RSVP
601   Traffic Engineering LSPs) is for future study.

Swap is a basic MPLS label operation. I am concerned by how the
processing of a NAS is unspecified in that case. Perhaps Select scope doesn't
make sense and is not processed during a swap?

606   Transit, non-penultimate nodes that pop a forwarding label and expose
607   a copy of a NAS MUST remove it.

The use of the term transit and non-penultimate node is not very clear
here. Consider a SR-MPLS label stack. There is the headend and the endpoint.
However, there are nodes in the middle that perform swap or pop (including for
PHP) - here I am assuming only prefix and adj SIDs for simplicity. So, is
this statement only about the case where multiple copies of a NAS are present
in the label stack? Because the next paragraph seems to contradict. Also, how
does the node know if the multiple NASes in the label stack are copies or
distinct NASes without performing an expensive compare operation?

617   The node that receives the NAS at the top of the label stack MUST
618   process and remove it.

Is it required for each node to understand the MNA capability of all
of it neighbors such that it can ensure that it doesn't forward packets to a
non-MNA capable neighbor with the NAS exposed as the topmost label?


620 7.1.  Actions when Pushing Labels

622   An MNA-capable node may need to push additional labels as well as
623   push new network actions onto a received packet.

625   While pushing additional labels on to the label stack of the received
626   packet, the MNA-capable node MUST verify that the entire top-most NAS
627   with HBH scope is still within the RLD of the downstream MNA-capable
628   nodes.  If required, the MNA-capable node MAY create a copy of the

The HBH NAS was in the incoming packet. The node is pushing its own
label stack (say SR BSID) and the entity computing that label stack is doing
what it needs to do based on the RLD of nodes along the path. However, in the
forwarding path, there is no clue whether incoming packets will have HBH NAS
- it seems incredibly complex to expect the node to figure out the RLD capabilities
along the packet path in the fast path. How is that MUST supposed to work?

629   top-most NAS with HBH scope and insert it within the RLD of the
630   downstream MNA-capable nodes on the label stack.

What about the MTU implications of doing such copy and insert operations?


639   The new network actions added MUST NOT conflict with the network
640   actions in the received NAS with HBH scope.  The mechanism to resolve
641   such conflicts depend on the network actions and can be based on
642   local policy.  The MNA-capable node that pushes entries MUST
643   understand any network actions which it is pushing which may result
644   in a conflict, and MUST resolve any conflicts between new and
645   received network actions.  In the usual case of a conflict of
646   duplicating a network action, the definition of a network action MUST
647   give guidance on confict resolution.

Are all of these MUSTs even possible to confirm to given that no actions
are currently defined, no conflicts are currently defined and, therefore, no
way to resolve conflicts are defined. All of this seems very aspirational and so
perhaps consider removing all the normative text and rephrase it as a guidance?

669   *  In the case of MPLS Segment Routing (SR-MPLS), as well as the,
670       RLD, the path computation system needs to know the MSD [RFC8664]
671       that can be imposed at the ingress node of a given SR path.  This

Perhaps:
In the case of MPLS Segment Routing (SR-MPLS), the path computation system needs
to know the MSD [RFC8664] that can be imposed at the ingress node of a given SR
path, as well as the, RLD of the nodes along the path.

672       ensures that the label stack depth of a computed path does not
673       exceed the maximum number of labels (i.e., MSD) the node is
674       capable of imposing and the maximum number of labels that can be
675       read by the MNA-processing nodes in the path.  The MSD MUST
676       include the MNA Sub-Stacks that will be added.

Perhaps:
The MSD and RLD calculations MUST factor in both the forwarding LSEs and the NAS.

678 9.  Processing the Network Action Sub-Stack

680   This section defines the specific responsibilities for nodes along an
681   LSP [RFC3031].

683 9.1.  Encapsulating Node Responsibilities

What is the definition of "Encapsulating Node"? I assume this is the node
that is receiving non-MPLS traffic which it encapsulates in a MPLS label stack?
If so, please clarify.

692   If there is an existing label stack, the encapsulating node MUST NOT
693   modify the first 20 bits of any LSE in the label stack when the ECMP
694   technique in the network is using the hashing of the labels on the
695   label stack.

How would the encapsulating node know about that? Is that something
to be figured out along the path of a specific LSP or something network-wide?

697   If the encapsulating node is also a transit node, then it MUST also
698   follow the rules set out in Section 9.2.

If my assumption of the definition of an "encapsulating node" is correct,
then I am not able to follow how the above sentence can be true.

700 9.2.  Transit Node Responsibilities

702   The transit node is the node that processes a NAS in the Label stack
703   but does not push any new NAS.

So, this is in fact a "MNA Transit Node" and not a "MPLS Transit Node"?
Please crosscheck such terms and see if they need a qualifier to distinguish from
"regular/classic" MPLS.

705   The transit node MUST follow the procedure for data specified in
706   Section 5.2.

There is are no procedures for data processing by MNA Transit nodes in
section 5.2. Am I missing something?

724 9.4.  Egress Node Responsibilities

726   The egress node MUST remove any NAS it receives.

Is it an egress node or the decapsulating node? The later would match
with the encapsulating node. Also, it needs to process the NAS and a little
differently than the MNA transit node since it also needs to deal with the I2E
IHS ones?

728 10.  Network Action Indicator Opcode Definition

730   The following information MUST be defined for a new Network Action
731   Indicator opcode request in the document that specifies the Network
732   Action.

This is the first time that the term "NAI opcode" is used. Perhaps you
want to introduce it in section 5.1 which is about opcodes?

737   *  Format: The definition of the new Network Action MUST specify the
738       LSE Formats.  The opcode can define Network Action in Format B or
739       C or both Format B and C.  Both Format B and C LSEs MAY optionally
740       carry Format D LSEs.

I am not sure that I understand the "MAY" here. For a given opcode, it is
ok to have variable length such that it might fit into simply Format B or C in
some cases, but then on need basis the size of data can be increased by arbitrary
number of Ds added to it - am I correct? The question is, is it implicit that
all opcodes can get extended by D or does the opcode need to specify if it can
be extended by D (and how many Ds) in its specification?

742   *  Scope: The definition of the new Network Action MUST specify at
743       least one scope (I2E, HBH, Select) for the Network Action, and MAY
744       specify more than one scope.

How about whether the given opcode can be present more than one time
in the same NAS or more than one time across different NAS with the same IHS?

746   *  Ancillary Data: The definition of the new Network Action MUST
747       specify the quantity, syntax, and semantics of any associated
748       Ancillary Data.  The Ancillary Data MAY be variable length, but
749       the length MUST be computable based on the data present in the
750       NAS.

which data present in the NAS? perhaps you mean the NAL ?

765 11.  Backward Compatibility

767   This section discusses interactions between MNA-capable and MNA-
768   incapable nodes.

770   An MNA-encapsulating node MUST ensure that the MPLS Network Action
771   Sub-Stack indicator is not at the top of the MPLS label stack when
772   the packet arrives at an MNA-incapable node.  If such a packet did

How is this MUST going to be honored when the document does not specify
the means of doing so?

859   *  The semantics of a network action are unbounded and may be
860       insecure.  A network action could be defined that made arbitrary
861       changes to the memory of the forwarding router, which could then
862       be used by the encapsulating node to compromise every MNA-capable
863       router in the network.  The IETF needs to ensure that only secure
864       network actions are defined.

How is the IETF going to be able to do that when both the flags and the
opcodes have allocations for private and experimental use where allocation does
not require IETF review? This contradicts the next bullet.

872   *  The MPLS domain border nodes MUST ensure that the MPLS packets
873       with MNA from any domain with a different administrative control
874       can be filtered to prevent entering the provider MPLS domain.  The
875       filtering capability MAY be enabled on a per network action basis
876       and it can be based on a local policy.  The filtering capability
877       MUST be implemented on those nodes before deploying MNA in the
878       provider MPLS domain.  The RLD on the filtering node MUST be
879       higher than the RLD on all other nodes in the provider MPLS
880       domain.

The use of "MAY" in what kind of filtering is required and how to do that
coupled with use of "MUST" do filtering is strange. Why not define very specifically
and in detailed terms what type of filtering MUST be implemented?

948   Bit Position refers to the position relative to the most significant
949   bit in LSE Format B or C Data fields and any subsequent Format D
950   LSEs.  Bit Position 0 is the most significant bit in an LSE Format B
951   or C Data field.  Bit Position 20 is the most significant bit in the
952   first LSE Format D Data field.  There are 20 bits available in LSE
953   Format C and 30 bits available in LSE Format D.  There are at most 14
954   Format D LSEs per opcode (due to NASL limit of 15 and Format D
955   requires Format C LSE), so there are at most 20 + 14 * 30 = 440 bit
956   positions.  The Bit Position is an integer with value 0-439.

The above paragraph is normative text and does not belong in the IANA
section. Please move it into section 6.2. The IANA is only going to deal with
the assignments of bits per their policy.



1018 16.  Examples

Please move examples into an Appendix section.


1067         Figure 6: Network Action Flags without AD using LSE Format D

1069   In this example, the NAS contains a Format B LSE with No-Operation
1070   Opcode value 2.  The next LSE uses Format C, but the Network Action
1071   Flag is not in a bit position contained within the Format C LSE, so a
1072   single Format D LSE has been added to the NAS to carry the flag.

This example is confusing. Can you indicate which specific bit position
is required to be set? That will explain why the no-op opcode is used with
the LSE B format and why the flags didn't start from that LSE B itself followed
by a LSE C or D but not both.


1154           Figure 9: Network Action With Additional Ancillary Data

1156   In this example, opcode 9 requires more than one LSE's worth of
1157   Ancillary Data, so a Format D LSE is added.

Sure, but why is LSE B used with no-op opcode? The answer needs to
be that there was need for a specific size of AD that gets encoded more
efficiently by the scheme shown.

1257   [RFC9613]  Bocci, M., Ed., Bryant, S., and J. Drake, "Requirements
1258               for Solutions that Support MPLS Network Actions (MNAs)",
1259               RFC 9613, DOI 10.17487/RFC9613, August 2024,
1260               .

I am wondering why this isn't an informative reference.

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-mpls-mna-hdr-19
CC @evyncke

Thank you for the work put into this document. This work looks very similar to the IPv6 extensions headers and to SRv6 Network Programming. So, as INT AD and working with IPv6 extension headers for 15+ years, I am afraid that I have some real concerns about this document. And, as usual, I will be happy to stand corrected.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Tarek Saad for the shepherd's *detailed* write-up including the difficult-to-reach WG consensus *BUT* it completely lacks the justification of the intended status even if the 2nd WGLC was about the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Intended publication status

With a single implementation from one University (i.e., no vendors), I do not think that this I-D should be a "proposed standard" but rather an "experimental" one. Gunter Vandevelde hinted also to this issue.

An 'experimental' status would also transform my blocking DISCUSS points below in COMMENT points.

### Section 2.2

Some acronyms have wrong references, e.g., I cannot find BOS in RFC 3032.

### Section 4

It is completely unclear to me how can a MPLS node know how to parse a LSE, i.e., how can it know that this is format B, or C ? The reader can *guess* that format A is the first one identifed by bSPL.

Normative text, including a figure having a complete NAS (with multiple LSEs) and key fields would be welcome. Section 5 has some hints that could be re-used to do EARLIER in the text. Or an example from the appendix.

### Section 7

`If the NAS is to be processed by a downstream MNA-capable node, then the entire NAS MUST be placed so that it is within RLD by the time the packet reaches the downstream MNA-capable node` is missing a normative reference on how a node knows about the RLD of the downstream node.

### Section 7.1

For very good reasons, IPv6 extension headers cannot be inserted on the path, so, how is the MTU change handled/signalled when a node increases the label stacks as in `n MNA-capable node may need to push additional labels as well as push new network actions onto a received packet.`

### Section 14.4

While the section 12 (security consideration) rightfully contains `The semantics of a network action are unbounded and may be insecure ... The IETF needs to ensure that only secure network actions are defined`, the section 14.4 only mentions `Registration requests should comply with Section 10.` (i.e., no security review).

[Ballot comment]

## COMMENTS (non-blocking)

### Section 3

In a PS (but see my DISCUSS points): s/This document describes how network actions/This document *specifies* how network actions/

### Section 5.2

I fear that the last paragraph is really opening the door for heavy troubleshooting a network that has assumed not to do ECMP but actually doing it...

### Section 5.3

With all the issues (and discussions) related to the IPv6 HbH options extension header, I am unsure whether it is wise to re-introduce the same concept. OTOH, the MPLS domain is usually under a single operator, so, perhaps safer.

### Section 5.4

Per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, there should be guidance when using a SHOULD such as in `the node SHOULD maintain a local counter for this event``

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot comment]
Thank you to the authors and the WG for their work on this document.

This document introduces a significant change to the decades-old MPLS architecture by incorporating concepts similar to IPv6 extension headers (HBH, DOH, RH), while allowing for arbitrary insertion/removal (push/pop) and "selective hop" processing. It also attempts to address backward compatibility through label entry encoding, identifying mutable/immutable bits for load-balancing purposes, and using multiple copies of options to account for Readable Label Depth (RLD) limitations. The challenges associated with such options are well-known; even within a router-centric MPLS environment, this adds considerable complexity to an architecture that is loved for being as simple and fast.

I recognize the significant effort, both technical and in consensus-building, that has gone into this work. Out of respect for the WG consensus, I am balloting ABSTAIN despite my questions, doubts, and concerns regarding the approach and choices made.

Please find my detailed review comments below. I hope they are helpful, should the authors and the WG wish, to improve the document.

The comments are inline in the idnits output of v18 of the document. Please look for the tag  at the end to ensure you have received the full review.


23   the MPLS packet or perform user-defined operations.  This document
24   addresses the requirements for In-stack network actions and In-stack
25   data found in RFC 9613.

Suggest to remove the last sentence of the abstract. I am suggesting
some editorial changes so that RFC9613 can become an informative reference.


127   The solution specified in this document addresses the requirements
128   for In-stack network action and In-stack data (ISD) found in
129   [RFC9613].

Suggest:
The requirements for In-stack network action and In-stack data (ISD) are
described in [RFC9613].

139 2.1.  Requirements Language

141   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
142   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
143   document are to be interpreted as described in [RFC2119] [RFC8174]
144   when, and only when, they appear in all capitals, as shown here.

Please fix the BCP14 template

157       +--------------+-----------------------------+---------------+
158       | BOS          | Bottom Of Stack            | [RFC3032]    |

The BOS acronym is not defined in RFC3032 but that field is defined
there.

170       +--------------+-----------------------------+---------------+
171       | LSE          | Label Stack Entry          | [RFC3032]    |

Same as previous comment - LSE acronym is not defined in RFC3032.

270   *  IHS (2 bits): The scope of all the network actions in this sub-
271       stack.  See Section 5.3.

I see the term "sub-stack" used without the "MNA" or "NA" prefix in a
few places in the document. I would suggest using the NAS acronym instead of
"sub-stack" in such places or prefix MNA before the "sub-stack" for clarity.
There is frequent use of the term "MNA sub-stack" and I wonder why all of them
could not be replaced by "NAS" for consistency?

323   NOTE: A Format A and a Format B LSE MUST be present when a Format C
324   LSE is carried in the NAS.

Please remove "NOTE:" since that is generally used in an informative
manner but this is normative text. Same applies in a few other places in the
document.

328   LSE Format D is used to encode additional data that did not fit in
329   the LSE with the preceding opcode.

The preceding opcode here imply LSE Format B or LSE Format C with its
opcode, but it could as well be another LSE Format D that does not carry an
opcode? Can this be clarified? Perhaps ... that did not fit in the previous
LSE Formats B, C, or D?

355 5.  The MNA Sub-Stack

357   The MNA Sub-Stack begins with a Format A LSE (Section 4.1).  The

Perhaps .. MUST begin with ... ?

358   label value of the LSE contains the MNA bSPL (value TBA) to indicate
359   the presence of the MNA Sub-Stack.

There is some very good text explaining the design of Format A that is
in the section 11. Perhaps consider moving it in here and then provide a pointer
to section 11 for the reader to understand how it helps backwards compatibility?

361   The TC and TTL values of the Format A LSE retain their semantics as
362   defined in [RFC3032] and [RFC5462].  The TTL and TC values in the
363   Format A LSE are copied from the forwarding label at the top of the

copied by who? Can you clarify that this is to be done by the node
pushing that NAS? Please also clarify what is meant by "top of the label stack".
If the node pushing a NAS were to also push another forwarding LSE on top of
the NAS, is the TTL/TC copied from that LSE or the LSE that was at the top of
the stack when the packet arrived at that node? Also, please consider moving
this discussion of TTL/TC into the appropriate sub-section(s) of section 9?

364   label stack.  The penultimate node on the path copies the TTL and TC

You mean the "penultimate node" doing PHP? Or perhaps a node doing pop
in general? Also, consider moving into section 9?

365   values from the preceding LSE to the next LSE on the label stack,
366   overwriting the TTL and TC values of the next LSE, as specified in
367   Section 3.5 of [RFC3443] and Section 2.6.3 of [RFC3270] in the
368   Uniform Mode LSPs.  If the node performing this copy is not aware of
369   MNA, this could overwrite the values in the first LSE of the MNA sub-
370   stack.

The first LSE if the NAS is not clear. I am assuming it is a Format A
LSE? And if so, I fail to see the issue. In other words, I am not understanding
the intent of this text.

380   A NAS MAY contain more Format C (Section 4.3) and Format D
381   (Section 4.4) LSEs, up to the length encoded in the NASL value.  All
382   Format D LSEs MUST follow a Format C or B LSE and be included in that
383   LSE's NAL value.

What would be good here is some text describing the thought process behind
these 3 types (B, C & D) of formats and how they can be used in combination of each
other. Then put a reference to the examples so the reader can validate understanding
based on those illustrations. One aspect that is not clear is that the AD for an
opcode can span across more than one Format D.

398   The label value (most significant 20 bits) in one or more consecutive
399   LSEs is commonly used for load balancing data flows in an ECMP
400   environment.  Modifying the first 20 bits in an LSE might alter a
401   packet's path and result in out-of-order delivery of packets
402   belonging to a given flow.  To maintain the stability of deployed
403   services in ECMP environments that rely on label value information
404   for load-balancing, care must be taken when encoding network action
405   data in the given LSE.  If the network action data may differ among
406   packets in the same flow or change during forwarding across the MPLS
407   network, it MUST NOT be placed in the most significant 20 bits of a
408   Format B LSE (Section 4.2), a Format C LSE (Section 4.3), or a Format
409   D LSE (Section 4.4).  Thus, the available bits for data that can
410   change by a transit node or differ among packets of the same flow in
411   Format A and Format B LSEs are 0, Format C LSE is 7 (bits 20-22 and
412   25-28) and Format D LSE is 11 (bits 20-22 and 24-31).

This aspect is not just for the AD but also for the construction of
the NAS (along with its opcodes). If all the packets of the flow are not subject
to the same NAS imposition and encoding, then we have a similar problem. I am
thinking of some OAM operation where the network action is not to be performed
on all packets but some (a sample) of them. Another possibly more important
aspect is why not just use the post-stack solution/option in the case of
mutable information or where things are changing within a flow? Isn't that
simpler as opposed to this complicated working with bits?

464   The egress node is included in the HBH scope.  This implies that the
465   penultimate node MUST NOT remove a HBH NAS.  The egress node MAY
466   receive a NAS at the top of the label stack as discussed in
467   Section 10.

s/MAY/may - also I don't see the connect to section 10. Then again, why
just the egress node, even an intermediate node could receive a NAS at the top
of the label stack.

469   An I2E scope NAS, if present, MUST be encoded after any HBH or
470   Select-scope NASes.  This makes it easier for the transit nodes to
471   process a NAS with HBH or Select scope.

Is the packet dropped if this "MUST" is violated?


496   When a packet with an unknown Network Action is dropped, the node
497   SHOULD maintain a local counter for this event, and MAY send a rate-
498   limited notification to the operator.

What is an "unknown Network Action" - is it an unknown opcode, the
reserved IHS value, anything else? Can this be specified?

510 6.  Special Opcodes

512   Below are the special opcodes defined to build a basic In-stack MNA
513   solution and has been assigned through IANA registry (Section 15.4).
514   In future, additional special opcodes can be defined and their code-
515   points assigned from the "Network Action Opcodes" IANA registry
516   (Section 15.4).

I don't see the registry differentiating between "special" and "usual"
opcodes. Can we say "Initial" opcodes? But then I don't know what "special"
opcodes in the future indicate ...

518 6.1.  bSPL Protection

520   Opcode: 0
521   Purpose: Legacy implementations may scan the label stack looking for
522   bSPL values.  As long as the opcode field is non-zero, an LSE cannot
523   be misinterpreted as containing a bSPL.  Opcode 0 is therefore
524   reserved and is not used.

Can we put "Reserved (not to be used)" in the IANA registry entry too?

534   LSE Formats: B, C, D

536   Data: The data field carries Network Action Indicators, which should
537   be evaluated from the most significant bit to the least significant
538   bit.  If this opcode is used with LSE Format B only, then up to 13
539   flags may be carried.  If this opcode is used with LSE Format C only,
540   then up to 20 flags may be carried.  Format D LSEs can be used with
541   format C LSEs to encode more than 20 flags.  Flags are assigned from
542   the "Network Action Flags Without Ancillary Data" registry
543   (Section 15.3).  If flags need to be evaluated in a different order,
544   multiple LSEs using this opcode may be used to specify the requested
545   order.  The Flag-Based Network Action Indicators MUST follow the
546   procedure for data specified in Section 5.2.

As I understand, the bit position depends on the sequence of the
LSE entries with opcode 1. It is not clear that all LSEs in the NAS with opcode
1 need to be contiguous - one of the examples shows when multiple LSEs with
opcode 1 can be present in the same NAS - please clarify in this normative text.
If the LSE Format B is used for another opcode and it is followed by LSE Format
C with opcode 1, then the bit 0 would be the MSB of that Format C LSE entry's AD.
Can we have B with opcode 1, D, and then C with opcode 1? I see too many
permutations and combinations that can become very complex unless there is a
very simple and prescriptive method for encoding of this opcode?


550 6.3.  No-Operation Opcode

552   Opcode: 2

554   Purpose: This opcode is reserved to indicate that this opcode does
555   not perform any Network Action and MUST be skipped.

Then why have it in the first place? What is the real purpose behind
this? E.g., in IPv6 options headers we have PAD options which are no-op but
they serve a purpose of alignment. Is it because it is mandatory to have an
LSE Format B after A and then what if the action needed actually needs LSE
Format C but we need to put a Format B with no-op opcode to follow the rules?
This may not be super obvious to a reader, if this was the motivation.
Suggest to explain why/when it is used and then perhaps put a reference to
one of the examples where this is used.

561 6.4.  Extension Opcode

563   Opcode: 127
564   Purpose: This opcode is reserved to extend the current opcode range
565   beyond 127 in future.  If this opcode is not supported, then the
566   packet with the opcode 127 MUST be dropped regardless of the setting
567   of the U bit.  Use of this opcode is outside the scope of this
568   document.

How can one support this opcode when it is unspecified? Why not make
this "Reserved (for future use)" and indicate that packets with this set are
to be dropped?

570 7.  NAS placement in the Label Stack

572   The node adding a NAS to the label stack places a copy of the NAS
573   where the relevant nodes can read it.  Each downstream node along the
574   path has a Readable Label Depth (RLD).  If the NAS is to be processed
575   by a downstream MNA-capable node, then the entire NAS MUST be placed
576   so that it is within RLD by the time the packet reaches the
577   downstream MNA-capable node.

579   If the label stack is deep, several copies of the NAS may need to be
580   encoded in the label stack.

Consider that the action is to set certain information in the HBH header
as it traverses the LSP. How is this information conveyed from the top most NAS to
its copies further below? Or, can such actions be only placed in a single copy
in the label stack?

587   A NAS MUST NOT appear at the top of the stack after popping the
588   forwarding label on an MNA-incapable node on the path.

The above is not clear - who is popping the label here? Is it the
node before the MNA-incapable node - in this case there is an issue? Or, is it
the MNA-incapable node - in which case there is no issue unless the node
after it is also MNA-incapable and it cannot do anything about it.


598   forwarding label and before the next forwarding label.  It could be
599   inserted before or after a HBH NAS.  Note that the case of a NAS with
600   Select scope with MPLS label swap operation (for example, with RSVP
601   Traffic Engineering LSPs) is for future study.

Swap is a basic MPLS label operation. I am concerned by how the
processing of a NAS is unspecified in that case. Perhaps Select scope doesn't
make sense and is not processed during a swap?

606   Transit, non-penultimate nodes that pop a forwarding label and expose
607   a copy of a NAS MUST remove it.

The use of the term transit and non-penultimate node is not very clear
here. Consider a SR-MPLS label stack. There is the headend and the endpoint.
However, there are nodes in the middle that perform swap or pop (including for
PHP) - here I am assuming only prefix and adj SIDs for simplicity. So, is
this statement only about the case where multiple copies of a NAS are present
in the label stack? Because the next paragraph seems to contradict. Also, how
does the node know if the multiple NASes in the label stack are copies or
distinct NASes without performing an expensive compare operation?

617   The node that receives the NAS at the top of the label stack MUST
618   process and remove it.

Is it required for each node to understand the MNA capability of all
of it neighbors such that it can ensure that it doesn't forward packets to a
non-MNA capable neighbor with the NAS exposed as the topmost label?


620 7.1.  Actions when Pushing Labels

622   An MNA-capable node may need to push additional labels as well as
623   push new network actions onto a received packet.

625   While pushing additional labels on to the label stack of the received
626   packet, the MNA-capable node MUST verify that the entire top-most NAS
627   with HBH scope is still within the RLD of the downstream MNA-capable
628   nodes.  If required, the MNA-capable node MAY create a copy of the

The HBH NAS was in the incoming packet. The node is pushing its own
label stack (say SR BSID) and the entity computing that label stack is doing
what it needs to do based on the RLD of nodes along the path. However, in the
forwarding path, there is no clue whether incoming packets will have HBH NAS
- it seems incredibly complex to expect the node to figure out the RLD capabilities
along the packet path in the fast path. How is that MUST supposed to work?

629   top-most NAS with HBH scope and insert it within the RLD of the
630   downstream MNA-capable nodes on the label stack.

What about the MTU implications of doing such copy and insert operations?


639   The new network actions added MUST NOT conflict with the network
640   actions in the received NAS with HBH scope.  The mechanism to resolve
641   such conflicts depend on the network actions and can be based on
642   local policy.  The MNA-capable node that pushes entries MUST
643   understand any network actions which it is pushing which may result
644   in a conflict, and MUST resolve any conflicts between new and
645   received network actions.  In the usual case of a conflict of
646   duplicating a network action, the definition of a network action MUST
647   give guidance on confict resolution.

Are all of these MUSTs even possible to confirm to given that no actions
are currently defined, no conflicts are currently defined and, therefore, no
way to resolve conflicts are defined. All of this seems very aspirational and so
perhaps consider removing all the normative text and rephrase it as a guidance?

669   *  In the case of MPLS Segment Routing (SR-MPLS), as well as the,
670       RLD, the path computation system needs to know the MSD [RFC8664]
671       that can be imposed at the ingress node of a given SR path.  This

Perhaps:
In the case of MPLS Segment Routing (SR-MPLS), the path computation system needs
to know the MSD [RFC8664] that can be imposed at the ingress node of a given SR
path, as well as the, RLD of the nodes along the path.

672       ensures that the label stack depth of a computed path does not
673       exceed the maximum number of labels (i.e., MSD) the node is
674       capable of imposing and the maximum number of labels that can be
675       read by the MNA-processing nodes in the path.  The MSD MUST
676       include the MNA Sub-Stacks that will be added.

Perhaps:
The MSD and RLD calculations MUST factor in both the forwarding LSEs and the NAS.

678 9.  Processing the Network Action Sub-Stack

680   This section defines the specific responsibilities for nodes along an
681   LSP [RFC3031].

683 9.1.  Encapsulating Node Responsibilities

What is the definition of "Encapsulating Node"? I assume this is the node
that is receiving non-MPLS traffic which it encapsulates in a MPLS label stack?
If so, please clarify.

692   If there is an existing label stack, the encapsulating node MUST NOT
693   modify the first 20 bits of any LSE in the label stack when the ECMP
694   technique in the network is using the hashing of the labels on the
695   label stack.

How would the encapsulating node know about that? Is that something
to be figured out along the path of a specific LSP or something network-wide?

697   If the encapsulating node is also a transit node, then it MUST also
698   follow the rules set out in Section 9.2.

If my assumption of the definition of an "encapsulating node" is correct,
then I am not able to follow how the above sentence can be true.

700 9.2.  Transit Node Responsibilities

702   The transit node is the node that processes a NAS in the Label stack
703   but does not push any new NAS.

So, this is in fact a "MNA Transit Node" and not a "MPLS Transit Node"?
Please crosscheck such terms and see if they need a qualifier to distinguish from
"regular/classic" MPLS.

705   The transit node MUST follow the procedure for data specified in
706   Section 5.2.

There is are no procedures for data processing by MNA Transit nodes in
section 5.2. Am I missing something?

724 9.4.  Egress Node Responsibilities

726   The egress node MUST remove any NAS it receives.

Is it an egress node or the decapsulating node? The later would match
with the encapsulating node. Also, it needs to process the NAS and a little
differently than the MNA transit node since it also needs to deal with the I2E
IHS ones?

728 10.  Network Action Indicator Opcode Definition

730   The following information MUST be defined for a new Network Action
731   Indicator opcode request in the document that specifies the Network
732   Action.

This is the first time that the term "NAI opcode" is used. Perhaps you
want to introduce it in section 5.1 which is about opcodes?

737   *  Format: The definition of the new Network Action MUST specify the
738       LSE Formats.  The opcode can define Network Action in Format B or
739       C or both Format B and C.  Both Format B and C LSEs MAY optionally
740       carry Format D LSEs.

I am not sure that I understand the "MAY" here. For a given opcode, it is
ok to have variable length such that it might fit into simply Format B or C in
some cases, but then on need basis the size of data can be increased by arbitrary
number of Ds added to it - am I correct? The question is, is it implicit that
all opcodes can get extended by D or does the opcode need to specify if it can
be extended by D (and how many Ds) in its specification?

742   *  Scope: The definition of the new Network Action MUST specify at
743       least one scope (I2E, HBH, Select) for the Network Action, and MAY
744       specify more than one scope.

How about whether the given opcode can be present more than one time
in the same NAS or more than one time across different NAS with the same IHS?

746   *  Ancillary Data: The definition of the new Network Action MUST
747       specify the quantity, syntax, and semantics of any associated
748       Ancillary Data.  The Ancillary Data MAY be variable length, but
749       the length MUST be computable based on the data present in the
750       NAS.

which data present in the NAS? perhaps you mean the NAL ?

765 11.  Backward Compatibility

767   This section discusses interactions between MNA-capable and MNA-
768   incapable nodes.

770   An MNA-encapsulating node MUST ensure that the MPLS Network Action
771   Sub-Stack indicator is not at the top of the MPLS label stack when
772   the packet arrives at an MNA-incapable node.  If such a packet did

How is this MUST going to be honored when the document does not specify
the means of doing so?

859   *  The semantics of a network action are unbounded and may be
860       insecure.  A network action could be defined that made arbitrary
861       changes to the memory of the forwarding router, which could then
862       be used by the encapsulating node to compromise every MNA-capable
863       router in the network.  The IETF needs to ensure that only secure
864       network actions are defined.

How is the IETF going to be able to do that when both the flags and the
opcodes have allocations for private and experimental use where allocation does
not require IETF review? This contradicts the next bullet.

872   *  The MPLS domain border nodes MUST ensure that the MPLS packets
873       with MNA from any domain with a different administrative control
874       can be filtered to prevent entering the provider MPLS domain.  The
875       filtering capability MAY be enabled on a per network action basis
876       and it can be based on a local policy.  The filtering capability
877       MUST be implemented on those nodes before deploying MNA in the
878       provider MPLS domain.  The RLD on the filtering node MUST be
879       higher than the RLD on all other nodes in the provider MPLS
880       domain.

The use of "MAY" in what kind of filtering is required and how to do that
coupled with use of "MUST" do filtering is strange. Why not define very specifically
and in detailed terms what type of filtering MUST be implemented?

948   Bit Position refers to the position relative to the most significant
949   bit in LSE Format B or C Data fields and any subsequent Format D
950   LSEs.  Bit Position 0 is the most significant bit in an LSE Format B
951   or C Data field.  Bit Position 20 is the most significant bit in the
952   first LSE Format D Data field.  There are 20 bits available in LSE
953   Format C and 30 bits available in LSE Format D.  There are at most 14
954   Format D LSEs per opcode (due to NASL limit of 15 and Format D
955   requires Format C LSE), so there are at most 20 + 14 * 30 = 440 bit
956   positions.  The Bit Position is an integer with value 0-439.

The above paragraph is normative text and does not belong in the IANA
section. Please move it into section 6.2. The IANA is only going to deal with
the assignments of bits per their policy.



1018 16.  Examples

Please move examples into an Appendix section.


1067         Figure 6: Network Action Flags without AD using LSE Format D

1069   In this example, the NAS contains a Format B LSE with No-Operation
1070   Opcode value 2.  The next LSE uses Format C, but the Network Action
1071   Flag is not in a bit position contained within the Format C LSE, so a
1072   single Format D LSE has been added to the NAS to carry the flag.

This example is confusing. Can you indicate which specific bit position
is required to be set? That will explain why the no-op opcode is used with
the LSE B format and why the flags didn't start from that LSE B itself followed
by a LSE C or D but not both.


1154           Figure 9: Network Action With Additional Ancillary Data

1156   In this example, opcode 9 requires more than one LSE's worth of
1157   Ancillary Data, so a Format D LSE is added.

Sure, but why is LSE B used with no-op opcode? The answer needs to
be that there was need for a specific size of AD that gets encoded more
efficiently by the scheme shown.

1257   [RFC9613]  Bocci, M., Ed., Bryant, S., and J. Drake, "Requirements
1258               for Solutions that Support MPLS Network Actions (MNAs)",
1259               RFC 9613, DOI 10.17487/RFC9613, August 2024,
1260               .

I am wondering why this isn't an informative reference.

[Ballot comment]
Hi Jags, all,

Thank you for the discussion and taking care of the review.

The new version [1] addresses all points raised in my previous ballot [2].

# Comment on -19

I suggest to update Section 2.3 to mention "encapsulating node" as well.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-mpls-mna-hdr-18&url2=draft-ietf-mpls-mna-hdr-19&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/mpls/tReEOJeGolLO8MM-u-mTWTyH9Js/

[Ballot comment]
Thanks to Derrell Piper for their secdir review, and thanks to Brian Trammell for highlighting part of the draft.

I am balloting no objection, but I encourage the authors to think about providing useful guidance/warnings in Section 12.

General:  I will note that RFC 9789' Sec Consid section quotes from RFC 5920 which says 'The MPLS forwarding plane has no built-in security mechanisms.'  This appears to be a long standing situation.     

Section 12:  This section should outline the risks of using these features/protocol/ideas with mitigations, when they exist.  I don't know a lot about this technology, but I'd be happy to review proposed changes.

Section 12, Bullet 2:  Please remove the last sentence.  Aspirational at best, and unlikely to be true going forward.

Section 12, Bullet 3:  Where are the instructions to implementers and operators documented?

Section 12, second to last bullet:  Perhaps the guidance should be that sensitive data MUST NOT be transmitted using these mechanisms?

Minor comments:
Section 1.2:  Normative Definitions?  Are there Informative Definitions?  I suggest dropping the 'Normative'.

[Ballot comment]
Section 9.2, paragraph 3

  The encapsulating node MUST NOT add a NAS to the label stack if the
  egress node does not support MNA.

How does the encapsulating node learn whether the egress node does or does not support MNA? If this work is being defined somewhere else, e.g., draft-ietf-mpls-mna-signaling, should it not be mentioned?

Section 13, paragraph 0
> 13.  Operational Considerations

Thanks to Joe for his OPSDIR review, for calling this out, and to the authors for adding this section.

Section 13.3, paragraph 7
>    However, as the existing behavior is not specified for transit LSRs,
>    upon encountering any unrecognized bSPLs or eSPLs below the top of
>    the label stack, some existing implementations may have chosen to
>    implement non-standardized actions, such as discarding packets.  Any
>    uses of a new bSPL or eSPL would cause issues with such existing
>    implementations using the non-standardized actions upon encountering
>    unrecognized bSPLs or eSPLs below the top of the label stack.  Since
>    this is a generic problem, any clarifications for the treatment of
>    unrecognized bSPL or eSPL are outside the scope of this document.

Thanks for providing this section. It is very useful.

There is one other case that I believe should be called out here, which I call the "Silently Skipping" caveat. If the network operator expects an action, e.g., "Account for this packet in Slice X", to happen at every hop, but a legacy node is in the path, that node will skip this action without a warning. While this does not crash the dataplane, it allows for "Silent Skipping" unless the operator uses strict TE (like SR-TE).

This document uses the RFC2119 keywords "OPTIONAL", "MUST", "SHALL NOT",
"SHOULD NOT", "MAY", "SHOULD", "REQUIRED", "RECOMMENDED", "MUST NOT", and
"SHALL", but does not contain the recommended RFC8174 boilerplate. (It contains
some text with a similar beginning.)

The IANA review of this document seems to not have concluded yet.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 5.3, paragraph 5
> ugh IANA registry (Section 14.4). In future, additional special opcodes can b
>                                  ^^^^^^^^^
The phrase "In future" is British English. Did you mean: "In the future"? Moreover,
this term will not stand the test of time.

Section 5.4, paragraph 4
> e current opcode range beyond 127 in future. If this opcode is not supported
>                                  ^^^^^^^^^
The phrase "in future" is British English. Did you mean: "in the future"?
Same here.

Section 7, paragraph 9
> gment Routing (SR-MPLS), as well as the, RLD, the path computation system ne
>                                    ^^^^
Articles like "the" are rarely followed by punctuation. A word may be missing
after "the", or the punctuation mark may not be necessary.

Section 13.3, paragraph 4
> (string), and "Reference" (string). Bit Position refers to the position rela
>                                    ^^^
It seems that an article is missing.

Section 13.3, paragraph 5
> s and any subsequent Format D LSEs. Bit Position 0 is the most significant b
>                                    ^^^
It seems that an article is missing.

Section 13.3, paragraph 5
> in an LSE Format B or C Data field. Bit Position 20 is the most significant
>                                    ^^^
It seems that an article is missing.

[Ballot discuss]
Hi Jaganbabu, Rakesh, Royi, Haoyu, and Kireeti,

Thank you for the effort put into this specification.

Thanks to Tianran and Joe for the OPSDIR reviews. Thank also to the authors for engaging and making changes to address main comments.

Please find below some easy-to-fix DISCUSS points:

# Internal consistency

Section 8:
  The encapsulating node is the node that pushes a NAS on to the Label
  stack.

Section 9.2
  The transit node is the node that processes a NAS in the Label stack
  but does not push any new NAS.

Section 9.1
  If the encapsulating node is also a transit node, then it MUST also
  follow the rules set out in Section 9.2.

Given the definition of these nodes, I don’t understand when 9.1 would work.

Is the intent here to refer to a node that may have different roles for distinct frames? Else?

I would simply delete the sentence in 9.1.

# Normative references

CURRENT:

  function, the MNA reserved label MUST NOT be used as a key for the
  load-balancing function, as specified in Section 4.3 of [RFC6790].

17.2.  Informative References
..

  [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              .

## RFC6790 should be listed as normative.

## I think the same applies for 3270 and 8126. Please check how references are classified.

[Ballot comment]
# Sample applications

CURRENT:
  There are applications
  that require MPLS packets to perform special network actions and
  carry optional Ancillary Data (AD) that can affect the packet
  forwarding decision or trigger Operations, Administration, and
  Maintenance (OAM) logging, for example. 

## Please consider adding a pointer to where such applications are discussed. If not, please add examples directly here.

## I appreciate this is not relevant at this stage in the document, but this requirement has scalability and performance implications. It would be useful to mention those or add a pointer where these are discussed.

# Slice Identifier

CURRENT:
  Ancillary Data can be used
  to carry additional information, such as a network slice identifier

There is no “network slide identifier“ defined yet in the IETF. I suggest this change:

CURRENT:
  Ancillary Data can be used
  to carry additional information, for network slice purposes [RFC5943]

# Please introduce Ingress/Egress nodes early in the document (Section 2, typically).

# The organization in term of various formats requires some attention to be digested. It would be helpful to consider a summary of these (and design rationale) in the overview section (Section 3).

# These are not sides notes; please format as plain text

CURRENT:
  NOTE: A Format A and a Format B LSE MUST be present when a Format C
  LSE is carried in the NAS.

(and similar ones)

# Section 9.1

CURRENT:
  The encapsulating node MUST NOT add a NAS to the label stack if the
  egress node does not support MNA.

Isn’t this part of the limitations in Section 8?

# Section 14

Thanks for the discussion in Backward compatibility Section. I think that this is better positioned as a subsection of Section 14.

# You may consider moving the examples into an appendix.

Cheers,
Med

[Ballot comment]
Please see the transport TSV-ART review, and I share the concern there about the words: "The IETF needs to ensure that only secure network actions are defined," in particular, this is not guidance that I would know how to follow.

I think this needs more description/specification, but I assume that Security ADs can advise on this and the best approach.

Gorry

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-mna-hdr-18

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-mpls-mna-hdr-18.txt

# Many thanks to Acee Lindem and Matt Bocci for the RTG DIR review, and to the authors to resolve the issues and observations made by the directorate review.

# The document introduces changes to the data plane, and while Section 12 discusses an implementation, I was left a bit uncertain about the operational impact when this technology is deployed in a live network. In particular, I’d like to feel more confident that it won’t cause unintended side effects, either network-wide or for devices using this technology. (I initially considered raising a blocking DISCUSS here, but given the long and intensive discussions this document has already gone through, I decided not to do so)

# The idnits report finds two downrefs. The Shepherd writeup suggests that the shepherd worked with the authors to address these downrefs. I did not see directly how this was addressed? Not sure i missed seeing the update?

# COMMENTS
# ========

139 2.1.  Requirements Language
140
141   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
142   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
143   document are to be interpreted as described in [RFC2119] [RFC8174]
144   when, and only when, they appear in all capitals, as shown here.

GV> is there a reason why BCP 14 is not mentioned in the usual Requirement Language template?

Kind Regards,
Gunter Van de Velde
Routing AD

[Ballot comment]
# Internet AD comments for draft-ietf-mpls-mna-hdr-18
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S7

* Reference to the "node capability" says "Section 7" but probably means
  "Section 8"?

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-mpls-mna-hdr-17. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are four actions which we must complete.

First, in the Base Special-Purpose MPLS Label Values registry in the Special-Purpose Multiprotocol Label Switching (MPLS) Label Values registry group located at:

https://www.iana.org/assignments/mpls-label-values/

a single new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: MPLS Network Actions
Reference: [ RFC-to-be ]

Second, a new registry group will be created called MPLS Network Actions Parameters. The new registry group will be located within the Multiprotocol Label Switching Architecture (MPLS) registry groups and will have a reference of [ RFC-to-be ].

Third, a new registry will be created called the Network Action Flags Without Ancillary Data registry. The new registry will be located in the new registry group created in Action 2 above. The registration rules for the new registry are (from Table 4 in Section 14.3 of the current draft):

Bit Position Registration Policy
-----------+-------------------
0-14 IETF Review
15-16 Experimental Use
17-19 Private Use
20-439 IETF Review

IANA Question --> Are there any initial registrations in this new registry?

Fourth, a new registry is to be created called the Network Action Opcodes registry. The new registry will be located in the new registry group created in Action 2 above. The registration rules for the new registry are (from Table 5 in Section 14.4 of the current draft):

Bit Position Registration Policy
------------+-------------------
1-110 IETF Review
111-114 Experimental Use
115-126 Private Use
127 IETF Review

There are initial registrations in the new registry as follows:

Opcode Description Reference
-------+-----------+-------------
0 Reserved [ RFC-to-be ]
1 Flag-Based Network Action Indicators without AD [ RFC-to-be ]
2 No operation Opcode [ RFC-to-be ]
127 Opcode Range Extension Beyond 127 [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-12-16):

From: The IESG
To: IETF-Announce
CC: draft-ietf-mpls-mna-hdr@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org, tsaad@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (MPLS Network Action (MNA) Sub-Stack Solution) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'MPLS Network Action (MNA)
Sub-Stack Solution'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-12-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines the MPLS Network Actions (MNA) sub-stack
  solution for carrying Network Actions and Ancillary Data in the MPLS
  label stack.  MNA can be used to influence packet forwarding
  decisions, carry additional Operations, Administration, and
  Maintenance information in the MPLS packet or perform user-defined
  operations.  The solution specified in this document addresses the
  requirements for In-stack network action and In-stack data found in
  RFC 9613.  This document follows the architectural framework for the
  MNA technologies specified in RFC 9789.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-hdr/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5828/
  https://datatracker.ietf.org/ipr/5668/
  https://datatracker.ietf.org/ipr/5669/
  https://datatracker.ietf.org/ipr/5965/
  https://datatracker.ietf.org/ipr/5903/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc9613: Requirements for Solutions that Support MPLS Network Actions (MNAs) (Informational - Internet Engineering Task Force (IETF) stream)
    rfc9789: MPLS Network Actions (MNAs) Framework (Informational - Internet Engineering Task Force (IETF) stream)

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]: This document had undergone three WGLCs.
  [1] the first WG LC (see https://mailarchive.ietf.org/arch/msg/mpls/_5qlFoOQWXVvuHfai46QIPSos0g/) failed due to:
    - Early on the start of the LC, it was pointed that there are outstanding comments yet to be addressed.
    - There has been further discussions on the document (still undergoing) and we expect further updates to the document to resolve them.

  [2] the second WG LC (see https://mailarchive.ietf.org/arch/msg/mpls/-sggY6AFe6zHc9umxymRrJYGnFI/) failed due to:
    - Concerns with regards to “Standards Track” intended status of the document, mainly due to the lack of implementation experience and interoperability of the data plane change
    - A renewed discussion about ISD and PSD and the extent of impact of this on the proposed MNA header encoding solution

  [3] the third WG LC (see https://mailarchive.ietf.org/arch/msg/mpls/McFdOBfRPafCrJm0IMxnu4kbUHY/) succeeded.
    - Some comments were raised and were actively followed up by the authors.
    - A renewed discussion on presence of multiple SPLs in the same MPLS header was raised. This has kickstarted a new ID and is tracked by this thread https://mailarchive.ietf.org/arch/msg/mpls/V3c0bgrs8Q10BM5tsZ6bGLmKKBU/


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
[Ans]: No.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
[Ans]: The document includes an implementation section in Section 12. There is one reported implementation of the solution.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
[Ans]: This document defines an MPLS header encapsulation for MNA technology.
The application of MNA technology for specific uscases is documented in RFC9791.
These application range from iOAM, DETNET, network-slicing, and others. The
PALS, DETNET, IPPM, WGs were kept in the loop early during the initial MNA design discussions.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
[Ans]: No such formal language.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
[Ans]: No YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
[Ans]: No formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
[Ans]: Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
[Ans]: An early review from the RTG-Dir was requested and completed satisfactorily.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
[Ans]: The intended RFC status is Standards Track and document reflects it in the Datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
[Ans]: Authors confirmed their knowledge of no other than the 5 IPRs known against the document:
      at the time of the WG last call.     
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-mna-hdr


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
[Ans]: There are five co-authors on the front page. By responding to the IPR poll, they
      have implicitly confirmed their willingness to be listed as co-authors.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[Ans]: IDnits reports:
  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------
    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)
   
  ** Downref: Normative reference to an Informational RFC: RFC 9613
  ** Downref: Normative reference to an Informational RFC: RFC 9789
    Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).
--> The document shepherd will work with authors to address those in the next revision.
--> No other issues were spotted by the shepherd.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
[Ans]:The references appear to be correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: All references are to IETF material.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
[Ans]: 2 downrefs documents. Shepherd will work with authors.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
[Ans]: No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
[Ans]: No status changes made.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
[Ans]: The document includes an IANA section. It:
1. requests a value (TBA) for the MNA bSPL label from the "Base Special-Purpose MPLS Label Values" registry.
2. requests that IANA creates a new category called "MPLS Network Actions Parameters" within the "Multiprotocol Label Switching Architecture (MPLS)" category
3. requests that IANA creates a new registry with the name "Network Action Flags Without Ancillary Data" within the "Multiprotocol Label Switching Architecture (MPLS)" category.
4. requests that IANA creates a new registry with the name "Network Action Opcodes".

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
[Ans]: None.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]: This document had undergone three WGLCs.
  [1] the first WG LC (see https://mailarchive.ietf.org/arch/msg/mpls/_5qlFoOQWXVvuHfai46QIPSos0g/) failed due to:
    - Early on the start of the LC, it was pointed that there are outstanding comments yet to be addressed.
    - There has been further discussions on the document (still undergoing) and we expect further updates to the document to resolve them.

  [2] the second WG LC (see https://mailarchive.ietf.org/arch/msg/mpls/-sggY6AFe6zHc9umxymRrJYGnFI/) failed due to:
    - Concerns with regards to “Standards Track” intended status of the document, mainly due to the lack of implementation experience and interoperability of the data plane change
    - A renewed discussion about ISD and PSD and the extent of impact of this on the proposed MNA header encoding solution

  [3] the third WG LC (see https://mailarchive.ietf.org/arch/msg/mpls/McFdOBfRPafCrJm0IMxnu4kbUHY/) succeeded.
    - Some comments were raised and were actively followed up by the authors.
    - A renewed discussion on presence of multiple SPLs in the same MPLS header was raised. This has kickstarted a new ID and is tracked by this thread https://mailarchive.ietf.org/arch/msg/mpls/V3c0bgrs8Q10BM5tsZ6bGLmKKBU/


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
[Ans]: No.


4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
[Ans]: The document includes an implementation section in Section 12. There is one reported implementation of the solution.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
[Ans]: This document defines an MPLS header encapsulation for MNA technology.
The application of MNA technology for specific uscases is documented in RFC9791.
These application range from iOAM, DETNET, network-slicing, and others. The
PALS, DETNET, IPPM, WGs were kept in the loop early during the initial MNA design discussions.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
[Ans]: No such formal language.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
[Ans]: No YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
[Ans]: No formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
[Ans]: Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
[Ans]: An early review from the RTG-Dir was requested and completed satisfactorily.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
[Ans]: The intended RFC status is Standards Track and document reflects it in the Datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
[Ans]: Authors confirmed their knowledge of no other than the 5 IPRs known against the document:
      at the time of the WG last call.     
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-mna-hdr


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
[Ans]: There are five co-authors on the front page. By responding to the IPR poll, they
      have implicitly confirmed their willingness to be listed as co-authors.


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[Ans]: IDnits reports:
  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------
    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)
   
  ** Downref: Normative reference to an Informational RFC: RFC 9613
  ** Downref: Normative reference to an Informational RFC: RFC 9789
    Summary: 2 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).
--> The document shepherd will work with authors to address those in the next revision.
--> No other issues were spotted by the shepherd.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
[Ans]:The references appear to be correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: All references are to IETF material.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
[Ans]: 2 downrefs documents. Shepherd will work with authors.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
[Ans]: No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
[Ans]: No status changes made.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
[Ans]: The document includes an IANA section. It:
1. requests a value (TBA) for the MNA bSPL label from the "Base Special-Purpose MPLS Label Values" registry.
2. requests that IANA creates a new category called "MPLS Network Actions Parameters" within the "Multiprotocol Label Switching Architecture (MPLS)" category
3. requests that IANA creates a new registry with the name "Network Action Flags Without Ancillary Data" within the "Multiprotocol Label Switching Architecture (MPLS)" category.
4. requests that IANA creates a new registry with the name "Network Action Opcodes".

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
[Ans]: None.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/