Hi Thomas, Checked the diff right now. All looks good to me.
Thank you for taking care of the comments. Cheers, Med > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : vendredi 5 septembre 2025 07:17 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected] > Cc : [email protected]; opsawg- > [email protected]; [email protected] > Objet : RE: [OPSAWG]Mohamed Boucadair's Yes on draft-ietf-opsawg- > ipfix-on-path-telemetry-20: (with COMMENT) > > 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 <[email protected]> > Sent: Monday, July 28, 2025 5:34 PM > To: The IESG <[email protected]> > Cc: [email protected]; opsawg- > [email protected]; [email protected] > 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/qRNGYGSasUsON8PUvpqrP > 86ojyo/ > > [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 -- [email protected] To unsubscribe send an email to [email protected]
