Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Thomas.Graf]

Dear OPSAWG,

I have read the document and I think it is ready to progress. It is an 
important component of the Service Assurance for Intent-based Networking 
architecture.

Best wishes
Thomas

From: OPSAWG  On Behalf Of Tianran Zhou
Sent: Wednesday, June 8, 2022 12:04 PM
To: opsawg@ietf.org
Subject: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs



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

[OPSAWG] FW: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-04.txt

[Thomas.Graf]

Dear opsawg working group,

draft-tgraf-opsawg-ipfix-srv6-srh defines new IPFIX entities where the SRH and 
associated control-plane related dimensions are exposed to enable SRv6 
data-plane visibility.

The draft has been introduced and presented at IETF 113 to OPSAWG and SPRING 
where we collected the first comments and requested adoption at OPSAWG.
https://datatracker.ietf.org/meeting/113/materials/slides-113-opsawg-export-of-segment-routing-ipv6-information-in-ipfix-01
 

We just published -04 version and would like to collect additional comments and 
feedback.

The main changes between version -03 and -04 are:

-   srhSegmentLocatorLength and srhSegmentEndpointBehavior has been added 
and included in the use case and operational section description
-   aligned IE naming according to 
https://datatracker.ietf.org/doc/html/rfc7012#section-2.3
-   updated srhFlagsIPv6 registry
-   Added "Compressed SRv6 Segment List Decomposition" in operational 
consideration section
-   Added data-template and data-record examples for 
srhSegmentIPv6ListSection and srhSectionIPv6 in example section

Best wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Wednesday, June 29, 2022 6:35 AM
To: Benoit Claise ; Pierre Francois 
; Graf Thomas, INI-NET-TCZ-ZH1 

Subject: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-04.txt


A new version of I-D, draft-tgraf-opsawg-ipfix-srv6-srh-04.txt
has been successfully submitted by Thomas Graf and posted to the IETF 
repository.

Name:   draft-tgraf-opsawg-ipfix-srv6-srh
Revision:   04
Title:  Export of Segment Routing IPv6 Information in IP Flow 
Information Export (IPFIX)
Document date:  2022-06-28
Group:  Individual Submission
Pages:  21
URL:
https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-srv6-srh-04.txt
Status: 
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-tgraf-opsawg-ipfix-srv6-srh-04


Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   information elements to identify the SRv6 Segment Routing Header
   dimensions, the SRv6 Control Plane Protocol and the SRv6 Endpoint
   Behavior that traffic is being forwarded with.


  


The IETF Secretariat

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

[OPSAWG] FW: New Version Notification for draft-tgraf-opsawg-ipfix-inband-telemetry-00.txt

[Thomas.Graf]

Dear IPPM and OPSAWG working group,

A new draft document describing the IPFIX export of Inband Telemetry delay 
metrics with  their corresponding performance metrics definitions has been 
submitted.

https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-inband-telemetry

The authors looking forward to your reviews and comments.

The draft will be presented at IETF 114 OPSAWG together with a status update on

https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh

Best wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Friday, July 8, 2022 8:08 AM
To: Alex Feng ; Alex Huang Feng 
; Benoit Claise ; Graf 
Thomas, INI-NET-TCZ-ZH1 
Subject: New Version Notification for 
draft-tgraf-opsawg-ipfix-inband-telemetry-00.txt


A new version of I-D, draft-tgraf-opsawg-ipfix-inband-telemetry-00.txt
has been successfully submitted by Thomas Graf and posted to the IETF 
repository.

Name:   draft-tgraf-opsawg-ipfix-inband-telemetry
Revision:   00
Title:  Export of Forwarding Path Delay in IPFIX
Document date:  2022-07-08
Group:  Individual Submission
Pages:  18
URL:
https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-inband-telemetry-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-inband-telemetry/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-inband-telemetry


Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   information elements to expose the Inband Telemetry measured
   forwarding path delay in passport and postcard mode on the transit
   and decapsulation nodes.


  


The IETF Secretariat



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

Re: [OPSAWG] [spring] FW: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-04.txt

[Thomas.Graf]

Hi Tianran,

Thanks a lot for the review and comments. 

Regarding your question why it is a standards and not a informational document. 
We consulted with the IPFIX IE doctors and went for a standards document 
because we create a new IPFIX registry: "IPFIX IPv6 SRH Flags" subregistry. We 
will follow the recommendations from the WG chair, IPFIX IE doctors, and AD.

As per your suggestion we found two cases were it should be "MUST" instead of 
"must" and will address it in the next draft version and do a normative 
reference to RFC 2119. 

Before: This doesn't impose any data flow manipulation on the exporter, 
facilitating the immediate export. However, the data collection must be able to 
decode the IPv6 addresses according the SR specifications. Compared to the 
srhSegmentIPv6BasicList, the srhSegmentIPv6ListSection flow records length is 
slightly reduced.
New: This doesn't impose any data flow manipulation on the exporter, 
facilitating the immediate export. However, the data collection MUST be able to 
decode the IPv6 addresses according the SR specifications. Compared to the 
srhSegmentIPv6BasicList, the srhSegmentIPv6ListSection flow records length is 
slightly reduced.

Before: The Length must be calculated to include the optional Type Length Value 
objects.
New: The Length MUST be calculated to include the optional Type Length Value 
objects.

Best wishes
Thomas

-Original Message-
From: Tianran Zhou  
Sent: Monday, July 25, 2022 5:16 AM
To: Benoit Claise ; Graf Thomas, 
INI-NET-TCZ-ZH1 ; spr...@ietf.org; opsawg@ietf.org
Cc: pierre.franc...@insa-lyon.fr
Subject: RE: [spring] FW: New Version Notification for 
draft-tgraf-opsawg-ipfix-srv6-srh-04.txt

Hi Benoit,

Thanks for bringing this up.
I have been monitoring the discussions on this draft in SPRING and OPSAWG.
As I suggested, please copy your discussions to OPSAWG also, so that we know 
the progress.

Basically, this draft is simple and straight forward. It's quite similar to 
rfc9160 also produced by OPSAWG. 
Here are some of my comments:
1. I see the use case section is still rather simple. I am not sure if you have 
plan to expand. IMO, more details on how to use the proposed IEs is very useful 
and builds an important part of this document.
2. We can discuss the "Intended status" of this draft, as a similar document 
rfc9160 is informational. I searched the shepherd review of rfc9160, and there 
is the following record:
 The intended status is justified given that the document includes
 informative use cases to illustrate the use of the new types
 and it does not include any normative statements. Moreover, the
 registration policy for the target IANA registry (MPLS label types)
 is "Expert Review".

So, if it's the same situation here?

3. I see many lowercase "must" appears in the draft. Please check if some of 
them should be "MUST".

Cheers,
Tianran

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Tuesday, July 19, 2022 2:42 PM
To: thomas.g...@swisscom.com; spr...@ietf.org
Cc: pierre.franc...@insa-lyon.fr
Subject: Re: [spring] FW: New Version Notification for 
draft-tgraf-opsawg-ipfix-srv6-srh-04.txt

Dear all,

Note that the authors will request WG adoption in the OPSAWG next week.
So feel free to join that meeting and/or post your comments via email.

Regards, Benoit

