Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv

Hi Rakesh,
I think that there could be various methods to optimize PM OAM ranging from
HW-based to CPU-centric with a number of "bump on a wire" solutions.

Regards,
Greg

On Tue, Jul 16, 2019 at 5:27 AM Rakesh Gandhi <rgandhi.ietf@gmail.com>
wrote:

> Hi Tianran,
> Yes, in some use-cases the TLV can carry the counters from the CPU
> processing (e.g. control-plane). In other use-cases, as the counters for
> the direct-mode LM (for actual data traffic) are in the hardware itself,
> the hardware can counter-stamp the probe packets just like time-stamping
> for DM
>
> Thanks,
> Rakesh
>
>
>
>
>
>
>
> On Mon, Jul 15, 2019 at 11:05 PM Tianran Zhou <zhoutianran@huawei.com>
> wrote:
>
>> Hi Rakesh,
>>
>>
>>
>> I am not clear why the direct loss test need to be hardware friendly.
>>
>> It seems the STAMP is end to end over UDP. It could be CPU processing.
>>
>>
>>
>> Tianran
>>
>>
>>
>> *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Rakesh Gandhi
>> *Sent:* Monday, July 15, 2019 10:48 PM
>> *To:* Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
>> *Cc:* draft-mirsky-ippm-stamp-option-tlv@ietf.org; IETF IPPM WG <
>> ippm@ietf.org>
>> *Subject:* Re: [ippm] Adoption call for
>> draft-mirsky-ippm-stamp-option-tlv
>>
>>
>>
>> Hi Authors,
>>
>> There were couple of items discussed on the mailing list and have added
>> them below for convenience. Like to see them addressed in the adopted draft.
>>
>>
>>
>> Thanks,
>>
>> Rakesh
>>
>>
>>
>> ------------------------------
>>
>> Regarding the size of the padding, yes, it's good to use the same size
>> payload for query and response.
>>
>> However, the STAMP payload with TLV extension
>> (draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size
>> of 30 MBZ vs 27 ( or > 29)in draft-ietf-ippm-stamp. Is there a way to make
>> them compatible? Does it mean that for STAMP with TLV, Server Octets is set
>> to 1, but it says MBZ 0 for all 30 bytes.. If the responder supports Server
>> Octets and see the size > 27, it may find the Server Octet size of 0
>> confusing?
>>
>>
>>
>> --------------------------
>>
>>
>>
>> The direct measurement TLV proposed in the draft may not be hardware
>> friendly for actual data traffic loss measurement due to the need to search
>> the presence of the TLV and the counter offset not always fixed due to the
>> variable length payload. Also, it overloads the delay measurement probes
>> just for measuring packet loss which complicates the implementation.
>>
>> GIM>> The Direct Loss TLV is intended to immediately follow the STAMP
>> test packet and thus its location is known. We'll work on the text to guide
>> implementations to be more HW friendly and support efficient testing.
>>
>>
>>
>> <RG> Revised format looks like following:
>>
>>
>>
>>        0                   1                   2                   3
>>
>>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>       |                        Sequence Number                        |
>>
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>       |                          Timestamp                            |
>>
>>       |                                                               |
>>
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>       |         Error Estimate        |                               |
>>
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
>>
>>       |                                                               |
>>
>>       |                                                               |
>>
>>       |                         MBZ (30 octets)                       |
>>
>>       |                                                               |
>>
>>       |                                                               |
>>
>>       |                                                               |
>>
>>       |                                                               |
>>
>>      * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>>
>>      * |*   * Direct Measurement Type*   * |*          * Length*
>>              * |*
>>
>>      * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>>
>>      * |*            * Session-Sender Tx counter* * (S_TxC)*
>>               *|*
>>
>>      * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>>
>>      * |*            * Session-Reflector Rx counter* * (R_RxC)*
>>             * |*
>>
>>      * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>>
>>      * |*            * Session-Reflector Tx counter* * (R_TxC)*
>>             * |*
>>
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>       |             Type              |           Length              |
>>
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>       ~                            Value                              ~
>>
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>>
>> On Mon, Jul 8, 2019 at 6:53 PM Tommy Pauly <tpauly=
>> 40apple.com@dmarc.ietf.org> wrote:
>>
>> Hello IPPM,
>>
>>
>>
>> This message begins an adoption call for
>> draft-mirsky-ippm-stamp-option-tlv, "Simple Two-way Active Measurement
>> Protocol Optional Extensions”. The document has been discussed on the list
>> recently, with good input and reviews from the group. We’d like to get the
>> working group’s input on if this document should be adopted and worked on
>> by the group.
>>
>>
>>
>> The current status and text of the document can be found here:
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/
>>
>> https://tools.ietf.org/html/draft-mirsky-ippm-stamp-option-tlv-05
>>
>>
>>
>> Please respond to this email by *Tuesday, July 23* to indicate whether
>> or not you think IPPM should adopt and work on the extensions and extension
>> mechanism described in this draft.
>>
>>
>>
>> Best,
>> Tommy (as IPPM co-chair)
>>
>> _______________________________________________
>> ippm mailing list
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>>