[bess] Re: draft-wang-bess-l3-accessible-evpn

[Aijun Wang <[e-mail]>]

Hi, Jeffery:

Thanks for your analysis.
Let’s try again to converge based on our current  mutual understandings.

First, the conclusion, the solution proposed in this document is necessary. 

Here is the reasoning: 
What you quoted at https://www.rfc-editor.org/rfc/rfc7432.html#section-9.2.1 is just the traditional layer 2 access EVPN services or one of our layer 3 accessible EVPN service(“LSI based EVPN services”), the protocol extensions proposed in draft-wang-bess-l3-accessible-evpn is mainly for “LSI Aware Bundle EVPN services”, which is not covered by the current RFC7432, or any other existing EVPN related services.

For example:

A PE may advertise the same single EVPN label for all MAC addresses
   in a given MAC-VRF.  This label assignment is referred to as a per
   MAC-VRF label assignment.  

—-The above description corresponds to “Layer 2 VLAN Bundled EVPN Service”


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.  

—-The above description corresponds to “Layer 2 VLAN Based EVPN Service”


As a third option, a PE may advertise a unique EVPN
   label per <ESI, Ethernet tag> combination.  This label assignment is
   referred to as a per <ESI, Ethernet tag> label assignment.  

—-The above description corresponds to “LSI Based EVPN Service”.

As a
   fourth option, a PE may advertise a unique EVPN label per MAC
   address.  This label assignment is referred to as a per MAC label
   assignment.  

—-The above description is just for some very specific situations, and is not in the scope of current “Layer 2 Access EVPN Service” or the corresponding newly proposed “Layer 3 accessible EVPN service” 


All of these label assignment methods have their
   trade-offs. 
 The choice of a particular label assignment methodology
   is purely local to the PE that originates the route


Aijun Wang
China Telecom


Aijun Wang
China Telecom
> On Mar 17, 2025, at 05:12, Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]> wrote:
> Hi Aijun,
> 
> Now that the -08 revision has been published, let me bring this discussion to the WG. The email thread has some details that help clarify the intended use case and why the proposed solution is not needed or not good.
> 
> The draft does not clearly state it, but based on our discussions below, the PE-CE connection is a PW that terminates into the EVPN PE. There are two previous points that I want to re-emphasize here. I'll then explain why your proposed solution is not needed in my view.
> 
> - There are already deployed solutions of PWs terminating into VPN service PEs, including EVPN, w/o any protocol extensions
> - On the EVPN side, there is no difference between "a PW terminates into a PW-PE, which then connects to EVPN PE via a physical L2 connection" and "a PW terminates into the EVPN PE directly"
> 
> Your solution requires the ingress EVPN PEs to put on the PW information that is used on the egress side. That is just unnecessary and not appropriate.
> 
> In the true L2 connection case, the MAC lookup on the egress PE leads to local forwarding information, including the outgoing AC and perhaps VID translation information.
> In the PW terminating into EVPN PE case, the same lookup leads to local forwarding information, including the PW information, which is *local* and should not be advertised other EVPN PEs for them to put into the VXLAN header.
> 
> If your intention is to avoid the MAC lookup on the egress PE (which the draft does not talk about), it is an orthogonal issue (nothing to do with PW terminating into EVPN PE) that is already solved. Per RFC7432:
> 
>   A PE may advertise the same single EVPN label for all MAC addresses
>   in a given MAC-VRF.  This label assignment is referred to as a per
>   MAC-VRF label assignment.  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.  As a third option, a PE may advertise a unique EVPN
>   label per <ESI, Ethernet tag> combination.  This label assignment is
>   referred to as a per <ESI, Ethernet tag> label assignment.  As a
>   fourth option, a PE may advertise a unique EVPN label per MAC
>   address.  This label assignment is referred to as