Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Thomas.Graf]

Dear OPSAWG,

I have read the document and support the adoption in OPSAWG. A OAM terminology 
is much needed.

Best wishes
Thomas

-Original Message-
From: OPSAWG  On Behalf Of Henk Birkholz
Sent: Wednesday, April 10, 2024 1:06 PM
To: OPSAWG 
Subject: [OPSAWG]  WG Adoption Call for 
draft-pignataro-opsawg-oam-whaaat-question-mark-03


Be aware: This is an external email.



Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-ques
> tion-mark-03.html

ending on Thursday, May 2nd.

As a reminder, this I-D summarizes how the term "Operations, Administration, 
and Maintenance" (OAM) is used currently & historically in the IETF and intends 
to consolidate unambiguous and protocol agnostic terminology for OAM. The 
summary includes descriptions of narrower semantics introduced by added 
qualifications the term OAM and a list of common capabilities that can be found 
in nodes processing OAM packets.

The chairs acknowledge a positive poll result at IETF119, but there has not 
been much discussion on the list yet. We would like to gather feedback from the 
WG if there is interest to further contribute and review. As a potential 
enabler for discussions, this call will last three weeks.

Please reply with your support and especially any substantive comments you may 
have.


For the OPSAWG co-chairs,

Henk

___
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] FW: [netconf] Adoption call for notif-yang-04

[Thomas.Graf]

Dear NMOP and OPSAWG working group,

At IETF 119, I introduced to NMOP below informational overview document. 
Describing the YANG-Push integration into Apache Kafka.

https://datatracker.ietf.org/doc/html/draft-netana-nmop-yang-kafka-integration
https://datatracker.ietf.org/meeting/119/materials/slides-119-nmop-an-architecture-for-yang-push-to-apache-kafka-integration-00.pdf

At the NETCONF working an adoption call is currently running on 
https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-04. The 
document solves the problem that RFC 5277 defines the netconf notification 
header in XML only. Since YANG Push (RFC 8641) is based on netconf notification 
defined in RFC 5277, current YANG-Push messages can't be validated based on 
schema compliance. This document solves that problem.

If you consider this as important to enable YANG-Push industry adoption I 
suggest to reply your support on the netconf mailing list.

Best wishes
Thomas

-Original Message-
From: netconf  On Behalf Of Kent Watsen
Sent: Sunday, April 7, 2024 12:14 AM
To: netc...@ietf.org
Subject: [netconf] Adoption call for notif-yang-04


Be aware: This is an external email.



NETCONF WG,

This message starts a two week poll on adopting the following document:

YANG model for NETCONF Event Notifications
https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-04

The poll ends April 20.

Please send email to the list indicating "yes/support” or "no/do not support".  
If indicating no, please state your reservations with the document.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.

No IPR is known for this document:  
https://mailarchive.ietf.org/arch/msg/netconf/oQVZ6Pf_novNfMB4RsnDxQibHpM/

PS: this document received strong support before, being very focused, providing 
just a module enabling validation of YANG “notification” messages.

Kent and Per (as co-chairs)





___
netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
--- Begin Message ---

Be aware: This is an external email.



NETCONF WG,

This message starts a two week poll on adopting the following document:

YANG model for NETCONF Event Notifications
https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-04

The poll ends April 20.

Please send email to the list indicating "yes/support” or "no/do not support".  
If indicating no, please state your reservations with the document.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.

No IPR is known for this document:  
https://mailarchive.ietf.org/arch/msg/netconf/oQVZ6Pf_novNfMB4RsnDxQibHpM/

PS: this document received strong support before, being very focused, providing 
just a module enabling validation of YANG “notification” messages.

Kent and Per (as co-chairs)





___
netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
--- End Message ---


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

Re: [OPSAWG] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

[Thomas.Graf]

Dear Joe and Med,


I updated both shepherd writeup's accordingly and adjusted to: that consensus 
for introducing a new data type unsigned256 has been achieved.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/shepherdwriteup/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/shepherdwriteup/

I confirm that there is no more blocking points for moving forward to IESG.

Best wishes
Thomas

From: OPSAWG  On Behalf Of Joe Clarke (jclarke)
Sent: Tuesday, April 2, 2024 5:41 PM
To: mohamed.boucad...@orange.com; Aitken, Paul ; 
opsawg@ietf.org
Cc: ip...@ietf.org
Subject: Re: [OPSAWG] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX 
documents


Be aware: This is an external email.


As a co-chair, I'm willing to call consensus on this as there hasn't been any 
other replies on this thread after Med asserted the reasoning for sticking with 
unsigned256.

I would ask Thomas as shepherd to note this in the write-up, and we can proceed 
to IESG as I believe all other comments from reviews have now been addressed.

Joe

From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Date: Tuesday, April 2, 2024 at 11:04
To: Aitken, Paul mailto:pait...@ciena.com>>, Joe Clarke 
(jclarke) mailto:jcla...@cisco.com>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>
Cc: ip...@ietf.org 
mailto:ip...@ietf.org>>
Subject: RE: Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents
Hi all,

As indicated in IETF#119, we suggest to tag this issue as closed and proceed 
with the publication of the current versions of the various I-Ds.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : vendredi 23 février 2024 15:55
À : 'Aitken, Paul' mailto:pait...@ciena.com>>; 'Joe Clarke 
(jclarke)' 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 'opsawg@ietf.org' mailto:opsawg@ietf.org>>
Cc : 'ip...@ietf.org' mailto:ip...@ietf.org>>
Objet : RE: Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul,

Unless I'm mistaken, I didn't see any follow-up to this issue.

May I consider this point as closed? Thanks.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 23 janvier 2024 14:23
À : 'Aitken, Paul' mailto:pait...@ciena.com>>; Aitken, Paul 
mailto:paitken=40ciena@dmarc.ietf.org>>;
 Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org
Cc : t...@ietf.org; 
ts...@ietf.org; 6...@ietf.org; 
ip...@ietf.org
Objet : Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul,

> It is consistent but wrong, as the numeric value of these fields is 
> meaningless. Bitfields with flags semantics don't have a meaningful 
> "unsigned" value.

You raised this comment for both TCP/UDP specs.

As I mentioned in the previous message, all existing IEs of type flags are 
using an unsigned type. Also, please note that rfc7012#section-3.2.5 says the 
followings:

   "flags" is an integral value that represents a set of bit fields.
   Logical operations are appropriate on such values, but other
   mathematical operations are not.  Flags MUST always be of an unsigned
   data type.

And rfc7012#section-3:

   Abstract data types unsigned8, unsigned16, unsigned32, unsigned64,
   signed8, signed16, signed32, and signed64 are integral data types.
   As described in Section 3.2, their data type semantics can be further

   specified, for example, by 'totalCounter', 'deltaCounter',
   'identifier', or 'flags'.
 ^^

I quite don't understand why we need to define Bitfields rather than leveraging 
on the approach followed so far in IPFIX.

Cheers,
Med

De : Aitken, Paul mailto:pait...@ciena.com>>
Envoyé : lundi 22 janvier 2024 11:49
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; Aitken, 
Paul 
mailto:paitken=40ciena@dmarc.ietf.org>>;
 Joe Clarke (jclarke) 
mailto:jclarke=40cisco@dmarc.ietf.org>>;
 opsawg@ietf.org
Cc : t...@ietf.org; 
ts...@ietf.org; 6...@ietf.org; 
ip...@ietf.org
Objet : Re: Re: [IPFIX] WG LC: IPFIX documents

Med,
   The IE specified in Section 4.1 uses the new abstract data type
   defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

The unsigned256 type? It makes more sense to introduce a bitfield type.
[Med] I think the use of unsigned256 is consistent with the current use in IP 
Flow Information Export (IPFIX) Entities (iana.org) 
[iana.org]
 (where unsigned8, unsigned16, unsigned32, and unsigned64 are used for IEs 
having data 

Re: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00

[Thomas.Graf]

Dear Xiao,

Correct. Obviously this will be exported per flow and the interface entities 
have to be key fields as the flow entities as well.

Best wishes
Thomas

On 3 Apr 2024, at 04:54, xiao.m...@zte.com.cn wrote:



Be aware: This is an external email.



Correcting the email address i...@ietf.org.


Hi Thomas,


If I understand you correctly, you mean the IE exporter can use 
ingressInterface/egressInterface to indicate LAG port and 
ingressPhysicalInterface/egressPhysicalInterface to indicate LAG member port, 
so the receiver can deduce the implicit meanings of them if they have different 
values, is that right?


Cheers,

Xiao Min

Original
From: thomas.g...@swisscom.com 
To: 肖敏10093570;draft-gfz-opsawg-ipfix-alt-m...@ietf.org 
;
Cc: opsawg@ietf.org ;'i...@ietf.org <'i...@ietf.org>;
Date: 2024年04月02日 19:32
Subject: RE: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00
Dear Xiao,

I agree that the description and the additional information does not provide 
information to distinguish between

ingressInterface, egressInterface

and

ingressPhysicalInterface, egressPhysicalInterface

However from an implementation perspective I have observed that in all cases 
ingressInterface and egressInterface refer to logical and 
ingressPhysicalInterface and egressPhysicalInterface to physical interfaces.

Where ingressInterfaceType and egressInterfaceType, which references to 
https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib, is describing 
what type of interface it is.

I would expect in a LAG configuration that the lag interface is 
ingressInterface resp. egressInterface and the member interfaces are 
ingressPhysicalInterface resp. egressPhysicalInterface.

I hope that helps.

Best wishes
Thomas

From: OPSAWG  On Behalf Of xiao.m...@zte.com.cn
Sent: Tuesday, April 2, 2024 10:58 AM
To: draft-gfz-opsawg-ipfix-alt-m...@ietf.org
Cc: opsawg@ietf.org; 'i...@ietf.org
Subject: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00



Be aware: This is an external email.



Hi authors,



At the request of Giuseppe, I had a read on draft-gfz-opsawg-ipfix-alt-mark-00.

There are IPFIX IEs ingressInterface, egressInterface, ingressPhysicalInterface 
and egressPhysicalInterface, is there an IE indicating a LAG interface?



Best Regards,

Xiao Min



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

Re: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00

[Thomas.Graf]

Dear Xiao,

I agree that the description and the additional information does not provide 
information to distinguish between

ingressInterface, egressInterface

and

ingressPhysicalInterface, egressPhysicalInterface

However from an implementation perspective I have observed that in all cases 
ingressInterface and egressInterface refer to logical and 
ingressPhysicalInterface and egressPhysicalInterface to physical interfaces.

Where ingressInterfaceType and egressInterfaceType, which references to 
https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib, is describing 
what type of interface it is.

I would expect in a LAG configuration that the lag interface is 
ingressInterface resp. egressInterface and the member interfaces are 
ingressPhysicalInterface resp. egressPhysicalInterface.

I hope that helps.

Best wishes
Thomas

From: OPSAWG  On Behalf Of xiao.m...@zte.com.cn
Sent: Tuesday, April 2, 2024 10:58 AM
To: draft-gfz-opsawg-ipfix-alt-m...@ietf.org
Cc: opsawg@ietf.org; 'i...@ietf.org
Subject: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00


Be aware: This is an external email.



Hi authors,



At the request of Giuseppe, I had a read on draft-gfz-opsawg-ipfix-alt-mark-00.

There are IPFIX IEs ingressInterface, egressInterface, ingressPhysicalInterface 
and egressPhysicalInterface, is there an IE indicating a LAG interface?



Best Regards,

Xiao Min


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

Re: [OPSAWG] draft-spiegel-ippm-ioam-rawexport

[Thomas.Graf]

Dear Reshad,

I am refering to the IOAM data fields described in 
https://datatracker.ietf.org/doc/html/rfc9197#section-4. So that those entities 
can be decomposed on the network node and not at the data collection. Depending 
on IPFIX configuration, some of the dimensions will be key fields, some of them 
not. Depending on keying, IPFIX will aggregate the data on the network node 
before exporting to the data collection. That increases scalability of the 
solution. See 
https://datatracker.ietf.org/doc/html/draft-gfz-opsawg-ipfix-alt-mark as 
example.

Best wishes
Thomas

From: Reshad Rahman 
Sent: Tuesday, March 19, 2024 12:46 PM
To: i...@ietf.org; opsawg@ietf.org; justin.iur...@uliege.be; Graf Thomas, 
INI-NET-VNC-HCS 
Subject: Re: [OPSAWG] draft-spiegel-ippm-ioam-rawexport


Be aware: This is an external email.


Hi Thomas,

By "IOAM dimension fields", are you referring to fields such as ingress/egress 
intf id etc in IOAM data? And you are requesting for these fields to be 
included to facilitate aggregation by another entity (e.g the aggregating 
mediator in RFC7015)? i.e you are not requesting for the IOAM node in this 
document (i.e. the exporter) to export aggregated data?

If I understood correctly, then I agree.

Regards,
Reshad.

On Monday, March 18, 2024, 08:42:41 PM EDT, 
thomas.g...@swisscom.com 
mailto:thomas.g...@swisscom.com>> wrote:



Dear Justin, Dear OPSAWG and IPPM working groups



Thanks a lot for the presentation at IPPM. I believe that this work needs 
further refinement by defining also IPFIX entities for IOAM which allow a 
decomposition of each IOAM dimension fields, thus enabling IPFIX Flow 
Aggregation as described in RFC 7015 which is a requirement to scale out for 
IOAM DEX and Trace Option Type. I believe this should be performed after the 
working group adoption and me should move forward quickly since IOAM is now 
getting implemented by vendors and applied by operators.



While shepherding IPFIX at OPSAWG, I noticed that most discussions where around 
choosing the right data type and aligning with the IPFIX registry. Not so much 
about exposing the right dimensions from the data plane.



draft-ietf-opsawg-ipfix-on-path-telemetry is already adopted and well 
progressed at OPSAWG. I suggest that draft-spiegel-ippm-ioam-rawexport is being 
adopted together with draft-gfz-opsawg-ipfix-alt-mark. With that we are 
covering both Hybrid Type options developed at IPPM.



In order to pool the IPFIX entity definitions, I believe OPSAWG would be the 
best place to move with draft-spiegel-ippm-ioam-rawexport forward.



I would appreciate feedback from IPPM and OPSAWG wherever they share my opinion 
or not.



Best wishes

Thomas


___
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-spiegel-ippm-ioam-rawexport

[Thomas.Graf]

Dear Justin, Dear OPSAWG and IPPM working groups

Thanks a lot for the presentation at IPPM. I believe that this work needs 
further refinement by defining also IPFIX entities for IOAM which allow a 
decomposition of each IOAM dimension fields, thus enabling IPFIX Flow 
Aggregation as described in RFC 7015 which is a requirement to scale out for 
IOAM DEX and Trace Option Type. I believe this should be performed after the 
working group adoption and me should move forward quickly since IOAM is now 
getting implemented by vendors and applied by operators.

While shepherding IPFIX at OPSAWG, I noticed that most discussions where around 
choosing the right data type and aligning with the IPFIX registry. Not so much 
about exposing the right dimensions from the data plane.

draft-ietf-opsawg-ipfix-on-path-telemetry is already adopted and well 
progressed at OPSAWG. I suggest that draft-spiegel-ippm-ioam-rawexport is being 
adopted together with draft-gfz-opsawg-ipfix-alt-mark. With that we are 
covering both Hybrid Type options developed at IPPM.

In order to pool the IPFIX entity definitions, I believe OPSAWG would be the 
best place to move with draft-spiegel-ippm-ioam-rawexport forward.

I would appreciate feedback from IPPM and OPSAWG wherever they share my opinion 
or not.

Best wishes
Thomas



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

[OPSAWG] draft-pignataro-opsawg-oam-whaaat-question-mark

[Thomas.Graf]

Dear Carlos and Adrian,

As the author of draft-ietf-opsawg-ipfix-on-path-telemetry, I care and value 
that you are defining OAM terminology. This is much needed. Count me on the 
list of people who misused the term inband previously.

I would appreciate of you could add also OAM node type. As an example in RFC 
9398 for IOAM the following types are defined

IOAM encapsulation node
IOAM transit node
IOAM decapsulation node

It would be very useful to have an OAM protocol agnostic terminology.

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]  IPR Call for draft-feng-opsawg-incident-management-04

[Thomas.Graf]

Dear OPSAWG,

As a co-author, I am not aware of any IPR.

Best wishes
Thomas

-Original Message-
From: Henk Birkholz  
Sent: Thursday, February 8, 2024 5:00 PM
To: OPSAWG ; draft-feng-opsawg-incident-managem...@ietf.org
Subject:  IPR Call for draft-feng-opsawg-incident-management-04


Be aware: This is an external email.



Dear authors and contributors,

as a part of the adoption process, the chairs would also like to issue a first 
IPR call on the content of adoption candidates (there will also be a second IPR 
call after successful WGLC).

Please respond on-list as to whether or not you are aware of any IPR that 
pertains to draft-feng-opsawg-incident-management-04.

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


For the OPAWG co-chairs,

Henk


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-fixes-05 shepherd review

[Thomas.Graf]

Dear Med and Benoit,

Thanks a lot. The document is straight forward and is a very valuable 
contribution to the Internet community since it updates existing IPFIX entities 
to make them consistent, which is for IPFIX data collections which obtain the 
information from the IPFIX IANA registry especially relevant, have references 
to other registries instead of re-defining them eases the update procedures in 
the future and last but not least updating some of the descriptions due to 
shortcomings for more clarity.

I have reviewed the document and wrote the initial shepherd review. 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/shepherdwriteup/

I am looking forward for the feedback from the OPSAWG mailing list wherever 
ipv6ExtensionHeaders and tcpOptions in favor of ipv6ExtensionHeadersFull and 
tcpOptionsFull defined in draft-ietf-opsawg-ipfix-tcpo-v6eh. Depending on 
feedback on the mailing list, a poll at the IETF 119 maybe could be useful as 
well.

ipv6ExtensionHeaders has been adopted by network vendors widely. Where 
tcpOptions appears to be, 
https://mailarchive.ietf.org/arch/msg/opsawg/gaJ9-A6i3Z4grgHT86OUym_DAqA/, 
merely used to its ambiguity.

I therefore suggest to deprecate tcpOptions. I suggest also 
ipv6ExtensionHeaders to deprecate because not all observed extension headers in 
a Flow maybe export because of a hardware or software limit as described in 
Section 4.1.1 of this document and addressed with ipv6ExtensionHeadersLimit.

As a contributor, I like also to confirm the authors opinions that 
forwardingStatus should be unsigned32 instead of unsigned8 not only because RFC 
7270 specifies forwardingStatus as unsigned32, but it reserves 3 bytes. We have 
with draft-opsawg-evans-discardmodel and draft-mvmd-opsawg-ipfix-fwd-exceptions 
two documents showing interest to describe the forwarding behavior in IPFIX. We 
have on OPSAWG mailing list 
https://mailarchive.ietf.org/arch/browse/opsawg/?q=draft-mvmd-opsawg-ipfix-fwd-exceptions
 various feedback that an update, extension of forwardingStatus would be 
preferred instead of introducing a new IPFIX entity.

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-tcpo-v6eh-08 shepherd review

[Thomas.Graf]

Dear Med,

That was a mistake by me. The idnits showed nothing. All clear. Will update the 
shepherd review in the next iteration.

Bets wishes
Thomas

-Original Message-
From: mohamed.boucad...@orange.com  
Sent: Tuesday, January 23, 2024 11:02 AM
To: Graf Thomas, INI-NET-VNC-HCS ; 
draft-ietf-opsawg-ipfix-tcpo-v6eh.auth...@ietf.org
Cc: draft-ietf-opsawg-ipfix-tcpo-v6eh.cha...@ietf.org; opsawg@ietf.org
Subject: RE: draft-ietf-opsawg-ipfix-tcpo-v6eh-08 shepherd review


Be aware: This is an external email.



Hi Thomas,

Thank you  much for preparing the writeup.

I'm not sure I received the comments mentioned in point 14 of the writeup, 
though. I suspect this is because of the issues I'm having with the IETF 
aliases. Please forward me offline these comments. Thanks and apologies for the 
inconvenience.

Cheers,
Med

> -Message d'origine-
> De : thomas.g...@swisscom.com  Envoyé : 
> dimanche 21 janvier 2024 09:45 À : 
> draft-ietf-opsawg-ipfix-tcpo-v6eh.auth...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh.cha...@ietf.org;
> opsawg@ietf.org
> Objet : draft-ietf-opsawg-ipfix-tcpo-v6eh-08 shepherd review
>
> Dear Med and Benoit,
>
> Thanks a lot. The document is very well written and straight forward.
> As shared previously during the working group, I believe this document 
> is very valuable to network operators since it addresses current 
> issues in the observation of IPv6 headers and TCP options.
>
> I have reviewed the document and wrote the initial shepherd review 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-tcpo-
> v6eh%2Fshepherdwriteup%2F=05%7C02%7Cmohamed.boucadair%40orange.co
> m%7C70d60422fea24fc37be708dc1a5d4799%7C90c7a20af34b40bfbc48b9253b6f5d2
> 0%7C0%7C0%7C638414235128846317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> ata=eFdqPjtvSpB7Z8Q4iG6ORBrX10TFrwraz3d1yJRtsbs%3D=0

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] A new draft on Network Incident Terminology

