Re: [ippm] Barry Leiba's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS)

Henrik Nydell <hnydell@accedian.com> Wed, 11 September 2019 08:42 UTC

Return-Path: <hnydell@accedian.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 F1DB21200B2 for <ippm@ietfa.amsl.com>; Wed, 11 Sep 2019 01:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian-com.20150623.gappssmtp.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 qSH5O06i0omu for <ippm@ietfa.amsl.com>; Wed, 11 Sep 2019 01:42:36 -0700 (PDT)
Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 10198120833 for <ippm@ietf.org>; Wed, 11 Sep 2019 01:42:36 -0700 (PDT)
Received: by mail-vk1-xa35.google.com with SMTP id d126so2086485vkb.1 for <ippm@ietf.org>; Wed, 11 Sep 2019 01:42:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FXLlikzcOce6ISzttD0uKhkmWP4RPqldDJSRuSSS4Bc=; b=mL5ZZAok/Eru9Be4F/IDQ2Tbz5pJanY1uvpL0uTbl/dCvR7BPBM4QIhuurD76p9po4 UNgIxbbcQe36Z/7KC22Fz6r4J79i713qSz/m8lv4lDz0gqxkwLtQe7XkZjuM6zoS8mz1 lKw8Pxj+GK9ii0FdpXqKi02wvIqyzsaQKLG/4N0Ogb7owVmgZXH1ln54VCvNFc5GlPk1 u4o6FyIo+Fo1SMU7c1hs3csBRGILGMKWGS7+UmznUYwvPLLahYxYe4LFGuz49+lLfl5I LbqW/msLETCs3j1sTwwV2WO/Gk0bzv30h1VPAo/GDd4Dig1FM4Y8AUCLx4WoQGtAXqyN XNig==
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=FXLlikzcOce6ISzttD0uKhkmWP4RPqldDJSRuSSS4Bc=; b=BlawYlMbXvBUmjecoi1i1jMlNUBYnO7l3YWJ+H6mozEdmqjk0kDgEvz6ECFnJ0Bz3z lviaP+H0LQ3qY/JTiJzuuEzqI1wGTiMeM9bod6y2DwZCaGRAe09YQeZ4rUE0zhRDdNl7 yaNOPIdHUuImIaFzoe3+R6983BcDzsBpNyxXl/p5oTVnJ/uVj/ysfAlxJoBRfiVeVTcT gWYSOTcglNfhfLyc9iMm90syXC+UYPdmEVJ0YcgbiDlE0osVsUaHAMBT8gIEC6MitfwU z9N5904pGAD1wA5+7NmBVuiT9tIGtL0k/Yr/fPMZfSoVxrHbyU+jxVG/BZWaJrjZNNT1 HqIw==
X-Gm-Message-State: APjAAAU3AbsHE3RjaAjbDt8QIknJQyX2I9T4sC2eoL9Qzi4+v7bT3Wyi g/YqtE7IQsjurjoaq9I/65OYZ3K/qkEY8HbeyIWys4x1J4Kewvtcs7lXwDVbcii34uceyPx5Rfe zKb6yMM2IQw==
X-Google-Smtp-Source: APXvYqwrcPXWi49U8ntB6Nivq+ukfFyeualVURmg6tsnisDslXkQUI4TzKjcuml2TPpS0EG+mWVriIM7OrIeIKFnRps=
X-Received: by 2002:a1f:2192:: with SMTP id h140mr5527422vkh.92.1568191354976; Wed, 11 Sep 2019 01:42:34 -0700 (PDT)
MIME-Version: 1.0
References: <156761599202.22808.13015902618373150935.idtracker@ietfa.amsl.com> <CA+RyBmV4_HaAC2=petia=SCh6wyAu+eRvbHtt5yKTioqn6jJNg@mail.gmail.com> <CALaySJLoUJX+4hA2inmGfG05Lf0kMv0QgsHTpS1_74+N0XzZvg@mail.gmail.com>
In-Reply-To: <CALaySJLoUJX+4hA2inmGfG05Lf0kMv0QgsHTpS1_74+N0XzZvg@mail.gmail.com>
From: Henrik Nydell <hnydell@accedian.com>
Date: Wed, 11 Sep 2019 10:42:23 +0200
Message-ID: <CALhTbpoYSDTjD0q=0t81mgQB4=JbHcfJ86tuMN-v7hJYXLYNsg@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: Greg Mirsky <gregimirsky@gmail.com>, 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="000000000000a752020592430004"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/4ZH2nah8i94rXhWc8DNDxPRDe0o>
Subject: Re: [ippm] Barry Leiba's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS)
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: Wed, 11 Sep 2019 08:42:40 -0000

