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

["Jorge Rabadan (Nokia)" <[e-mail]>]

Hi Yubao,

I would recommend reading RFC8584 section 4.1 for VLAN-aware bundle and AC-DF.

Also it is important to understand the difference between ethernet tag id and ethernet tag. The latter is used for DF election, and not the former.

“Ethernet Tag:
Used to represent a BD that is configured on a given ES for the purposes of DF election and <EVI, BD> identification for frames received from the CE. Note that any of the following may be used to represent a BD: VIDs (including Q-in-Q tags), configured IDs, VNIs (Virtual Extensible Local Area Network (VXLAN) Network Identifiers), normalized VIDs, I-SIDs (Service Instance Identifiers), etc., as long as the representation of the BDs is configured consistently across the multihomed PEs attached to that ES.
Ethernet Tag ID:
Normalized network wide ID that is used to identify a BD within an EVI and carried in EVPN routes.”

Hope it helps.
Thanks.
Jorge


From: BESS <[e-mail]> on behalf of [e-mail] <[e-mail]>
Date: Tuesday, May 16, 2023 at 11:43 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [bess] Discussion on modulo-based DF-Election of draft-ietf-bess-rfc7432bis-07

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.





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