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

[Giuseppe Fioccola <[e-mail]>]

Hi Thomas, Marcus,
Please note that we just submitted draft-ietf-ippm-on-path-telemetry-yang-00 for your approval.
This revision only includes few minor changes that were already addressed in my local version.

Regards,

Giuseppe


From: [e-mail] <[e-mail]>
Sent: Friday, May 16, 2025 4:14 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: [ippm] draft-fz-ippm-on-path-telemetry-yang (On-path Telemetry YANG Data Model )

Dear IPPM,

We conclude successfully herewith the adoption call. We received plenty of feedback and interest.

We currently awaiting additional feedback wherever the proposed YANG module should stay as is or augment existing ietf-ioam:ioam and ietf-altmark/altmark modules.

Authors, please submit the document draft-fz-ippm-on-path-telemetry-yang-01 under draft-ietf-ippm-on-path-telemetry-yang-00 unchanged and address the open issues in the following revision.

Best wishes
Thomas and Marcus

From: Alex Huang Feng <[e-mail]<mailto:[e-mail]>>
Sent: Friday, May 9, 2025 11:28 AM
To: giuseppe.fioccola <[e-mail]<mailto:[e-mail]>>; Graf Thomas, INI-NET-VNC-E2E <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [ippm] draft-fz-ippm-on-path-telemetry-yang (On-path Telemetry YANG Data Model )


Be aware: This is an external email.


Dear Thomas and Giuseppe,

@Giuseppe, ack on the follow up mail. About the timestamp specified in the current model, just note that currently, there are a few timestamps defined:
- eventTime (RFC8641/RFC8639)
- ietf-yp-observation:timestamp (draft-ietf-netconf-notif-envelope-01)
So, I would suggest to clarify and well define this timestamp in the current model.

Regarding what we consider operational data, I understood that it does not only cover the operational state of the configuration, but also the metrics. See ietf-interfaces.yang (RFC 8343), the module has a container "statistics" where counters related to the interface are reported within the model. So, I see the same usecase for iOAM and alt-mark.
I agree that metrics should not be under ietf-ioam:ioam/info and ietf-altmark:altmark/altmark-info as this information is more related to the capabilities of the router and not the metrics.

Cheers,
Alex

On 8 May 2025, at 15:19, Giuseppe Fioccola <[e-mail]<mailto:[e-mail]>> wrote:

Hi Thomas,
Thank you for bringing this up.
As coauthor of draft-fz-ippm-on-path-telemetry-yang, I just wanted to highlight that we initially decided to work on a separate YANG module for telemetry given the approach in RFC9617. And I concur with your understanding of RFC8342.
But, if required, we are open to revise the draft and split the current YANG module in order to augment the YANG modules of RFC9617 and draft-ietf-ippm-alt-mark-yang.
In this case, it would also be good to clarify this point in draft-opsarea-rfc5706bis and maybe consider to update RFC8342 accordingly.

Regards,

Giuseppe

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, May 7, 2025 2:40 PM
To: Giuseppe Fioccola <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [ippm] Re: draft-fz-ippm-on-path-telemetry-yang (On-path Telemetry YANG Data Model )

Dear Alex, Giuseppe, draft-fz-ippm-on-path-telemetry-yang and draft-opsarea-rfc5706bis authors,

As an individual. My current understanding of the NMDA objectives https://datatracker.ietf.org/doc/html/rfc8342#section-2 is to have the operational and configurational state in the same data tree.

Looking at https://datatracker.ietf.org/doc/html/rfc9617#section-3.1 and https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-yang-00#section-2, I see under ietf-ioam:ioam/info resp. ietf-altmark:altmark/altmark-info the operational state of the configuration. Therefore satisfying the NMDA objective.

Where with https://datatracker.ietf.org/doc/html/draft-fz-ippm-on-path-telemetry-yang-01#section-3, relevant to this IPPM working group adoption call, the data model for the exported data is being defined. This is different to the operational state of the configuration in my opinion. Therefore I believe there is no NMDA requirement to augment ietf-ioam and ietf-altmark.

However, since https://datatracker.ietf.org/doc/html/draft-opsarea-rfc5706bis is currently being authored at OPSAREA for the Ops Directorate, and the scope of the document defines guidelines for considering operations and management of new protocols and protocol extensions, I would like very much to hear feedback on my conclusion. I also added our OPS area AD's on CC to see wherever they have a comment here as well.

As a chair, I see we have throughout positive comments on the adoption call. However, I would like to keep the adoption call open for the moment until we have some additional feedback on above point, indicating the direction the working group should take with this document after it is being adopted.

Best wishes
Thomas

From: Giuseppe Fioccola <[e-mail]<mailto:[e-mail]>>
Sent: Friday, May 2, 2025 11:40 AM
To: Alex Huang Feng <[e-mail]<mailto:[e-mail]>>; Graf Thomas, INI-NET-VNC-E2E <[e-mail]<mailto:[e-mail]>>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [ippm] Re: draft-fz-ippm-on-path-telemetry-yang (On-path Telemetry YANG Data Model )


Be aware: This is an external email.


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]<mailto:[e-mail]>>
Sent: Wednesday, April 30, 2025 5:38 PM
To: Thomas Graf <[e-mail]<mailto:[e-mail]>>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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]>