Dear Greg,
On behalf of the authors. We received feedback from Deb, Gunter, Med and Greg and decided to publish revision -21. https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-21 From what we understand from this conversation is that there is one open item regarding the naming of the performance metrics. We are also expecting feedback from Éric, Tim, Gorry and Mike and based on their and the discussion with you we will merge the input in -22. Best wishes Thomas From: Graf Thomas, SCS-INI-NET-VNC-E2E Sent: Monday, September 8, 2025 8:43 AM To: Greg Mirsky <[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) Dear Greg, Thanks a lot. See my reply inline. Best wishes Thomas From: Greg Mirsky <[email protected]<mailto:[email protected]>> Sent: Monday, September 8, 2025 2:53 AM To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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. Dear Thomas, thank you for adding more structure to the discussion. Please find my follow-up notes below tagged GIM2>>. Regards, Greg On Sat, Sep 6, 2025 at 11:48 PM <[email protected]<mailto:[email protected]>> wrote: 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? TG> 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. GM> thought that Passive refers to the measurement method, not the method of collecting metrics Thans a lot. I think we misunderstand each other. We need to distinguish between the performance metrics definition which includes 'method AND metrics' and the IPFIX where 'metrics' are defined. Section 4.1.1.2 of draft-ietf-opsawg-ipfix-on-path-telemetry-21 defines the name of the performance metrics. The document follows the guideline from https://datatracker.ietf.org/doc/html/rfc8911#section-7.1.2 which includes RFC 7799 terminology and how it applies in performance metrics naming. https://datatracker.ietf.org/doc/html/rfc8912 is the first document describing performance metrics following those guidelines. Section 4 of draft-ietf-opsawg-ipfix-on-path-telemetry-21 follows the criteria in https://datatracker.ietf.org/doc/html/rfc8911#section-5 where one objective is "accurate in terms of producing equivalent results". https://www.rfc-editor.org/rfc/rfc7013.html#section-4.1 gives guidance on IPFIX entity naming. Even though https://datatracker.ietf.org/doc/html/rfc8911#section-1 intend is to facilitate a centralize performance metrics which can be then referenced when being used in data models of telemetry protocols such as IPFIX or YANG, it does not give guidance on naming those data elements. This makes sense to me since IPFIX and YANG as example models and name data differently. Have different taxonomies. Taking https://datatracker.ietf.org/doc/html/rfc8911#section-7.1.2 as naming guidance, do you agree that the following names match the guidance or do you propose a different more appropriate name? 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 GIM2>> I have two questions to use of HybridType1 and Passive in the naming performance metrics: * RFC 7799 defines Hybrid Type 1 measurement methods as follows: Augmentation or modification of the stream of interest, or employment of methods that modify the treatment of the stream Should note that "stream" here is interpreted as a flow of data, i.e., customer's, packets. On the other hand, since the publication of RFC 9197 and RFC 9326, where only combination of IOAM shim with a data packet is considered, we have drafts that propose combining IOAM shim with, for example, STAMP packet. Such a measurement method, in my opinion, is an active method according to RFC 7799. Do you agree? TG2> Correct. It is active because packets are originated and reflected at the OAM node with STAMP. Hence my first question: Are these performance metrics produced using only RFC9197-based manner or also combining, for example, STAMP and IOAM? TG2> No. Section 4.3.2 "Packet Stream Generation" should be clear with the sentence "The time when the packet is being received at the OAM header encapsulating node" that the OAM packet is not originated. It is passive therefore. If the intention to include both approaches, characterization Hybrid Type 1 in the name contradicts my conclusion about the combination of STAMP and IOAM as an active measurement method. TG2> It is not the authors intention. My second question is about using Passive in the name. As understand naming recommendation<https://datatracker.ietf.org/doc/html/rfc8911#name-name>, HybridType1_Passive intended to reflect a method that is recommended as follows: Method: One of the methods defined in [RFC7799], such as and not limited to: As an alternative to HybridType1_Passive, I propose Hop_by_Hop What are your thoughts? TG2> Since neither RFC 7799 nor RFC 8911 contain the word "hop" nor "Hop_by_Hop" I object to introduce new terms which are not clearly defined prior. I would like to understand what the objective (judging from prior questions, probably your concern is that it is applicable beyond Hybrid Type 1 Passive, which is not the case) is and from there I can help to make a proposal. Taking https://www.rfc-editor.org/rfc/rfc7013.html#section-4.1 as naming guidance, taking from that guidance "new Information Elements pertaining to a specific protocol should name the protocol in the first word in order to ease searching by name" into account, considering that the IPFIX metering process can't distinguish between wherever the metrics are generated actively or passively, take icmp packets captured by the IPFIX process as example, do you agree that the following names match the guidance or do you propose a different more appropriate name than pathDelay? 6.2. IPFIX Entities * pathDelayMeanDeltaMicroseconds pathDelayMinDeltaMicroseconds pathDelayMaxDeltaMicroseconds pathDelaySumDeltaMicroseconds Best wishes Thomas From: Greg Mirsky <[email protected]<mailto:[email protected]>> Sent: Saturday, September 6, 2025 8:33 PM To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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, Thank you for the expedient response. I thought that Passive refers to the measurement method, not the method of collecting metrics. If Passive in the registry name refers to IPFIX as the performance metric collection method, should all metrics collected using IPFIX include the Passive reference? Is this naming convention used in the IANA Performance Metrics registry<https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml>? If performance metrics defined in the draft are collected using methods other than IPFIX, e.g., YANG notifications, should it be described in the registry as a different metric? And as we are discussing naming, according to RFC 7799, the Hybrid performance method is a combination of Passive and Active measurement methods. IOAM and Alternate Marking are examples of a Hybrid measurement method when applied to a data flow. However, when IOAM or Alternate Marking is used in combination with a specially constructed test packet, e.g., STAMP, it is still characterized as an Active measurement method. But that combination can produce performance metrics defined in the draft under discussion. That brings me to question the use of Hybrid Type 1 in the naming of new entries in the IANA Performance Metrics registry. Would both cases of using IOAM or Alternate Marking be generalized by replacing HybridType1 with another identification, e.g., HopByHop, to signify the collection of performance metrics from transit nodes? What are your thoughts? Regards, Greg On Sat, Sep 6, 2025 at 1:07 AM <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]>> Sent: Saturday, September 6, 2025 2:16 AM To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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: * 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 > > > >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
