Dear Greg, Thanks a lot for the review and feedback.
* as I understand it, the scope of this document is on reporting delay-related metrics based on the use of IOAM specifically. Is that correct understanding? If it is, reflecting that in the title might be helpful as other op-path telemetry methods, for example, Alternate Marking, might use a different set of IEs. The document focuses solely on the IPFIX export of the on-path telemetry measured delay. However these delay measurements are on-path telemetry protocol agnostic and can be applied to IOAM, iFIT and path tracing as described in section 1 (https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-1). To my knowledge, and please correct me if I am wrong, Alternate Marking does not describe a method were the timestamp is within the packet. If you feel that section 1 could be updated to make the scope more clearer, your feedback would be much appreciated. * I appreciate you using a picture (Figure 1) to illustrate the use case for IEs. It might be helpful for an operator to add more information about how IOAM is expected to be used. For example: * IOAM Option Types that are applicable to the defined IEs; * any special considerations using different IOAM Trace Option-Types; * mandatory IOAM Trace-Type. Very valid point. I think this would fit best in the operational considerations section. We have section 7.3 (https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-7.3) which focuses solely on timestamps at the moment. I agree that section 7 could be expanded to describe within IOAM to which IOAM Option Types the document applies. In case of passport mode that would be the IOAM Edge-to-Edge Option-Type (https://datatracker.ietf.org/doc/html/rfc9197#section-4.6) with bits 2 and 3 in flags fields for the timestamps set. Export would be only on the IOAM decapsulation node. In case of postcard mode that would have been the Direct Exporting (DEX) IOAM-Option-Type (https://datatracker.ietf.org/doc/html/rfc9326#section-3) if bits 2 and 3 in flags field for the timestamps would be set able. We intend to prepare a separate IOAM DEX document describing this case. Export would be on the IOAM transit and decapsulation nodes. Since IOAM Trace Option-Types (https://datatracker.ietf.org/doc/html/rfc9197#section-4.4) also supports bits 2 and 3 in flags field for the timestamps, this document could be partially applied there as well. However all the fields described in section 4.2 of RFC 9197 (https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2) are IOAM specific and not covered in draft-tgraf-opsawg-ipfix-on-path-telemetry. We believe that draft-spiegel-ippm-ioam-rawexport (https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-ioam-rawexport) is the appropriate document to cover these IPFIX entities. Export would be only on the IOAM decapsulation node. I will prepare and update for after the adoption call and address this point as described. Feedback and comments welcome. Best wishes Thomas From: Greg Mirsky <gregimir...@gmail.com> Sent: Monday, December 26, 2022 9:22 PM To: Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org> Cc: opsawg@ietf.org; draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org Subject: Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01 Dear All, I read the latest version of the draft. I appreciate the work authors put into making the document clear and easy to read. Proposed IEs are essential for further developing an out-of-band collection of telemetry information. I strongly support the adoption of this work by the OPSAWG. I have two notes to discuss (clearly non-blocking): * as I understand it, the scope of this document is on reporting delay-related metrics based on the use of IOAM specifically. Is that correct understanding? If it is, reflecting that in the title might be helpful as other op-path telemetry methods, for example, Alternate Marking, might use a different set of IEs. * I appreciate you using a picture (Figure 1) to illustrate the use case for IEs. It might be helpful for an operator to add more information about how IOAM is expected to be used. For example: * IOAM Option Types that are applicable to the defined IEs; * any special considerations using different IOAM Trace Option-Types; * mandatory IOAM Trace-Type. Regards, Greg On Wed, Dec 21, 2022 at 6:26 PM Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: Hi WG, This mail starts a WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01. https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-on-path-telemetry%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7Ce1df80c7c57045d56e3f08dae77edb90%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638076829274371352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hAhj%2BwL%2BqaUFonEHr2UNBetbVnhaJjDJH%2FHyegdcxqc%3D&reserved=0> Please reply your supports or objections. We would really appreciate your comments. Since there are holidays, this call will last for 3 weeks, and end on Thursday, Jan 12, 2023. Cheers, Tianran (as co-chairs) _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org<mailto:OPSAWG@ietf.org> https://www.ietf.org/mailman/listinfo/opsawg<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&data=05%7C01%7CThomas.Graf%40swisscom.com%7Ce1df80c7c57045d56e3f08dae77edb90%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638076829274371352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=n80HWTC2ubuh0SdXUEja7hmW1DyKAdEdvaMF89atIy4%3D&reserved=0>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg