Re: [ippm] FW: New Version Notification for draft-ietf-ippm-ioam-yang-07.txt

[Tianran Zhou <[e-mail]>]

Hi Greg,

A correction:

  *   IOAM-DEX is explained as
The direct export option is used as a trigger for IOAM nodes to export IOAM data to a receiving entity (or entities).
I think that RFC 9326 does not specify that an IOAM-enable node must export IOAM data specified in the IOAM header. A slight rewording as s/export/produce/ would be less specific about how the node handles the IOAM data requested in the IOAM header. I imagine that a local policy may allow a number of options, including the export of raw telemetry data, aggregation with exporting of batched data, and even calculated metrics based on a pre-defined set of measurements.

ZTR> I recall we discussed this. The receiving entity could be local control plane. But I find some more accurate text from RFC9326. I think we can use this.

“This Option-Type is used as a
   trigger for IOAM data to be directly exported or locally aggregated
   without being pushed into in-flight data packets.
”


Tianran

From: ippm [mailto:[e-mail]] On Behalf Of Tianran Zhou
Sent: Friday, July 21, 2023 10:49 AM
To: Greg Mirsky <[e-mail]>
Cc: IETF IPPM WG <[e-mail]>
Subject: Re: [ippm] FW: New Version Notification for draft-ietf-ippm-ioam-yang-07.txt

Hi Greg,
Thanks very much for your detailed review and comments.
Please see in line.

Cheers,
Tianran

From: Greg Mirsky [mailto:[e-mail]]
Sent: Friday, July 21, 2023 6:36 AM
To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Cc: IETF IPPM WG <[e-mail]<mailto:[e-mail]>>; Thomas Graf <[e-mail]<mailto:[e-mail]>>
Subject: Re: FW: New Version Notification for draft-ietf-ippm-ioam-yang-07.txt

Hi Tianran,
my apologies for the delay in reviewing the new version. Please find my notes below:

  *   The abstract characterizes IOAM as
In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network.
Firstly, a nit s/In situ/In-situ/
I am sure that the emphasis on the collection of operational and telemetry information is correct. As the YANG model now supports the configuration of IOAM-DEX, it seems like the emphasis is on producing operational and telemetry information. Perhaps the following could be useful:
In-situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a method to produce operational and telemetry information that may be exported using the in-band or out-of-band method.
Also, I think that the next sentence should reference RFC 9326.

ZTR> Agreed.

  *   "This document defines a YANG module for the IOAM function."
Perhaps it will be more accurate to say "This document defines a YANG module for the configuration of the IOAM function."

ZTR> Agreed.

  *   The document states that the IOAM YANG model supports the Proof-of-Transit option. AFAIK, IOAM PoT was discussed in the experimental draft-ietf-sfc-proof-of-transit that was last updated on 2020-11-01. It seems like there's no energy to finish `PoT applicability in SFC NSH work. If there are no other documents that describe the applicability of IOAM PoT, what is the possible value of adding it without addressing significant security issues the IOAM PoT has?
ZTR>RFC9197 defines the basic PoT option. IMO the document you pointed is about an PoT application in SFC and encap in NSH. So  I think it’s reasonable to be included here. WRT the security issues, I do not think it’s in scope of this draft. RFC9197 is published, but  draft-ietf-ippm-ioam-data-integrity is still in the working group. Is you have any concern, I think it’s better to raise ASAP to the author of that draft, so that they can be addressed.

  *   As I understand it correctly, the model reports system-wide timestamp-type. I think that it is plausible that different data-plane modules use different formats of a timestamp.
ZTR> I am sorry, I do not know what I should do on this. ☺

  *   leaf enabled is used in grouping ioam-admin-config and tracing-profile containers. I think it would be helpful to use different names. For example, ioam-config-enabled in the grouping, and tracing-profile-enabled in containers. WDYT?
ZTR> IMHO, it’s not critical. This yang model has passed the yang doctor review. I think it’s fine.

  *   IOAM-DEX is explained as
The direct export option is used as a trigger for IOAM nodes to export IOAM data to a receiving entity (or entities).
I think that RFC 9326 does not specify that an IOAM-enable node must export IOAM data specified in the IOAM header. A slight rewording as s/export/produce/ would be less specific about how the node handles the IOAM data requested in the IOAM header. I imagine that a local policy may allow a number of options, including the export of raw telemetry data, aggregation with exporting of batched data, and even calculated metrics based on a pre-defined set of measurements.

ZTR> Agreed.

  *   The YANG model defines two node-action identities: action-encapsulate and action-decapsulate. Should there be an action-transit as well?
ZTR> In the very early version, there was an action-transit. But we found it no use. We did not find any action that need to configure for the transit at present. Or could you please indicate some?

Thank you for your kind consideration of my notes.

Regards,
Greg



On Wed, Jul 5, 2023 at 3:18 PM Tianran Zhou <[e-mail]<mailto:[e-mail]>> wrote:
Thanks Greg.
Look forward to your review.
Happy holidays.

Cheers,
Tianran


________________________________

Sent from WeLink
发件人： Greg Mirsky<[e-mail]<mailto:[e-mail]>>
收件人： Tianran Zhou<[e-mail]<mailto:[e-mail]>>
抄送： IETF IPPM WG<[e-mail]<mailto:[e-mail]>>;Thomas Graf<[e-mail]<mailto:[e-mail]>>
主题： Re: FW: New Version Notification for draft-ietf-ippm-ioam-yang-07.txt
时间： 2023-07-06 05:27:25

Hi Tianran,
thank you for your kind consideration of my comments. I believe that adding IOAM-DEX to the YANG model significantly increased the value of the document. I will re-read the document and share my thoughts, questions with the authors next week.

Regards,
Greg

On Tue, Jun 27, 2023 at 3:08 AM Tianran Zhou <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg, Thomas, and WG,

As requested in the WGLC, I updated the draft with ioam-dex included.
Please check if it works for you.

Cheers,
Tianran

-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, June 27, 2023 6:05 PM
To: Frank Brockners <[e-mail]<mailto:[e-mail]>>; Jim Guichard <[e-mail]<mailto:[e-mail]>>; Srihari Raghavan <[e-mail]<mailto:[e-mail]>>; Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-ietf-ippm-ioam-yang-07.txt


A new version of I-D, draft-ietf-ippm-ioam-yang-07.txt has been successfully submitted by Tianran Zhou and posted to the IETF repository.

Name:           draft-ietf-ippm-ioam-yang
Revision:       07
Title:          A YANG Data Model for In-Situ OAM
Document date:  2023-06-27
Group:          ippm
Pages:          30
URL:            https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-yang-07.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-yang
Diff:           https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-ioam-yang-07

Abstract:
   In situ Operations, Administration, and Maintenance (IOAM) collects
   operational and telemetry information in the packet while the packet
   traverses a path between two points in the network.  RFC9197
   discusses the data fields and associated data types for IOAM.  This
   document defines a YANG module for the IOAM function.




The IETF Secretariat