Re: [ippm] IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts
Tianran Zhou <zhoutianran@huawei.com> Tue, 23 April 2024 14:31 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 898B9C14E513 for <ippm@ietfa.amsl.com>; Tue, 23 Apr 2024 07:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.894
X-Spam-Level:
X-Spam-Status: No, score=-6.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzpSq0RxrENt for <ippm@ietfa.amsl.com>; Tue, 23 Apr 2024 07:31:17 -0700 (PDT)
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 4F9FEC14F5EC for <ippm@ietf.org>; Tue, 23 Apr 2024 07:31:17 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VP3vB0rCZz6D92N; Tue, 23 Apr 2024 22:11:18 +0800 (CST)
Received: from lhrpeml500002.china.huawei.com (unknown [7.191.160.78]) by mail.maildlp.com (Postfix) with ESMTPS id 65A29140CB1; Tue, 23 Apr 2024 22:11:25 +0800 (CST)
Received: from dggpemm500008.china.huawei.com (7.185.36.136) by lhrpeml500002.china.huawei.com (7.191.160.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 23 Apr 2024 15:11:24 +0100
Received: from kwepemf100007.china.huawei.com (7.202.181.221) by dggpemm500008.china.huawei.com (7.185.36.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 23 Apr 2024 22:11:21 +0800
Received: from kwepemf100007.china.huawei.com ([7.202.181.221]) by kwepemf100007.china.huawei.com ([7.202.181.221]) with mapi id 15.02.1544.004; Tue, 23 Apr 2024 22:11:21 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Tommy Pauly <tpauly@apple.com>, "IETF IPPM WG (ippm" <ippm@ietf.org>, "Zhukeyi(Kaiyin,Datacom Standard&Patent)" <zhukeyi@huawei.com>
Thread-Topic: [ippm] IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts
Thread-Index: AQHaipxckikIEh17l0O/OpMtIVJcBLF0MlPwgAEt/wCAAJqxCg==
Date: Tue, 23 Apr 2024 14:11:21 +0000
Message-ID: <205f7071475c49528ff0dfe3f488299a@huawei.com>
References: <EB9C8A72-2118-4D5F-8A49-BB6CC327297F@apple.com> <5ff7dd49fd0e4b8ab76ebb77663a467e@huawei.com>, <CA+RyBmV0Nn7F-__6gVTL4NsGC2hjaAdifk1noSB4AQfUxKwcDg@mail.gmail.com>
In-Reply-To: <CA+RyBmV0Nn7F-__6gVTL4NsGC2hjaAdifk1noSB4AQfUxKwcDg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/related; boundary="_004_205f7071475c49528ff0dfe3f488299ahuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/50W3NNl6XZqcA-mQe8OKDXM36vs>
Subject: Re: [ippm] IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 23 Apr 2024 14:31:19 -0000
Hi Greg, Thanks for the reply. Please see inline. Best, Tianran ________________________________ Sent from WeLink 发件人: Greg Mirsky<gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> 收件人: Tianran Zhou<zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>> 抄送: Tommy Pauly<tpauly@apple.com<mailto:tpauly@apple.com>>;IETF IPPM WG (ippm<ippm@ietf.org<mailto:ippm@ietf.org>>;Zhukeyi(Kaiyin,Datacom Standard&Patent)<zhukeyi@huawei.com<mailto:zhukeyi@huawei.com>> 主题: Re: [ippm] IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts 时间: 2024-04-23 20<tel:2024-04-23%2020>:58:25 Hi Tianran, thank you for your consideration of the proposal and questions. Please find my notes below tagged GIM>>. Regards, Greg On Tue, Apr 23, 2024 at 9:10 AM Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote: Hi Tommy, Greg and WG, During the discussions in the mailing list several month ago. We find some interesting use cases. My question is can we use a controller to configure different nodes instead of using this Control TLV? GIM>> An interesting point, thank you. In general, any control action, in my opinion, may be achieved through configuration. For example, leaves of multicast distribution tree could be configured to not reflect STAMP test packets of a specific STAMP test session (or not to reflect any STAMP packet). Similarly, SR ergress node could be configured with the path to transmit reflected STAMP packets to achieve the same behavior as using the STAMP extensions defined in RFC 9503. In my personal opinion, one does not preclude another. ZTR> I actually meant to ask what’s the benefit to do so. And on your examples, it seems no need for the body of control tlv, but only a not to reflect instruction. Or is this document want to introduce a way to eliminate the controller? GIM>> I am not sure what in this draft can be interpretted in that way. The draft proposes an optional extension, not a mandatory one. Also, the use of a controller is optional. A STAMP implementation may be configured and managed by means other than a controller (as noted in the quote below)." ZTR> What’s the scenario for this control tlv? No controller? Or still with a controller? Again what’s the benefit? Looking at RFC8762, one motivation of STAMP is: “At the same time, there has been noticeable interest in using a more straightforward mechanism for active performance monitoring that can provide deterministic behavior and inherent separation of control (vendor-specific configuration or orchestration) and test functions.” And in the reference model below, “The configuration and management of the STAMP Session-Sender, Session-Reflector, and sessions are outside the scope of this document and can be achieved through various means. A few examples are Command Line Interface, telecommunication services' Operational Support System (OSS) / Business Support System (BSS), SNMP, and NETCONF/YANG-based Software-Defined Networking (SDN) controllers.” [图片加载失败] So I am thinking whether this proposal want to go back to TWAMP? GIM>> Can you point to the text in the document that states that or lead you to that conclusion? Clearly, the authors have no intention to re-create a separate mandatory STAMP control plane like exists in TWAMP. ZTR > My understanding of your reply is you want to create an optional control plane. Right? This may introduce many issues that TWAMP control session solved. GIM>> Do you see benefits of establishing a mechanism in STAMP analogous to TWAMP Control plane? What these could be? ZTR > No I don’t think so. So I want to understand what‘s the difference to TWAMP control plane. I see many people have raised the security issue. GIM>> The authors appreciate the comments and suggestions we received from Tal and Sebastian, and we'll work on addressing their concerns in the next revisions of the draft. Best, Tianran From: ippm [mailto:ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>] On Behalf Of Tommy Pauly Sent: Wednesday, April 10, 2024 12<tel:%202024%2012>:28 AM To: IETF IPPM WG (ippm@ietf.org<mailto:ippm@ietf.org>) <ippm@ietf.org<mailto:ippm@ietf.org>> Subject: [ippm] IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts Hello IPPM, This email starts an adoption call for draft-mirsky-ippm-asymmetrical-pkts. This is a document we’ve discussed several times, and is a normative dependency for another document we discussed adopting at IETF 119, draft-gandhi-ippm-stamp-ext-hdr. You can find the draft here: https://datatracker.ietf.org/doc/draft-mirsky-ippm-asymmetrical-pkts/ https://www.ietf.org/archive/id/draft-mirsky-ippm-asymmetrical-pkts-04.html#name-reflected-test-packet-control Please review the draft and respond to this email to indicate if you think IPPM should adopt this document as a working group item. This call will last for 3 weeks. Please reply by Tuesday, April 30. Best, Tommy & Marcus _______________________________________________ ippm mailing list ippm@ietf.org<mailto:ippm@ietf.org> https://www.ietf.org/mailman/listinfo/ippm
- [ippm] IPPM adoption call for draft-mirsky-ippm-a… Tommy Pauly
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Ernesto Ruffini
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Sebastian Moeller
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Giuseppe Fioccola
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Rakesh Gandhi
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Tal Mizrahi
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… xiao.min2
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Footer Foote (Nokia)
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Bjørn Ivar Teigen
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Tianran Zhou
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Ruediger.Geib
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Henrik Nydell (hnydell)
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Tommy Pauly
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Tianran Zhou
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Tianran Zhou
- [ippm] Re: IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Tianran Zhou
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Tianran Zhou
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Tianran Zhou
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Greg Mirsky
- Re: [ippm] IPPM adoption call for draft-mirsky-ip… Tianran Zhou
- [ippm] Re: IPPM adoption call for draft-mirsky-ip… Tal Mizrahi