Dear Med, On behalf of the authors, thank you very much for your detailed review and comments.
We addressed your feedback together with Tim's, Mike's, Deb's, Éric's, Gunter's, Greg's and Gorry's as following https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-20&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-on-path-telemetry/refs/heads/main/draft-ietf-opsawg-ipfix-on-path-telemetry-21.txt I hope this addresses your comments. Looking forward to your review. Best wishes Thomas -----Original Message----- From: Mohamed Boucadair via Datatracker <nore...@ietf.org> Sent: Monday, July 28, 2025 5:34 PM To: The IESG <i...@ietf.org> Cc: draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org Subject: [OPSAWG]Mohamed Boucadair's Yes on draft-ietf-opsawg-ipfix-on-path-telemetry-20: (with COMMENT) Mohamed Boucadair has entered the following ballot position for draft-ietf-opsawg-ipfix-on-path-telemetry-20: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Thomas, Benoît, and Alex, Thank your for the effort put into this specification. Interesting to see the approach defined in RFC 8911 exercised here. Also, thanks to Menachem Dodge for the OPSDIR review and Qin Wu for the PERFMETRDIR review. Appreciate that Menachem, Qin, and authors converged for both reviews. As I reviewed a previous version of the spec [1], I only focused the current review on the diff since then [2]. I specifically appreciated the new text added to explain the need for the IEs compared to an approach where intermediate nodes export the timestamps observed in packets and local receiving timestamps and let the collector to do the various math operations. Likewise, I appreciate that the IEs were generalized to be independent of IOAM. I only have very minor comments: # Use the exact registry name ## Section 1 OLD: In order to export the delay-related metrics via IPFIX [RFC7011], this document defines four new IPFIX Information Elements (IEs), exposing the On-Path delay on OAM transit and decapsulating nodes, following the postcard mode principles. Since these IPFIX IEs are performance metrics [RFC8911], they are also registered in the "IANA Performance Metric Registry [IANA-PERF-METRIC]. NEW: In order to export the delay-related metrics via IPFIX [RFC7011], this document defines four new IPFIX Information Elements (IEs), exposing the On-Path delay on OAM transit and decapsulating nodes, following the postcard mode principles. Since these IPFIX IEs are performance metrics [RFC8911], they are also registered in the IANA “Performance Metric” Registry [IANA-PERF-METRIC]. ## Section 1 OLD: Following the guidelines for Registered Performance Metric Requesters and Reviewers [RFC8911], the different characteristics of the performance metrics (Identifier, Name, URI, Status, Requester, Revision, Revision Date, Description, etc.) must be clearly specified in the "IANA Performance Metric Registry [IANA-PERF-METRIC] in order NEW: Following the guidelines for Registered Performance Metric Requesters and Reviewers [RFC8911], the different characteristics of the performance metrics (Identifier, Name, URI, Status, Requester, Revision, Revision Date, Description, etc.) must be clearly specified in the IANA "Performance Metric” Registry [IANA-PERF-METRIC] in order ## Section 3.1 OLD: This section specifies four performance metrics for the Hybrid Type I Passive assessment of IP One-Way Delay, to be registered in the "IANA Performance Metric Registry [IANA-PERF-METRIC]. NEW: This section specifies four performance metrics for the Hybrid Type I Passive assessment of IP One-Way Delay, to be registered in the IANA “Performance Metric” Registry [IANA-PERF-METRIC]. # There might be multiple OAM encapsulating nodes OLD: Assuming time synchronization on devices, the delay is measured by calculating the difference between the timestamp imposed with On-Path Telemetry in the packet at the OAM encapsulating node and the ^^^^ NEW: Assuming time synchronization on devices, the delay is measured by calculating the difference between the timestamp imposed with On-Path Telemetry in the packet at an OAM encapsulating node and the Please check other similar constructs. # I don’t remember I have seen “flow packet” used in other IPFIX specs + there might be many OAM headers RFC7011 defines flow as follows: A Flow is defined as a set of packets or frames passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties. I suggest we make this change: OLD: * Encapsulating Node: Receives the IP Flow packets, encapsulates the ^^^^^^^^^^^^ packets with the OAM header and adds the timestamp into the OAM header. * Transit Node: Receives the IP Flow packets, measures the delay^ ^^^^^^^^^^^^ between the timestamp in the packet and the timestamp when the packet was received. * Decapsulating Node: Receives the IP Flow packets, computes the ^^^^^^^^^^^^ delay between the timestamp in the packet and the timestamp when the packet was received and removes the OAM header from the packet. NEW: * Encapsulating Node: Receives the IP packets, encapsulates the packets with an OAM header and adds the timestamp into the OAM ^^ header. * Transit Node: Receives the IP packets, measures the delay between the timestamp in the packet and the timestamp when the packet was received. * Decapsulating Node: Receives the IP Flow packets, computes the delay between the timestamp in the packet and the timestamp when the packet was received and removes the OAM header from the packet. # Please add “Collector” and “Observation Point” to the list of terms under 7011 CURRENT: The following terms are used as defined in [RFC7011]: … # (Nit) Only one term is imported from 7799 OLD: The following terms are used as defined in Section 3.8 of [RFC7799]: * Hybrid Type I Passive NEW: The following term is used as defined in Section 3.8 of [RFC7799]: * Hybrid Type I Passive # (nit) Section 3.1.2 OLD: We consider the measurement of one-way delay based on a single Observation Point [RFC7011] somewhere in the network. NEW: The measurement of one-way delay is based on a single Observation Point [RFC7011] somewhere in the network. Please make the same change for other similar constructs in the document. # IANA is the authoritative reference for IEs, not RFC7012 & Use the exact registry names OLD: 5.2. IPFIX Entities This document requests IANA to register new IPFIX IEs (see table 3) under the "IPFIX Information Elements" registry [RFC7012] available at "IANA IP Flow Information Export (IPFIX) Entities Registry [IANA-IPFIX] and assign the following initial code points. NEW: 5.2. IPFIX Entities This document requests IANA to register new IPFIX IEs (see table 3) under the "IPFIX Information Elements" registry under the " IP Flow Information Export (IPFIX) Entities” registry group [IANA-IPFIX] and assign the following initial code points. # RFC-to-be There are several notes to the RFC editor with distinct patterns [RCC-to-be] vs. _RFC[RFC-to-be] (1) with RFC label 778 Reference: [RFC-to-be] (2) without RFC label … 781 OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean in the 782 IANA Performance Metric Registry. Hope this won't be confusing for the RFC editor. # Section 6.5 ## nit s/Section 4.4.2.3 and 4.4.2.4 of [RFC9197]/ Sections 4.4.2.3 and 4.4.2.4 of [RFC9197] There are many such occurrences in the doc. ## Cite RFC8754 CURRENT: 919 be applied to the SRv6 Segment Routing Header. Hope this helps. Cheers, Med [1] https://mailarchive.ietf.org/arch/msg/opsawg/qRNGYGSasUsON8PUvpqrP86ojyo/ [2] https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-ipfix-on-path-telemetry-08&url2=draft-ietf-opsawg-ipfix-on-path-telemetry-20&difftype=--html
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
