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 ----------------------------------------------------------------------
- [ippm] Magnus Westerlund's Discuss on draft-ietf-… Magnus Westerlund via Datatracker
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Greg Mirsky
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Henrik Nydell
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Henrik Nydell
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Greg Mirsky
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Greg Mirsky
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Greg Mirsky
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Greg Mirsky