[mpls] Re: WG Last Call: draft-ietf-mpls-mna-ioam-11 (Ends 2026-09-02)

[Rakesh Gandhi <[e-mail]>]

Thank you Jie for the review comments and suggestions.

We have posted rev-12 that addresses your comments.

https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-ioam/

Please see replies inline with <RG>...


On Thu, Aug 20, 2026 at 9:27 PM Dongjie (Jimmy) <jie.dong=
[e-mail]> wrote:

> Hi Adrian,
>
> I've read the latest version of this draft and support its publication.
>
> There are a few nits for the authors to consider.
>
> - In 2.1 terminology, the reference for the term "AD (Ancillary Data)"
> should be RFC 9613.
>

<RG> Updated.


>
> - The authors may consider to add the term "Blob" to the terminology
> section, with a reference to this draft.
>

<RG> Added.


>
> - In section 3, the description of IOAM-DEX does not reflect its
> difference from other IOAM option-types. It is suggested to have something
> similar to the description of IOAM-DEX in the introduction section.
>

<RG> Updated.


>
> - In the last paragraph of section 4.2, it is suggested to re-organize the
> order of the text to improve readability. The text after changing the order
> could be something like:
>
>    "The Opcodes TBA1 and TBA2 MUST NOT be carried in the same NAS,
> otherwise the packet MUST be treated as malformed and MUST be dropped.
> IOAM-DEX MAY be carried simultaneously as both In-Stack Data using Opcode
> TBA2 and Post-Stack Data using Opcode TBA1 in different NASes of the same
> MPLS Packet. Each Network Action operates independently: TBA2 triggers
> direct export at nodes processing the In-Stack NAS, while TBA1 triggers
> direct export at nodes processing the Post-Stack NAS."
>

<RG> Changed the order and updated as bullet points for clarity.


>
> As the term In-Stack NAS and Post-Stack NAS are introduced by this
> document, the authors may consider to add some clarifications about their
> meanings. For example, can a Post-stack NAS contain some in-stack network
> actions other than IOAM-DEX ?
>

<RG> Removed new terms like Post-Stack NAS and edited the text for clarity.


Thanks,
Rakesh (for authors)




> Hope this helps.
>
> Best regards,
> Jie
>
> -----Original Message-----
> From: Adrian Farrel via Datatracker <[e-mail]>
> Sent: Thursday, August 20, 2026 3:22 AM
> To: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: [mpls] WG Last Call: draft-ietf-mpls-mna-ioam-11 (Ends 2026-09-02)
>
> We have all of the IPR response, so...
>
> This message starts a WG Last Call for:
> draft-ietf-mpls-mna-ioam-11
>
> This Working Group Last Call ends on 2026-09-02
>
> Abstract:
>    In situ Operations, Administration, and Maintenance (IOAM), defined
>    in RFC 9197, collects operational and telemetry information in the
>    packet using IOAM-Data-Fields while the packet traverses a path
>    between two points in the network.  Several IOAM Option-Types are
>    available, for example, Pre-allocated Trace, Proof of Transit (POT),
>    Edge-to-Edge (E2E), and Incremental Trace, that can be used to
>    collect information for calculating various performance metrics.  RFC
>    9326 defines the IOAM Direct Export (IOAM-DEX) Option-Type, which is
>    used as a trigger for IOAM data to be directly exported or locally
>    aggregated without being pushed into in-flight data packets.
>
>    MPLS Network Actions (MNA) techniques indicate actions to be
>    performed on any combination of Label Switched Paths, MPLS packets,
>    and the node itself, and to transport data needed for these actions.
>    This document employs the MNA mechanisms to collect and transport the
>    operational state and telemetry information using IOAM-Data-Fields as
>    well as IOAM-DEX.
>
> File can be retrieved from:
> https://www.ietf.org/archive/id/draft-ietf-mpls-mna-ioam-11.txt
>
> Please review and indicate your support or objection to proceed with the
> publication of this document by replying to this email keeping
> [e-mail] in copy. Objections should be explained and suggestions to
> resolve them are highly appreciated.
>
> Authors, and WG participants in general, are reminded of the Intellectual
> Property Rights (IPR) disclosure obligations described in BCP 79 [1].
> Appropriate IPR disclosures required for full conformance with the
> provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of
> any.
> Sanctions available for application to violators of IETF IPR Policy can be
> found at [3].
>
> Thank you.
>
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-ioam/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-mpls-mna-ioam-11.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-mna-ioam-11
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>