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

[Tony Li <[e-mail]>]

Hi Carlos,

The authors have now posted version -05. Could you please confirm that this addresses all of your issues?

Thanks,
Tony


> On Sep 19, 2026, at 11:38 AM, Carlos Pignataro <[e-mail]> wrote:
> 
> Thank you Haoyu for engaging, and the quick, useful reply!
> 
> For #1, great text.
> 
> For #3, I meant add both.
> 
> Thanks!
> 
> Carlos.
> 
>> On Sep 18, 2026, at 7:27 PM, Haoyu Song <[e-mail]> wrote:
>> 
>> Hi Carlos,
>> 
>> Thank you very much for the review and new comments! They are very helpful to further improve the documents. 
>> Please see below for my response. Especially for item 1 and 3, I'd like to get your confirmation before making the change. 
>> Once these are settled, I'll go ahead to publish the draft revision.
>> 
>> Best regards,
>> Haoyu 
>> 
>> -----Original Message-----
>> From: Carlos Pignataro <[e-mail]> 
>> Sent: Thursday, September 17, 2026 2:11 PM
>> To: Tony Li <[e-mail]>
>> Cc: Haoyu Song <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [mpls] draft-ietf-mpls-on-path-telemetry-flag-01 early Opsdir review
>> 
>> 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.
>> 
>> [HS] Suggested new text to replace the para to make it more concrete: 
>> 
>> "To mitigate configuration churn caused by frequent path shifts (e.g., due to dynamic routing or ECMP), the basic export data set SHOULD remain enabled as a standing, flow-independent default on all PBT-M-aware nodes, so path discovery needs no per-flow state and follows a shift automatically. The per-flow detailed templates SHOULD be installed as soft state with an idle timeout that is refreshed by continued marking and expires automatically rather than being explicitly revoked on each path change. The idle timeout is set to a small multiple of the marking interval (for example, tens of seconds). To absorb ECMP or fast-reroute shifts without a controller round-trip, the controller MAY pre-install these templates on the ECMP-group members and immediate next-hops adjacent to the current path."
>> 
>> 2. In the operational considerations, I’d check against and cite draft-opsarea-rfc5706bis instead of RFC5706
>> 
>> [HS] Will do.
>> 
>> 3. MSD interaction is IS-IS-only — cites RFC 8491 (IS-IS) but not RFC 8476 (OSPF).
>> 
>> [HS] Do you mean the other way around  (i.e., change RFC8491 to RFC8476) ? Now in the draft the reference is RFC8491.
>> 
>> 4. Is the RTGDIR review misattributed in the Acks?
>> 
>> [HS] Both Bruno Decraene and Gyan Mishra provided RTGDIR review. Will acknowledge in -05. 
>> 
>> 5. Does RFC 8491 need to be Normative?
>> 
>> [HS] Will move to Normative section.
>> 
>> 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.
>> 
>> [HS] Good suggestion. Will be added to the text.
>> 
>> 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
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>