[mpls] Re: Éric Vyncke's Abstain on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)
xiao.min2@zte.com.cn Tue, 03 September 2024 06:36 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 5DD45C14F602; Mon, 2 Sep 2024 23:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 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, 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 SHqsqwMgAUoi; Mon, 2 Sep 2024 23:36:17 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F34C14F5EA; Mon, 2 Sep 2024 23:36:13 -0700 (PDT)
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 mxhk.zte.com.cn (FangMail) with ESMTPS id 4WybVd4xq6z5B1J5; Tue, 3 Sep 2024 14:36:09 +0800 (CST)
Received: from njy2app01.zte.com.cn ([10.40.12.136]) by mse-fl2.zte.com.cn with SMTP id 4836ZwPh021014; Tue, 3 Sep 2024 14:35:58 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njb2app05[null]) by mapi (Zmail) with MAPI id mid201; Tue, 3 Sep 2024 14:36:00 +0800 (CST)
Date: Tue, 03 Sep 2024 14:36:00 +0800
X-Zmail-TransId: 2afd66d6ae50221-0424a
X-Mailer: Zmail v1.0
Message-ID: <20240903143600016-Y313R_2KhcA0sJggm875@zte.com.cn>
In-Reply-To: <PH0PR11MB496610EC8CE778E149C7F43DA9922@PH0PR11MB4966.namprd11.prod.outlook.com>
References: 172501904944.250685.15035516054798308423@dt-datatracker-68b7b78cf9-q8rsp,20240902174217573KdK1XbKEH7VbPCQCkT4cT@zte.com.cn,PH0PR11MB496610EC8CE778E149C7F43DA9922@PH0PR11MB4966.namprd11.prod.outlook.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: evyncke@cisco.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 4836ZwPh021014
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 66D6AE59.007/4WybVd4xq6z5B1J5
Message-ID-Hash: BSMC2SRJZGZKSYUPFIS57HM746QKZIRH
X-Message-ID-Hash: BSMC2SRJZGZKSYUPFIS57HM746QKZIRH
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: iesg@ietf.org, draft-ietf-mpls-inband-pm-encapsulation@ietf.org, mpls-chairs@ietf.org, mpls@ietf.org, tsaad@cisco.com
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: Éric Vyncke's Abstain on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/IwkhHQ6DfaTLfBdbDsCC63bzDsw>
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 Eric, Thank you for the confirmation and suggested new text. I'll make the changes we agreed to version -16. With respect to the security considerations, I agree to add the text you proposed as "packet leakage is neither breaching privacy nor can be a source of DoS". Cheers, Xiao Min Original From: EricVyncke(evyncke) <evyncke@cisco.com> To: 肖敏10093570; Cc: iesg@ietf.org <iesg@ietf.org>;draft-ietf-mpls-inband-pm-encapsulation@ietf.org <draft-ietf-mpls-inband-pm-encapsulation@ietf.org>;mpls-chairs@ietf.org <mpls-chairs@ietf.org>;mpls@ietf.org <mpls@ietf.org>;Tarek Saad (tsaad) <tsaad@cisco.com>;tony.li@tony.li <tony.li@tony.li>; Date: 2024年09月02日 20:31 Subject: Re: Éric Vyncke's Abstain on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT) Hello Xiao and Tony, While I am still puzzled by the ‘time bomb’ in an RFC, all the suggested changes look like improvements (including the use of “deep labels inspection”). About the security considerations, we agree it seems ;-) but this may also be added in the text “packet leakage are neither breaching privacy not can be a source of DoS” (even if we can argue that such packets could increase the CPU utilization of another admin domain). Regards -éric From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> Date: Monday, 2 September 2024 at 11:43 To: Eric Vyncke (evyncke) <evyncke@cisco.com> Cc: iesg@ietf.org <iesg@ietf.org>, draft-ietf-mpls-inband-pm-encapsulation@ietf.org <draft-ietf-mpls-inband-pm-encapsulation@ietf.org>, mpls-chairs@ietf.org <mpls-chairs@ietf.org>, mpls@ietf.org <mpls@ietf.org>, Tarek Saad (tsaad) <tsaad@cisco.com>, tony.li@tony.li <tony.li@tony.li> Subject: Re: Éric Vyncke's Abstain on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT) Hi Eric, Thanks for your thoughtful review and comments. Please see inline. Original From: ÉricVynckeviaDatatracker <noreply@ietf.org> To: The IESG <iesg@ietf.org>; Cc: draft-ietf-mpls-inband-pm-encapsulation@ietf.org <draft-ietf-mpls-inband-pm-encapsulation@ietf.org>;mpls-chairs@ietf.org <mpls-chairs@ietf.org>;mpls@ietf.org <mpls@ietf.org>;tsaad@cisco.com <tsaad@cisco.com>;tony.li@tony.li <tony.li@tony.li>;tony.li@tony.li <tony.li@tony.li>; Date: 2024年08月30日 19:57 Subject: Éric Vyncke's Abstain on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-mpls-inband-pm-encapsulation-15: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-inband-pm-encapsulation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-mpls-inband-pm-encapsulation-15 Thank you for the work put into this document. As this I-D is about very specific protocols, I have only reviewed it from the high level perspective. I am balloting ABSTAIN because I am neither comfortable nor confident that having a time bomb (see below about MNA) in a published RFC is sensible. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Tony Li for the shepherd's write-up even if more information about the 'time bomb' would have assisted my reading. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Having the time bomb... Both the shepherd's write-up and section 1 `it is agreed that this document will be made Historic` contain a trigger bomb to make this document historic. No explanations are given, so I guess that this was a WG compromise but without any further justification, it is hard to tell and hard to judge the IETF consensus. Why has the MPLS WG (and IETF Last Call and then the IESG) worked on this document if it was clear that it will become historic ? I am not convinced that `it is agreed` in an IETF RFC is meaningful. If the authors or the MPLS WG have a precedent case in a published RFC, then I will be happy to read it. [XM]>>> I noticed Tony Li has replied to this point. That's exactly what happened and no more words from my side. ## Section 2.1 Beyond acronyms expansions, some information references (e.g., for IPFIX or MNA), or some concise definitions (e.g., for eSPL or cSPL) would be useful for the readers. [XM]>>> Make sense. Propose to make the changes as below. IPFIX, add a reference to RFC7011. MNA, add a reference to RFC9613. eSPL, add text "A special-purpose label that is placed in the label stack after the Extension Label (value 15)". cSPL, add text "The combination of the Extension Label (value 15) and an Extended Special Purpose Label". ## Section 3 Possibly linked to my lack of MPLS expertise, I wonder why fields MUST be identical and MAY differ in `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. In this case the TC and TTL for the XL and FLI MAY be of different values. ` Should `In this case` be more specific ? [XM]>>> "In this case..." should have been deleted along with the deletion of "unless..." in version -15. That's a missing point when I made changes in version -15. Will delete "In this case..." in version -16. Sorry for the confusion. What is the expected behavior when the TC/TTL are not using the same value ? Is this specified in other MPLS document or should it be specified in this I-D ? [XM]>>> The quoted text was originally borrowed from Section 4.2 of RFC 6790, which says "X SHOULD put the same TTL and TC fields for the ELI as it does for TL". Considering the exception case in RFC 6790 doesn't apply to this document, MUST is used rather than SHOULD. In RFC 6790 I don't find the expected behavior when the TC/TTL are not using the same value, so propose to remain as is. ## Section 4 Also probably due to my own lack of expertise, how can a transit MPLS node know that it needs to do 'deep packet inspection' ? [XM]>>> That may be the default behavior of a transit MPLS node or some provision may be needed. It seems to me it's outside the scope of this document. BTW, as 'deep packet inspection' is usually used in a security context to look in the application payload, may I suggest to use 'labels look-ahead' or something similar ? [XM]>>> Is s/deep packet inspection/deep labels inspection ok for you? ## Section 7 Please add a reference for `Synonymous Flow Label`. [XM]>>> There is already a reference to RFC 8957 (Synonymous Flow Label Framework). I don't mind to add one more reference to that RFC. :-) ## Section 8 While I understand that it is not clean when packets with those labels leak outside the admin domain, what are the *actual security issues* ? E.g., DoS ? privacy ? [XM]>>> To be honest, I don't see *actual security issues* here. If there are some, I'm happy to add. The Flow-ID label introduced in this document is similar to the Entropy label introduced in RFC 6790, and after checking the security section of that RFC, I don't find them. # NITS (non-blocking / cosmetic) ## Section 3 Rather than `as shown in figure below` please use the figure number. [XM]>>> OK. Will do that change. Cheers, Xiao Min
- [mpls] Éric Vyncke's Abstain on draft-ietf-mpls-i… Éric Vyncke via Datatracker
- [mpls] Re: Éric Vyncke's Abstain on draft-ietf-mp… Tony Li
- [mpls] Re: Éric Vyncke's Abstain on draft-ietf-mp… xiao.min2
- [mpls] Re: Éric Vyncke's Abstain on draft-ietf-mp… Eric Vyncke (evyncke)
- [mpls] Re: Éric Vyncke's Abstain on draft-ietf-mp… xiao.min2
- [mpls] Re: Éric Vyncke's Abstain on draft-ietf-mp… xiao.min2