Hi all, I also support these documents proposing to export metrics through IPFIX, however not the way draft-spiegel-ippm-ioam-rawexport is implemented.
The advantage of IPFIX is aggregation directly at the node. The proposal in draft-spiegel-ippm-ioam-rawexport is exporting directly the raw packets from IOAM as an octetArray through IPFIX. Even though I like the idea of exporting metrics through IPFIX, I don’t think octetArrays are the way to go. I agree with Thomas that the IOAM values need to be decomposed, otherwise, users need to decode yet again the data from IPFIX. +1 on the adoption. Cheers, Alex > On 19 Mar 2024, at 11:45, Reshad Rahman <reshad=40yahoo....@dmarc.ietf.org> > wrote: > > 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 > <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 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
