Hi Greg, Just a ping on this. Thank you.
Best regards, David Dong IANA Services Sr. Specialist On Thu Sep 11 07:04:53 2025, [email protected] wrote: > 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]; Michael.Scharf@hs- > esslingen.de; [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:drafts-expert-review- > [email protected]>; Michael.Scharf@hs- > esslingen.de<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 > GIM>> Type 1 and Passive are concatenated in IE's name, e.g., > GIM>> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum? > > TG> The reason why passive is chosen is because of the document scope: > TG> Export of Delay Performance Metrics in IPFIX. The IPFIX process > TG> passively observes IP flows. Section 4.3.2, Packet Stream > TG> Generation, starts with "The time when the packet is being received > TG> at the OAM header encapsulating node" therefore. > > GM> thought that Passive refers to the measurement method, not the > GM> 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 > GIM2>> 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 > TG2> 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 > TG2> the sentence "The time when the packet is being received at the > TG2> OAM header encapsulating node" that the OAM packet is not > TG2> 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 > TG2> "Hop_by_Hop" I object to introduce new terms which are not clearly > TG2> defined prior. I would like to understand what the objective > TG2> (judging from prior questions, probably your concern is that it is > TG2> applicable beyond Hybrid Type 1 Passive, which is not the case) is > TG2> 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:drafts-expert-review- > [email protected]>; Michael.Scharf@hs- > esslingen.de<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 > GIM>> Type 1 and Passive are concatenated in IE's name, e.g., > GIM>> 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:drafts-expert-review- > [email protected]>; Michael.Scharf@hs- > esslingen.de<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 > GM> is not consistent with RFC 9232 where the passport mode is referred > GM> to IOAM as defined in RFC 9127, while postcard mode - to RFC 9326. > GM> According to RFC 9232, the passport mode is when telemetry > GM> information is collected along the path and transported in the > GM> trigger packet, while postcard mode - such information is collected > GM> and transported from each traversed node by some mechanism, e.g., > GM> 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" > GIM>> and "OAM header transit node", addresses my concern. You may > GIM>> consider dropping "header" altogether. > > > > GM> Combining "Hybrid Type I" with "Passive" in reference to > GM> performance metrics is confusing and inaccurate. RFC 7799 defines > GM> hybrid measurement methods as a combination of the elements of > GM> passive and active measurement methods. Furthermore, RFC 7799 > GM> identifies two types of hybrid measurement methods - Type I (IOAM > GM> and Alternate Marking are examples of it) and Type II. There's no > GM> 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 > GIM>> Type 1 and Passive are concatenated in IE's name, e.g., > GIM>> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum? > > > > GM> Another concern with the naming new IPFIX IEs is reference to IP in > GM> "HybridType1_Passive_IP". Is it to signify that the IEs are > GM> applicable only to delay measurement of the IP flows? But can they > GM> 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 > GM> "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 > GM> essential and that the reader must understand any document > GM> referenced in the section. Hence, I believe that references to [I- > GM> D.zhou-ippm-enhanced-alternate-marking] and [I-D.fz-spring-srv6- > GM> alt-mark] must be normative, if the Alternate Marking method is in > GM> 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:drafts-expert-review- > [email protected]> > Cc: [email protected]<mailto:Michael.Scharf@hs- > esslingen.de>; [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 <drafts-expert- > [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:drafts-expert-review- > > [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, Michael.Scharf@hs- > > > esslingen.de<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 <drafts-expert-review- > > > > > [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]
