[mpls] Re: Opsdir last call review of draft-ietf-mpls-inband-pm-encapsulation-14
xiao.min2@zte.com.cn Wed, 28 August 2024 08:06 UTC
Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA777C151082; Wed, 28 Aug 2024 01:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 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, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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 saQ1FWJhJfyX; Wed, 28 Aug 2024 01:06:16 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B462C14F738; Wed, 28 Aug 2024 01:06:12 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4WtxnC3VJQz8RV7Y; Wed, 28 Aug 2024 16:06:07 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4Wtxmg40kqz4x6Ch; Wed, 28 Aug 2024 16:05:39 +0800 (CST)
Received: from njy2app02.zte.com.cn ([10.40.13.116]) by mse-fl2.zte.com.cn with SMTP id 47S85Lfr041861; Wed, 28 Aug 2024 16:05:21 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njy2app04[null]) by mapi (Zmail) with MAPI id mid201; Wed, 28 Aug 2024 16:05:23 +0800 (CST)
Date: Wed, 28 Aug 2024 16:05:23 +0800
X-Zmail-TransId: 2afc66ceda43ffffffffdb3-bdb07
X-Mailer: Zmail v1.0
Message-ID: <20240828160523489cMau-FTYqRyNGX0XSUKTl@zte.com.cn>
In-Reply-To: <202408261804313624-W-MOovlpNwC1Q5we4Kf@zte.com.cn>
References: 20240826165805718n_xd6I1X5mpTFwHekDqjo@zte.com.cn,CY8PR11MB73401F761BF4D4B0FD8B7E95D48B2@CY8PR11MB7340.namprd11.prod.outlook.com,202408261804313624-W-MOovlpNwC1Q5we4Kf@zte.com.cn
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: dceccare@cisco.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 47S85Lfr041861
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 66CEDA6F.000/4WtxnC3VJQz8RV7Y
Message-ID-Hash: UH6EAYIEX5JHBQDR4DBVAT66XPSUR5M3
X-Message-ID-Hash: UH6EAYIEX5JHBQDR4DBVAT66XPSUR5M3
X-MailFrom: xiao.min2@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ops-dir@ietf.org, draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org, last-call@ietf.org, mpls@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: Opsdir last call review of draft-ietf-mpls-inband-pm-encapsulation-14
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/4_9nQ34_jRtfjBQnbb6IS_S8ghg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>
Hi Daniele, A new version -15 of this document has been posted to address your comments. Link as below. https://datatracker.ietf.org/doc/html/draft-ietf-mpls-inband-pm-encapsulation-15 Best Regards, Xiao Min Original From: 肖敏10093570 To: DanieleCeccarelli(dceccare) <dceccare@cisco.com>; Cc: ops-dir@ietf.org <ops-dir@ietf.org>;draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org <draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org>;last-call@ietf.org <last-call@ietf.org>;mpls@ietf.org <mpls@ietf.org>; Date: 2024年08月26日 18:04 Subject: Re: Opsdir last call review of draft-ietf-mpls-inband-pm-encapsulation-14 Hi Daniele, Thank you for the prompt reply. Please see inline. From: DanieleCeccarelli(dceccare) <dceccare@cisco.com> To: 肖敏10093570; Cc: ops-dir@ietf.org <ops-dir@ietf.org>;draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org <draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org>;last-call@ietf.org <last-call@ietf.org>;mpls@ietf.org <mpls@ietf.org>; Date: 2024年08月26日 17:27 Subject: RE: Opsdir last call review of draft-ietf-mpls-inband-pm-encapsulation-14 Hi Xiao Min, Please find some more comments in line. Thanks Daniele From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> Sent: Monday, August 26, 2024 10:58 AM To: Daniele Ceccarelli (dceccare) <dceccare@cisco.com> Cc: ops-dir@ietf.org; draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org; last-call@ietf.org; mpls@ietf.org Subject: Re: Opsdir last call review of draft-ietf-mpls-inband-pm-encapsulation-14 Hi Daniele, Thanks for your review and thoughtful comments. Please see inline. Original From: DanieleCeccarelliviaDatatracker <noreply@ietf.org> To: ops-dir@ietf.org <ops-dir@ietf.org>; Cc: draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org <draft-ietf-mpls-inband-pm-encapsulation.all@ietf.org>;last-call@ietf.org <last-call@ietf.org>;mpls@ietf.org <mpls@ietf.org>; Date: 2024年08月23日 20:34 Subject: Opsdir last call review of draft-ietf-mpls-inband-pm-encapsulation-14 Reviewer: Daniele Ceccarelli Review result: Has Issues General comments: The intro says: "Considering the MPLS performance measurement with the Alternate-Marking method can also be achieved by MNA encapsulation, it is agreed that this document will be made Historic once the MNA solution of performance measurement with the Alternate-Marking method is published as an RFC." The first reaction to this statement is: how long will it take for the MNA encapsulation to be delivered? If we already know that this will be obsoleted by the MNA encapsulation, is it worth publishing it? [XM]>>> At the request of the MPLS WG chairs, the text you quoted was added to version -11 of this document. After that, this document passed WGLC and there was unanimous consensus to publish it as an RFC. Considering there are existing interoperable implementations of this document, while the MNA solution of performance measurement with alternate marking method is still at the early stage without WG draft and known implementation, it's worth publishing this document. [[DC]] Ok. Sounds a pretty strange approach to me, but it’s up to the chairs to decide. Probably a temporary solution waiting for something to happen might be labelled as “experimental”, but again, up to the chairs to decide. [XM-2]>>> During the WGLC of this document, there was discussion about whether this document should be "standards track" or "experimental", it's agreed it should be "standards track". Detailed comments below: - Section 3: I was expecting a bit of intro/explanation here. The section starts saying that the encapsulation has this format. Boom. Is it something that already exists? If so where has it been defined? If not could we say something like" this document defines a new encapsulation as shown in figure below..." [XM]>>> That's defined in this document first. Propose to change the text as below. OLD Flow-based MPLS performance measurement encapsulation with alternate marking method has the following format: NEW This document defines the Flow-based MPLS performance measurement encapsulation with alternate marking method, as shown in figure below. [[DC]] sounds good. - Section 3 suggest rephrasing. OLD The Traffic Class (TC) and Time To Live (TTL) [RFC3032] for the XL and FLI MUST use the same field values as the label immediately preceding the XL. unless it is known that the XL will not be exposed as the top label at any point along the LSP. NEW The Traffic Class (TC) and Time To Live (TTL) fields of the XL and FLI MUST use the same values of the label immediately preceding the XL, unless it is known that the XL will not be exposed as the top label at any point along the LSP. Is the "unless..." really necessary? Can't this be always the case? [XM]>>> Yes, this can always be the case. Will use the text you suggested and delete the "unless...". - Section 3: "The BoS bit for the FL depends on whether the FL is placed at the bottom of the MPLS label stack, i.e., the BoS bit for the FL is set only when the FL is placed at the bottom of the MPLS label stack. Isn't this always the case? [XM]>>> No, Figure 2 provides an example the FL is not placed at the bottom of the MPLS label stack. [[DC]] I’m not saying that the FL is always at the bottom of the stack, I’m saying that the BoS bit for the FL is set when the FL is at the bottom of the stack. What I’m trying to say is that it’s not something newly defined here but expected behavior. [XM-2]>>> Aha, I see your point. :-) I see the value of this sentence is to emphasize that the definition of the BoS bit is not changed by this document in any way. - Section 3: To achieve the purpose of coloring the MPLS traffic, and to distinguish between hop-by-hop measurement and edge-to-edge measurement, the TC for the FL is defined as follows: The TC is a single field 3 bits long and here it's used as 3 independent flags. I'm not sure if this is possible, but if it is it must at least be explained. [XM]>>> This is possible and it's already been implemented. Propose to add below new text to the end of the TC definition. NEW Considering the FL is not used as a forwarding label, the repurposing of the TC for the FL is feasible and viable. [[DC]] I’m not an expert here, if you say that it’s possible to change the role/definition of label fields in non-forwarding labels I trust you. [XM-2]>>> Thank you for your trust. Regards, Xiao Min - Examples section highly appreciated - Section 4,5 and 6 clear [XM]>>> Thank you. Cheers, Xiao Min
- [mpls] Opsdir last call review of draft-ietf-mpls… Daniele Ceccarelli via Datatracker
- [mpls] Re: Opsdir last call review of draft-ietf-… xiao.min2
- [mpls] Re: Opsdir last call review of draft-ietf-… Daniele Ceccarelli (dceccare)
- [mpls] Re: Opsdir last call review of draft-ietf-… xiao.min2
- [mpls] Re: Opsdir last call review of draft-ietf-… xiao.min2
- [mpls] Re: Opsdir last call review of draft-ietf-… Daniele Ceccarelli (dceccare)