IETF Logo Mail Archive

RE: Follow-up on Error Performance Measurement presentation at IETF-110

"Wangyali(Yali,Data Communication Standards and Patents Dept)" <wangyali11@huawei.com> Mon, 17 May 2021 13:07 UTC

Return-Path: <wangyali11@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681623A371B; Mon, 17 May 2021 06:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 w0nGYg0JX7zT; Mon, 17 May 2021 06:07:52 -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 A4A1D3A374B; Mon, 17 May 2021 06:07:52 -0700 (PDT)
Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FkK2v5bmTz6wjNQ; Mon, 17 May 2021 20:59:19 +0800 (CST)
Received: from dggpeml100022.china.huawei.com (7.185.36.176) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 17 May 2021 15:07:48 +0200
Received: from dggpeml500024.china.huawei.com (7.185.36.10) by dggpeml100022.china.huawei.com (7.185.36.176) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 17 May 2021 21:07:46 +0800
Received: from dggpeml500024.china.huawei.com ([7.185.36.10]) by dggpeml500024.china.huawei.com ([7.185.36.10]) with mapi id 15.01.2176.012; Mon, 17 May 2021 21:07:46 +0800
From: "Wangyali(Yali,Data Communication Standards and Patents Dept)" <wangyali11@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, IETF IPPM WG <ippm@ietf.org>, RTGWG <rtgwg@ietf.org>
Subject: RE: Follow-up on Error Performance Measurement presentation at IETF-110
Thread-Topic: Follow-up on Error Performance Measurement presentation at IETF-110
Thread-Index: AQHXLAJyxSBu7Alb2kWqU4j5kuq9UKrn2VeA
Date: Mon, 17 May 2021 13:07:46 +0000
Message-ID: <ddc4329ad8de414883f79d4f8d785eca@huawei.com>
References: <CA+RyBmUrUzMdRAK1GDjYxivdFiSsL0FtJ8sjhxH=DGKQ5_dG7g@mail.gmail.com>
In-Reply-To: <CA+RyBmUrUzMdRAK1GDjYxivdFiSsL0FtJ8sjhxH=DGKQ5_dG7g@mail.gmail.com>
Accept-Language: en-US, zh-CN
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_ddc4329ad8de414883f79d4f8d785ecahuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/OJun9x6OwbzHVq9Jn0CTK00QWgo>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2021 13:07:59 -0000

Hi Greg,

After reading these draft, which are interesting to me, I have following considerations.


1)      Is the Integrated OAM defined as a new protocol? Otherwise this draft is intent to extend the BFD specified in RFC5880?

2)      If it’s a new protocol, why not define a new Integrated OAM message independent to BFD, which supports both proactive connectivity check and performance measurement ? For example, directly defining the LM message, DM message or combined LM/DM message in the IntOAM control message body but not as a TLV. While it’s flexible using TLVs.

3)      For EPM use case, it may be defined as a TLV in IntOAM control message, right?

From my side, this work is interesting. And willing to work together to advance the IntOAM document.

Best,
Yali

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, April 8, 2021 7:04 AM
To: IETF IPPM WG <ippm@ietf.org>; RTGWG <rtgwg@ietf.org>
Subject: Follow-up on Error Performance Measurement presentation at IETF-110

Dear All,
in the course of presenting our work on the Error Performance Measurement<https://datatracker.ietf.org/doc/draft-mirsky-ippm-epm/> (slides attached), I didn't mention the work on the Integrated OAM<https://datatracker.ietf.org/doc/draft-mmm-rtgwg-integrated-oam/>. The Integrated OAM work was presented and discussed at the RTGWG session during the IETF-110. We believe that EPM is one of the use cases that highlight the benefits of using the Integrated OAM. We believe that experts from IPPM and RTGWG WGs would be interested to see how the works we've presented are related to each other and help to solve challenges in operating networks.
The authors always welcome your questions, comment, and suggestions.

Regards,
Greg

v2.23.0 | Report a Bug | By Email