Re: [ippm] Comments for draft-fz-ippm-alt-mark-deployment

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Thu, 05 October 2023 08:41 UTC

Return-Path: <giuseppe.fioccola@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 C1BDFC1595E5 for <ippm@ietfa.amsl.com>; Thu, 5 Oct 2023 01:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 KJTmI07wz91K for <ippm@ietfa.amsl.com>; Thu, 5 Oct 2023 01:41:31 -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 265E9C153CA8 for <ippm@ietf.org>; Thu, 5 Oct 2023 01:41:31 -0700 (PDT)
Received: from frapeml100005.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4S1Q3R0n6Qz6K677 for <ippm@ietf.org>; Thu, 5 Oct 2023 16:39:47 +0800 (CST)
Received: from frapeml500006.china.huawei.com (7.182.85.219) by frapeml100005.china.huawei.com (7.182.85.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Thu, 5 Oct 2023 10:41:28 +0200
Received: from frapeml500006.china.huawei.com ([7.182.85.219]) by frapeml500006.china.huawei.com ([7.182.85.219]) with mapi id 15.01.2507.031; Thu, 5 Oct 2023 10:41:28 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Chongfeng Xie <chongfeng.xie@foxmail.com>, ippm <ippm@ietf.org>
Thread-Topic: Comments for draft-fz-ippm-alt-mark-deployment
Thread-Index: AQHZ9gebQ/crnZuV2UewLgmxqb3Ki7A5RHmQ
Date: Thu, 05 Oct 2023 08:41:28 +0000
Message-ID: <970f04ff3f6c48dfa39fe8cf3142a683@huawei.com>
References: <tencent_C35F7F008E738499C5C6BE54B214C6E4070A@qq.com>
In-Reply-To: <tencent_C35F7F008E738499C5C6BE54B214C6E4070A@qq.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.150.27]
Content-Type: multipart/alternative; boundary="_000_970f04ff3f6c48dfa39fe8cf3142a683huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/04KROLE72EcQW_p1vbFU562aex8>
Subject: Re: [ippm] Comments for draft-fz-ippm-alt-mark-deployment
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: Thu, 05 Oct 2023 08:41:35 -0000

Hi Chongfeng,
Thanks a lot for your detailed review and feedback.
Please see inline [GF].

Regards,

Giuseppe

From: Chongfeng Xie <chongfeng.xie@foxmail.com>
Sent: Tuesday, October 3, 2023 4:41 PM
To: ippm <ippm@ietf.org>
Cc: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Subject: Comments for draft-fz-ippm-alt-mark-deployment


Hello, folks,
I have given a review to draft-fz-ippm-alt-mark-deployment. This draft discusses the deployment considerations of Alternative Marking, which is helpful for operators to timely understand and master the performance of the network. therefore, I think this document is very useful and hope it can proceed smoothly in the future. In addition, I have the following comments and suggestions:
1) The first point is about the scope of the framework. Section 5 introduces "Manageability", which refers to configuring Alternate Marking in network nodes that support it, including to signal and configure the parameters to identify the flow to monitor. In Section 6, the main focus is on data collection and calculation, and an Alternative Marking Framework with Data Export, including NMS, is specifically provided. At present, it seems that this Framework in figure 2 does not include the configuration features described in section 5. In the operator network, it is likely that the configuration functions are implemented by the controller. I think that the Alternative Marking Framework should include both configuration and data export, in other words, the framework should also include so-called configuration functions, configuration and data collection form a closed loop between the system and the underlying network nodes.

[GF]: Good point. We mentioned the use of  the YANG model for configuring Alternate-Marking, but, I will update Figure 2 in order to include the configuration features together with the export capabilities. I also plan to add more details in the text.

2) NMS is a general and vague terminology, different operators may have different understandings and scopes of it. In particular, over the years, network management and operation have undergone many changes, making it difficult to use NMS to precisely cover related content. Therefore, it is recommended to avoid using the term NMS here, instead, this framework can be illustrated by showing the functional modules and interfaces between the modules and underlying network nodes in handling Alternative Marking.

[GF]: I agree. We can replace NMS with Configuration function and Data Collection module.

3) In addition, the IPv6 based Alternative Marking encapsulation utilizes HBH and Destination extension headers, so it is required that the underlying network enable functions related to the above extension headers. However, to my knowledge, most IPv6 networks do not pay much attention to the operation of HBH and Destination Option headers. Therefore, it is recommended to clearly indicate that the transmission and processing of extension headers should be enabled in order to support Alternative Marking.

[GF]: Yes, it is worth highlighting the need for support of HbH and DoH for IPv6. In this regard, we can also refer to the ongoing work in 6MAN WG (e.g. draft-ietf-6man-hbh-processing).

In the end, I would like to express my thanks to the authors for their work.I also hope the comments above have some values for the authors. Thank you!

[GF]: Thank you!

Cheers
Chongfeng