[mpls] Re: draft-ietf-mpls-mna-ps-hdr-08 ietf last call Opsdir review

[Rakesh Gandhi <[e-mail]>]

Hi Chongfeng,

Thank you for the detailed Opsdir review and suggestions.

We have updated the work in progress revision (09) that addresses your
comments.

Please see replies inline with <RG>...


On Tue, Jun 16, 2026 at 7:33 AM Chongfeng Xie via Datatracker <
[e-mail]> wrote:

> Document: draft-ietf-mpls-mna-ps-hdr
> Title: Post-Stack MPLS Network Action (MNA) Header Specification
> Reviewer: Chongfeng Xie
> Review result: Has Issues
>
> Hi,
>
> I have been selected as the Operational Directorate (opsdir) reviewer for
> this
> Internet-Draft.
>
> The Operational Directorate reviews all operational and management-related
> Internet-Drafts to ensure alignment with operational best practices and
> that
> adequate operational considerations are covered.
>
> A complete set of _"Guidelines for Considering Operations and Management in
> IETF Specifications"_ can be found at
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.
>
> While these comments are primarily for the Operations and Management Area
> Directors (Ops ADs), the authors should consider them alongside other
> feedback
> received.
>
> - Document: [draft-ietf-mpls-mna-ps-hdr-08]
>
> - Reviewer: [Chongfeng Xie]
>
> - Review Date: [June 17, 2026]
>
> - Intended Status: [Proposed Standard]
>
> ---
>
> ## Summary
>
> Choose one:
>
> - Has Issues: I have some minor concerns about this document that I think
> should be resolved before publication.
>
> ## General Operational Comments Alignment with RFC 5706bis
>
> > This document defines a mechanism to influence packet forwarding
> decisions
> based on the additional
>     information in the MPLS packet, or perform user-defined operations.
> While
>     the technical approach is sound,  the document lacks the consideration
> on
>     how the mechanism would be deployed and managed, and it is recommended
> that
>     a section on operational considerations be added to aligh with
> RFC57606 bis.
>

<RG> We have added the following section.




























*8.  Operational Considerations   The operational considerations in
[I-D.ietf-mpls-mna-hdr] also apply   to this document.   Performance and
scale assessments are outside the scope of this   document; the authors of
any future PS MNA application documents are   encouraged to address
them.8.1.  Manageability Considerations   A PS MNA implementation MAY
collect the following counters:   *  MNA Sub-Stacks with P flag received
 *  MNA Sub-Stacks with P flag processed   *  PS MNA per-network-action
counters   *  Packets with PSMH dropped due to unknown actions   *  Packets
with PSMH skipped due to unknown actions   *  Packets with PSMH dropped due
to malformed PSMH   Additionally, tracking both successful invocations and
failures for   each specific post-stack network action is RECOMMENDED to
provide   granular visibility.  Nodes MAY generate rate-limited
notifications   or alarms for significant operational events, such as
sustained high   rates of PS MNA packet drops or frequent encounters of
malformed   PSMH, to alert operators to potential issues.  Comprehensive
logging   of PS MNA processing details and outcomes can aid in the network
 diagnostics and post-mortem analysis.*



>
> ## Major Issues
>
>  > No major issues found.
>
> ---
>
> ## Minor Issues
>
> List non-blocking but important clarifications (e.g., ambiguous
> terminology or
> incomplete examples).
>
> > This document currently uses full terms and their abbreviations
> interchangeably (e.g., “Post-Stack MPLS Header” and “PSMH”). To avoid
> redundancy, it is recommended to adopt a single consistent form throughout,
> otherwise, defining the abbreviation is unnecessary.
>

<RG> Fixed.


>
> > It is recommended to change the definition of IHS as below,
>
>   OLD:
>       IHS (2 Bits): The In-Stack NAS for each scope with the P bit set
>       has a corresponding Post-Stack MPLS Header.
>
>   NEW:
>     IHS (2 Bits): The scope of all the network actions for the In-Stack NAS
>     with the P bit set.
>

<RG> Updated as following:


*   *  IHS (2 Bit): The scope of all the NAIs encoded in the NAS as well
  as in the corresponding PSMH.*



>
> > In section 3.1, the definition of the S flag should be relocated to
> precede
> that of the U flag, and the text can be changed to "Same to the definition
> of S
> flag in section 4.2 of [I-D.ietf-mpls-mna-hdr]"
>

<RG> Added as following:


*The following fields are carried in an NAS as defined in
 [I-D.ietf-mpls-mna-hdr] and shown in Figure 1. *





*   *  S (1 Bit): The BoS.   *  NASL (4 Bits): The Network Action Sub-Stack
Length.   *  NAL (3 Bits): The Network Action Length.*



>
> > Regarding the title of section 3.2.1, since the struct in figure 2
> contains
> not only header type, but also PFN and PSMH-Len, it is more suitable to use
> "Post-Stack MPLS Base Header", instead of "Post-Stack MPLS Header Type".
>

<RG> Updated.


>
> >In section 3.2.3, I think the addreviation of "PSMHT" can be removed, too
> many
> abbreviations, particularly those without substantive meaning, do not
> contribute much to the draft.
>

<RG> Removed PSMHT and replaced with Base.


>
> >The title of section 4.1 can be simplified as,
>      OLD:
>           In-Stack Network Action Opcode for PSMH Start Offset for MNA
>      NEW:
>           Opcode for PSMH Start Offset for MNA
>

<RG> Updated to:
*4.1.  Opcode for PSMH Start Offset*


> >The title of section 4.2 can be simplified as,
>     OLD:
>       In-Stack Network Action Opcode for Offset of End of Post-Stack MPLS
>       Header for MNA
>
>     NEW:
>      Opcode for Offset of End of Post-Stack MPLS Header for MNA
>


<RG> Updated to:
*4.2.  Opcode for PSMH End Offset*


> > In section 5.3,  "ingress node" is used to refer to the node that adds a
> Post-Stack MPLS Header, to avoid duplicative terms., it is suggested to
> change
> it to "Encapsulating node" , and the terms of "participating node" and
> "egress
> node" can be changed to "encapsulating node" and "decapsulating node"
> repectively.
> ---
>

<RG> Updated.

Thanks,
Rakesh (for authors)




>
> ## Nits
>
> > No Nits found.
>
> ---
>
> Chongfeng Xie
>
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>