On 6/29/2022 6:53 AM, thomas.g...@swisscom.com wrote:
> Dear spring working group,
>
> draft-tgraf-opsawg-ipfix-srv6-srh defines new IPFIX entities where the SRH 
> and associated control-plane related dimensions are exposed to enable SRv6 
> data-plane visibility.
>
> The draft has been introduced and presented at IETF 113 to OPSAWG and SPRING 
> where we collected the first comments and requested adoption at OPSAWG.
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F113%2Fmaterials%2Fslides-113-opsawg-export-of-segment-routing-ipv6-information-in-ipfix-01&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cc18fbb1e9fda48b71c6408da6e1e5884%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637943373849634565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mCoyzP3JTr5Nw8OtAEQMjHiZMnS9sQ%2BiqOcQ7WqCIO8%3D&reserved=0
>
> We just published -04 version and would like to collect additional comments 
> and feedback.
>
> The main changes between version -03 and -04 are:
>
> - srhSegmentLocatorLength and srhSegmentEndpointBehavior has been added 
> and included in the use case and operational section description
> - aligned IE naming according to 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7012%23section-2.3&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cc18fbb1e9fda48b71c6408da6e1e5884%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637943373849634565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC

Re: [OPSAWG] New Version Notification for draft-tgraf-opsawg-ipfix-inband-telemetry-01.txt

[Thomas.Graf]

Dear Greg,

Thanks a lot for the feedback and comments during OPSAWG and the conversation 
afterwards.

We are going to change the terminology from "Inband" to  "On-Path" Telemetry as 
per your suggestion to be inline with IPPM.

Regarding the term "Aggregation" in the slide deck. It refers to RFC 7015, 
IPFIX Flow Aggregation, where data is being aggregated during the metering 
process.

I reviewed draft-ietf-ippm-ioam-direct-export, RFC8321 and 
draft-ietf-ippm-rfc8321bis. I understood that the following sections are 
relevant for the data export
  
  In-situ OAM Direct Exporting
   
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export#section-3.1.2
   
https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-ioam-rawexport-06#section-3.1

  Alternate-Marking Method for Passive and Hybrid Performance Monitoring
   https://datatracker.ietf.org/doc/html/rfc8321#section-3.1.3
   
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-rfc8321bis-03#section-4.3
   
https://datatracker.ietf.org/doc/html/draft-chen-ippm-ipfpm-report-01#section-4.4

