Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 26 September 2019 08:41 UTC

Return-Path: <magnus.westerlund@ericsson.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 6EB9F12085C; Thu, 26 Sep 2019 01:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 dji0MakT9Rjs; Thu, 26 Sep 2019 01:41:27 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0623.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::623]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6929120104; Thu, 26 Sep 2019 01:41:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jog2mmQ12ElOVdgP85H33mHOhli2rRBkIGlzPehJNPznFOpv1yJSeHJ95G3dkWncgn4DtM985CvTPey5QIgJuyB9QJdZpKbY6g8DLoKcv1FLXeGyE3HyAgjTytastK8xEFkuHJJ7NSDfpRMOO+Mkg9Rb/Y+V9fFAmapIbcLBaPfMAEMa+Tm/xHmrk/jA6IZcLZrP6Qb22ZWlMtakolpkFGo0miwszoZShNBkjtRA4/nMi1fsSQkzV8FMJABufPSGD8K9Fc5xVcNi5jwCZFBHIYbqUtMf5o9yuzpLgAFdgjJfkVK4gm1Yec6ll2f/1UqI438oE5+080Iz4MgkIOgd1Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kXZ4x+Sf9oGTo9yZPOXtRHv4O3Y6r0jQvYCRcMxbFlo=; b=hqixQ+5dqnVwjBoHPr3qUgdXhMieZE40JOVCXkpoNx9uimBWUVxWx5uEo9tHSrN1Y8YOb3JGatuanS6u3ulOwHi9LKhqeeN1pE5L7Gq0HIMXaF+SWPOZG2r/49PJC97UlkIQ6aNlDF7yBNTcTHQciFnrwsnQ6HJx5ePWa/4rSipywOzOwMd8o7yMvt3GweNIIr3VmdXkfUxUAdak3/1J1T7gjdHz4aPUyitIPGKJCaLsQFZ4IZh72EUL/leAOUHyxxpM6gh0FN8iCQvw4F6UQu7g2Npw7/oxOEKEDs2grSTVzrr6ZgwV5ZzlElYdzavNKO/rIrbO4bB7vh163+Zt/Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kXZ4x+Sf9oGTo9yZPOXtRHv4O3Y6r0jQvYCRcMxbFlo=; b=UPIbGXH0PArRn4kN5WLoVKRWYvR8DzG8BSl05KGux4DoNxdWwSs7Q77dk4Wn9oxUnPvOCc681+yq++Tz6b4gTwmXi1TAfW+gAyKs4uej6A06WhqQuMsFCd7tdnGPqB+P0f4eypO3yVl5ih95/NLQXpZlOHTQq8hcsxTX51555Bg=
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com (20.177.194.155) by DB7PR07MB5078.eurprd07.prod.outlook.com (20.177.192.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Thu, 26 Sep 2019 08:41:23 +0000
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::e48c:a942:9682:2ce4]) by DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::e48c:a942:9682:2ce4%7]) with mapi id 15.20.2305.017; Thu, 26 Sep 2019 08:41:23 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "gregimirsky@gmail.com" <gregimirsky@gmail.com>
CC: "draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "tal.mizrahi.phd@gmail.com" <tal.mizrahi.phd@gmail.com>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)
Thread-Index: AQHVaBAbqbmUyWu4qEOdjey0JDZTiacmG9IAgACy4wCAB6hCAIAM6RsAgAJcJgA=
Date: Thu, 26 Sep 2019 08:41:23 +0000
Message-ID: <d87ce9b28bc7649875a1e5faff975e899f4609c9.camel@ericsson.com>
References: <156760524845.22816.16339950342338392164.idtracker@ietfa.amsl.com> <CA+RyBmUy-_ETfaPWoYivcWa0S3De4dcn9=Wb47M7x0vSfEsjYQ@mail.gmail.com> <06fcd3bea80067202534aa70857194b2e4335d3f.camel@ericsson.com> <CA+RyBmUowr39bRBDv1g35f-rJve-whkscd0ht17cjJA5-rWixQ@mail.gmail.com> <ed5f1afb634e8c0d39cdb6c2a52ad9e2ab459285.camel@ericsson.com> <CA+RyBmU08iGsqK9M9Vyq5wgs9UKQ7Q7c1zg_0j4u4X_48jOHGw@mail.gmail.com>
In-Reply-To: <CA+RyBmU08iGsqK9M9Vyq5wgs9UKQ7Q7c1zg_0j4u4X_48jOHGw@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 28a870cc-2bee-4816-2e8b-08d7425d500d
x-ms-traffictypediagnostic: DB7PR07MB5078:
x-microsoft-antispam-prvs: <DB7PR07MB5078D7717F867093D1459A2195860@DB7PR07MB5078.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0172F0EF77
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(39860400002)(396003)(366004)(199004)(51914003)(189003)(51444003)(966005)(478600001)(102836004)(25786009)(8676002)(14454004)(186003)(26005)(44832011)(66574012)(81166006)(81156014)(1730700003)(99936001)(66066001)(2616005)(486006)(476003)(4326008)(76176011)(6512007)(6246003)(1411001)(6486002)(14444005)(2351001)(5640700003)(6436002)(54906003)(53546011)(316002)(6306002)(6506007)(71190400001)(66946007)(2906002)(76116006)(64756008)(66556008)(7736002)(305945005)(118296001)(6116002)(36756003)(3846002)(91956017)(229853002)(5660300002)(256004)(86362001)(2501003)(8936002)(6916009)(446003)(1361003)(11346002)(66476007)(66616009)(71200400001)(30864003)(99286004)(66446008)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5078; H:DB7PR07MB5736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: olh7pqaOsAyn3LM4uxszwJ5mHBNOC+ACJ1acp/CGKBxO13OuaCopGAvlNsPGfPJVjmDju/ld7zyAZdy0Nhv41gDQpcenV4a/9yoPUzQPKFMMu+53V2/luXYgIFx9zqb9tKP6kgOK9ji1dhfTcebi/PxUdEoxsv/k5Atzs6iU9YWO5QcNPa/SCjSUybUJBn9hrqroldnwLRoKirC/zd6ZVWikaAv9TiijY7ZoUdeMaLpWL7qcmIAEwmrAZZaeVrgFUm0BnJzHmVDWZy2fPc6DMS+8wPMclTb7lY4ldEpdgJWQc/ud89qbN5JdAV64+mDABUDYPZ3gkOhzD6gRW6QMSFE2aXbY8jd8xr3r03h+kBu2EXnFvbh2+wdQvK3mtxacbmfFEuFbvsoCDkjMXg1lS/NWMJAUGZDDRsJzqt4++N4=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-BSDuZmCvAkt4A0WX0iIt"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 28a870cc-2bee-4816-2e8b-08d7425d500d
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2019 08:41:23.7168 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: aLphdeLgakbRBU8gG7oZd7K+erOieReq8PIPve9am+g0jjsnlK1goY2QxL5ZLBEnSHKIZYHs75ErL6e+qZlO27Vnz3xM2QqKK+3raWXOwsI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5078
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/DRlH6TpH-NtnD8oqcsrXrAj660k>
Subject: Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and 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: Thu, 26 Sep 2019 08:41:36 -0000

