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 <res...@yahoo.com> 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 <thomas.g...@swisscom.com> 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> <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<mailto: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
