Re: [ippm] WGLC for draft-ietf-ippm-ioam-yang

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

Cheers,
Tianran

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Sunday, August 14, 2022 4:22 AM
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-ioam-yang

Dear Authors, et al.,
please kindly consider my notes as the WG LC comments on the draft:

  *   I read the document and left with a general question about the applicability of this YANG model. Is it to be applied at:

     *   ingress IOAM node
     *   ingress and egress IOAM nodes
     *   ingress, egress, and transit IOAM nodes
ZTR> Note ingress, egress, and transit are modeled as node action of a profile. That means for different measurements (e.g., tracing, e2e), one node role could change. As for one profile, there is no transit node configuration specified in this model.

  *   Abstract and the first paragraph of the Introduction section characterize IOAM as only collecting the operational data and telemetry information in the data packet. That seems like a contradiction with the list of IOAM options that include the IOAM Direct Export.
ZTR> I am sorry I do not get you here. Could you please give some more hints?

  *   The first paragraph of the Introduction is likely to benefit from references to documents that define IOAM encapsulation in IPv6 and NSH.
ZTR> OK. I will add.

  *   The Proof-of-Transit option is listed in the Introduction section. Can you give an example or reference of an IETF document that describes the applicability of this trace option?
ZTR> This model only gives the pointer to add PoT configuration, but does not specify the PoT configuration. As mentioned in the document “User need to augment this module for the configuration of a specifc POT type.”

  *   It seems like "end to end data" in Section 3.1 should be "edge-to-edge data".
ZTR> Yes, thanks.

  *   Can you explain the behavior of a transit IOAM node that receives IOAM with Loopback mode/flag? How "the source" is identified in a data packet, for example, NSH?
ZTR> I hope other co-authors could help on this. IMO, this should be defined in IOAM-flag document. Not this.

  *   What is "active measurement"? Can you provide an example or reference to an IETF document that describes active measurements using IOAM?
ZTR> The same as above.

  *   I found only two data plane encapsulations - NSH and IPv6. Does that mean that this model is not intended to support IOAM in an MPLS network?
ZTR>We defined a base identity to represent the carrier protocol. More encapsulations could be extended. This document only considers mature ones which are wg docuemts. MPLS encapsulation is still in wg discussion.

  *   Can you point out a part of the YANG model that can be used to control a transit IOAM node for the IOAM Direct Export trace option?
ZTR> There is no configuration on transit node for IOAM-DEX in this document.

  *   Nits:

     *   s/Edge to Edge/Edge-to--Edge/ per RFC 9197
ZTR>Thanks. I will revise.
Regards,
Greg

On Tue, Aug 9, 2022 at 9:15 AM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:40apple.com@dmarc.ietf.org>> wrote:
Hello IPPM,

This email starts a Working Group Last Call for draft-ietf-ippm-ioam-yang.

https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/
https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-yang-04.html

Please review this document, and reply to this email to indicate your comments, and if you support publishing this document.

The last call will go until Wednesday, August 31.

Best,
Tommy & Marcus
_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm