Re: [ippm] draft-song-ippm-ioam-ipv6-support

[Alex Huang Feng <[e-mail]>]

Hi Thomas,

Just a comment on the second point.
Actually, IOAM Trace Option Type and IOAM DEX use the same IANA registry for the data you want to export (https://datatracker.ietf.org/doc/html/rfc9197#name-ioam-trace-type-registry), therefore, any new bit allocated will impact both IOAM types.

That’s something I actually don’t like personally since I see both IOAM types used for different use cases (and therefore having different types of data to be exported) but it was already implemented that way.
And this was also the reason to write draft-ahuang-ioam-on-path-delay even though it does not have a lot of impact on the IPFIX collector, just for the consistency within the IOAM environment.

Cheers,
Alex

> On 19 Mar 2024, at 12:21, [e-mail] wrote:
> 
> Dear Haoyu, Dear IPPM
>  
> Thank you very much for your presentation at IPPM.
>  
> I like that you listed the possible proposals make IOAM trace option type more applicable when additional IPv6 extension headers such as Segment Routing header is being used.
>  
> I like on one hand to call out to network vendors to describe which suggested options can be potentially supported in their hardware/software implementations.
>  
> Second, as the co-author of https://datatracker.ietf.org/doc/html/draft-ahuang-ippm-dex-timestamp-ext, extending IOAM DEX with a timestamp to facilitate on-path delay measurement in IPFIX as described inhttps://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry, I would appreciate that the working group make a clear statement wherever they intend to make all the features on IOAM trace option type available on IOAM DEX as well or not. A good starting point might be to revisit the following conversation: https://mailarchive.ietf.org/arch/msg/ippm/YbPlODR342z-NM0nulySYS8S_P4/ as there were concerns on the available bit field space.
>  
> Best wishes
> Thomas