[mpls] Re: John Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)
xiao.min2@zte.com.cn Tue, 03 September 2024 07:56 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 92DC3C15198F; Tue, 3 Sep 2024 00:56:11 -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 usfPypUp1zww; Tue, 3 Sep 2024 00:56:09 -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 4C83FC14F6BE; Tue, 3 Sep 2024 00:55:57 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (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 4WydGd2V96z8R039; Tue, 3 Sep 2024 15:55:53 +0800 (CST)
Received: from njy2app08.zte.com.cn ([10.40.13.206]) by mse-fl1.zte.com.cn with SMTP id 4837teer030472; Tue, 3 Sep 2024 15:55:41 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njy2app04[null]) by mapi (Zmail) with MAPI id mid201; Tue, 3 Sep 2024 15:55:43 +0800 (CST)
Date: Tue, 03 Sep 2024 15:55:43 +0800
X-Zmail-TransId: 2afc66d6c0ff1a3-bb115
X-Mailer: Zmail v1.0
Message-ID: <20240903155543651yrxENssUczvXjb7jYxvnX@zte.com.cn>
In-Reply-To: <172506137980.395202.2970841674854076736@dt-datatracker-68b7b78cf9-q8rsp>
References: 172506137980.395202.2970841674854076736@dt-datatracker-68b7b78cf9-q8rsp
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: jgs@juniper.net
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 4837teer030472
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 66D6C109.001/4WydGd2V96z8R039
Message-ID-Hash: OACKHIAR743VVJUWKOTPQGCGL2NJ3HU4
X-Message-ID-Hash: OACKHIAR743VVJUWKOTPQGCGL2NJ3HU4
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: John Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/NM5vWYxR7HU5uHHjU4ifcwo3_MA>
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 John, Thank you for the thoughtful review and comments. Please see inline. Original From: JohnScudderviaDatatracker <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月31日 07:43 Subject: John Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT) John Scudder has entered the following ballot position for draft-ietf-mpls-inband-pm-encapsulation-15: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document. I agree with Éric Vyncke that the paragraph in the introduction about moving to Historic is unusual, to say the least. However, if the working group has consensus to publish the document in this form, I won’t stand in their way. [XM]>>> Thank you for your understanding. I do have three points I'd like to discuss, and also a comment. ## DISCUSS ### Section 3, same values, or different? 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. The "in this case" sentence doesn't make sense to me (what case is "this case"?), and seems to contradict the preceding sentence. Either they MUST use the same values, or not. Which is it? Is there something missing before the "in this case" sentence? [XM]>>> Sorry for the confusion. As I've replied to Éric Vyncke, "In this case..." should have been deleted along with the deletion of "unless..." in version -15. Will do it in version -16. ### Number of flows vs. ECMP Section 3 says, The Flow-ID Label (FL) is used as an MPLS flow identification [RFC8372]. Its value MUST be unique within the administrative domain. So, there can be at most 2^20 flows per administrative domain. That seems small, but I guess it's OK if I think of the number of instrumented flows as being a small fraction of the total flows that exist. But then later, Section 7 says, Analogous to what's described in Section 5 of [RFC8957], under conditions of Equal-Cost Multipath (ECMP), the introduction of the FL may lead to the same problem as caused by the Synonymous Flow Label (SFL). The two solutions proposed for SFL would also apply here. Specifically, adding FL to an existing flow may cause that flow to take a different path. If the operator expects to resolve this problem, they can choose to apply entropy labels [RFC6790] **or add FL to all flows**. (Emphasis added.) When I add these up, it seems to me that the operator of a large network has some unpleasant options. - They can accept that the use of FL may perturb the path taken by the flow. But that seems unacceptable for a technology whose purpose is performance measurement. - They can use entropy label. - They can add FL to all flows, but this means they have to instrument every flow, so they really are restricted to 2^20 total flows in their network. That is a rather small number, probably too small for a significant deployment.. The conclusion I arrive at is that any deployment at scale has to use entropy label. Is that correct? If so it seems to me it would be better to be more up-front about it. If I'm mistaken (e.g. there's some realistic use case where it's fine to accept the observer effect perturbing the selected path, or where 2^20 flows is more than enough) I'd appreciate some help seeing it. [XM]>>> I checked it with my colleague who has implemented this feature in ZTE. The takeaway is that "adding FL to an existing flow may cause that flow to take a different path" doesn't apply to our implementation. There are two ways for ECMP hash, one way is the entropy label, and the other way is the inner IP header, so the SPL and the FL won't affect the ECMP at all. ### Penultimate hop popping creates a conflict Section 4 has, * The processing node MUST pop the XL, FLI and FL from the MPLS label stack when it needs to pop the preceding forwarding label. The egress node MUST pop the whole MPLS label stack, and this document doesn't introduce any new process to the decapsulated packet. But Section 3.1 said, Note that here if the penultimate hop popping (PHP) is in use, the PHP LSR that recognizes the cSPL MUST NOT pop the cSPL and the following Flow-ID label, otherwise the egress LSR would be excluded from the performance measurement. As far as I can tell, these two are in conflict, and there's no way to comply with both other than by disabling PHP. That's OK I guess, but if so you should just say PHP isn't allowed. [XM]>>> Yes, you're correct. Propose to change the text in Section 3.1 as below. OLD Note that here if the penultimate hop popping (PHP) is in use, the PHP LSR that recognizes the cSPL MUST NOT pop the cSPL and the following Flow-ID label, otherwise the egress LSR would be excluded from the performance measurement. NEW Note that here if the penultimate hop popping (PHP) is in use, the PHP LSR that recognizes the cSPL should not pop the cSPL and the following Flow-ID label, otherwise the egress LSR would be excluded from the performance measurement. So the PHP should be disabled, unless it's acceptable to exclude the egress LSR. By the way (and this is not DISCUSS level, just included here since we're already talking about this section) I find it problematic that a subsection called "examples" includes normative requirements, which 3.1 does in two places -- the quote above, and also, Note that for this example, the two Flow-ID Label values appearing in a label stack MUST be different. In other words, the Flow-ID label applied to the MPLS transport and the Flow-ID label applied to the MPLS service MUST be different. Also, note that the two Flow-ID label values are independent of each other. For example, two packets can belong to the same VPN flow but different LSP flows, or two packets can belong to different VPN flows but the same LSP flow. [XM]>>> Make sense. Propose to do s/MUST/must/g for the quoted text. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ### Section 8, ACLs The Shepherd write-up, and Section 9, indicate that this specification has been implemented. Section 8 says, To prevent packets carrying Flow-ID labels from leaking from one domain to another, domain boundary nodes SHOULD deploy policies (e.g., ACL) to filter out these packets. Specifically, at the sending edge, the domain boundary node SHOULD filter out the packets that carry the Flow-ID Label Indicator and are sent to other domains. At the receiving edge, the domain boundary node SHOULD drop the packets that carry the Flow-ID Label Indicator and are from other domains. Do the existing implementations provide the necessary ACL primitives to comply with the SHOULD above? For that matter, why are these SHOULD and not MUST? [XM]>>> I checked it with my colleague who has implemented this feature in ZTE. The takeaway is that the existing implementation supports the necessary ACL provision. As I recall it, there is no specific consideration on using SHOULD against MUST, so will do s/SHOULD/MUST/g for the quoted text. Cheers, Xiao Min
- [mpls] John Scudder's Discuss on draft-ietf-mpls-… John Scudder via Datatracker
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… John Scudder
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… BRUNGARD, DEBORAH A
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Greg Mirsky
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… James Guichard
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… James Guichard
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Stewart Bryant
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Joel Halpern
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… James Guichard
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Stewart Bryant
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Tony Li
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… xiao.min2