Subject: [ippm] review comments on draft-mirsky-ippm-hybrid-two-step-05

From: Haoyu Song <[email-masked]>
Date: Thu, 15 Oct 2020 20:03:39 +0000

Hi authors and IPPM,

I reviewed the draft and see a close link of the proposed method with the other methods in discussion in the IPPMWG. Below are some questions and comments for your consideration.

  1.  I believe HTS has its place in the on-path telemetry branch of technology. In essence, it sits just between IOAM and PBT: collect the telemetry data using one dedicated and separate packet. The benefit of doing so is clear and sound.
  2.  To best progress this work, I think a good strategy is to try to align it with the existing specifications of IOAM Trace and IOAM DEX (e.g., data and header specification). It's even possible to think about it as yet another option for IOAM.
  3.  The nodes on the path need to maintain the states for each trigger (the transport header and timer). This is not a  trivial process and the scalability also needs to be considered.
  4.  How is the trigger implemented and how is the follow-up packet header encapsulated? The current draft doesn't provide enough details on these issues.
  5.  The definition and usage of the sequence number is not very clear to me. It seems to be used to differentiate the internal generated follow-up packets. Based on the description, if a follow-up packet is dropped, then each hop on the remaining path will experience the timer expiration and generate a new follow-up packet. Will these packets all have the same sequence number? If the original follow-up packet is just delayed but not dropped, how will this and the other newly generated follow-up packets are differentiated and processed?
  6.  The specification of the data profile is also missing. Isn't the data profile should be carried by the trigger packet instead of the follow-up packet?
  7.  The telemetry is encoded as TLV. How can the collector tell which data is generated by which node?
Please let me known if I missed or misunderstood anything. Thanks!
Best regards,
Haoyu

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 18 Oct 2020 19:32:27 -0700

Hi Haoyu,
many thanks for your thorough review and detailed comments, much
appreciated. I'll respond with the proposed updates later this week.

Best regards,
Greg

On Thu, Oct 15, 2020 at 1:03 PM Haoyu Song <[email-masked]> wrote:

> Hi authors and IPPM,
>
>
>
> I reviewed the draft and see a close link of the proposed method with the
> other methods in discussion in the IPPMWG. Below are some questions and
> comments for your consideration.
>
>    1. I believe HTS has its place in the on-path telemetry branch of
>    technology. In essence, it sits just between IOAM and PBT: collect the
>    telemetry data using one dedicated and separate packet. The benefit of
>    doing so is clear and sound.
>    2. To best progress this work, I think a good strategy is to try to
>    align it with the existing specifications of IOAM Trace and IOAM DEX (e.g.,
>    data and header specification). It’s even possible to think about it as yet
>    another option for IOAM.
>    3. The nodes on the path need to maintain the states for each trigger
>    (the transport header and timer). This is not a  trivial process and the
>    scalability also needs to be considered.
>    4. How is the trigger implemented and how is the follow-up packet
>    header encapsulated? The current draft doesn’t provide enough details on
>    these issues.
>    5. The definition and usage of the sequence number is not very clear
>    to me. It seems to be used to differentiate the internal generated
>    follow-up packets. Based on the description, if a follow-up packet is
>    dropped, then each hop on the remaining path will experience the timer
>    expiration and generate a new follow-up packet. Will these packets all have
>    the same sequence number? If the original follow-up packet is just delayed
>    but not dropped, how will this and the other newly generated follow-up
>    packets are differentiated and processed?
>    6. The specification of the data profile is also missing. Isn't the
>    data profile should be carried by the trigger packet instead of the
>    follow-up packet?

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 21 Oct 2020 14:51:52 -0700

Hi Haoyu,
thank you for your comments, questions, and suggestions. Please find my
answers, notes, and proposed updates in-lined below under the GIM>> tag.

Regards,
Greg

On Thu, Oct 15, 2020 at 1:03 PM Haoyu Song <[email-masked]> wrote:

> GIM>> Thank you for your kind words, much appreciated. I fully agree with
your characterization of telemetry collection methods the IPPM WG has been
working on over the last several years. Each of the methods has advantages
in some use cases. Together they, in my opinion, are complementary and
compose a comprehensive set for the collection of telemetry information in
a wide variety of scenarios.

>    1.
> GIM>> Thank you for the valuable suggestion. I'll work on an update and
hope to present it for the discussion at the IETF-109 meeting.

>
>    1.
>    2. The nodes on the path need to maintain the states for each trigger
> GIM>> I agree with your concern about the impact HTS may have on a node.
Will highlight that in the Security Considerations section.

