[mpls] draft-ietf-mpls-mna-ioam-09 early Rtgdir review

[Matthew Bocci via Datatracker <[e-mail]>]

Document: draft-ietf-mpls-mna-ioam
Title: Supporting In Situ Operations, Administration, and Maintenance Using
MPLS Network Actions Reviewer: Matthew Bocci Review result: Has Issues

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-spring-bfd-12.txt/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document.

Document: draft-ietf-mpls-mna-ioam-09
Reviewer: Matthew Bocci
Review date: 3rd August 2026

Summary
-------
In general, the draft is clear and readable. Thank you! I have a few comments
and questions that I think should be addressed before proceeding, below. The
following text uses line numbers from the ID-Nits output for the draft.

232     3.  Applicability of IOAM and IOAM-DEX in an MPLS Network

234        Pre-allocated Trace, POT, and E2E IOAM Option-Types [RFC9197] use
235        user packets to collect and transport the operational state and
236        telemetry information.  This document defines the Post-Stack MNA
237        [I-D.ietf-mpls-mna-ps-hdr] solution supporting Pre-allocated Trace,
238        POT, and E2E IOAM Option-Types (Section 4.1).

240        However, for some use cases, e.g., mobile backhaul, in which network
241        resources are closely controlled, collecting and transporting
242        telemetry information within a user packet may noticeably decrease
243        the cost efficiency of network operations.  As such, collecting and

MB> It would be better to avoid talking about cost efficiency and instead refer
to matters that can be described using technical language. MB> I suggest
replacing the above sentence with "...collecting and transporting
           telemetry information within a user packet may increase the
           complexity of network operations."

244        transporting the operational state and telemetry information using
245        the management plane is a viable option for some environments.  IOAM-
246        DEX [RFC9326] allows to collect the IOAM data defined in [RFC9197]
247        using on-path telemetry information.  In this document, the In-Stack
248        and Post-Stack realizations of IOAM-DEX are specified in Section 4.2
249        and Section 4.1, respectively.

MB> This paragraph implies that IOM-DEX support is OPTIONAL in the context of
this document. Perhaps you can state that more clearly.

548        *  Sequence Number MNA: An optional 4-octet field and carries a
549           30-bit sequence number (after removing leading 1 and S bits).  The
550           semantics of the Sequence Number MNA field are as those of the
551           Sequence Number field defined in Section 3.2 of [RFC9326].  The
552           most significant bit MUST be set to 1.  The bit 23 MUST be set

MB> Doesn't this diverge in terms of processing and the handling of wrapping
from RFC9326? Also the sequence number space is significantly less.

553           according to the definition of the S bit in [RFC3032].  In MPLS
554           network environments where label stack information is used for
555           load-balancing flows, the 19-bit-long part of the Sequence Number
556           MNA, starting from the bit 1 position of the LSE, MUST remain
557           immutable for a particular packet flow that the value of the Flow
558           ID MNA field identifies.  In MPLS networks, where other load-
559           balancing techniques are used, all bits of the Sequence Number MNA
560           field can be varied.

MB> Can you explain how the ingress LSR can determine if load balancing is in
use somewhere in the network? This seems difficult for the ingress to verify.
In other cases e.g. SATOP PW, the header containing the sequence number is
designed so that it does not alias for a packet that can be load balanced.

583     5.1.  Ingress-to-Egress Scope IOAM and IOAM-DEX Network Actions

585        The I2E IOAM data fields carry IOAM Option-Types that require
586        processing on the encapsulating and decapsulating nodes only.

588        The IOAM Option-Type carried can be the IOAM E2E Option-Type (value
589        3) defined in [RFC9197] or the IOAM-DEX Option-Type (value 4) defined
590        in [RFC9326].  The I2E IOAM data fields SHOULD NOT carry any IOAM
591        Option-Type that requires IOAM processing on the intermediate nodes,
592        as it will not be processed by them when the IHS scope is set to
593        "I2E, value 0x0".

MB> Is this a 'SHOULD NOT' or a 'MUST NOT'?

595        The I2E IOAM and IOAM-DEX Network Action procedure is summarized as
596        follows:

598        *  The encapsulating node inserts a NAS with the IHS scope set to
599           "I2E, value 0x0", as well as one or more Network Actions for IOAM
600           and IOAM-DEX in the MPLS packet.

602        *  The intermediate nodes do not process the I2E IOAM data fields.

MB> this text seems unnecessary, unless there are cases where you might allow
I2E IOAM to be exposed on an intermediate node, in which case isn't it a MUST
NOT?

604        *  The decapsulating node MAY punt the IOAM data fields from the
605           packet with the receive timestamp to the slow path for processing.
606           The receive timestamp is required by the various I2E IOAM use
607           cases, including streaming telemetry.  Note that the packet is not
608           necessarily punted to the control-plane.

MB> This paragraph is unclear as to what it is trying to achieve in terms of
slow path vs control plane. Do you just mean that the decapsulating node MAY
extract the IOAM data fields, including the timestamp, for further processing?

663     5.3.  Node Capability

665        The decapsulating node that needs to remove the IOAM and IOAM-DEX
666        data fields and perform the IOAM and IOAM-DEX functions may not be
667        capable of supporting them.

MB> Do you mean that an MNA-capably decapsulating node MAY NOT support the IOAM
and IOAM-DEX data fields and related processing in a decapsulated packet? Can
you say that processing is as per the U-bit for unsupported actions? Or is it
possible that a node can support IOAM MNA but not certain IOAM data?

The encapsulating node needs to know if
668        the decapsulating node can support the IOAM and IOAM-DEX functions.
669        The signaling extension for this capability exchange is outside the
670        scope of this document.
672        The intermediate node that is not capable of supporting the IOAM and
673        IOAM-DEX functions defined in this document can simply skip the IOAM
674        and IOAM-DEX processing.

MB> Does this stop proof of transit from working, not just in terms of lack of
IOAM support, but also for nodes that do not support MNA?