[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