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

[[e-mail]]

Hi Jorge,






Thanks for your explanation. 


I doubt that the meaning of Ethernet Tag is not consistent in rfc7432bis. There are some examples.


1) section 13.1 "If P2MP LSPs are being used, the packet MUST be sent on the P2MP LSP of which the PE is the root, for the <EVI, BD> associated with the received packet's Ethernet tag."


    If the Ethernet tag is a VNI or normalized VID, the received packet can't contain a VNI or normalized VID.


2) section 9.2.1 "· Alternatively, a PE may advertise a unique EVPN label per <MAC-VRF, Ethernet tag> combination. This label assignment is referred to as a per <MAC-VRF, Ethernet tag> label assignment."


    Is the Ethernet tag here an Ethernet Tag ID or a VLAN-tag on the AC? Typically a VLAN-tag only has a port-based significance, thus I don't see why it should be combined with a MAC-VRF.



3) "7.10.1. Auto-derivation from the Ethernet Tag (VLAN ID)... ... If the Ethernet Tag ID length is 24 bits, the RT for the MAC-VRF can be auto-derived as per [RFC8365] section 5.1.2.1."


    I think the auto-derivation is actually done by Ethernet Tag ID, not Ethernet Tag, in "unique VLAN ID" use case, the Ethernet Tag happens to be the same as Ethernet Tag ID, but generally speaking the RT is derived from the Ethernet Tag ID.


    Actually, in RFC7432, this section is called "auto-derivation from the Ethernet Tag ID"


4) In "Inclusive Multicast Ethernet Tag Route", the Ethernet Tag is obvious has nothing to do with the "Ethernet Tag", but refers to the "Ethernet Tag ID".



5) To me it is a bit confusing that the "Ethernet Tag ID" is not the ID of the "Ethernet Tag", literally it should have this meaning. 


6) The "Ethernet Tag" tries to combine too many things together, some of which can't be included in the packets received on the corresponding ES, some of which is even not ethernet parameters.






I suggest using the service-delimiter or service-delimiting tag concept to refer to the VLAN/QinQ tag on the ES, while other "ethernet tag" which can't appear in the packets received on the ES can still be called "Ethernet Tag ID". The service-delimiter concept is defined in RFC4762, which is also referred by rfc7432bis.


In such case, for DF election, we can say that the V used in modulo function is the service-delimiter or Ethernet Tag ID.






Thanks,


Yubao














原始邮件



发件人：JorgeRabadan(Nokia)
收件人：王玉保10045807;[e-mail];
抄送人：[e-mail];
日 期 ：2023年05月17日 04:55
主 题 ：Re: [bess] Discussion on modulo-based DF-Election of draft-ietf-bess-rfc7432bis-07




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