Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Marco.Tollini1]

Dear OPSAWG,

I have reviewed this draft and support it.

On-path delay is becoming more relevant, and having it exposed through a 
well-standardized and diffused protocol as IPFIX is the right approach.

Best regards,
Marco



From: Tianran Zhou 
Date: Thursday, 22 December 2022 at 03:25
To: opsawg@ietf.org 
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org 

Subject: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01
Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Thomas.Graf]

https://mailarchive.ietf.org/arch/browse/opsawg/?q=draft-tgraf-opsawg-ipfix-on-path-telemetry-01


Danke! Angekommen 


Sorry für den Stress.


Lg Thomas

On 13 Jan 2023, at 07:16, Buchs Yannick, INI-NET-VNC-HCS 
 wrote:


Dear OPSAWG,

I strongly support the adoption of 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01. It addresses an important topic 
which is export of on-path delay metrics through IPFIX, which is a mature and 
widely used standard.

Best Regards

Yannick


From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Thursday, December 22, 2022 3:26 AM
To: opsawg@ietf.org
Cc: 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)




smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Yannick.Buchs]

Dear OPSAWG,

I strongly support the adoption of 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01. It addresses an important topic 
which is export of on-path delay metrics through IPFIX, which is a mature and 
widely used standard.

Best Regards

Yannick


From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Thursday, December 22, 2022 3:26 AM
To: opsawg@ietf.org
Cc: 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Paolo Lucente]

Hi,

I support adoption of draft-tgraf-opsawg-ipfix-on-path-telemetry-01 and 
intend to validate and implement the data collection in pmacct.


Paolo


On 21/12/22 23:25, Tianran Zhou wrote:

Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.


https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/ 


Please reply your supports or objections.

We would really appreciate your comments.

Since there are holidays, this call will last for 3 weeks, and end on 
Thursday, Jan 12, 2023.


Cheers,

Tianran (as co-chairs)


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[MORTON JR., AL]

Hi OPSAWG,

I reviewed this draft on the IPPM-List a few months back, and I support its 
adoption by the opsawg.

Al


On Wed, Dec 21, 2022 at 6:26 PM Tianran Zhou 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Alex Huang Feng]

Dear OPSAWG,

Of course, as a co-author of the draft, I support the WG adoption.
I do think we need this new information elements in IPFIX.

I also would like to inform that I am working on an implementation in the 
open-source project Fd.io  VPP of this draft using Trace-type 
IOAM as on-path telemetry protocol.
The results will be shared during the next IETF Hackathon.

Regards,
Alex

> On 22 Dec 2022, at 03:25, Tianran Zhou 
>  wrote:
> 
> Hi WG,
>  
> This mail starts a WG Adoption Call for 
> draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
> https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/ 
> 
>  
> Please reply your supports or objections.
> We would really appreciate your comments.
>  
> Since there are holidays, this call will last for 3 weeks, and end on 
> Thursday, Jan 12, 2023.
>  
> Cheers,
> Tianran (as co-chairs)
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org 
> https://www.ietf.org/mailman/listinfo/opsawg 
> 
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Severin Dellsperger]

Hi all,

I support this WG Adoption Call.
I'm convinced it helps us to do an honorable step in the future of modern 
network monitoring and analytics.

Best Regards,
Severin Dellsperger

From: OPSAWG  on behalf of Tianran Zhou 

Sent: Thursday, December 22, 2022 3:25 AM
To: opsawg@ietf.org 
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org 

Subject: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01


Hi WG,



This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.

https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/



Please reply your supports or objections.

We would really appreciate your comments.



Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.



Cheers,

Tianran (as co-chairs)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Benoit Claise]

Dear all,

I support WG adoption.  Obviously, since I am a co-author you may say.

Sure, but let me stress one important aspect in this work. This would be 
the first draft that would specify an IPFIX IE that would also be a 
performance metric.


When we initiated what became RFC 8911 (registry for performance 
metrics) a couple of years ago, this was exactly the intent: not only 
have active metrics in the registry but also passive and even hybrid 
measurement method (https://www.rfc-editor.org/rfc/rfc7799#section-3.8) 
metrics.


Basically this draft links, for the first time, two IANA registries (the 
IPFIX and the performance metrics), specifying a metric in both.
Note that the authors are in discussion with performance metrics expert 
(from the performance metric directorate) to make this right.


Regards, Benoit

On 12/22/2022 3:25 AM, Tianran Zhou wrote:


Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.


https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/

Please reply your supports or objections.

We would really appreciate your comments.

Since there are holidays, this call will last for 3 weeks, and end on 
Thursday, Jan 12, 2023.


Cheers,

Tianran (as co-chairs)


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Jean Quilbeuf]

Hi Thomas and Benoit,
The changes are perfectly addressing my comments, thanks.

