[bess] Re: comments on draft-ietf-bess-rfc7432bis

zhang.zheng@zte.com.cn Wed, 19 March 2025 06:45 UTC

Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: bess@mail2.ietf.org
Delivered-To: bess@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 668A6E6F30C for <bess@mail2.ietf.org>; Tue, 18 Mar 2025 23:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.194
X-Spam-Level:
X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4l3jvBhMLm2 for <bess@mail2.ietf.org>; Tue, 18 Mar 2025 23:45:44 -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 mail2.ietf.org (Postfix) with ESMTPS id 02ABCE6F2FE for <bess@ietf.org>; Tue, 18 Mar 2025 23:45:43 -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 4ZHfNf4fNvz5B1Jc for <bess@ietf.org>; Wed, 19 Mar 2025 14:45:38 +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 4ZHfN15qzmz4xfxN; Wed, 19 Mar 2025 14:45:05 +0800 (CST)
Received: from njy2app03.zte.com.cn ([10.40.13.14]) by mse-fl2.zte.com.cn with SMTP id 52J6is6R089298; Wed, 19 Mar 2025 14:44:54 +0800 (+08) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njy2app01[null]) by mapi (Zmail) with MAPI id mid203; Wed, 19 Mar 2025 14:44:56 +0800 (CST)
Date: Wed, 19 Mar 2025 14:44:56 +0800
X-Zmail-TransId: 2af967da67e823d-9641d
X-Mailer: Zmail v1.0
Message-ID: <20250319144456212w_ESBpR1qtdVBHVV4CqoQ@zte.com.cn>
In-Reply-To: <20241205083350279Zq3XISe5AL_rUzJ1t9_z_@zte.com.cn>
References: 20241205083350279Zq3XISe5AL_rUzJ1t9_z_@zte.com.cn
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: sajassi@cisco.com, lburdet@cisco.com, je_drake@yahoo.com, jorge.rabadan@nokia.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 52J6is6R089298
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 67DA6812.000/4ZHfNf4fNvz5B1Jc
Message-ID-Hash: 7EUJ4V5Z6VB6JKX67MAZONB64TJBYNEN
X-Message-ID-Hash: 7EUJ4V5Z6VB6JKX67MAZONB64TJBYNEN
X-MailFrom: zhang.zheng@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: bess@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [bess] Re: comments on draft-ietf-bess-rfc7432bis
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/vxJ5xWDMWmWej7MpMbaKn8FHZlE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Owner: <mailto:bess-owner@ietf.org>
List-Post: <mailto:bess@ietf.org>
List-Subscribe: <mailto:bess-join@ietf.org>
List-Unsubscribe: <mailto:bess-leave@ietf.org>

Just resent this draft to the mailing list.
Appreciate for the clarification from authors.
Thanks,
Sandy












Original


From: 张征
To: sajassi@cisco.com <sajassi@cisco.com>;lburdet@cisco.com <lburdet@cisco.com>;je_drake@yahoo.com <je_drake@yahoo.com>;jorge.rabadan@nokia.com <jorge.rabadan@nokia.com>;
Cc: bess@ietf.org <bess@ietf.org>;
Date: 2024年12月05日 08:36
Subject: [bess] comments on draft-ietf-bess-rfc7432bis


_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-leave@ietf.org


Hi, 
I have some comments about the flow label, could you please help me understand it more clearly:

1. Can the flow label be used with other bottom label, such as the GAL used in RFC9489. When both of the labels are used, the flow label is no longer the bottom label, right?

2. In the last paragraph of section 7.11.2, 
"......  If there is a mismatch, the local PE MUST NOT add the
   remote PE as the EVPN destination for any of the corresponding
   service instances.  The Flow label capability signaling is further
   described in Section 18.1."
From this sentense, we know that if the PE supports flow label, but the remote PE doesn't, or the PE doesn't support flow label, but the remote PE does, then in both cases, the remote PE will be excluded as an EVPN destination.

But in section 18.1:
"   *  When F-bit is set to 1, the PE announces the capability of both
      sending and receiving flow label for known unicast.

      If the PE is capable itself of supporting Flow Label, then:

      -  upon receiving the F-bit set (F=1) from a remote PE, it MUST
         send known unicast packets to that PE with Flow labels;

      -  alternately, upon receiving the F-bit unset (F=0) from a
         remote PE, it MUST NOT send known unicast packets to that PE
         with Flow labels."
From the description, it seems that when PE supports flow label, but the remote PE doesn't support flow label, the remote PE will not be excluded as an EVPN destination, do I understand it correctly?

3. for the sentence in section 18.1:
"      When a PE that doesn't support flow label, receives the F-bit set
      (F=1) from a remote PE, it takes the following actions: a) it
      notifies the operator and b) it excludes the remote PE as the EVPN
      destination for any of the corresponding service instances.  ......"
Regarding the action b, does it mean that the remote PE's RT3 routes will be excluded from all the services, or only for that remote PE's RT2/RT1 routes?
Will the remote PE's RT4 routes be excluded from these services?

Thank you very much!
Best regards,
Sandy