Return-Path: X-Original-To: opsawg@mail2.ietf.org Delivered-To: opsawg@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id CBA4133B11B0; Wed, 11 Jun 2025 06:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -3.995 X-Spam-Level: X-Spam-Status: No, score=-3.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdXRK9nDreSW; Wed, 11 Jun 2025 06:37:10 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 6EA9C33B0F7F; Wed, 11 Jun 2025 06:36:39 -0700 (PDT) Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4bHRWf0LQSz6DB3q; Wed, 11 Jun 2025 21:36:14 +0800 (CST) Received: from frapeml500001.china.huawei.com (unknown [7.182.85.94]) by mail.maildlp.com (Postfix) with ESMTPS id 615B61405E2; Wed, 11 Jun 2025 21:36:38 +0800 (CST) Received: from [10.45.154.5] (10.45.154.5) by frapeml500001.china.huawei.com (7.182.85.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 11 Jun 2025 15:36:33 +0200 Content-Type: multipart/alternative; boundary="------------kv6QgOzYWc3RONk5L1tcdnux" Message-ID: <984361aa-4ac3-4636-b4b8-d59635bd6cee@huawei.com> Date: Wed, 11 Jun 2025 15:36:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: "Aitken, Paul" , Mahesh Jethanandani , "draft-ietf-opsawg-ipfix-on-path-telemetry.all@ietf.org" References: <9DE24B5A-A1B9-4EE8-82F2-87F092AECC45@gmail.com> <960A9EEB-3DC8-446C-9649-9E883E1EFAB0@gmail.com> Content-Language: en-US From: Benoit Claise In-Reply-To: X-Originating-IP: [10.45.154.5] X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To frapeml500001.china.huawei.com (7.182.85.94) Message-ID-Hash: WJOH2EJBZ3YVRVSCRCIZHZGAICLSBSTD X-Message-ID-Hash: WJOH2EJBZ3YVRVSCRCIZHZGAICLSBSTD X-MailFrom: benoit.claise@huawei.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-opsawg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: opsawg-chairs , opsawg , "iana@iana.org" , michelle.cotton@icann.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOPSAWG=5DRe=3A_AD_review_of_draft-ietf-opsawg-ipfix-on-path-tel?= =?utf-8?q?emetry-17?= List-Id: OPSA Working Group Mail List Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --------------kv6QgOzYWc3RONk5L1tcdnux Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Paul, Thanks for the quick reaction. On 6/11/2025 3:06 PM, Aitken, Paul wrote: > Benoit, > > > I suggest removing section 4 as sections 6.2.x contain a superset of > the same information. Fine > > > For sections 3.1.1.2 - 3.1.2, the draft reads like it's filling a > form; it does not read well as a stand-alone document. If someone > would refer back to this in future, the information they need would be > spread across many sections of the document. It's actually just "filling a form".  A painful form, I agree, according to RFC 8911 with the guidelines in RFC 6390. I wonder who wrote those RFCs? ;-) Michele Cotton still hates me for the IPFIX and Performance Metric registries, and remind me at every single meeting ;-) The end goal is the IANA registrations, not this document, IMO. Hence my early discussion with IANA, to make sure they were fine. Unless the AD insists, I would be reluctant to make the change. I am afraid I would have duplicate much of the following content (all entries in the template), with just a few changes: 3.1.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Description . . . . . . . . . . . . . . . . . . . . . 8 3.1.3. Reference . . . . . . . . . . . . . . . . . . . . . . 8 3.1.4. Change Controller . . . . . . . . . . . . . . . . . . 9 3.1.5. Version of Registry Format . . . . . . . . . . . . . 9 3.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Reference Definition . . . . . . . . . . . . . . . . 9 3.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 9 3.3. Method of Measurement . . . . . . . . . . . . . . . . . . 10 3.3.1. Reference Methods . . . . . . . . . . . . . . . . . . 10 3.3.2. Packet Stream Generation . . . . . . . . . . . . . . 10 3.3.3. Traffic Filtering (Observation) Details . . . . . . . 10 3.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 10 3.3.5. Runtime Parameters and Data Format . . . . . . . . . 10 3.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4.2. Reference Definition . . . . . . . . . . . . . . . . 12 3.4.3. Administrative Items . . . . . . . . . . . . . . . . 14 3.4.4. Comments and Remarks . . . . . . . . . . . . . . . . 15 Not sure the draft is going to read any better, as the reader will have to back and forth if the entries are similar with min,max,mean,sum > > Citing "it was already done badly in another RFC" is a disappointing > excuse. > > > Otherwise, please apply the changes. Thanks and regards, Benoit > > > Thanks, > P. > > ------------------------------------------------------------------------ > *From:* Benoit Claise > *Sent:* Wednesday, June 11, 2025 13:45 > *To:* Aitken, Paul ; Mahesh Jethanandani > ; > draft-ietf-opsawg-ipfix-on-path-telemetry.all@ietf.org > > *Cc:* opsawg-chairs ; opsawg > ; iana@iana.org > *Subject:* [**EXTERNAL**] Re: AD review of > draft-ietf-opsawg-ipfix-on-path-telemetry-17 > > Hi Paul, > > Thomas addressed some feedback already in > https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-17&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-18.txt > [author-tools.ietf.org] > > > So I'll keep only the remaining items in this email thread. > > > > > 3.1.1.2 - 3.1.2 > > The document should define and request one metric at a time, > rather than providing bulk inputs. > > At least the Name, URI, Description, and Units should be grouped > per metric, because the current format provides no relation > between these values. > > > > We actually followed the RFC 8912 section 4.1.x. So we believe we're > safe on that front, as IANA already process a similar RFC. > Note: the RFC 8912 is the first and only RFC that populates > https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml > [iana.org] > . > Also I discussed this specific draft with IANA already. > > > > 3.4.2.5 Why are the PM metrics measured in seconds (with a > resolution of 1ns) while the IPFIX IEs are in Microseconds? > > There was no mention that they are incompatible, nor any > discussion of how to convert between them. > > Well spot. > OLD: > > > 3.4.2.5. [datatracker.ietf.org] > Metric > Units [datatracker.ietf.org] > > > * > > Mean > > * > > Min > > * > > Max > > * > > Sum > > The one-way delay of the IP Flow singleton is expressed in seconds. > > > > NEW: > > > 3.4.2.5. [datatracker.ietf.org] > Metric > Units [datatracker.ietf.org] > > > * > > Mean > > * > > Min > > * > > Max > > * > > Sum > > The one-way delay of the IP Flow singleton is expressed in > microseconds. > > > OLD (4 instances): > > > The time value of the result is expressed in units of seconds, as > a positive value of type decimal64 with fraction digits = 9 > (similar to the decimal64 in YANG, Section 9.3 [rfc-editor.org] >  of > [RFC6020 [rfc-editor.org] > ]) > with a resolution of 0.000000001 seconds (1.0 ns), and with > lossless conversion to/from the 64-bit NTP timestamp as per > Section 6 [rfc-editor.org] >  of > [RFC5905 [rfc-editor.org] > ]. > > NEW: > > The time value of the result is expressed in units of seconds, as > a positive value of type decimal64 with fraction digits = 9 > (similar to the decimal64 in YANG, Section 9.3 [rfc-editor.org] >  of > [RFC6020 [rfc-editor.org] > ]) > with a resolution of 0.000001 seconds (1.0 microsecond), and with > lossless conversion to/from the 64-bit NTP timestamp as per > Section 6 [rfc-editor.org] >  of > [RFC5905 [rfc-editor.org] > ]. > > > > Section 4. Is this section necessary? These definitions repeat > those in section 6, except that the line, "according to > OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_* in the > IANA Performance Metric Registry." is missing. > > We could remove it > > > > > 6.1 "with the four templates defined in Section 3." > > It was not clear that section 3 defined four templates. > > OLD: > > 3.  Performance Metrics   This section defines the new performance > metrics following the   template defined in Section 11 of [RFC8911]. > > NEW: > > 3.  Performance Metrics   This section defines four the new > performance metrics following the   template defined in Section 11 > of [RFC8911]. > > If fine with you, I'll apply the changes. > > Thanks and regards, Benoit > > > > > --------------kv6QgOzYWc3RONk5L1tcdnux Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi Paul,

