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

[Haoyu Song <[e-mail]>]

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 <[e-mail]>
Sent: Wednesday, October 21, 2020 2:52 PM
To: Haoyu Song <[e-mail]>
Cc: [e-mail]; IETF IPPM WG ([e-mail]) <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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.
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.
Please let me known if I missed or misunderstood anything. Thanks!
Best regards,
Haoyu