[bess] Discussion on modulo-based DF-Election of draft-ietf-bess-rfc7432bis-07

wang.yubao2@zte.com.cn Tue, 16 May 2023 09:43 UTC

Return-Path: <wang.yubao2@zte.com.cn>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B01DC05E02F for <bess@ietfa.amsl.com>; Tue, 16 May 2023 02:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 067hjUQl-p57 for <bess@ietfa.amsl.com>; Tue, 16 May 2023 02:43:31 -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 ECC5CC05E02A for <bess@ietf.org>; Tue, 16 May 2023 02:43:30 -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 4QLBBQ1nKCz5B151; Tue, 16 May 2023 17:43:26 +0800 (CST)
Received: from njb2app05.zte.com.cn ([10.55.22.121]) by mse-fl2.zte.com.cn with SMTP id 34G9hGJp036387; Tue, 16 May 2023 17:43:16 +0800 (+08) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njy2app02[null]) by mapi (Zmail) with MAPI id mid203; Tue, 16 May 2023 17:43:18 +0800 (CST)
Date: Tue, 16 May 2023 17:43:18 +0800
X-Zmail-TransId: 2afa64635036fffffffff28-ca2a6
X-Mailer: Zmail v1.0
Message-ID: <202305161743187541444@zte.com.cn>
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: draft-ietf-bess-rfc7432bis-07@ietf.org
Cc: bess@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 34G9hGJp036387
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6463503E.000/4QLBBQ1nKCz5B151
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/BJVi_LpohCj4kE5CoG-kFgCLI5k>
Subject: [bess] Discussion on modulo-based DF-Election of draft-ietf-bess-rfc7432bis-07
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 May 2023 09:43:32 -0000

Hi all,







I noticed that the DF-election for VLAN-based/VLAN-bundle service interface has been modified in section 8.5 of rfc7432bis.





"3. When the timer expires, each PE ... ... The ordinals are used to determine which PE node will be the DF for a given EVPN instance on the Ethernet segment, using the following rule: Assuming a redundancy group of N PE nodes, the PE with ordinal i is the DF for an <ES, EVI> when (V mod N) = i, where V is the Ethernet tag for that EVI. For VLAN-Aware Bundle service, then the numerically lowest Ethernet tag in that EVI MUST be used in the modulo function."






If the EVIs are all VLAN-based or VLAN-bundle and above Ethernet tag is the Ethernet Tag ID of the corresponding A-D per EVI route, the Ethernet tag for each EVI will be 0. Thus above i will be 0 for each of these EVIs. But the goal of service carving is "The load-balancing procedure carves the set of EVIs on that ES among the PEs nodes evenly such that every PE is the DF for a disjoint and distinct set of EVIs for that ES." 


How can this goal be achieved for VLAN-based or VLAN-bundle service? As far as I know, RFC7432 didn't say that V is the ethernet tag ID for that EVI.







I understand that in AC-DF mode (AC-influenced DF-election) , the Ethernet tag for that EVI should be used to match a corresponding A-D per EVI route.


But if the modulo function is done using Ethernet Tag ID, the load-balancing cannot be evenly done for VLAN-based and VLAN-bundle service interface.






I guess, according to original RFC7432, when the modulo function is done, the V should be the original VLAN on that AC, especially in VLAN-based service interface and VLAN-aware bundle service interface with VID translation (https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-07#name-vlan-aware-bundle-service-i), where the VID is not the same as the ethernet Tag ID.


Is my understanding correct? Have I missed something important?






Furthermore, the lowest Ethernet Tag ID for all VLAN-aware bundle EVIs may be the same value, I guess it may be 0 or 1.  In such case,  the load-balancing cannot be evenly done for VLAN-aware bundle service interface either.


So maybe it should be said as the following: For VLAN-Aware Bundle service, then the numerically lowest Ethernet tag on that <ES, EVI> MUST be used in AC-DF mode, and the VID corresponding to that lowest ethernet Tag ID of that <ES, EVI> is used in the modulo function. 






The last question is that: If an ES are attached to serveral VLAN-aware bundle EVIs, can these EVIs use the same Ethernet Tag ID for that ES? 


If they can, then using ethernet tag ID to do the modulo function may not be a good choice.






Thanks,


Yubao