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

[Greg Mirsky <[e-mail]>]

Hi Martin,
my apologies for the delayed response. Thank you for sharing your thoughts
and questions. Please find my notes below tagged GIM>>.
Attached, please find the new working version and diff highlighting the
proposed updates.

Regards,
Greg

On Thu, Sep 21, 2023 at 1:45 PM Martin Duke <[e-mail]> 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.
>
GIM>> RFC 8169 <https://datatracker.ietf.org/doc/rfc8169/> is one of known
to me examples that creates packets that must follow the path of the
preceding packet. AFAIK, there was no issues with deploying implementations
in a network.

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.
>
GIM>> Updated Abstract as following:
NEW TEXT:
   The development and advancements in network operation automation have
   brought new measurement methodology requirements.  mong them is the
   ability to collect instant network state as the packet being
   processed by the networking elements along its path through the
   domain.  That task can be solved using on-path telemetry, also called
   hybrid measurement.  An on-path telemetry method allows the
   collection of essential information that reflects the operational
   state and network performance experienced by the packet.  This
   document introduces a method complementary to on-path telemetry that
   causes the generation of telemetry information.  This method,
   referred to as Hybrid Two-Step (HTS), separates the act of measuring
   and/or calculating the performance metric from collecting and
   transporting network state.  The HTS packet traverses the same set of
   nodes and links as the trigger packet, thus simplifying the
   correlation of informational elements originating on nodes traversed
   by the trigger packet.

Is it clearer now?

>
> 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?
>
GIM>> You are correct.

>
> 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.
>
GIM>> Thank you for your question. HTS is based on the requirement stated
in Section 4.4:
4.4.  Considerations for HTS Timers

   This specification defines two timers - HTS Follow-up and HTS
   Collection.  For the particular flow, there MUST be no more than one
   HTS Trigger, values of HTS timers bounded by the rate of the trigger
   generation for that flow.

The requirement is to have only one on-path telemetry packet, e.g., a
packet equipped with IOAM-DEX header, of a particular monitored flow in the
network. I think that avoid the mis-correlation of HTS packets and the
trigger packet of the telemetry protocol.

>
> What assurances are there that the followon packet followed the same path
> from ingress to egress as the trigger packet?
>
GIM>> Ensuring that a followup packet traverses the same set of nodes and
links as the trigger packet is the responsibility of the HTS Egress node
defined in Section 4.1:
   The follow-up packet has the transport network encapsulation
   identical with the trigger packet followed by the HTS shim and one or
   more telemetry information elements encoded as Type-Length-Value
   (TLV).

What are the consequences of this not happening and remaining undetected?
>
GIM>> An HTS Intermediate node starts the HTS Followup timer upon receiving
the HTS Trigger packet. If the HTS Timer expires before the node receives
corresponding followup packet node acts as defined in Section 4.2:
   If the HTS Follow-up Timer expires, the intermediate node MUST:

   *  originate the follow-up packet using transport information
      associated with the expired timer;

   *  initialize the HTS shim by setting the Version field's value to
      0b00 and Sequence Number field to 0.  Values of HTS Shim Length
      and Telemetry Data Profile fields MAY be set according to the
      local policy.

   *  copy telemetry information into Telemetry Data TLV's Value field
      and transmit the packet.
Further, the section defines handling of a "late" followup packet:

   If the intermediate node receives a "late" follow-up packet, i.e., a
   packet to which the node has no associated HTS Follow-up timer, the
   node MUST forward the "late" packet.


> This is not very important, but I find "hybrid two-step" to be a
> nondescriptive name, and might prefer something like "IOAM Followon".
>
GIM>> I imagine that HTS can complement other on-path telemetry methods,
e.g., Alternate Marking method.

>
> Martin
>
>
> On Tue, Sep 19, 2023 at 11:28 AM Haoyu Song <[e-mail]>
> 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 <[e-mail]> *On Behalf Of * Tommy Pauly
>> *Sent:* Wednesday, September 13, 2023 9:22 AM
>> *To:* IETF IPPM WG <[e-mail]>
>> *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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ippm
>>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>