Re: [ippm] Fwd: New Version Notification for draft-ietf-ippm-stamp-option-tlv-03.txt

Thanks Greg for your reply.
As this is a WG document, an internal authors discussion only is not
sufficient. New field added takes up 16-bits (too many) from the fixed
length format for session-ID, which makes it difficult to add flags for new
use-cases in future. BTW, the packet has 32-bit sequence number, out of
which 16-bits can be used for session-ID in some use-cases. As mentioned if
there is a need, 32-bit sequence number can be added in a TLV. The scope of
the WG adopted draft was to define TLVs for STAMP.

Thanks,
Rakesh

On Fri, Feb 28, 2020 at 6:57 PM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Rakesh,
> thank you for reminding me of the decision WGs chairs made.
> Your questions about SSID are greatly appreciated. Authors of the STAMP
> TLV draft have discussed where to place the SSID field, and our proposal is
> reflected in the updated draft. I'll present it at the IPPM WG meeting and
> will be glad to discuss and answer any questions.
>
> Regards,
> Greg
>
> On Fri, Feb 28, 2020 at 3:40 PM Rakesh Gandhi <rgandhi.ietf@gmail.com>
> wrote:
>
>> Hi Greg,
>> Thanks for your reply.
>> After some good discussions between the IPPM and SPRING chairs, it has
>> already been agreed that the draft-gandhi-spring-twamp-srpm will be hosted
>> in SPRING. It is captured in the chairs update at the last IETF meeting:
>>
>> https://datatracker.ietf.org/meeting/106/materials/slides-106-spring-sessa-chairs-slides-01
>>
>> Original purpose of the draft-ietf-ippm-stamp-option-tlv accepted as a WG
>> document was to define TLVs for STAMP. But now it is also modifying the
>> STAMP packet format. Shouldn't SSID (session ID) be in a STAMP TLV? It can
>> then be 32-bit number (as opposed to 16-bit) and can be used for encoding
>> additional information.
>>
>> This way, we can keep the 16-bits available in the STAMP packet format
>> for future use - instead of leaving no space at all and using up all the
>> available bits in the message for SSID.
>>
>> Recall that draft-gandhi-spring-twamp-srpm only uses one bit flag from
>> the 16-bit field, rest is still available.
>>
>> Thanks,
>> Rakesh
>>
>>
>> On Fri, Feb 28, 2020 at 3:12 PM Greg Mirsky <gregimirsky@gmail.com>
>> wrote:
>>
>>> Hi Rakesh,
>>> thank you for your expedient clarification. I think that one assumption
>>> made in your draft requires very careful consideration by IPPM WG that had
>>> worked on STAMP for quite some time already. Here's the paragraph that
>>> raises a question:
>>>    The loss measurement probe and query messages defined in this
>>>    document are also equally applicable to STAMP and STAMP TLVs, and use
>>>    the message formats defined in [I-D.ippm-stamp].
>>> As I understand, you've planned to anchor this work at SPRING WG though
>>> you propose to update documents developed in IPPM WG. Perhaps Chars of
>>> these two WGs will discuss and suggest to you on the appropriate WG to host
>>> this draft.
>>> As for the proposed changes to STAMP, I believe that these should be
>>> handled with lots of caution and we encourage authors to make the use of
>>> the STAMP extension mechanism provided by TLVs.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Fri, Feb 28, 2020 at 10:10 AM Rakesh Gandhi <rgandhi.ietf@gmail.com>
>>> wrote:
>>>
>>>> Hi Greg,
>>>> Thanks for your reply.
>>>> The draft-gandhi-spring-twamp-srpm includes both TWAMP Light and STAMP
>>>> (Section 3.2) (TLVs for STAMP in other sections). Two drafts are updating
>>>> the same field in the STAMP packet format.
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>> On Thu, Feb 27, 2020 at 11:14 PM Greg Mirsky <gregimirsky@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Rakesh,
>>>>> thank you for your interest in the update to STAMP extensions. Can you
>>>>> elaborate on where you see the conflict between STAMP and your proposal? Is
>>>>> the change you've proposed applicable to STAMP test packet? As far as I
>>>>> understand, STAMP cannot support your proposal and interwork with a system
>>>>> that is complaint with draft-gandhi-spring-twamp-srpm. As for STAP
>>>>> interworking with TWAMP in Unauthenticated mode, SSID doesn't change
>>>>> anything, as TWAMP Session-Sender will zero the field and Session-Reflector
>>>>> will ignore it on receipt. So I don't see conflict here at all. I greatly
>>>>> appreciate your clarification.
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>> On Thu, Feb 27, 2020 at 7:48 PM Rakesh Gandhi (rgandhi) <
>>>>> rgandhi@cisco.com> wrote:
>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> I noticed that this STAMP TLV draft update is proposing to modify the
>>>>>> STAMP packet format to contain SSID.
>>>>>>
>>>>>>
>>>>>>
>>>>>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>
>>>>>>       |         Error Estimate        |             SSID              |
>>>>>>
>>>>>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>
>>>>>>
>>>>>>
>>>>>> The SRPM draft posted in December had already proposed to use the
>>>>>> same field for control-code.
>>>>>>
>>>>>> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-05
>>>>>>
>>>>>>     .                                                               .
>>>>>>
>>>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>
>>>>>>     |         Error Estimate        | Reserved      |  Control Code |
>>>>>>
>>>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>
>>>>>>     .
>>>>>>
>>>>>>
>>>>>>
>>>>>> Looks like there is a conflict in packet format update proposed that
>>>>>> need to sort out.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Rakesh
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *ippm <ippm-bounces@ietf.org> on behalf of Greg Mirsky <
>>>>>> gregimirsky@gmail.com>
>>>>>> *Date: *Friday, February 21, 2020 at 11:07 AM
>>>>>> *To: *IETF IPPM WG <ippm@ietf.org>
>>>>>> *Subject: *[ippm] Fwd: New Version Notification for
>>>>>> draft-ietf-ippm-stamp-option-tlv-03.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>> Dear All,
>>>>>>
>>>>>> the new version includes updates to the Followup Telemetry TLV and
>>>>>> introduces the new HMAC TLV.
>>>>>>
>>>>>> We always welcome and greatly appreciate your comments, questions,
>>>>>> and suggestions.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Greg
>>>>>>
>>>>>> ---------- Forwarded message ---------
>>>>>> From: <internet-drafts@ietf.org>
>>>>>> Date: Fri, Feb 21, 2020 at 8:04 AM
>>>>>> Subject: New Version Notification for
>>>>>> draft-ietf-ippm-stamp-option-tlv-03.txt
>>>>>> To: Henrik Nydell <hnydell@accedian.com <hnydell@accedian..com>>,
>>>>>> Min Xiao <xiao.min2@zte.com.cn>, Adi Masputra <adi@apple.com>,
>>>>>> Ernesto Ruffini <eruffini@outsys.org>, Gregory Mirsky <
>>>>>> gregimirsky@gmail.com>, Richard Foote <footer.foote@nokia.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> A new version of I-D, draft-ietf-ippm-stamp-option-tlv-03.txt
>>>>>> has been successfully submitted by Greg Mirsky and posted to the
>>>>>> IETF repository.
>>>>>>
>>>>>> Name:           draft-ietf-ippm-stamp-option-tlv
>>>>>> Revision:       03
>>>>>> Title:          Simple Two-way Active Measurement Protocol Optional
>>>>>> Extensions
>>>>>> Document date:  2020-02-21
>>>>>> Group:          ippm
>>>>>> Pages:          25
>>>>>> URL:
>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-ippm-stamp-option-tlv-03.txt
>>>>>> Status:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/
>>>>>> Htmlized:
>>>>>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-03
>>>>>> Htmlized:
>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-option-tlv
>>>>>> Diff:
>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-option-tlv-03
>>>>>>
>>>>>> Abstract:
>>>>>>    This document describes optional extensions to Simple Two-way
>>>>>> Active
>>>>>>    Measurement Protocol (STAMP) which enable measurement performance
>>>>>>    metrics in addition to ones supported by the STAMP base
>>>>>>    specification.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>> submission
>>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>>
>>>>>> The IETF Secretariat
>>>>>>
>>>>> _______________________________________________
>>>>> ippm mailing list
>>>>> ippm@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>>
>>>>