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

[Rakesh Gandhi <[e-mail]>]

Hi Chongfeng,

FYI: Updated draft (rev-09) is posted, that contains the suggested changes.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-ps-hdr/

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-mna-ps-hdr-09

Thanks,
Rakesh (for authors)


On Tue, Jun 23, 2026 at 12:19 PM Rakesh Gandhi <[e-mail]>
wrote:

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