[ippm] Re: Call for adoption for draft-mirsky-ippm-hybrid-two-step

Hi Bjørn,
my apologies for procrastinating to respond. Thank you for your comments
and questions. Please find my notes below tagged GIM>>.

Regards,
Greg

On Fri, Sep 22, 2023 at 6:52 AM Bjørn Ivar Teigen <bjorn@domos.no> wrote:

> IPPM WG,
>
> I support adopting this document.
> I do think it is a bit challenging to understand the motivations for the
> mechanism, but that can probably be easily fixed by adding some clarifying
> text and/or diagrams.
>
> Here are my comments on the draft:
>
>    - Is one of the purposes of the two-packet approach to separate
>    measurements from different domains from each other? (I.e. by having one
>    ingress and egress node for each domain, but one trigger packet that
>    triggers measurements at all of the domains) If so, perhaps adding a
>    diagram will make that more clear.
>
> GIM>> That is an interesting idea, thank you. I imagine that an on-path
telemetry protocol is applied whithin a single domain because revealing
information about the operational state of the network is very sensitive
and proprietary from the standpoint of an operator.

>
>    - Is the purpose of the trigger packet to signal each intermediate
>    node to take a measurement immediately? The list of things for the
>    intermediate node to do upon receiving a trigger packet does not include
>    taking a measurement. Is that an oversight?
>
> GIM>> A trigger packet is the packet of the hybrid measurement protocol,
e.g., IOAM-DEX or the Alternate Marking method. As I understand it, such
measurement protocols reflect the network conditions as experienced by the
trigger packet. In that sense, HTS is based on the assumption that the
measurements and operational state information are obtained as that packet
traverses the intermediate node.

>
>    - If I understand correctly there can only be one trigger packet
>    active at a time. That limits the measurement rate to one measurement per
>    round-trip. Is that correct? If so, this limitation should be more clearly
>    stated.
>
> GIM>> Your understanding of the requirement in Section 4.4 is correct. But
I am not sure that the interval between trigger packets is bound by the
RTT. I think that it is closer to RTT/2, as the measurement conducted are
one-way. WDYT?

> Best regards,
> Bjørn Ivar Teigen
>
> On Fri, 22 Sept 2023 at 12:54, Martin Duke <martin.h.duke@gmail.com>
> wrote:
>
>> I agree that this type of work is in-charter.
>>
>> I can't speak to whether this answers a big need or anyone would deploy
>> it, but I don't see a fundamental problem with adoption, assuming there are
>> satisfactory answers to the questions below.
>>
>> I can see how something like this could go haywire, with followon packets
>> getting misrouted, reordered, or lost, and wonder if we have enough
>> experience with it to be a standard, or if we should instead aim for
>> experimental.
>>
>> Some more minor comments:
>>
>> I found the motivation in the introduction to be a bit hard to
>> understand, and the abstract could use a sentence or two explaining what
>> this protocol specifically does.
>>
>> IIUC since the last major presentation @IETF 113, the model seems to have
>> evolved from each intermediate node generating its own followon packet,
>> instead the ingress node generates one and each intermediate node appends
>> to the followup. I hope that's right?
>>
>> It's also disturbing to me that there doesn't seem to be strong
>> wire-image synchronization between the trigger packet and followon packet
>> via a common sequence number or something else. This could lead to
>> confusion at the egress.
>>
>> What assurances are there that the followon packet followed the same path
>> from ingress to egress as the trigger packet? What are the consequences of
>> this not happening and remaining undetected?
>>
>> This is not very important, but I find "hybrid two-step" to be a
>> nondescriptive name, and might prefer something like "IOAM Followon".
>>
>> Martin
>>
>>
>> On Tue, Sep 19, 2023 at 11:28 AM Haoyu Song <haoyu.song@futurewei.com>
>> wrote:
>>
>>> IPPM WG,
>>>
>>>
>>>
>>> As a coauthor, I support the adoption of the draft as the WG document.
>>> The hybrid approach complements with the other IOAM approaches well and has
>>> its own merits.  Thanks!
>>>
>>>
>>>
>>> Best,
>>>
>>> Haoyu
>>>
>>>
>>>
>>> *From:* ippm <ippm-bounces@ietf.org> *On Behalf Of * Tommy Pauly
>>> *Sent:* Wednesday, September 13, 2023 9:22 AM
>>> *To:* IETF IPPM WG <ippm@ietf.org>
>>> *Subject:* [ippm] Call for adoption for
>>> draft-mirsky-ippm-hybrid-two-step
>>>
>>>
>>>
>>> Hello IPPM,
>>>
>>>
>>>
>>> This email starts a call for adoption for
>>> draft-mirsky-ippm-hybrid-two-step. This draft has been around for a while
>>> and discussed several times on list and in WG meetings.
>>>
>>>
>>>
>>> https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/
>>>
>>> https://www.ietf.org/archive/id/draft-mirsky-ippm-hybrid-two-step-15.html
>>>
>>>
>>>
>>> Please review the document and email the list with your comments, and if
>>> you think IPPM should adopt this work.
>>>
>>>
>>>
>>> This call for adoption will last three weeks and end on *October 4th*.
>>>
>>>
>>>
>>> Best,
>>>
>>> Tommy
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ippm
>>>
>> _______________________________________________
>> ippm mailing list
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>
>
> --
> Bjørn Ivar Teigen, Ph.D.
> Head of Research
> +47 47335952 | bjorn@domos.ai | www.domos.ai
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>