[bess] Re: [EXTERNAL] Re: Re: My question/comment about draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

2025-08-01 Thread Alexander Vainshtein 
Dear all,
The previous email was sent prematurely, my sincere apologies. Completing my 
response now inline below.

Get Outlook for Android


From: Alexander Vainshtein 
Sent: Friday, August 1, 2025 1:56:34 PM
To: Wei Wang ; 
[email protected] 

Cc: BESS ; Aijun Wang ; Ali Sajassi 
(sajassi) 
Subject: Re: [EXTERNAL] Re: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Dear Wei Wang,
Lots of thanks for your email and explains to me the Root Cause of your problem.

It seems that your implementation of VLAN-aware Bundle allocates labels (Core 
VNI) per MAC-VRF and uses received customer VLAN to identify specific BD in 
this MAC-VRF.

Another (and more generic) option is label allocation per (MAC-VRF, BD) pairs. 
Section 6.3 of 7432bis RECOMMENDS this option.
With such implementation yiu will not need carrying customer VLAN ,(or Access 
VNI,) across the core.

My 2c,
Sasha

Get Outlook for Android


From: Wei Wang 
Sent: Friday, August 1, 2025 10:49:56 AM
To: Ali Sajassi (sajassi) ; Aijun Wang 
; Alexander Vainshtein 
; [email protected] ; 
[email protected] 

Subject: [EXTERNAL] Re: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Hi Ali and Sasha,

Let’s use VLAN-aware bundle to clarify why we need both Access VNI (LSI) and 
Core VNI in one VxLAN header.

In traditional VLAN-aware bundle ([RFC7432]), multiple VIDs map to a single 
EVI. Isolation relies on VIDs (e.g., VID 10 vs. 20) to separate broadcast 
domains, even with overlapping MACs.

In our Layer 3 scenario (LSI-aware bundle, the L3 equivalent), VIDs are 
replaced by LSIs (Access VNIs) to retain that "broadcast domain ID" role, while 
the core EVI maps to a Core VNI.

If we only include Core VNI (no LSI), the core PE loses the LSI (like losing 
VID) and can’t distinguish traffic from overlapping MACs in shared Core 
VNI—breaking isolation, just as losing VID would in VLAN-aware bundle.

Since standard VxLAN has only one VNI field, we extend it to carry both: Core 
VNI (for EVI) and LSI (for "VID-like" isolation).

Best regards,
Wei


原始邮件

发件人：Ali Sajassi (sajassi) 
发件时间：2025年8月1日 00:59
收件人：Wei Wang , Aijun Wang , 
'Alexander Vainshtein' , [email protected] 
, [email protected] 

主题：[bess] Re: My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today

Wei,

You said: "the critical challenge lies in how to physically encapsulate both in 
a single VxLAN packet to ensure end-to-end traffic isolation and correct 
mapping in a Layer 3 access scenario, which is not addressed by existing 
specifications.”

Please elaborate - i.e., give detailed explanation and use cases as to why both 
VNI need to be encapsulated in the same VxLAN packet. PWs are only stretched 
over access network (and NOT core network) and are terminated onto service VRF. 
Therefore, they are not needed between VRFs over the core network!

Cheers,
Ali

From: Wei Wang 
Date: Wednesday, July 30, 2025 at 6:34 PM
To: Ali Sajassi (sajassi) , Aijun Wang 
, 'Alexander Vainshtein' 
, [email protected] , 
[email protected] 

Subject: Re: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Hi Ali,

Thanks for your perspective. While we agree that the access EVPN-VPWS VNI and 
backbone VxLAN VNI are logically independent in terms of their roles—similar to 
MPLS labels or Q-tags—the critical challenge lies in how to physically 
encapsulate both in a single VxLAN packet to ensure end-to-end traffic 
isolation and correct mapping in a Layer 3 access scenario, which is not 
addressed by existing specifications.

Our proposal addresses this by extending the VxLAN header with an "S" flag and 
a 16-bit LSI field. When the "S" flag is set, the LSI field carries the access 
PW VNI, while the original VNI field retains the backbone VNI—enabling both 
identifiers to coexist in one packet . This extension is precisely to bridge 
the gap between logical independence and practical encapsulation requirements 
in Layer 3 access scenarios.

Best Regards,
Wei

原始邮件

发件人：Ali Sajassi (sajassi) 
发件时间：2025年7月26日 01:03
收件人：Aijun Wang , 'Alexander Vainshtein' 
, [email protected] , 
[email protected] 

主题：[bess] Re: My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today


Hi Aiju,



The answer to your question is very easy. The access EVPN-VPWS VNI 
(representing a PW) is independent from the backbone EVPN VxLAN VNI 
representing ELAN, E-TREE, or IRB service just like the access MPLS label for 
PW is independent from backbone EVPN MPLS label representing ELAN,

[bess] Re: [EXTERNAL] Re: Re: My question/comment about draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

2025-08-01 Thread Alexander Vainshtein 
Dear Wei Wang,
Lots of thanks for your email and explains your problem

Get Outlook for Android


From: Wei Wang 
Sent: Friday, August 1, 2025 10:49:56 AM
To: Ali Sajassi (sajassi) ; Aijun Wang 
; Alexander Vainshtein 
; [email protected] ; 
[email protected] 

Subject: [EXTERNAL] Re: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Hi Ali and Sasha,

Let’s use VLAN-aware bundle to clarify why we need both Access VNI (LSI) and 
Core VNI in one VxLAN header.

In traditional VLAN-aware bundle ([RFC7432]), multiple VIDs map to a single 
EVI. Isolation relies on VIDs (e.g., VID 10 vs. 20) to separate broadcast 
domains, even with overlapping MACs.

In our Layer 3 scenario (LSI-aware bundle, the L3 equivalent), VIDs are 
replaced by LSIs (Access VNIs) to retain that "broadcast domain ID" role, while 
the core EVI maps to a Core VNI.

If we only include Core VNI (no LSI), the core PE loses the LSI (like losing 
VID) and can’t distinguish traffic from overlapping MACs in shared Core 
VNI—breaking isolation, just as losing VID would in VLAN-aware bundle.

Since standard VxLAN has only one VNI field, we extend it to carry both: Core 
VNI (for EVI) and LSI (for "VID-like" isolation).

Best regards,
Wei


原始邮件

发件人：Ali Sajassi (sajassi) 
发件时间：2025年8月1日 00:59
收件人：Wei Wang , Aijun Wang , 
'Alexander Vainshtein' , [email protected] 
, [email protected] 

主题：[bess] Re: My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today

Wei,

You said: "the critical challenge lies in how to physically encapsulate both in 
a single VxLAN packet to ensure end-to-end traffic isolation and correct 
mapping in a Layer 3 access scenario, which is not addressed by existing 
specifications.”

Please elaborate - i.e., give detailed explanation and use cases as to why both 
VNI need to be encapsulated in the same VxLAN packet. PWs are only stretched 
over access network (and NOT core network) and are terminated onto service VRF. 
Therefore, they are not needed between VRFs over the core network!

Cheers,
Ali

From: Wei Wang 
Date: Wednesday, July 30, 2025 at 6:34 PM
To: Ali Sajassi (sajassi) , Aijun Wang 
, 'Alexander Vainshtein' 
, [email protected] , 
[email protected] 

Subject: Re: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Hi Ali,

Thanks for your perspective. While we agree that the access EVPN-VPWS VNI and 
backbone VxLAN VNI are logically independent in terms of their roles—similar to 
MPLS labels or Q-tags—the critical challenge lies in how to physically 
encapsulate both in a single VxLAN packet to ensure end-to-end traffic 
isolation and correct mapping in a Layer 3 access scenario, which is not 
addressed by existing specifications.

Our proposal addresses this by extending the VxLAN header with an "S" flag and 
a 16-bit LSI field. When the "S" flag is set, the LSI field carries the access 
PW VNI, while the original VNI field retains the backbone VNI—enabling both 
identifiers to coexist in one packet . This extension is precisely to bridge 
the gap between logical independence and practical encapsulation requirements 
in Layer 3 access scenarios.

Best Regards,
Wei

原始邮件

发件人：Ali Sajassi (sajassi) 
发件时间：2025年7月26日 01:03
收件人：Aijun Wang , 'Alexander Vainshtein' 
, [email protected] , 
[email protected] 

主题：[bess] Re: My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today


Hi Aiju,



The answer to your question is very easy. The access EVPN-VPWS VNI 
(representing a PW) is independent from the backbone EVPN VxLAN VNI 
representing ELAN, E-TREE, or IRB service just like the access MPLS label for 
PW is independent from backbone EVPN MPLS label representing ELAN, E-TREE, or 
IRB service, just like Q-tag or Q-in-Q tag in the access is independent from 
VNI or MPLS label in the backbone.



You should keep in mind that VNI does NOT need to be global. It can be domain 
specific and even down-stream assigned!



Cheers,

Ali



From: Aijun Wang 
Date: Friday, July 25, 2025 at 1:50 AM
To: Ali Sajassi (sajassi) , 'Alexander Vainshtein' 
, [email protected] , 
[email protected] 

Subject: RE: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Hi, Ali:



It’s relatively easy to incorporate the MPLS based pseudowire into EVPN, as 
that described in RFC9784.

But, it is not easy to incorporate the VxLAN based PW into EVPN, although they 
are all VPWS.



draft-wang-bess-l3-accessible-evpn wants just to fit the gap.

Or else, would you like to tell us how to encapsulate the access PW VNI 
information, together with the backbone

[bess] Re: [EXTERNAL] Re: Re: My question/comment about draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

2025-07-31 Thread Ali Sajassi (sajassi) 

Hi Sasha,

I don’t think we need a short draft to just say that EVPN-VPWS can be used as 
virtual segment in 9784 because it is understood that EVPN-VPWS service is 
analogous to PWs but with MH capabilities as described in RFC8214 and it can be 
both VxLAN encapsulated and MPLS encapsulated - i.e., we don’t need to create a 
draft to explain trivial concepts.

Cheers,
Ali

From: Alexander Vainshtein 
Date: Wednesday, July 30, 2025 at 11:13 PM
To: Wei Wang 
Cc: Ali Sajassi (sajassi) , Aijun Wang 
, [email protected] , 
[email protected] 

Subject: RE: [EXTERNAL] Re: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Dear Wei Wang,
Could you please explain why encapsulating both the “Access VNI” and the “Core 
VNI” in the same VxLAN header is needed?

The concept of a PW acting as a virtual Ethernet Segment assumes that:

  1.  “The ingress core PE” attached to such a segment:
 *   Uses the “access PW encapsulation” (be it a label or an “access VNI”)  
to identify the local representation of the core EVI/BD that would handle this 
customer frame
 *   Terminates the PW encapsulation and ushers the resulting customer 
Ethernet frame for Layer 2 forwarding in the identified EVI/BD
  2.  The “egress core PW”
 *   Uses EVPN encapsulation of the received Ethernet frame to identify the 
local representation of the core EVI/BD that would handle this packet
 *   Terminates the EVPN  encapsulation and ushers the resulting customer 
Ethernet frame for Layer 2 forwarding in the identified EVI/BD. If it decides 
that it should be sent via a PW-based virtual Ethernet Segment, it pushes 
appropriate “access PW encapsulation” and forward it accordingly.

I.e., “access PW encapsulations (regardless of whether we are speaking about 
classic MPLS PW, MPLS-based EVPN-VPWS or VxLAN-based EVPN-VPWS) is only visible 
to the endpoints of the Access PE, while “core EVPN encapsulation” (again, 
regardless of whether it is implemented as EVPN-MPLS, EVPN-VxLAN or EVPN over 
SRv6) is only visible to the EVPN  PEs.

I would also like to mention that RFC 9784 does not explicitly mention the 
possibility of using EVPN-VPWS instances as virtual Ethernet Segments. This 
could worth a short draft.

Hopefully, these notes would be useful.

Regards,
Sasha

From: Wei Wang 
Sent: Thursday, July 31, 2025 4:34 AM
To: Ali Sajassi (sajassi) ; Aijun Wang 
; Alexander Vainshtein 
; [email protected]; 
[email protected]
Subject: [EXTERNAL] Re: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Hi Ali,

Thanks for your perspective. While we agree that the access EVPN-VPWS VNI and 
backbone VxLAN VNI are logically independent in terms of their roles—similar to 
MPLS labels or Q-tags—the critical challenge lies in how to physically 
encapsulate both in a single VxLAN packet to ensure end-to-end traffic 
isolation and correct mapping in a Layer 3 access scenario, which is not 
addressed by existing specifications.

Our proposal addresses this by extending the VxLAN header with an "S" flag and 
a 16-bit LSI field. When the "S" flag is set, the LSI field carries the access 
PW VNI, while the original VNI field retains the backbone VNI—enabling both 
identifiers to coexist in one packet . This extension is precisely to bridge 
the gap between logical independence and practical encapsulation requirements 
in Layer 3 access scenarios.

Best Regards,
Wei

原始邮件

发件人：Ali Sajassi (sajassi) 
mailto:[email protected]>>
发件时间：2025年7月26日 01:03
收件人：Aijun Wang mailto:[email protected]>>, 
'Alexander Vainshtein' 
mailto:[email protected]>>, 
[email protected] mailto:[email protected]>>, 
[email protected]
 
mailto:[email protected]>>
主题：[bess] Re: My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today


Hi Aiju,



The answer to your question is very easy. The access EVPN-VPWS VNI 
(representing a PW) is independent from the backbone EVPN VxLAN VNI 
representing ELAN, E-TREE, or IRB service just like the access MPLS label for 
PW is independent from backbone EVPN MPLS label representing ELAN, E-TREE, or 
IRB service, just like Q-tag or Q-in-Q tag in the access is independent from 
VNI or MPLS label in the backbone.



You should keep in mind that VNI does NOT need to be global. It can be domain 
specific and even down-stream assigned!



Cheers,

Ali



From: Aijun Wang mailto:[email protected]>>
Date: Friday, July 25, 2025 at 1:50 AM
To: Ali Sajassi (sajassi) mailto:[email protected]>>, 
'Alexander Vainshtein' 
mailto:[email protected]>>, 
[email protected] mailto:[email protected]>>, 
draft-wang-bess-l3-acces

[bess] Re: [EXTERNAL] Re: Re: My question/comment about draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

2025-07-30 Thread Alexander Vainshtein 
Dear Wei Wang,
Could you please explain why encapsulating both the “Access VNI” and the “Core 
VNI” in the same VxLAN header is needed?

The concept of a PW acting as a virtual Ethernet Segment assumes that:

  1.  “The ingress core PE” attached to such a segment:
 *   Uses the “access PW encapsulation” (be it a label or an “access VNI”)  
to identify the local representation of the core EVI/BD that would handle this 
customer frame
 *   Terminates the PW encapsulation and ushers the resulting customer 
Ethernet frame for Layer 2 forwarding in the identified EVI/BD
  2.  The “egress core PW”
 *   Uses EVPN encapsulation of the received Ethernet frame to identify the 
local representation of the core EVI/BD that would handle this packet
 *   Terminates the EVPN  encapsulation and ushers the resulting customer 
Ethernet frame for Layer 2 forwarding in the identified EVI/BD. If it decides 
that it should be sent via a PW-based virtual Ethernet Segment, it pushes 
appropriate “access PW encapsulation” and forward it accordingly.

I.e., “access PW encapsulations (regardless of whether we are speaking about 
classic MPLS PW, MPLS-based EVPN-VPWS or VxLAN-based EVPN-VPWS) is only visible 
to the endpoints of the Access PE, while “core EVPN encapsulation” (again, 
regardless of whether it is implemented as EVPN-MPLS, EVPN-VxLAN or EVPN over 
SRv6) is only visible to the EVPN  PEs.

I would also like to mention that RFC 9784 does not explicitly mention the 
possibility of using EVPN-VPWS instances as virtual Ethernet Segments. This 
could worth a short draft.

Hopefully, these notes would be useful.

Regards,
Sasha

From: Wei Wang 
Sent: Thursday, July 31, 2025 4:34 AM
To: Ali Sajassi (sajassi) ; Aijun Wang 
; Alexander Vainshtein 
; [email protected]; 
[email protected]
Subject: [EXTERNAL] Re: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Hi Ali,

Thanks for your perspective. While we agree that the access EVPN-VPWS VNI and 
backbone VxLAN VNI are logically independent in terms of their roles—similar to 
MPLS labels or Q-tags—the critical challenge lies in how to physically 
encapsulate both in a single VxLAN packet to ensure end-to-end traffic 
isolation and correct mapping in a Layer 3 access scenario, which is not 
addressed by existing specifications.

Our proposal addresses this by extending the VxLAN header with an "S" flag and 
a 16-bit LSI field. When the "S" flag is set, the LSI field carries the access 
PW VNI, while the original VNI field retains the backbone VNI—enabling both 
identifiers to coexist in one packet . This extension is precisely to bridge 
the gap between logical independence and practical encapsulation requirements 
in Layer 3 access scenarios.

Best Regards,
Wei

原始邮件

发件人：Ali Sajassi (sajassi) 
mailto:[email protected]>>
发件时间：2025年7月26日 01:03
收件人：Aijun Wang mailto:[email protected]>>, 
'Alexander Vainshtein' 
mailto:[email protected]>>, 
[email protected] mailto:[email protected]>>, 
[email protected]
 
mailto:[email protected]>>
主题：[bess] Re: My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today


Hi Aiju,



The answer to your question is very easy. The access EVPN-VPWS VNI 
(representing a PW) is independent from the backbone EVPN VxLAN VNI 
representing ELAN, E-TREE, or IRB service just like the access MPLS label for 
PW is independent from backbone EVPN MPLS label representing ELAN, E-TREE, or 
IRB service, just like Q-tag or Q-in-Q tag in the access is independent from 
VNI or MPLS label in the backbone.



You should keep in mind that VNI does NOT need to be global. It can be domain 
specific and even down-stream assigned!



Cheers,

Ali



From: Aijun Wang mailto:[email protected]>>
Date: Friday, July 25, 2025 at 1:50 AM
To: Ali Sajassi (sajassi) mailto:[email protected]>>, 
'Alexander Vainshtein' 
mailto:[email protected]>>, 
[email protected] mailto:[email protected]>>, 
[email protected]
 
mailto:[email protected]>>
Subject: RE: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Hi, Ali:



It’s relatively easy to incorporate the MPLS based pseudowire into EVPN, as 
that described in RFC9784.

But, it is not easy to incorporate the VxLAN based PW into EVPN, although they 
are all VPWS.



draft-wang-bess-l3-accessible-evpn wants just to fit the gap.

Or else, would you like to tell us how to encapsulate the access PW VNI 
information, together with the backbone VxLAN VNI information in the normal 
VxLAN packet?