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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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 <[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]>
> 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
>
>