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

[Giuseppe Fioccola <[e-mail]>]

Dear Alex,
Thank you for your review of this document.
Please see my replies inline as [GF].

Regards,

Giuseppe

From: Alex Huang Feng <[e-mail]>
Sent: Wednesday, April 30, 2025 5:38 PM
To: Thomas Graf <[e-mail]>; IETF IPPM WG <[e-mail]>
Cc: [e-mail]
Subject: [ippm] Re: draft-fz-ippm-on-path-telemetry-yang (On-path Telemetry YANG Data Model )

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!

[GF]: Thanks!

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.

[GF]: As I also mentioned in Bangkok, I see your point and it is fine for me to incorporate in the same YANG modules both configuration and telemetry data. If the WG agrees, we can revise the draft in order to augment RFC9617 and draft-ietf-ippm-alt-mark-yang respectively.

- 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?

[GF]: Yes, for the flows under monitoring, we need to export the IOAM and AltMark relevant data for the calculation of performance metrics. But, if you look at RFC9617 and draft-ietf-ippm-alt-mark-yang, the relevant parameters are not defined. For example, draft-ietf-ippm-alt-mark-yang does not include packet counters for loss calculation, timestamps for delay calculation, and so on. The same applies to RFC9617.

- 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.

[GF]: You can use the timestamps but there are also dedicated parameters to control the time window (i.e. period and period-number).

- 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/)

[GF]: I agree to decompose the IOAM data, but if we decide to continue with the raw export of IOAM data, we will define the leaves as list of the last IOAM messages in the period (time window).

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.

[GF]: Yes, we can change its name to differentiate it.

- 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.

[GF]: No, we need another timestamp to differentiate between the time when the message is generated and the starting time of the considered period. This is needed for correlation. Maybe we can change its name to clarify.

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.

[GF]: As already mentioned above, if the WG agrees on this, this document can augment the YANG modules of RFC9617 and draft-ietf-ippm-alt-mark-yang.


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]<mailto:[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]>