[Thomas.Graf]

Dear Adrian and Davis,

Nice! Thanks a lot for this document. I think it will help future documents to 
chose the correct terms and language.

I reviewed and have some minor input.

Regarding

Change: A modification to the state of a resource in time.

I believe it not only applies to a resource but also a network entity such a 
network path or a NRLI. Not only applying to management but also to control 
plane. From a Network Anomaly Detection perspective it might even stretch to an 
outlier, including also forwarding plane. See 
https://datatracker.ietf.org/doc/html/draft-netana-nmop-network-anomaly-semantics-00#section-2.

Regarding

Incident: An event that has a negative effect that is not as required/desired.

For me an incident is one or more symptoms 
(https://datatracker.ietf.org/doc/html/draft-netana-nmop-network-anomaly-semantics-00#section-4).
 As you described, an event can be positive or negative. One or more negative 
event or measurement can lead into a symptom. See also 
https://datatracker.ietf.org/doc/html/rfc9418#section-2.

Regarding Problem definition. I suggest to go towards the an objective or 
intend (https://datatracker.ietf.org/doc/html/rfc9315) is no longer fulfilled.

Best wishes
Thomas

From: Adrian Farrel 
Sent: Thursday, January 18, 2024 4:15 PM
To: ne...@ietf.org
Cc: draft-opsawg-evans-discardmo...@ietf.org; 
draft-netana-opsawg-nmrg-network-anomaly-semant...@ietf.org; 
draft-feng-opsawg-incident-managem...@ietf.org; n...@irtf.org; 'Davis, Nigel' 
; 'Ops Area WG' 
Subject: A new draft on Network Incident Terminology


Be aware: This is an external email.


All,

At the side meeting in Prague, Nigel and I committed to putting together a 
first stab at a terminology set for network incidents. We have now posted a -00 
draft.

The intentions here are:

  *   To provide a starting point for discussions of the terminology
  *   To give something that can be edited and made correct
  *   To end up with a set of terms that we can agree upon and use in all of 
our work

We would be shocked if we have got this right on our first pass. We are sure 
that there will be many opinions, and we welcome suggestions for edits and 
proposals for changes.

Although this email is circulated quite widely (including OPSAWG, NMRG, and 
NMOP (still masquerading as NETMO)), we believe that this work will end up in 
NMOP (if the WG is ever formed) and so we suggest that all responses and 
discussions be directed exclusively to the NETMO mailing list.

Looking forward to a fruitful debate,

Nigel and Adrian

===


Internet-Draft draft-davis-nmop-incident-terminology-00.txt is now available.



   Title:   Some Key Terms for Incident Management

   Authors: Nigel Davis

Adrian Farrel

   Name:draft-davis-nmop-incident-terminology-00.txt

   Pages:   5

   Dates:   2024-01-18



Abstract:



   This document sets out some key terms that are fundamental to a

   common understanding of Incident Management.



   The purpose of this document is to bring clarity to discussions and

   other work related to Incident Management in particular YANG models

   and management protocols that report, make visible, or manage

   incidents.



The IETF datatracker status page for this Internet-Draft is:

https://datatracker.ietf.org/doc/draft-davis-nmop-incident-terminology/



There is also an HTML version available at:

https://www.ietf.org/archive/id/draft-davis-nmop-incident-terminology-00.html



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-tcpo-v6eh-08 shepherd review

[Thomas.Graf]

Dear Med and Benoit,

Thanks a lot. The document is very well written and straight forward. As shared 
previously during the working group, I believe this document is very valuable 
to network operators since it addresses current issues in the observation of 
IPv6 headers and TCP options.

I have reviewed the document and wrote the initial shepherd review 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/shepherdwriteup/.

I agree with the points from the IPFIX doctor and the Transport area in regards 
to the comments made to the data type choice for tcpOptionsFull, 
tcpSharedOptionExID16 and tcpSharedOptionExID32. Mirroring my concerns 
previously shared in the review of draft-ietf-opsawg-tsvwg-udp-ipfix with 
udpExpOptionExID and udpUnsafeExpOptionExID.

I suggest to change the sentence from "Because some of these limitations cannot 
be addressed" to "Because some of these issues cannot be addressed" which is 
used in several occasions in the document.

I suggest in section 3.1, to extend the paragraph

Regarding "exported in separate ipv6ExtensionHeadersFull IEs" described in 
Section 3.1, I assume this refers to Section 8 of RFC 7011 
(https://datatracker.ietf.org/doc/html/rfc7011#section-8) where

   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.

Is described. If yes, I suggest to reference. If not, to clarify the meaning 
within the document.

Here are some nits I found.

replace headerss with headers
replace octers with octets

Otherwise all perfect.

Best wishes
Thomas





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-netana-nmop-network-anomaly-semantics-00.txt

[Thomas.Graf]

Dear OPSAWG,

The Semantic Metadata Annotation for Network Anomaly Detection document was 
previously presented at IEPG and NMRG

https://datatracker.ietf.org/meeting/118/materials/slides-118-nmrg-semantic-metadata-annotation-for-network-anomaly-detection-01.pdf
https://youtu.be/zC-R_fWUUEA?si=oAvc66agikiZtilf=849

and has been updated. We added some more control plane symptoms based on 
network anomaly detection incident postmortems in the last 3 months and did 
some minor editorial changes.

Here the diff: 
https://author-tools.ietf.org/diff?url_1=https://www.ietf.org/archive/id/draft-netana-opsawg-nmrg-network-anomaly-semantics-01.txt_2=https://www.ietf.org/archive/id/draft-netana-nmop-network-anomaly-semantics-00.txt

We are looking forward to feedback and comments.

Best wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Sunday, January 21, 2024 7:39 AM
To: Alex Feng ; Alex Huang Feng 
; Antonio Roberto ; 
Graf Thomas, INI-NET-VNC-HCS ; Vincenzo Riccobene 
; Du Wanting, INI-NET-VNC-HCS 

Subject: New Version Notification for 
draft-netana-nmop-network-anomaly-semantics-00.txt


Be aware: This is an external email.



A new version of Internet-Draft
draft-netana-nmop-network-anomaly-semantics-00.txt has been successfully 
submitted by Thomas Graf and posted to the IETF repository.

Name: draft-netana-nmop-network-anomaly-semantics
Revision: 00
Title:Semantic Metadata Annotation for Network Anomaly Detection
Date: 2024-01-21
Group:Individual Submission
Pages:15
URL:  
https://www.ietf.org/archive/id/draft-netana-nmop-network-anomaly-semantics-00.txt
Status:   
https://datatracker.ietf.org/doc/draft-netana-nmop-network-anomaly-semantics/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-netana-nmop-network-anomaly-semantics


Abstract:

   This document explains why and how semantic metadata annotation helps
   to test, validate and compare outlier detection, supports supervised
   and semi-supervised machine learning development, enables data
   exchange among network operators, vendors and academia and make
   anomalies for humans apprehensible.  The proposed semantics uniforms
   the network anomaly data exchange between and among operators and
   vendors to improve their network outlier detection systems.



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] draft-ietf-opsawg-tsvwg-udp-ipfix-03 shepherd review

[Thomas.Graf]

Dear Med,

Thanks a lot for addressing all my points.

I updated and submitted my shepherd review: 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/shepherdwriteup/

I agree with your assessment on Joe's comment that having a figure on udp 
options packet header and short description on SAFE and UNSAFE options helps 
the reader to understand the context. It is clear that they are not defined 
within this document.


I will track the discussion on unsigned256 vs bitfield and update the shepherd 
review accordingly.



Best wishes

Thomas

From: mohamed.boucad...@orange.com 
Sent: Monday, January 15, 2024 11:32 AM
To: Graf Thomas, INI-NET-VNC-HCS ; 
draft-ietf-opsawg-tsvwg-udp-ipfix.auth...@ietf.org; 
draft-ietf-opsawg-tsvwg-udp-ipfix.cha...@ietf.org
Subject: RE: draft-ietf-opsawg-tsvwg-udp-ipfix-03 shepherd review


Be aware: This is an external email.


Hi Thomas, all,

Let's me first wish you a Happy New Year !

Thank you for the careful shepherd review. A new version that addresses the 
review is now online: 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/05/. Please 
note that I didn't change to unsigned64 because in theory we need to cover up 
to 256 bits to map the full options range.

Cheers,
Med

De : thomas.g...@swisscom.com 
mailto:thomas.g...@swisscom.com>>
Envoyé : samedi 13 janvier 2024 12:17
À : 
draft-ietf-opsawg-tsvwg-udp-ipfix.auth...@ietf.org;
 
draft-ietf-opsawg-tsvwg-udp-ipfix.cha...@ietf.org
Objet : draft-ietf-opsawg-tsvwg-udp-ipfix-03 shepherd review

Dear Joe, Tianran and Henk,

Thanks a lot for entrusting me. I have done the first shepherd review of the 3 
IPFIX drafts. Since this is my first Shepherd review, please have a brief look 
before submitting to the data tracker.

One clarification question. There is a OPS area review pending, the review from 
the Internet and Transport area needs to be addressed by the authors, I suggest 
to have a review from the IPFIX experts as well as described in point 6 and I 
have some minor editorial remarks (see below). Once all done I believe we are 
ready to move forward to the IESG with this document. Should I wait with the 
Shepherd submission or submit it now and update it later as we progress?


Dear Med and Tirumaleswar,

Thanks a lot. The document is very well written and straight forward.

I have reviewed the document. I agree with the feedback from the Transport area 
that the data type of udpOptions should be unsigned64 instead of unsigned since 
https://www.rfc-editor.org/rfc/rfc7011#section-6.2 describes that unsigned64 
can be reduced-size encoded in unsigned32. I suggest to change the wording in 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tsvwg-udp-ipfix-03#section-4.1
 from "The encoding specified in" to "The reduced-size encoding specified in" 
to make the meaning of the reference more clear.

Regarding the abstract data type and the data type semantics of 
udpExpOptionExID and udpUnsafeExpOptionExID. I am unsure wherever octetArray 
with identifier fits or not. I tend to agree with your assessment.

I reviewed

https://datatracker.ietf.org/doc/html/rfc7012#section-3.1.13
https://datatracker.ietf.org/doc/html/rfc7012#section-3.2.4
https://datatracker.ietf.org/doc/html/rfc7012#section-3.2.5

and also checked

https://www.iana.org/assignments/ipfix/ipfix.xhtml

where I only found

IE464internalAddressRealm
IE465externalAddressRealm

I understand that flags won't fit according to 
https://datatracker.ietf.org/doc/html/rfc7012#section-3.2.5 due to "represents 
a set of bit fields" versus a single value we have here.

Below are some nits I found.

replace "experiements" with "experiments"
replace "Expermients" with "Experiments"
replace "less-signficant" with "less-significant"

Adjust the following references to draft-ietf-tsvwg-udp-options-28

From
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-23#section-10

To
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-12


From
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-23#section-23

To
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-25


From
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-23#section-8

To
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-10


And below the output from idnits.

Otherwise all perfect. I agree due to the draft-ietf-tsvwg-udp-options 
dependency the content of this document should not be part of 
draft-ietf-opsawg-ipfix-tcpo-v6eh. I will review 
draft-ietf-opsawg-ipfix-tcpo-v6eh next. I like that this document, 
draft-ietf-opsawg-ipfix-tcpo-v6eh and draft-ietf-tsvwg-udp-options is being 
submitted about the same time to IESG. From a network operator perspective, I 
can't ask more to have a new transport 

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Thomas.Graf]

Dear OPSAWG,



I read the document and think it is very valuable for network operators. I like 
that it is defined as information module so later we can see how this would be 
applicable in IPFIX and YANG.



Best wishes

Thomas



-Original Message-
From: OPSAWG  On Behalf Of Henk Birkholz
Sent: Wednesday, January 17, 2024 1:52 PM
To: OPSAWG 
Subject: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02





Be aware: This is an external email.







Dear OPSAWG members,



this email starts a call for Working Group Adoption of



> https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.htm

> l



ending on Wednesday, January 31st.



As a reminder, this I-D describes an information model in support of automated 
network mitigation on what and how to report about unintentional packet 
discards/losses that can have an impact on service level objectives. 
Implementation of the informational model, which could manifest, e.g., via 
NETCONF/YANG, SNMP or IPFIX, is out-of-scope.



The chairs acknowledge feedback to and interest for the topic during the

IETF118 meeting and on the list after afterwards. We would like to gather 
feedback from the WG if there is interest to further contribute and review.



Please reply with your support and especially any substantive comments you may 
have.





For the OPSAWG co-chairs,



Henk



___

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] I-D Action: draft-ietf-opsawg-ipfix-on-path-telemetry-06.txt

[Thomas.Graf]

Dear opsawg,

We updated the document and replaced the references from Path Tracing 
(draft-filsfils-ippm-path-tracing) to Alternate Marking (RFC 9341, RFC 9343, 
draft-ietf-ippm-ioam-deployment, draft- fz-spring-srv6-alt-mark) currently 
under development at IPPM. Describing with IOAM (RFC 9197, 
draft-ietf-ippm-ioam-deployment, draft-ahuang-ippm-dex-timestamp-ext) and 
Alternate Marking two applications.

Since the Path Tracing implementation changed according to section 9.2 from 
draft-filsfils-spring-path-tracing-04 to draft-filsfils-ippm-path-tracing-00, 
this document is no longer applicable since the timestamp changed from a 
Segment Routing Header TLV to the IPv6 destination option header which 
according to Section 4.6 of RFC8200 
(https://datatracker.ietf.org/doc/html/rfc8200#section-4.6) can only be parsed 
at the decapsulation node. Hence it is no longer applicable for postcard based 
on-path delay measurement.

We will approach next the IP Performance Registry experts for a review on the 
document. Especially on the aspect of linking the two registries since RFC 8911 
and RFC 8912.

I would appreciate your review and comments on the mailing list.

Best wishes
Thomas

-Original Message-
From: OPSAWG  On Behalf Of internet-dra...@ietf.org
Sent: Sunday, January 14, 2024 10:15 AM
To: i-d-annou...@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-on-path-telemetry-06.txt


Be aware: This is an external email.



Internet-Draft draft-ietf-opsawg-ipfix-on-path-telemetry-06.txt is now 
available. It is a work item of the Operations and Management Area Working 
Group (OPSAWG) WG of the IETF.

   Title:   Export of On-Path Delay in IPFIX
   Authors: Thomas Graf
Benoit Claise
Alex Huang Feng
   Name:draft-ietf-opsawg-ipfix-on-path-telemetry-06.txt
   Pages:   29
   Dates:   2024-01-14

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 datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-06

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-on-path-telemetry-06

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-tgraf-netconf-notif-sequencing-03, draft-tgraf-netconf-yang-push-observation-time-00

[Thomas.Graf]

Dear netconf,

The following two documents have been updated:


Name: draft-tgraf-netconf-notif-sequencing

Revision: 03

Title:Support of Hostname and Sequencing in YANG Notifications

Date: 2024-01-14

Group:Individual Submission

Pages:10

URL:  
https://www.ietf.org/archive/id/draft-tgraf-netconf-notif-sequencing-03.txt

Status:   https://datatracker.ietf.org/doc/draft-tgraf-netconf-notif-sequencing/

HTMLized: 
https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing

Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-tgraf-netconf-notif-sequencing-03


Title:Support of Network Observation Timestamping in YANG Notifications

Date: 2024-01-14

Group:Individual Submission

Pages:13

URL:  
https://www.ietf.org/archive/id/draft-tgraf-netconf-yang-push-observation-time-00.txt

Status:   
https://datatracker.ietf.org/doc/draft-tgraf-netconf-yang-push-observation-time/

HTMLized: 
https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-yang-push-observation-time


draft-tgraf-netconf-notif-sequencing was presented in IETF 118 and received 
feedback from Jan Lindblad to expand the definition of the sysName object which 
we addressed in this revision. Feedback welcome if this addresses the concern.

In draft-tgraf-netconf-yang-push-observation-time we added a paragraph in the 
intro section describing a common network operator problem when the bucketing 
in a timeseries data base is equally long to the periodic YANG push 
subscription and eventTime is being used for timeseries data base indexing. 
Leading to inconsistent accounting errors in the time series database which is 
being resolved by using the observation-time instead.

I take the liberty to share two documents from the YANG Push to Apache Kafka 
side meeting at IETF 118. Giving the overall picture and the current state.

https://github.com/network-analytics/draft-daisy-kafka-yang-integration/blob/main/draft-daisy-kafka-yang-integration-05.md
https://github.com/network-analytics/draft-daisy-kafka-yang-integration/blob/main/yang-push-workflow-02.pdf

We received comments from the netconf chairs during the netconf sessions and 
also from the community during the side meeting that an IETF document 
describing the overall picture with the references to each draft document 
describing the changes to the netconf notification, YANG push header and the 
YANG library but also to Apache Kafka and its schema registry would be very 
helpful. That document is in the works to be ready for IETF 119.

I would appreciate your review and comments on the mailing list.

Best wishes
Thomas


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-netconf-notif-sequencing-02.txt

[Thomas.Graf]

Dear netconf and opsawg,

In order to align with the new Message Publisher ID terminology in 
draft-ietf-netconf-distributed-notif-08 we updated 
draft-tgraf-netconf-notif-sequencing accordingly. Looking forward to feedback 
from the working group.

Best wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Saturday, October 7, 2023 6:58 AM
To: Alex Feng ; Alex Huang Feng 
; Jean Quilbeuf ; Graf 
Thomas, INI-NET-VNC-HCS 
Subject: New Version Notification for 
draft-tgraf-netconf-notif-sequencing-02.txt

A new version of Internet-Draft draft-tgraf-netconf-notif-sequencing-02.txt
has been successfully submitted by Thomas Graf and posted to the IETF 
repository.

Name: draft-tgraf-netconf-notif-sequencing
Revision: 02
Title:Support of Hostname and Sequencing in YANG Notifications
Date: 2023-10-07
Group:Individual Submission
Pages:10
URL:  
https://www.ietf.org/archive/id/draft-tgraf-netconf-notif-sequencing-02.txt
Status:   https://datatracker.ietf.org/doc/draft-tgraf-netconf-notif-sequencing/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-tgraf-netconf-notif-sequencing-02

Abstract:

   This document specifies a new YANG module that augment the NETCONF
   Event Notification header to support hostname, Message Publisher ID
   and sequence numbers to identify from which network node and at which
   time the message was published.  This allows the collector to
   recognize loss, delay and reordering between the publisher and the
   downstream system storing the message.



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] ipfix-fwd-exceptions - Request WG adoption

[Thomas.Graf]

Dear Chaitanya,

Thanks a lot for the updated document. As previously stated, as a network 
operator, I value contributions describing reasons why packets are being 
dropped.

I reviewed the latest document revision and have the following comments:

Looking at 
https://datatracker.ietf.org/doc/html/draft-mvmd-opsawg-ipfix-fwd-exceptions-08#section-4.2.1
 and comparing to https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12, the 
listed examples in table 3 are rather generic and do not justify to be 
enterprise and could or even should be IANA. I support that IE89 
ForwardingStatius reason codes are being added, and your provided list is a 
good starting point, 
https://datatracker.ietf.org/doc/html/draft-opsawg-evans-discardmodel#name-information-model
 has also some interesting input to be considered.

Regarding 
https://datatracker.ietf.org/doc/html/draft-mvmd-opsawg-ipfix-fwd-exceptions-08#section-4.2.2,
 I welcome that the author detailed the meaning of the entity. As I commented 
in with the -02 review, it was not clear how it differentiates to

IE15  ipNextHopIPv4Address
IE18  bgpNextHopIPv4Address
IE62  ipNextHopIPv6Address
IE63  bgpNextHopIPv6Address
IE47  mplsTopLabelIPv4Address

Reading now the section, I understood that the authors try to capture the 
exception of a hierarchical lookup failure. Is that correct?

Reading 
https://datatracker.ietf.org/doc/html/draft-mvmd-opsawg-ipfix-fwd-exceptions-08#section-4.2.3,
 I understand that you would like to gain insights at which level of the 
hierarchical lookup the failure occurred. Correct?

Reading 
https://datatracker.ietf.org/doc/html/draft-mvmd-opsawg-ipfix-fwd-exceptions-08#section-4.2.4,
 I did not understood the difference to IE252 ingressPhysicalInterface. My 
expectation is that if sampling is being applied to a logical LACP interface 
that with IE252 the physical interface ifindex where the packet is being 
received is exported and with IE10 ingressInterface the logical LACP ifindex.

Best wishes
Thomas