Hi Greg,

This clarifies it sufficiently. I have cleared my discuss. 

Thanks

Magnus

On Tue, 2019-09-24 at 13:39 -0700, Greg Mirsky wrote:
> Hi Magnus,
> a new section, Operational Considerations, has been added to address Barry's
> DISCUSS:
> 
> 5.  Operational Considerations
> 
>    STAMP is intended to be used on production networks to enable the
>    operator to assess service level agreements based on packet delay,
>    delay variation, and loss.  When using STAMP over the Internet,
>    especially when STAMP test packets are transmitted with the
>    destination UDP port number from the User Ports range, the possible
>    impact of the STAMP test packets MUST be thoroughly analyzed.  The
>    use of STAMP for each case MUST be agreed by users of nodes hosting
>    the Session-Sender and Session-Reflector before starting the STAMP
>    test session.
> 
>    Also, the use of the well-known port number as the destination UDP
>    port number in STAMP test packets transmitted by a Session-Sender
>    would not impede the ability to measure performance in an Equal Cost
>    Multipath environment and analysis in Section 5.3 [RFC8545] fully
>    applies to STAMP.
> 
> Would it address your concern?
> 
> The new version of the draft has been published. It includes all the updates
> we've discussed.
> 
> Much appreciate your consideration of the new version, comments, and
> questions.
> 
> Kind regards,
> Greg
> 
> On Mon, Sep 16, 2019 at 8:29 AM Magnus Westerlund <
> magnus.westerlund@ericsson.com>; wrote:
> > On Wed, 2019-09-11 at 11:33 -0700, Greg Mirsky wrote:
> > > Hi Magnus,
> > > thank you for clarifications and further detailing your comments,
> > > questions. Please find my answers and notes below in-lined under the
> > > GIM2>> tag.
> > > 
> > > Regards,
> > > Greg
> > > 
> > > On Wed, Sep 11, 2019 at 12:53 AM Magnus Westerlund <
> > > magnus.westerlund@ericsson.com>; wrote:
> > > > Hi Greg,
> > > > 
> > > > Thanks for the reply. See inline for my comments and response. 
> > > > 
> > > > 
> > > > On Tue, 2019-09-10 at 12:43 -0700, Greg Mirsky wrote:
> > > > > Hi Magnus,
> > > > > thank you for the review and thoughtful, pointed questions.
> > > > Please
> > > > > find my answers in-line under GIM>> tag.
> > > > > 
> > > > > Regards,
> > > > > Greg
> > > > > 
> > > > > On Wed, Sep 4, 2019 at 3:54 PM Magnus Westerlund via Datatracker
> > > > <
> > > > > noreply@ietf.org>; wrote:
> > > > > > Magnus Westerlund 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:
> > > > > > -------------------------------------------------------------
> > > > ----
> > > > > > -----
> > > > > > 
> > > > > > Two very much discussing discusses. However, I would really
> > > > like to
> > > > > > hear the
> > > > > > answer to these concerns before clearing.
> > > > > > 
> > > > > > 1. Section 4.3: Is the HMAC field size of 16 bytes hard coded?
> > > > If
> > > > > > there ever
> > > > > > would exist a need to deploy another integrity solution, even
> > > > if
> > > > > > the actual
> > > > > > algorithm used to construct the tag can be agreed by the
> > > > > > management, there
> > > > > > appear to exist a hard look in to use 16-byte tags. Have this
> > > > issue
> > > > > > been
> > > > > > considered?
> > > > > 
> > > > > GIM>> Indeed, this specification defines the use of only one
> > > > > algorithm and only 16 bytes-long HMAC field. Your question
> > > > prompted
> > > > > the discussion among authors and we believe that in a future
> > > > > specification it would be feasible to extend supporting a number
> > > > of
> > > > > algorithms and different lengths of HMAC field both being defined
> > > > > through extension to STAMP YANG data model.
> > > > 
> > > > So if I understand this (taking a discussion with Mirja about
> > > > keeping
> > > > things as simple as possible) the solution is to basically is when
> > > > need
> > > > arises define a new STAMP version, and then use YANG to coordinate
> > > > which version is used for the measurement. If that is a correct re-
> > > > interpretation of your response then I am fine with it. 
> > > 
> > > GIM2>> The direction from the WG was to keep the base specification
> > > as simple  as possible (and that was the reason to split TLV
> > > extensions into a separate document). 
> > 
> > Yes, understood. 
> > 
> > > > > >         2. Section 6:
> > > > > >         The possible impact of the
> > > > > >    STAMP test packets on the network MUST be thoroughly
> > > > analyzed,
> > > > > > and
> > > > > >    the use of STAMP for each case MUST be agreed by all users
> > > > on
> > > > > > the
> > > > > >    network before starting the STAMP test session.
> > > > > > 
> > > > > >         I assume some potential issues are know, shouldn't they
> > > > > > really be
> > > > > >         listed here in the security consideration to further
> > > > > > motivate why the
> > > > > >         analysis needs to happen.
> > > > > 
> > > > > GIM>> This is in reference to using numbers from the User range
> > > > as
> > > > > the destination port number. Would adding the reference to the
> > > > case
> > > > > of using the port numbers from the User range address your
> > > > concern?
> > > > > Or rather refer to Section 4, as it includes more discussion
> > > > (see 
> > > > > below)? 
> > > > 
> > > > Okay, I don't really care where the discussion happens. But I don't
> > > > find any real discussion and listing of the concerns with using
> > > > user or
> > > > dynamic ports for STAMP Sessions? With the formulation you use, I
> > > > would
> > > > expect at least some list of potential concerns that needs to be
> > > > evaluated in the context of the particular usage of STAMP. 
> > > 
> > > GIM2>> Per Berry's suggestion, I'm adding a new section, Operational
> > > Considerations, to list possible scenarios and possible issues with
> > > using destination ports from the User range and from the Dynamic
> > > range. I hope to finish it in a couple days. Will share on this
> > > discussion thread promptly. 
> > 
> > Great!
> > 
> > Looking forward to review it when written. 
> > 
> > > > > > 
> > > > > > -------------------------------------------------------------
> > > > ----
> > > > > > -----
> > > > > > COMMENT:
> > > > > > -------------------------------------------------------------
> > > > ----
> > > > > > -----
> > > > > > 
> > > > > >         1. Section 4:
> > > > > >         Before using numbers from the User Ports range, the
> > > > > > possible impact
> > > > > >    on the network MUST be carefully studied and agreed by all
> > > > users
> > > > > > of
> > > > > >    the network.
> > > > > > 
> > > > > >         Is the above sentence missing to list an important
> > > > > > assumption? Is the
> > > > > >         assumption that by using the registred destination port
> > > > an
> > > > > > operator
> > > > > >         that sees to much STAMP traffic can simply filter it
> > > > out
> > > > > > and that way
> > > > > >         deal with the traffic, something which is not possible
> > > > when
> > > > > > using an
> > > > > >         locally decided port? If that is the case, this
> > > > assumption
> > > > > > should
> > > > > >         probably be noted.
> > > > > 
> > > > > GIM>> That is a very good point but our primary motivation for
> > > > this
> > > > > cautionary note (or strong warning) was that by allowing STAMP to
> > > > use
> > > > > port numbers from the User range, ports that may be already
> > > > assigned
> > > > > to protocols, creates a DDOS attack vector. As for the filtering
> > > > > STAMP traffic out, I think that even if the destination port is
> > > > one
> > > > > from the Dynamic range, for a relatively long test session it can
> > > > be
> > > > > filtered out.
> > > > 
> > > > So if that is the only? concern then write it out. I would expect
> > > > that
> > > > the higher layer management protocol that creates a measurement
> > > > session
> > > > to actually ensure that the STAMP endpoint actually have the port
> > > > numbers they attempt to use. Isn't that a reasonable requirement to
> > > > put
> > > > on the solution? 
> > > 
> > > GIM2>> Agree with your suggestion. Will put in the new section. If
> > > STAMP is managed by a centralized system, whether it is proprietary
> > > OSS/BSS or an orchestrator that uses YANG data models, the system
> > > will be able to coordinate selection of port numbers on the Session-
> > > Sender and Session-Reflector. But some systems may use EMS or CLI and
> > > that is where human coordination may be required. 
> > 
> > 
> > Good, then likely this is resolved when your text is ready. 
> > 
> > > > My thinking with the filtering out concern was that in cases where
> > > > one
> > > > runs STAMP measurement sessions, if the measurement interfer with
> > > > critical traffic an action for an on-path node that can actually
> > > > identify the STAMP traffic was to filer it out. And that may be
> > > > considered trivial when the well known port is used, but if a user
> > > > or
> > > > dynamic port is used, then that requries a managment system to
> > > > provide
> > > > the on-path node with the necessary information, i.e. 3/5 tuple for
> > > > the
> > > > STAMP flows. 
> > > 
> > > GIM2>> I think that a transit node can identify a flow as the STAMP
> > > flow only if the destination port is the STAMP default UDP
> > > destination port number, 862. In case a STAMP session has the
> > > destination port number as one of port numbers from the User range,
> > > IP/UDP encapsulation of STAMP packets would be indistinguishable from
> > > packets originated by the application that is assigned that port
> > > number. Thus, filtering out on only destination port number may
> > > negatively affect service, legitimate service. Because of that, I
> > > think that filtering will have to use more information. On the other
> > > hand, if the test flow does not exceed agreed rate, then any
> > > filtering test packets out, in my opinion, is counter-productive, as
> > > it hides some issues in the networks rather than letting the OAM
> > > tools to expose them, localize, and characterize.
> > 
> > Ok. This was primarily to understand if this was in scope or not. But
> > it sounds like this is not really in scope for how to manage it. 
> > 
> > > > 
> > > > > >         2. Section 3 and 4, and 4.1.1: What is a STAMP Session?
> > > > Is
> > > > > > that a
> > > > > >         measurment session between one specific and sender and
> > > > a
> > > > > > specific
> > > > > >         reflector for a time duration?  The defenition of the
> > > > > > session do matter
> > > > > >         if one intended to enable a single sender to use
> > > > multiple
> > > > > > reflectors,
> > > > > >         and if that can be a single session or always multiple
> > > > > > indepdendent
> > > > > >         ones. Would appreciate a definition what a session is.
> > > > If
> > > > > > it is
> > > > > >         possible to send STAMP traffic using a multicast or
> > > > > > broadcast address
> > > > > >         should be made explicit.
> > > > > 
> > > > > GIM>> Your interpretation is correct, STAMP session is implicitly
> > > > > defined as p2p. And that is what reflected in the STAMP YANG
> > > > model.
> > > > > Would the following text make it clearer:
> > > > > NEW TEXT:
> > > > >    In this document, a measurement session also referred to as
> > > > >    STAMP session, is the session between one specific Session-
> > > > Sender
> > > > > and
> > > > >    one particular Session-Reflector for a time duration.
> > > > 
> > > > Yes, please include that definition. Question would it be clearer
> > > > to
> > > > replace ".. is the session betweeen .." with ".. is the bi-
> > > > directional
> > > > packet flows between .."? 
> > > 
> > > GIM2>> I agree, defining a session as a session makes is somewhat
> > > repetitive. Thank you. 
> > > Below is the updated text:
> > >    In this document, a measurement session also referred to as
> > >    STAMP session, is the bi-directional packet flow between one
> > > specific
> > >    Session-Sender and one particular Session-Reflector for a time
> > >    duration.
> > 
> > Looks good to me. 
> > 
> > > > 
> > > > > >         3.  Section 4.1.1.:
> > > > > >         Timestamp is eight octets long field.  STAMP node MUST
> > > > > > support
> > > > > >       Network Time Protocol (NTP) version 4 64-bit timestamp
> > > > format
> > > > > >       [RFC5905], the format used in [RFC5357].  STAMP node MAY
> > > > > > support
> > > > > >       IEEE 1588v2 Precision Time Protocol truncated 64-bit
> > > > > > timestamp
> > > > > >       format [IEEE.1588.2008], the format used in [RFC8186].
> > > > > > 
> > > > > >         Is the clock source here something that may be relevant
> > > > or
> > > > > > simply
> > > > > >         information the management functions should capture. I
> > > > > > think there is a
> > > > > >         similar issue to that of RTP faced when it comes to
> > > > > > understand what the
> > > > > >         timestamp actually represent and thus be used
> > > > correctly.
> > > > > > RTP clock
> > > > > >         source specification is RFC 7273
> > > > > >         (https://datatracker.ietf.org/doc/rfc7273/)
> > > > > 
> > > > > GIM>> NTP and PTP encodings have a different interpretation of
> > > > the
> > > > > Fraction field of the Timestamp field. In my experience, PTP
> > > > format
> > > > > is native for the data plane, while NTP is more used at the
> > > > control
> > > > > plane. Original extension to TWAMP has been described in RFC
> > > > 8186.
> > > > 
> > > > I think you missunderstood. When I talk about clock source, I am
> > > > actually referring to identifying the particular clock that the
> > > > node
> > > > use to derive the included timestamp from. 
> > > > 
> > > > And likely this is a moot point in this document where the clock
> > > > source
> > > > information belongs in the management layer, e.g. in the YANG data
> > > > model. 
> > > 
> > > GIM2>> Timestamp Information TLV (draft-ietf-ippm-stamp-option-tlv)
> > > provides information about the clock synchronization protocol and the
> > > method by wich the timestamp has been acquired at a Session-
> > > Reflector. We may extend it to list the name/locatior of the master
> > > clock.
> > 
> > Ok. sounds reasonable. 
> > 
> > > > 
> > > > > >         4. Section 4.1:
> > > > > >            Because STAMP supports symmetrical test packets,
> > > > STAMP
> > > > > > Session-Sender
> > > > > >    packet has a minimum size of 44 octets in unauthenticated
> > > > mode,
> > > > > > see
> > > > > >    Figure 2, and 112 octets in the authenticated mode, see
> > > > Figure
> > > > > > 4.
> > > > > > 
> > > > > >         The above text implies some potential for UDP payload
> > > > size
> > > > > > variability
> > > > > >         for the STAMP packets. However, the actual definition
> > > > > > appear to have
> > > > > >         fixed sizes. Can you please clarify if I have missed
> > > > > > something that
> > > > > >         enables the STAMP packet to have variable size?
> > > > > 
> > > > > GIM>> I think that the text can be improved by characterizing the
> > > > > listed sizes as "base". The variable length of a test packet in
> > > > STAMP
> > > > > is supported by using Extra Padding TLV defined in draft-ietf-
> > > > ippm-
> > > > > stamp-option-tlv. Below is the proposed update:
> > > > > OLD TEXT:
> > > > >    Because STAMP supports symmetrical test packets, STAMP
> > > > Session-
> > > > > Sender
> > > > >    packet has a minimum size of 44 octets in unauthenticated
> > > > mode,
> > > > > see
> > > > >    Figure 2, and 112 octets in the authenticated mode, see Figure
> > > > 4.
> > > > > NEW TEXT:
> > > > >    STAMP supports symmetrical test packets.  The base STAMP
> > > > Session-
> > > > >    Sender packet has a minimum size of 44 octets in
> > > > unauthenticated
> > > > >    mode, see Figure 2, and 112 octets in the authenticated mode,
> > > > see
> > > > >    Figure 4.  The variable length of a test packet in STAMP is
> > > > > supported
> > > > >    by using Extra Padding TLV defined in
> > > > >    [I-D.ietf-ippm-stamp-option-tlv].
> > > > > 
> > > > > With the new reference, should I-D.ietf-ippm-stamp-option-tlv be
> > > > > moved to the Normative References list or may remain in the
> > > > > Informative list?
> > > > 
> > > > From my perspective, the fact that optional TLV may occur following
> > > > the
> > > > base headers appears quite important. Here comes a question of
> > > > intention form the WG. Is it intended that one can have STAMP
> > > > endpoints
> > > > that do not even support receiving packets larger than the base? 
> > > > In other words there will be two main versions already now, one
> > > > that
> > > > supports some TLV and can at least handle the TLV skip forward and
> > > > ignore the content and one that will throw a fit over the TLVs? If
> > > > that
> > > > is not the intention I think the fact that TLV's may occur should
> > > > be
> > > > moved into this specification and have it as a normative reference.
> > > 
> > > GIM2>> Will move the reference to the Normative section. With TLV
> > > being normative, I'd expect that the intelligent implementation of
> > > this draft, of the base STAMP specification, will accept any valid
> > > STAMP packet though not process extensions. But the base STAMP
> > > Session-Reflector will return the base reflected packet.  
> > 
> > I think that is very reasonable approach. Are you close to complete the
> > stamp-option-tlv document, or will the missref cause any issue? 
> > 
> > > > I guess the answer is that you have backwards comaptibility reasons
> > > > for
> > > > not allowing TLVs at all in some sessions, or? 
> > > 
> > > GIM2>> Yes, that and the principle "keep it simple". 
> > 
> > Thanks,
> > 
> > To me it looks like with some text changes all my issues are addressed.
> > 
> > Cheers
> > 
> > Magnus Westerlund 
> > 
> > 
> > ----------------------------------------------------------------------
> > Network Architecture & Protocols, Ericsson Research
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  +46 10 7148287
> > Torshamnsgatan 23           | Mobile +46 73 0949079
> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> > ----------------------------------------------------------------------
> > 
> > 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------