Dear Greg, GIM>> I probably was not clear in my notes. My question is Why Hybrid Type 1 and Passive are concatenated in IE's name, e.g., OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum?
Apologies for not having commented this point. OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum is the name in the performance registry. Not the IE name. The name for the performance registry is defined in section 4.1.1.2 where for IPFIX entities in 6.2 4.1.1.2. Name OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum 6.2. IPFIX Entities pathDelayMeanDeltaMicroseconds pathDelayMinDeltaMicroseconds pathDelayMaxDeltaMicroseconds pathDelaySumDeltaMicroseconds The reason why passive is chosen is because of the document scope: Export of Delay Performance Metrics in IPFIX. The IPFIX process passively observes IP flows. Section 4.3.2, Packet Stream Generation, starts with "The time when the packet is being received at the OAM header encapsulating node" therefore. Does that clarify your question or do you propose different names? Paul as designated IPFIX expert is on C. Best wishes Thomas From: Greg Mirsky <[email protected]> Sent: Saturday, September 6, 2025 2:16 AM To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [OPSAWG]Re: [IANA #1422930] expert review for draft-ietf-opsawg-ipfix-on-path-telemetry (performance-metrics) Be aware: This is an external email. Hi, Thomas and the authors, thank you for your careful consideration of my comments. I appreciate updates that address them improving the document. Please find my follow-up notes below tagged GIM>>. Regards, Greg On Thu, Sep 4, 2025 at 10:16 PM <[email protected]<mailto:[email protected]>> wrote: Dear David and Greg, 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, Med's, Deb's, Éric's, Gunter'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 GM> Characterization if Passport and Postcard modes in the Introduction is not consistent with RFC 9232 where the passport mode is referred to IOAM as defined in RFC 9127, while postcard mode - to RFC 9326. According to RFC 9232, the passport mode is when telemetry information is collected along the path and transported in the trigger packet, while postcard mode - such information is collected and transported from each traversed node by some mechanism, e.g., over the management plane. Your description on Passport and Postcard mode is correct. Regarding RFC 9232 reference. I believe you are refering to https://datatracker.ietf.org/doc/html/rfc9232#appendix-A.3.5. Our understanding is that IOAM is one of many implementations of passport resp. postcard mode. Your understanding is that IOAM the only implementation correct? GIM>> The updated terminology, i.e., "OAM header decapsulating node" and "OAM header transit node", addresses my concern. You may consider dropping "header" altogether. GM> Combining "Hybrid Type I" with "Passive" in reference to performance metrics is confusing and inaccurate. RFC 7799 defines hybrid measurement methods as a combination of the elements of passive and active measurement methods. Furthermore, RFC 7799 identifies two types of hybrid measurement methods - Type I (IOAM and Alternate Marking are examples of it) and Type II. There's no mention of Hybrid Type I Passive in RFC 7799. This has been addressed by refering now to two terms "Passive" and "Hybrid Type I" to section 3.7 and 3.8 of RFC 7799 separately. GIM>> I probably was not clear in my notes. My question is Why Hybrid Type 1 and Passive are concatenated in IE's name, e.g., OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum? GM> Another concern with the naming new IPFIX IEs is reference to IP in "HybridType1_Passive_IP". Is it to signify that the IEs are applicable only to delay measurement of the IP flows? But can they be used to export delay metrics of, for example, an MPLS flow? The document scope is IP flow. Therefore IP is used in the naming. GM> Some key elements used in the document, e.g., "OAM node" and "Collector", are underdefined. "Collector" has been used from RFC 7011 and is now defined as well. "OAM node" has been replaced with "OAM header encapsulating node", "OAM header transit node" and "OAM header decapsulating node" which are defined in the document. GIM>> Thank you. GM> I consider the content of Section 3.2.2 Packet Stream Generation essential and that the reader must understand any document referenced in the section. Hence, I believe that references to [I-D.zhou-ippm-enhanced-alternate-marking] and [I-D.fz-spring-srv6-alt-mark] must be normative, if the Alternate Marking method is in the scope of the document. I agree that the "Packet Stream Generation" section contains two normative sentences: The time when the packet is being received at the OAM header encapsulating node. The timestamp format depends on On-Path Telemetry implementation. However the sentences describing possible implementations such as IOAM or Enhanced Alternate Marking are not normative since in the preceding section, "IP One-Way Delay Hybrid Type I Passive Performance Metrics", a generic metric definition is defined as per RFC 8911. I hope this addresses your comments. Looking forward to your review. Best wishes Thomas From: Greg Mirsky <[email protected]<mailto:[email protected]>> Sent: Friday, August 1, 2025 10:52 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [OPSAWG]Re: [IANA #1422930] expert review for draft-ietf-opsawg-ipfix-on-path-telemetry (performance-metrics) Hi David, thank you for your kind consideration. Iread the latest version of the draft and found that my concern about the naming new IEs ( see comments from 10, 2024<https://mailarchive.ietf.org/arch/msg/opsawg/kbNvNZgNfDThtg3ZZj9q0Jawx80/>) is not addressed, along with concerns with using undefined entities like "OAM node" and "Collector". Below, please find my comments to the draft-ietf-opsawg-ipfix-on-path-telemetry-20<http://>: * Characterization if Passport and Postcard modes in the Introduction is not consistent with RFC 9232 where the passport mode is referred to IOAM as defined in RFC 9127, while postcard mode - to RFC 9326. According to RFC 9232, the passport mode is when telemetry information is collected along the path and transported in the trigger packet, while postcard mode - such information is collected and transported from each traversed node by some mechanism, e.g., over the management plane. * Combining "Hybrid Type I" with "Passive" in reference to performance metrics is confusing and inaccurate. RFC 7799 defines hybrid measurement methods as a combination of the elements of passive and active measurement methods. Furthermore, RFC 7799 identifies two types of hybrid measurement methods - Type I (IOAM and Alternate Marking are examples of it) and Type II. There's no mention of Hybrid Type I Passive in RFC 7799. * Another concern with the naming new IPFIX IEs is reference to IP in "HybridType1_Passive_IP". Is it to signify that the IEs are applicable only to delay measurement of the IP flows? But can they be used to export delay metrics of, for example, an MPLS flow? * Some key elements used in the document, e.g., "OAM node" and "Collector", are underdefined. * I consider the content of Section 3.2.2 Packet Stream Generation essential and that the reader must understand any document referenced in the section. Hence, I believe that references to [I-D.zhou-ippm-enhanced-alternate-marking] and [I-D.fz-spring-srv6-alt-mark] must be normative, if the Alternate Marking method is in the scope of the document. I hope that my comments are helpful. Regards, Greg On Tue, Jul 29, 2025 at 1:46 PM David Dong via RT <[email protected]<mailto:[email protected]>> wrote: Hi Greg, That will be fine, thank you! Best regards, David Dong IANA Services Sr. Specialist On Tue Jul 29 20:44:30 2025, [email protected]<mailto:[email protected]> wrote: > Hi David, > my apologies for the belated response and missing the deadline. I can > review the current version by August 1st. Please let me know if that is > acceptable to you. > > Regards, > Greg > > On Tue, Jul 29, 2025 at 12:39 PM David Dong via RT < > [email protected]<mailto:[email protected]>> > wrote: > > > Hi Greg, > > > > Just a ping on this one if you're available to take another look at this > > document. > > > > Thank you! > > > > Best regards, > > > > David Dong > > IANA Services Sr. Specialist > > > > On Wed Jul 16 20:58:45 2025, > > [email protected]<mailto:[email protected]> wrote: > > > Hi David, > > > > > > As Greg has already reviewed earlier versions of this document, I > > > believe that he is in a better position to review this document. > > > > > > If Greg is not available, I'd have a look myself. > > > > > > I have not followed this document in detail so far. As far as I can > > > see, there has been a OPSAWG list discussion regarding IANA in the > > > past. For what it is worth, I back some of the questions raised by > > > Greg in his past e-mail > > > ( > > https://mailarchive.ietf.org/arch/msg/opsawg/kbNvNZgNfDThtg3ZZj9q0Jawx80/ > > ). > > > And at least in the list archive it is not clear how all of them have > > > been resolved, as there is only one follow-up posting. For instance, > > > RFC 7799 Section 3.8 doesn't really define a combination of "Hybrid I" > > > and "Passive", as far as I read the text of RFC 7799. But Greg has > > > probably more context regarding that discussion. > > > > > > Best regards > > > > > > Michael > > > > > > > > > > > > > -----Original Message----- > > > > From: David Dong via RT > > > > <[email protected]<mailto:[email protected]>> > > > > Sent: Tuesday, July 15, 2025 12:01 AM > > > > Cc: [email protected]<mailto:[email protected]>; Scharf, > > > > Michael <Michael.Scharf@hs- <mailto:Michael.Scharf@hs-%0b>> > > > esslingen.de<http://esslingen.de/>>; [email protected]<mailto:[email protected]> > > > > Subject: [IANA #1422930] expert review for draft-ietf-opsawg-ipfix- > > > > on-path- > > > > telemetry (performance-metrics) > > > > > > > > Dear Greg Mirsky, Michael Scharf (cc: opsawg wg), > > > > > > > > As the designated experts for the Performance Metrics Registry, can > > > > you > > > > review the proposed registrations in draft-ietf-opsawg-ipfix-on-path- > > > > telemetry-19 for us? Please see > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path- > > > > telemetry/ > > > > > > > > The due date is July 28th. > > > > > > > > If this is OK, when the IESG approves the document for publication, > > > > we'll make > > > > the registration at: > > > > > > > > https://www.iana.org/assignments/performance-metrics/ > > > > > > > > Unless you ask us to wait for the other reviewer, we’ll act on the > > > > first response > > > > we receive. > > > > > > > > With thanks, > > > > > > > > David Dong > > > > IANA Services Sr. Specialist > > > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
