Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[[e-mail]]

Dear Tianran,

Thanks a lot for your feedback. I understood that with draft-zhou-ippm-enhanced-alternate-marking we already have a document which intends to extend alternat path marking with timestamping. Very well.

Regarding IOAM-DEX. I was refereeing to the Section 3.2 of RFC 9326 (https://datatracker.ietf.org/doc/html/rfc9326#section-3.2) where "Flags" and "Extension-Flags" are being described for IOAM Trace Option-Types. As you pointed out, we would need not only to add similar to https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.1 the bit 2 and 3 in the "Flags" field but also need to support similar to https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2.3 and https://datatracker.ietf.org/doc/html/rfc9197#section-4.4.2.4 the possibility to add the timestamps in the "Extension-Flags" field. This was he point you wanted to highlight correct?

Best wishes
Thomas

From: Tianran Zhou <[e-mail]>
Sent: Wednesday, December 28, 2022 2:04 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi Thomas,

Some comments to your reply.

> Alternate Marking does not describe a method were the timestamp is within the packet

You can refer to the following draft, where you can get the timestamp you need.
https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zhou-ippm-enhanced-alternate-marking%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sk2JFwgWOE1HuNrUR1f4DDtFq%2Feefsf55f%2B1wQ%2FZvsA%3D&reserved=0>

> 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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9326%23section-3&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HKGG3eZAfuBQo690OK9C9%2BeNc%2B0bQnq0YmGow3RHX3M%3D&reserved=0>) if bits 2 and 3 in flags field for the timestamps would be set able.

I do not think you can get the timestamp by setting Bit 2 and 3 in IOAM-DEX.

Cheers,
Tianran

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Tuesday, December 27, 2022 5:13 PM
To: [e-mail]<mailto:[e-mail]>; Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-on-path-telemetry-01%23section-1&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m1XNm7XibW8ScwEphGblLW2C6oJe3vHXV%2FPuvDWnPZo%3D&reserved=0>). 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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-on-path-telemetry-01%23section-7.3&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8UrIEAobAj%2BabJyAe45fHgDGvH2Gnkn5Au041zqRK3U%3D&reserved=0>) 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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9197%23section-4.6&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BiNOE0WvHrSXsarnn5ke5kwzMz7JUe0rIvzRBkyHKDM%3D&reserved=0>) 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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9326%23section-3&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HKGG3eZAfuBQo690OK9C9%2BeNc%2B0bQnq0YmGow3RHX3M%3D&reserved=0>) 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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9197%23section-4.4&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mbtmEXtxByXKe5Uy08AFQgc9wASRrX1%2Fl8P%2BE6YKahQ%3D&reserved=0>) 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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9197%23section-4.4.2&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T2%2Bn5zjip3N%2FpvN%2FLw7EtWvWCfi9RtLS27ZfzPMcOVc%3D&reserved=0>) 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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-spiegel-ippm-ioam-rawexport&data=05%7C01%7CThomas.Graf%40swisscom.com%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IXdH7O68KjcO3CPFNYZVnFjHm%2B%2BxP6f5h2ul5%2BXo22s%3D&reserved=0>) 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 <[e-mail]<mailto:[e-mail]>>
Sent: Monday, December 26, 2022 9:22 PM
To: Tianran Zhou <zhoutianran=[e-mail]<mailto:zhoutianran=[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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=[e-mail]<mailto:[e-mail]>> 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%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485136196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=J6H4%2FViqAD%2BjXCMwmEUjDnEKwySacz5wzTHlJobVqmM%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
[e-mail]<mailto:[e-mail]>
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%7Cfebb16ba2b4b44466f6c08dae86f6b7f%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638077862485292417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Yi8tAzWVAT90BvsIprZANNkzwmrz9Wnw5x8ba9YWn1g%3D&reserved=0>