Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Tianran Zhou <zhoutianran@huawei.com> Mon, 07 February 2022 01:25 UTC

Return-Path: <zhoutianran@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 ACA423A1114 for <ippm@ietfa.amsl.com>; Sun, 6 Feb 2022 17:25:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 HlLE4l09dfdd for <ippm@ietfa.amsl.com>; Sun, 6 Feb 2022 17:25:25 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2863A1118 for <ippm@ietf.org>; Sun, 6 Feb 2022 17:25:24 -0800 (PST)
Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JsT2d2mbmz67lJd; Mon, 7 Feb 2022 09:24:41 +0800 (CST)
Received: from kwepeml500004.china.huawei.com (7.221.188.141) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Feb 2022 02:25:20 +0100
Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Mon, 7 Feb 2022 09:25:18 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Henrik Nydell <hnydell@accedian.com>, "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
CC: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, ippm <ippm@ietf.org>
Thread-Topic: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt
Thread-Index: AQHYFPJxu5xCezYrfEWdrz70y9tLx6x8k8sAgArCImA=
Date: Mon, 07 Feb 2022 01:25:18 +0000
Message-ID: <6e5bc80d616a4d9d851285505f3731d0@huawei.com>
References: <2022012917284150500611@chinamobile.com> <CALhTbpqYR2NUq1kHvb4hv8Ppmv5u7iPfo8ZtK+2gFhZoM1pL5g@mail.gmail.com>
In-Reply-To: <CALhTbpqYR2NUq1kHvb4hv8Ppmv5u7iPfo8ZtK+2gFhZoM1pL5g@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.195]
Content-Type: multipart/alternative; boundary="_000_6e5bc80d616a4d9d851285505f3731d0huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/M_YH7yy4MzRr3aRVM0Zpq5D5u6A>
Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt
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: Mon, 07 Feb 2022 01:25:31 -0000

Hi Henrik,

This draft follows the same pattern as RFC7130, where BFD is also a protocol over UDP, and applied to LAG.
I am not sure if I can agree with you that TWAMP is layer-3, nor an odd choice for LAG.
For the Y.1731, would you like to shed light how it could apply? So that we can compare.

Thanks,
Tianran

From: Henrik Nydell [mailto:hnydell@accedian.com]
Sent: Monday, January 31, 2022 8:56 PM
To: lizhenqiang@chinamobile.com
Cc: Tianran Zhou <zhoutianran@huawei.com>; Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; ippm <ippm@ietf.org>
Subject: Re: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Yes, that is understood, which is why I think TWAMP (being layer-3) is an odd choice for this. A layer-2 test like Y.1731 would be more suitable to monitor performance of individual LAG links.



On Sat, Jan 29, 2022 at 10:28 AM lizhenqiang@chinamobile.com<mailto:lizhenqiang@chinamobile.com> <lizhenqiang@chinamobile.com<mailto:lizhenqiang@chinamobile.com>> wrote:
Hello Henrik and all,

We considered the situation you mentioned. Becase it is difficult to traverse all the possible link combinations, i.e. the number of possible substreams is huge, we try to address LAG that directly connects two devices first.

________________________________
Best Regards,
Zhenqiang Li

li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>

From: Henrik Nydell<mailto:hnydell@accedian.com>
Date: 2022-01-28 19:56
To: Tianran Zhou<mailto:zhoutianran=40huawei.com@dmarc.ietf.org>
CC: Giuseppe Fioccola<mailto:giuseppe.fioccola=40huawei.com@dmarc.ietf.org>; IETF IPPM WG \(ippm@ietf.org\)<mailto:ippm@ietf.org>
Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt
I still think it would be much better to generalize this micro TWAMP concept and not tie this to LAG, since that will be implementation specific - only if you implement TWAMP directly on a LAG-device this draft would apply.
Better then to generalize the concept and call the added identifier "Substream ID" or something similar. Then this draft would also apply to for example a vendor that implements routing over different paths or as Tianran pointed out, MPLS-SR uses. Thus I would propose removing all references to LAG in this draft and widen the scope to any situation where there would be uses for labelled (ID:ed) substreams between the same TWAMP-sender and session-reflector.



On Fri, Jan 28, 2022 at 12:15 PM Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote:
Hi Giuseppe,

Thanks very much for your review.
I will incorporate your suggestions in the next revision.

Cheers,
Tianran

-----Original Message-----
From: ippm [mailto:ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>] On Behalf Of Giuseppe Fioccola
Sent: Friday, January 28, 2022 7:03 PM
To: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>>; IETF IPPM WG (ippm@ietf.org<mailto:ippm@ietf.org>) <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi Tianran, All,
I think that this is a useful work.
For LAG, the use of active methods (OWAMP, TWAMP, STAMP) can also complement passive and hybrid methods. Indeed, the extensions proposed in this draft allow to monitor all the links and not only the link crossed by the observed packet stream.
Maybe, you can also highlight this point in the introduction section.

Minor nits:
s/Reflector Member Link ID fields/Reflector Member Link ID field/

s/When sending a response to the received Test packet, the micro TWAMP Session-Sender/ When sending a response to the received Test packet, the micro TWAMP Session- Reflector/


Regards,

Giuseppe


-----Original Message-----
From: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> On Behalf Of Tianran Zhou
Sent: Monday, January 24, 2022 7:23 AM
To: IETF IPPM WG (ippm@ietf.org<mailto:ippm@ietf.org>) <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi WG,

We think this is an useful work on adapting OWAMP/TWAMP in LAG performance measurement.
We updated this draft based on the comments from the meeting discussion and mailing list.
Thanks for all the suggestions.
More reviews and comments are welcome.

Cheers,
Tianran

-----Original Message-----
From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>]
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>; Guo Jun <guo.jun2@zte.com.cn<mailto:guo.jun2@zte.com.cn>>; Jun Guo <guo.jun2@zte.com.cn<mailto:guo.jun2@zte.com.cn>>; Rakesh Gandhi <rgandhi@cisco.com<mailto:rgandhi@cisco.com>>; Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>; Zhenqiang Li <li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt


A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
has been successfully submitted by Tianran Zhou and posted to the IETF repository.

Name:           draft-li-ippm-otwamp-on-lag
Revision:       02
Title:          One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG
Document date:  2022-01-24
Group:          Individual Submission
Pages:          13
URL:            https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt
Status:         https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag
Diff:           https://www.ietf.org/rfcdiff?url2=draft-li-ippm-otwamp-on-lag-02

Abstract:
   This document defines extensions to One-way Active Measurement
   Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to
   implement performance measurement on every member link of a Link
   Aggregation Group (LAG).  Knowing the measured metrics of each member
   link of a LAG enables operators to enforce the performance based
   traffic steering policy across the member links.





The IETF Secretariat


_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm


--

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://ca.linkedin.com/company/accedian>
<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.


--

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://ca.linkedin.com/company/accedian>
<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.