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;draft-ietf-bess-rfc7432bis...@ietf.org;
抄送人:bess@ietf.org;
日 期 :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 <bess-boun...@ietf.org> on behalf of wang.yub...@zte.com.cn
<wang.yub...@zte.com.cn>
Date: Tuesday, May 16, 2023 at 11:43 AM
To: draft-ietf-bess-rfc7432bis...@ietf.org
<draft-ietf-bess-rfc7432bis...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess