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

[Greg Mirsky <[e-mail]>]

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
>