[mpls] Re: A review of draft-ietf-mpls-mna-ioam

["Frank Brockners (fbrockne)" <[e-mail]>]

Adrien asked me to review draft-ietf-mpls-mna-ioam. I just read through version -09.
Overall, the document reads well, though IMHO there are a couple of points that could be improved:

* Section 4.1 - "... detect the HbH Option-Type": Do you mean "Pre-allocated Trace-Option-Type"?

* Section 4.1.1 - Block-Number field. How is this field treated if alternate marking is not used? Is it scoped to a namespace, flow?

* Section 4.2.1 - mentions that "However, currently only two flags have been assigned by IANA as defined in Section 4.3 of [RFC9326]".. Apparently there are 4 Extensions-Flags by now, those defined by RFC 9326 and those defined by RFC 9630, see https://www.iana.org/assignments/ioam/ioam.xhtml?utm_source=chatgpt.com#dex-flags. A reference to RFC 9630 should be added.

* Section 4.2.1 - Is there a reason, why the document references RFC 9197 for the definition of several fields (IOAM-Trace-Type-MNA, ..) of the MNA ISD variant of the IOAM-DEX Option-Type? I would have expected reference to RFC 9326 instead, which defines the DEX Option-Type format, and refers back to RFC9197 where suitable.

* Section 5.1 (as example) - Overall IOAM nomenclature should be streamlined and made consistent with RFC 9197. I.e., it is "IOAM-Data-Fields" and not "IOAM data fields". Also the document sometimes says, "data fields", when it refers to IOAM-Option-Types. I.e., if you are picky, you could say that "I2E IOAM data fields" do not exist. From the context given in the section, I could guess that the doc means the "IOAM Edge-to-Edge Option-Type". How about we simply say that? (To be fair, in parts this is done - but it is not consistent). In addition, I personally find the renaming to I2E very confusing. While I understand that you loan these terms from RFC 9789, IMHO we need to stay consistent: If you one uses IOAM-Data-Fields or Option-Types, one would expect the use of IOAM nomenclature. If we are talking about MNA then one would expect MNA nomenclature. 

* Section 5.1 - "The decapsulating node MAY punt the IOAM data fields..." - Is there a reason why we are so specific on implementation details here?

Cheers, Frank

> -----Original Message-----
> From: Adrian Farrel <[e-mail]>
> Sent: Wednesday, 1 July 2026 19:47
> To: Frank Brockners (fbrockne) <[e-mail]>
> Subject: A review of draft-ietf-mpls-mna-ioam
> 
> Hi Frank,
> 
> The authors of https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-ioam/
> have asked for WG last call.
> Discussion of this work on the list has been very insubstantial so the chairs are
> poking a few key people to see whether they have time (yeah, I know, IETF-
> 126) to skim the text and raise any issues or support that might come to mind.
> 
> Cheers,
> Adrian