>
>    1.
>    2. How is the trigger implemented and how is the follow-up packet
> GIM>> Thank you for pointing this out, I'll work on an update to add more
details. The nature of a trigger could be, in my view, anything that
functions similarly to an ACL. For example, an iOAM header or a designated
packet in a flow of Alternate-Marked packets. An encapsulation of a
follow-up packet must replicate the encapsulation of the trigger packet so
that the follow-up packet, actually there could be a train of them,
traverse the same nodes and links as the trigger. One advantage of HTS over
embedding telemetry information in a data packet could be seen in an option
not to use the same QoS as the data, thus minimize the impact of telemetry
collection on a service. Of course, an operator may decide to use the QoS
for the collection flow as for the data.

>
>    1.
>    2. The definition and usage of the sequence number is not very clear
>    follow-up packets.
> GIM>> In HTS. a single trigger may generate amount information that
requires several follow-up packets. Sequence Number is intended to
enumerate these follow-up packets.

>
>    1. Based on the description, if a follow-up packet is dropped, then
>    each hop on the remaining path will experience the timer expiration and
>    generate a new follow-up packet. Will these packets all have the same
>    sequence number?
>
> GIM>> If a follow-up packet is dropped, it is expected that the next
HTS-enabled node will generate a new follow-up packet with the Sequence
Number set to 0. All downstream HTS nodes are expected to collect their
telemetry data into that follow-up packet as long as there's sufficient
space. Otherwise, a new follow-up packet to be generated with the Sequence
Number value incremented by one, i.e., 1.

>
>    1. If the original follow-up packet is just delayed but not dropped,
>    how will this and the other newly generated follow-up packets are
>    differentiated and processed?
>
> GIM>> Very interesting scenario, thank you. If the delay is longer then
the wait timer, i.e., that packet is late, then it would be forwarded
without any update and the HTS node should not be in 'waiting' state.

>
>    1.
>    2. The specification of the data profile is also missing. Isn't the
> GIM>> Thank you for the suggestion. I think that is some applications,
e.g., iOAM, data profile is presented by the iOAM header. If HTS is used in
combination with the Alternate-Marking method, the profile could be part of
the follow-up packet. Would you agree?

>
>    1.
>    2. The telemetry is encoded as TLV. How can the collector tell which
>    data is generated by which node?
>
> GIM>> Thank you for this question. I think that HTS should use iOAM data
definitions as much as possible, including to identify the telemetry
generating node. I will add a note to clarify that.

>    1.

---

From: Haoyu Song <[email-masked]>
Date: Wed, 21 Oct 2020 22:36:18 +0000

Hi Greg,

Thank you for your feedback, your evaluation and measures all sound reasonable to me. I think the goal is to try to reuse the existing works as much as possible and have a coherent suite of on-path telemetry methods which can be chosen to use in various scenarios. I think there’s no one-size-fits-all solution so the diversity is necessary. Let’s see what other people consider about this.

Best regards,
Haoyu