None of the IPFIX identities are defiing a delay measurement. However they 
describe how timestamps can be exported. In order to ensure that the timestamp 
for every packet can be exposed, timestamps needs to be defined as flow key 
field (https://datatracker.ietf.org/doc/html/rfc7011#section-2). This however 
prevents IPFIX Flow Aggregation (RFC7015) due to the increased cardinality. In 
draft-tgraf-opsawg-ipfix-inband-telemetry, this is described in the use case 
section: 
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-inband-telemetry#section-4.
 Feel free to comment wherever this needs to be described more approprietly.

As you and also Benoit mentioned, draft-tgraf-opsawg-ipfix-inband-telemetry 
complements draft-ietf-ippm-ioam-direct-export, RFC8321 and 
draft-ietf-ippm-rfc8321bis. Looking forward for additional input to describe 
also this aspect.

Best wishes
Thomas

-Original Message-
From: OPSAWG  On Behalf Of Benoit Claise
Sent: Thursday, July 28, 2022 3:02 PM
To: opsawg@ietf.org
Subject: [OPSAWG] FW: New Version Notification for 
draft-tgraf-opsawg-ipfix-inband-telemetry-01.txt

Dear all,

We posted a new version of this draft, which exports forwarding path delay in 
IPFIX.

The updated version includes multiple clarifications:
- the use case is better described
- the mapping between IPFIX Information Elements and Performance Metrics is 
explained
- It includes a figure displaying which forwarding path delay is actually 
exported
- We used a consistent terminology throughout the document
- the IANA considerations section is improved (and double-checked with the IANA 
rep. on site)

Your feedback is welcome, either on the mailing or during the presentation 
tomorrow.

Regards, Thomas, Alex, Benoit

-Original Message-
From: internet-dra...@ietf.org  
Sent: Thursday, July 28, 2022 10:44 AM
To: Alex Feng ; Alex Huang Feng 
; Benoit Claise ; 
Thomas Graf 
Subject: New Version Notification for 
draft-tgraf-opsawg-ipfix-inband-telemetry-01.txt


A new version of I-D, draft-tgraf-opsawg-ipfix-inband-telemetry-01.txt
has been successfully submitted by Thomas Graf and posted to the IETF 
repository.

Name:   draft-tgraf-opsawg-ipfix-inband-telemetry
Revision:   01
Title:  Export of Forwarding Path Delay in IPFIX
Document date:  2022-07-28
Group:  Individual Submission
Pages:  21
URL:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tgraf-opsawg-ipfix-inband-telemetry-01.txt&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cd3828009bf9a48ac9e4908da70cc2814%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637946319390764912%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jssrP7zcVggQzkmD7bjpbSbgMOlzRZF8t5eEb5PrCnQ%3D&reserved=0
Status: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-inband-telemetry%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cd3828009bf9a48ac9e4908da70cc2814%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637946319390764912%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=seW1wx0O3XP%2Fjz0y8UECLqq74MwDYmqFE2zPR%2BBbhKI%3D&reserved=0
Htmlized:   
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-inband-telemetry&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cd3828009bf9a48ac9e4908da70cc2814%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637946319390921142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FPQz0IYAFjdjUtqu5sCm0ZqYjt8HdVe4zakxLSRD9K0%3D&reserved=0
Diff:   
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3F

Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

[Thomas.Graf]

Dear Med,

Many thanks for the comprehensive review. Much appreciated. We merged all your 
input to the upcoming -01 release. 
https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt

The diff to the current -00 version can be found here: 
https://www.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-srv6-srh-00.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt

For some we need further clarifications if we addressed them correctly. I would 
appreciate if you could clarify the following three points:

Med> Section 2, remark: "Why do we need three IE, srhSegmentIPv6ListSection, 
srhSegmentIPv6BasicList and srhSectionIPv6, to expose SRH Segment List
Thomas> Section 5.1 should provide the answer. If that should not be 
sufficient, please suggest how this could be better expressed.

Med> Section 2: remark: "as series of n octets" is not clearly comprehensible.
Thomas> Extended to "as series of n octets in IPFIX". Does that makes it 
clearer?

Med> Section 4.11, remark: "Do you really need to define a new registry here?"
Thomas> The registry could potentially be used (and updated) by non IPFIX 
people.

Best wishes
Thomas

From: OPSAWG  On Behalf Of mohamed.boucad...@orange.com
Sent: Tuesday, September 6, 2022 10:19 AM
To: Joe Clarke (jclarke) ; opsawg@ietf.org
Subject: Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi all,

I support.

FWIW, the authors may found some quick comments at:


  *   pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-tgraf-opsawg-ipfix-srv6-srh-05-rev%20Med.pdf
  *   doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-tgraf-opsawg-ipfix-srv6-srh-05-rev%20Med.doc

Cheers,
Med

De : OPSAWG mailto:opsawg-boun...@ietf.org>> De la 
part de Joe Clarke (jclarke)
Envoyé : jeudi 18 août 2022 22:14
À : opsawg@ietf.org
Objet : [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hello, WG.  We'd like to begin a two week call for adoption of this work.  Even 
as an individual draft it has already received some reviews and has iterated 
quite a bit.  Based on IETF 114 there does seem to be interest in adopting this 
in opsawg, but we need a formal adoption poll.

Please review and provide your adoption thoughts no later than September 1, 
2022.

Thanks.

Joe

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.


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

Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

[Thomas.Graf]

Hi Med,

Benoit will feedback on your reply.

In the meanwhile I like to take the opportunity to get your feedback on an 
additional operational consideration section I added based on an off list 
feedback I received from a software developer implementing the draft document.

https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt

5.3.  Multiple Segment Routing Headers

   [RFC8200] describes the support of multiple extension headers in one
   IPv6 packet.  Allowing the use of multiple SRH per SRv6 packet.  The
   export of the same IE multiple times in one data-record and data-
   template is supported and the order within the packet SHOULD be
   preserved in the IPFIX export according to Section 8 of [RFC7011].
   If the network node is not capable to export IPFIX for more than one
   SRH, it MUST export IPFIX for the active SRH.


Best wishes
Thomas

From: mohamed.boucad...@orange.com 
Sent: Monday, September 19, 2022 2:22 PM
To: Benoit Claise ; Graf Thomas, INI-NET-TCZ-ZH1 
; jclarke=40cisco@dmarc.ietf.org; opsawg@ietf.org
Cc: pierre.franc...@insa-lyon.fr
Subject: RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi Benoît,

Thank you for the follow-up.

Actually, the more I look into this, the more I'm convinced that we don't need 
a new registry for the flags and that the statement "Values for this 
Information Element are listed in the "IPFIX IPv6 SRH Flags" registry" is 
restrictive (inaccurate(?)). The flags should be exported as ** observed ** not 
as set in the registry.

Think about discarded packets because some flags are set (including those 
already for which a meaning is already defined such as the O flag) while the 
processing of these flags is not supported by a router. In such cases, one use 
of the srhFlagsIPv6 IE would be to display the erroneous set of flags together 
with some error counters. The values of the IE is not "taken from the IANA 
registry".

That said, I fully agree that the spec has to indicate "Data Type Semantics:  
flags" for that IE.

The same would apply for the srhSegmentEndpointBehavior IE.

Please let me know if I'm missing something. Thanks.

Cheers,
Med

De : Benoit Claise mailto:benoit.cla...@huawei.com>>
Envoyé : samedi 17 septembre 2022 17:39
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; 
thomas.g...@swisscom.com; 
jclarke=40cisco@dmarc.ietf.org; 
opsawg@ietf.org
Cc : pierre.franc...@insa-lyon.fr; me 
mailto:benoit.cla...@huawei.com>>
Objet : Re: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi Med,

Thanks for your comments.

I visited IANA in Philly to validate this propose, but we could re-evaluate & 
discuss about it.

We need a registry because just telling that we take the value from 
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags
 is not sufficient as we also need to specify the following IPFIX fields:
- Abstract Data Type. (unsigned8 in this srhFlagsIPv6 case)
- Data Type Semantics (flags in srhFlagsIPv6 case)

Now, if your point is that we don't really to mention the initial values ...
Initial values in the registry are defined by the table
  below.

  ++---+--+
  | Value  |Description|  Reference   |
  ++---+--+
  | 0-1| Unassigned|  |
  ++---+--+
  | 2  | O-flag|  [RFC-ietf-6man-spring-srv6-oam-13]  |
  ++---+--+
  | 3-7| Unassigned|  |
  ++---+--+

   Table 2: "IPFIX IPv6 SRH Flags" registry
... I agree it's not strictly necessary but it helps (me/the IPFIX experts) to 
understand, from this document, which type of values are currently available.

See inline.
On 9/16/2022 9:34 AM, 
mohamed.boucad...@orange.com wrote:
Hi Thomas,

Thank you for preparing this revised version.

I think almost all my comments are addressed in this version. However, 

Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

[Thomas.Graf]

Hi Med,


You read my mind. If I read yours correctly you mean that there can be multiple 
extension headers which could be exposed each with one IE64 
ipv6ExtensionHeaders. What we don't know is how many times each header type 
occurs and the order in the packet. What is also missing is the distinguisher 
between the routing types. Correct?



Best wishes

Thomas

From: mohamed.boucad...@orange.com 
Sent: Tuesday, September 20, 2022 11:13 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; 
benoit.cla...@huawei.com; jclarke=40cisco@dmarc.ietf.org; opsawg@ietf.org
Cc: pierre.franc...@insa-lyon.fr
Subject: ***Signed_Message*** RE: CALL FOR ADOPTION: 
draft-tgraf-opsawg-ipfix-srv6-srh

Hi Thomas,

This is a useful addition. Thanks.


A more general question is to check whether one can report the identity of the 
EHs that form the Header Chain, but this is not specific to this draft. The 
current ipv6ExtensionHeaders does not allow for that.

Cheers,
Med

De : thomas.g...@swisscom.com 
mailto:thomas.g...@swisscom.com>>
Envoyé : lundi 19 septembre 2022 16:47
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; 
benoit.cla...@huawei.com; 
jclarke=40cisco@dmarc.ietf.org; 
opsawg@ietf.org
Cc : pierre.franc...@insa-lyon.fr
Objet : RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi Med,

Benoit will feedback on your reply.

In the meanwhile I like to take the opportunity to get your feedback on an 
additional operational consideration section I added based on an off list 
feedback I received from a software developer implementing the draft document.

https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt

5.3.  Multiple Segment Routing Headers

   [RFC8200] describes the support of multiple extension headers in one
   IPv6 packet.  Allowing the use of multiple SRH per SRv6 packet.  The
   export of the same IE multiple times in one data-record and data-
   template is supported and the order within the packet SHOULD be
   preserved in the IPFIX export according to Section 8 of [RFC7011].
   If the network node is not capable to export IPFIX for more than one
   SRH, it MUST export IPFIX for the active SRH.


Best wishes
Thomas

From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Sent: Monday, September 19, 2022 2:22 PM
To: Benoit Claise mailto:benoit.cla...@huawei.com>>; 
Graf Thomas, INI-NET-TCZ-ZH1 
mailto:thomas.g...@swisscom.com>>; 
jclarke=40cisco@dmarc.ietf.org; 
opsawg@ietf.org
Cc: pierre.franc...@insa-lyon.fr
Subject: RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi Benoît,

Thank you for the follow-up.

Actually, the more I look into this, the more I'm convinced that we don't need 
a new registry for the flags and that the statement "Values for this 
Information Element are listed in the "IPFIX IPv6 SRH Flags" registry" is 
restrictive (inaccurate(?)). The flags should be exported as ** observed ** not 
as set in the registry.

Think about discarded packets because some flags are set (including those 
already for which a meaning is already defined such as the O flag) while the 
processing of these flags is not supported by a router. In such cases, one use 
of the srhFlagsIPv6 IE would be to display the erroneous set of flags together 
with some error counters. The values of the IE is not "taken from the IANA 
registry".

That said, I fully agree that the spec has to indicate "Data Type Semantics:  
flags" for that IE.

The same would apply for the srhSegmentEndpointBehavior IE.

Please let me know if I'm missing something. Thanks.

Cheers,
Med

De : Benoit Claise mailto:benoit.cla...@huawei.com>>
Envoyé : samedi 17 septembre 2022 17:39
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; 
thomas.g...@swisscom.com; 
jclarke=40cisco@dmarc.ietf.org; 
opsawg@ietf.org
Cc : pierre.franc...@insa-lyon.fr; me 
mailto:benoit.cla...@huawei.com>>
Objet : Re: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi Med,

Thanks for your c

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-01.txt

[Thomas.Graf]

Dear OPSAWG, SPRING and 6MAN,

Version -01 of draft-ietf-opsawg-ipfix-srv6-srh has been published to address 
various comments from the lists since IETF 114. Many thanks for all who 
reviewed and contributed. This is much appreciated.

We added section 6.3, Multiple Segment Routing Headers in the Operational 
Considerations section to address off list feedback to clarify how IPFIX export 
should be supported when more then one SRH is present in the packet.

We would appreciate your review and comment on the changes of the -01 version.

We are going to join the IETF 115 hackathon 
(https://wiki.ietf.org/en/meeting/115/hackathon) where we validate the first 
implementations. If you have interest to participate please feel free to ping 
me off list.

Best wishes
Thomas

-Original Message-
From: OPSAWG  On Behalf Of internet-dra...@ietf.org
Sent: Friday, September 23, 2022 1:19 PM
To: i-d-annou...@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : Export of Segment Routing over IPv6 Information in IP 
Flow Information Export (IPFIX)
Authors : Thomas Graf
  Benoit Claise
  Pierre Francois
  Filename: draft-ietf-opsawg-ipfix-srv6-srh-01.txt
  Pages   : 26
  Date: 2022-09-23

Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   Information Elements to identify a set of Segment Routing over IPv6
   (SRv6) related information such as data contained in a Segment
   Routing Header (SRH), the SRv6 control plane, and the SRv6 behavior
   that traffic is being forwarded with.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-01

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

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

[OPSAWG] draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early code point allocation

[Thomas.Graf]

Dear OPSAWG chairs,

We believe that the draft is reaching stable state. At IETF 115 hackathon in 
November we will have one open-source and one closed-source implementation of 
draft-ietf-opsawg-ipfix-srv6-srh-01.

Therefore we believe we are satisfying the conditions for early allocation of 
code points as described https://www.rfc-editor.org/rfc/rfc7120#section-2.

With your permission we would like to go ahead an get in contact with IANA and 
clarify Med's comments on the

srhFlagsIPv6
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.1

and

srhSegmentEndpointBehavior
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.11

registry commented at 
https://github.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/pull/15/commits/470424596d9eeaa368a497a1a53f19573b764df9

first and then go ahead with the IPFIX entity early allocation.

Best wishes
Thomas


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

Re: [OPSAWG] draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early code point allocation

[Thomas.Graf]

Dear Joe,


My apology for late reply. That works for us.



We are in touch with IANA and the IPFIX doctors to clarify the points raised by 
Med in regards to the srhFlagsIPv6 and the srhSegmentEndpointBehavior registry. 
Once this has been clarified we will publish -02 version.



We would like to request a 15min slot for IETF 115 to present an update on the 
latest document updates and some feedback on two running code implementations 
from the hackathon where we use IPFIX entities from the PEN space. Could we 
raise the question to the WG in this slot wherever we have consensus that early 
allocation is warranted or not?



Best wishes

Thomas

From: Joe Clarke (jclarke) 
Sent: Friday, September 23, 2022 7:49 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; 
opsawg-cha...@ietf.org
Cc: opsawg@ietf.org; pierre.franc...@insa-lyon.fr
Subject: Re: draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early code 
point allocation

Hey, Thomas.  I'm a wee bit nervous declaring stability since IETF 115 hasn't 
happened yet, but I do think you're on track, and I can request of the WG their 
thoughts as to whether there is consensus that early allocation is warranted.

So, I think a, b, and d from Section 2 are met (speaking for ADs on d).  I just 
want to make sure we're not bit by anything at the 'thon at 115.

In terms of process, once we are satisfied that c is met, it is on us (chairs) 
to request approval from the ADs.  You do not need to contact IANA.  If this is 
approved, we will make that request.

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of thomas.g...@swisscom.com 
mailto:thomas.g...@swisscom.com>>
Date: Friday, September 23, 2022 at 8:27 AM
To: opsawg-cha...@ietf.org 
mailto:opsawg-cha...@ietf.org>>
Cc: opsawg@ietf.org 
mailto:opsawg@ietf.org>>, 
pierre.franc...@insa-lyon.fr 
mailto:pierre.franc...@insa-lyon.fr>>
Subject: [OPSAWG] draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early 
code point allocation
Dear OPSAWG chairs,

We believe that the draft is reaching stable state. At IETF 115 hackathon in 
November we will have one open-source and one closed-source implementation of 
draft-ietf-opsawg-ipfix-srv6-srh-01.

Therefore we believe we are satisfying the conditions for early allocation of 
code points as described 
https://www.rfc-editor.org/rfc/rfc7120#section-2.

With your permission we would like to go ahead an get in contact with IANA and 
clarify Med's comments on the

srhFlagsIPv6
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.1

and

srhSegmentEndpointBehavior
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.11

registry commented at 
https://github.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/pull/15/commits/470424596d9eeaa368a497a1a53f19573b764df9

first and then go ahead with the IPFIX entity early allocation.

Best wishes
Thomas


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG maili

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-02.txt

[Thomas.Graf]

Dear OPSAWG,

On behalf of the authors. The -02 version includes besides editorial changes 
and nits the following updates:

- Expanded the terminology section
- The srhFlagsIPv6 and srhSegmentEndpointBehavior registries have now a 
reference to the Segment Routing Header registry. Thanks Med for the input.
- Added Segment Routing Policy in the srhActiveSegmentIPv6Type registry
- Corrected "Template Record and Data Set with SRH Section" example

Looking forward to your reviews and comments.

We are at the hackathon (https://wiki.ietf.org/en/meeting/115/hackathon) where 
we validate two implementations. You are welcome to join us.

Best wishes
Thomas

-Original Message-
From: OPSAWG  On Behalf Of internet-dra...@ietf.org
Sent: Thursday, October 20, 2022 2:11 PM
To: i-d-annou...@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : Export of Segment Routing over IPv6 Information in IP 
Flow Information Export (IPFIX)
Authors : Thomas Graf
  Benoit Claise
  Pierre Francois
  Filename: draft-ietf-opsawg-ipfix-srv6-srh-02.txt
  Pages   : 26
  Date: 2022-10-20

Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   Information Elements to identify a set of Segment Routing over IPv6
   (SRv6) related information such as data contained in a Segment
   Routing Header (SRH), the SRv6 control plane, and the SRv6 behavior
   that traffic is being forwarded with.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

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

Re: [OPSAWG] New Version Notification for draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt

[Thomas.Graf]

Dear OPSAWG and IPPM,

On behalf of the authors. Thank you very much for the comments at IETF 114 in 
Philadelphia and on the list. 

We addressed your feedback in a new document version and renamed the draft 
document from draft-tgraf-opsawg-ipfix-inband-telemetry to 
draft-tgraf-opsawg-ipfix-on-path-telemetry. Thanks Greg for the input.

Looking forward to your reviews and comments.

Best wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Thursday, October 20, 2022 3:32 PM
To: Alex Feng ; Alex Huang Feng 
; Benoit Claise ; Graf 
Thomas, INI-NET-TCZ-ZH1 
Subject: New Version Notification for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt


A new version of I-D, draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt
has been successfully submitted by Thomas Graf and posted to the IETF 
repository.

Name:   draft-tgraf-opsawg-ipfix-on-path-telemetry
Revision:   00
Title:  Export of On-Path Delay in IPFIX
Document date:  2022-10-20
Group:  Individual Submission
Pages:  22
URL:
https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry
Diff:  
https://www.ietf.org/rfcdiff?url1=draft-tgraf-opsawg-ipfix-inband-telemetry-01&url2=draft-tgraf-opsawg-ipfix-on-path-telemetry-00&difftype=--html

Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   information elements to expose the On-Path Telemetry measured delay
   on the IOAM transit and decapsulation nodes.


  


The IETF Secretariat



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

[OPSAWG] FW: Comments on draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt

[Thomas.Graf]

Dear Al,

Thank you very much for the review and the comments. Much appreciated. I merged 
them in the next -01 version as following:

https://www.ietf.org/rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt

Best wishes
Thomas

From: MORTON JR., AL 
Sent: Monday, October 31, 2022 2:22 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; 
benoit.cla...@huawei.com; i...@ietf.org
Subject: Comments on draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt

Hi Thomas and Benoit,

I reviewed your draft at
https://github.com/graf3net/draft-tgraf-opsawg-ipfix-inband-telemetry/blob/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-00.txt


I like the fact that you have appreciated the IPPM work and IPfix work that 
precedes your efforts.  This draft is fully useful in ippm and the OPSarea, IMO.

You might mention that Section 2 uses the template of RFC8911 and the 
Performance Metrics Registry. Your draft is the first to adopt this template – 
now that the RFC is fully published!

I’ll add some notes as I scan through:

End of 2.3.1
   The Traffic Filter at the OP is configured to observe a single IP
   connection.
We don’t have connections at the IP-layer, only a stream of datagrams...

BTW, when I used the simplifying convention of
2.4.2.5.  Metric Units

   The  of one-way delay is expressed in seconds, where
is one of:

   *  Mean
...

in RFC 8912, I ultimately had to help IANA prepare complete and separate 
sections for each . So, while I completely agree with re-using the 
 simplification in the draft, be prepared to create the 4 new 
versions of Section 2, one for each , when this eventually reaches 
IANA for implementation. 😊

and that’s it for now!

I can easily see how much research and work you have committed to this draft. 
There seem to be some other comments to address, but the solutions appear 
within reach.

regards,
Al




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

Re: [OPSAWG] IPR POLL: draft-ietf-opsawg-ipfix-srv6-srh

[Thomas.Graf]

Dear OPSAWG,

No, I'm not aware of any IPR that applies to this draft.

Best wishes
Thomas

From: Joe Clarke (jclarke) 
Sent: Wednesday, November 30, 2022 2:55 PM
To: opsawg@ietf.org
Cc: draft-ietf-opsawg-ipfix-srv6-...@ietf.org
Subject: IPR POLL: draft-ietf-opsawg-ipfix-srv6-srh

Authors and contributors, please respond on-list as to whether or not you are 
aware of any IPR that pertains to this work.

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If you are aware of IPR, indicate whether or not this has been disclosed per 
IETF IPR rules (see RFCs 3669, 5378, and 8179).

Joe


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

Re: [OPSAWG] 🔔 WG LC: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)

[Thomas.Graf]

Dear OPSAWG,

Writing as one of the authors. Talking to various network operators deploying 
SRv6 and network vendors implementing the document in the last few months, 
refining the document steadily and arrived at this stable state, I believe this 
document is ready for working group last call.

Best wishes
Thomas

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, November 30, 2022 2:54 PM
To: opsawg@ietf.org
Subject: [OPSAWG] 🔔 WG LC: Export of Segment Routing over IPv6 Information in 
IP Flow Information Export (IPFIX)

Hello, WG.  As discussed at IETF 115, we want to conduct a WG LC for 
draft-ietf-opsawg-ipfix-srv6-srh.  The authors believe this work is stable and 
moreover used the 115 hackathon to develop a interoperable implementations 
(linked in Data Tracker) .  Additionally, IANA has already weighed in on this 
work and agree with the considerations approach.

Therefore, we are calling for a two week LC.  We will conclude on December 14.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/

Please review the current -04 draft, post your comments and/or your thoughts on 
the current text.

Thanks.

Joe


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

Re: [OPSAWG] 🔔 WG LC: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)

[Thomas.Graf]

Dear Qin,

Thanks a lot for the detailed review and comments. This is much appreciated. My 
answers inline.

I am tracking the changes in here:

https://www.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-srv6-srh-04.txt&url2=https://raw.githubusercontent.com/graf3net/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-05.txt

Best wishes
Thomas

From: Qin Wu 
Sent: Saturday, December 3, 2022 3:07 PM
To: Joe Clarke (jclarke) ; opsawg@ietf.org
Cc: Graf Thomas, INI-NET-TCZ-ZH1 
Subject: RE: 🔔 WG LC: Export of Segment Routing over IPv6 Information in IP 
Flow Information Export (IPFIX)

Hi, All:
Thanks authors to write this draft and validate it using Hackathon project. I 
take some time to review this draft, my general position is to support moving 
this work toward publication.
Here are a few comments and suggestions:

1.   Abstract:
What is the difference between “the SRv6 behavior that traffic is being 
forwarded with. “ and SRv6 forwarding plane? Should we just use SRv6 forwarding 
plane to replace original wording? Maybe I miss something.
But we need to consider consistency between abstract and introduction 
description.

TG > With "SRv6 behavior" the "SRv6 endpoint behavior" is meant from RFC 8986 
section 4 (https://datatracker.ietf.org/doc/html/rfc8986#section-4). We will 
change the wording in the abstract from "SRv6 behavior" to "SRv6 endpoint 
behavior".

2.Section 3, the definition of srhFlagsIPv6
At the current stage, 8 bit flags defined in SRH are all unused according to 
RFC8754,however looking up IANA registry for Segment Routing Header Flags,
Only OAM flag is allocated for RFC9259, I am wondering whether OAM flag should 
be reported together with other unused flags.
What is the impact on this parameter when some other flags have been allocated 
from Segment Routing Header Flags registry, it seems no harm, but do you think 
we should clarify only OAM flag is allocated in this srhFlagsIPv6 definition.


TG > We clarified this with IANA extensively. As described in 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh#section-5.1,
 we refer to the "Segment Routing Header Flags" IANA registry where the flags 
are defined for the segment routing header. IPFIX doesn't allocate new entities.

3.Section 3, the definition of srhTagsIPv6
I am wondering whether we need to have some out-band  mechanism to define the 
meaning or purpose of using these srhTagIPv6, when we say a group of packet 
sharing the same set of properties, what is the example of these properties? 
Should these srhTagIPv6 global unique? Or local scope specific?

TG > The SRH tags are defined and described in 
https://datatracker.ietf.org/doc/html/rfc8754#section-2. They are currently not 
used but in context of IPFIX could become very useful since we now can mark and 
group packets with the same properties. It is outside of the scope of 
draft-ietf-opsawg-ipfix-srv6-srh to describe the usage of SRH tags.

4.Section 3 the definition of srhSegmentIPv6ListSection
I am not sure I understand the difference between srhSegmentIPv6BasicList and 
srhSegmentIPv6ListSection?
I know you provide an usage example to explain this, but  for the reader who 
are not familiar with IPFIX, it is hard to parse this. Would it be great to add 
some text in the definition of srhSegment IPv6ListSection to clarify this 
difference.
Maybe add a pointer to section 6.1

TG > Correct section 6.1 describes the differences between 
srhSegmentIPv6BasicList and srhSegmentIPv6ListSection. We could add a pointer.

Also I believe srhSegmentIPv6BasicList and srhSegmentIPv6ListSection should not 
be reported at the same time? Two IE should be mutually excluded? No?

TG > We don't prevent this. That would go to far. We describe under operation 
consideration in section 6.1 that this would not be an expected behavior.

   It is not expected that an exporter would support both
   srhSegmentIPv6BasicList and srhSegmentIPv6ListSection at the same
   time.

5.Section 3. The definition of srhSection IPv6
The same comment is applied to srhSection IPv6, I think we should add more 
texts to explain how srhSectionIPv6 organized? Or what information is included 
in srhSectionIPv6

TG > srhSectionIPv6 exports the entire SRH and its TLVs as specified in 
https://datatracker.ietf.org/doc/html/rfc8754#section-2. For the authors the 
description makes sense. Could you propose a wording which would make more 
sense to you?

6.Section 4
It looks these information in section 4 can be used to provide SRv6 visibility 
or troubleshooting, for the answer 2, I am wondering what else does the 
management system do for troubleshooting? Or the network devices have already 
done everything for the management system regarding troubleshooting?

TG > In this section we describe use cases how this metrics can be used. We 
follow the same pattern as we did for MPLS-SR 
(https://datatracker.ietf.org/doc/html/rfc9160#section-2). We belie

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-05.txt

[Thomas.Graf]

Dear Med,

Many thanks for the review and my apology that we missed your input on section 
5.9

I updated the document on section 5.9 and 6.3 as per input. Please review and 
comment before we submit.

https://author-tools.ietf.org/iddiff?url1=https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-srv6-srh-05.txt&url2=https://raw.githubusercontent.com/graf3net/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-06.txt

We agree that RFC 8200 doesn't explicitly describe the use of multiple SRH and 
therefore the wording in section 6.3 is misleading as you pointed out. 
Therefore we removed the RFC 8200 reference and used your wording proposal.

In section 6.3 we want to ensure that there is no ambiguity how IPFIX needs to 
be implemented in case more than one SRH is present. Section 8 of RFC 7011 
describes only the case when both SRH can be exported. Since section 6 is 
devoted to operational considerations, the authors believe it make sense to 
spend a paragraph in describing both cases, when both SRH can be export versus 
when only the SRH of the active segment can be exported in IPFIX to have a 
complete description. Does that make sense?

Best wishes
Thomas

-Original Message-
From: mohamed.boucad...@orange.com  
Sent: Friday, December 16, 2022 9:24 AM
To: opsawg@ietf.org; Graf Thomas, INI-NET-TCZ-ZH1 
Subject: RE: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-05.txt

Hi Thomas, all,

Thanks for preparing this version. However, I think that not all the issues 
were fixed: 

* Section "5.9.  srhActiveSegmentIPv6Type": please add the pointer to the IANA 
registry under "Additional Information". Please see the proposal from Benoît 
at: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fopsawg%2FZZ5anFVYpabnmm12sfkmGB6nHYI%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf3bfd5fa3dea48ca6a0d08dadf3ef5aa%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638067758737320741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1X%2BI2yBo6C5NApGb053NIyCj2LYIdWlZWaxjbj0kr5A%3D&reserved=0

* The text about multiple SRH is somehow "misleading" as it can be interpreted  
as 8200 discusses explicitly multiple SRHs case. Also, and unless I' mistaken, 
there is no spring document that motivates the need for multiple SRHs or how 
these can be used. I suggest to simplify the wording of 6.3 to basically say: 
if multiple SRHs are observed (for reasons that are not detailed here), 
exporting multiple IEs is allowed + follow the base reco in 7011 for the 
ordering. No normative language is needed for this behavior. 

* Please define what is meant by "active SRH". 

Thank you. 

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de internet- 
> dra...@ietf.org Envoyé : vendredi 16 décembre 2022 08:50 À : 
> i-d-annou...@ietf.org Cc : opsawg@ietf.org Objet : [OPSAWG] I-D 
> Action: draft-ietf-opsawg-ipfix-srv6-srh- 05.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area
> Working Group WG of the IETF.
> 
> Title   : Export of Segment Routing over IPv6
> Information in IP Flow Information Export (IPFIX)
> Authors : Thomas Graf
>   Benoit Claise
>   Pierre Francois
>   Filename: draft-ietf-opsawg-ipfix-srv6-srh-05.txt
>   Pages   : 28
>   Date: 2022-12-15
> 
> Abstract:
>This document introduces new IP Flow Information Export (IPFIX)
>Information Elements to identify a set of Segment Routing over
> IPv6
>(SRv6) related information such as data contained in a Segment
>Routing Header (SRH), the SRv6 control plane, and the SRv6
> endpoint
>behavior that traffic is being forwarded with.
> 
> 
> The IETF datatracker status page for this draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-srv6-srh%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf3bfd5fa3dea48ca6a0d08dadf3ef5aa%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638067758737320741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yHPX83xmakzfCRJZMxdJ5oq9T3xHbvCN9C2HHMGYaDg%3D&reserved=0
> 
> There is also an htmlized version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-opsawg-ipfix-&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cf3bfd5fa3dea48ca6a0d08dadf3ef5aa%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638067758737320741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xZjDt94k7d99AQtEzMjXpO7Im2XD8Cqhn3cqvMTpO24%3D&reserved=0
> srv6-srh-05
> 
> A diff from the previous version is available at:
> https://

[OPSAWG] FW: New Version Notification for draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt

[Thomas.Graf]

Dear OPSAWG and IPPM,

We received at IETF 115 some feedback and comments. We added a terminology 
section, the reference to RFC 9232 Network Telemetry Framework and some minor 
editorial changes.

As always, feedback and comments are very welcome.

Looking forward for the adoption call at OPSAWG.

We are planning to attend the IETF 116 hackathon 
(https://wiki.ietf.org/en/meeting/116/hackathon) where we implement, validate 
and test an open-source and closed-source router, an open-source 
data-collection implementation and show it with a Network Anomaly detection use 
case.

Best wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Tuesday, December 20, 2022 6:27 AM
To: Alex Feng ; Alex Huang Feng 
; Benoit Claise ; Graf 
Thomas, INI-NET-TCZ-ZH1 
Subject: New Version Notification for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt


A new version of I-D, draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt
has been successfully submitted by Thomas Graf and posted to the IETF 
repository.

Name:   draft-tgraf-opsawg-ipfix-on-path-telemetry
Revision:   01
Title:  Export of On-Path Delay in IPFIX
Document date:  2022-12-20
Group:  Individual Submission
Pages:  23
URL:
https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-tgraf-opsawg-ipfix-on-path-telemetry-01
Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   information elements to expose the On-Path Telemetry measured delay
   on the IOAM transit and decapsulation nodes.


  


The IETF Secretariat



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

Re: [OPSAWG] IPR Poll on draft-tgraf-opsawg-ipfix-on-path-telemetry

[Thomas.Graf]

Dear OPSAWG,

I am not aware of any IPR related to this draft.

Best wishes
Thomas

From: Tianran Zhou 
Sent: Thursday, December 22, 2022 3:56 AM
To: opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: IPR Poll on draft-tgraf-opsawg-ipfix-on-path-telemetry

Hi Authors and Contributors,

Accompany with the WG adoption on this draft, I'd like all authors and 
contributors to confirm on the list.
Please respond if you are aware of any IPR related to this draft.
If you are aware of IPR, please indicate whether or not this has been disclosed 
per IETF IPR rules (see RFCs 3669, 5378, and 8179).

Thanks,
Tianran


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

[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/

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
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)


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

Re: [OPSAWG] [ippm] 回复: FW: 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: ippm  On Behalf Of li_zhenqi...@hotmail.com
Sent: Tuesday, January 3, 2023 4:51 PM
To: Tianran Zhou ; ippm 
Cc: opsawg@ietf.org
Subject: [ippm] 回复: FW: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi Tianran and all,

Why not use one protocol, such as grpc, to export all the iOAM metrics? It is 
ok to export one way delay in IPFIX. If other metrics, such as queue depth, 
buffer occupancy, etc,  have to be exported in grpc, it is not necessory to 
export one way delay in IPFIX.


Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

发件人： Tianran Zhou
发送时间： 2022-12-22 10:40
收件人： 'IETF IPPM WG'
抄送： opsawg@ietf.org
主题： [ippm] FW: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01
Hi IPPM,

The OPSAWG just started 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/

There are performance metrics registrations within this draft.
We would really appreciate your comments from IPPM.

Thanks,
Tianran

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2022年12月22日 10:26
收件人: opsawg@ietf.org
抄送: 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
主题: [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/

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&url2=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
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)


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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-05.txt

[Thomas.Graf]

Dear Med,



Also many thanks from my side. Much appreciated. I just submitted the -06 
version.

If there aren't any objections anymore I think Joe can go ahead from here.

Best wishes
Thomas

From: Benoit Claise 
Sent: Thursday, January 5, 2023 10:08 AM
To: mohamed.boucad...@orange.com; Graf Thomas, INI-NET-VNC-HCS 
; opsawg@ietf.org
Cc: pierre.franc...@insa-lyon.fr
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-05.txt

Hi Med,

Perfect. That makes sense. Let's execute on this proposal below.
Let me stress again: thanks for your continuous effort to improve this draft.

Regards, Benoit
On 1/5/2023 9:18 AM, 
mohamed.boucad...@orange.com wrote:
Hi Benoît,

You got it. We are not defining a new ordering behavior, but simply adhering to 
what the IPFIX spec says on this matter.

I would mix your proposed wording with what Thomas already implemented in 
https://raw.githubusercontent.com/graf3net/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-06.txt:

NEW:
   If multiple SRHs are observed (for reasons that are not detailed
   here), the export of the same IE multiple times in one data record
   and related template record is supported. In such a case,
   the following IPFIX behavior in Section 8 of [RFC7011] applies:
   "If an Information Element is required more than once in a Template,
   the different occurrences of this Information Element SHOULD follow
   the logical order of their treatments by the Metering Process".
   If the network node is not capable to export IPFIX for
   more than one SRH, it MUST export IPFIX for the SRH of the active
   segment.

Thank you.

Cheers,
Med

De : Benoit Claise 
Envoyé : mercredi 4 janvier 2023 18:43
À : BOUCADAIR Mohamed INNOV/NET 
; 
thomas.g...@swisscom.com; 
opsawg@ietf.org
Cc : pierre.franc...@insa-lyon.fr
Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-05.txt

Hi Med,

Thanks for your continuous effort to improve this draft.

Help me understand your point of view regarding your comment:

Thanks for preparing this revised version. The changes look good.

However, and as discussed previously, I was expecting to see s/packet

SHOULD be preserved in the IPFIX export according/packet should be

preserved in the IPFIX export according.
Actually, we have this specific sentence in 
https://www.rfc-editor.org/rfc/rfc7011#section-8

If an Information Element is required more than once in a Template,

the different occurrences of this Information Element SHOULD follow

the logical order of their treatments by the Metering Process.
This sentence applies to the case of multiple SRHs in a Flow Record and this 
specification MUST be followed in such a case.
This was actually our intent with this paragraph in the draft version 5, that 
is drawing attention to that specific sentence:

6.3.  Multiple Segment Routing Headers



   [RFC8200] describes the support of multiple extension headers such as

   the SRH in one IPv6 packet.  The export of the same IE multiple times

   in one data record and related template is supported and the order

   within the packet SHOULD be preserved in the IPFIX export according

   to Section 8 of [RFC7011].  If the network node is not capable to

   export IPFIX for more than one SRH, it MUST export IPFIX for the

   active SRH

Do we agree so far on the intent of this paragraph?
I believe so when I re-read your initial comment:

I suggest to simplify the wording of 6.3 to basically say: if

multiple SRHs are observed (for reasons that are not detailed

here), exporting multiple IEs is allowed + follow the base reco in

7011 for the ordering. No normative language is needed for this

behavior.
Reco?

Granted, we most likely did not express ourselves correctly in section 6.3.
For ex, we used a SHOULD to be aligned with the sentence in RFC7011.
Is this this issue at stake here: t

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/

> 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 
mailto:zhoutian...@huawei.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 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 consid

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]
Sent: Thursday, January 5, 2023 9:22 PM
To: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
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
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/

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

[Thomas.Graf]

Dear Zhenqiang,

Thanks a lot for the feedback. Much appreciated.

I do not disagree that YANG push isn't capable of exporting control and 
forwarding plane metrics. However it is not the best choice in terms of scale. 
Table 1 of RFC 9232 gives a good summary. It even makes the distinction between 
network processor and route processor export. What it doesn't show however is 
that gRPC isn't suitable for network processors. To date, no vendor 
implementations are present. From my research with network and ASIC vendors as 
being the co-author of draft-ietf-netconf-distributed 
(https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif) I 
understood that gRPC won't be implementable in its current form. One of the 
main reason is the lack of backpressure support on network processors.

I fully agree that export for probing metrics such a TWAMP, TWAMP light or 
STAMP makes perfectly sense. With draft-ietf-ippm-stamp-yang and RFC 8913 we 
have well defined YANG modules. Speaking as network operator with approx. 7000 
YANG publishers I can confirm that this works well. Either when both probing 
and export runs on the route processor or both on the network processor 
directly.


  *   In my understanding, the aggregation benifit of IPFIX is not applicable 
for iOAM metrics, such as delay and packet loss, because iOAM metrics are 
different for different flows.

This I don't understand fully. Could you describe more detailed please.

To my understanding and maybe this helps to establish a clearer picture. IOAM 
is applied to existing or replicated packets and is classified as One-Way Delay 
Hybrid Type I according to Section 1 of draft-ietf-ippm-ioam-deployment 
(https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment#section-1).
 There are two modes. Active and Passive. In passive, where 
draft-tgraf-opsawg-ipfix-on-path-telemetry focuses on, existing packets are 
being used. Where in active mode, existing packets are replicated. IPFIX takes 
the packets and accounts them into flows. In flows we account bytes and packets 
over a given time period. With draft-tgraf-opsawg-ipfix-on-path-telemetry we 
also account for delay.


  *   Neither sampling, how can you insure that the flow you want its iOAM 
metrics will be sampled?

Packets have to be selected in the IOAM encapsulation node as described in 
Section 7.4 of draft-ietf-ippm-ioam-deployment 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment#section-7.4.
 IOAM doesn't specify how the packets are being selected. To my opinion it 
would make sense to refer in Section 7.4 of draft-ietf-ippm-ioam-deployment to 
RFC 5474 and RFC 5475 which are describing packet selection and sampling 
techniques, both widely used with IPFIX.

The benefit of sampling at the IOAM encapsulation node and flag with IOAM-DEX 
versus sampling on all nodes is that the amount of flows being exported is the 
same, but in case of IOAM-DEX we know the forwarding path in addition without 
additional overhead in the data export.


  *   The iOAM metrics, especially the delay and packet loss, should be 
exported in time, for example in one second. I don't think IPFIX is the right 
protocol.

For packet loss, you are correct, IPFIX is not the right protocol since packet 
loss is observed at the edges of the observation domain (black box monitoring). 
Packet loss is observed with probing where YANG push is the best choice for 
data export. IPFIX is being used to visualize where the packets are being 
dropped for which flow with IE89 ForwardingStatus.

IPFIX can export metrics without aggregation where flows are immediately being 
exported at ingress or egress. It is correct that aggregation introduces delay. 
Therefore it should only be applied to use cases which make sense 
https://www.rfc-editor.org/rfc/rfc7015#section-3. What I like to highlight is 
that in IPFIX supports an inactice timeout window. This allows the data export 
to be exported as quickly as possibly without waiting to finish the active 
timeout window.

Therefore using aggregation depends on the use case, the objective. Speaking 
for a network operator with a large scale Network Telemetry pipeline one of the 
key objectives is to have a wide view across the network while minimizing the 
amount of data as much and as early in the pipeline as possible. For automated 
traffic verification of several thousands of L3 VPN's a highly aggregated data 
set makes more sense then when troubleshooting of a particular customer flow 
across the network is needed. Here cardinality counts. Therefore we use with 
RFC7015 a two step data aggregation concept. One where the aggregation is 
performed on the network node without loosing cardinality. Where at 
data-collection through replication a second aggregation is performed where 
cardinality is reduced to a minimum. Allowing latency queries on the data set.

Looking forward to your comments.

Best wishes
Thomas

From: li_zhenqi...@hotmail.com 

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] Conclusion//RE: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Thomas.Graf]

Dear Tianran,

Thanks a lot. We submitted draft-opsawg-ipfix-on-path-telemetry-00 and awaiting 
your approval.

We addressed the working group feedback in -01 version and will submit it right 
after.

Best wishes
Thomas

From: Tianran Zhou 
Sent: Wednesday, January 18, 2023 4:39 AM
To: opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: Conclusion//RE: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi WG,

This mail we conclude the adoption call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
It's cross reviewed by IPPM.
We received reasonable sufficient supports from both WGs. The discussion moved 
well.
We also collected all the IPR responses from the authors.
The working group will adopt this work.
The authors please submit the draft to datatracker with only the name changed 
to draft-ietf-opsawg-**.
And the authors please revise the document based on the discussions during the 
adoption call in the following update.

Cheers,
Tianran (as co-chair)

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday, December 22, 2022 10:26 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)


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

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

[Thomas.Graf]

Dear Joe,

My appology. Sure! Just submited with the correct name.

Best wishes
Thomas


From: Joe Clarke (jclarke) 
Sent: Thursday, January 19, 2023 6:40 PM
To: Graf Thomas, INI-NET-VNC-HCS ; 
zhoutian...@huawei.com; opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: Re: Conclusion//RE: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Thanks, Thomas.  However, there is an issue with your name.  You've used 
draft-opsawg-ipfix-on-path-telemetry.  It needs to be 
draft-ietf-opsawg-on-path-telemetry.  I will cancel this submission.  Can you 
resubmit with the correct name?

Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of thomas.g...@swisscom.com 
mailto:thomas.g...@swisscom.com>>
Date: Thursday, January 19, 2023 at 12:34
To: zhoutian...@huawei.com 
mailto:zhoutian...@huawei.com>>, 
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: [OPSAWG] Conclusion//RE: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01
Dear Tianran,

Thanks a lot. We submitted draft-opsawg-ipfix-on-path-telemetry-00 and awaiting 
your approval.

We addressed the working group feedback in -01 version and will submit it right 
after.

Best wishes
Thomas

From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Wednesday, January 18, 2023 4:39 AM
To: opsawg@ietf.org
Cc: 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: Conclusion//RE: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi WG,

This mail we conclude the adoption call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
It's cross reviewed by IPPM.
We received reasonable sufficient supports from both WGs. The discussion moved 
well.
We also collected all the IPR responses from the authors.
The working group will adopt this work.
The authors please submit the draft to datatracker with only the name changed 
to draft-ietf-opsawg-**.
And the authors please revise the document based on the discussions during the 
adoption call in the following update.

Cheers,
Tianran (as co-chair)

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday, December 22, 2022 10:26 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)


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

Re: [OPSAWG] CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element

[Thomas.Graf]

Dear opsawg,

I support the adoption and think draft-boucla-opsawg-ipfix-fixes should follow 
the adoption call next as well. Both are very valuable to keep the IPFIX 
registry up to date.

I agree with the author that IE6 tcpControlBits should mirror the TCP header 
flags registry 
(https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-header-flags).

With this update network operators understand when packets are being observed 
with bit 7 set which application in the network should be upgraded to reflect 
the change being introduced with RFC 8311.

I suggest in the introduction to take the angle of correct observability vs. 
TCP protocol interoperability to describe the motivation.

Best wishes
Thomas

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Tuesday, January 17, 2023 5:25 PM
To: opsawg@ietf.org
Subject: [OPSAWG] CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow 
Information Export (IPFIX) Information Element

Happy new year, all.  One of the AIs that slipped through the cracks coming out 
of 115 was a call for adoption for draft-boucadair-opsawg-rfc7125-update.   One 
of the asks of Med at 115 was to look at what else might need to be done from 
an IE registry standpoint.  He replied on-list to that a while ago:

"Yes, I had a discussion with Benoît during the IETF meeting to see how to 
handle this. We agreed to proceed with at least two documents:

  *   draft-boucadair-opsawg-rfc7125-update to update the TCP IPFIX RFC.
  *   Edit a second draft to "clean" other entries in registry. This document 
is intended to include only simple fixes and which do not require updating 
existing RFCs. The candidate list of these proposed fixes can be seen at 
https://boucadair.github.io/simple-ipfix-fixes/draft-boucla-opsawg-ipfix-fixes.html.
 New IEs, if needed, will be moved to a separate document. simple-ipfix-fixes 
may or may not be published as an RFC."

So, let this serve as a two-week call for adoption for the existing 
draft-boucadair-opsawg-rfc7125-update document.  Please reply on-list with your 
comments, support, or dissent by January 31, 2023.

Thanks.

Joe


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

[OPSAWG] FW: New Version Notification for draft-ietf-opsawg-ipfix-on-path-telemetry-01.txt

[Thomas.Graf]

Dear OPSAWG and IPPM working group,

Thanks a lot for the comments during the adoption call. We updated the document 
accordingly. 

Here in brief the differences to the previous version:

- Extended the introduction and the terminology section with performance 
registry relevant information's.
- Corrected some small nits in the performance registry sections.
- Increased IPFIX entity data type sizes based on implementation tests results.
- Corrected IPFIX entity data type semantic.
- Introduced section 7.3. Describing how IPFIX reduced-size encoding is 
applicable.
- Updated section 7.4 according input from Greg Mirsky. Detailing IOAM 
application.
- Removed nanosecond granularity

Looking forward to comments and feedback.

Best wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Thursday, February 16, 2023 1:59 PM
To: Alex Feng ; Alex Huang Feng 
; Benoit Claise ; Graf 
Thomas, INI-NET-VNC-HCS 
Subject: New Version Notification for 
draft-ietf-opsawg-ipfix-on-path-telemetry-01.txt


A new version of I-D, draft-ietf-opsawg-ipfix-on-path-telemetry-01.txt
has been successfully submitted by Thomas Graf and posted to the IETF 
repository.

Name:   draft-ietf-opsawg-ipfix-on-path-telemetry
Revision:   01
Title:  Export of On-Path Delay in IPFIX
Document date:  2023-02-16
Group:  opsawg
Pages:  22
URL:   
https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-on-path-telemetry-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-on-path-telemetry-01

Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   information elements to expose the On-Path Telemetry measured delay
   on the IOAM transit and decapsulation nodes.


  


The IETF Secretariat



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