[OPS-DIR]Re: draft-ietf-mpls-on-path-telemetry-flag-01 early Opsdir review

[Haoyu Song <[e-mail]>]

Hi Carlos,

Thanks again for the careful OPSDIR review! The central point of the review, i.e., the insufficient operational and management treatment, was well taken. In the updated revision we added a dedicated operational section plus concreate mechanisms for the specific gaps you called out. Please see below for our response to each comment inline marked as [HS] where we also explain what changes were made specifically.

We hope these updates close the operational/manageability gap and would welcome any further comments.

Best regards,
Haoyu

-----Original Message-----
From: Carlos Pignataro via Datatracker <[e-mail]>
Sent: Friday, July 31, 2026 10:42 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: draft-ietf-mpls-on-path-telemetry-flag-01 early Opsdir review

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.

[HS] Addressed. Following the pattern of draft-ietf-mpls-mna-ps-hdr, in the revision, we created a new "Operational and Manageability Considerations" section. We explicitly added 'MUST'/'SHOULD' requirements for maintaining counters (marked packets, triggered/dropped postcards, malformed instructions), action tracking, and generating rate-limited alarms for dropped postcards or anomalous flag rates. The abstract and introduction were updated to state that the document now provides operational, manageability, and security considerations, and to preview the concrete mechanisms for load control, DoS mitigation, configuration scalability, and partial-path telemetry.

## 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?"

[HS] Addressed in Section 5.1. We added a "Partial Path Support" bullet point in the new operational section. It now explicitly tier to RFC9994 §12.3.  It advises operators and analytic systems to use TTL gaps or IGP topology data to differentiate between an idle network hop and a non-PBT-M-aware node dropping the telemetry trigger.

* 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.

[HS] Addressed in Section 4.4 and 6. We updated the "Load Control" and "Security Considerations" sections by replacing descriptive text with strict directives: devices MUST limit packet marking rates, and a default hard limit on the generation of postcards per second SHOULD be configured on all PBT-M-aware nodes. We provide two default and tunable rates limits: head node marking rate and PBT-M-aware node postcard generation rate.

* 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.

[HS] Addressed in Section 4.2. We added a paragraph to the "Flow Path Discovery" section directing controllers to employ scalable configurations and implement a graceful aging mechanism for stale configurations, rather than explicitly revoking them on every path change. As a path shifts, the new path is re-learned by the collector, which drives targeted updates only on the newly active nodes.

---

## 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!

[HS] Fixed. We updated the reference ID and the corresponding XML reference tags to "draft-ietf-mpls-mna-ps-hdr" throughout the document.

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

[HS] Fixed. The Security Considerations section now uses normative "MUST" ("security measures MUST be taken"; "ingress filtering and the default rate-limiting posture MUST be applied").

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

[HS] Addressed. The Use Cases subsection (now Section 5.4) was rewritten around measurable claims derived from the encoding itself (The subjective terms ("critical," "viable," "fills the gaps") were removed.):
PBT-M adds a fixed 3-LSE MNA Sub-Stack (Format A/B/D) = 12 octets, constant regardless of hop count or the number/size of telemetry parameters, because the data is carried out-of-band in postcards rather than in-situ. It therefore consumes a constant three label positions of the MLD/MSD budget: enabling telemetry on an N-segment SR-TE path reduces the segments that fit within a given MSD by at most three, independent of N. It adds a fixed 12 octets at the ingress and nothing per hop, so there is no per-hop PMTU impact, versus in-stack passport-mode telemetry that may grow by tens to hundreds of octets across a path.

---

## Nits

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

[HS] Addressed. In the new revision, we renamed Section 5 to "Implementation and Operational Recommendations" and nested the newly created "Operational and Manageability Considerations" inside. This expansion provides a comprehensive guide for network operators in one place.

---

I hope these are clear and useful!

Thanks, and best,

Carlos Pignataro