From: Greg Mirsky <[email-masked]>
Sent: Wednesday, October 21, 2020 2:52 PM
To: Haoyu Song <[email-masked]>
Cc: [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: review comments on draft-mirsky-ippm-hybrid-two-step-05

Hi Haoyu,
thank you for your comments, questions, and suggestions. Please find my answers, notes, and proposed updates in-lined below under the GIM>> tag.

Regards,
Greg

On Thu, Oct 15, 2020 at 1:03 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi authors and IPPM,

  1.  I believe HTS has its place in the on-path telemetry branch of technology. In essence, it sits just between IOAM and PBT: collect the telemetry data using one dedicated and separate packet. The benefit of doing so is clear and sound.
GIM>> Thank you for your kind words, much appreciated. I fully agree with your characterization of telemetry collection methods the IPPM WG has been working on over the last several years. Each of the methods has advantages in some use cases. Together they, in my opinion, are complementary and compose a comprehensive set for the collection of telemetry information in a wide variety of scenarios.

  1.
  2.  To best progress this work, I think a good strategy is to try to align it with the existing specifications of IOAM Trace and IOAM DEX (e.g., data and header specification). It’s even possible to think about it as yet another option for IOAM.
GIM>> Thank you for the valuable suggestion. I'll work on an update and hope to present it for the discussion at the IETF-109 meeting.

  1.
  2.  The nodes on the path need to maintain the states for each trigger (the transport header and timer). This is not a  trivial process and the scalability also needs to be considered.
GIM>> I agree with your concern about the impact HTS may have on a node. Will highlight that in the Security Considerations section.

  1.
  2.  How is the trigger implemented and how is the follow-up packet header encapsulated? The current draft doesn’t provide enough details on these issues.
GIM>> Thank you for pointing this out, I'll work on an update to add more details. The nature of a trigger could be, in my view, anything that functions similarly to an ACL. For example, an iOAM header or a designated packet in a flow of Alternate-Marked packets. An encapsulation of a follow-up packet must replicate the encapsulation of the trigger packet so that the follow-up packet, actually there could be a train of them, traverse the same nodes and links as the trigger. One advantage of HTS over embedding telemetry information in a data packet could be seen in an option not to use the same QoS as the data, thus minimize the impact of telemetry collection on a service. Of course, an operator may decide to use the QoS for the collection flow as for the data.

  1.
  2.  The definition and usage of the sequence number is not very clear to me. It seems to be used to differentiate the internal generated follow-up packets.
GIM>> In HTS. a single trigger may generate amount information that requires several follow-up packets. Sequence Number is intended to enumerate these follow-up packets.

  1.  Based on the description, if a follow-up packet is dropped, then each hop on the remaining path will experience the timer expiration and generate a new follow-up packet. Will these packets all have the same sequence number?
GIM>> If a follow-up packet is dropped, it is expected that the next HTS-enabled node will generate a new follow-up packet with the Sequence Number set to 0. All downstream HTS nodes are expected to collect their telemetry data into that follow-up packet as long as there's sufficient space. Otherwise, a new follow-up packet to be generated with the Sequence Number value incremented by one, i.e., 1.

  1.  If the original follow-up packet is just delayed but not dropped, how will this and the other newly generated follow-up packets are differentiated and processed?
GIM>> Very interesting scenario, thank you. If the delay is longer then the wait timer, i.e., that packet is late, then it would be forwarded without any update and the HTS node should not be in 'waiting' state.

  1.
  2.  The specification of the data profile is also missing. Isn't the data profile should be carried by the trigger packet instead of the follow-up packet?
GIM>> Thank you for the suggestion. I think that is some applications, e.g., iOAM, data profile is presented by the iOAM header. If HTS is used in combination with the Alternate-Marking method, the profile could be part of the follow-up packet. Would you agree?

  1.
  2.  The telemetry is encoded as TLV. How can the collector tell which data is generated by which node?
GIM>> Thank you for this question. I think that HTS should use iOAM data definitions as much as possible, including to identify the telemetry generating node. I will add a note to clarify that.

  1.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 22 Oct 2020 08:31:51 -0700

Hi Haoyu,
I fully agree with your vision of building a comprehensive set of on-path
telemetry collection mechanisms that share common elements as much as
possible. I hope you would agree to join in the work on this draft. I'd be
happy to welcome you as a co-author.

Regards,
Greg

On Wed, Oct 21, 2020 at 3:36 PM Haoyu Song <[email-masked]> wrote:

> Hi Greg,
>
>
>
> Thank you for your feedback, your evaluation and measures all sound
> reasonable to me. I think the goal is to try to reuse the existing works as
> much as possible and have a coherent suite of on-path telemetry methods
> which can be chosen to use in various scenarios. I think there’s no
> one-size-fits-all solution so the diversity is necessary. Let’s see what
> other people consider about this.
>
>
>
> Best regards,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Wednesday, October 21, 2020 2:52 PM
> *To:* Haoyu Song <[email-masked]>
> *Cc:* [email-masked]; IETF IPPM WG (
> [email-masked]) <[email-masked]>
> *Subject:* Re: review comments on draft-mirsky-ippm-hybrid-two-step-05
>
>
>
> Hi Haoyu,
>

---

From: Haoyu Song <[email-masked]>
Date: Thu, 22 Oct 2020 16:07:39 +0000

Hi Greg,

That would be an honor for me. I’m glad to work with you on progressing this draft.
Thanks!

Best regards,
Haoyu

Sent: Thursday, October 22, 2020 8:32 AM

Hi Haoyu,
I fully agree with your vision of building a comprehensive set of on-path telemetry collection mechanisms that share common elements as much as possible. I hope you would agree to join in the work on this draft. I'd be happy to welcome you as a co-author.

Regards,
Greg

On Wed, Oct 21, 2020 at 3:36 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Best regards,
Haoyu

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, October 21, 2020 2:52 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: review comments on draft-mirsky-ippm-hybrid-two-step-05

Hi Haoyu,

Regards,
Greg

  1.

  1.

  1.

  1.

  1.

  1.

  1.