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

[Carlos Pignataro <[e-mail]>]

Hi, Tony,

Thank you for asking!

Regarding my early review, rev -02 seems to have addressed most of my issues. While substantially successful, there’s still some areas that can benefit from improvement.

1. The mitigation added in the last para of S4.2 is a bit vague and unactionable. It is an improvement, but wonder if it the reco can be more concrete.

2. In the operational considerations, I’d check against and cite draft-opsarea-rfc5706bis instead of RFC5706

3. MSD interaction is IS-IS-only — cites RFC 8491 (IS-IS) but not RFC 8476 (OSPF).

4. Is the RTGDIR review misattributed in the Acks?

5. Does RFC 8491 need to be Normative?

6. Lastly, some added textual suggestions for consideration for Section 5.1:

Verifying Correct Operation: Before relying on PBT-M in production, an
operator SHOULD confirm correct operation by marking a small,
controlled set of test packets on a known path and verifying that
the expected postcard set (one per PBT-M-aware node on that path) is
received at the collector.

Management Data Model: This document does not currently define a YANG
data model for configuring or monitoring PBT-M.

Best,

Carlos.



> On Sep 15, 2026, at 6:15 PM, Tony Li <[e-mail]> wrote:
> 
> 
> Hi Carlos,
> 
> This draft has now passed WGLC and is headed to publication.  I believe that the authors have tried to address your comments in -03.  Do you have any further comments or suggestions?  Have they addressed all of your issues to your satisfaction?
> 
> Thanks,
> Tony
> 
> 
>> On Jul 31, 2026, at 11:24 AM, Carlos Pignataro <[e-mail]> wrote:
>> 
>> Thank you for the quick reply, Haoyu, and happy to support and/or clarify.
>> 
>>> On Jul 31, 2026, at 7:53 PM, Haoyu Song <[e-mail]> wrote:
>>> 
>>> Hi Carlos,
>>> 
>>> Thank you very much for the constructive review and revision suggestions. We'll carefully consider the issues, study the related documents, and update the draft accordingly.
>>> 
>>> 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.
>>> 
>>> ## 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
>>> 
>>> 
>> 
>