Best,
Jean

From: Benoit Claise
Sent: Thursday 5 January 2023 13:19
To: thomas.g...@swisscom.com; Jean Quilbeuf ; 
zhoutianran=40huawei@dmarc.ietf.org; opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: Re: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear all,
On 1/5/2023 9:48 AM, thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 
wrote:
Dear Jean,

Thanks a lot for the comprehensive review and comments. They all make perfectly 
sense.

I merged them into the -02 version 
https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt

And here the diff: 
https://author-tools.ietf.org/iddiff?url1=https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt=https://github.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/blob/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt

Correct URL is actually (raw instead of blog):

https://author-tools.ietf.org/iddiff?url1=https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt=https://github.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/raw/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt



Regards, Benoit

Please let me know if I addressed all your points. I will submit -02 once the 
ongoing adoption call is finished and the document name changed.

Best wishes
Thomas

From: Jean Quilbeuf <mailto:jean.quilb...@huawei.com>
Sent: Wednesday, January 4, 2023 6:11 PM
To: Tianran Zhou 
<mailto:zhoutianran=40huawei@dmarc.ietf.org>;
 opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc: 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>
Subject: RE: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear All,
I support the adoption of this draft.

I have a few very minor comments below.

Best,
Jean


Section 1, paragraph 4:

OLD
   "Since these IPFIX IEs are performance metrics [RFC8911], they must be
registered as registered performance metrics [RFC8911] in the "IANA ..."

NEW
   "Since these IPFIX IEs are performance metrics [RFC8911], they must be
registered in the "IANA ..."

Section 3.4.2

OLD
  "For each , Singleton one of the following [..] applies "

NEW
  "For each  Singleton, one of the following [..] applies "

Section 3.4.2.3. (Max)

I would add the scope of n from RFC6049 after the formula
  "where all packets n = 1 through N have finite singleton delays."


Section 6.2.X

  "OctedDelta" is not defined, do you mean deltaCounter as in 
https://www.rfc-editor.org/rfc/rfc7012#section-3.2.3

Section 7.2
   Computing the average from PathDelaySumDeltaMicroseconds seems unecessary as 
PathDelayMeanDeltaMicroseconds already exports it. Maybe state that the 
advantage of pushing that computation to the collector is to avoid doing too 
much computation in the router?

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday 22 December 2022 02:26
To: opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc: 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>
Subject: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-on-path-telemetry%2F=05%7C01%7CThomas.Graf%40swisscom.com%7Caa99015a1e2c4866f54808daee76aa36%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638084490672856810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=v2E88K1AbhDgQXruPPmv6gWCI8cQ1lhaBkB2QFI2MqA%3D=0>


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Thomas.Graf]

Dear Tianran,

ZTR> I think I understand how you can achieve. You can add to bits in 
"extension-flags" in rfc9326, as the knob to control the existence of 
timestamp, just like the flow id and sequence. Right?

Correct. That works as well. Thanks for pointing out.

Best wishes
Thomas

From: Tianran Zhou 
Sent: Friday, January 6, 2023 2:36 AM
To: Graf Thomas, INI-NET-VNC-HCS ; 
gregimir...@gmail.com
Cc: opsawg@ietf.org; draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org; 
i...@ietf.org
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi Thomas,

Thanks for your reply. Please see inline.

Cheers,
Tianran

From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 
[mailto:thomas.g...@swisscom.com]
Sent: Thursday, January 5, 2023 9:22 PM
To: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
gregimir...@gmail.com<mailto:gregimir...@gmail.com>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear Tianran,

Thanks a lot for your feedback. I understood that with 
draft-zhou-ippm-enhanced-alternate-marking we already have a document which 
intends to extend alternat path marking with timestamping. Very well.

Regarding IOAM-DEX. I was refereeing to the Section 3.2 of RFC 9326 
(https://datatracker.ietf.org/doc/html/rfc9326#section-3.2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9326%23section-3.2=05%7C01%7CThomas.Graf%40swisscom.com%7Cfc9bd9bed61346a4475108daef86606f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638085657662132015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=7FMnMBi77iXER6gABu2lK2v2pWpTkvDmlrB0hoTOB6U%3D=0>)
 where "Flags" and "Extension-Flags" are being described for IOAM Trace 
Option-Types. As you pointed out, we would need not only to add similar to 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.1<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9197%23section-4.4.1=05%7C01%7CThomas.Graf%40swisscom.com%7Cfc9bd9bed61346a4475108daef86606f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638085657662132015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=w5jZwsJibosoVIU4abheHzm1TJZ2H9qsxSpHd5bYGIQ%3D=0>
 the bit 2 and 3 in the "Flags" field but also need to support similar to 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2.3<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9197%23section-4.4.2.3=05%7C01%7CThomas.Graf%40swisscom.com%7Cfc9bd9bed61346a4475108daef86606f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638085657662132015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=2fpDQ%2FmRc7ycvMqCSuk1lbKyb5mFAY4%2BOmAAQBEuxxQ%3D=0>
 and 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2.4<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9197%23section-4.4.2.4=05%7C01%7CThomas.Graf%40swisscom.com%7Cfc9bd9bed61346a4475108daef86606f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638085657662132015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lppygY5Rp%2FbxA%2FJnqoELar6KE%2Fr0P5WlISsHvmleLt0%3D=0>
 the possibility to add the timestamps in the "Extension-Flags" field. This was 
he point you wanted to highlight correct?


ZTR> I think I understand how you can achieve. You can add to bits in 
"extension-flags" in rfc9326, as the knob to control the existence of 
timestamp, just like the flow id and sequence. Right?

Best wishes
Thomas

From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Wednesday, December 28, 2022 2:04 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 
mailto:thomas.g...@swisscom.com>>; 
gregimir...@gmail.com<mailto:gregimir...@gmail.com>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi Thomas,

Some comments to your reply.

> Alternate Marking does not describe a method were the timestamp is within the 
> packet

You can refer to the following draft, where you can get the timestamp you need.
https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/<https://eur03.safelinks.protection.outloo

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Tianran Zhou]

Hi Thomas,

Thanks for your reply. Please see inline.

Cheers,
Tianran

From: thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com]
Sent: Thursday, January 5, 2023 9:22 PM
To: Tianran Zhou ; gregimir...@gmail.com
Cc: opsawg@ietf.org; draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org; 
i...@ietf.org
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear Tianran,

Thanks a lot for your feedback. I understood that with 
draft-zhou-ippm-enhanced-alternate-marking we already have a document which 
intends to extend alternat path marking with timestamping. Very well.

