Re: [ippm] Martin Vigoureux's No Objection on draft-ietf-ippm-stamp-07: (with COMMENT)

Greg Mirsky <gregimirsky@gmail.com> Tue, 10 September 2019 23:36 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 EA33B120026; Tue, 10 Sep 2019 16:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ksNvPmFYO7CM; Tue, 10 Sep 2019 16:36:50 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 BBD0E120013; Tue, 10 Sep 2019 16:36:49 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id y5so7336584lji.4; Tue, 10 Sep 2019 16:36:49 -0700 (PDT)
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=06/wqBuhwuMXjQRQiCHSRitx4dp75B799gIYBRAsfwE=; b=YG6vB9riw1lTsF8FGdEjGUPEaUkR2ySovKOMO+HM6HKQgy9imTx6b/9cQMaB2Ct8su D/wuw/UTyMvDOT3qMA/FsRd/Izdx+eBEaFfpDCKtSsqPtaijKzgYN6nNdEeVysHtVo+O Zvpm8PbrK8tsQAS+NmX3vUNmhGM9hssPs8rUBIcGxInAK/sRvGQVy/+6au+v28VT5Ii/ e1wr8kZStR8Zxj9mzmOz9/mgJkdFNmib0hX0LbNb/HBUsgF+MYBJHiQs3aOZW4OUxA4B /LkqCILZ4iXBJutjZ/e1ABaM6NqBToreGOp41G65oZQa5ZNVzv/B3LJt0LobUAl838j+ WyHQ==
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=06/wqBuhwuMXjQRQiCHSRitx4dp75B799gIYBRAsfwE=; b=nd0X2VCzZJldP+vByctDHN6EyfgPhVzExm47Hx2RmOPoHJt+Rdxn3ZCmMvayl1Wl/V D5X1ORT+ZVNUphsX67kbT+GnWAt6SVWCOX/FH3vQmLJniJJIVdwF3u0AjVusGBaMCiZA T3+hOuF6ks87Lo5cA53v57HEkDveP+Bv6fZr2IuIKOBnSzilfAsuBi5FO/7VTzo0E5OE 4/8Mf7j3YvGJ3hCBLOTPj2Ke87NHofp+Vcfa/3RRmrcZPRDAWk9nK/eTyZEkYNY1ui40 V6zlfvrvfBM0vVnMhuMzwniqJbBBxerOnfJzuUV4MfZOuI/m3GBq1sfevTALtG/WrXfh ZGOA==
X-Gm-Message-State: APjAAAX0oMqFkpsQ2aI66k3GkcAExTVvTLBpzCkXHktnm/jUu2X+SZBk 4yQV+wnuIV0NKHQGByByB+w0rgsgkt/txFNtxU4=
X-Google-Smtp-Source: APXvYqwvuQHgZxlyBB3IK3YoiD1xeBNRrgm03MragZrdCPr34HXJTtUJ0mus0alLrfEq4NgMReJwAoMe1VExNtGm6ZM=
X-Received: by 2002:a2e:3201:: with SMTP id y1mr18026600ljy.177.1568158607965; Tue, 10 Sep 2019 16:36:47 -0700 (PDT)
MIME-Version: 1.0
References: <156769231672.22739.6443411633239129567.idtracker@ietfa.amsl.com>
In-Reply-To: <156769231672.22739.6443411633239129567.idtracker@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 10 Sep 2019 16:36:36 -0700
Message-ID: <CA+RyBmW5GaYy3S6x_+5zLAtfasG-BW34aUifP==MZOLyeSFsWA@mail.gmail.com>
To: Martin Vigoureux <martin.vigoureux@nokia.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ippm-stamp@ietf.org, Tal Mizrahi <tal.mizrahi.phd@gmail.com>, IPPM Chairs <ippm-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c7826605923b601f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/eNHtxCJHmxOUgGlD1jDM0Y-uVBQ>
Subject: Re: [ippm] Martin Vigoureux's No Objection on draft-ietf-ippm-stamp-07: (with COMMENT)
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: Tue, 10 Sep 2019 23:36:52 -0000

Hi Martin,
thank you for your comments and questions. Will follow on to address
Barry's DISCUSS on another thread. In this reply, please find answers to
your comments in-line tagged GIM>>.

Regards,
Greg

On Thu, Sep 5, 2019 at 7:05 AM Martin Vigoureux via Datatracker <
noreply@ietf.org> wrote:

> Martin Vigoureux has entered the following ballot position for
> draft-ietf-ippm-stamp-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support Barry's DISCUSS.
>
> Also a few points are not clear:
>
>    o  Stateless - STAMP Session-Reflector does not maintain test state
>       and will reflect the received sequence number without
>       modification.
> This is not the only thing that the reflector reflects, right?
>
GIM>> Correct. A Session-Reflector reflects all the information received in
a test packet as well as the value of TTL/Hop Count field. To clarify how
the Stateless mode is different from the Stateful propose the following
update:
OLD TEXT:
      Stateless - STAMP Session-Reflector does not maintain test state
      and will reflect the received sequence number without
      modification.
NEW TEXT:
      Stateless - STAMP Session-Reflector does not maintain test state
      and will use the value in the Sequence Number field in the
      recieved packet as the value for the Sequence Number field in the
      reflected packet.  As a result, values in Sequence Number and
      Session-Sender Sequence Number fields are the same, and only
      round-trip packet loss can be calculated while the reflector is
      operating in stateless mode.

>
>       The STAMP Session-Sender and Session-Reflector MAY use, not use,
>       or set value of the Z field in accordance with the timestamp
>       format in use.  This optional field is to enhance operations, but
>       local configuration or defaults could be used in its place.
> What do you mean by "use"and how does that differ from "set"?
>
GIM>> Yes, it's awkward. We propose the following update:
OLD TEXT:
      The STAMP Session-Sender and Session-Reflector MAY use, not use,
      or set value of the Z field in accordance with the timestamp
      format in use.  This optional field is to enhance operations, but
      local configuration or defaults could be used in its place.
NEW TEXT:
      The STAMP Session-Sender and Session-Reflector MUST use a Z field
      value of 0, (NTP 64 bit format of a timestamp) as the default.
      The STAMP Session-Sender and Session-Reflector MAY optionally set
      the Z field to a value of 1 (PTPv2 truncated format of a
      timestamp).

Also the fact that it is described as optional here but as "MUST/SHOULD be
> set
> to NTP" in interop with TWAMP light is confusing.
>
GIM>> Thank you for pointing to these two references. After reviewing them,
we've concluded that the first is in fact unnecessary because only the
Session-Sender uses timestamp and must be aware of its format. Hence, in
the case when a Session-Reflector supports TWAMP-Light, STAMP
Session-Sender can use any format. Will remove these two sentences:
  The Session-Sender SHOULD use the default format for its timestamps -
   NTP.  And it MAY use PTPv2 timestamp format.
The second reference to the Z flag in the section:
   The Session-Reflector MUST be set to use the default format
   for its timestamps, NTP.
is in sync with the proposed above update.
Would these changes address your concern?