Re: [bess] A doubt in the requirements pertaining to VLAN-aware service interface in draft-ietf-bess-rfc7432bis

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Sasha,

Thanks for your insightful comments. A few comments:


  1.  The text that you provided, gives further clarification to the existing text and thus I will incorporate it with some modifications as below:
“In the case where a single VLAN is represented by a single VID and
   thus no VID translation is required for the operational duration of
   that VLAN , an MPLS-encapsulated packet MUST
   carry that VID and the Ethernet Tag ID in all EVPN routes advertised for this BD
   MUST be set to that VID.  The advertising PE SHOULD advertise the MPLS Label in the
   Ethernet A-D per EVI and Inclusive Multicast routes and MPLS Label1
   in the MAC/IP Advertisement routes representing both the Ethernet Tag ID
   and the EVI but MAY advertise the labels representing ONLY the EVI.
   This decision is only a local matter by the advertising PE which
   is also the disposition PE) and doesn't affect any other PEs.”

  1.  For the use case that you provided where a single VLAN can be represented by multiple VIDs (although at the later time where the VLAN starts with a single VID and then additional VID is configured for the same VLAN), is more appropriate to the 2nd paragraph that you quoted below. Basically, if the operator knows that at some point, there will be multiple VIDs for a VLAN, then they should follow the 2nd para text.
  2.  I will clarify what normalized VID mean (i.e., a unique VID network wide in context of an EVI). Although this VID is not used explicitly in data plane, it is used implicitly because it identifies the BD and thus the bridge table for incoming packets at the ingress PE. Even though the tag translation is done at the egress PE.

Cheers,
Ali



From: Alexander Vainshtein <[e-mail]>
Date: Tuesday, November 29, 2022 at 2:18 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, Ron Sdayoor <[e-mail]>, Moti Morgenstern <[e-mail]>, Nitsan Dolev <[e-mail]>, Michael Gorokhovsky <[e-mail]>
Subject: A doubt in the requirements pertaining to VLAN-aware service interface in draft-ietf-bess-rfc7432bis
Hi all,
I have some doubts in the following requirement for Ethernet Tag ID in Section 6.3 of the 7432bis draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-05#section-6.3> (the problematic text is highlighted):


   In the case where a single VLAN is represented by a single VID and
   thus no VID translation is required, an MPLS-encapsulated packet MUST
   carry that VID.  The Ethernet Tag ID in all EVPN routes MUST be set
   to that VID.  The advertising PE MAY advertise the MPLS Label in the
   Ethernet A-D per EVI and MPLS Label1 in the MAC/IP Advertisement
   routes representing ONLY the EVI or representing both the Ethernet
   Tag ID and the EVI.  This decision is only a local matter by the
   advertising PE (which is also the disposition PE) and doesn't affect
   any other PEs.


   In the case where a single VLAN is represented by different VIDs on

   different CEs and thus VID translation is required, a normalized

   Ethernet Tag ID (VID) MUST be carried in the EVPN BGP routes.

   Furthermore, the advertising PE advertises the MPLS Label1 in the

   MAC/IP Advertisement route representing both the Ethernet Tag ID and

   the EVI, so that upon receiving an MPLS-encapsulated packet, the

   advertising PE can identify the corresponding bridge table from the

   MPLS EVPN label and perform Ethernet Tag ID translation ONLY at the

   disposition PE -- i.e., the Ethernet frames transported over the

   MPLS/IP network MUST remain tagged with the originating VID, and VID

   translation is performed on the disposition PE.  The Ethernet Tag ID

   in all EVPN routes MUST be set to the normal

First of all, please note that the quoted text does not mention Inclusive Multicast Ethernet Tag routes and the labels advertised in them at all.

My doubts are based on the following scenario:

  1.  Suppose that originally all the BDs in an EVI that implements VLAN-aware Bundle service interface has been has been created with the same per BD VID delimiting all the attachment circuits network-wide (in all the PEs). In accordance with the highlighted requirement, Ethernet Tag ID in all EVPN routes advertised for this BD has been set to the VID in question and at least some (may be all) the PEs have allocated only per-EVI labels for these routes.
  2.  Suppose further that a new attachment circuit delimited by a different single VID (and configured with egress VLAN translation) is now added to this BD in one of the PEs:
     *   The highlighted requirements are now applicable, and the EVPN Type 2 routes now must carry labels that represent both the Ethernet Tag ID and the EVI.
     *   This presumably means that all the previously advertised EVPN Type 2 routes for this BD MUST be withdrawn, and new ones – carrying labels that represent both the EVI and the specific BD – advertised. The same applies to EVPN Type 3 routes for the affected BD. My guess that this would result in a substantial traffic disruption at least for the affected BD – but most probably for all the BDs in this EVI.

Please note that if labels advertised in EVPN per EVI Type 1, Type 2 and Type 3 routes were always allocated to represent t6he {EVI, Ethernet Tag ID} pairs, the problem would not occur.

May I suggest replacing the problematic (for me) para with the new text as following (the changes vs. the current text are highlighted):

   In the case where a single VLAN is represented by a single VID and
   thus no VID translation is required, an MPLS-encapsulated packet MUST
   carry that VID.  The Ethernet Tag ID in all EVPN routes advertised for this BD
   MAY be set to that VID.  The advertising PE SHOULD advertise the MPLS Label in the
   Ethernet A-D per EVI and Inclusive Multicast routes and MPLS Label1
   in the MAC/IP Advertisement routes representing both the Ethernet Tag ID
   and the EVI but MAY advertise the labels representing ONLY the EVI.
   This decision is only a local matter by the advertising PE which
   is also the disposition PE) and doesn't affect any other PEs.

May I also suggest not to use the term "normalized Ethernet Tag" in the next para because:

  *   It is not actually defined anywhere
  *   It carries (from my POV) some data plane-related connotations while in fact it only is seen in the EVPN control plane entities and does not affect the data plane at all.

  1.

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha


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.