Thanks for the quick reaction.


On 6/11/2025 3:06 PM, Aitken, Paul wrote:
Benoit,


I suggest removing section 4 as sections 6.2.x contain a superset of the same information.
Fine


For sections 3.1.1.2 - 3.1.2, the draft reads like it's filling a form; it does not read well as a stand-alone document. If someone would refer back to this in future, the information they need would be spread across many sections of the document.
It's actually just "filling a form".  A painful form, I agree, according to RFC 8911 with the guidelines in RFC 6390. I wonder who wrote those RFCs? ;-)
Michele Cotton still hates me for the IPFIX and Performance Metric registries, and remind me at every single meeting ;-)

The end goal is the IANA registrations, not this document, IMO. Hence my early discussion with IANA, to make sure they were fine.
Unless the AD insists, I would be reluctant to make the change. I am afraid I would have duplicate much of the following content (all entries in the template), with just a few changes:
    3.1.1.  Summary . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.2.  Description . . . . . . . . . . . . . . . . . . . . .   8
       3.1.3.  Reference . . . . . . . . . . . . . . . . . . . . . .   8
       3.1.4.  Change Controller . . . . . . . . . . . . . . . . . .   9
       3.1.5.  Version of Registry Format  . . . . . . . . . . . . .   9
     3.2.  Metric Definition . . . . . . . . . . . . . . . . . . . .   9
       3.2.1.  Reference Definition  . . . . . . . . . . . . . . . .   9
       3.2.2.  Fixed Parameters  . . . . . . . . . . . . . . . . . .   9
     3.3.  Method of Measurement . . . . . . . . . . . . . . . . . .  10
       3.3.1.  Reference Methods . . . . . . . . . . . . . . . . . .  10
       3.3.2.  Packet Stream Generation  . . . . . . . . . . . . . .  10
       3.3.3.  Traffic Filtering (Observation) Details . . . . . . .  10
       3.3.4.  Sampling Distribution . . . . . . . . . . . . . . . .  10
       3.3.5.  Runtime Parameters and Data Format  . . . . . . . . .  10
       3.3.6.  Roles . . . . . . . . . . . . . . . . . . . . . . . .  11
     3.4.  Output  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       3.4.1.  Type  . . . . . . . . . . . . . . . . . . . . . . . .  12
       3.4.2.  Reference Definition  . . . . . . . . . . . . . . . .  12
       3.4.3.  Administrative Items  . . . . . . . . . . . . . . . .  14
       3.4.4.  Comments and Remarks  . . . . . . . . . . . . . . . .  15
