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

Greg Mirsky <gregimirsky@gmail.com> Fri, 28 February 2020 23:57 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41733A0524; Fri, 28 Feb 2020 15:57:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0tHk8jLVe87; Fri, 28 Feb 2020 15:57:10 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C793A0474; Fri, 28 Feb 2020 15:57:09 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id b15so3383515lfc.4; Fri, 28 Feb 2020 15:57:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7a3fQF3JYDtv6awIBV5YNMwzUPTeOrO4CsRfvSa9LQw=; b=nPGZoLLPaxygKNXhymLThpCUqeLcjO5ESh4SX4+IKLCTqNSFdXfdd4Ea4+HE9qMfP1 QuE+iADE8MfaRoGk4Oqbr7PA0d2kTQqJAUibXipYJi3Zc70ZcS+b0AQJ+hzBN/HBrKQM pwppxfb0CCTjiKf1rq/uunfaybZ0NlCpXmBVLYI3kCPJMWEQtnlKQSYa+A3jR/JkWKqB 5OEHN3w+qLx60/lSSZNYCnGn3jCCU/0cZDyQZKkrFNcX6xW76UKYHsWvWo+6Tmlqr6o2 ZIagEkj60uOo0rrrn5Xw2wc8+8vok8DtGauZRfvjx7+b5XU0/aIxVw7Nftcf1XGqBFuB 3Upw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7a3fQF3JYDtv6awIBV5YNMwzUPTeOrO4CsRfvSa9LQw=; b=TJ/Tt7wD/s0bGRb0b/NfsBECHgPTzWS3+uOHR9a1who53fonvmX/x5ZryTGXy4oDok cPMPNauorJDHNoaaLI3U4F98+5cdKfGzF4speGaBcBSllFBVJaayAaC5D2DzgbReoPMK p0ZsOG+Ow3h72e8HK4ACLs8Ev8K9JEhedQF+Iseeise0P/opfc0/LBcQw3iYvY8CEsJb oX01LdK9cRaJqpa7WD1JU8ktSvsng8yfQ+NSGS6x1SfFltwRPgVpDCe41gW6+xXzzbgR JWWH70w/ruKMgR+M+1ZLZ47pIzqFWOumTxOi58aHU20I28OM6w6oY53Ib492hwyaACZM zvoA==
X-Gm-Message-State: ANhLgQ3884Ld3w4XVNmE3bnZzEyRAqg5n8s6i7X4tyMGQxJx1Ery9V/n wgbXfM98E1xaOKkldXGhLzVArm8nP4Ea9QXwKnE=
X-Google-Smtp-Source: ADFU+vssGO1w7ZQsOemX06GrKpN2XqvxdaZ/RIaJjotDwlDEkfw7hyvgvFF2+JXk8YEw6r43RHsDAwgPkGuVoZNePBc=
X-Received: by 2002:ac2:4c39:: with SMTP id u25mr3763866lfq.195.1582934227712; Fri, 28 Feb 2020 15:57:07 -0800 (PST)
MIME-Version: 1.0
References: <158230107443.29037.14133930624764653909.idtracker@ietfa.amsl.com> <CA+RyBmWChGcvBtjBf2J9788D6Jkjhvg2L3jK5DRNUg-ZLMin_g@mail.gmail.com> <4ABD2C49-D3AC-4E3E-8059-259371085D91@cisco.com> <CA+RyBmUTh6NL-h-d7BqJG-mL7=sBLw7zn45DRP8SrR4a8dT_PQ@mail.gmail.com> <CAMZsk6deP3fFtWhYqLBSmLBtEmFw4fhoojHak6UAvu6A369ZgQ@mail.gmail.com> <CA+RyBmW81gMSZ6kpzV6RMiKy1oXpe0ekYznvXqxWVe1tc2Cbyg@mail.gmail.com> <CAMZsk6dJEnhrC9ebMpKbeu4gJ0Jck-c+KJLTmOShfCZ24EAgDQ@mail.gmail.com>
In-Reply-To: <CAMZsk6dJEnhrC9ebMpKbeu4gJ0Jck-c+KJLTmOShfCZ24EAgDQ@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 28 Feb 2020 15:56:56 -0800
Message-ID: <CA+RyBmXkUF6+Lq990gMWRPs8UjSzLu_UJ-Nvi82-U1zBfbNtuQ@mail.gmail.com>
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@ietf.org, "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000587e60059fab98fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/v9JVxTFDEWfSSeJuLdZ1vtin6Vc>
Subject: Re: [ippm] Fwd: New Version Notification for draft-ietf-ippm-stamp-option-tlv-03.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 23:57:15 -0000

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
>>>>
>>>