Hi Sasha,
Thanks for your response. I agree, using a manually configured ID is the
best option when VID translation is performed at one or more ingress PEs
that are part of the multi-homed group to obtain a predictable default DF
election result..
That said, the current situation is, different vendors seem to use
different VIDs for DF election when VID translation is performed at the
ingress PE; some seem to use the translated VID and some even the BGP
router ID when the translation rule removes the tag entirely (making it
untagged) without proving a configurable ID..
How about adding some text to rfc7432bis section 6?
An Ethernet Tag ID is a 32-bit field containing either a 12-bit or
24-bit identifier that identifies a particular broadcast domain
(e.g., a VLAN) in an EVPN instance. The 12-bit identifier is called
the VLAN ID (VID). An EVPN instance consists of one or more
broadcast domains (one or more VLANs). VLANs are assigned to a given
EVPN instance by the provider of the EVPN service. A given VLAN can
itself be represented by multiple VIDs. In such cases, the PEs
participating in that VLAN for a given EVPN instance are responsible
for performing VLAN ID translation to/from locally attached CE
devices.
An Ethernet Tag ID is a 32-bit field containing either a 12-bit or
24-bit identifier that identifies a particular broadcast domain
(e.g., a VLAN) in an EVPN instance. The 12-bit identifier is called
the VLAN ID (VID). An EVPN instance consists of one or more
broadcast domains (one or more VLANs). VLANs are assigned to a given
EVPN instance by the provider of the EVPN service. A given VLAN can
itself be represented by multiple VIDs. In such cases, the PEs
participating in that VLAN for a given EVPN instance are responsible
for performing VLAN ID translation to/from locally attached CE
devices.
*If a PE performs VID translation of frames received from locally
attached CE (including removing all tags making it untagged), the PE
SHOULD provide a configurable ID for the EVPN instance for the purpose of
DF election.*
Regards,
Muthu
On Tue, Feb 15, 2022 at 6:53 PM Alexander Vainshtein <
alexander.vainsht...@rbbn.com> wrote:
> Muthu,
>
> Quoting from Section 3 of 7432bis
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-02#section-3>
> :
>
>
>
>Ethernet Tag: Used to represent a BD that is configured on a given
>
> ES for the purposes of DF election and 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.
>
>
>
> As I see it, using manually configured IDs can address your concerns.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> Email: alexander.vainsht...@rbbn.com
>
>
>
> *From:* BESS *On Behalf Of * Muthu Arul Mozhi
> Perumal
> *Sent:* Tuesday, February 15, 2022 1:23 PM
> *To:* bess@ietf.org
> *Subject:* [EXTERNAL] [bess] EVPN service carving with ingress VLAN
> translation
>
>
>
> Hi,
>
>
>
> Though rfc7432bis recommends VLAN translation to be performed at the
> disposition PE (for VLAN-based and VLAN-aware bundle services), I believe
> there are existing deployments where VLAN translation is performed at the
> ingress PE. In this scenario, is there any guideline on whether service
> carving is to be performed based on the original VLAN or translated VLAN?
>
>
>
> I think this cannot be left implementation specific, since DF election is
> a distributed algorithm and should yield the same result in all PEs that
> are part of the multi-homed group.
>
>
>
> Any feedback would be helpful..
>
>
>
> Regards,
>
> Muthu
>
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/or proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/