Not sure the draft is going to read any better, as the reader will have to back and forth if the entries are similar with min,max,mean,sum

Citing "it was already done badly in another RFC" is a disappointing excuse.


Otherwise, please apply the changes.
Thanks and regards, Benoit




Thanks,
P.

From: Benoit Claise <benoit.claise@huawei.com>
Sent: Wednesday, June 11, 2025 13:45
To: Aitken, Paul <paitken@ciena.com>; Mahesh Jethanandani <mjethanandani@gmail.com>; draft-ietf-opsawg-ipfix-on-path-telemetry.all@ietf.org <draft-ietf-opsawg-ipfix-on-path-telemetry.all@ietf.org>
Cc: opsawg-chairs <opsawg-chairs@ietf.org>; opsawg <opsawg@ietf.org>; iana@iana.org <iana@iana.org>
Subject: [**EXTERNAL**] Re: AD review of draft-ietf-opsawg-ipfix-on-path-telemetry-17




3.1.1.2 - 3.1.2

The document should define and request one metric at a time, rather than providing bulk inputs.

At least the Name, URI, Description, and Units should be grouped per metric, because the current format provides no relation between these values.



We actually followed the RFC 8912 section 4.1.x. So we believe we're safe on that front, as IANA already process a similar RFC.
Note: the RFC 8912 is the first and only RFC that populates https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml [iana.org]. Also I discussed this specific draft with IANA already.



3.4.2.5 Why are the PM metrics measured in seconds (with a resolution of 1ns) while the IPFIX IEs are in Microseconds?

There was no mention that they are incompatible, nor any discussion of how to convert between them.
Well spot.
OLD:
3.4.2.5. [datatracker.ietf.org]Metric Units [datatracker.ietf.org]

  • Mean

  • Min

  • Max

  • Sum

The one-way delay of the IP Flow singleton is expressed in seconds.


NEW:
3.4.2.5. [datatracker.ietf.org]Metric Units [datatracker.ietf.org]

  • Mean

  • Min

  • Max

  • Sum

The one-way delay of the IP Flow singleton is expressed in microseconds.

OLD (4 instances):

The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (similar to the decimal64 in YANG, Section 9.3 [rfc-editor.org] of [RFC6020 [rfc-editor.org]]) with a resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 [rfc-editor.org] of [RFC5905 [rfc-editor.org]].
NEW:
The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (similar to the decimal64 in YANG, Section 9.3 [rfc-editor.org] of [RFC6020 [rfc-editor.org]]) with a resolution of 0.000001 seconds (1.0 microsecond), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 [rfc-editor.org] of [RFC5905 [rfc-editor.org]].



Section 4. Is this section necessary? These definitions repeat those in section 6, except that the line, "according to OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_* in the IANA Performance Metric Registry." is missing.
We could remove it



6.1 "with the four templates defined in Section 3."

It was not clear that section 3 defined four templates.
OLD:
3.  Performance Metrics

   This section defines the new performance metrics following the
   template defined in Section 11 of [RFC8911].


NEW:


3.  Performance Metrics

   This section defines four the new performance metrics following the
   template defined in Section 11 of [RFC8911].
If fine with you, I'll apply the changes.

Thanks and regards, Benoit





--------------kv6QgOzYWc3RONk5L1tcdnux--