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? <original-text> 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. </original-text> <updated-text> 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.* </updated-text> 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 <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. > > > > 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 <bess-boun...@ietf.org> *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/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. >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
