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

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.com@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.Graf@swisscom.com <thomas.graf@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