From: OPSAWG  On Behalf Of Venkata Naga Chaitanya 
Munukutla
Sent: Monday, November 6, 2023 3:56 PM
To: opsawg@ietf.org
Cc: Shivam Vaid ; Vishnu Pavan Beeram 
; Aditya Mahale ; 
pateldev...@google.com
Subject: [OPSAWG] ipfix-fwd-exceptions - Request WG adoption

Hello OPSAWG experts,

We've posted version v08 for IPFIX Extensions for Forwarding Exceptions (minor 
editorial changes).
https://datatracker.ietf.org/doc/draft-mvmd-opsawg-ipfix-fwd-exceptions/08/

The document has been stable for a while and we believe it is sufficiently 
baked to be considered for WG adoption. The last time we presented this draft 
(IETF116), there seemed to be a reasonable amount of interest in the work (as 
captured in the meeting notes -- https://notes.ietf.org/notes-ietf-116-opsawg) .

We would like to invite more feedback on this document and also formally 
request WG adoption.

Thanks,
Chaitanya (on behalf of co-authors/contributors)


Juniper Business Use Only


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

Re: [OPSAWG] Section 6 - draft-fz-ippm-alt-mark-deployment-01

[Thomas.Graf]

Dear Massimo,


My apology for late reply. Both your comments are very valid. 
packetDeltaCount(IE2) can be also used for loss measurement. As well 
flowEndSeconds(IE151), flowEndMilliseconds(IE153),flowEndMicroseconds(IE155) or 
flowEndNanoseconds(IE157) for delay measurement. Both has been added in the -01 
revision of the document.

Best wishes
Thomas

From: Nilo Massimo 
Sent: Thursday, October 12, 2023 5:22 PM
To: Graf Thomas, INI-NET-VNC-HCS ; i...@ietf.org; 
draft-fz-ippm-alt-mark-deployment.auth...@ietf.org
Cc: opsawg@ietf.org
Subject: RE: Section 6 - draft-fz-ippm-alt-mark-deployment-01

Hi Thomas,
thank you for your feedback.
I have a couple of comments.
In section 6.1 for IPFIX, in order to calculate loss you said to use for 
packets the entity octetDeltaCount(IE1). But might it be better to use the 
entity packetDeltaCount(IE2)?

Moreover I suggest for the delay to add the use of existing entities 
flowEndSeconds, flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds.

Best Regards,

Massimo




Gruppo TIM - Uso Interno - Tutti i diritti riservati.
From: ippm mailto:ippm-boun...@ietf.org>> On Behalf Of 
thomas.g...@swisscom.com
Sent: lunedì 25 settembre 2023 13:23
To: i...@ietf.org; 
giuseppe.fiocc...@huawei.com; 
draft-fz-ippm-alt-mark-deployment.auth...@ietf.org
Cc: opsawg@ietf.org
Subject: [EXT] [ippm] Section 6 - draft-fz-ippm-alt-mark-deployment-01

Dear draft-fz-ippm-alt-mark-deployment authors, Dear IPPM working group,

First of all I think draft-fz-ippm-alt-mark-deployment is a valuable document 
describing the deployment of Alternat Marking.

I have reviewed 
https://datatracker.ietf.org/doc/draft-fz-ippm-alt-mark-deployment/ the Network 
Telemetry aspect described in Section 6 and wrote a proposal for -01 as 
following:

https://raw.githubusercontent.com/network-analytics/draft-fz-ippm-alt-mark-deployment/main/draft-fz-ippm-alt-mark-deployment-01.txt
https://raw.githubusercontent.com/network-analytics/draft-fz-ippm-alt-mark-deployment/main/draft-fz-ippm-alt-mark-deployment-01.xml

The new section describes how the export could be performed with existing IPFIX 
entities where decomposition is performed at the data collection and what needs 
to be consider for new IPFIX entities. I also described the publication with 
YANG push and what needs to be considered in terms of subscription, data 
publication and modeling.

Here the current diff: 
https://author-tools.ietf.org/diff?url_1=https://www.ietf.org/archive/id/draft-fz-ippm-alt-mark-deployment-00.txt_2=https://raw.githubusercontent.com/network-analytics/draft-fz-ippm-alt-mark-deployment/main/draft-fz-ippm-alt-mark-deployment-01.txt

I hope this makes sense and is helpful for the community. Feedback and comments 
welcome.

Best wishes
Thomas





Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
ricevuto questo documento per errore siete cortesemente pregati di darne 
immediata comunicazione al mittente e di provvedere alla sua distruzione, 
Grazie.

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the intended 
recipient, please delete this message and any attachments and advise the sender 
by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.




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

[OPSAWG] FW: [netconf] I-D Action: draft-ietf-netconf-distributed-notif-08.txt

[Thomas.Graf]

Dear netconf and opsawg,

We updated draft-ietf-netconf-distributed-notif to address Benoit's comment on 
the use of domain observation id terminology. We believe that by introducing a 
new terminology, Message Publisher and Message Publisher ID we have been 
addressing his concerns. Looking forward to feedback from Benoit and the 
working group.

Best wishes
Thomas

-Original Message-
From: netconf  On Behalf Of internet-dra...@ietf.org
Sent: Saturday, October 7, 2023 6:57 AM
To: i-d-annou...@ietf.org
Cc: netc...@ietf.org
Subject: [netconf] I-D Action: draft-ietf-netconf-distributed-notif-08.txt

Internet-Draft draft-ietf-netconf-distributed-notif-08.txt is now available.
It is a work item of the Network Configuration (NETCONF) WG of the IETF.

   Title:   Subscription to Distributed Notifications
   Authors: Tianran Zhou
Guangying Zheng
Eric Voit
Thomas Graf
Pierre Francois
   Name:draft-ietf-netconf-distributed-notif-08.txt
   Pages:   21
   Dates:   2023-10-06

Abstract:

   This document describes extensions to the YANG notifications
   subscription to allow metrics being published directly from
   processors on line cards to target receivers, while subscription is
   still maintained at the route processor in a distributed forwarding
   system.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-distributed-notif/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-08

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netconf-distributed-notif-08

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


___
netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

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

[OPSAWG] Section 6 - draft-fz-ippm-alt-mark-deployment-01

[Thomas.Graf]

Dear draft-fz-ippm-alt-mark-deployment authors, Dear IPPM working group,

First of all I think draft-fz-ippm-alt-mark-deployment is a valuable document 
describing the deployment of Alternat Marking.

I have reviewed 
https://datatracker.ietf.org/doc/draft-fz-ippm-alt-mark-deployment/ the Network 
Telemetry aspect described in Section 6 and wrote a proposal for -01 as 
following:

https://raw.githubusercontent.com/network-analytics/draft-fz-ippm-alt-mark-deployment/main/draft-fz-ippm-alt-mark-deployment-01.txt
https://raw.githubusercontent.com/network-analytics/draft-fz-ippm-alt-mark-deployment/main/draft-fz-ippm-alt-mark-deployment-01.xml

The new section describes how the export could be performed with existing IPFIX 
entities where decomposition is performed at the data collection and what needs 
to be consider for new IPFIX entities. I also described the publication with 
YANG push and what needs to be considered in terms of subscription, data 
publication and modeling.

Here the current diff: 
https://author-tools.ietf.org/diff?url_1=https://www.ietf.org/archive/id/draft-fz-ippm-alt-mark-deployment-00.txt_2=https://raw.githubusercontent.com/network-analytics/draft-fz-ippm-alt-mark-deployment/main/draft-fz-ippm-alt-mark-deployment-01.txt

I hope this makes sense and is helpful for the community. Feedback and comments 
welcome.

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-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00

[Thomas.Graf]

Dear Greg,

Thanks a lot. Valid point on connectivity service terminology. The proposed 
text works for me. Perfect.

Best wishes
Thomas

On 18 Aug 2023, at 21:53, Greg Mirsky  wrote:


Hi Thomas,
thank you for the feedback and proposed update. Please find my notes below 
tagged by GIM2>>.

Regards,
Greg

On Fri, Aug 18, 2023 at 6:56 AM 
mailto:thomas.g...@swisscom.com>> wrote:
Dear Greg,

Thanks a lot for addressing my comments.

GIM> It could be easier to take out "flow" altogether. WDYT?

TG> Let me propose something else:

Change from

"When analyzing the availability metrics of a service flow between two nodes"

To

"When analyzing the availability metrics of a connectivity service between two 
measurement points"
GIM2>> Prior to IETF-117 the authors extensively discussed the definition of a 
connectivity service. Because we couldn't find it being formulated in published 
documents we agreed to avoid referencing it in the PAM document. I hope that 
you will agree to the following update:
OLD TEXT:
   When analyzing the availability metrics of a service flow between two
   nodes, a time interval as the unit of PAM needs to be selected.
NEW TEXT:
   When analyzing the availability metrics of a service between two
   measurement points, a time interval as the unit of PAM needs to be
   selected.

GIM>> I agree. Check the attached diff.

TG> Perfect thanks!
GIM2>> Great!

Best wishes
Thomas

From: Greg Mirsky mailto:gregimir...@gmail.com>>
Sent: Monday, August 14, 2023 10:33 PM
To: Graf Thomas, INI-NET-VNC-HCS 
mailto:thomas.g...@swisscom.com>>
Cc: opsawg@ietf.org; i...@ietf.org
Subject: Re: [OPSAWG] draft-ietf-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00

Hi Thomas,
thank you for supporting this work and for your helpful comments. Please find 
my notes inlined below tagged by GIM>>.

Regards,
Greg

On Wed, Jul 26, 2023 at 2:24 PM 
mailto:thomas.g...@swisscom.com>> wrote:
Dear Alex and Greg,

I reviewed draft-ietf-ippm-pam-04 and draft-clemm-opsawg-pam-ipfix-00 and have 
some comments and questions.

Section 3.1 of draft-ietf-ippm-pam-04 
(https://datatracker.ietf.org/doc/html/draft-ietf-ippm-pam-04#section-3.1) 
mentions the term "service flow".

I haven't been able to find in any IETF document describing/defining the term. 
I suggest to describe it in the terminology section 2.1 and specify it as an 
IPFIX and YANG element.
GIM>> I checked and found that "service flow" is used only once in the document:

   When analyzing the availability metrics of a service flow between two
   nodes, a time interval as the unit of PAM needs to be selected.

It could be easier to take out "flow" altogether. WDYT?

Section 3.3 of draft-ietf-ippm-pam-04 specifies an "Unavailability threshold". 
I suggest to specify in Section 3.1 of draft-clemm-opsawg-pam-ipfix-00 
(https://datatracker.ietf.org/doc/html/draft-clemm-opsawg-pam-ipfix-00#section-3.1)
 this as IPFIX element as well.

The "service flow" describes that the SLO metrics are measured between two 
nodes. However in draft-clemm-opsawg-pam-ipfix the SLO metrics are measured and 
export on one node. I would appreciate if you could describe how this 
information is being measured. Presumably by leveraging of probing.
GIM>> The PAM document will not specify how to measure but where and what to be 
measured. We will work on clarifying that all PAM metrics are measured between 
two Measurement Points in the PAM IPFIX draft.

In general I feel that draft-ietf-ippm-pam-04 would benefit of having a 
reference to the Performance Metrics Registry defined in RFC 8911/8912.
 GIM>> I agree. Check the attached diff.

I would be interested to understand wherever the authors intend to create a 
draft document describing a service YANG module.
GIM>> That's a great suggestion, thank you. Let us discuss it.

Best wishes
Thomas
___
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] draft-ietf-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00

[Thomas.Graf]

Dear Greg,

Thanks a lot for addressing my comments.

GIM> It could be easier to take out "flow" altogether. WDYT?

TG> Let me propose something else:

Change from

"When analyzing the availability metrics of a service flow between two nodes"

To

"When analyzing the availability metrics of a connectivity service between two 
measurement points"

GIM>> I agree. Check the attached diff.

TG> Perfect thanks!

Best wishes
Thomas

From: Greg Mirsky 
Sent: Monday, August 14, 2023 10:33 PM
To: Graf Thomas, INI-NET-VNC-HCS 
Cc: opsawg@ietf.org; i...@ietf.org
Subject: Re: [OPSAWG] draft-ietf-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00

Hi Thomas,
thank you for supporting this work and for your helpful comments. Please find 
my notes inlined below tagged by GIM>>.

Regards,
Greg

On Wed, Jul 26, 2023 at 2:24 PM 
mailto:thomas.g...@swisscom.com>> wrote:
Dear Alex and Greg,

I reviewed draft-ietf-ippm-pam-04 and draft-clemm-opsawg-pam-ipfix-00 and have 
some comments and questions.

Section 3.1 of draft-ietf-ippm-pam-04 
(https://datatracker.ietf.org/doc/html/draft-ietf-ippm-pam-04#section-3.1) 
mentions the term "service flow".

I haven't been able to find in any IETF document describing/defining the term. 
I suggest to describe it in the terminology section 2.1 and specify it as an 
IPFIX and YANG element.
GIM>> I checked and found that "service flow" is used only once in the document:

   When analyzing the availability metrics of a service flow between two
   nodes, a time interval as the unit of PAM needs to be selected.

It could be easier to take out "flow" altogether. WDYT?

Section 3.3 of draft-ietf-ippm-pam-04 specifies an "Unavailability threshold". 
I suggest to specify in Section 3.1 of draft-clemm-opsawg-pam-ipfix-00 
(https://datatracker.ietf.org/doc/html/draft-clemm-opsawg-pam-ipfix-00#section-3.1)
 this as IPFIX element as well.

The "service flow" describes that the SLO metrics are measured between two 
nodes. However in draft-clemm-opsawg-pam-ipfix the SLO metrics are measured and 
export on one node. I would appreciate if you could describe how this 
information is being measured. Presumably by leveraging of probing.
GIM>> The PAM document will not specify how to measure but where and what to be 
measured. We will work on clarifying that all PAM metrics are measured between 
two Measurement Points in the PAM IPFIX draft.

In general I feel that draft-ietf-ippm-pam-04 would benefit of having a 
reference to the Performance Metrics Registry defined in RFC 8911/8912.
 GIM>> I agree. Check the attached diff.

I would be interested to understand wherever the authors intend to create a 
draft document describing a service YANG module.
GIM>> That's a great suggestion, thank you. Let us discuss it.

Best wishes
Thomas
___
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-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00

[Thomas.Graf]

Dear Alex and Greg,

I reviewed draft-ietf-ippm-pam-04 and draft-clemm-opsawg-pam-ipfix-00 and have 
some comments and questions.

Section 3.1 of draft-ietf-ippm-pam-04 
(https://datatracker.ietf.org/doc/html/draft-ietf-ippm-pam-04#section-3.1) 
mentions the term "service flow".

I haven't been able to find in any IETF document describing/defining the term. 
I suggest to describe it in the terminology section 2.1 and specify it as an 
IPFIX and YANG element.

Section 3.3 of draft-ietf-ippm-pam-04 specifies an "Unavailability threshold". 
I suggest to specify in Section 3.1 of draft-clemm-opsawg-pam-ipfix-00 
(https://datatracker.ietf.org/doc/html/draft-clemm-opsawg-pam-ipfix-00#section-3.1)
 this as IPFIX element as well.

The "service flow" describes that the SLO metrics are measured between two 
nodes. However in draft-clemm-opsawg-pam-ipfix the SLO metrics are measured and 
export on one node. I would appreciate if you could describe how this 
information is being measured. Presumably by leveraging of probing.

In general I feel that draft-ietf-ippm-pam-04 would benefit of having a 
reference to the Performance Metrics Registry defined in RFC 8911/8912.

I would be interested to understand wherever the authors intend to create a 
draft document describing a service YANG module.

Best wishes
Thomas


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-03.txt

[Thomas.Graf]

Dear OPSAWG and IPPM wg,

As described at IETF 116, draft-ietf-opsawg-ipfix-on-path-telemetry has been 
updated to -03 with an example section. Show an example with 
PathDelayMeanDeltaMicroseconds where the mean is already calculated at the 
IPFIX export and one with PathDelaySumDeltaMicroseconds where the mean is 
calculated at the IPFIX data collection.

Looking forward for feedback and comments.

Best wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Friday, June 9, 2023 2:17 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-03.txt


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

Name:   draft-ietf-opsawg-ipfix-on-path-telemetry
Revision:   03
Title:  Export of On-Path Delay in IPFIX
Document date:  2023-06-09
Group:  opsawg
Pages:  27
URL:
https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-on-path-telemetry-03.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-03

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] WG Adoption call for IPFIX

[Thomas.Graf]

Dear OPSAWG wg,

I support the adoption. I find this work very important to keep the IPFIX 
registry up to date. In particular I like to contribute to 
draft-boucadair-opsawg-ipfix-tcpo-v6eh since proper visibility of the IPv6 
extension headers are a great concern.

Best wishes
Thomas

From: OPSAWG  On Behalf Of Tianran Zhou
Sent: Tuesday, June 6, 2023 7:19 AM
To: opsawg 
Cc: opsawg-chairs 
Subject: [OPSAWG] WG Adoption call for IPFIX

Hi WG,

As we agreed on IETF 116, this mail starts a two weeks working group adoption 
call for the following three related drafts:

Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry
https://datatracker.ietf.org/doc/draft-boucla-opsawg-ipfix-fixes/

Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-ipfix-tcpo-v6eh/

Export of UDP Options Information in IP Flow Information Export (IPFIX)
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-tsvwg-udp-ipfix/

Please send your support or objection to the list.
Any comments are welcome.

This call will be end on June 20.

Cheers,
Tianran, as cochair


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

Re: [OPSAWG] Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS)

[Thomas.Graf]

Hi Med,

Thanks a lot for this. I am looking very forward to the discussion in the 
working group whether/how we will export also the observed occurrences of 
Routing Types. I believe with the continuous adoption of IPv6 and SRv6 this 
work will become important to network operators.

Best wishes
Thomas

From: mohamed.boucad...@orange.com 
Sent: Thursday, May 25, 2023 8:11 PM
To: Rob Wilton (rwilton) ; Andrew Alston - IETF 
; John Scudder 
Cc: The IESG ; draft-ietf-opsawg-ipfix-srv6-...@ietf.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: RE: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: 
(with DISCUSS)

Hi Rob,

I fully agree with your analysis.

The good news is that the WG still have the opportunity to address the multiple 
EH occurrences case, and not specifically for the SRH case. FWIW, 
https://www.ietf.org/archive/id/draft-boucadair-opsawg-ipfix-tcpo-v6eh-02.txt 
defines this NEW IE:

==
3.2.  ipv6ExtensionHeaderCount Information Element

   Name:  ipv6ExtensionHeaderCount

   ElementID:  TBD2

   Description:  As per [RFC8200], IPv6 nodes must accept and attempt to
  process extension headers in occurring any number of times in the
  same packet.  This Information Element echoes the number of
  occurrences of the same EH instance in an IPv6 packet.  EH Type
  values are taken from [IPv6-EH].
==

The occurrences are displayed per EH Type (aggregated) in the current version 
of the I-D. We will discuss in the WG whether/how we will export also the 
observed occurrences of Routing Types. Of course, we will send a note to 6man 
on this.

Cheers,
Med

De : Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Envoyé : jeudi 25 mai 2023 18:31
À : Andrew Alston - IETF 
mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>>;
 John Scudder mailto:j...@juniper.net>>; BOUCADAIR Mohamed 
INNOV/NET mailto:mohamed.boucad...@orange.com>>
Cc : The IESG mailto:i...@ietf.org>>; 
draft-ietf-opsawg-ipfix-srv6-...@ietf.org;
 opsawg-cha...@ietf.org; 
opsawg@ietf.org
Objet : RE: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: 
(with DISCUSS)

Hi,

I don't think that John's example is quite the same.  The IPv6 packet header 
format only has a space for a single source address and it is 16 bytes long.  
Two source addresses or a 20-byte address is clearly an invalid IPv6 packet 
because it doesn't match the IPv6 packet format.

But I don't think that this is quite true for IPv6 extension headers, where the 
text states:

   Each extension header should occur at most once, except for the
   Destination Options header, which should occur at most twice (once
   before a Routing header and once before the upper-layer header).

But it also states in the same section:


   IPv6 nodes must accept and attempt to process extension headers in

   any order and occurring any number of times in the same packet,

   except for the Hop-by-Hop Options header, which is restricted to

   appear immediately after an IPv6 header only.  Nonetheless, it is

   strongly advised that sources of IPv6 packets adhere to the above

   recommended order until and unless subsequent specifications revise

   that recommendation.

This second paragraph, which is just as normative as the first, seems to 
clearly indicate that IPv6 nodes are expected to handle and process extension 
headers occurring multiple times, implying that they could occur.

Hence, I suspect that it is this second paragraph as to why Thomas was trying 
to define how IPFIX works if this scenario is encountered in the wild.  E.g., 
operationally, it is better to report what you actually see rather report what 
the operator/client ideally wants to believe is in the packet.  I.e., if your 
IPv6 node does receive a packet with two SRv6 headers (which I still believe 
RFC 8200 allows for), and modulo Jim's argument that this is invalid, then I 
would still argue that it is more helpful to report that they are both there 
than just reporting the first one and ignoring the second.  YANG NMDA, RFC 8342 
is designed similarly.  Even if a YANG list states that it can only contain 2 
elements, but due to some (presumably buggy) reason, the device actually has 3, 
it is better to report all three than just pretend that there are only 2 
elements, because it helps the operator debug that something is going wrong 
(section 5.3).

I would argue that Jim's argument that another SRv6 related RFC (I don't know 
which one) clearly indicates that a v6 header can only ever contain a single 
SRH header holds a little more sway and is perhaps more relevant.

Having said all that, I think that point is somewhat moot because I think that 
the authors have agreed to remove this paragraph anyway - even if IMO it 
possibly makes the spec a bit less robust/helpful.

Regards,
Rob


From: iesg mailto:iesg-boun...@ietf.org>> On Behalf Of 
Andrew Alston - IETF
Sent: 

Re: [OPSAWG] Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS)

[Thomas.Graf]

Dear Andrew,

Thanks a lot for the review and comment. The intent of the authors was never to 
violate RFC 8200 but help the implementers of draft-ietf-opsawg-ipfix-srv6-srh 
how to deal with multiple SRH by referencing to Section 8 of RFC 7011. However, 
I understand from your feedback that multiple SRH should never occur and 
therefore makes the section 6.2 obsolete. I published version -14 where I 
removed the section and addressed some other minor editorial changes from 
today's IESG feedback. I hope this is addressing your concerns.


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

Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-14

Best wishes
Thomas

From: Andrew Alston - IETF 
Sent: Thursday, May 25, 2023 5:54 PM
To: John Scudder ; mohamed.boucad...@orange.com
Cc: The IESG ; draft-ietf-opsawg-ipfix-srv6-...@ietf.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: Re: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: 
(with DISCUSS)

Hi Med,

Firstly - I need to second what John said below.  Secondly, while we can agree 
that IPFIX supporting this doesn't violate the RFC - what it does do - is cater 
explicitly for what I believe is a violation of RFC8200, and that is where I 
have a problem.

While there could be *many* things that are done out of spec - unless there is 
a very specific and solid reason to cater for such out of spec behavior, this 
doesn't make sense to pick and choose the out of spec we are agreeing to 
suddenly cater for.

Thanks

Andrew


From: John Scudder mailto:j...@juniper.net>>
Date: Thursday, 25 May 2023 at 16:33
To: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Cc: Andrew Alston - IETF 
mailto:andrew-i...@liquid.tech>>, The IESG 
mailto:i...@ietf.org>>, 
draft-ietf-opsawg-ipfix-srv6-...@ietf.org
 
mailto:draft-ietf-opsawg-ipfix-srv6-...@ietf.org>>,
 opsawg-cha...@ietf.org 
mailto:opsawg-cha...@ietf.org>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>
Subject: Re: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13: 
(with DISCUSS)
Hi Med,

Not my DISCUSS, but... I did take a look at that thread earlier and found it 
somewhat unsatisfying. In particular, I find it a little odd that we feel the 
need to cover this particular out-of-spec behavior with IPFIX but not others - 
to take some extreme examples, how would IPFIX handle a packet with two source 
addresses? A packet with a 20-byte destination address? You can tell me that 
these aren't possible so it doesn't need to handle them, but that's the point 
(as I understand it).

$0.02,

-John

> On May 25, 2023, at 9:14 AM, 
> mohamed.boucad...@orange.com wrote:
>
> Hi Andrew,
>
> (replying as the doc shepherd)
>
> Éric raised a similar comment. I shared already some context about that 
> section: FYI, this point was discussed in the WG especially that there is no 
> SPING document that motivates/explains the use of multiple SRHs. Please 
> check: 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/opsawg/SVm4TZk1v6-a0WJwALk3FrUunFU/__;!!NEt6yMaO-gk!Dqk0pIxnGjA2Vlh7UL9wPsJy3iaHiPQ_mbdLAYsZ75BNxWqgxagtdnR_shIVNSp9F-GG_g7TBAFpbyc-kuhiV4jT$
>  for why the authors think this section is useful to be maintained in the 
> document.
>
> As currently worded, Section 6.3 does not violate any RFC. It only ensures 
> that it can successfully export what it is observed in packets. This can be 
> even used to detect abnormal behaviors/packs, which is one of the 
> observability goals of IPFIX.
>
> Cheers,
> Med
>
>> -Message d'origine-
>> De : Andrew Alston via Datatracker 
>> mailto:nore...@ietf.org>>
>> Envoyé : jeudi 25 mai 2023 15:03
>> À : The IESG mailto:i...@ietf.org>>
>> Cc : 
>> draft-ietf-opsawg-ipfix-srv6-...@ietf.org;
>>  opsawg-
>> cha...@ietf.org; 
>> opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET
>> mailto:mohamed.boucad...@orange.com>>; 
>> BOUCADAIR Mohamed INNOV/NET
>> mailto:mohamed.boucad...@orange.com>>
>> Objet : Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-
>> 13: (with DISCUSS)
>>
>> Andrew Alston has entered the following ballot position for
>> draft-ietf-opsawg-ipfix-srv6-srh-13: Discuss
>>
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>>
>>
>>
>>
>> 
>> --
>> 

Re: [OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-ipfix-srv6-srh-13: (with COMMENT)

[Thomas.Graf]

Dear Lars,

Thanks a lot for the review and comment. I addressed them in -14 version.

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-14

Best wishes
Thomas

-Original Message-
From: Lars Eggert via Datatracker  
Sent: Thursday, May 25, 2023 9:16 AM
To: The IESG 
Cc: draft-ietf-opsawg-ipfix-srv6-...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; mohamed.boucad...@orange.com; mohamed.boucad...@orange.com
Subject: Lars Eggert's No Objection on draft-ietf-opsawg-ipfix-srv6-srh-13: 
(with COMMENT)

Lars Eggert has entered the following ballot position for
draft-ietf-opsawg-ipfix-srv6-srh-13: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/



--
COMMENT:
--

# GEN AD review of draft-ietf-opsawg-ipfix-srv6-srh-11

CC @larseggert

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

 Section 3, paragraph 10
```
s information [IANA-IPFIX] allow to provide answers to the following questio
 ^^
```
Did you mean "providing"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

 Section 5.1.10, paragraph 5
```
as a list, without the need of post processing. However, this method require
   ^^^
```
This word is normally spelled with a hyphen.

 Section 6.1, paragraph 6
```
emented the following IEs as part of a a production implementation in the VRP
 ^^^
```
Possible typo: you repeated a word.

 Section 6.2, paragraph 1
```
ListSection decomposition as part of a a production implementation in the ope
 ^^^
```
Possible typo: you repeated a word.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool





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

Re: [OPSAWG] John Scudder's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-12: (with DISCUSS and COMMENT)

[Thomas.Graf]

Dear John,

My apology. Your assumption is correct. 

In case when the compressed SID container is only used in the IPv6 destination 
address of the provider data plane and the SRH is not being present at all, it 
would be a zero lenght array.

Best wishes
Thomas

> On 24 May 2023, at 17:32, John Scudder  wrote:
> 
> Thanks, Thomas. I think this part isn’t answered yet?
> 
>> On May 24, 2023, at 1:03 AM, thomas.g...@swisscom.com wrote:
>> 
>> And what
>> of srhIPv6Section? Would it just be omitted in the case of a bare cSID, would
>> it be a zero-length octetArray, ...?
> 
> Regards,
> 
> —John
> 


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

Re: [OPSAWG] [**EXTERNAL**] RE: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt

[Thomas.Graf]

Dear Paul,

Thanks a lot. I addressed both in -13 along with other IESG feedback.


There is also an htmlized version available at:

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



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-13

Best wishes
Thomas

From: Aitken, Paul 
Sent: Tuesday, May 23, 2023 4:02 PM
To: Graf Thomas, INI-NET-VNC-HCS 
Cc: benoit.cla...@huawei.com; pierre.franc...@insa-lyon.fr; 
mohamed.boucad...@orange.com; opsawg@ietf.org
Subject: Re: [**EXTERNAL**] RE: I-D Action: 
draft-ietf-opsawg-ipfix-srv6-srh-10.txt

3: "This section specifies the new IPv6 SRH IPFIX IEs." -> "... the new IPFIX 
IPv6 SRH IEs".

5.1: "Table 1 lists the new SRH IEs:" -> "... the new IPv6 SRH IEs" (because 
that's the title under the table).

5.2: Remove "(Section 5.2)".


P.
On 23/05/2023 14:35, thomas.g...@swisscom.com 
wrote:
Dear Paul and Med,

Makes completely sense. I had the same thoughts. Thanks a lot. I submitted -12.


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

Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-12

Best wishes
Thomas

From: Aitken, Paul 
Sent: Tuesday, May 23, 2023 10:36 AM
To: mohamed.boucad...@orange.com; Graf 
Thomas, INI-NET-VNC-HCS 
; 
opsawg@ietf.org
Cc: benoit.cla...@huawei.com; 
pierre.franc...@insa-lyon.fr
Subject: Re: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt

In that case, I would update the names of sections 3 and 5.1 so that 5.1 and 
5.2 are consistent, eg:

5.1.  New IPFIX IPv6 SRH Information Elements

5.2.  New IPFIX IPv6 SRH Segment Type Subregistry


Moreover, please use consistent terminology around the words "IPFIX", "IPv6", 
and "SRH" / "SRv6". Although "IPFIX IPv6 SRH" is the most used, I also see 
these uses:
3.  New SRH IPFIX Information Elements

This section specifies the new SRv6 IPFIX IEs.

Table 1: New SRv6 IEs in the "IPFIX Information Elements" Registry

Thanks,
P.


On 23/05/2023 07:26, 
mohamed.boucad...@orange.com wrote:
Hi Thomas, all,

Thanks for implementing the changes.

Looks good to me except one point: 5.1 as about new IEs. I think you should 
make this change:

OLD:
  5.1.10. New IPFIX IPv6 SRH Segment Type Subregistry

NEW:
  5.2. New IPFIX IPv6 SRH Segment Type Subregistry

Cheers,
Med

De : thomas.g...@swisscom.com 

Envoyé : mardi 23 mai 2023 07:19
À : BOUCADAIR Mohamed INNOV/NET 
; 
pait...@ciena.com; 
opsawg@ietf.org
Cc : benoit.cla...@huawei.com; 
pierre.franc...@insa-lyon.fr
Objet : RE: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt


Dear Paul and Med,



Excellent. Thanks a lot for your suggestions. I merged them into the -11 
version.



There is also an htmlized version available at:

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



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-11



Best wishes

Thomas

From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Sent: Monday, May 22, 2023 2:50 PM
To: Aitken, Paul mailto:pait...@ciena.com>>; Graf Thomas, 
INI-NET-VNC-HCS mailto:thomas.g...@swisscom.com>>; 
opsawg@ietf.org
Cc: benoit.cla...@huawei.com; 
pierre.franc...@insa-lyon.fr
Subject: RE: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt

Re-,

The designed experts for this sub-registry should be familiar with SRH. I think 
your concern can be fixed by making this change:

OLD:

 The guidelines that are being followed by the designated experts for ..


NEW:

 The designed experts for this registry should be familiar with SRH.

 The guidelines that are being followed by the designated experts for ..

The AD (Rob) will take that into account when selecting the DEs for this 
sub-registry. The good news is that the authors of 
draft-ietf-opsawg-ipfix-srv6-srh said that they volunteer to be DE for this 
registry.

Cheers,
Med

De : Aitken, Paul mailto:pait...@ciena.com>>
Envoyé : lundi 22 mai 2023 13:10
À : Graf Thomas, INI-NET-VNC-HCS 
mailto:thomas.g...@swisscom.com>>; BOUCADAIR Mohamed 
INNOV/NET mailto:mohamed.boucad...@orange.com>>; 
opsawg@ietf.org
Cc : benoit.cla...@huawei.com; 

Re: [OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-ipfix-srv6-srh-12: (with COMMENT)

[Thomas.Graf]

Dear Erik,

Thanks a lot for your review and comment. I added the following sentence in the 
-13 revision to make it clear which IEs are needed and where the decoding needs 
to be done:

By using described information from srhSegmentIPv6EndpointBehavior and 
srhSegmentIPv6LocatorLength the compressed-SID containers can be decoded at the 
data collection.

Best wishes
Thomas

-Original Message-
From: Erik Kline via Datatracker  
Sent: Wednesday, May 24, 2023 6:36 AM
To: The IESG 
Cc: draft-ietf-opsawg-ipfix-srv6-...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; mohamed.boucad...@orange.com; mohamed.boucad...@orange.com
Subject: Erik Kline's No Objection on draft-ietf-opsawg-ipfix-srv6-srh-12: 
(with COMMENT)

Erik Kline has entered the following ballot position for
draft-ietf-opsawg-ipfix-srv6-srh-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/



--
COMMENT:
--

# Internet AD comments for draft-ietf-opsawg-ipfix-srv6-srh-12
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S6.2

* We might clarify here that no export method involves any "decompression"
  of a compressed SID.  (I assume unpacking a compressed SID is entirely the
  responsibility of an analysis function within or downstream of the
  collector.)

## Nits

### S5.2

* s/designed experts/designated experts/





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

Re: [OPSAWG] Éric Vyncke's Yes on draft-ietf-opsawg-ipfix-srv6-srh-10: (with COMMENT)

[Thomas.Graf]

Dear Eric,

Thanks for your comments.

With srhIPv6ActiveSegmentType the authors intended to have the operational 
experience in SRv6 than we have in MPLS-SR with mplsTopLabelType

https://datatracker.ietf.org/doc/html/rfc9160
https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type

The authors believe it is necessary to have in IPFIX where we monitor the 
forwarding-plane all the information needed to perform a lookup in the 
control-plane next. For that the information which routing protocol is used for 
the srhIPv6ActiveSegment is needed.

Such keys enable a lookup between different planes. So a small but necessary 
overlap between the different Network Telemetry protocols are needed. Therefore 
if the information is learned by two sources it is not a concern.

Best wishes
Thomas

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: Monday, May 22, 2023 4:17 PM
To: The IESG 
Cc: draft-ietf-opsawg-ipfix-srv6-...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; mohamed.boucad...@orange.com; mohamed.boucad...@orange.com
Subject: Éric Vyncke's Yes on draft-ietf-opsawg-ipfix-srv6-srh-10: (with 
COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-ipfix-srv6-srh-10: Yes

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/



--
COMMENT:
--

# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-ipfix-srv6-srh-10

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Mohamed Boucadair for the shepherd's detailed write-up
including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### More than data plane

I like the idea of exporting srhIPv6ActiveSegmentType for operation, it goes
well beyond the plain export of the SRH header. I just fear that the extra
information is redundant and will be repeated quite often.

### Section 5.1.9

What would happen if this information is learned by two sources ?

### Section 6.3

Beside encapsulation, I do not see how multiple (S)RHs could be in one IPv6
packet. Anyway, the router will, per RFC 8200, only act on the outermost one.
I.e., strongly suggest that this I-D specifies that only the outermost SRH &
associated behavior are specified.





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-10.txt

[Thomas.Graf]

Dear Paul and Med,

Makes completely sense. I had the same thoughts. Thanks a lot. I submitted -12.


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

Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-12

Best wishes
Thomas

From: Aitken, Paul 
Sent: Tuesday, May 23, 2023 10:36 AM
To: mohamed.boucad...@orange.com; Graf Thomas, INI-NET-VNC-HCS 
; opsawg@ietf.org
Cc: benoit.cla...@huawei.com; pierre.franc...@insa-lyon.fr
Subject: Re: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt

In that case, I would update the names of sections 3 and 5.1 so that 5.1 and 
5.2 are consistent, eg:

5.1.  New IPFIX IPv6 SRH Information Elements

5.2.  New IPFIX IPv6 SRH Segment Type Subregistry


Moreover, please use consistent terminology around the words "IPFIX", "IPv6", 
and "SRH" / "SRv6". Although "IPFIX IPv6 SRH" is the most used, I also see 
these uses:
3.  New SRH IPFIX Information Elements

This section specifies the new SRv6 IPFIX IEs.

Table 1: New SRv6 IEs in the "IPFIX Information Elements" Registry

Thanks,
P.

On 23/05/2023 07:26, 
mohamed.boucad...@orange.com wrote:
Hi Thomas, all,

Thanks for implementing the changes.

Looks good to me except one point: 5.1 as about new IEs. I think you should 
make this change:

OLD:
  5.1.10. New IPFIX IPv6 SRH Segment Type Subregistry

NEW:
  5.2. New IPFIX IPv6 SRH Segment Type Subregistry

Cheers,
Med

De : thomas.g...@swisscom.com 

Envoyé : mardi 23 mai 2023 07:19
À : BOUCADAIR Mohamed INNOV/NET 
; 
pait...@ciena.com; 
opsawg@ietf.org
Cc : benoit.cla...@huawei.com; 
pierre.franc...@insa-lyon.fr
Objet : RE: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt


Dear Paul and Med,



Excellent. Thanks a lot for your suggestions. I merged them into the -11 
version.



There is also an htmlized version available at:

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



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-11



Best wishes

Thomas

From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Sent: Monday, May 22, 2023 2:50 PM
To: Aitken, Paul mailto:pait...@ciena.com>>; Graf Thomas, 
INI-NET-VNC-HCS mailto:thomas.g...@swisscom.com>>; 
opsawg@ietf.org
Cc: benoit.cla...@huawei.com; 
pierre.franc...@insa-lyon.fr
Subject: RE: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt

Re-,

The designed experts for this sub-registry should be familiar with SRH. I think 
your concern can be fixed by making this change:

OLD:

 The guidelines that are being followed by the designated experts for ..


NEW:

 The designed experts for this registry should be familiar with SRH.

 The guidelines that are being followed by the designated experts for ..

The AD (Rob) will take that into account when selecting the DEs for this 
sub-registry. The good news is that the authors of 
draft-ietf-opsawg-ipfix-srv6-srh said that they volunteer to be DE for this 
registry.

Cheers,
Med

De : Aitken, Paul mailto:pait...@ciena.com>>
Envoyé : lundi 22 mai 2023 13:10
À : Graf Thomas, INI-NET-VNC-HCS 
mailto:thomas.g...@swisscom.com>>; BOUCADAIR Mohamed 
INNOV/NET mailto:mohamed.boucad...@orange.com>>; 
opsawg@ietf.org
Cc : benoit.cla...@huawei.com; 
pierre.franc...@insa-lyon.fr
Objet : Re: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt


1) Yes, 5.1.9.1. could be renumbered to 5.2. But also modify the name to "New 
IPFIX IPv6 SRH Segment Type Subregistry", similar to the name of section 5.1. 
"New SRH Information Elements".

Also watch for confusion between section 3's title and section 5.1:

3.  New SRv6 IPFIX Information Elements
5.1.  New SRH Information Elements


2) I specifically asked for the Expert Reviewers to be named, for two reasons:

1. Each registry lists the "Registration Procedure(s)" (Expert Review) and 
the corresponding "Expert(s)" (IE Doctors) - so it's necessary to provide both 
pieces of information.
2. Without specifying "SRH Experts", it might incorrectly be assumed that 
"IE Doctors" will be the expert reviewers.


P.
On 22/05/2023 09:38, thomas.g...@swisscom.com 
wrote:

Dear Med,



Thanks a lot.



Regarding your feedback on expert review, for me valid and ok but I am waiting 
on Paul's feedback if that make sense to him as well.



Regarding, IPFIX IPv6 SRH Segment Type Subregistry. I believe the section is 
related to the 

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

[Thomas.Graf]

Dear Paul and Med,



Excellent. Thanks a lot for your suggestions. I merged them into the -11 
version.



There is also an htmlized version available at:

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



A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-11



Best wishes

Thomas

From: mohamed.boucad...@orange.com 
Sent: Monday, May 22, 2023 2:50 PM
To: Aitken, Paul ; Graf Thomas, INI-NET-VNC-HCS 
; opsawg@ietf.org
Cc: benoit.cla...@huawei.com; pierre.franc...@insa-lyon.fr
Subject: RE: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt

Re-,

The designed experts for this sub-registry should be familiar with SRH. I think 
your concern can be fixed by making this change:

OLD:

 The guidelines that are being followed by the designated experts for ..


NEW:

 The designed experts for this registry should be familiar with SRH.

 The guidelines that are being followed by the designated experts for ..

The AD (Rob) will take that into account when selecting the DEs for this 
sub-registry. The good news is that the authors of 
draft-ietf-opsawg-ipfix-srv6-srh said that they volunteer to be DE for this 
registry.

Cheers,
Med

De : Aitken, Paul mailto:pait...@ciena.com>>
Envoyé : lundi 22 mai 2023 13:10
À : Graf Thomas, INI-NET-VNC-HCS 
mailto:thomas.g...@swisscom.com>>; BOUCADAIR Mohamed 
INNOV/NET mailto:mohamed.boucad...@orange.com>>; 
opsawg@ietf.org
Cc : benoit.cla...@huawei.com; 
pierre.franc...@insa-lyon.fr
Objet : Re: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt


1) Yes, 5.1.9.1. could be renumbered to 5.2. But also modify the name to "New 
IPFIX IPv6 SRH Segment Type Subregistry", similar to the name of section 5.1. 
"New SRH Information Elements".

Also watch for confusion between section 3's title and section 5.1:

3.  New SRv6 IPFIX Information Elements
5.1.  New SRH Information Elements


2) I specifically asked for the Expert Reviewers to be named, for two reasons:

1. Each registry lists the "Registration Procedure(s)" (Expert Review) and 
the corresponding "Expert(s)" (IE Doctors) - so it's necessary to provide both 
pieces of information.
2. Without specifying "SRH Experts", it might incorrectly be assumed that 
"IE Doctors" will be the expert reviewers.


P.
On 22/05/2023 09:38, thomas.g...@swisscom.com 
wrote:

Dear Med,



Thanks a lot.



Regarding your feedback on expert review, for me valid and ok but I am waiting 
on Paul's feedback if that make sense to him as well.



Regarding, IPFIX IPv6 SRH Segment Type Subregistry. I believe the section is 
related to the srhIPv6ActiveSegmentType section. Therefore in the all the 
previous revisions of the document it was listed that way. For me to list it 
either under 5.1.9.1 or 5.2 works. Since it is the IANA section, lets get the 
opinion from Paul as well. I will adjust then accordingly.



Best wishes

Thomas



-Original Message-

From: mohamed.boucad...@orange.com 


Sent: Monday, May 22, 2023 8:50 AM

To: opsawg@ietf.org; Graf Thomas, INI-NET-VNC-HCS 


Cc: Aitken, Paul 

Subject: RE: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt



Hi Thomas,



I think there was a bug in -10:



s/5.1.9.1.  IPFIX IPv6 SRH Segment Type Subregistry/5.2  IPFIX IPv6 SRH Segment 
Type Subregistry





Also, for this text:



  The allocation policy of this new subregistry is Expert Review

  (Section 4.5 of [RFC8126]) by SRH Experts.



I don't think we need to have ".. by SRH Experts" mentioned here given that the 
assigned DEs for this subregistry are IMO required to be familiar with SRH.



If you think this is obvious and has to be recorded in the draft, I suggest the 
following:



(1)



OLD

  The allocation policy of this new subregistry is Expert Review

  (Section 4.5 of [RFC8126]) by SRH Experts.



NEW:

  The allocation policy of this new subregistry is Expert Review

  (Section 4.5 of [RFC8126]).



(2)



OLD:

  The guidelines that are being followed by the designated experts for ...



NEW:

 The designed experts for this registry should be familiar with SRH.

 The guidelines that are being followed by the designated experts for ..





Thanks.



Cheers,

Med

_



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 

Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-ipfix-srv6-srh-10: (with COMMENT)

[Thomas.Graf]

Dear Roman,

Thanks a lot for your review and comment. I merged them into the -11 version.

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

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-11

Best wishes
Thomas

-Original Message-
From: Roman Danyliw via Datatracker  
Sent: Monday, May 22, 2023 6:28 PM
To: The IESG 
Cc: draft-ietf-opsawg-ipfix-srv6-...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; mohamed.boucad...@orange.com; mohamed.boucad...@orange.com
Subject: Roman Danyliw's No Objection on draft-ietf-opsawg-ipfix-srv6-srh-10: 
(with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-opsawg-ipfix-srv6-srh-10: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/



--
COMMENT:
--

Thank you to Tero Kivinen for the SECDIR review.

** Section 9
   There exists no significant extra security considerations regarding
   allocation of these new IPFIX IEs compared to [RFC7012]

What are the “non-significant extra security considerations” not mentioned in
RFC7012?  The text implies there is something more to say.

** Section 9.
   Privacy considerations described in Section 11.8 of [RFC7012] SHOULD
   be considered for all described IEs.  They export provider data plane
   metrics which describe how packets are being forwarded within the
   SRv6 network.

-- Typo.  This text should reference Section 11.8 of RFC7011.  RFC7012 has no
privacy consideration and no Section 11.

-- Even though this is a data model, the clarity of “SHOULD ... consider”
language (here) to text which has non-normative “mays” and “musts” (of RFC7011)
is murky.  Consider if it is more appropriate to say “must”.  For example:

NEW
The IEs described in this document export provider plane data metrics on how
packets are being forwarded within an SRv6 network. Applications and operators
using the IEs described in this document must evaluate the sensitivity of this
information in their implementation context, and apply the data-at-rest storage
guidance in Section 11.8 of RFC7011 as appropriate.





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-10.txt

[Thomas.Graf]

Dear Med,

Thanks a lot. 

Regarding your feedback on expert review, for me valid and ok but I am waiting 
on Paul's feedback if that make sense to him as well.

Regarding, IPFIX IPv6 SRH Segment Type Subregistry. I believe the section is 
related to the srhIPv6ActiveSegmentType section. Therefore in the all the 
previous revisions of the document it was listed that way. For me to list it 
either under 5.1.9.1 or 5.2 works. Since it is the IANA section, lets get the 
opinion from Paul as well. I will adjust then accordingly.

Best wishes
Thomas

-Original Message-
From: mohamed.boucad...@orange.com  
Sent: Monday, May 22, 2023 8:50 AM
To: opsawg@ietf.org; Graf Thomas, INI-NET-VNC-HCS 
Cc: Aitken, Paul 
Subject: RE: I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-10.txt

Hi Thomas,

I think there was a bug in -10:

s/5.1.9.1.  IPFIX IPv6 SRH Segment Type Subregistry/5.2  IPFIX IPv6 SRH Segment 
Type Subregistry


Also, for this text: 

  The allocation policy of this new subregistry is Expert Review
  (Section 4.5 of [RFC8126]) by SRH Experts.

I don't think we need to have ".. by SRH Experts" mentioned here given that the 
assigned DEs for this subregistry are IMO required to be familiar with SRH.

If you think this is obvious and has to be recorded in the draft, I suggest the 
following: 

(1)

OLD 
  The allocation policy of this new subregistry is Expert Review
  (Section 4.5 of [RFC8126]) by SRH Experts.

NEW:
  The allocation policy of this new subregistry is Expert Review
  (Section 4.5 of [RFC8126]).

(2)

OLD: 
  The guidelines that are being followed by the designated experts for ...

NEW:
 The designed experts for this registry should be familiar with SRH.
 The guidelines that are being followed by the designated experts for ..


Thanks. 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de 
> internet-dra...@ietf.org Envoyé : jeudi 18 mai 2023 13:11 À : 
> i-d-annou...@ietf.org Cc : opsawg@ietf.org Objet : I-D Action: 
> draft-ietf-opsawg-ipfix-srv6-srh-10.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories. This Internet-Draft is a work item of the Operations and 
> Management Area Working Group (OPSAWG) 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-10.txt
>Pages   : 28
>Date: 2023-05-18
> 
> 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 Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-srv6-
> srh%2F=05%7C01%7Cmohamed.boucadair%40orange.com%7Cddcd5d8eceb
> 64928d33308db5790ac5b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> C638200051102993802%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> =Q%2Fl7cb4MQj4Jj4bSm4fRySHmkdnPdIkrmWIcoEUPpZ0%3D=0
> 
> There is also an htmlized version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-opsawg-ipfix-srv6-
> srh-
> 10=05%7C01%7Cmohamed.boucadair%40orange.com%7Cddcd5d8eceb6492
> 8d33308db5790ac5b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> 200051102993802%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=QsD
> 1F2oq5TSKove3Rx4UtUJcaOYSH16GK%2FATo%2FRxbw8%3D=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> author-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-ipfix-
> srv6-srh-
> 10=05%7C01%7Cmohamed.boucadair%40orange.com%7Cddcd5d8eceb6492
> 8d33308db5790ac5b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> 200051102993802%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=928
> QZUj8oeWXbhOMlNfGO2Iuq0oRi%2BXa2TyiPiMOg6w%3D=0
> 
> Internet-Drafts are also available by rsync at 
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.ietf.org%2Fmailman%2Flistinfo%2Fi-d-
> announce=05%7C01%7Cmohamed.boucadair%40orange.com%7Cddcd5d8ec
> eb64928d33308db5790ac5b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0
> 

Re: [OPSAWG] [Ie-doctors] [IANA #1271817] expert review for draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

[Thomas.Graf]

Dear Paul,


Thanks a lot. I adjusted the indent structure as it was before but under 5.1 
since Med added the 5.1 "New SRH Information Elements" section and reference it 
in the text, which makes sense to me and addressed your nit.

Here the -10 document:
https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

The diff from your last input:
https://author-tools.ietf.org/iddiff?url1= 
https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/e9edb50bfa901017d45b8237b2bedcd08c95dfd3/draft-ietf-opsawg-ipfix-srv6-srh-10.txt=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

I am now submitting the document so that IESG has enough time to review before 
the telechat.

Best wishes
Thomas

From: Aitken, Paul 
Sent: Thursday, May 18, 2023 12:26 PM
To: Graf Thomas, INI-NET-VNC-HCS 
Cc: ie-doct...@ietf.org; opsawg@ietf.org; 
drafts-expert-review-comm...@iana.org; mohamed.boucad...@orange.com; 
rwil...@cisco.com
Subject: Re: [Ie-doctors] [IANA #1271817] expert review for 
draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

Thomas,

1. Please check the indentation of section 5's subsections.

ie, either  5.1.x should be 5.x as before, or 5.2 and 5.3 should be 5.1.11 
and 5.1.12.


2. In section 5.1.10, please say who the Expert Reviewers will be. Is it 
IE-Doctors, or SRH Experts, or some other group?

The allocation policy of this new subregistry is Expert Review by ...

communicating this decision to the IANA


P.

On 18/05/2023 09:27, thomas.g...@swisscom.com 
wrote:
Dear Med,

Thanks a lot for your comment on the designated expert in the "IPFIX IPv6 SRH 
Segment Type Subregistry" and the removal of the intro section in the "IANA 
Considerations"

Here the -10 document:
https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

The diff from your last input:
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/3dc1a87f423fe8aa8f61691df924b95971c38860/draft-ietf-opsawg-ipfix-srv6-srh-10.txt=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

Best wishes
Thomas

From: Graf Thomas, INI-NET-VNC-HCS
Sent: Wednesday, May 17, 2023 7:48 AM
To: 'Aitken, Paul' 
Cc: ie-doct...@ietf.org; 
opsawg@ietf.org; 
drafts-expert-review-comm...@iana.org;
 mohamed.boucad...@orange.com; 
rwil...@cisco.com
Subject: RE: [Ie-doctors] [IANA #1271817] expert review for 
draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

Dear Paul,

Thank you very much. I merged all your input.

PA> 5.4. srhActiveSegmentIPv6 / Additional Information, Changed from RFC8754 to 
RFC8402, is that correct? Please say which section of the RFC is relevant.

TG> That is correct. The active section is specified in Section 2 of RFC 8402 
and being obtained from the SRH based from the Segment List and Segment Left. I 
add the section in the RFC 8402 reference now as well. Thanks for spotting this.

Here the -10 document:
https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

The diff from your last input:
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/2669406f75d0ad66d830d9981c2d0c480dc88e2b/draft-ietf-opsawg-ipfix-srv6-srh-10.txt=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

And the diff to -09:
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-09.txt=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

Best wishes
Thomas

From: Aitken, Paul mailto:pait...@ciena.com>>
Sent: Tuesday, May 16, 2023 9:29 PM
To: Graf Thomas, INI-NET-VNC-HCS 
mailto:thomas.g...@swisscom.com>>
Cc: ie-doct...@ietf.org; 
opsawg@ietf.org; 
drafts-expert-review-comm...@iana.org;
 

Re: [OPSAWG] [Ie-doctors] [IANA #1271817] expert review for draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

[Thomas.Graf]

Dear Med,

Thanks a lot for your comment on the designated expert in the "IPFIX IPv6 SRH 
Segment Type Subregistry" and the removal of the intro section in the "IANA 
Considerations"

Here the -10 document:
https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

The diff from your last input:
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/3dc1a87f423fe8aa8f61691df924b95971c38860/draft-ietf-opsawg-ipfix-srv6-srh-10.txt=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

Best wishes
Thomas

From: Graf Thomas, INI-NET-VNC-HCS
Sent: Wednesday, May 17, 2023 7:48 AM
To: 'Aitken, Paul' 
Cc: ie-doct...@ietf.org; opsawg@ietf.org; 
drafts-expert-review-comm...@iana.org; mohamed.boucad...@orange.com; 
rwil...@cisco.com
Subject: RE: [Ie-doctors] [IANA #1271817] expert review for 
draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

Dear Paul,

Thank you very much. I merged all your input.

PA> 5.4. srhActiveSegmentIPv6 / Additional Information, Changed from RFC8754 to 
RFC8402, is that correct? Please say which section of the RFC is relevant.

TG> That is correct. The active section is specified in Section 2 of RFC 8402 
and being obtained from the SRH based from the Segment List and Segment Left. I 
add the section in the RFC 8402 reference now as well. Thanks for spotting this.

Here the -10 document:
https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

The diff from your last input:
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/2669406f75d0ad66d830d9981c2d0c480dc88e2b/draft-ietf-opsawg-ipfix-srv6-srh-10.txt=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

And the diff to -09:
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-09.txt=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

Best wishes
Thomas

From: Aitken, Paul mailto:pait...@ciena.com>>
Sent: Tuesday, May 16, 2023 9:29 PM
To: Graf Thomas, INI-NET-VNC-HCS 
mailto:thomas.g...@swisscom.com>>
Cc: ie-doct...@ietf.org; 
opsawg@ietf.org; 
drafts-expert-review-comm...@iana.org;
 mohamed.boucad...@orange.com; 
rwil...@cisco.com
Subject: Re: [Ie-doctors] [IANA #1271817] expert review for 
draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

Thomas,


3.  srhSegmentIPv6BasicList

"As specified in Section 2 of [RFC8754]" versus 5.5 / Description, "As 
described in Section 2 of [RFC8754]".


3.  srhSegmentIPv6ListSection

Remove "Exposes" for consistency with 5.6 / Description.


3.  srhSegmentsIPv6Left

"Segment List from the SRH" -> "Segment List in the SRH" for consistency 
with 5.7 / Description.


3.  srhIPv6Section

Remove "Exposes" for consistency with 5.8 / Description.


3. srhIPv6ActiveSegmentType  and  5.9. / Description

Remove the first "from" to avoid "from ... from":

Name of the routing protocol or PCEP extension from where the
active SRv6 segment has been learned from.


3.  srhSegmentIPv6LocatorLength

The definition is inconsistent with 5.10 / Description.


5.4.  srhActiveSegmentIPv6 / Additional Information

Changed from RFC8754 to RFC8402, is that correct?

Please say which section of the RFC is relevant.


5.7.  srhSegmentsIPv6Left / Additional Information

Please don't duplicate the Description; just list the information once.


Thanks,
P.


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

Re: [OPSAWG] [Ie-doctors] [IANA #1271817] expert review for draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

[Thomas.Graf]

Dear Paul,

Thank you very much. I merged all your input.

PA> 5.4. srhActiveSegmentIPv6 / Additional Information, Changed from RFC8754 to 
RFC8402, is that correct? Please say which section of the RFC is relevant.

TG> That is correct. The active section is specified in Section 2 of RFC 8402 
and being obtained from the SRH based from the Segment List and Segment Left. I 
add the section in the RFC 8402 reference now as well. Thanks for spotting this.

Here the -10 document:
https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

The diff from your last input:
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/2669406f75d0ad66d830d9981c2d0c480dc88e2b/draft-ietf-opsawg-ipfix-srv6-srh-10.txt=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

And the diff to -09:
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-09.txt=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

Best wishes
Thomas

From: Aitken, Paul 
Sent: Tuesday, May 16, 2023 9:29 PM
To: Graf Thomas, INI-NET-VNC-HCS 
Cc: ie-doct...@ietf.org; opsawg@ietf.org; 
drafts-expert-review-comm...@iana.org; mohamed.boucad...@orange.com; 
rwil...@cisco.com
Subject: Re: [Ie-doctors] [IANA #1271817] expert review for 
draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

Thomas,


3.  srhSegmentIPv6BasicList

"As specified in Section 2 of [RFC8754]" versus 5.5 / Description, "As 
described in Section 2 of [RFC8754]".


3.  srhSegmentIPv6ListSection

Remove "Exposes" for consistency with 5.6 / Description.


3.  srhSegmentsIPv6Left

"Segment List from the SRH" -> "Segment List in the SRH" for consistency 
with 5.7 / Description.


3.  srhIPv6Section

Remove "Exposes" for consistency with 5.8 / Description.


3. srhIPv6ActiveSegmentType  and  5.9. / Description

Remove the first "from" to avoid "from ... from":

Name of the routing protocol or PCEP extension from where the
active SRv6 segment has been learned from.


3.  srhSegmentIPv6LocatorLength

The definition is inconsistent with 5.10 / Description.


5.4.  srhActiveSegmentIPv6 / Additional Information

Changed from RFC8754 to RFC8402, is that correct?

Please say which section of the RFC is relevant.


5.7.  srhSegmentsIPv6Left / Additional Information

Please don't duplicate the Description; just list the information once.


Thanks,
P.


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

Re: [OPSAWG] [Ie-doctors] [IANA #1271817] expert review for draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

[Thomas.Graf]

Dear Paul,

Thanks a lot. I updated section 5.9.1 as you suggested.

https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-09.txt=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

Once you reviewed and commented, I will submit the changes. We still have a 
week to the IESG telechat.

I assume that the SRH expert IANA mailing list can be established after IESG 
has passed and would be between IESG and IANA if I understand 
https://datatracker.ietf.org/doc/html/rfc8126#section-11 correctly.

Best wishes
Thomas

From: Aitken, Paul 
Sent: Tuesday, May 16, 2023 2:54 PM
To: Graf Thomas, INI-NET-VNC-HCS ; 
drafts-expert-review-comm...@iana.org; mohamed.boucad...@orange.com; 
rwil...@cisco.com
Cc: ie-doct...@ietf.org; opsawg@ietf.org
Subject: Re: [Ie-doctors] [IANA #1271817] expert review for 
draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

Thanks Thomas, I will re-review the updated draft later.


PA> 7. Implementation Status, I would put this section in an appendix to avoid 
the need to renumber sections 8, 9, and 10 when this is removed.

TG> Good point. I double checked. I am following Section 2 of RFC 7942 
(https://datatracker.ietf.org/doc/html/rfc7942#section-2) describing that the 
"Implementation Status" section should be before the "Security Considerations", 
which was previously before the "acknowledge" section in this document. I 
therefore adjusted accordingly.

Then the issue remains: since the "Implementation Status" section is to be 
deleted, the following sections must be renumbered which could invalidate any 
references to those sections. eg, "... per the Security Considerations in 
section 9" would be wrong. Fortunately it's not (currently) an issue in this 
draft.



Regarding your question who the srhIPv6ActiveSegmentType sub-registry should 
be. If Rob agrees, I as one of the authors of draft-ietf-opsawg-ipfix-srv6-srh 
would volunteer to do the expert review. Benoit would be also available if 
needed.

Great! So in section 5.9.1, please say something like, "and are subject to 
Expert Review [RFC8126] by SRH Experts" and ensure that IANA has a mailing list 
for that. Otherwise allocation would fall to IE-doctors who are not SRH experts!

Thanks,
P.


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

Re: [OPSAWG] [Ie-doctors] [IANA #1271817] expert review for draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

[Thomas.Graf]

Dear Paul,

Thanks a lot for your review and comments. With one minor editorial exception, 
all are valid and merged in the coming -10 version of the document.

https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-09.txt=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt

Please let me know if this addressing your points. I will submit it then to the 
data tracker.

Here our feedback to the other points:

PA> 7. Implementation Status, I would put this section in an appendix to avoid 
the need to renumber sections 8, 9, and 10 when this is removed.

TG> Good point. I double checked. I am following Section 2 of RFC 7942 
(https://datatracker.ietf.org/doc/html/rfc7942#section-2) describing that the 
"Implementation Status" section should be before the "Security Considerations", 
which was previously before the "acknowledge" section in this document. I 
therefore adjusted accordingly.

Regarding your question who the srhIPv6ActiveSegmentType sub-registry should 
be. If Rob agrees, I as one of the authors of draft-ietf-opsawg-ipfix-srv6-srh 
would volunteer to do the expert review. Benoit would be also available if 
needed.

Looking forward for your and Rob's feedback.

Best wishes
Thomas

From: OPSAWG  On Behalf Of Aitken, Paul
Sent: Monday, May 15, 2023 4:17 PM
To: drafts-expert-review-comm...@iana.org; mohamed.boucad...@orange.com
Cc: ie-doct...@ietf.org; opsawg@ietf.org
Subject: Re: [OPSAWG] [Ie-doctors] [IANA #1271817] expert review for 
draft-ietf-opsawg-ipfix-srv6-srh (ipfix)

IE-doctors already looked at this under [IANA #1240167] and [IANA #1263583].

I've reviewed draft-ietf-opsawg-ipfix-srv6-srh-08 and -09 which appeared during 
the review window.

(Editors, please don't move the goalposts while reviews are in progress!)



3.  New SRv6 IPFIX Information Elements
The definitions in section 3 are inconsistent with the "IANA Considerations" in 
section 5. Sometimes there is more detail in one section or the other. Section 
3 claims "This section specifies the new SRv6 IPFIX IEs." yet section 5 will 
update IANA's registry - so these two sections must be consistent. Please 
either use the exact same words in both sections, or entirely remove the 
duplicate definitions in section 3.

5. Note to the RFC-Editor:

I would put this note right at the top, immediately after the section 5 
header, and not after table 1.


5.1 srhFlagsIPv6 / Additional Information

Remove the space from the URL:  /ipv6- parameters/


5.* / Additional Information

In each case, please mention the specific section of the RFC. eg "See 
section 2 of RFC8754".


5.5. srhSegmentIPv6BasicList / Description

"segment list" versus "Segment List" ?


5.7. srhSegmentsIPv6Left / Description
8-bit unsigned integer defining the number of segments
remaining to reach the end of the segment list from the SRH, as
specified by the "Segments Left" field in Section 4.4 of 
[RFC8200]
and mentioned part of the SRH in Section 2 of 
[RFC8754]).
Consider "from" -> "in" and removing "part of the SRH" ?


5.9.1 Subregistry

Who will be the expert reviewers for the sub-registry? Is it IE-doctors, or 
SRH-experts, or another group?


5.10. srhSegmentIPv6LocatorLength / Description

The period has been lost from "SRv6 Locator."


5.11 srhSegmentIPv6EndpointBehavior / Additional Information
"Section 4 of RFC8986." has been added with no context. eg consider:
Additional Information: See section 4 of RFC8986 and the "SRV6 Endpoint 
Behavior" registry at
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors.

Also minor editorial comments:

"as series of octets" appears several times. Is "series" is plural, or 
should it be "as a series of octets" ?


7. Implementation Status

I would put this section in an appendix to avoid the need to renumber 
sections 8, 9, and 10 when this is removed.


P.

On 03/05/2023 00:08, David Dong via RT wrote:

Dear IE Doctors (cc: opsawg WG),



As the designated experts for the IPFIX Information Elements registry, can you 
review the proposed registration in draft-ietf-opsawg-ipfix-srv6-srh for us? 
Please see



https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/__;!!OSsGDw!Olm5L_aWqtbpGyxypC2dvr2pJ8APDlZbByuYeEV-WilsP91koTwzwOeZ8QMgLIkwPKxegSjgXszfsyzTIbeaC8w$
 [datatracker[.]ietf[.]org]



The due date is May 16th, 2023.



If this is OK, when the IESG approves the document for publication, we'll make 
the registration at:

Re: [OPSAWG] Jim Guichard's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-08: (with DISCUSS and COMMENT)

[Thomas.Graf]

Dear Jim,

Thank you very much for the review. We addressed your comments together with 
some minor editorial nits from Med in version -09 which just has been 
published. Below inline the feedback

Best wishes
Thomas


The IETF datatracker status page for this Internet-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-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-09


JG> The above needs to be fixed. OSPFv3 is not [RFC9352] and I assume that the 
reference should point to 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/, 
ietf-lsr-isis-srv6-extensions is an out-of-date reference as it is now 
https://www.rfc-editor.org/rfc/rfc9352, and RFC 9252 is "BGP Overlay Services 
Based on Segment Routing over IPv6 (SRv6)" that provides protocol extensions 
for SRv6-based BGP services.

TG> Thanks. References corrected.

JG> Section 4 of the referenced draft does not define new endpoint 
JG> behaviors for SRv6; the document defines new flavors for existing behaviors.

TG> Correct. Based on the endpoint behaviors the encoding of the segment list 
can be deducted. 
We adjusted the wording 

From

   The SID endpoint behaviors described in section 4 of
   [I-D.ietf-spring-srv6-srh-compression] determine wherever the segment
   list is compressed or not.

To

   The SR Endpoint Flavors, described in section 4 of
   [I-D.ietf-spring-srv6-srh-compression] defines new flavors for SID
   endpoint behaviors, and determine wherever the segment list encoding
   is compressed, along with the flavor.

JG> The above description is not technically accurate. While section 2 
JG> of RFC8754 does define the SRH, the 'Segments Left' field of the SRH is 
actually defined in Section 4.4 of RFC8200 
(https://www.rfc-editor.org/rfc/rfc8200#section-4.4) and RFC8754 points to that 
reference. Section 5.7 of this document should also point to the correct 
reference.

TG> Well spotted. We adjusted the wording as following to include both 
TG> references in the right context:

   srhSegmentsIPv6Left
  8-bit unsigned integer defining the number of segments remaining
  to reach the end of the segment list from the SRH, as specified by
  the "Segments Left" field in Section 4.4 of [RFC8200] and
  mentioned part of the SRH in Section 2 of [RFC8754]).

-Original Message-
From: Jim Guichard via Datatracker  
Sent: Wednesday, May 10, 2023 3:04 AM
To: The IESG 
Cc: draft-ietf-opsawg-ipfix-srv6-...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; mohamed.boucad...@orange.com; mohamed.boucad...@orange.com
Subject: Jim Guichard's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-08: (with 
DISCUSS and COMMENT)

Jim Guichard has entered the following ballot position for
draft-ietf-opsawg-ipfix-srv6-srh-08: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/



--
DISCUSS:
--

Section 1:

   Also, three routing protocol extensions, OSPFv3 [RFC9352], IS-IS
   [I-D.ietf-lsr-isis-srv6-extensions] and BGP Prefix Segment
   Identifiers(Prefix-SIDs) [RFC9252]

The above needs to be fixed. OSPFv3 is not [RFC9352] and I assume that the
reference should point to
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/,
ietf-lsr-isis-srv6-extensions is an out-of-date reference as it is now
https://www.rfc-editor.org/rfc/rfc9352, and RFC 9252 is "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)" that provides protocol extensions
for SRv6-based BGP services.

Section 3:

   srhSegmentsIPv6Left
  8-bit unsigned integer defining the number of segments remaining
  to reach the end of the segment list as defined in Section 2 of
  [RFC8754].

The above description is not technically accurate. While section 2 of RFC8754
does define the SRH, the 'Segments Left' field of the SRH is actually defined
in Section 4.4 of RFC8200 (https://www.rfc-editor.org/rfc/rfc8200#section-4.4)
and RFC8754 points to that reference. Section 5.7 of this document should also
point to the correct reference.

Section 5.9.1:

  | TBD15 | OSPFv3 | [RFC-to-be],   |
  |   | Segment Routing|   |
  +---++---+
  | 

Re: [OPSAWG] draft-boucla-opsawg-ipfix-fixes-04

[Thomas.Graf]

Dear Med and Benoit,

Excellent. Thank you very much for addressing this so quickly. The proposed 
changes make perfectly sense and addresses my concerns.

Indeed I was miss leaded by the IANA IPFIX registry indicating unisgned8 where 
RFC7270 defined unisgned32 for the IE89 forwardingStatus. Therefore 
reduced-size encoding makes perfectly sense now.

Best wishes
Thomas

From: mohamed.boucad...@orange.com 
Sent: Friday, May 5, 2023 11:48 AM
To: Benoit Claise ; Graf Thomas, INI-NET-VNC-HCS 
; opsawg@ietf.org
Cc: juans...@cisco.com; rjo...@cisco.com
Subject: RE: draft-boucla-opsawg-ipfix-fixes-04

Hi Benoît,

"To make it clear and avoid any issues (which I smell coming) with the 
IE-doctors at review time, I would make it very clear in the next version of 
the draft:
[IANA Note: this unsigned8 to unsigned32 is actually a bug, as 
https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 clearly mentions that 
the Abstract Data Type must be unsigned32]"
I went with the following:

NEW:
   The current entry in [IANA-IPFIX] deviates from what is provided in
  [RFC7270].  In particular, the registered Abstract Data Type is
  unsigned8, while it must be unsigned32.  The following update fixes
  that issue.  The description is also updated to clarify the use of
  the reduced-size encoding as per Section 6.2 of [RFC7011].

Cheers,
Med

De : Benoit Claise mailto:benoit.cla...@huawei.com>>
Envoyé : vendredi 5 mai 2023 11:04
À : thomas.g...@swisscom.com; 
opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : juans...@cisco.com; 
rjo...@cisco.com; me 
mailto:benoit.cla...@huawei.com>>
Objet : Re: draft-boucla-opsawg-ipfix-fixes-04

Dear Thomas,

Thanks for spotting this.
See inline.
On 5/3/2023 4:07 PM, thomas.g...@swisscom.com 
wrote:
Dear OPSAWG, Med and Benoit

Regarding section 6.2, forwardingStatus 
(https://datatracker.ietf.org/doc/html/draft-boucla-opsawg-ipfix-fixes-04#section-6.2).
 Section 4.12 of RFC 7270 
(https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12) describes that 
reduced-size encoding according to Section 6.2 of RFC 7011 
(https://www.rfc-editor.org/rfc/rfc7011#section-6.2) can be applied. Further 
Section 4.12 of RFC 7270 describes that "The basic encoding is 8 bits. The 
future extensions could add one or three bytes". The IANA IPFIX registry 
(https://www.iana.org/assignments/ipfix/ipfix.xhtml) reads unisgned8 for IE89 
forwardingStatus.

Recently we came across a vendor implementation which implemented IE89 
forwardingStatus with unsigned32 instead of unsigned8 already. This raised the 
following questions which I like to clarify here:


  1.  Does "The future extensions could add one or three bytes" means that data 
type can be changed from unsigned8 to unsigned32 today already or is a new RFC 
document needed to update the IPFIX entity?
Actually, this is clearly a bug in the IFPIX IANA registry.
https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 mentions unsigned32 
and it's not the case in the IPFIX IANA registry

  1.
  2.  Does " reduced-size encoding" also applies for increasing the field size?
No. That's the reason why unsigned32 must be in the IPFIX IANA registry

  1.  If yes, I find the wording rather misleading.
  2.  If IE89 forwardingStatus can be implemented in unsigned8, unsigned16 and 
unsigned32, shouldn't it be reflected in the IPFIX registry accordingly?

Depending on the answers we might take the opportunity with 
draft-boucla-opsawg-ipfix-fixes to update the IE89 forwardingStatus description.
As I mentions, this is a bug.
We can take the opportunity to include it in draft-boucla-opsawg-ipfix-fixes-05
Med did it, and this is perfect. Thanks.
To make it clear and avoid any issues (which I smell coming) with the 
IE-doctors at review time, I would make it very clear in the next version of 
the draft:
[IANA Note: this unsigned8 to unsigned32 is actually a bug, as 
https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 clearly mentions that 
the Abstract Data Type must be unsigned32]

Thanks to Thomas for the investigaiton and Med for the speedy reaction.

Regards, Benoit


Best wishes
Thomas


_



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;

Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-ipfix-srv6-srh-08

[Thomas.Graf]

Dear Tero, Med and Rob


Thanks a lot for the SECDIR review. Below the feedback from the authors inline.



Looking forward to your feedback and please let me know if we should proceed to 
add suggested paragraph in the security section for the document version.



Best wishes

Thomas





TK> On the other hand the 7012 security considerations say:



   The IPFIX information model itself does not directly introduce

   security issues.  Rather, it defines a set of attributes that may,

   for privacy or business issues, be considered sensitive information.



   For example, exporting values of header fields may make attacks

   possible for the receiver of this information; this would otherwise

   only be possible for direct observers of the reported Flows along the

   data path.



   The underlying protocol used to exchange the information described

   here must therefore apply appropriate procedures to guarantee the

   integrity and confidentiality of the exported information.  These

   protocols are defined in separate documents, specifically the IPFIX

   protocol document [RFC7011].



TK> Meaning that this document should explain whether any of the attributes

it exports have any privacy concerns, or whether it exports header values

which attacker might not otherwise have.



TK> So the security considerations should mention whether any of those

information elements it export has any privacy concerns or not

(and if so, add note that the protocol transporting these should

provide suitable security).



TG> The authors believe that the security consideration section in RFC7012

Are adequately describing what needs to be taken care to ensure privacy

concerns. However the following sentence helps the implementers

to remind what kind of data is being exported and privacy concerns shall be

properly addressed. We propose therefore to extend the Security Considerations

with the following paragraph in -09 version:



TG Example> Privacy Considerations described in Section 11.8 of [RFC7012] SHOULD

be considered for all described IEs. They export provider data plane metrics 
which

describe how packets are being forwarded within the SRv6 core network.



TK> Also this document allows two ways of exporting same information

(srhSegmentIpv6BasicList and srhSegmentIPv6ListSection). This always

causes a question what can someone do if it provides both but the values

are different? Can it cause that one data collector parses one list

and another data collector uses the other list, and can it then cause

differences in the collectors behavior based on which one they used?



TG> If the IPFIX metering process would implement srhSegmentIpv6BasicList

and srhSegmentIPv6ListSection differently, intentionally or unintentionally,

then this document describes, the IPFIX data collection process would simply

collect different values and a network operator would see that they won't match.

However this is a very unlikely scenario as the operational consideration states

since it does not make sense to implement both because they expose the same

information with a different structure. Even in the case of one collector 
receiving

srhSegmentIPv6BasicList and another one receiving srhSegmentIPv6ListSection,

the same conclusions hold.



TK> Are both of them allowed to be used at the same time? The operational

considerations say that:



   It is not expected that an exporter would support both

   srhSegmentIPv6BasicList and srhSegmentIPv6ListSection at the same

   time.



TG> The document doesn't prevent to implement both at the same time. The 
phrasing

Is correct.



TK> But it is not explained what happens if both are used at the same time,

and what happens if both are used but the contents is different?



TG> Besides that both would be exported, nothing else would happen.




Reviewer: Tero Kivinen
Review result: Has Issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document adds new information elements for transmitting segment routing
over IPv6 related information over IPFIX.

The security considerations section claims:

   There exists no significant extra security considerations regarding
   allocation of these new IPFIX IEs compared to [RFC7012].

The first question is that if there is no significant extra security
considerations, so what non-significant extra security considerations
there is?

On the other hand the 7012 security considerations say:

   The IPFIX information model itself does not directly introduce
   security issues.  Rather, it defines a set of attributes that may,
   for privacy or business issues, be considered sensitive information.

   For example, exporting values of header 

[OPSAWG] draft-boucla-opsawg-ipfix-fixes-04

[Thomas.Graf]

Dear OPSAWG, Med and Benoit

Regarding section 6.2, forwardingStatus 
(https://datatracker.ietf.org/doc/html/draft-boucla-opsawg-ipfix-fixes-04#section-6.2).
 Section 4.12 of RFC 7270 
(https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12) describes that 
reduced-size encoding according to Section 6.2 of RFC 7011 
(https://www.rfc-editor.org/rfc/rfc7011#section-6.2) can be applied. Further 
Section 4.12 of RFC 7270 describes that "The basic encoding is 8 bits. The 
future extensions could add one or three bytes". The IANA IPFIX registry 
(https://www.iana.org/assignments/ipfix/ipfix.xhtml) reads unisgned8 for IE89 
forwardingStatus.

Recently we came across a vendor implementation which implemented IE89 
forwardingStatus with unsigned32 instead of unsigned8 already. This raised the 
following questions which I like to clarify here:


  *   Does "The future extensions could add one or three bytes" means that data 
type can be changed from unsigned8 to unsigned32 today already or is a new RFC 
document needed to update the IPFIX entity?
  *   Does " reduced-size encoding" also applies for increasing the field size? 
If yes, I find the wording rather misleading.
  *   If IE89 forwardingStatus can be implemented in unsigned8, unsigned16 and 
unsigned32, shouldn't it be reflected in the IPFIX registry accordingly?

Depending on the answers we might take the opportunity with 
draft-boucla-opsawg-ipfix-fixes to update the IE89 forwardingStatus description.

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] POLL FOR IPR: A Data Manifest for Contextualized Telemetry Data

[Thomas.Graf]

Dear Joe,

No, I am not aware of any IPR applying to this draft.

Best wishes
Thomas

From: Joe Clarke (jclarke) 
Sent: Tuesday, May 2, 2023 12:20 AM
To: Benoit Claise ; jean.quilb...@huawei.com; IGNACIO 
DOMINGUEZ MARTINEZ-CASANUEVA ; 
diego.r.lo...@telefonica.com; Graf Thomas, INI-NET-VNC-HCS 

Cc: opsawg@ietf.org
Subject: POLL FOR IPR: A Data Manifest for Contextualized Telemetry Data

Authors and contributors on the To: line, 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

[OPSAWG] draft-boucadair-opsawg-ipfix-tcpo-v6eh-01

[Thomas.Graf]

Dear Med and Benoit,

Regarding adding a new IE ipv6ExtensionHeadersFull 
(https://datatracker.ietf.org/doc/html/draft-boucadair-opsawg-ipfix-tcpo-v6eh-01#section-3).

I would appreciate if that new IE ipv6ExtensionHeadersFull would support more 
than one extension header of the same kind.

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] I-D Action: draft-ietf-opsawg-ipfix-on-path-telemetry-02.txt

[Thomas.Graf]

Dear OPSAWG,

We updated the draft document to version -02 by adding the Implementation 
Status section. Reflecting what we have been testing/implementing during IETF 
116 hackathon.

The hackathon slides describing implementation details and use case be applied 
to can be found here:
https://github.com/IETF-Hackathon/ietf116-project-presentations/blob/main/ietf-116-hackathon-srv6-on-path-delay-anomaly-detection.pdf

Best wishes
Thomas

-Original Message-
From: OPSAWG  On Behalf Of internet-dra...@ietf.org
Sent: Monday, March 27, 2023 1:12 PM
To: i-d-annou...@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-on-path-telemetry-02.txt


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

   Title   : Export of On-Path Delay in IPFIX
   Authors : Thomas Graf
 Benoit Claise
 Alex Huang Feng
   Filename: draft-ietf-opsawg-ipfix-on-path-telemetry-02.txt
   Pages   : 23
   Date: 2023-03-26

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 datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/

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

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-on-path-telemetry-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

[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

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

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

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.

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 considerations using different IOAM Trace Option-Types;
 *   

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: this might be perceived as we are 

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

[Thomas.Graf]

Dear Jean,

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

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

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

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

Best wishes
Thomas

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

Dear All,
I support the adoption of this draft.

I have a few very minor comments below.

Best,
Jean


Section 1, paragraph 4:

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

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

Section 3.4.2

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

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

Section 3.4.2.3. (Max)

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


Section 6.2.X

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

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

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

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

[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] 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=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=05%7C01%7CThomas.Graf%40swisscom.com%7Cf3bfd5fa3dea48ca6a0d08dadf3ef5aa%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638067758737320741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=1X%2BI2yBo6C5NApGb053NIyCj2LYIdWlZWaxjbj0kr5A%3D=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=05%7C01%7CThomas.Graf%40swisscom.com%7Cf3bfd5fa3dea48ca6a0d08dadf3ef5aa%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638067758737320741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=yHPX83xmakzfCRJZMxdJ5oq9T3xHbvCN9C2HHMGYaDg%3D=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-=05%7C01%7CThomas.Graf%40swisscom.com%7Cf3bfd5fa3dea48ca6a0d08dadf3ef5aa%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638067758737320741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=xZjDt94k7d99AQtEzMjXpO7Im2XD8Cqhn3cqvMTpO24%3D=0
> srv6-srh-05
> 
> A diff from the previous version is available at:
> 

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=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 believe 

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

[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=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] 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=draft-tgraf-opsawg-ipfix-on-path-telemetry-00=--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

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

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 comments.

I visited 

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, I still 
don't see 

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=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] 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.txtdata=05%7C01%7CThomas.Graf%40swisscom.com%7Cd3828009bf9a48ac9e4908da70cc2814%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637946319390764912%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=jssrP7zcVggQzkmD7bjpbSbgMOlzRZF8t5eEb5PrCnQ%3Dreserved=0
Status: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-inband-telemetry%2Fdata=05%7C01%7CThomas.Graf%40swisscom.com%7Cd3828009bf9a48ac9e4908da70cc2814%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637946319390764912%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=seW1wx0O3XP%2Fjz0y8UECLqq74MwDYmqFE2zPR%2BBbhKI%3Dreserved=0
Htmlized:   
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-inband-telemetrydata=05%7C01%7CThomas.Graf%40swisscom.com%7Cd3828009bf9a48ac9e4908da70cc2814%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637946319390921142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2FPQz0IYAFjdjUtqu5sCm0ZqYjt8HdVe4zakxLSRD9K0%3Dreserved=0
Diff:   

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-01data=05%7C01%7CThomas.Graf%40swisscom.com%7Cc18fbb1e9fda48b71c6408da6e1e5884%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637943373849634565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=mCoyzP3JTr5Nw8OtAEQMjHiZMnS9sQ%2BiqOcQ7WqCIO8%3Dreserved=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 
> 

[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

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

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

[Thomas.Graf]

Dear OPSAWG and SPRING working group,

Thanks for the feedback on slide 7.

https://datatracker.ietf.org/meeting/113/materials/slides-113-opsawg-export-of-segment-routing-ipv6-information-in-ipfix-01
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-03

We understood it does not bring much added value to decompose the C-SID 
container into Compressed-SID (C-SID) in IPFIX and it does makes sense to add 
an operational consideration section to describe how an IPFIX data-collection 
could distinct between a list of IPv6 SID's and a list of C-SID containers.

Regarding the question wherever slide 7 also applies to G-SID defined in 
https://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-for-cmpr-04#section-3.1.
 Yes, in essencence the same alsop applies to G-SID and G-SID Container.

We will update the input in the upcoming -04 version. Further comments and 
input welcomed.

Regarding implementation status. We intend to release open-source VPP running 
code by IETF 115 hacktathon. One major network vendor commited on 
implementation and others showed interest.

Best wishes
Thomas

-Original Message-
From: Graf Thomas, INI-NET-TCZ-ZH1 
Sent: Sunday, March 6, 2022 8:46 AM
To: spring ; opsawg 
Subject: FW: New Version Notification for 
draft-tgraf-opsawg-ipfix-srv6-srh-02.txt

Dear OPSAWG and SPRING working group,

Based on the feedbacks I received, I updated the document. 

Apart from the small editorial changes, the following points have been addressed

- updated IANA sections according to RFC 8126
- added ipv6SRHSegmentListSection to facilitate immediate export without data 
flow manipulation
- added Operational Considerations section to described differences between 
ipv6SRHSegmentBasicList and ipv6SRHSegmentListSection

Looking forward for further reviews and comments.

Based wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Sunday, March 6, 2022 8:35 AM
To: Benoit Claise ; Graf Thomas, INI-NET-TCZ-ZH1 

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


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

Name:   draft-tgraf-opsawg-ipfix-srv6-srh
Revision:   02
Title:  Export of Segment Routing IPv6 Information in IP Flow 
Information Export (IPFIX)
Document date:  2022-03-06
Group:  Individual Submission
Pages:  12
URL:
https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-srv6-srh-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-srv6-srh/
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-02

Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   information elements to identify the SRv6 Segment Routing Header
   dimensions and SRv6 Control Plane Protocol 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-srv6-srh-02.txt

[Thomas.Graf]

Dear OPSAWG and SPRING working group,

Based on the feedbacks I received, I updated the document. 

Apart from the small editorial changes, the following points have been addressed

- updated IANA sections according to RFC 8126
- added ipv6SRHSegmentListSection to facilitate immediate export without data 
flow manipulation
- added Operational Considerations section to described differences between 
ipv6SRHSegmentBasicList and ipv6SRHSegmentListSection

Looking forward for further reviews and comments.

Based wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Sunday, March 6, 2022 8:35 AM
To: Benoit Claise ; Graf Thomas, INI-NET-TCZ-ZH1 

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


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

Name:   draft-tgraf-opsawg-ipfix-srv6-srh
Revision:   02
Title:  Export of Segment Routing IPv6 Information in IP Flow 
Information Export (IPFIX)
Document date:  2022-03-06
Group:  Individual Submission
Pages:  12
URL:
https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-srv6-srh-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-srv6-srh/
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-02

Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   information elements to identify the SRv6 Segment Routing Header
   dimensions and SRv6 Control Plane Protocol 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] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-01.txt

[Thomas.Graf]

Dear OPSAWG and SPRING working group,

Based on the feedbacks I received on and off list, I updated the document. 

Apart from the small editorial changes, the following points have been addressed

- added ipv6SRHSection to expose the SRH and it's TLV's in one IE
- added ipv6SRHSegmentsLeft to expose how many SID's are left to be considered 
for forwarding

Looking forward for further reviews and comments.

Based wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Friday, February 18, 2022 2:48 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 
Subject: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-01.txt


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

Name:   draft-tgraf-opsawg-ipfix-srv6-srh
Revision:   01
Title:  Export of Segment Routing IPv6 Information in IP Flow 
Information Export (IPFIX)
Document date:  2022-02-18
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-srv6-srh-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-srv6-srh/
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-01

Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   information elements to identify the SRv6 Segment Routing Header
   dimensions and SRv6 Control Plane Protocol 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

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

[Thomas.Graf]

Hi Greg,

Thanks for bringing that question up. I already considered this aspect.


As described in 
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-00.html#section-2,
 the compressed-SID container (C-SID container) is 128-bit long and contains a 
sequence of C-SIDs. Therefore the ipv6SRHSegmentList

contains either a list of IPv6 SID's, a list of compressed-SID containers or 
both. They are not mutually exclusive.



It probably makes sense to add an operational consideration section in 
draft-tgraf-opsawg-ipfix-srv6-srh to describe the use of C-SID containers and 
its context to ipv6SRHSegmentType. From what I understood, and here I would 
like to have feedback from the mailing list, it does not bring much added value 
to decompose the C-SID container into Compressed-SID (C-SID) in IPFIX.



Best wishes

Thomas

From: Greg Mirsky 
Sent: Sunday, February 13, 2022 10:04 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 
Cc: liu.ya...@zte.com.cn; spring ; opsawg 
Subject: Re: [spring] New Version Notification for 
draft-tgraf-opsawg-ipfix-srv6-srh-00.txt

Hi Thomas, et al.,
what do you think of the new SPRING WG draft that introduces two methods of the 
compressed SRv6 SID list encoding in the 
SRH?

Regards,
Greg

On Sat, Feb 12, 2022 at 12:10 AM 
mailto:thomas.g...@swisscom.com>> wrote:
Dear Yao,

Thanks a lot for the detailed description. Both understood,  acknowledged and 
being merged to the -01 version. Feedback welcome.

https://www.ietf.org/rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-00.txt=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-01.txt

I will publish -01 in the upcoming weeks before IETF 113.

Best wishes
Thomas

-Original Message-
From: liu.ya...@zte.com.cn 
mailto:liu.ya...@zte.com.cn>>
Sent: Monday, February 7, 2022 10:42 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 
mailto:thomas.g...@swisscom.com>>
Cc: spr...@ietf.org
Subject: Re:[spring] New Version Notification for 
draft-tgraf-opsawg-ipfix-srv6-srh-00.txt

Hi Thomas,

Sorry for the late reply. Please see inline [Yao2].
> [Yao] Segments left is one of the elements to identify an SRH. For example, 
> (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) 
> (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also 
> useful when exporting SRv6 information.
Would you agree that ipv6SRHSegmentList at node egress would be equal to 
Segments left? Or in other words segments left would only differ at ingress to 
ipv6SRHSegmentList. Correct? If yes, than I think I got your point. Would you 
please describe me what kind of use case you have in mind.
[Yao2] I mean without segment left, it's difficult to distinguish between 
packets of the same segment list in some cases.
Below is one scenario I can think of. The corresponding segment list of path 
1--A--2--3--1--A--4 is .
3
  /   \
 / \
1   2
 \ /
  \   /
A-4
The flow passes node A twice.
The first time, the packet is 
(SA,DA=SID-A).
The second time, the packet is 
(SA,DA=SID-A).
If one wants to collect the info of these two traffic separately, the segment 
left element is needed.
But to be honest, I'm not sure whether this requirement is strong.

> [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while 
> other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are 
> defined. What if the user want to export the SRH TLV info of the packets?
You mean the entire SRH header without disassemble the dimensions into IPFIX 
entities. Like IE 316 mplsLabelStackSection. Correct? I think this makes a lot 
of sense and I consider this to the -01 version of the document.
[Yao2] Yes, that's what I mean.

Best Regards,
Yao

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

[Thomas.Graf]

Dear OPSAWG,

Following up on just released RFC 9160 
(https://datatracker.ietf.org/doc/html/rfc9160), IPFIX code points for MPLS 
Segment Routing,

https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh has 
been submitted for the SRV6 data-plane.

The document aims to be on par with MPLS-SR. Describe the routing protocol or 
PCEP extension where the last SRv6 segment has been learned from, the SRv6 
segment list and all other properties from the Segment Routing header.

I would appreciate your document review and feedback.

I aim to present at IETF 113 at OPSAWG and SPRING and request adoption at 
OPSAWG.

Best wishes
Thomas

-Original Message-
From: internet-dra...@ietf.org  
Sent: Saturday, January 15, 2022 10:12 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 
Subject: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt


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

Name:   draft-tgraf-opsawg-ipfix-srv6-srh
Revision:   00
Title:  Export of Segment Routing IPv6 Information in IP Flow 
Information Export (IPFIX)
Document date:  2022-01-15
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-srv6-srh-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-srv6-srh/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh


Abstract:
   This document introduces new IP Flow Information Export (IPFIX) code
   points to identify which traffic is being forwarded with which
   Segemnt Routing Header dimensions based on which SRv6 control plane
   protocol.


  


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] Benjamin Kaduk's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

[Thomas.Graf]

Dear Rob, Med and IESG

Based on Ben's feedback, I submitted the final -11 version.

https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-11

I think the document is ready now for the RFC editor queue.

Best wishes
Thomas

-Original Message-
From: Benjamin Kaduk  
Sent: Tuesday, September 14, 2021 1:57 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 
Cc: i...@ietf.org; draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org; mohamed.boucad...@orange.com
Subject: Re: Benjamin Kaduk's No Objection on 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

Hi Thomas,

Many thanks; that looks like it should work quite nicely.

-Ben

On Sat, Sep 11, 2021 at 07:46:17AM +, thomas.g...@swisscom.com wrote:
> Hi Benjamin,
> 
> Thanks for the clarifications and suggestions. Very much appreciated.
> 
> > I think it would be good to add a few words to hint at dimensional 
> > modeling, and maybe also to add a few words to clarify why 
> > draft-hegde-spring-mpls-seamless-sr is being referenced.
> 
> I put additional thoughts into that paragraph and changed the reference to 
> RFC 8670 (BGP Prefix Segment in Large-Scale Data Centers) instead. RFC 7983 
> (Use of BGP for Routing in Large-Scale Data Centers)  describes the use of 
> BGP labeled-unicast in large data center environments. Where RFC 8670 focuses 
> on using Segmenting Routing with BGP by using the same architecture. RFC 8670 
> describes the motivation of such a migration and is a stable document. I hope 
> this makes more sense now.
> 
>Also, [I-D.ali-spring-sr-traffic-accounting] describes how IP Flow
>Information Export [RFC7012] can be leveraged in dimensional data
>modelling to account traffic to MPLS SR label dimensions within a
>Segment Routing domain.
> 
>Another use case is to monitor MPLS control plane migrations from
>dynamic BGP labels [RFC8277] to BGP Prefix-SIDs [RFC8669].  The
>motivation and benefits for such a migration is described in
>[RFC8670].
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2F%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fraw.githubusercontent.com
> %2Fgraf3net%2Fdraft-tgraf-ipfix-mpls-sr-label-type%2Fmaster%2Fdraft-ie
> tf-opsawg-ipfix-mpls-sr-label-type-10.txt%26url2%3Dhttps%3A%2F%2Fraw.g
> ithubusercontent.com%2Fgraf3net%2Fdraft-tgraf-ipfix-mpls-sr-label-type
> %2Fmaster%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txtdata
> =04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123c
> d4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480108639%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C1000sdata=6J6eFY%2FHjJWFUIKugTO%2F0q%2FhSUm9a
> 54DE8qV2LSCa3E%3Dreserved=0
> 
> Let me know your thoughts.
> 
> Best wishes
> Thomas
> 
> -Original Message-
> From: Benjamin Kaduk 
> Sent: Saturday, September 11, 2021 4:02 AM
> To: Graf Thomas, INI-NET-TCZ-ZH1 
> Cc: i...@ietf.org; 
> draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; 
> opsawg-cha...@ietf.org; opsawg@ietf.org; mohamed.boucad...@orange.com
> Subject: Re: Benjamin Kaduk's No Objection on 
> draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)
> 
> Hi Thomas,
> 
> On Thu, Sep 09, 2021 at 05:19:00AM +, thomas.g...@swisscom.com wrote:
> > Hi Benjamin,
> > 
> > > I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of 
> > > maturity to be a good reference here (and thus, that this example is 
> > > worth including).  
> > I agree. The only alternative is to reference 
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-mpls-seamless-mpls-07data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480108639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=W9Y9RGobCEdshkILs7JeW2HpAE3T%2BdJ322XTfbD9STo%3Dreserved=0
> >  instead. The challenge is that Seamless MPLS is widely supported and used 
> > at network vendors and operators but not yet standardized at IETF. Both 
> > Seamless MPLS drafts are either in progress or expired. If you don't 
> > object, I like to keep that example and reference for not having a better 
> > alternative.
> 
> To be clear, I don't have issues with referring to an individual draft in the 
> abstract.  It's more that for this particular draft, I came away very unsure 
> what I was supposed to take away from reading it that made it worth 
> referencing.  It would probably be possible to add more words to 
> draft-ietf-opsawg-ipfix-mpls-sr-label-type to help me know what to look for 
> in draft-hedge-spring-mpls-seamless-sr, or to make edits to 
> draft-hegde-spring-mpls-seamless-sr itself (or both), to help clarify what's 
> interesting about it that we want the reader to think about.  Since I am 
> still unclear on 

Re: [OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

[Thomas.Graf]

Hi Benjamin,

Thanks for the clarifications and suggestions. Very much appreciated.

> I think it would be good to add a few words to hint at dimensional modeling, 
> and maybe also to add a few words to clarify why 
> draft-hegde-spring-mpls-seamless-sr is being referenced.

I put additional thoughts into that paragraph and changed the reference to RFC 
8670 (BGP Prefix Segment in Large-Scale Data Centers) instead. RFC 7983 (Use of 
BGP for Routing in Large-Scale Data Centers)  describes the use of BGP 
labeled-unicast in large data center environments. Where RFC 8670 focuses on 
using Segmenting Routing with BGP by using the same architecture. RFC 8670 
describes the motivation of such a migration and is a stable document. I hope 
this makes more sense now.

   Also, [I-D.ali-spring-sr-traffic-accounting] describes how IP Flow
   Information Export [RFC7012] can be leveraged in dimensional data
   modelling to account traffic to MPLS SR label dimensions within a
   Segment Routing domain.

   Another use case is to monitor MPLS control plane migrations from
   dynamic BGP labels [RFC8277] to BGP Prefix-SIDs [RFC8669].  The
   motivation and benefits for such a migration is described in
   [RFC8670].

https://www.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-10.txt=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txt

Let me know your thoughts.

Best wishes
Thomas

-Original Message-
From: Benjamin Kaduk  
Sent: Saturday, September 11, 2021 4:02 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 
Cc: i...@ietf.org; draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org; mohamed.boucad...@orange.com
Subject: Re: Benjamin Kaduk's No Objection on 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

Hi Thomas,

On Thu, Sep 09, 2021 at 05:19:00AM +, thomas.g...@swisscom.com wrote:
> Hi Benjamin,
> 
> > I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of 
> > maturity to be a good reference here (and thus, that this example is worth 
> > including).  
> I agree. The only alternative is to reference 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-mpls-seamless-mpls-07data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268212042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZE7ap4WzesHE5wOJstYpopUlqTm8AJDiFZ91CyTlVBg%3Dreserved=0
>  instead. The challenge is that Seamless MPLS is widely supported and used at 
> network vendors and operators but not yet standardized at IETF. Both Seamless 
> MPLS drafts are either in progress or expired. If you don't object, I like to 
> keep that example and reference for not having a better alternative.

To be clear, I don't have issues with referring to an individual draft in the 
abstract.  It's more that for this particular draft, I came away very unsure 
what I was supposed to take away from reading it that made it worth 
referencing.  It would probably be possible to add more words to 
draft-ietf-opsawg-ipfix-mpls-sr-label-type to help me know what to look for in 
draft-hedge-spring-mpls-seamless-sr, or to make edits to 
draft-hegde-spring-mpls-seamless-sr itself (or both), to help clarify what's 
interesting about it that we want the reader to think about.  Since I am still 
unclear on what the important concepts are, I unfortunately don't have any 
concrete suggestions for what that text could be.

> > For example, the referenced section refers to "option A", "option B", and 
> > "option C" but I couldn't find where in the document these options were 
> > enumerated as such.  
> That refers to RFC4364 section 10. 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4364%23section-10data=04%7C01%7CThomas.Graf%40swisscom.com%7C8bbd8fe2f05c4b6c1b7f08d974c82720%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637669225268217020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7fB48K9MprNUDazBaASPc1PmYiCYeCwhS4VAFAuxwPU%3Dreserved=0.
>  And yes, the author should include the reference for clarity. I will follow 
> up on that.

Thanks for following up; having that reference from 
draft-hegde-spring-mpls-seamless-sr would have been very helpful.

> >I don't understand the word "dimensions" in this context.  (It 
> >doesn't appear in the referenced documents, either, which suggests 
> >that a different word may have been intended.)
> 
> Regarding: account traffic to MPLS SR label dimensions
> 
> In data engineering, metrics are divided into two groups. Dimensions 
> 

Re: [OPSAWG] Alvaro Retana's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

[Thomas.Graf]

Hi Alvaro,

Thanks for the feedback. It appears I need reading glasses. 

I added a IANA note for moving the RFC references from the additional 
information to the reference column.  

https://www.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-10.txt=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txt

As soon as I have the feedback from Benjamin, I will submit -11 and move 
forward to the RFC editor queue. 

Best wishes
Thomas


-Original Message-
From: Alvaro Retana  
Sent: Thursday, September 9, 2021 6:11 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; i...@ietf.org
Cc: opsawg-cha...@ietf.org; 
draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; 
mohamed.boucad...@orange.com; opsawg@ietf.org
Subject: RE: Alvaro Retana's No Objection on 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

On September 5, 2021 at 2:45:59 AM, thomas.g...@swisscom.com wrote:


Thomas:

Hi!

...
> Regarding the second remark. Updating the "Additional Information" in 
> the IPFIX Information Elements registry for mplsTopLabelType.
>
> Throughout the process we had a lengthy exchange with IANA and the IE 
> doctors what the best course of action is since "Additional 
> Information" is not publicly visible. We came to the conclusion that 
> this is addressed best by adding the RFC which is describing the code point 
> to the "Reference"
> column.

The "Additional Information" column *is* publicly visible -- that is how I 
found it. ;-)

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fipfix%2Fipfix.xhtml%23ipfix-information-elementsdata=04%7C01%7CThomas.Graf%40swisscom.com%7C4b2206a9ee624de0a93808d973ac7840%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637668006849700536%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=MQPTRcTrtgJJM4IuF%2BgI9Byy0rLRoIVKlWVaxW4wV98%3Dreserved=0


> I could add an IANA remark that for the existing entries in 
> mplsTopLabelType, the RFC references described in "Additional 
> Information" could be moved to the reference column.

That works for me -- I'm assuming you would also add a reference to this 
document, right?

What about the current text in "Additional Information"?  If it is left as-is, 
I think may still look incomplete (regardless of what the reference column 
points to).

Thanks!

Alvaro.

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

Re: [OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

[Thomas.Graf]

Hi Benjamin,

> I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of 
> maturity to be a good reference here (and thus, that this example is worth 
> including).  
I agree. The only alternative is to reference 
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls-07 instead. 
The challenge is that Seamless MPLS is widely supported and used at network 
vendors and operators but not yet standardized at IETF. Both Seamless MPLS 
drafts are either in progress or expired. If you don't object, I like to keep 
that example and reference for not having a better alternative.

> For example, the referenced section refers to "option A", "option B", and 
> "option C" but I couldn't find where in the document these options were 
> enumerated as such.  
That refers to RFC4364 section 10. 
https://datatracker.ietf.org/doc/html/rfc4364#section-10. And yes, the author 
should include the reference for clarity. I will follow up on that.

>I don't understand the word "dimensions" in this context.  (It doesn't appear 
>in the referenced documents, either, which suggests that a different word may 
>have been intended.)

Regarding: account traffic to MPLS SR label dimensions

In data engineering, metrics are divided into two groups. Dimensions 
(https://www.merriam-webster.com/dictionary/dimension) and measurements 
(https://www.merriam-webster.com/dictionary/measurement). Dimensions are 
important for Dimensional data modelling 
(https://en.wikipedia.org/wiki/Dimensional_modeling). To give measurements 
context. I agree that the words dimensions and measurements aren't widely used 
at IETF in such a context.

> The most that I would suggest changing is to add the word "significant", for 
> "no significant extra security considerations".
Acknowledged and merged into -09 version.

> I suggest dropping the word "new", which is a relative term and will be less 
> and less applicable over time.
Acknowledged and merged into -09 version.

I am going to publish -09 version once all the IESG reviews are concluded. Here 
the inputs I received and merged so far
https://www.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-08.txt=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-09.txt

Best wishes
Thomas

-Original Message-
From: Benjamin Kaduk via Datatracker  
Sent: Wednesday, September 8, 2021 7:01 PM
To: The IESG 
Cc: draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org; mohamed.boucad...@orange.com; 
mohamed.boucad...@orange.com
Subject: Benjamin Kaduk's No Objection on 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.htmldata=04%7C01%7CThomas.Graf%40swisscom.com%7C3a44f339ab3b45c7707108d972ea4921%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637667172840885226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cqmEKyd5B0ZoBK0kTMNF1%2BnOFoyJ2%2FmyPNVRoLvEXTA%3Dreserved=0
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7C3a44f339ab3b45c7707108d972ea4921%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637667172840885226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NRFVezr2O2J6IyAiXvlXm%2BdXFtZIyS1aM1tGUaDLJ2Q%3Dreserved=0



--
COMMENT:
--

This document presents a couple use cases for the new IE 46 codepoints, but 
both are in the context of monitoring the rollout of a migration of 
control-plane technology.  Are there steady-state use cases for these values?

Section 2

   Another use case is to monitor MPLS control plane migrations from
   dynamic BGP labels [RFC8277] to BGP Prefix-SIDs in the context of
   Seamless MPLS SR described in Section 4.6 of
   [I-D.hegde-spring-mpls-seamless-sr].

I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of maturity 
to be a good reference here (and thus, that this example is worth including).  
For example, the referenced section refers to "option A", "option B", and 
"option C" 

Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

[Thomas.Graf]

Hi Eric,

Thanks a lot for the review and the comment. I am not sure to which IE you are 
referring to.  The first encounter in the document is in section 1 where it is 
expanded.

   In [RFC7012], the Information Element (IE) mplsTopLabelType(46)
   identifies which MPLS control plane protocol allocated the top-of-
   stack label in the MPLS label stack.  Section 7.2 of [RFC7012]
   creates the "IPFIX MPLS label type (Value 46)" subregistry
   [IANA-IPFIX] where MPLS label type should be added.  This document
   defines new code points to address typical use cases that are
   discussed in Section 2.

Maybe I miss something. Thanks for a brief clarification.

Best wishes
Thomas

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: Monday, September 6, 2021 3:26 PM
To: The IESG 
Cc: draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org; mohamed.boucad...@orange.com; 
mohamed.boucad...@orange.com
Subject: Éric Vyncke's No Objection on 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.htmldata=04%7C01%7CThomas.Graf%40swisscom.com%7C93131a2d1c13499a377808d97139db5a%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637665315572093115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=H%2FOEEBHBT9YXhskb6u7s%2F%2FrdfdovIRAnO1ssAFeKZIk%3Dreserved=0
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7C93131a2d1c13499a377808d97139db5a%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637665315572093115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TKJwqgsWY01S7KoP6t5nZuSewZzRL4Uq5jp1N8sIAdY%3Dreserved=0



--
COMMENT:
--

Thank you for the work put into this document.

I have only one suggestion: expand "IE" on the first use.

Special thanks to Med Boucadair for his detailed shepherd's write-up notably 
about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric




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

Re: [OPSAWG] Alvaro Retana's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

[Thomas.Graf]

Hi Alvaro,

Many thanks for the review and the remarks.

I added the PCEP SR extension to the document version -09 which I haven't 
published yet. Here the diff

http://www.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-08.txt=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-09.txt

I would appreciate Alvaro, Rob and Med for a quick review and let me know when 
I should publish the update.

Regarding the second remark. Updating the "Additional Information" in the IPFIX 
Information Elements registry for mplsTopLabelType.

Throughout the process we had a lengthy exchange with IANA and the IE doctors 
what the best course of action is since "Additional Information" is not 
publicly visible. We came to the conclusion that this is addressed best by 
adding the RFC which is describing the code point to the "Reference" column. 

I could add an IANA remark that for the existing entries in mplsTopLabelType, 
the RFC references described in "Additional Information" could be moved to the 
reference column.

Let me know your thoughts. I will then double check with Med, IANA and the IE 
doctors if they support and update the document.


  +---++--+
  | Value |  Description   |  Reference   |
  +---++--+
  | TBD1  | Path Computation Element   | [RFC-to-be], RFC8664 |
  +---++--+
  | TBD2  | OSPFv2 Segment Routing | [RFC-to-be], RFC8665 |
  +---++--+
  | TBD3  | OSPFv3 Segment Routing | [RFC-to-be], RFC8666 |
  +---++--+
  | TBD4  | IS-IS Segment Routing  | [RFC-to-be], RFC8667 |
  +---++--+
  | TBD5  | BGP Segment Routing Prefix-SID | [RFC-to-be], RFC8669 |
  +---++--+


Best wishes
Thomas

-Original Message-
From: Alvaro Retana via Datatracker  
Sent: Friday, September 3, 2021 9:04 PM
To: The IESG 
Cc: draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; 
opsawg-cha...@ietf.org; opsawg@ietf.org; mohamed.boucad...@orange.com
Subject: Alvaro Retana's No Objection on 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.htmldata=04%7C01%7CThomas.Graf%40swisscom.com%7Ce0245989d4ce40d0cded08d96f0da6d6%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637662926682829654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=XSxsFdRPCgH0dL4e8E5lOzCyxAfwby7bsN5JAJEjAYM%3Dreserved=0
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7Ce0245989d4ce40d0cded08d96f0da6d6%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637662926682829654%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=K16zrTMek0EkKVRNsGdkscWbkFIj46E0RBoJKZKDgAw%3Dreserved=0



--
COMMENT:
--

(1) The SR labels can also be programmed by a PCE (rfc8664).  For completeness, 
it would be very nice if a codepoint was also allocated for that.

(2) The "Additional Information" field in the IPFIX Information Elements 
registry includes information about mplsTopLabelType that will now be 
incomplete -- it currently says:

   See [RFC3031] for the MPLS label structure. See [RFC4364] for the
   association of MPLS labels with Virtual Private Networks (VPNs).
   See [RFC4271] for BGP and BGP routing. See [RFC5036] for Label
   Distribution Protocol (LDP). See the list of MPLS label types
   assigned by IANA at 

Re: [OPSAWG] AD review of draft-ietf-opsawg-ipfix-mpls-sr-label-type-05

[Thomas.Graf]

Hi Rob,

Excellent. Many thanks for the AD review and comments.

I updated and posted the draft -06 version accordingly.

Best wishes
Thomas

-Original Message-
From: Rob Wilton (rwilton)  
Sent: Thursday, July 1, 2021 8:17 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; 
draft-ietf-opsawg-ipfix-mpls-sr-label-type@ietf.org; 
mohamed.boucad...@orange.com
Cc: opsawg@ietf.org; opsawg-cha...@ietf.org
Subject: AD review of draft-ietf-opsawg-ipfix-mpls-sr-label-type-05

Hi Thomas,

This is my AD review of draft-ietf-opsawg-ipfix-mpls-sr-label-type-05.

Thanks for the draft, it is both short and sweet, and I have only a few minor 
comments/suggestions:

1. In the abstract, I would suggest changing on which MPLS control plane 
protocol within => the MPLS control plane protocol used within

2. Please add a reference to RFC 7012 in the IANA registrations.

E.g., something like:

   This document requests IANA to allocate the following code points in
   the existing subregistry "IPFIX MPLS label type (Value 46)" under the
   "IPFIX Information Elements" registry [RFC7012] available at [IANA-IPFIX].

3. Two minor nits:

Also [I-D.ali-spring-sr-traffic-accounting] => Also, 
[I-D.ali-spring-sr-traffic-accounting]

I would like to thank to =>
I would like to thank

Please post an updated draft with these changes, then let me know and I'll kick 
off the IETF LC.

Med, thanks for the good shepherd writeup, it is both clear and informative.

Thanks,
Rob


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

Re: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

[Thomas.Graf]

Dear Tianran, Med and Tom

Thanks a lot for the discussion wherever the document intend should be standard 
or informational. 

Also after reviewing RFC 1796 and RFC 2026, I agree that current content and 
language of the draft aren't normative enough to qualify to be on the standard 
track. To me as the author I feel more comfortable to change the intend to 
informational instead of changing the language to be more normative and 
describe in more detail where the new code points MUST (or SHOULD) be used and 
where the existing BGP code points MUST NOT be used. 

Therefore I changed the intend and updated the draft to -05 version.

I hope this makes sense. Looking forward for the feedback from the list.

Best wishes
Thomas

-Original Message-
From: tom petch  
Sent: Thursday, June 24, 2021 5:34 PM
To: mohamed.boucad...@orange.com; Tianran Zhou ; 
draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; opsawg-cha...@ietf.org
Cc: opsawg@ietf.org
Subject: Re: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

From: mohamed.boucad...@orange.com 
Sent: 24 June 2021 13:57

Hi Tom,

That's an interesting approach, indeed. However, one may object this is 
speculating about future use. No?


It is speculating about whether or not this data will ever be needed to be 
referred to in a Normative manner.  I keep seeing examples where it is, but the 
authors have not allowed for that, as with YANG modules.  Talking of YANG 
modules, almost every one I see is short of reference clauses, judged by the 
standards of 'YANG Guidelines', and sometimes the reason is because that would 
be a DownRef and that is hassle.  I think that YANG reference clauses have 
tilted the playing field and that the IESG will catch up with that in time, 
even if the letter of the law lags behind.  A reference to an IANA registry is 
usually second-best because all that does is point to the real source of 
information. the RFC that defined the concept or the value.

Tom Petch



Please note that IPFIX types (in general, not only this I-D) can be used in 
YANG modules without having to cite an RFC. The authoritative reference would 
be the IANA registry itself. I'm thinking about an IANA-maintained IPFIX module 
that would echo the content of the current registry.

Cheers,
Med

> -Message d'origine-
> De : tom petch [mailto:ie...@btconnect.com] Envoyé : jeudi 24 juin 
> 2021 12:20 À : Tianran Zhou ; BOUCADAIR 
> Mohamed INNOV/NET ; 
> draft-ietf-opsawg-ipfix- mpls-sr-label-t...@ietf.org; 
> opsawg-cha...@ietf.org Cc : opsawg@ietf.org Objet : Re: Shepherd 
> Review of draft-ietf-opsawg-ipfix-mpls-sr- label-type
>
> From: OPSAWG  on behalf of Tianran Zhou 
> 
> Sent: 24 June 2021 07:34
> To: mohamed.boucad...@orange.com; draft-ietf-opsawg-ipfix-mpls-sr- 
> label-t...@ietf.org; opsawg-cha...@ietf.org
>
> Hi Med,
>
> Your capture is correct.
> Let's go through the more complete definition of "informational", but 
> ignore the "consensus" part.
>
> 
> A slightly different, pragmatic consideration is that Normative 
> References to Informational documents create more work, some hassle.
> I see this regularly with YANG modules which SHOULD have reference 
> clauses referring to the source of a definition and often this is an 
> informational model which has been given Informational status; wrong 
> IMHO.
>
> So if these values are ever going to be referenced, by such as  a YANG 
> module, then Standards Track is more straightforward.
>
> Tom Petch
>
> "An "Informational" specification is published for the general 
> information of the Internet community, and does not represent an 
> Internet community consensus or recommendation. The Informational 
> designation is intended to provide for the timely publication of a 
> very broad range of responsible informational documents from many 
> sources, subject only to editorial considerations and to verification 
> that there has been adequate coordination with the standards process 
> (see section 4.2.3)."
>
> It seems this draft is not intended only to provide information as 
> described in the further explanation.
> What's your thoughts?
>
> Best,
> Tianran
>
> From: mohamed.boucad...@orange.com
> [mailto:mohamed.boucad...@orange.com]
> Sent: Thursday, June 24, 2021 1:24 PM
> To: Tianran Zhou ; draft-ietf-opsawg-ipfix- 
> mpls-sr-label-t...@ietf.org; opsawg-cha...@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr- 
> label-type
>
> Hi Tianran, all,
>
> Please see inline.
>
> Cheers,
> Med
>
> De : Tianran Zhou [mailto:zhoutian...@huawei.com] Envoyé : jeudi 24 
> juin 2021 05:09 À : BOUCADAIR Mohamed INNOV/NET 
> mailto:mohamed.boucad...@orange.com>>;
> draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org>; opsawg- 
> cha...@ietf.org
> Cc : opsawg@ietf.org
> Objet : RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr- 
> 

Re: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

[Thomas.Graf]

Hi Med,

Thanks for the promptly feedback. I updated to -04 version according to your 
input.

https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-04

All lines now within 72 characters. Added the "." as described and reverted 
back to the previous paragraph and included your input.

Best wishes
Thomas

From: mohamed.boucad...@orange.com 
Sent: Thursday, June 24, 2021 7:39 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 
Subject: RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Re-,

I forgot to mention this one about this long sentence:


"
   Both use cases can be verified by using mplsTopLabelType(46),
   mplsTopLabelIPv4Address(47), mplsTopLabelIPv6Address(140),
   mplsTopLabelStackSection(70) and forwardingStatus(89) IEs to infer

   how many packets are forwarded or dropped to which MPLS provider edge


   loopback address and label protocol, and if dropped for which
   reasons.
"

I don't parse the part I highlighted. I prefer what you had in the previous 
version, though.

Thanks.

Cheers,
Med

De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de 
mohamed.boucad...@orange.com
Envoyé : jeudi 24 juin 2021 07:35
À : thomas.g...@swisscom.com; 
draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org;
 opsawg-cha...@ietf.org
Cc : opsawg@ietf.org
Objet : Re: [OPSAWG] Shepherd Review of 
draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Thomas,

Thank you for promptly addressing the comments.

Looks good to me, but idnits is still not happy with these long lines of Table 
1:

==
  ** There are 12 instances of too long lines in the document, the longest
 one being 2 characters in excess of 72.
==

One very very minor nit:

OLD:
   These values are thus used for those
   distinct purposes
NEW:
   These values are thus used for those
   distinct purposes.

For the intended status, I'm still not convinced we have valid arguments for 
it. Let's see how to fix that.

Cheers,
Med

De : thomas.g...@swisscom.com 
[mailto:thomas.g...@swisscom.com]
Envoyé : jeudi 24 juin 2021 06:23
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; 
draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org;
 opsawg-cha...@ietf.org
Cc : opsawg@ietf.org
Objet : RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Med,

Many thanks for the shepherd review. I updated the document accordingly into 
-03 version.

https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-03

I included all your suggestions and followed your example in using 
abbreviations and changed the term "MPLS Segment Routing"
To "MPLS SR" throughout the document. The same for the term "subregistry" 
instead of "sub-registry" or "SubRegistry".

I took the liberty to further simplify the use case paragraph in section 2. I 
hope it is better readable now. Looking forward to your review.

Below in detail where I deviated to your suggestions. Mostly minor.

Regarding wherever this document should be on Standard Track or not. That's a 
reasonable question. I doubled checked on 
https://www.ietf.org/standards/process/informational-vs-experimental/,
 checked also other IPFIX RFC's such as 
https://datatracker.ietf.org/doc/html/rfc8549
 which also only specified new IPFIX code points for existing protocols, and 
came to the same conclusion then Tianran that Informational 

Re: [OPSAWG] Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

[Thomas.Graf]

Hi Med,

Many thanks for the shepherd review. I updated the document accordingly into 
-03 version.

https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-03

I included all your suggestions and followed your example in using 
abbreviations and changed the term "MPLS Segment Routing"
To "MPLS SR" throughout the document. The same for the term "subregistry" 
instead of "sub-registry" or "SubRegistry".

I took the liberty to further simplify the use case paragraph in section 2. I 
hope it is better readable now. Looking forward to your review.

Below in detail where I deviated to your suggestions. Mostly minor.

Regarding wherever this document should be on Standard Track or not. That's a 
reasonable question. I doubled checked on 
https://www.ietf.org/standards/process/informational-vs-experimental/, checked 
also other IPFIX RFC's such as https://datatracker.ietf.org/doc/html/rfc8549 
which also only specified new IPFIX code points for existing protocols, and 
came to the same conclusion then Tianran that Informational does not fit.

Best wishes
Thomas


Section 1
---
Proposed:

Also [I-D.ali-spring-sr-traffic-accounting] describes
how IP Flow Information Export  can be leveraged
to account traffic to MPLS Segment Routing label dimensions within a
Segment Routing domain.

Changed to:

Also [I-D.ali-spring-sr-traffic-accounting] describes
how IP Flow Information Export  can be leveraged
to account traffic to MPLS SR label dimensions within a
Segment Routing domain.


Section 2
---
Proposed:

By introducing four new code points to the IPFIX IE
mplsTopLabelType(46) for IS-IS, OSPFv2, OSPFv3, and BGP Prefix-SID,
it is possible to identify into which traffic is being
forwarded based upon which MPLS control plane protocol is in use.

Changed to:

By introducing four new code points to the IPFIX IE
mplsTopLabelType(46) for IS-IS, OSPFv2, OSPFv3 and BGP Prefix-SID,
it is possible to identify which traffic is being
forwarded based upon which MPLS SR control plane protocol is in use.


Section 2
---
Proposed:

Both use cases can be verified by using mplsTopLabelType(46),
mplsTopLabelIPv4Address(47), mplsTopLabelIPv6Address(140),
mplsTopLabelStackSection(70), and forwardingStatus(89) IEs to infer:

o  how many packets are forwarded or dropped,
o  if dropped, for which reasons, and
o  the MPLS provider edge loopback address and label protocol.

Changed to:

Both use cases can be verified by using mplsTopLabelType(46),
mplsTopLabelIPv4Address(47), mplsTopLabelIPv6Address(140),
mplsTopLabelStackSection(70) and forwardingStatus(89) IEs to infer
how many packets are forwarded or dropped to which MPLS provider
edge loopback address and label protocol, and if dropped for which
reasons.


Section 3
---
Proposed: Table 1: Updates to "IPFIX MPLS label type (Value 46)" SubRegistry
Changed to: Table 1: Updates to "IPFIX MPLS label type (Value 46)" subregistry


Section 4
---
Proposed: These values are thus used for distinct purposes
Changed to: These values are thus used for those distinct purposes

From: mohamed.boucad...@orange.com 
Sent: Wednesday, June 23, 2021 5:47 PM
To: draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; opsawg-cha...@ietf.org
Cc: opsawg@ietf.org
Subject: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type

Hi Thomas, all,

I made a shepherd review of the document. The review can be found at:


  *   pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf
  *   doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-reqs-06-rev%20Med.docx

Almost all the comments are minor. These are basically to enhance the 
readability of the document (shorten long sentences, etc.) and make idnits 
happy.

There is one "procedural" comment that it is better to discuss now as I suspect 
it will pop up in the process: Why the document is in the "Standard Track"?

I failed to see any valid reason especially that:
* The IANA policy for the target registry is Expert Review.
* We don't have any normative statements in the 

Re: [OPSAWG] Conclusion//RE: WG Last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

[Thomas.Graf]

Hi Tianran,

Thanks a lot. Based on the latest feedback from the mailing in the last call I 
updated the draft to -02 version.

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-mpls-sr-label-type-02

Best Wishes
Thomas

From: OPSAWG  On Behalf Of Tianran Zhou
Sent: Tuesday, June 22, 2021 5:44 AM
To: Tianran Zhou ; opsawg@ietf.org
Subject: [OPSAWG] Conclusion//RE: WG Last call for 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

Hi WG,

We conclude the last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01.
We are going to move it forward.
Thanks all the comments and discussions on this work.
The author please revise the draft based on the suggestions and discussion in 
the mailing list.

Cheers,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Tuesday, June 8, 2021 8:56 AM
To: opsawg@ietf.org
Subject: [OPSAWG] WG Last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

Hi WG,

The following draft is mainly to request some IPFIX IE allocations.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/

We agreed to fast track this draft and move forward.
Now the authors think it's stable. And we got IE expert reviewed.

This mail we start a two weeks WG last call, before June21.
Please reply your comments on this.

Thanks,
Tianran


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

Re: [OPSAWG] IPR question//RE: WG Last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

[Thomas.Graf]

Hi Tianran,

No, I am not aware of any IPR related to this document.

Best Wishes
Thomas


From: OPSAWG  On Behalf Of Tianran Zhou
Sent: Monday, June 21, 2021 10:40 AM
To: Tianran Zhou ; opsawg@ietf.org
Subject: [OPSAWG] IPR question//RE: WG Last call for 
draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

Hi Thomas and the WG,

Do you aware of any IPR related to this document?

Best,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Tuesday, June 8, 2021 8:56 AM
To: opsawg@ietf.org
Subject: [OPSAWG] WG Last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

Hi WG,

The following draft is mainly to request some IPFIX IE allocations.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/

We agreed to fast track this draft and move forward.
Now the authors think it's stable. And we got IE expert reviewed.

This mail we start a two weeks WG last call, before June21.
Please reply your comments on this.

Thanks,
Tianran


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