Regarding IOAM-DEX. I was refereeing to the Section 3.2 of RFC 9326 
(https://datatracker.ietf.org/doc/html/rfc9326#section-3.2) where "Flags" and 
"Extension-Flags" are being described for IOAM Trace Option-Types. As you 
pointed out, we would need not only to add similar to 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.1 the bit 2 and 3 in 
the "Flags" field but also need to support similar to 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2.3 and 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2.4 the possibility 
to add the timestamps in the "Extension-Flags" field. This was he point you 
wanted to highlight correct?


ZTR> I think I understand how you can achieve. You can add to bits in 
"extension-flags" in rfc9326, as the knob to control the existence of 
timestamp, just like the flow id and sequence. Right?

Best wishes
Thomas

From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Wednesday, December 28, 2022 2:04 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 
mailto:thomas.g...@swisscom.com>>; 
gregimir...@gmail.com<mailto:gregimir...@gmail.com>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi Thomas,

Some comments to your reply.

> Alternate Marking does not describe a method were the timestamp is within the 
> packet

You can refer to the following draft, where you can get the timestamp you need.
https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zhou-ippm-enhanced-alternate-marking%2F=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=sk2JFwgWOE1HuNrUR1f4DDtFq%2Feefsf55f%2B1wQ%2FZvsA%3D=0>

> In case of postcard mode that would have been the Direct Exporting (DEX) 
> IOAM-Option-Type 
> (https://datatracker.ietf.org/doc/html/rfc9326#section-3<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9326%23section-3=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=HKGG3eZAfuBQo690OK9C9%2BeNc%2B0bQnq0YmGow3RHX3M%3D=0>)
>  if bits 2 and 3 in flags field for the timestamps would be set able.

I do not think you can get the timestamp by setting Bit 2 and 3 in IOAM-DEX.

Cheers,
Tianran

From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 
[mailto:thomas.g...@swisscom.com]
Sent: Tuesday, December 27, 2022 5:13 PM
To: gregimir...@gmail.com<mailto:gregimir...@gmail.com>; Tianran Zhou 
mailto:zhoutian...@huawei.com>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear Greg,

Thanks a lot for the review and feedback.
?  as I understand it, the scope of this document is on reporting delay-related 
metrics based on the use of IOAM specifically. Is that correct understanding? 
If it is, reflecting that in the title might be helpful as other op-path 
telemetry methods, for example, Alternate Marking, might use a different set of 
IEs.
The document focuses solely on the IPFIX export of the on-path telemetry 
measured delay. However these delay measurements are on-path telemetry protocol 
agnostic and can be applied to IOAM, iFIT and path tracing as described in 
section 1 
(https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-1<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-op

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Thomas.Graf]

Dear Tianran,

Thanks a lot for your feedback. I understood that with 
draft-zhou-ippm-enhanced-alternate-marking we already have a document which 
intends to extend alternat path marking with timestamping. Very well.

Regarding IOAM-DEX. I was refereeing to the Section 3.2 of RFC 9326 
(https://datatracker.ietf.org/doc/html/rfc9326#section-3.2) where "Flags" and 
"Extension-Flags" are being described for IOAM Trace Option-Types. As you 
pointed out, we would need not only to add similar to 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.1 the bit 2 and 3 in 
the "Flags" field but also need to support similar to 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2.3 and 
https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2.4 the possibility 
to add the timestamps in the "Extension-Flags" field. This was he point you 
wanted to highlight correct?

Best wishes
Thomas

From: Tianran Zhou 
Sent: Wednesday, December 28, 2022 2:04 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; 
gregimir...@gmail.com
Cc: opsawg@ietf.org; draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org; 
i...@ietf.org
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi Thomas,

Some comments to your reply.

> Alternate Marking does not describe a method were the timestamp is within the 
> packet

You can refer to the following draft, where you can get the timestamp you need.
https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zhou-ippm-enhanced-alternate-marking%2F=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=sk2JFwgWOE1HuNrUR1f4DDtFq%2Feefsf55f%2B1wQ%2FZvsA%3D=0>

> In case of postcard mode that would have been the Direct Exporting (DEX) 
> IOAM-Option-Type 
> (https://datatracker.ietf.org/doc/html/rfc9326#section-3<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9326%23section-3=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=HKGG3eZAfuBQo690OK9C9%2BeNc%2B0bQnq0YmGow3RHX3M%3D=0>)
>  if bits 2 and 3 in flags field for the timestamps would be set able.

I do not think you can get the timestamp by setting Bit 2 and 3 in IOAM-DEX.

Cheers,
Tianran

From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 
[mailto:thomas.g...@swisscom.com]
Sent: Tuesday, December 27, 2022 5:13 PM
To: gregimir...@gmail.com<mailto:gregimir...@gmail.com>; Tianran Zhou 
mailto:zhoutian...@huawei.com>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>;
 i...@ietf.org<mailto:i...@ietf.org>
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear Greg,

Thanks a lot for the review and feedback.

  *   as I understand it, the scope of this document is on reporting 
delay-related metrics based on the use of IOAM specifically. Is that correct 
understanding? If it is, reflecting that in the title might be helpful as other 
op-path telemetry methods, for example, Alternate Marking, might use a 
different set of IEs.
The document focuses solely on the IPFIX export of the on-path telemetry 
measured delay. However these delay measurements are on-path telemetry protocol 
agnostic and can be applied to IOAM, iFIT and path tracing as described in 
section 1 
(https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-1<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-on-path-telemetry-01%23section-1=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=m1XNm7XibW8ScwEphGblLW2C6oJe3vHXV%2FPuvDWnPZo%3D=0>).
 To my knowledge, and please correct me if I am wrong, Alternate Marking does 
not describe a method were the timestamp is within the packet. If you feel that 
section 1 could be updated to make the scope more clearer, your feedback would 
be much appreciated.

  *   I appreciate you using a picture (Figure 1) to illustrate the use case 
for IEs. It might be helpful for an operator to add more information about how 
IOAM is expected to be used. For example:

 *   IOAM Option Types tha

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Benoit Claise]

Dear all,

On 1/5/2023 9:48 AM, thomas.g...@swisscom.com wrote:


Dear Jean,

Thanks a lot for the comprehensive review and comments. They all make 
perfectly sense.


I merged them into the -02 version 
https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt


And here the diff: 
https://author-tools.ietf.org/iddiff?url1=https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt=https://github.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/blob/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt 
<https://author-tools.ietf.org/iddiff?url1=https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt=https://github.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/blob/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt>




Correct URL is actually (raw instead of blog):

https://author-tools.ietf.org/iddiff?url1=https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt=https://github.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/raw/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt

Regards, Benoit

Please let me know if I addressed all your points. I will submit -02 
once the ongoing adoption call is finished and the document name changed.


Best wishes

Thomas

*From:*Jean Quilbeuf 
*Sent:* Wednesday, January 4, 2023 6:11 PM
*To:* Tianran Zhou ; 
opsawg@ietf.org

*Cc:* draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
*Subject:* RE: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01


Dear All,

I support the adoption of this draft.

I have a few very minor comments below.

Best,

Jean

Section 1, paragraph 4:

OLD

"Since these IPFIX IEs are performance metrics [RFC8911], they must be

registered as registered performance metrics [RFC8911] in the "IANA ..."

NEW

"Since these IPFIX IEs are performance metrics [RFC8911], they must be

registered in the "IANA ..."

Section 3.4.2

OLD

  "For each , Singleton one of the following [..] applies "

NEW

  "For each  Singleton, one of the following [..] applies "

Section 3.4.2.3. (Max)

I would add the scope of n from RFC6049 after the formula

  "where all packets n = 1 through N have finite singleton delays."

Section 6.2.X

"OctedDelta" is not defined, do you mean deltaCounter as in 
https://www.rfc-editor.org/rfc/rfc7012#section-3.2.3


Section 7.2

Computing the average from PathDelaySumDeltaMicroseconds seems 
unecessary as PathDelayMeanDeltaMicroseconds already exports it. Maybe 
state that the advantage of pushing that computation to the collector 
is to avoid doing too much computation in the router?


*From:*OPSAWG [mailto:opsawg-boun...@ietf.org 
<mailto:opsawg-boun...@ietf.org>] *On Behalf Of *Tianran Zhou

*Sent:* Thursday 22 December 2022 02:26
*To:* opsawg@ietf.org
*Cc:* draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
*Subject:* [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01


Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.


https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/ 
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-on-path-telemetry%2F=05%7C01%7CThomas.Graf%40swisscom.com%7Caa99015a1e2c4866f54808daee76aa36%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638084490672856810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=v2E88K1AbhDgQXruPPmv6gWCI8cQ1lhaBkB2QFI2MqA%3D=0>


Please reply your supports or objections.

We would really appreciate your comments.

Since there are holidays, this call will last for 3 weeks, and end on 
Thursday, Jan 12, 2023.


Cheers,

Tianran (as co-chairs)

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Thomas.Graf]

Dear Jean,

Thanks a lot for the comprehensive review and comments. They all make perfectly 
sense.

I merged them into the -02 version 
https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt

And here the diff: 
https://author-tools.ietf.org/iddiff?url1=https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt=https://github.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/blob/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt

Please let me know if I addressed all your points. I will submit -02 once the 
ongoing adoption call is finished and the document name changed.

Best wishes
Thomas

From: Jean Quilbeuf 
Sent: Wednesday, January 4, 2023 6:11 PM
To: Tianran Zhou ; opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: RE: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear All,
I support the adoption of this draft.

I have a few very minor comments below.

Best,
Jean


Section 1, paragraph 4:

OLD
   "Since these IPFIX IEs are performance metrics [RFC8911], they must be
registered as registered performance metrics [RFC8911] in the "IANA ..."

NEW
   "Since these IPFIX IEs are performance metrics [RFC8911], they must be
registered in the "IANA ..."

Section 3.4.2

OLD
  "For each , Singleton one of the following [..] applies "

NEW
  "For each  Singleton, one of the following [..] applies "

Section 3.4.2.3. (Max)

I would add the scope of n from RFC6049 after the formula
  "where all packets n = 1 through N have finite singleton delays."


Section 6.2.X

  "OctedDelta" is not defined, do you mean deltaCounter as in 
https://www.rfc-editor.org/rfc/rfc7012#section-3.2.3

Section 7.2
   Computing the average from PathDelaySumDeltaMicroseconds seems unecessary as 
PathDelayMeanDeltaMicroseconds already exports it. Maybe state that the 
advantage of pushing that computation to the collector is to avoid doing too 
much computation in the router?

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday 22 December 2022 02:26
To: opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc: 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>
Subject: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-on-path-telemetry%2F=05%7C01%7CThomas.Graf%40swisscom.com%7Caa99015a1e2c4866f54808daee76aa36%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638084490672856810%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=v2E88K1AbhDgQXruPPmv6gWCI8cQ1lhaBkB2QFI2MqA%3D=0>


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Jean Quilbeuf]

Dear All,
I support the adoption of this draft.

I have a few very minor comments below.

Best,
Jean


Section 1, paragraph 4:

OLD
   "Since these IPFIX IEs are performance metrics [RFC8911], they must be
registered as registered performance metrics [RFC8911] in the "IANA ..."

NEW
   "Since these IPFIX IEs are performance metrics [RFC8911], they must be
registered in the "IANA ..."

Section 3.4.2

OLD
  "For each , Singleton one of the following [..] applies "

NEW
  "For each  Singleton, one of the following [..] applies "

Section 3.4.2.3. (Max)

I would add the scope of n from RFC6049 after the formula
  "where all packets n = 1 through N have finite singleton delays."


Section 6.2.X

  "OctedDelta" is not defined, do you mean deltaCounter as in 
https://www.rfc-editor.org/rfc/rfc7012#section-3.2.3

Section 7.2
   Computing the average from PathDelaySumDeltaMicroseconds seems unecessary as 
PathDelayMeanDeltaMicroseconds already exports it. Maybe state that the 
advantage of pushing that computation to the collector is to avoid doing too 
much computation in the router?

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday 22 December 2022 02:26
To: opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Thomas.Graf]

Dear Zhenqiang,

Thanks a lot for your feedback.

I presume with gRPC you are referring to YANG push (RFC 8639, RFC 8641, 
draft-ietf-netconf-udp-notif, draft-ietf-netconf-https-notif). gNMI (gRPC is 
the transport of gNMI) has been proposed (draft-openconfig-rtgwg-gnmi-spec) in 
2018 but not standardized within IETF as a transport protocol for YANG push. It 
did not find enough traction. A good overview about the state of the union 
about YANG push in the industry is a presentation I gave at the IEPG, slide 
3-6, 
http://www.iepg.org/2022-11-06-ietf115/slides-115-iepg-sessa-network-operator-challenges-in-network-telemetry-data-mesh-integration-thomas-graf-00.pdf.

RFC 9232 gives a good overview about Network Telemetry. In section 3.1.3 
(https://datatracker.ietf.org/doc/html/rfc9232#section-3.1.3) is a summary of 
the protocols for forwarding plane data collection. As you pointed out, it 
makes sense to use one common Network Telemetry protocol. However today we have 
3, IPFIX for data plane, BMP for BGP routing control-plane and YANG push for 
management-plane. These 3 protocols have different unique mandatory 
characteristics. IPFIX allows data reduction with sampling (RFC5476) an 
aggregation (RFC7015). While BMP allows to mirror BGP PDU's (lightweight) and 
add device dimensions such as peering, RIB and route-policy (context). And YANG 
push allows through its sophisticated data modelling to have configurational 
and operational metrics within a single data model.

In OPSAWG presentation of IETF 115 
(https://datatracker.ietf.org/meeting/115/materials/slides-115-opsawg-export-of-on-path-delay-in-ipfix-00.pdf)
 I described in slide 2 and 3 the benefit of adding the delay measurements to 
IPFIX. Having one single protocol for data-plane data collection. The ability 
to perform data correlation and aggregation with an existing proven IPFIX 
protocol. Does that resonate with you?

The use cases are described in section 5 of the draft 
(https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-5).
 Able to see for a given egress interface, BGP next-hop or SRv6 traffic 
engineered path or active segment how much delay at which node we accumulate. 
With YANG push this would be rather difficult and expensive to achieve. This 
was also confirmed by large network operators in their first on-path delay 
measurement deployments.

Best wishes
Thomas

From: OPSAWG  On Behalf Of li_zhenqi...@hotmail.com
Sent: Tuesday, January 3, 2023 4:41 PM
To: Tianran Zhou ; opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: Re: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hello all,

Why not use the grpc to export all the iOAM metrics measured by the device? 
Only one way delay is expoeted by IPFIX in this doc, how about others? I prefer 
using  one protocol to export all the iOAM metrics if possible because this is 
convinent for both the device and the collector.


Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

From: Tianran Zhou<mailto:zhoutianran=40huawei@dmarc.ietf.org>
Date: 2022-12-22 10:25
To: opsawg@ietf.org<mailto:opsawg@ietf.org>
CC: 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>
Subject: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01
Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-on-path-telemetry%2F=05%7C01%7CThomas.Graf%40swisscom.com%7C86371878d3fb48b149e708daeda0ac7d%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638083571584639621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=8Tv9HsW8fqnc9h4%2B%2BWXYsirDdhNGj7DOjcdgtDFiI64%3D=0>


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[li_zhenqi...@hotmail.com]

Hello all,

Why not use the grpc to export all the iOAM metrics measured by the device? 
Only one way delay is expoeted by IPFIX in this doc, how about others? I prefer 
using  one protocol to export all the iOAM metrics if possible because this is 
convinent for both the device and the collector.



Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com
 
From: Tianran Zhou
Date: 2022-12-22 10:25
To: opsawg@ietf.org
CC: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01
Hi WG,
 
This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/
 
Please reply your supports or objections.
We would really appreciate your comments.
 
Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.
 
Cheers,
Tianran (as co-chairs)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Chongfeng Xie]

Hi WG chairs and all,

I have read this draft and support its adption by opsawg WG.

On-path delay is an important concern to operators. The  exposion of the 
On-Path Telemetry measured delay on the IOAM nodes in IPFIX is very useful for 
the network opeartion and guaratee the experience of customers. The whole 
document has been well written and the problems has been clearly described, 
thanks for the authors' work.

Best regards

Chongfeng

 
From: Tianran Zhou  
Sent: Thursday, December 22, 2022 3:26 AM
To: opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01
 
Hi WG,
 
This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/
 
Please reply your supports or objections.
We would really appreciate your comments.
 
Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.
 
Cheers,
Tianran (as co-chairs)
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Tianran Zhou]

Hi Thomas,

Some comments to your reply.

> Alternate Marking does not describe a method were the timestamp is within the 
> packet

You can refer to the following draft, where you can get the timestamp you need.
https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/

> In case of postcard mode that would have been the Direct Exporting (DEX) 
> IOAM-Option-Type (https://datatracker.ietf.org/doc/html/rfc9326#section-3) if 
> bits 2 and 3 in flags field for the timestamps would be set able.

I do not think you can get the timestamp by setting Bit 2 and 3 in IOAM-DEX.

Cheers,
Tianran

From: thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com]
Sent: Tuesday, December 27, 2022 5:13 PM
To: gregimir...@gmail.com; Tianran Zhou 
Cc: opsawg@ietf.org; draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org; 
i...@ietf.org
Subject: RE: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear Greg,

Thanks a lot for the review and feedback.
?  as I understand it, the scope of this document is on reporting delay-related 
metrics based on the use of IOAM specifically. Is that correct understanding? 
If it is, reflecting that in the title might be helpful as other op-path 
telemetry methods, for example, Alternate Marking, might use a different set of 
IEs.
The document focuses solely on the IPFIX export of the on-path telemetry 
measured delay. However these delay measurements are on-path telemetry protocol 
agnostic and can be applied to IOAM, iFIT and path tracing as described in 
section 1 
(https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-1).
 To my knowledge, and please correct me if I am wrong, Alternate Marking does 
not describe a method were the timestamp is within the packet. If you feel that 
section 1 could be updated to make the scope more clearer, your feedback would 
be much appreciated.
?  I appreciate you using a picture (Figure 1) to illustrate the use case for 
IEs. It might be helpful for an operator to add more information about how IOAM 
is expected to be used. For example:

 *   IOAM Option Types that are applicable to the defined IEs;
 *   any special considerations using different IOAM Trace Option-Types;
 *   mandatory IOAM Trace-Type.
Very valid point. I think this would fit best in the operational considerations 
section. We have section 7.3 
(https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-7.3)
 which focuses solely on timestamps at the moment. I agree that section 7 could 
be expanded to describe within IOAM to which IOAM Option Types the document 
applies.

In case of passport mode that would be the IOAM Edge-to-Edge Option-Type 
(https://datatracker.ietf.org/doc/html/rfc9197#section-4.6) with bits 2 and 3 
in flags fields for the timestamps set. Export would be only on the IOAM 
decapsulation node.

In case of postcard mode that would have been the Direct Exporting (DEX) 
IOAM-Option-Type (https://datatracker.ietf.org/doc/html/rfc9326#section-3) if 
bits 2 and 3 in flags field for the timestamps would be set able. We intend to 
prepare a separate IOAM DEX document describing this case. Export would be on 
the IOAM transit and decapsulation nodes.

Since IOAM Trace Option-Types 
(https://datatracker.ietf.org/doc/html/rfc9197#section-4.4) also supports bits 
2 and 3 in flags field for the timestamps, this document could be partially 
applied there as well. However all the fields described in section 4.2 of RFC 
9197 (https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2) are IOAM 
specific and not covered in draft-tgraf-opsawg-ipfix-on-path-telemetry. We 
believe that draft-spiegel-ippm-ioam-rawexport 
(https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-ioam-rawexport) is 
the appropriate document to cover these IPFIX entities. Export would be only on 
the IOAM decapsulation node.

I will prepare and update for after the adoption call and address this point as 
described. Feedback and comments welcome.

Best wishes
Thomas

From: Greg Mirsky mailto:gregimir...@gmail.com>>
Sent: Monday, December 26, 2022 9:22 PM
To: Tianran Zhou 
mailto:zhoutianran=40huawei@dmarc.ietf.org>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org<mailto:draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org>
Subject: Re: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear All,
I read the latest version of the draft. I appreciate the work authors put into 
making the document clear and easy to read. Proposed IEs are essential for 
further developing an out-of-band collection of telemetry information. I 
strongly support the adoption of this work by the OPSAWG.
I have two notes to discuss (clearly non-blocking):

  *   as I understand it, the scope of this document is on reporting 
delay-related metrics based on the use of IOAM speci

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Thomas.Graf]

Dear Greg,

Thanks a lot for the review and feedback.

  *   as I understand it, the scope of this document is on reporting 
delay-related metrics based on the use of IOAM specifically. Is that correct 
understanding? If it is, reflecting that in the title might be helpful as other 
op-path telemetry methods, for example, Alternate Marking, might use a 
different set of IEs.
The document focuses solely on the IPFIX export of the on-path telemetry 
measured delay. However these delay measurements are on-path telemetry protocol 
agnostic and can be applied to IOAM, iFIT and path tracing as described in 
section 1 
(https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-1).
 To my knowledge, and please correct me if I am wrong, Alternate Marking does 
not describe a method were the timestamp is within the packet. If you feel that 
section 1 could be updated to make the scope more clearer, your feedback would 
be much appreciated.

  *   I appreciate you using a picture (Figure 1) to illustrate the use case 
for IEs. It might be helpful for an operator to add more information about how 
IOAM is expected to be used. For example:

 *   IOAM Option Types that are applicable to the defined IEs;
 *   any special considerations using different IOAM Trace Option-Types;
 *   mandatory IOAM Trace-Type.
Very valid point. I think this would fit best in the operational considerations 
section. We have section 7.3 
(https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-7.3)
 which focuses solely on timestamps at the moment. I agree that section 7 could 
be expanded to describe within IOAM to which IOAM Option Types the document 
applies.

In case of passport mode that would be the IOAM Edge-to-Edge Option-Type 
(https://datatracker.ietf.org/doc/html/rfc9197#section-4.6) with bits 2 and 3 
in flags fields for the timestamps set. Export would be only on the IOAM 
decapsulation node.

In case of postcard mode that would have been the Direct Exporting (DEX) 
IOAM-Option-Type (https://datatracker.ietf.org/doc/html/rfc9326#section-3) if 
bits 2 and 3 in flags field for the timestamps would be set able. We intend to 
prepare a separate IOAM DEX document describing this case. Export would be on 
the IOAM transit and decapsulation nodes.

Since IOAM Trace Option-Types 
(https://datatracker.ietf.org/doc/html/rfc9197#section-4.4) also supports bits 
2 and 3 in flags field for the timestamps, this document could be partially 
applied there as well. However all the fields described in section 4.2 of RFC 
9197 (https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2) are IOAM 
specific and not covered in draft-tgraf-opsawg-ipfix-on-path-telemetry. We 
believe that draft-spiegel-ippm-ioam-rawexport 
(https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-ioam-rawexport) is 
the appropriate document to cover these IPFIX entities. Export would be only on 
the IOAM decapsulation node.

I will prepare and update for after the adoption call and address this point as 
described. Feedback and comments welcome.

Best wishes
Thomas

From: Greg Mirsky 
Sent: Monday, December 26, 2022 9:22 PM
To: Tianran Zhou 
Cc: opsawg@ietf.org; draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: Re: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear All,
I read the latest version of the draft. I appreciate the work authors put into 
making the document clear and easy to read. Proposed IEs are essential for 
further developing an out-of-band collection of telemetry information. I 
strongly support the adoption of this work by the OPSAWG.
I have two notes to discuss (clearly non-blocking):

  *   as I understand it, the scope of this document is on reporting 
delay-related metrics based on the use of IOAM specifically. Is that correct 
understanding? If it is, reflecting that in the title might be helpful as other 
op-path telemetry methods, for example, Alternate Marking, might use a 
different set of IEs.
  *   I appreciate you using a picture (Figure 1) to illustrate the use case 
for IEs. It might be helpful for an operator to add more information about how 
IOAM is expected to be used. For example:

 *   IOAM Option Types that are applicable to the defined IEs;
 *   any special considerations using different IOAM Trace Option-Types;
 *   mandatory IOAM Trace-Type.
Regards,
Greg

On Wed, Dec 21, 2022 at 6:26 PM Tianran Zhou 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-on-path-telemetry%2F=05%7C01%7CThomas.Graf%40swisscom.com%7Ce1df80c7c57045d56e3f08dae77edb90%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638076829

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Greg Mirsky]

Dear All,
I read the latest version of the draft. I appreciate the work authors put
into making the document clear and easy to read. Proposed IEs are essential
for further developing an out-of-band collection of telemetry information.
I strongly support the adoption of this work by the OPSAWG.
I have two notes to discuss (clearly non-blocking):

   - as I understand it, the scope of this document is on reporting
   delay-related metrics based on the use of IOAM specifically. Is that
   correct understanding? If it is, reflecting that in the title might be
   helpful as other op-path telemetry methods, for example, Alternate Marking,
   might use a different set of IEs.
   - I appreciate you using a picture (Figure 1) to illustrate the use case
   for IEs. It might be helpful for an operator to add more information about
   how IOAM is expected to be used. For example:
  - IOAM Option Types that are applicable to the defined IEs;
  - any special considerations using different IOAM Trace Option-Types;
  - mandatory IOAM Trace-Type.

Regards,
Greg

On Wed, Dec 21, 2022 at 6:26 PM Tianran Zhou  wrote:

> Hi WG,
>
>
>
> This mail starts a WG Adoption Call for
> draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
>
>
> https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/
>
>
>
> Please reply your supports or objections.
>
> We would really appreciate your comments.
>
>
>
> Since there are holidays, this call will last for 3 weeks, and end on
> Thursday, Jan 12, 2023.
>
>
>
> Cheers,
>
> Tianran (as co-chairs)
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg