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

[Wei Wang]

Hi Ali,


After reading RFC8214, I think it is aim to propose a P2P communication 
solution by letting EVPN support VPWS. But for the senario shown in Figure 2 of 
https://datatracker.ietf.org/doc/draft-wang-bess-l3-accessible-evpn/, 
communication between multiple C-A (or C-B) may involve point-to-multipoint and 
multipoint-to-multipoint communication (Perhaps this poinit has not been 
clearly explained in the draft, and we will make modifications when updating 
it), which cannot be supported by EVPN-VPWS. 


Best Regards,
Wei
 原始邮件
 
   
发件人：Ali Sajassi (sajassi) mailto:forwardingalgori...@ietf.org] 代表 
Ali Sajassi (sajassi)
 发送时间: 2025年3月23日 12:52
 收件人: Aijun Wang https://www.rfc-editor.org/rfc/rfc8214.html#section-2.3):

 
Contrary to EVPN, in EVPN-VPWS this service interface maps to a
   VLAN-based service interface (defined in Section 2.1); thus, this 
service interface is not used in EVPN-VPWS.  In other words, if one tries 
to define data-plane and control-plane behavior for this service interface, one 
would realize that it is the same as that of the VLAN-based service.

 

So, there is no LSI aware bundle service now.

Should we define it then?

 

Aijun Wang

China Telecom

 

On Mar 21, 2025, at 10:30, 【外部账号】 Ali Sajassi (sajassi) 
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 ___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

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

[Jeffrey (Zhaohui) Zhang]

Aijun,

You did not answer my question. Is it that you want to avoid a mac lookup on 
the egress PE?

Also, can you elaborate “traffic isolation”?

Jeffrey



Juniper Business Use Only
From: Aijun Wang 
Sent: Thursday, March 20, 2025 10:01 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: Aijun Wang ; BESS ; 
draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan 

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

[External Email. Be cautious of content]

Hi, Jeffery:

Yes, they are related to the MAC lookup, which can assure the traffic isolation 
in LSI based/LSI bundle/LSI aware bundle environment.

The related forwarding plane extension and control plane extension are only 
necessary for LSI aware bundle environment——in this situation, the destination 
MAC of incoming traffic will be looked up within the specified LSI BD domain 
only.

If there is no LSI value(which is different from the VNI value of backbone 
EVPN) associated with the income traffic, the above aim cannot be accomplished.

Aijun Wang
China Telecom


On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang 
mailto:zzhang=40juniper@dmarc.ietf.org>>
 wrote:

Hi Aijun,

My quote of RFC7432 is in this context:

“If your intention is to avoid the MAC lookup on the egress PE (which the draft 
does not talk about)” …

Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will 
come back with more comments.

Jeffrey




Juniper Business Use Only
From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
BESS mailto:bess@ietf.org>>; 
draft-wang-bess-l3-accessible-e...@ietf.org<mailto:draft-wang-bess-l3-accessible-e...@ietf.org>;
 Jorge Rabadan mailto:jorge.raba...@nokia.com>>
Subject: Re: [bess] draft-wang-bess-l3-accessible-evpn

[External Email. Be cautious of content]

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<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7432.html*section-9.2.1__;Iw!!NEt6yMaO-gk!EVS8RAEKl0m4mLCuOqpNzbkMSq2HFrRlHCebswm9hv4cNcjVIUouszlapK9Cr_XiqJ9ekoWkbuol07Bc7idetStS$>
 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  combination.  This label

   assignment is referred to as a per  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  combination.  This label assignment is

   referred to as a per  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 
mailto:zzhang=40juniper@dmarc.ietf.org>>
 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 &qu

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

[Aijun Wang]

Hi, Jeffery:Yes, they are related to the MAC lookup, which can assure the traffic isolation in LSI based/LSI bundle/LSI aware bundle environment.The related forwarding plane extension and control plane extension are only necessary for LSI aware bundle environment——in this situation, the destination MAC of incoming traffic will be looked up within the specified LSI BD domain only.If there is no LSI value(which is different from the VNI value of backbone EVPN) associated with the income traffic, the above aim cannot be accomplished.Aijun WangChina TelecomOn Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang  wrote:









Hi Aijun,
 
My quote of RFC7432 is in this context:
 
“If your intention is to avoid the MAC lookup on
 the egress PE (which the draft does not talk about)” …
 
Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will come back with more comments.
 
Jeffrey
 
 


Juniper Business Use Only


From: Aijun
 Wang  
Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: Aijun Wang ; BESS ; draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan 
Subject: Re: [bess] draft-wang-bess-l3-accessible-evpn


 
[External Email. Be cautious of content]
 


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  combination.  This label
   assignment is referred to as a per  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  combination.  This label assignment is
   referred to as a per  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  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 la

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

[Ali Sajassi (sajassi)]

Hi Aijun,

As I was explaining to you at the mic, what you are trying to do already exists 
and it works better than your proposal! Here are a few points to explain it in 
a further details:


  1.  Your draft doesn’t explain what issues or gaps currently exist in 
existing EVPN RFCs/drafts, and instead jumps into a proposal of needing LSI 
field in VxLAN header.
  2.  None of the EVPN experts are clear about what you are trying to do 
(including myself) and that’s why the questions from Jeffrey and Jorge.
  3.  As I mentioned at the mic, my guess is that you are trying to backhaul 
traffic from CEs to PEs (per figure-2) and then map the traffic to different 
EVPN service interfaces on PEs. For that the existing VxLAN constructs as 
explained in both RFC 7348 and RFC 8365 do the jobs and nothing else is needed. 
Furthermore, because CE does VxLAN encapsulation, it is not a CE but rather a 
PE and that’s one of the reasons for confusion when reading your draft.
  4.  VxLAN encapsulation allows for VLAN ID to be carried after VxLAN header 
and as explained in RFC 8365, that can be used to provide VLAN bundle (or VLAN 
aware bundle) service.


So here why you don’t need any new field (LSI field) in VxLAN header for 
traffic backhauling over MAN and mapping them to EVPN service interfaces at the 
PEs (in figure-2).

  1.  If VLAN based service mapping is needed at the PE, the VNI itself is 
sufficient!
  2.  If VLAN bundle service mapping is needed, then you carry VLAN ID after 
the VxLAN header per RFC 8365 (inner VLAN ID)
  3.  If VLAN-aware bundle service mapping is needed, then you can either use 
VNI or inner VLAN ID

Why existing RFC7348 and RFC8365 are better than your proposal? That is because

i)when you need to provide (b) above, you don’t need to do 
any VLAN ID provisioning on PEs because they will be transparent to them. 
Whereas in your proposal you need to configure LSIs on PEs!

ii)   It doesn’t need a new field to do the job

iii) It doesn’t have any backward compatibility issues and 
interworking issues because it uses existing RFCs!

Cheers,
Ali

From: Aijun Wang 
Date: Thursday, March 20, 2025 at 8:02 AM
To: Jeffrey Zhang 
Cc: Aijun Wang , BESS , 
draft-wang-bess-l3-accessible-e...@ietf.org 
, Jorge Rabadan 

Subject: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi, Jeffery:

Yes, they are related to the MAC lookup, which can assure the traffic isolation 
in LSI based/LSI bundle/LSI aware bundle environment.

The related forwarding plane extension and control plane extension are only 
necessary for LSI aware bundle environment——in this situation, the destination 
MAC of incoming traffic will be looked up within the specified LSI BD domain 
only.

If there is no LSI value(which is different from the VNI value of backbone 
EVPN) associated with the income traffic, the above aim cannot be accomplished.

Aijun Wang
China Telecom


On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang 
 wrote:

Hi Aijun,

My quote of RFC7432 is in this context:

“If your intention is to avoid the MAC lookup on the egress PE (which the draft 
does not talk about)” …

Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will 
come back with more comments.

Jeffrey




Juniper Business Use Only
From: Aijun Wang 
Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: Aijun Wang ; BESS ; 
draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan 

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

[External Email. Be cautious of content]

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<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7432.html*section-9.2.1__;Iw!!NEt6yMaO-gk!EVS8RAEKl0m4mLCuOqpNzbkMSq2HFrRlHCebswm9hv4cNcjVIUouszlapK9Cr_XiqJ9ekoWkbuol07Bc7idetStS$>
 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  combination.  This label

   assignment is referred to as a per  label

   assignment.



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





As a

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

[Ali Sajassi (sajassi)]

Hi Aijun,

Please read the RFCs carefully before introducing your own interpretation! I 
basically quoted the last sentence of the paragraph for you and you started 
your reply with “No”!! Again, the last sentence says:

“In other words, if one tries to define data-plane and control-plane behavior 
for this service interface, one would realize that it is the same as that of 
the VLAN-based service.”
This means contrary to EVPN (multipoint service) where the control-plane and 
data-plane behaviors are different for the two interface types, in EVPN-VPWS 
(P2P service), they will be the same and thus the two maps to the same behavior 
and thus no need for VLAN-aware service interface for P2P EVPN-VPWS.

I am getting the impression that you keep persisting on your own point of view 
without taking my comments into account and without fully understanding the 
existing RFCs. If you still not clear on why that is, then I would recommend to 
talk to your hardware/switch vendors so that you fully understand the existing 
RFCs.

This is my last email on this topic as I believe I have exhausted explaining 
this topic.

Cheers,
Ali

From: Aijun Wang 
Date: Sunday, March 23, 2025 at 8:19 PM
To: Ali Sajassi (sajassi) 
Cc: 'Jeffrey Zhang' , 'BESS' , 
draft-wang-bess-l3-accessible-e...@ietf.org 
, 'Jorge Rabadan' 

Subject: 答复: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi, Ali:


No. The reason that they are same is because “Contrary to EVPN, in EVPN-VPWS 
this service interface maps to a VLAN-based service interface (defined in 
Section 2.1<https://www.rfc-editor.org/rfc/rfc8214.html#section-2.1>); thus, 
this service interface is not used in EVPN-VPWS. “.



That is to say, there is no requirements to define “VLAN-Aware Bundle Service 
Interface” for EVPN-VPWS.



And, one further question is, the EVPN-VPWS solution is to cross connect the 
VPWS, via the EVPN backbone-There is no need the MAC lookup at the 
disposition PE.  But for our mentioned scenario, it is not the VPWS like 
communicationsthe hosts located behind the different CEs needs to 
communicate with each other, via the MAC lookup on the egress PEs.


As discussed before, we need the LSI information to be encapsulated within the 
VxLAN header(or reuse the VLAN field of the original Ethernet frame) to 
identify the different BDs on the egress PE, to let the egress PE accomplish 
the right MAC lookup
The control plane needs also to extend to transfer the LSI information.

Or else, would you like to describe the control plane/forward plane procedures 
to accomplish the above aim, based on RFC 8214/RFC 9744?


Best Regards

Aijun Wang
China Telecom

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Ali 
Sajassi (sajassi)
发送时间: 2025年3月23日 12:52
收件人: Aijun Wang 
抄送: Aijun Wang ; Jeffrey Zhang 
; BESS ; 
draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan 

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

Hi Aijun,

If you read the last sentence of that paragraph carefully, it says that for 
EVPN-VPWS, control-plane and data-plane behavior are the same for vlan-based 
and vlan-aware bundle services. Thus no need to define the latter.

There are other paragraphs that explain this further …

   “In terms of route advertisement and MPLS label lookup behavior,
   EVPN-VPWS resembles the VLAN-aware bundle mode of 
[RFC7432<https://www.rfc-editor.org/rfc/rfc7432>] such that
   when a PE advertises a per-EVI Ethernet A-D route, the VPWS service
   instance serves as a 32-bit normalized Ethernet Tag ID.  The value of
   the MPLS label in this route represents both the EVI and the VPWS
   service instance, so that upon receiving an MPLS-encapsulated packet,
   the disposition PE can identify the egress AC from the MPLS label and
   subsequently perform any required tag translation.  For the EVPL
   service, the Ethernet frames transported over an MPLS/IP network
   SHOULD remain tagged with the originating VLAN ID (VID), and any VID
   translation MUST be performed at the disposition PE.  For the EPL
   service, the Ethernet frames are transported as is, and the tags
   are not altered.

   The MPLS label value in the Ethernet A-D route can be set to the
   Virtual Extensible LAN (VXLAN) Network Identifier (VNI) for VXLAN
   encapsulation as per [RFC7348<https://www.rfc-editor.org/rfc/rfc7348>], and 
this VNI will have a local scope
   per PE and may also be equal to the VPWS service instance identifier
   set in the Ethernet A-D route.  When using VXLAN encapsulation, the
   BGP Encapsulation extended community is included in the Ethernet A-D
   route as described in 
[EVPN-OVERLAY<https://www.rfc-editor.org/rfc/rfc8214.html#ref-EVPN-OVERLAY>].  
The VNI is like the MPLS label
   that will be set in the tunnel header used to tunnel Ethernet packets
   from all the service interface types defined in Section 
2<https://www.rfc-editor.org/rfc/rfc8214.html#section-2>.  

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

[Ali Sajassi (sajassi)]

Hi Aijun,

If you read the last sentence of that paragraph carefully, it says that for 
EVPN-VPWS, control-plane and data-plane behavior are the same for vlan-based 
and vlan-aware bundle services. Thus no need to define the latter.

There are other paragraphs that explain this further …

   “In terms of route advertisement and MPLS label lookup behavior,
   EVPN-VPWS resembles the VLAN-aware bundle mode of 
[RFC7432<https://www.rfc-editor.org/rfc/rfc7432>] such that
   when a PE advertises a per-EVI Ethernet A-D route, the VPWS service
   instance serves as a 32-bit normalized Ethernet Tag ID.  The value of
   the MPLS label in this route represents both the EVI and the VPWS
   service instance, so that upon receiving an MPLS-encapsulated packet,
   the disposition PE can identify the egress AC from the MPLS label and
   subsequently perform any required tag translation.  For the EVPL
   service, the Ethernet frames transported over an MPLS/IP network
   SHOULD remain tagged with the originating VLAN ID (VID), and any VID
   translation MUST be performed at the disposition PE.  For the EPL
   service, the Ethernet frames are transported as is, and the tags
   are not altered.

   The MPLS label value in the Ethernet A-D route can be set to the
   Virtual Extensible LAN (VXLAN) Network Identifier (VNI) for VXLAN
   encapsulation as per [RFC7348<https://www.rfc-editor.org/rfc/rfc7348>], and 
this VNI will have a local scope
   per PE and may also be equal to the VPWS service instance identifier
   set in the Ethernet A-D route.  When using VXLAN encapsulation, the
   BGP Encapsulation extended community is included in the Ethernet A-D
   route as described in 
[EVPN-OVERLAY<https://www.rfc-editor.org/rfc/rfc8214.html#ref-EVPN-OVERLAY>].  
The VNI is like the MPLS label
   that will be set in the tunnel header used to tunnel Ethernet packets
   from all the service interface types defined in Section 
2<https://www.rfc-editor.org/rfc/rfc8214.html#section-2>.  The
   EVPN-VPWS techniques defined in this document have no dependency on
   the tunneling technology.”


Cheers,
Ali

From: Aijun Wang 
Date: Friday, March 21, 2025 at 9:12 PM
To: Ali Sajassi (sajassi) 
Cc: Aijun Wang , Jeffrey Zhang 
, BESS , 
draft-wang-bess-l3-accessible-e...@ietf.org 
, Jorge Rabadan 

Subject: Re: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi, Ali:

I reviewed roughly RFC8214, and found the following 
description(https://www.rfc-editor.org/rfc/rfc8214.html#section-2.3):


Contrary to EVPN, in EVPN-VPWS this service interface maps to a

   VLAN-based service interface (defined in Section 
2.1<https://www.rfc-editor.org/rfc/rfc8214.html#section-2.1>); thus, this 
service interface is not used in EVPN-VPWS.  In other words, if one tries to 
define data-plane and control-plane behavior for this service interface, one 
would realize that it is the same as that of the VLAN-based service.

So, there is no LSI aware bundle service now.
Should we define it then?

Aijun Wang
China Telecom


On Mar 21, 2025, at 10:30, 【外部账号】 Ali Sajassi (sajassi)  
wrote:

Aijun,

Cool!, So in terms of encapsulation, you agree that we can use existing VxLAN 
encapsulation (with inner VID if needed). In terms of concept of backhauling 
traffic, RFC 8214 and RFC 9744 do cover the concept.

Cheers,
Ali

From: Aijun Wang 
Date: Thursday, March 20, 2025 at 4:32 PM
To: Ali Sajassi (sajassi) 
Cc: Aijun Wang , Jeffrey Zhang 
, BESS , 
draft-wang-bess-l3-accessible-e...@ietf.org 
, Jorge Rabadan 
, Ali Sajassi (sajassi) 
Subject: Re: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi, Ali:

I understand your proposal and think you understand also our aim after my 
presentation and offline discussions.

As I responded to Jorge, it’s reasonable to reuse the VLAN field within the 
Ethernet itself to transfer the LSI information. By doing so, we can avoid the 
extension of the VxLAN itself and may be more easier to be implemented.

We still think it’s necessary to define the LSI concept and 
configure/allocate/distribute it by the operator——the VLAN information that you 
mentioned on the CE, is located/configured under/behind the CE device, not the 
LSI(or VLAN for layer 2 aware bundle service) that is located between CE and PE.

And, maybe there is no VLAN allocation under/behind CE.


Aijun Wang
China Telecom

On Mar 21, 2025, at 05:51, Ali Sajassi (sajassi)  wrote:

Hi Aijun,

As I was explaining to you at the mic, what you are trying to do already exists 
and it works better than your proposal! Here are a few points to explain it in 
a further details:


  1.  Your draft doesn’t explain what issues or gaps currently exist in 
existing EVPN RFCs/drafts, and instead jumps into a proposal of needing LSI 
field in VxLAN header.
  2.  None of the EVPN experts are clear about what you are trying to do 
(including myself) and that’s why the questions from Jeffrey and Jorge.
  3.  As I mentioned at the mic, my guess is that you are trying to

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

[Aijun Wang]

Hi, Ali:I reviewed roughly RFC8214, and found the following description(https://www.rfc-editor.org/rfc/rfc8214.html#section-2.3):Contrary to EVPN, in EVPN-VPWS this service interface maps to a
   VLAN-based service interface (defined in Section 2.1); thus, this service interface is not used in EVPN-VPWS.  In other words, if one tries to define data-plane and control-plane behavior for this service interface, one would realize that it is the same as that of the VLAN-based service.
So, there is no LSI aware bundle service now.Should we define it then?Aijun WangChina TelecomOn Mar 21, 2025, at 10:30, 【外部账号】 Ali Sajassi (sajassi)  wrote:







Aijun, 
 
Cool!, So in terms of encapsulation, you agree that we can use existing VxLAN encapsulation (with inner VID if needed). In terms of concept of backhauling traffic, RFC 8214 and RFC 9744 do cover the concept.

 
Cheers,
Ali
 




From:
Aijun Wang 
Date: Thursday, March 20, 2025 at 4:32 PM
To: Ali Sajassi (sajassi) 
Cc: Aijun Wang , Jeffrey Zhang , BESS , draft-wang-bess-l3-accessible-e...@ietf.org , Jorge Rabadan ,
 Ali Sajassi (sajassi) 
Subject: Re: [bess] Re: draft-wang-bess-l3-accessible-evpn

Hi, Ali:

 


I understand your proposal and think you understand also our aim after my presentation and offline discussions.


 


As I responded to Jorge, it’s reasonable to reuse the VLAN field within the Ethernet itself to transfer the LSI information. By doing so, we can avoid the extension of the VxLAN itself and may be more easier to be implemented.


 


We still think it’s necessary to define the LSI concept and configure/allocate/distribute it by the operator——the VLAN information that you mentioned on the CE, is located/configured under/behind the CE device, not the LSI(or VLAN for layer
 2 aware bundle service) that is located between CE and PE.


 


And, maybe there is no VLAN allocation under/behind CE. 

 


 

Aijun Wang

China Telecom







On Mar 21, 2025, at 05:51, Ali Sajassi (sajassi)  wrote:




 


Hi Aijun,
 
As I was explaining to you at the mic, what you are trying to do already exists and it works better than your proposal! Here are a few points to explain it in a further details:
 

Your draft doesn’t explain what issues or gaps currently exist in existing EVPN RFCs/drafts, and instead jumps into a proposal of needing LSI field in
 VxLAN header.None of the EVPN experts are clear about what you are trying to do (including myself) and that’s why the questions from Jeffrey and Jorge.
As I mentioned at the mic, my guess is that you are trying to backhaul traffic from CEs to PEs (per figure-2) and then map the traffic to different EVPN
 service interfaces on PEs. For that the existing VxLAN constructs as explained in both RFC 7348 and RFC 8365 do the jobs and nothing else is needed. Furthermore, because CE does VxLAN encapsulation, it is not a CE but rather a PE and that’s one of the reasons
 for confusion when reading your draft.VxLAN encapsulation allows for VLAN ID to be carried after VxLAN header and as explained in RFC 8365, that can be used to provide VLAN bundle (or VLAN
 aware bundle) service. 
 
So here why you don’t need any new field (LSI field) in VxLAN header for traffic backhauling over MAN and mapping them to EVPN service interfaces at the PEs (in figure-2).


a. 
If VLAN based service mapping is needed at the PE, the VNI itself is sufficient!

b.
If VLAN bundle service mapping is needed, then you carry VLAN ID after the VxLAN header per RFC 8365 (inner VLAN ID)

c. 
If VLAN-aware bundle service mapping is needed, then you can either use VNI or inner VLAN ID
 
Why existing RFC7348 and RFC8365 are better than your proposal? That is because

when you need to provide (b) above, you don’t need to do any VLAN ID provisioning on PEs because they will be transparent to them. Whereas in your proposal
 you need to configure LSIs on PEs!
It doesn’t need a new field to do the job
It doesn’t have any backward compatibility issues and interworking issues because it uses existing RFCs!
 
Cheers,
Ali
 




From:
Aijun Wang 
Date: Thursday, March 20, 2025 at 8:02 AM
To: Jeffrey Zhang 
Cc: Aijun Wang , BESS , draft-wang-bess-l3-accessible-e...@ietf.org , Jorge Rabadan 
Subject: [bess] Re: draft-wang-bess-l3-accessible-evpn

Hi, Jeffery:

 


Yes, they are related to the MAC lookup, which can assure the traffic isolation in LSI based/LSI bundle/LSI aware bundle environment.


 


The related forwarding plane extension and control plane extension are only necessary for LSI aware bundle environment——in this situation, the destination MAC of incoming traffic will be looked up within the specified LSI BD domain only.


 


If there is no LSI value(which is different from the VNI value of backbone EVPN) associated with the income traffic, the above aim cannot be accomplished.



 

Aijun Wang

China Telecom



 

On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang  wrote:




 


Hi Aijun,
 
My quote of RFC7432 is in this context:
 
“If

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

[Jeffrey (Zhaohui) Zhang]

Hi Aijun,



Juniper Business Use Only
From: Aijun Wang 
Sent: Saturday, March 22, 2025 6:05 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: Aijun Wang ; BESS ; 
draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan 

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

[External Email. Be cautious of content]

Hi, Jeffery:

No.  We just want the MAC address lookup within the specific BD(identified by 
LSI)of one MAC-VRF on the egress PE.

Zzh> Good. In that case, your reply dated “Monday, March 17, 2025 7:06 AM” does 
not provide additional information to my email marked with “On Mar 17, 2025, at 
05:12” in this thread.

Zzh> Now that you mention mac address lookup is within the specific BD 
(identified by LSI), what’s the purpose of VNI field in the proposed header? 
That may be a moot point though.

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|S|R|R|I|R|R|R|R|D|R|R|A|R|R|R|  LSI  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  VXLAN Network Identifier (VNI)   |   Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The “traffic isolation” refers mainly that the source mac can only communicate 
with the destination mac within the same BD of the LSI, which is similar with 
the requirements of VLAN aware bundle service.

Zzh> Existing EVPN service already provide traffic isolation.

Zzh> An EVPN AC is always layer 2, whether it is physical connection all the 
way to the CE, or it is physical connection to a PW PE (and then PW towards the 
CE), or it is PW directly from the EVPN PE (your case), it does not matter.

Zzh> In summary, there is nothing new on the EVPN side, and my conclusion in 
the email marked with “On Mar 17, 2025, at 05:12” in this thread remains.
Zzh> Thanks.
Zzh> Jeffrey

Aijun Wang
China Telecom


Aijun Wang
China Telecom
On Mar 21, 2025, at 10:52, Jeffrey (Zhaohui) Zhang 
mailto:zzhang=40juniper@dmarc.ietf.org>>
 wrote:

Aijun,

You did not answer my question. Is it that you want to avoid a mac lookup on 
the egress PE?

Also, can you elaborate “traffic isolation”?

Jeffrey



Juniper Business Use Only
From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Thursday, March 20, 2025 10:01 PM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
BESS mailto:bess@ietf.org>>; 
draft-wang-bess-l3-accessible-e...@ietf.org<mailto:draft-wang-bess-l3-accessible-e...@ietf.org>;
 Jorge Rabadan mailto:jorge.raba...@nokia.com>>
Subject: Re: [bess] Re: draft-wang-bess-l3-accessible-evpn

[External Email. Be cautious of content]

Hi, Jeffery:

Yes, they are related to the MAC lookup, which can assure the traffic isolation 
in LSI based/LSI bundle/LSI aware bundle environment.

The related forwarding plane extension and control plane extension are only 
necessary for LSI aware bundle environment——in this situation, the destination 
MAC of incoming traffic will be looked up within the specified LSI BD domain 
only.

If there is no LSI value(which is different from the VNI value of backbone 
EVPN) associated with the income traffic, the above aim cannot be accomplished.

Aijun Wang
China Telecom


On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang 
mailto:zzhang=40juniper@dmarc.ietf.org>>
 wrote:

Hi Aijun,

My quote of RFC7432 is in this context:

“If your intention is to avoid the MAC lookup on the egress PE (which the draft 
does not talk about)” …

Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will 
come back with more comments.

Jeffrey




Juniper Business Use Only
From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>
Cc: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
BESS mailto:bess@ietf.org>>; 
draft-wang-bess-l3-accessible-e...@ietf.org<mailto:draft-wang-bess-l3-accessible-e...@ietf.org>;
 Jorge Rabadan mailto:jorge.raba...@nokia.com>>
Subject: Re: [bess] draft-wang-bess-l3-accessible-evpn

[External Email. Be cautious of content]

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<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7432.html*section-9.2.1__;Iw!!NEt6yMaO-gk!EVS8RAEKl0m4mLCuOqpNzbkMSq2HFrRlHCebswm9hv4cNcjVIUouszlapK9Cr_XiqJ9ekoWkbuol07Bc7idetStS$>
 is just the traditional layer 2 access EVPN services 

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

[Aijun Wang]

Hi, Jeffery:No.  We just want the MAC address lookup within the specific BD(identified by LSI)of one MAC-VRF on the egress PE.The “traffic isolation” refers mainly that the source mac can only communicate with the destination mac within the same BD of the LSI, which is similar with the requirements of VLAN aware bundle service.Aijun WangChina TelecomAijun WangChina TelecomOn Mar 21, 2025, at 10:52, Jeffrey (Zhaohui) Zhang  wrote:









Aijun,
 
You did not answer my question. Is it that you want to avoid a mac lookup on the egress PE?
 
Also, can you elaborate “traffic isolation”?
 
Jeffrey
 


Juniper Business Use Only


From: Aijun
 Wang  
Sent: Thursday, March 20, 2025 10:01 PM
To: Jeffrey (Zhaohui) Zhang 
Cc: Aijun Wang ; BESS ; draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan 
Subject: Re: [bess] Re: draft-wang-bess-l3-accessible-evpn


 
[External Email. Be cautious of content]
 

Hi, Jeffery:


 


Yes, they are related to the MAC lookup, which can assure the traffic isolation in LSI based/LSI bundle/LSI aware bundle environment.


 


The related forwarding plane extension and control plane extension are only necessary for LSI aware bundle environment——in this situation, the destination MAC of incoming traffic will
 be looked up within the specified LSI BD domain only.


 


If there is no LSI value(which is different from the VNI value of backbone EVPN) associated with the income traffic, the above aim cannot be accomplished.



 

Aijun Wang


China Telecom







On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang <zzhang=40juniper@dmarc.ietf.org> wrote:






Hi Aijun,
 
My quote of RFC7432 is in this context:
 
“If your intention is to avoid the MAC lookup on the egress PE (which the draft does not talk about)” …
 
Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will come back with more comments.
 
Jeffrey
 
 

 
Juniper Business Use Only

From:
 Aijun Wang <wangai...@tsinghua.org.cn>

Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>
Cc: Aijun Wang <wangai...@tsinghua.org.cn>; BESS <bess@ietf.org>;
draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan <jorge.raba...@nokia.com>
Subject: Re: [bess] draft-wang-bess-l3-accessible-evpn


 
[External Email. Be cautious of content]
 


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  combination.  This label
   assignment is referred to as a per  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  combination.  This label assignment is
   referred to as a per  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=40juniper@dmarc.ietf.org> 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 

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

[Ali Sajassi (sajassi)]

Aijun,

Cool!, So in terms of encapsulation, you agree that we can use existing VxLAN 
encapsulation (with inner VID if needed). In terms of concept of backhauling 
traffic, RFC 8214 and RFC 9744 do cover the concept.

Cheers,
Ali

From: Aijun Wang 
Date: Thursday, March 20, 2025 at 4:32 PM
To: Ali Sajassi (sajassi) 
Cc: Aijun Wang , Jeffrey Zhang 
, BESS , 
draft-wang-bess-l3-accessible-e...@ietf.org 
, Jorge Rabadan 
, Ali Sajassi (sajassi) 
Subject: Re: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi, Ali:

I understand your proposal and think you understand also our aim after my 
presentation and offline discussions.

As I responded to Jorge, it’s reasonable to reuse the VLAN field within the 
Ethernet itself to transfer the LSI information. By doing so, we can avoid the 
extension of the VxLAN itself and may be more easier to be implemented.

We still think it’s necessary to define the LSI concept and 
configure/allocate/distribute it by the operator——the VLAN information that you 
mentioned on the CE, is located/configured under/behind the CE device, not the 
LSI(or VLAN for layer 2 aware bundle service) that is located between CE and PE.

And, maybe there is no VLAN allocation under/behind CE.


Aijun Wang
China Telecom


On Mar 21, 2025, at 05:51, Ali Sajassi (sajassi)  wrote:

Hi Aijun,

As I was explaining to you at the mic, what you are trying to do already exists 
and it works better than your proposal! Here are a few points to explain it in 
a further details:


  1.  Your draft doesn’t explain what issues or gaps currently exist in 
existing EVPN RFCs/drafts, and instead jumps into a proposal of needing LSI 
field in VxLAN header.
  2.  None of the EVPN experts are clear about what you are trying to do 
(including myself) and that’s why the questions from Jeffrey and Jorge.
  3.  As I mentioned at the mic, my guess is that you are trying to backhaul 
traffic from CEs to PEs (per figure-2) and then map the traffic to different 
EVPN service interfaces on PEs. For that the existing VxLAN constructs as 
explained in both RFC 7348 and RFC 8365 do the jobs and nothing else is needed. 
Furthermore, because CE does VxLAN encapsulation, it is not a CE but rather a 
PE and that’s one of the reasons for confusion when reading your draft.
  4.  VxLAN encapsulation allows for VLAN ID to be carried after VxLAN header 
and as explained in RFC 8365, that can be used to provide VLAN bundle (or VLAN 
aware bundle) service.


So here why you don’t need any new field (LSI field) in VxLAN header for 
traffic backhauling over MAN and mapping them to EVPN service interfaces at the 
PEs (in figure-2).

a.  If VLAN based service mapping is needed at the PE, the VNI itself is 
sufficient!

b. If VLAN bundle service mapping is needed, then you carry VLAN ID after 
the VxLAN header per RFC 8365 (inner VLAN ID)

c.  If VLAN-aware bundle service mapping is needed, then you can either use 
VNI or inner VLAN ID

Why existing RFC7348 and RFC8365 are better than your proposal? That is because

when you need to provide (b) above, you don’t need to do any VLAN ID 
provisioning on PEs because they will be transparent to them. Whereas in your 
proposal you need to configure LSIs on PEs!

It doesn’t need a new field to do the job

It doesn’t have any backward compatibility issues and interworking issues 
because it uses existing RFCs!

Cheers,
Ali

From: Aijun Wang 
Date: Thursday, March 20, 2025 at 8:02 AM
To: Jeffrey Zhang 
Cc: Aijun Wang , BESS , 
draft-wang-bess-l3-accessible-e...@ietf.org 
, Jorge Rabadan 

Subject: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi, Jeffery:

Yes, they are related to the MAC lookup, which can assure the traffic isolation 
in LSI based/LSI bundle/LSI aware bundle environment.

The related forwarding plane extension and control plane extension are only 
necessary for LSI aware bundle environment——in this situation, the destination 
MAC of incoming traffic will be looked up within the specified LSI BD domain 
only.

If there is no LSI value(which is different from the VNI value of backbone 
EVPN) associated with the income traffic, the above aim cannot be accomplished.

Aijun Wang
China Telecom

On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang 
 wrote:

Hi Aijun,

My quote of RFC7432 is in this context:

“If your intention is to avoid the MAC lookup on the egress PE (which the draft 
does not talk about)” …

Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will 
come back with more comments.

Jeffrey




Juniper Business Use Only
From: Aijun Wang 
Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: Aijun Wang ; BESS ; 
draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan 

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

[External Email. Be cautious of content]

Hi, Jeffery:

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

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

[Aijun Wang]

Hi, Ali:I understand your proposal and think you understand also our aim after my presentation and offline discussions.As I responded to Jorge, it’s reasonable to reuse the VLAN field within the Ethernet itself to transfer the LSI information. By doing so, we can avoid the extension of the VxLAN itself and may be more easier to be implemented.We still think it’s necessary to define the LSI concept and configure/allocate/distribute it by the operator——the VLAN information that you mentioned on the CE, is located/configured under/behind the CE device, not the LSI(or VLAN for layer 2 aware bundle service) that is located between CE and PE.And, maybe there is no VLAN allocation under/behind CE. Aijun WangChina TelecomOn Mar 21, 2025, at 05:51, Ali Sajassi (sajassi)  wrote:







Hi Aijun,
 
As I was explaining to you at the mic, what you are trying to do already exists and it works better than your proposal! Here are a few points to explain it in a further details:
 

Your draft doesn’t explain what issues or gaps currently exist in existing EVPN RFCs/drafts, and instead jumps into a proposal of needing LSI field in
 VxLAN header.None of the EVPN experts are clear about what you are trying to do (including myself) and that’s why the questions from Jeffrey and Jorge.
As I mentioned at the mic, my guess is that you are trying to backhaul traffic from CEs to PEs (per figure-2) and then map the traffic to different EVPN
 service interfaces on PEs. For that the existing VxLAN constructs as explained in both RFC 7348 and RFC 8365 do the jobs and nothing else is needed. Furthermore, because CE does VxLAN encapsulation, it is not a CE but rather a PE and that’s one of the reasons
 for confusion when reading your draft.VxLAN encapsulation allows for VLAN ID to be carried after VxLAN header and as explained in RFC 8365, that can be used to provide VLAN bundle (or VLAN
 aware bundle) service. 
 
So here why you don’t need any new field (LSI field) in VxLAN header for traffic backhauling over MAN and mapping them to EVPN service interfaces at the PEs (in figure-2).


If VLAN based service mapping is needed at the PE, the VNI itself is sufficient!If VLAN bundle service mapping is needed, then you carry VLAN ID after the VxLAN header per RFC 8365 (inner VLAN ID)If VLAN-aware bundle service mapping is needed, then you can either use VNI or inner VLAN ID
 
Why existing RFC7348 and RFC8365 are better than your proposal? That is because


i)   
when you need to provide (b) above, you don’t need to do any VLAN ID provisioning on PEs because they will be transparent to them. Whereas in your proposal you need to configure LSIs on PEs!

ii)  
It doesn’t need a new field to do the job

iii)
It doesn’t have any backward compatibility issues and interworking issues because it uses existing RFCs!
 
Cheers,
Ali
 




From:
Aijun Wang 
Date: Thursday, March 20, 2025 at 8:02 AM
To: Jeffrey Zhang 
Cc: Aijun Wang , BESS , draft-wang-bess-l3-accessible-e...@ietf.org , Jorge Rabadan 
Subject: [bess] Re: draft-wang-bess-l3-accessible-evpn

Hi, Jeffery:

 


Yes, they are related to the MAC lookup, which can assure the traffic isolation in LSI based/LSI bundle/LSI aware bundle environment.


 


The related forwarding plane extension and control plane extension are only necessary for LSI aware bundle environment——in this situation, the destination MAC of incoming traffic will be looked up within the specified LSI BD domain only.


 


If there is no LSI value(which is different from the VNI value of backbone EVPN) associated with the income traffic, the above aim cannot be accomplished.



 

Aijun Wang

China Telecom







On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang  wrote:




 


Hi Aijun,
 
My quote of RFC7432 is in this context:
 
“If your intention is to avoid the MAC lookup on the egress PE (which the draft does not talk about)” …
 
Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will come back with more comments.
 
Jeffrey
 
 

 
Juniper Business Use Only

From: Aijun Wang 

Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: Aijun Wang ; BESS ; draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan 
Subject: Re: [bess] draft-wang-bess-l3-accessible-evpn


 
[External Email. Be cautious of content]
 


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

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

[Aijun Wang]

Hi, Jorge:It’s possible to subdivide the VNI for backbone EVPN identifier to carry both the BD information and the common VNI part information.But it has the following drawbacks:1) Normally, the VNI within the packet is used to identify the MAC-VRF itself, and the LSI(for layer 3 accessible EVPN) or VLAN(for layer 2 accessible EVPN) is used to identify the BD within this MAC-VRF.2) If we subdivide the VNI, then the MAC within different BD domains is actually in different MAC-VRF(because the VNI is different). Then such mode is equivalent to the LSI based layer 3 accessible EVPN, not the LSI aware Bundle layer 3 accessible EVPN.3) When we compare it again with the VLAN aware Bundle service, we should notice the VLAN information is carried within the inner Ethernet packet itself.  But for LSI aware bundle service, there is no place to carry such information.Jeffery(and also Ali) recommended to reuse the VLAN field in the Ethernet packet itself to identify the LSI. I think it is more reasonable, but we need the PE device to do some map work autonomously at the ingress PE side, and the reverse map at egress PE side. This can also avoid the extension of VxLAN format itself and may be more easily forwarded within BESS WG(we needn’t coordinate with other WGs or ISE)If the above proposal is accepted, we will revise the document and ask the WG begin the adoption call. The control plane extension(define one new ESI type) is still necessary, but the forward plane extension can be removed(we should add the mapping process between LSI/VLAN that mentioned above).Thanks the discussions! I think we are converging more and more now.Aijun WangChina TelecomOn Mar 20, 2025, at 22:55, Jorge Rabadan (Nokia)  wrote:







Hi Aijun,
 
I didn’t have time to ask you this question at the BESS meeting yesterday:
 
My interpretation of the problem statement is that you need some extra bits in the vxlan header to identify the LSI, hence the BD in “LSI” aware bundle mode.
 
But could you not use some bits of the VNI itself and therefore have a solution that works without any extensions? The VNI is a 24-bit value. You could e.g., use 20bits (or X) for the
 common ID and 4bits (or Y) for the “LSI”. Then on the PE, if you have “LSI” aware bundle, you can use those 4 to differentiate each BD. The EVPN routes would be advertised with a different “Y” value for each BD.

 
In other words, if you need to provide such “structure” for the VXLAN identifier that yields the BD on the ingress lookup, why can't you do it with the existing VNI space? The VNI space
 gives you 16M values, is that not enough?
 
Thanks.
Jorge
 





From: Aijun Wang 
Date: Thursday, March 20, 2025 at 8:01 AM
To: Jeffrey Zhang 
Cc: Aijun Wang , BESS , draft-wang-bess-l3-accessible-e...@ietf.org , Jorge Rabadan (Nokia) 
Subject: Re: [bess] Re: draft-wang-bess-l3-accessible-evpn






 




CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.





 

Hi, Jeffery: 

 


Yes, they are related to the MAC lookup, which can assure the traffic isolation in LSI based/LSI bundle/LSI aware bundle environment.


 


The related forwarding plane extension and control plane extension are only necessary for LSI aware bundle environment——in this situation, the destination MAC of incoming traffic will be looked up within the specified
 LSI BD domain only.


 


If there is no LSI value(which is different from the VNI value of backbone EVPN) associated with the income traffic, the above aim cannot be accomplished.



 

Aijun Wang 

China Telecom








On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang  wrote:







Hi Aijun,
 
My quote of RFC7432 is in this context:
 
“If your intention is to avoid the MAC lookup on the egress PE (which the draft does not talk about)” …
 
Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will come back with more comments.
 
Jeffrey
 
 

 

Juniper Business Use Only

From: Aijun Wang 

Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: Aijun Wang ; BESS ; draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan 
Subject: Re: [bess] draft-wang-bess-l3-accessible-evpn


 

[External Email. Be cautious of content]
 


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

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

[Jorge Rabadan (Nokia)]

Hi Aijun,

I didn’t have time to ask you this question at the BESS meeting yesterday:

My interpretation of the problem statement is that you need some extra bits in 
the vxlan header to identify the LSI, hence the BD in “LSI” aware bundle mode.

But could you not use some bits of the VNI itself and therefore have a solution 
that works without any extensions? The VNI is a 24-bit value. You could e.g., 
use 20bits (or X) for the common ID and 4bits (or Y) for the “LSI”. Then on the 
PE, if you have “LSI” aware bundle, you can use those 4 to differentiate each 
BD. The EVPN routes would be advertised with a different “Y” value for each BD.

In other words, if you need to provide such “structure” for the VXLAN 
identifier that yields the BD on the ingress lookup, why can't you do it with 
the existing VNI space? The VNI space gives you 16M values, is that not enough?

Thanks.
Jorge

From: Aijun Wang 
Date: Thursday, March 20, 2025 at 8:01 AM
To: Jeffrey Zhang 
Cc: Aijun Wang , BESS , 
draft-wang-bess-l3-accessible-e...@ietf.org 
, Jorge Rabadan (Nokia) 

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

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi, Jeffery:

Yes, they are related to the MAC lookup, which can assure the traffic isolation 
in LSI based/LSI bundle/LSI aware bundle environment.

The related forwarding plane extension and control plane extension are only 
necessary for LSI aware bundle environment——in this situation, the destination 
MAC of incoming traffic will be looked up within the specified LSI BD domain 
only.

If there is no LSI value(which is different from the VNI value of backbone 
EVPN) associated with the income traffic, the above aim cannot be accomplished.

Aijun Wang
China Telecom


On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang 
 wrote:

Hi Aijun,

My quote of RFC7432 is in this context:

“If your intention is to avoid the MAC lookup on the egress PE (which the draft 
does not talk about)” …

Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will 
come back with more comments.

Jeffrey




Juniper Business Use Only
From: Aijun Wang 
Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: Aijun Wang ; BESS ; 
draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan 

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

[External Email. Be cautious of content]

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<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7432.html*section-9.2.1__;Iw!!NEt6yMaO-gk!EVS8RAEKl0m4mLCuOqpNzbkMSq2HFrRlHCebswm9hv4cNcjVIUouszlapK9Cr_XiqJ9ekoWkbuol07Bc7idetStS$>
 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  combination.  This label

   assignment is referred to as a per  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  combination.  This label assignment is

   referred to as a per  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 
mailto:zzhang=40juniper@dmarc.ietf.org>>
 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

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

[Jeffrey (Zhaohui) Zhang]

Hi Aijun,

My quote of RFC7432 is in this context:

“If your intention is to avoid the MAC lookup on the egress PE (which the draft 
does not talk about)” …

Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will 
come back with more comments.

Jeffrey




Juniper Business Use Only
From: Aijun Wang 
Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: Aijun Wang ; BESS ; 
draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan 

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

[External Email. Be cautious of content]

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  combination.  This label

   assignment is referred to as a per  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  combination.  This label assignment is

   referred to as a per  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 
mailto:zzhang=40juniper@dmarc.ietf.org>>
 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  combination.  This label
  assignment is referred to as a per  label
  assignment.  As a third option, a PE may advertise a unique EVPN
  label per  combination.  This label assignment is
  referred to as a per  label assignment.  As a
  fourth option, a PE may adver

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

[Aijun Wang]

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  combination.  This label
   assignment is referred to as a per  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  combination.  This label assignment is
   referred to as a per  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 
>  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  combination.  This label
>   assignment is referred to as a per  label
>   assignment.  As a third option, a PE may advertise a unique EVPN
>   label per  combination.  This label assignment is
>   referred to as a per  label assignment.  As a
>   fourth option, a PE may advertise a unique EVPN label per MAC
>   address.  This label assignment is referred to as
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org