[mpls] draft-ietf-mpls-on-path-telemetry-flag-01 early Opsdir review

[Carlos Pignataro via Datatracker <[e-mail]>]

Document: draft-ietf-mpls-on-path-telemetry-flag
Title: MPLS On-Path Telemetry Network Action Flag for OAM
Reviewer: Carlos Pignataro
Review result: Serious 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.

Reviewer: Carlos Pignataro
Review type: OPSDIR
Document: draft-ietf-mpls-on-path-telemetry-flag-01
Title: MPLS On-Path Telemetry Network Action Flag for OAM
Reviewed version: -01
Review date: 6 July 2026
Intended status (per doc header): Standards Track
WG: mpls

---

## Summary

Choose one:

- Has Major Issues: I have significant concerns about this document and
recommend that the OPS ADs discuss these issues further with the authors.

Problem statement is clear, scope is on-topic for mpls WG, encoding is
consistent with RFC 9994's mutable-data placement rules (Format D LSE, bits
24-31, outside both the 20-bit and 23-bit ECMP-sensitive ranges).

Main OPSDIR gap: no operational/manageability treatment. The sibling document
draft-ietf-mpls-mna-ps-hdr added exactly this section in response to its own
OPSDIR review -- same base spec, same WG...

## General Operational Comments Alignment with RFC 5706bis

* No Operational/Manageability Considerations section. RFC 9994 §12/12.1 and
draft-ietf-mpls-mna-ps-hdr §8/8.1 set the baseline pattern: counters (marked,
triggered, dropped, malformed), success/failure tracking per action,
rate-limited alarms. Add the PBT-M equivalent.

## Major Issues

* Partial PBT-M support along a path isn't addressed operationally. RFC 9994
§12.3 (Backward Compatibility) covers capable/incapable node interaction; this
draft doesn't (and should) extend that to "operator sees an incomplete postcard
set... is that a hop idle or non-PBT-M-aware?"

* Load control / DoS (§4.4, §6) stays descriptive. "Sampling and metering,"
"security measures must be taken" -- that's a nice intro but it there is no
actionable, concrete default posture, despite Req. 4 explicitly framing this as
a DoS vector.

* Req. 2 config-scalability cost (§3, §4.2) is named, but not resolved. Flow
Path Discovery addresses learning the path, not the configuration-churn problem
as paths shift. This is, of course, another OPSDIR relevant issue.

---

## Minor Issues

List non-blocking but important clarifications (e.g., ambiguous terminology or
incomplete examples).

* draft-jags-mpls-ps-mna-hdr-05 --> now draft-ietf-mpls-mna-ps-hdr-12!

* §6 uses lowercase "must" despite BCP 14 in §1.1 — fix or reword.

* §5.3 Use Cases reads aspirational ("critical solution," "critical
optimization") — please use **measurable** claims.

---

## Nits

* Suggestion: §5 is three short paragraphs for the section that operators
really need --> expand or restructure, and leverage for an Operational
Considerations section.

---

I hope these are clear and useful!

Thanks, and best,

Carlos Pignataro