IETF Logo Mail Archive

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

wangyali <wangyali11@huawei.com> Fri, 16 October 2020 03:46 UTC

Return-Path: <wangyali11@huawei.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 4CCF13A0838; Thu, 15 Oct 2020 20:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tUn64-szJzUP; Thu, 15 Oct 2020 20:46:41 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 670A43A082F; Thu, 15 Oct 2020 20:46:41 -0700 (PDT)
Received: from lhreml701-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9190C96DAF65ACE8B565; Fri, 16 Oct 2020 04:46:37 +0100 (IST)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 16 Oct 2020 04:46:02 +0100
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Fri, 16 Oct 2020 04:46:01 +0100
Received: from DGGEML524-MBX.china.huawei.com ([169.254.1.7]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0487.000; Fri, 16 Oct 2020 11:44:48 +0800
From: wangyali <wangyali11@huawei.com>
To: "li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com>, draft-li-ippm-pm-on-lag <draft-li-ippm-pm-on-lag@ietf.org>
CC: ippm <ippm@ietf.org>
Thread-Topic: Comments for draft-li-ippm-pm-on-lag
Thread-Index: AQHWo1utDv93C4Uf1UeC08LrPhOcw6mZdRWA
Date: Fri, 16 Oct 2020 03:44:49 +0000
Message-ID: <1520992FC97B944A9979C2FC1D7DB0F405005338@dggeml524-mbx.china.huawei.com>
References: <1520992FC97B944A9979C2FC1D7DB0F40500377D@dggeml524-mbx.china.huawei.com> <MEYP282MB202292FF6B31BB51696F568DFC030@MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM>
In-Reply-To: <MEYP282MB202292FF6B31BB51696F568DFC030@MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.136]
Content-Type: multipart/alternative; boundary="_000_1520992FC97B944A9979C2FC1D7DB0F405005338dggeml524mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/C_4_Swk0q_oOoKBFS1-KCi5G7KU>
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 03:46:43 -0000

Hi Zhenqiang,

Thanks for your reply. As the optional TLVs, the length of the extended STAMP test packet, indeed is variable. While such extensions enhance the STAMP base functions, which lead active PM to be scalable. I prefer that having the extension formats to be an additional option in this draft.

Comments from other forks are also welcome. :)

Best regards,
Yali

From: li_zhenqiang@hotmail.com [mailto:li_zhenqiang@hotmail.com]
Sent: Friday, October 16, 2020 9:28 AM
To: wangyali <wangyali11@huawei.com>; draft-li-ippm-pm-on-lag <draft-li-ippm-pm-on-lag@ietf.org>
Cc: ippm <ippm@ietf.org>
Subject: Re: Comments for draft-li-ippm-pm-on-lag

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<mailto:li_zhenqiang@hotmail.com>

From: wangyali<mailto:wangyali11@huawei.com>
Date: 2020-10-14 15:09
To: draft-li-ippm-pm-on-lag@ietf.org<mailto:draft-li-ippm-pm-on-lag@ietf.org>
CC: IETF IPPM WG<mailto:ippm@ietf.org>
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

v2.23.0 | Report a Bug | By Email