Re: [ippm] Comments for draft-li-ippm-pm-on-lag

"li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com> Fri, 16 October 2020 01:27 UTC

Return-Path: <li_zhenqiang@hotmail.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 F1E673A0DD8; Thu, 15 Oct 2020 18:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 yofpTJ0w3w1R; Thu, 15 Oct 2020 18:27:43 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255030.outbound.protection.outlook.com [40.92.255.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC803A0DD6; Thu, 15 Oct 2020 18:27:40 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OzZ00Sof6LCN3deRoPl32OFGDrTAcVi4VxBDDpSuTHO0HOgdlMym09+lZv8RlFU+H/7F0DIJXdM94ylTFPyBaCT2TCBTDHNI83Gsg32p1GGMgQE6AQXeaq4zFJHhlYGAC0kTM44hZCOSXexrpIlGP9ocwM1yCrLQSdVL7LkEWw6+CBBRbjjsKt1qv1mfESNtiaNLHq6Te80PZ4xbbhPPFSfwcijVtnVwWUAH1PmP6uLX8gavAVvHGHzCLclaGJy0LimriPT14jrYPPOpdIjZtM2mML8U21MzryUw6lsosWaR5fyELuGyqJNK7rOOtrKwWDotvBhVZypnqt0PdWcDbw==
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=g9Sl3tpu6So/Yua/0brKnpPf96PWnuG8e3oHp5IoIfs=; b=d48aujrug9DvqZmYFaxTS9eJ20WRtM7/vO5XucXANR+eJvMzO39F4YAai6l8t2LTnJ6x8IPIBHvPaSzU+Aznw6sk2yE02OP/8t9fOuvYKlAWf6omfcy1RfLLJUmluNy6joIHiZNt6xHdA9oX1BSjxsHUBdYjetgdBQrqKcdNkr11xz+RN2MJU3WFvN9Je4kJLYIlPuwWmlgXEXWkY1cXVdsaWf1CeiTxnCidsVcqVffEkN1x6O+TjOA1lGyA785S8C4KnE6F3xE4yjGnR0lq48o0x1mPuHU+56Lc8e0aGdpYK0+3ovxlVBoYp+DrGPOeZ+dj0NnzxqRky+1wtfL3YA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g9Sl3tpu6So/Yua/0brKnpPf96PWnuG8e3oHp5IoIfs=; b=r3tsR93KJI2DTaLGedJ+z7qTjQh9PhVFDNJj0B5eWN17wuz/grwBwmiQdKsliszTE/ilkBEBB66kf7JEXGEkF5vSZKb3lFT08mI2YkMtbilmHa39R9k3Xn1xPOef73kXvoiSCw+kpERgtg3npgU3EqpMUw7udNTL2txVt26kwoDBEL3gRthDcbLBENMNKfBVySFSLtLNs+YgCHU2Idk9/TmtHdEFKzfYJFKWomF2ZSc4BfdP7P9w9PBIEnkCLkFUbMkdVBH9l+/d6NIut+eOfPb7prt82I4VFQtIj2rDBPBs+VKPRAw9GeC1hVbMHG2j+/jb+/GR3K078CrDXRAnuA==
Received: from HK2APC01FT035.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::46) by HK2APC01HT037.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::345) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Fri, 16 Oct 2020 01:27:37 +0000
Received: from MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM (10.152.248.54) by HK2APC01FT035.mail.protection.outlook.com (10.152.248.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Fri, 16 Oct 2020 01:27:37 +0000
X-IncomingTopHeaderMarker: OriginalChecksum:EE30B0DFB7FC8B938ADE4C8FD2235842309DDBEA1D873C497861803C730B21C1; UpperCasedChecksum:941DD6C489884B413E37F5B2EB2C1AEC4D0F8AB1CAB24EA02798886E514D24A1; SizeAsReceived:7619; Count:46
Received: from MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM ([fe80::a506:54c:167:69f8]) by MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM ([fe80::a506:54c:167:69f8%6]) with mapi id 15.20.3477.023; Fri, 16 Oct 2020 01:27:37 +0000
Date: Fri, 16 Oct 2020 09:28:15 +0800
From: "li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com>
To: wangyali <wangyali11@huawei.com>, draft-li-ippm-pm-on-lag <draft-li-ippm-pm-on-lag@ietf.org>
Cc: ippm <ippm@ietf.org>
References: <1520992FC97B944A9979C2FC1D7DB0F40500377D@dggeml524-mbx.china.huawei.com>
X-Has-Attach: no
X-Mailer: Foxmail 7.2.9.156[cn]
Message-ID: <MEYP282MB202292FF6B31BB51696F568DFC030@MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM>
Content-Type: multipart/alternative; boundary="----=_001_NextPart062467371103_=----"
X-TMN: [+gLdIU8I5/Bjay8PqU4JKBKMOLxOkCrT7RmG7WFrXsg=]
X-ClientProxiedBy: HK2PR0401CA0001.apcprd04.prod.outlook.com (2603:1096:202:2::11) To MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:b4::7)
X-Microsoft-Original-Message-ID: <2020101609281148029314@hotmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from cmcc-PC (183.243.251.179) by HK2PR0401CA0001.apcprd04.prod.outlook.com (2603:1096:202:2::11) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.3477.21 via Frontend Transport; Fri, 16 Oct 2020 01:27:36 +0000
X-MS-PublicTrafficType: Email
X-IncomingHeaderCount: 46
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-Correlation-Id: 8063b9c8-fbc1-4790-d8b7-08d87172aa68
X-MS-TrafficTypeDiagnostic: HK2APC01HT037:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: z1p+HwaPssW4h5YoO6RugAif4B47HME5IWyK30QUxKxNbg2NvEZWHweUjLTqMadmBRn0ROyAHZmDb6BRaFqZvx46Og524QYq/COTb0aemyv0B3tdeEIHxDLnJVi/h349y9gDgnoo9rMHn5HqNecTVrSscCJwmF8ApMgD9IVSmYKOad4uEN1Cp5J1CEiNaXRnsceNVdk2CmZVKVbfCyROQA==
X-MS-Exchange-AntiSpam-MessageData: GblFUL1OMzvN5jRDBIOsgQrV2pkIgoefXy2Ov3Aoqyel9IdkVwU+QF/q3ZyE1BqtLdjbuRzMhRNrDQjFtjuPgdjjakE1fn4iBV0cN5nL1w1ha+DHPnEICikap4fv37xRYmXoRhyoeyuJjDbZKdbz/g==
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8063b9c8-fbc1-4790-d8b7-08d87172aa68
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2020 01:27:37.6394 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-AuthSource: HK2APC01FT035.eop-APC01.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT037
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/HPx3I0QKDs0DdAY-7FFWFOuwOCU>
Subject: Re: [ippm] Comments for draft-li-ippm-pm-on-lag
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, 16 Oct 2020 01:27:45 -0000

