Re: [ippm] AD review of draft-ietf-ippm-stamp

"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Fri, 09 August 2019 17:03 UTC

Return-Path: <rgandhi@cisco.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 CA5A2120020; Fri, 9 Aug 2019 10:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=HaHu0anG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rz50aJcN
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 a2lED2eBC8tV; Fri, 9 Aug 2019 10:03:32 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9992412002F; Fri, 9 Aug 2019 10:03:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=189191; q=dns/txt; s=iport; t=1565370211; x=1566579811; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hD1ZR7hX2qZ5k6HKtwxYaFyAmZ5v0PLMySdBLA50HVE=; b=HaHu0anGXZ6hCxBkgQCY2NrNUowTvJQip/bQ2zOkelnv3bXDGJYV3IOk WCdF8qwjcJDpLg+Xu5Yf4Q+7qdr7+MSXGF/T/ZMyWKWWTDgqNG7DTqO3q ikZenWFlL1vIeUTgaFREbCZ9zppPXSDldOdHrlFMW6VgWptz1ZRRqoPeZ g=;
IronPort-PHdr: =?us-ascii?q?9a23=3Af7dqMxN9v4NyHFcIffMl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhI/fsYyw7NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAQD0pk1d/5RdJa1jAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWeBFi8kBScDbVUgBAsqg15Ag0cDiw9MgWoliVuLIoJ?= =?us-ascii?q?kgUKBEANQBAkBAQEMAQEYAQkHBAIBAYQ/AheCSiM4EwEEAQEEAQEEAQpthSc?= =?us-ascii?q?MCQiFOQEBAQECAQEBCgYIAQgEBhMBASwLAQQLAgEGAgcKAwEBAQEgAQYDAgI?= =?us-ascii?q?CHwYLFAkIAgQOBSKDAAGBHU0DDg8BAgyPbJBhAoE4iGByfzOCegEBBYEzAYN?= =?us-ascii?q?hDQuCFAmBHReFUoJ0ggCBHheBQD+BEScME4FOfj6CGkcBAQEBAReBFAELAQY?= =?us-ascii?q?BCR0HCQkBCwEJAgYJgkQXG4ImiiSBcgcBGAEDgQyBGTGFDCOIXo0/LUAJAoI?= =?us-ascii?q?dhVmBCYFCh0BSgUKCNxuCMC8+hkKEFIYrhBqMLFaCBYVABWOBeI4pAgQCBAU?= =?us-ascii?q?CDgEBBYFnIWdxcBU7KgGCQQmBQVQkCQMXgQQBAoJIgmSCMIU/cgEBEQKBFIs?= =?us-ascii?q?UAQYIF4IsAQE?=
X-IronPort-AV: E=Sophos;i="5.64,366,1559520000"; d="scan'208,217";a="303477572"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Aug 2019 17:03:29 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x79H3TGH028669 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Aug 2019 17:03:29 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 9 Aug 2019 12:03:28 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 9 Aug 2019 12:03:28 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 9 Aug 2019 12:03:28 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I4gnurdtwjz1qIbzfpqa89Cgiccel5KdOLcadMGyxT1SzQ3oqsrkZBcvXdQH/PDDJIsqGK+CVPKp4Jt88USg+jqbgyPCOgBiIw6hdjAVzDifHez1W1riPi3hGpQzlbPkocuZ9NyJCT2hui6edpvBl5M+u2msNihgFXiztu9mY2vvXuwmWdZXXnM8luuwvG0RIAwAzhCs6Y0Yns15PxAlaZgbM7497wJCeLIwx+kv85V6n7J6MNBpPPo9bJa6ksYlUtKtxEPaL23OaL0uXdkJyzLqraQqLjrIuYy+gvMy2Txry8DaTaxWKt9pmuZwqxpbQp9GdytCfm+QCBzcXHon+Q==
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=hD1ZR7hX2qZ5k6HKtwxYaFyAmZ5v0PLMySdBLA50HVE=; b=URN/YlmpbomWMmxNZBx33fbQqPVqRWOwgAdHwbEij4iQ8WGzwVmJnjsRnj4vN4bVX7s94TDGjQAN6imZqs0U0slDH4ZKJtICOW0sP/Q0NWDvs/oJne691jl9z/kzuWrxMJ6tyHvGCcmnFouXWyXb65JHIw9okcWdxfLpa9DVFxtTe9fUFcnZUN0cAvPXOfPOww01v+oMJU/pntM6QCec1PFJBJeZET27scBRSTMTTYmOOdxT5TxG7bdRaUh/0T4DBpv3Fsnn5S0PQ5zHLvmNjdqSvOH6xEQAEATPzd84nQqhlgM5ECj4n035h7EWo+/CItc0rf1h3hWsJ31oE5LHXg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hD1ZR7hX2qZ5k6HKtwxYaFyAmZ5v0PLMySdBLA50HVE=; b=rz50aJcNZJi4DcJQhse0d0l01uE/64YfC7/ddsf/G/uk+p2DKUVL0ckAhyQEIpSDMsjRDpqjuViQsr8979sCtudod0JpdO0xXY6MgoVnv6Qzp8IL7bzp6W7nzMc8tiYxIdPUWCCwp8aq6KoDimiQZjwL4Bo2JkyvzTPcCJO+07o=
Received: from SN6PR11MB3278.namprd11.prod.outlook.com (52.135.109.11) by SN6PR11MB2606.namprd11.prod.outlook.com (52.135.91.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.18; Fri, 9 Aug 2019 17:03:26 +0000
Received: from SN6PR11MB3278.namprd11.prod.outlook.com ([fe80::d97f:e2dd:1ea6:303f]) by SN6PR11MB3278.namprd11.prod.outlook.com ([fe80::d97f:e2dd:1ea6:303f%5]) with mapi id 15.20.2157.020; Fri, 9 Aug 2019 17:03:26 +0000
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Henrik Nydell <hnydell@accedian.com>, "MORTON, ALFRED C (AL)" <acm@research.att.com>, Rakesh Gandhi <rgandhi.ietf@gmail.com>, "draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>, "IPPM Chairs" <ippm-chairs@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, "IETF IPPM WG" <ippm@ietf.org>
Thread-Topic: [ippm] AD review of draft-ietf-ippm-stamp
Thread-Index: AQHVNZ0+7z5WSZ7weEqWcphMhijoKabA4NeAgAAWDoCAAD6nAIAAJQyAgADuSwCAJfN4gIAADqkAgAGE5ICABJNAgIAABkeAgAAuxACAAPFGgIAAZCeAgAAaAgCAAQlCAIAAE6+AgAACD4CAAHHQAIABLEoA///ejYCAAIHEAP//1V8A
Date: Fri, 9 Aug 2019 17:03:25 +0000
Message-ID: <85295835-DB1C-4DF0-B56F-EB2C709DE881@cisco.com>
References: <B617B303-6EBE-4E3B-AE5C-1438FF1C5D7F@kuehlewind.net> <CA+RyBmVEmKQu=LGp9eVT+x5e01LCSk_A4tQD=RE8Ett-R35BVg@mail.gmail.com> <11938018-8A65-483B-8176-A6E1C2A265A3@kuehlewind.net> <CA+RyBmX=Jx2yXrMXu4Y2VKX36iKphymb1Hkyfy0XhPGFmsUGzQ@mail.gmail.com> <B8047CA0-2F5E-48F8-9BE4-3FA41D742F12@kuehlewind.net> <CA+RyBmXPCe7TZQqPgsKsVnifZDG8O8wGafDn-nzYfGpx2OiaXQ@mail.gmail.com> <F167C330-76F4-48FC-B720-415CA190239C@broadcom.com> <CA+RyBmVtfXcwqu1RH-1JXnhpCZcbGgm30ubKGctUPnLNJCgVZQ@mail.gmail.com> <CAMZsk6f=x1j_fXAoqZ874y0nw7Y1wP0OeS9eFuToSBQfrqkJLQ@mail.gmail.com> <CA+RyBmVWZ3utikyBRm4TDhRDuMd3cZ9-otbuX=Mbg0ioAGjwHg@mail.gmail.com> <CAMZsk6eJf2xjsRJwnBtd5KFHbwO4KX3gEjs_Nv1Dhf39ZWjegA@mail.gmail.com> <CA+RyBmXHTjpbWv4FGpOsfL94Zip3MsVvESyka5M8PrmNKFB=YQ@mail.gmail.com> <CAMZsk6dGneYXFr3Xk_DuQnbwa=-ObV_SNdGOSj1Z203wW-PzTg@mail.gmail.com> <CALhTbppn9jpCLaSLR3QSN=yA0uDyXXMCQ+Rm4qFrR5OrjS31Dw@mail.gmail.com> <CAMZsk6eidFR-doLCvMim6HJZ142q_Q0V7XmiLP6Ki5_jmNvUxw@mail.gmail.com> <CALhTbppD+GSRf2U_eSPfm4RkTC1-vm-+rfuVJUesHmFiPxmnGw@mail.gmail.com> <4D7F4AD313D3FC43A053B309F97543CFA0ADA7AE@njmtexg4.research.att.com> <CAMZsk6fODTiLctxJArHyVz9AvyKfrUwefPw0GPg+T3uhRFv6dg@mail.gmail.com> <CALhTbpqzriiZ8RqtFWR0+tjYUwj6A4AV=0d=w6_cMBHFHrF6Fw@mail.gmail.com> <4D7F4AD313D3FC43A053B309F97543CFA0ADAA75@njmtexg4.research.att.com> <9AEB8751-44B2-41C0-84D8-39B69F7D55BF@cisco.com> <CA+RyBmXteNOH6nfoeF5cH8v2U7mOQPFxX6wHMqKSSPugCKZGrQ@mail.gmail.com> <CALhTbprAKvHTO4Osy_HcX05XXeJi+Muz1s=eqwVRoTJWPuU4xQ@mail.gmail.com> <F9DC42CF-0145-45CC-ADCB-BAFBC1B6C99C@cisco.com> <CA+RyBmU+7W=BqcWow1tUeQU2G5iQ7igKg+qgWGFXBqRTxqSM3Q@mail.gmail.com>
In-Reply-To: <CA+RyBmU+7W=BqcWow1tUeQU2G5iQ7igKg+qgWGFXBqRTxqSM3Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.c.190715
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rgandhi@cisco.com;
x-originating-ip: [2001:420:c0c4:1006::8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 100e2c01-994f-4a16-4a6c-08d71ceb7e85
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR11MB2606;
x-ms-traffictypediagnostic: SN6PR11MB2606:
x-ms-exchange-purlcount: 11
x-microsoft-antispam-prvs: <SN6PR11MB2606E63CCD56298023ED515DBFD60@SN6PR11MB2606.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 01244308DF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(346002)(396003)(376002)(54094003)(53754006)(51914003)(51444003)(40764003)(199004)(189003)(76116006)(54896002)(30864003)(6306002)(8676002)(7736002)(6512007)(5660300002)(6436002)(2906002)(733005)(99286004)(316002)(46003)(446003)(58126008)(486006)(81166006)(81156014)(6916009)(476003)(11346002)(66574012)(91956017)(2616005)(5024004)(14444005)(790700001)(6116002)(64756008)(6486002)(561944003)(66946007)(66476007)(66556008)(66446008)(86362001)(8936002)(256004)(229853002)(54906003)(6506007)(33656002)(5070765005)(478600001)(76176011)(53546011)(236005)(4326008)(53946003)(14454004)(1411001)(53386004)(25786009)(966005)(606006)(6246003)(36756003)(186003)(9326002)(53936002)(53376002)(71200400001)(102836004)(71190400001)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2606; H:SN6PR11MB3278.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: B8YTQIhSCXGFNIwzLe9NuzlnsqPL3IZhtMkc1nhqWQwiJzBtUjUvh4e0iuhJ7BLFyddTcF/SLtGZQfLKRE+8AYDZE22OqdNiofhs0nkKXOozNK4OZr8ortRykA0beWH+j1sLiQCrqeJRK/8CjUsWDTZSsRbpkA9xnX0Y2VpxrjirQYEDy7FiDIvhYtscd/m6jmlcUMy7lisgVtV+IQDwlEYFSrG2VRK4CCC7Rhg7xZV/5xmNyN1G2rioRy4J/EJWZy9mxwb6fVGnenGjLrs/oY7ip/eTco2tuTDGxW0xsIZHK1U7nvMNAWjnV/r6QlzO8lSn3IzzLdvaUoff568u0hf0zf/THCCCwB3q5Q5JU1NvJr+0HuxkKVkYNjs9zATlOxWmIyOgmDTUNiqCOmSg7D8MQ0Po6LTHHYeVuYzxSs0=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_85295835DB1C4DF0B56FEB2C709DE881ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 100e2c01-994f-4a16-4a6c-08d71ceb7e85
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2019 17:03:26.0252 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Y8cWMHadQM+Kduf9RAlp90oFIzBpZ9RnxSV/ejTZTfvD+RI56zmNIVeOEBxSwTgVnhnaM6a1rrcvO4U1Dd1BGg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2606
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ktlnHBNTzD0WCNUxt8hlanfk9EM>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp
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, 09 Aug 2019 17:03:40 -0000

Hi Greg,
Thanks for your comments. As there is an alternate “MAY” option, IMO, having “MUST” creates unnecessary restriction, as some implementation may choose to only support that range because of “MUST”.

Thanks,
Rakesh


From: Greg Mirsky <gregimirsky@gmail.com>
Date: Friday, August 9, 2019 at 11:36 AM
To: "=SMTP:rgandhi@cisco. com" <rgandhi@cisco.com>
Cc: Henrik Nydell <hnydell@accedian.com>om>, "MORTON, ALFRED C (AL)" <acm@research.att.com>om>, Rakesh Gandhi <rgandhi.ietf@gmail.com>om>, "draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>rg>, IPPM Chairs <ippm-chairs@ietf.org>rg>, Mirja Kuehlewind <ietf@kuehlewind.net>et>, IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh and Henrik,
much appreciate your ideas. I agree with the new text that includes "MAY" as expressed by Rakesh. I think that Henrik's proposal to maintain "MUST" for the Dynamic range is accurate and will ensure interoperability, including with the existing implementations of TWAMP Light.
What do you think?

Regards,
Greg

On Fri, Aug 9, 2019 at 4:51 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com<mailto:rgandhi@cisco.com>> wrote:
Thanks Henrik and Greg for the text proposals.

May be we can change the text as follows to allow the flexibility.

"Thus STAMP Session-Sender SHOULD be able to send test packets to destination UDP port number from the Dynamic and/or Private Ports range 49152-65535 as well as the registered TWAMP port 862. Implementations MAY allow using UDP port number outside the Private Ports range when the test management system finds a port number that both devices can use."

Thanks,
Rakesh


From: Henrik Nydell <hnydell@accedian.com<mailto:hnydell@accedian.com>>
Date: Friday, August 9, 2019 at 5:51 AM
To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: "=SMTP:rgandhi@cisco. com" <rgandhi@cisco.com<mailto:rgandhi@cisco.com>>, "MORTON, ALFRED C (AL)" <acm@research.att.com<mailto:acm@research.att.com>>, Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>>, "draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>" <draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>>, IPPM Chairs <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>, Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>>, IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp


Hi Greg, to make the wording even clearer you could change to

"Thus STAMP Session-Sender MUST as a minimum be able to send test
   packets to destination UDP port number from the Dynamic and/or
   Private Ports range 49152-65535 as well as the registered TWAMP port 862. Implementations MAY allow using ports outside the IANA assigned Private Ports range."



On Thu, Aug 8, 2019 at 5:56 PM Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Rakesh and Henrik,
thank you for a very informative discussion. Do you think the wording in Section 4.4 of the STAMP specification needs modification:
   Thus STAMP Session-Sender MUST be able to send test
   packets to destination UDP port number from the Dynamic and/or
   Private Ports range 49152-65535, test management system should find a
   port number that both devices can use.
...
   In the latter scenario, the test management system SHOULD set STAMP
   Session-Reflector to use UDP port number from the Dynamic and/or
   Private Ports range.
I think that the text is not restrictive and can stay. What do you think?
We can review and update STAMP YANG model in a separate thread.

Regards,
Greg



On Thu, Aug 8, 2019 at 6:09 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com<mailto:rgandhi@cisco.com>> wrote:
Thanks Henrik and Al for your feedbacks and discussions.

I have few comments on the TWAMP yang model draft-ietf-ippm-twamp-yang:


1)      Reflector side does not have autoallocate option. Only sender side has it and both allow dynamic range ports only (and 862).
      leaf reflector-udp-port {
               type inet:port-number {
                 range "862 | 49152..65535";
               }

     leaf sender-udp-port {
               type union {
                 type dynamic-port-number;
                 type enumeration {
                   enum autoallocate {
                     description
                       "Indicates that the Contol-Client will
                        auto-allocate the TWAMP-Test (UDP) port number
                        from the dynamic port range.";
                   }


2)      Autoallocate is still from the dynamic port range only.

3)      Even with the dynamic UDP port, the backend and controller still need to  handle the case where the UDP port has been allocated to something else on that node, as it is dynamic.

4)      Well known ports can be handled by the backend similarly if there was an error in provisioning.

5)      This range issue seems to get propagated to the new work like draft-ietf-ippm-stamp.

Other than the VOIP example below, there is another example of the similar case on Page 31 in https://www.ietf.org/id/draft-ietf-tram-turnbis-29.txt as pointed out by Mirja in another thread.

At this point, two vendors are saying the UDP port range for TWAMP is an issue for them. As the existing implementations do not have such range limit, operators may be using an UDP port outside this range, this means moving to the TWAMP Yang model could be troublesome.

Thanks,
Rakesh


From: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> on behalf of "MORTON, ALFRED C (AL)" <acm@research.att.com<mailto:acm@research.att.com>>
Date: Thursday, August 8, 2019 at 5:02 AM
To: Henrik Nydell <hnydell@accedian.com<mailto:hnydell@accedian.com>>, Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>>
Cc: "draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>" <draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>>, IPPM Chairs <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>, Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>>, IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh and Henrik,

working from the VoIP testing example below, it seems as though
“ability to test on a specific port in the User range,
with prior agreement of users on the tested network”
should have been asked for-as a feature during
YANG model development?

the authors used the Dynamic Range to avoid *accidentally*
stepping on IANA-allocated User ports during auto-allocation:

             leaf sender-udp-port {
               type union {
                 type dynamic-port-number;
                 type enumeration {
                   enum autoallocate {
                     description
                       "Indicates that the Contol-Client will
                        auto-allocate the TWAMP-Test (UDP) port number
                        from the dynamic port range.";
                   }
with RFC 6335:
6.  Port Number Ranges

   TCP, UDP, UDP-Lite, SCTP, and DCCP use 16-bit namespaces for their
   port number registries.  The port registries for all of these
   transport protocols are subdivided into three ranges of numbers
   [RFC1340], and Section 8.1.2 describes the IANA procedures for each
   range in detail:

   o  the System Ports, also known as the Well Known Ports, from 0-1023
      (assigned by IANA)

   o  the User Ports, also known as the Registered Ports, from 1024-
      49151 (assigned by IANA)

providing our over-riding guidance.

If we agree that the sort of testing you describe means
adding a new feature to the model, then let’s give some thought
to how that might best be done.

Al

From: Henrik Nydell [mailto:hnydell@accedian.com<mailto:hnydell@accedian.com>]
Sent: Thursday, August 8, 2019 3:51 AM
To: Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>>
Cc: MORTON, ALFRED C (AL) <acm@research.att.com<mailto:acm@research.att.com>>; IPPM Chairs <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>; Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>>; draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Agree Rakesh.
There is value in being able to for example as close as possibly mimic for example a VoIP flow on a network path, using typical UDP ports (5060 for example), and a typical VoIP IPG (20ms) and proper payload length to make the TWAMP flows be treated in the same way as the real RTP traffic by the network elements (firewalls, NAT or other port-sensitive devices).


On Wed, Aug 7, 2019 at 6:02 PM Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>> wrote:

Thanks Al and Henrik.
If there is no specific requirement to add a limit on the UDP port range, it would be good to not have it in the STAMP draft as well as in the TWAMP Yang model. Let implementations decide what ports they can support (keeping in mind the assigned ones) and let operators decide what port they like to provision.

Thanks,
Rakesh


On Wed, Aug 7, 2019 at 10:34 AM MORTON, ALFRED C (AL) <acm@research.att.com<mailto:acm@research.att.com>> wrote:

From: ippm [mailto:ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>] On Behalf Of Henrik Nydell
Sent: Wednesday, August 7, 2019 4:30 AM
To: Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>>
Cc: IPPM Chairs <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>; Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>>; draft-ietf-ippm-stamp@ietf.org<mailto:draft-ietf-ippm-stamp@ietf.org>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

The range probably comes from the IANA definition of the ephemeral ports (49152 to 65535) although these are defined for short-lived TCP and not explicitly for UDP. Why this made it into the yang model for TWAMP-test (which is UDP) I dont know, probably someone mixed it up with TCP and it passed the reviewers without much thought.
[acm]
https://tools.ietf.org/html/rfc6335#section-6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6335-23section-2D6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=Y3I4sW9cQ0UXh8cUXuPymXo9soP2KQFzein5oCkPdKE&e=>
seems clear to me, without making the distinction between TCP and UDP
you mention. There was discussion on the ippm-list IIRC, too.

Most, if not all, implementations of TWAMP I have seen does not impose limitations on the source UDP ports for the TWAMP-test packets when configuring via CLI. For example neither Accedian, Exfo, Viavi, Juniper, Nokia, Huawei impose any limitation like that when configuring via CLI or GUI.

With a yang model based configuration the user will of course be limited if they use the yang model that only defines the ephemeral range as valid. I see no severe disadvantages of this, but it would of course have been better if the yang model was less restrictive, since the restriction has no real value in itself.

[acm] ...except avoiding a port assigned by IANA...

Al

On Tue, Aug 6, 2019 at 8:07 PM Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>> wrote:
Thanks Henrik. Where does this requirement come from? Also, how do I configure the UDP port outside the range using the TWAMP Yang model?

Thanks,
Rakesh

On Tue, Aug 6, 2019 at 11:19 AM Henrik Nydell <hnydell@accedian.com<mailto:hnydell@accedian.com>> wrote:
There is a distinction between "must be able to send to these destination ports" and "must only be able to send to these destination ports"

The first wording does not prohibit senders to be able to send also to other destination ports.


On Tue, Aug 6, 2019 at 4:57 PM Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>> wrote:
Hi Greg,
Many thanks for the reply.
As there are already implementations out there where such restrictions do not exist as discussed in another email thread (just forwarded them), the following text with MUST is already violated. The TWAMP Yang model draft-ietf-ippm-twamp-yang<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dtwamp-2Dyang-2D13&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=HR_5ntwVu98MLVsNSbfLkeGlQc_DST02a_jurALHOPQ&e=> should also not place such restriction.
Section 4.4
       Thus STAMP Session-Sender MUST be able to send test
       packets to destination UDP port number from the Dynamic and/or
       Private Ports range 49152-65535, test management system should find a
       port number that both devices can use.

Thanks,
Rakesh

On Sat, Aug 3, 2019 at 1:05 PM Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Rakesh,
my apologies for the misspelling of your name.
Thank you for your kind consideration of the proposed update.
Regarding the definition of the range of the valid UDP port numbers, draft-ietf-ippm-twamp-yang<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dtwamp-2Dyang-2D13&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=HR_5ntwVu98MLVsNSbfLkeGlQc_DST02a_jurALHOPQ&e=> uses type dynamic-port-number as follows:
     typedef dynamic-port-number {
       type inet:port-number {
         range 49152..65535;
       }
       description "Dynamic range for port numbers.";
     }
to specify the valid range for a sender-udp-port. The range for a UDP port number of a Session-Reflector has been specified slightly differently because it includes the well-known port 862:
           leaf reflector-udp-port {
             type inet:port-number {
               range "862 | 49152..65535";
               }
             description
               "The destination UDP port number used in the
                TWAMP-Test (UDP) test packets belonging to this
                test session.";
           }
But, as we observe, in both cases definitions include the Dynamic/Private range explicitly defined. I think that keeping STAMP specification consistent with the TWAMP, TWAMP YANG data model in particular, in the way the valid range of UDP ports is being specified, is beneficial to the STAMP document. Hope you'll agree.

Regards,
Greg

On Fri, Aug 2, 2019 at 10:53 AM Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>> wrote:
Thanks Greg for considering my review comments.
Good to see the message format aligned with draft-ietf-ippm-stamp-option-tlv and using MBZ 30. This should fix the interoperability issue between the two. This also gives few (3) bytes for any future extensions.
------------------------------------------------------------------------
You may fix the spelling of my name and another typo below:
OLD:
and Rakesh Gandi or their

NEW:
and Rakesh Gandhi for their
----------------------------------------------------------------------

I did not see following comment addressed. Is that intentional?
------------------------------------------------
On Tue, Jul 9, 2019 at 9:11 AM Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>> wrote:

    Thanks Greg for the reply.

    In this case, should the draft just state that the Session-Sender can select destination UDP port number following the guidelines specified in [RFC6335], instead of specifying following?

Section 4.4
    Thus STAMP Session-Sender MUST be able to send test
       packets to destination UDP port number from the Dynamic and/or
       Private Ports range 49152-65535, test management system should find a
       port number that both devices can use.
----------------------------------------------

Thanks,
Rakesh


On Fri, Aug 2, 2019 at 1:00 PM Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Rakesh,
thank you for your helpful comments. We've updated the format of the base STAMP test packet. Appreciate your feedback on the proposed changes, comments and questions,

Regards,
Greg

On Tue, Jul 9, 2019 at 9:27 AM Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>> wrote:
Hi Greg,
Regarding the size of the padding, yes, it's good to use the same size payload for query and response.
However, the STAMP payload with TLV extension (draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size (27 ( or > 29) vs. 30). Is there a way to make them compatible? Does it mean that for STAMP with TLV, Server Octets is set to 1, but it says MBZ 0 for all 30 bytes. If the responder supports Server Octets and see the size > 27, it may find the Server Octet size of 0 confusing?

Thanks,
Rakesh





On Mon, Jul 8, 2019 at 7:20 PM Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Shahram,
thank you for the review and questions. Please find my answers below tagged GIM>>.

Regards,
Greg

On Mon, Jul 8, 2019 at 2:02 PM Shahram Davari <shahram.davari@broadcom.com<mailto:shahram.davari@broadcom.com>> wrote:
HI Greg

I read your draft and have the following questions:

1) Does it require any UDP/TCP port number or it reuses the one from TWAMP? if it reuses from TWAMP then  how does the receiver differentiate between TWAMP and STAMP?
GIM>> STAMP uses the well-known UDP port number allocated for the OWAMP-Test/TWAMP-Test Receiver port (RFC 8545) as the default destination UDP port number.. STAMP may use destination UDP port number from the Dynamic and/or Private Ports range 49152-65535.
2) What is the benefit of STAMO compared to TWAMP?
GIM>> The work was driven by several observations, among them:

  *   challenges in achieving interoperability among implementations of TWAMP-Light;
  *   industry interest in standardizing performance monitoring in IP broadband access networks (TR-390);
  *   improve extensibility of IP performance monitoring tool to support measurements, testing of new metrics and parameters, e.g., consistency of CoS in the network.
3) Why is there so much MBZ byte?
GIM>> It was agreed to make the symmetrical size of STAMP test packets the default. RFC 6038 defined it for TWAMP and TR-390 requires it to be supported by TWAMP-Light implementations.

Thx
Shahram

On Jul 8, 2019, at 10:17 AM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Hi Mirja,
thank you for the suggested text. The new paragraph now reads as:
      Load of STAMP test packets offered to a network MUST be carefully
      estimated, and the possible impact on the existing services MUST
      be thoroughly analyzed before launching the test session.
      [RFC8085] section 3.1.5 provides guidance on handling network load
      for UDP-based protocol.  While the characteristic of test traffic
      depends on the test objective, it is highly recommended to stay in
      the limits as provided in [RFC8085].

If it is acceptable, I'd like to upload the updated version of draft-ieff-ippm-stamp before the cut-off deadline.

Regards,
Greg

On Mon, Jul 8, 2019 at 8:58 AM Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>> wrote:
Hi Greg,

See below.

> On 8. Jul 2019, at 16:54, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
>
> Hi Mirja,
> thank you for the reference to RFC 8085. I agree that the document is very much relevant and a reference to RFC 8085 in STAMP is useful. While reading Section 3.1.3 I came to think that the discussion and guidance in other sections of RFC 8085, particularly, Section 3.1.5 Implications of RTT and Loss Measurements on Congestion Control. Would adding the reference to that section in the new text proposed for the Security Considerations section work? I'll put RFC 8085 as Informational reference as it is BCP.
> NEW TEXT:
>       Load of STAMP test packets offered to a network MUST be carefully
>       estimated, and the possible impact on the existing services MUST
>       be thoroughly analyzed using [RFC8085] and its Section 3.1.5 in
>       particular before launching the test session....


Not sure if “using” is the right word but otherwise fine for me. Or you could have a separate sentence like:

“RFC8085 section 3.1.5 provides guidance on handling network load for UDP-based protocol. While the characteristic of test traffic depends on the test objective, it is highly recommended to say in the limits as provided in RFC8085.”

Or something similar…

BCP is the same maturity level as PS. So it wouldn’t be a downref. However, I think having this as informational ref is fine.

Mirja



>
> Regards,
> Greg
>
> On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>> wrote:
> Hi Greg,
>
> Thanks a lot for you reply. Changes are good. I wonder if it would be useful to provide a reference to RFC8085 because it has a lot of information about congestion control of UDP based traffic? It recommends to send not more than 1 packet per 3 seconds (if RTT is unknown). I guess it doesn’t make sense to require this for testing traffic, however, it could maybe still be a good recommendation? What do you think?
>
> Also I’ve just resend my review to the IPPM list, as I unfortunately cc’ed only the IPPM chairs instead of the whole list. Can you resend you proposed changes to the list, so other people are aware of these changes. Sorry for the unconvience.
>
> Mirja
>
>
> > On 6. Jul 2019, at 17:46, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
> >
> > Hi Mirja,
> > thank you for your thorough review, very pointed and helpful comments. Please find my responses in-lined and tagged GIM>>. Attached the diff.
> >
> > Regards,
> > Greg
> >
> > On Thu, Jul 4, 2019 at 9:10 AM Mirja Kuehlewind <ietf@kuehlewind.net<mailto:ietf@kuehlewind.net>> wrote:
> > Hi authors, hi all,
> >
> > Thanks for this well-written document and very good shepherd write-up! I would like discuss one point before I start IETF last call.
> >
> > I believe this document should say something about network load and congestion (control). OWAMP and TWAMP discuss quite a bit sender scheduling, however, as this is a simplified version, so I think it could at least be good to put a waring in this document that packet sending should be somehow rate limited. I know it might be hard to provide more concrete guidance but at least having some discussion or warning in this document could be good.
> > GIM>>  Thank you for your suggestion. Security Considerations section points to the fact that STAMP does not include control and management components:
> >    Because of the control
> >    and management of a STAMP test being outside the scope of this
> >    specification only the more general requirement is set:
> > adding the new text here:
> >       Load of STAMP test packets offered to a network MUST be carefully
> >       estimated, and the possible impact on the existing services MUST
> >       be thoroughly analyzed before launching the test session.
> >
> >
> > Another comment: You only say at the very end that a certain UDP port is used, which implies that STAMP runs over UDP. However, I think you should mention at the very beginning that this is a UDP-based protocol. Just to make things crystal clear.
> > GIM>> Adding the reference to "UDP transport" into the first sentence of Theory of  Operations section:
> >    STAMP Session-Sender transmits test packets over UDP transport toward STAMP Session-Reflector.
> >
> > Mirja
> >
> > P.S.:
> > Nit: s/This document defines active performance measurement test protocol/ This document defines an active performance measurement test protocol/
> > -> “an” missing
> > GIM>> Thank you. Done.
> > <Diff_ draft-ietf-ippm-stamp-06.txt - draft-ietf-ippm-stamp-07....txt.html>
>
_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=E34uqKmQdO2Vs1uXtW7HIiPr4co6fApp7dRo_EPCiio&e=>

_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=E34uqKmQdO2Vs1uXtW7HIiPr4co6fApp7dRo_EPCiio&e=>


--

Henrik Nydell
Sr Product Manager
1.866.685.8181
hnydell@accedian.com<mailto:hnydell@accedian.com>
[https://i.xink.io/Images/Get/N63832/a65.png]<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>
[https://i.xink.io/Images/Get/N63832/f97.png]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=w-fFLajYSxdAGnDPgc5eJL9Ke1Fxt_ZUh7g2JxMXFmw&e=> [https://i.xink.io/Images/Get/N63832/t99.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aLxX-L8YFiio4PJusnMzJACdZYIkFz5kzSYYg33tHXY&e=>  [https://i.xink.io/Images/Get/N63832/l54.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aV10PvZ65gihBtrcyRfWWFZ3Opvaf3e4gzQ9pRJIum0&e=>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=PowT9C9_E09Yg8toWCa4x0cfFsepQJ8D1Dhd9LZ1az4&e=>
accedian.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>


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.


--

Henrik Nydell
Sr Product Manager
1.866.685.8181
hnydell@accedian.com<mailto:hnydell@accedian.com>
[https://i.xink.io/Images/Get/N63832/a65.png]<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>
[https://i.xink.io/Images/Get/N63832/f97.png]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=w-fFLajYSxdAGnDPgc5eJL9Ke1Fxt_ZUh7g2JxMXFmw&e=> [https://i.xink.io/Images/Get/N63832/t99.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aLxX-L8YFiio4PJusnMzJACdZYIkFz5kzSYYg33tHXY&e=>  [https://i.xink.io/Images/Get/N63832/l54.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aV10PvZ65gihBtrcyRfWWFZ3Opvaf3e4gzQ9pRJIum0&e=>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=PowT9C9_E09Yg8toWCa4x0cfFsepQJ8D1Dhd9LZ1az4&e=>
accedian.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>


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.


--

Henrik Nydell
Sr Product Manager
1.866.685.8181
hnydell@accedian.com<mailto:hnydell@accedian.com>
[https://i.xink.io/Images/Get/N63832/a65.png]<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=UXlLLIWQPztVoCaATnyldPuiq5cMx4soEbPTGjmsJQE&e=>
[https://i.xink.io/Images/Get/N63832/f97.png]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=0ltpwFIjvuZ8sVhjuD2RN1tIgObw07RIgL_4j3vK9Zc&e=> [https://i.xink.io/Images/Get/N63832/t99.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=QTHdaq6bXMydVVJSnS8pfuhqEnLCWzO0tP9A-gyMWBA&e=>  [https://i.xink.io/Images/Get/N63832/l54.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=V_ehVarzjW8vvOqJeyq61146LyKQ_Rgz1fNJzJw1waI&e=>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=9V6-ggZb009wP2eti0vCu9OWNz1EgxcbDPqe0xCailk&e=>
accedian.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=UXlLLIWQPztVoCaATnyldPuiq5cMx4soEbPTGjmsJQE&e=>


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.


--

Henrik Nydell
Sr Product Manager
1.866.685.8181
hnydell@accedian.com<mailto:hnydell@accedian.com>
[https://i.xink.io/Images/Get/N63832/a65.png]<http://accedian.com/>
[https://i.xink.io/Images/Get/N63832/f97.png]<https://www.facebook.com/accedian/> [https://i.xink.io/Images/Get/N63832/t99.png] <https://twitter.com/Accedian>  [https://i.xink.io/Images/Get/N63832/l54.png] <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.