Subject: [bess] EVPN service carving with ingress VLAN translation

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 15 Feb 2022 16:52:58 +0530

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 15 Feb 2022 13:22:55 +0000

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:   [email-masked]

From: BESS <[email-masked]> On Behalf Of Muthu Arul Mozhi Perumal
Sent: Tuesday, February 15, 2022 1:23 PM
To: [email-masked]
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.

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.

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 16 Feb 2022 15:52:14 +0530

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 <
[email-masked]> wrote:

> Muthu,
>
> Quoting from Section 3 of 7432bis
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-02#section-3>
> :
>
>
>
> *From:* BESS <[email-masked]> *On Behalf Of * Muthu Arul Mozhi
> Perumal
> *Sent:* Tuesday, February 15, 2022 1:23 PM
> *To:* [email-masked]
> *Subject:* [EXTERNAL] [bess] EVPN service carving with ingress VLAN
> translation
>
>
>
> Hi,
>
>
>
> 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.
>
>
>
> 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.
>