Hi Yali,

Thank you for your support and suggestion.
The extended STAMP with optional TLV is an option to do PM on LAG. We discussed it internaly in our design team. The main concern about it is whether it is hardware friendly. Since the base STAMP with extensions proposed in this doc is sufficient for PM on LAG, do you still prefer the TLV option? We also want to know the opinion from this list.

Thanks,
Zhenqiang Li


li_zhenqiang@hotmail.com
 
From: wangyali
Date: 2020-10-14 15:09
To: draft-li-ippm-pm-on-lag@ietf.org
CC: IETF IPPM WG
Subject: Comments for draft-li-ippm-pm-on-lag
Hi authors,
 
This is a valuable draft discussing about PM on LAG through OWAMP/TWAMP/STAMP extension. 
 
The basic STAMP defined in RFC8762 has been extended to implement PM on member link of a LAG in your draft.  Do you consider the extended STAMP proposed in [draft-ietf-ippm-stamp-option-tlv] to be used for PM on LAG?
 
Nits:
OLD: When receives a Test packet, the micro STAMP Session-Reflector MUST
   use the member link from which the Test packet is received to
   correlate to a micro STAMP session and use the Sender/Reflector
   member link identifiers to validate whether the Test packet is is
   correctly transmitted over the expected member link.
 
NEW: When receives a Test packet, the micro STAMP Session-Reflector MUST
   use the member link from which the Test packet is received to
   correlate to a micro STAMP session and use the Sender/Reflector
   member link identifiers to validate whether the Test packet is
   correctly transmitted over the expected member link.
 
Best regards,
Yali