The STAMP test (As for RFC5357 TWAMP and for example Cisco IP-SLA , Huawei
U.2520, Juniper RPM and other in-line test functions) is indeed intended to
be used on production networks to enable the operator to assess service
level agreements based on delay, jitter and loss. So the rephrasing needs
to be done keeping that in mind, and I see no implications on using it over
the Internet either. The agreement on UDP ports to use needs to be done
between the session-sender and the session-reflector only. Intermediate
nodes or other users of the network need not be aware of the STAMP test or
the ports it uses. It is in fact desirable that the STAMP packets are not
distinguishable from other traffic on the network, but are treated just
like any user traffic in the class of service they are transmitted.

Best
Henrik

On Wed, Sep 11, 2019 at 2:15 AM Barry Leiba <barryleiba@computer.org> wrote:

> Hi, Greg, and thanks for the response.
>
> I think a minor rephrasing of the requirement isn't enough, really.
> As I understand it now, after other discussion, it's not that you need
> agreement from the users, but that you should put a paragraph (or
> maybe a separate section, to highlight the point) that says that this
> is not intended for use on the open Internet nor on production
> networks, and gives examples of what it *is* intended for... perhaps
> test networks, production networks during advertised maintenance
> windows, that sort of thing.  And then you don't need to say that the
> network's users need to agree, but simply that they need to be aware
> that performance testing will be happening during period X, and that
> disruptions to normal network operation are possible.  You'd need to
> come up with text that the working group agrees with, of course, but I
> think that if you do it will address my concern as well as some of the
> others that were raised.
>
> Does that make sense?
>
> Barry
>
> On Tue, Sep 10, 2019 at 5:01 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
> >
> > Hi Barry,
> > thank you for your pointed question. Please find my explanation and the
> proposed updated below under the GIM>> tag.
> >
> > Regards,
> > Greg
> >
> > On Wed, Sep 4, 2019 at 9:53 AM Barry Leiba via Datatracker <
> noreply@ietf.org> wrote:
> >>
> >> Barry Leiba has entered the following ballot position for
> >> draft-ietf-ippm-stamp-07: Discuss
> >>
> >> 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/
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >> I'm sure this will be easy to either explain to me or re-phrase:
> >>
> >> Sections 4 and 6 both say something like "MUST be agreed by all users
> of the
> >> network".  What does that really mean?  How is it remotely possible to
> get
> >> agreement from all users of your network?  How is it remotely possible
> that
> >> they could understand what you're asking them to agree to?
> >
> >
> > GIM>> Yes, looking at the bigger picture, at the Internet rather than
> only at the domain where the test will be performed makes such condition
> unattainable. Would s/network/network domain where the test is planned/  so
> that it reads as:
> >
> > ... MUST be agreed by all users on the network domain where the test is
> planned ...
> >
> > make it clearer and the number of parties involved reasonable, practical?
> > As for what the could be the question users will be asked, I think that
> it should verify whether the application that has the port number assigned
> is active as the same number will be used as the destination port number in
> the STAMP test.
>


-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
hnydell@accedian.com
<http://accedian.com>
<https://www.facebook.com/accedian/>  <https://twitter.com/Accedian>
<https://www.linkedin.com/company/accedian-networks?originalSubdomain=ca>
<http://www.accedian.com>
*accedian.com <http://accedian.com>*

-- 


Avis de confidentialité

Les
 informations contenues dans le présent 
message et dans toute pièce qui 
lui est jointe sont confidentielles et 
peuvent être protégées par le 
secret professionnel. Ces informations sont 
à l’usage exclusif de son ou
 de ses destinataires. Si vous recevez ce 
message par erreur, veuillez 
s’il vous plait communiquer immédiatement 
avec l’expéditeur et en 
détruire tout exemplaire. De plus, il vous est 
strictement interdit de 
le divulguer, de le distribuer ou de le reproduire 
sans l’autorisation 
de l’expéditeur. Merci.


Confidentiality notice

This

 e-mail message and any attachment hereto contain confidential 
information 
which may be privileged and which is intended for the 
exclusive use of its 
addressee(s). If you receive this message in error,
 please inform sender 
immediately and destroy any copy thereof. 
Furthermore, any disclosure, 
distribution or copying of this message 
and/or any attachment hereto 
without the consent of the sender is 
strictly prohibited. Thank you.