[ippm] Re: draft-fz-ippm-on-path-telemetry-yang (On-path Telemetry YANG Data Model )

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

Dear Giuseppe, Tianran, and IPPM WG,

I have mixed feelings about this draft.

I support the idea behind this draft. Having a YANG model for exporting on-path delay metrics using YANG-Push is useful!
However, I have concerns the way it is approached so far:

- I read on the ML that the WG decided to separate configuration and operational data. However, this approach breaks NMDA [RFC8342]. In different OPS-related WG, contributors have been pushing for adherence to NMDA.
So, here I suggest to rethink this. As defined in NMDA, all new YANG modules should provide both the config and operational data to ease manageability. I think the IETF should go on a single direction and not approach network management using different approaches.

- Which is the scope of the exported metrics? I am assuming all packets traversing the ACL defined by the filter? I assume this acl filter matches the one defined in RFC9617 and draft-ietf-ippm-alt-mark-yang?

- When exporting the on-path delay metrics, these metrics do not have an association to the time window in which they were measured. Do the authors assume that the time window is between the last exported period (current timestamp minus period) and the current timestamp? Or do they use some of the timestamps defined in alt-mark/iOAM? I missed this information by reading the draft.

- I see that the 5 iOAM options types are included in the model but, they are all defined as an identity:
          +--ro ioam-incremental-tracing     ioam-trace-data
          +--ro ioam-preallocated-tracing    ioam-trace-data
          +--ro ioam-direct-export           ioam-trace-data
          +--ro ioam-proof-of-transit        ioam-pot-data
          +--ro ioam-edge-to-edge            ioam-e2e-data
I see two issues here: first, on-path-delay metrics are aggregate data while iOAM data is not aggregated, so having them on the same level, I do not see how to implement this. When generating this message, this iOAM leaves represent the last iOAM message? Are they a list of the last iOAM messages (as currently defined, they cannot…)?
Second, I would rather having these data decomposed. From data collection perspective, it seems not very usable when the iOAM data is just pushed raw (https://datatracker.ietf.org/doc/draft-spiegel-ippm-ioam-rawexport/07/)

Some minor comments:
- I think the leaf period is an alt-mark parameter. Note that in section 4, it is not specified. As periodical subscriptions from YANG-Push have a similar parameter, please explicit that this parameter is different from the one defined in RFC8641.
- Reading the introduction, this model is to be used for YANG-Push (and not with NETCONF get). Note YANG-Push has a header already with a timestamp. So, I wonder why do we have a timestamp in the model?
See Figure 1 from RFC8641, the eventTime present in the YANG-Push header already defines the time when the message was generated. This timestamp does not need to be defined.

TL;DR I support the idea behind this draft but I think the YANG module should follow NMDA and address some under-specifications noted above.
The way I would do it is implementing a grouping with the operational data (the on-path delay measurements) and augment each iOAM type from RFC9617 with an operational container. Similarly, for alt-mark, I think augmenting the module defined in draft-ietf-ippm-alt-mark-yang-00 would also simplify a few leaves present in the current draft.

I will leave the chairs decide whether these issues can be addressed once the document is adopted or a new revision is needed.

Cheers,
Alex


> On 14 Apr 2025, at 12:08, [e-mail] wrote:
> 
> Dear IPPM,
>  
> As the IPR poll has concluded (no IPR has been reported), the authors and chairs would like to call for adoption of
>  
> https://datatracker.ietf.org/doc/html/draft-fz-ippm-on-path-telemetry-yang-01
> https://datatracker.ietf.org/doc/draft-fz-ippm-on-path-telemetry-yang/
>  
> Please reply on-list to this email with comments, support for, or reasons not to adopt this work as a WG document.
>  
> We will run a three-week adoption call, ending on May 5th.
>  
> Best wishes
> Thomas and Marcus
> _______________________________________________
> ippm mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>