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

2025-08-01 Thread Ali Sajassi (sajassi) 
Hi Wei,

What you want to do is already supported by current RFCs and specifications.


  1.
Use EVPN-VPWS service to setup a PW identified by the access VNI to carry your 
VLANs traffic to your core PE. This PWs carries traffic for several VIDs and it 
is terminated on the core PE.
  2.
The core PE uses the concept of EVPN vES to map each VID to a different BD.
  3.
For encapsulation over the core network for VLAN-aware bundle service, you have 
two options: a) to use core-VNI+VID to identify the BD on the receiving core PE 
or b) to use core-VNI alone to identify the BD. In the latter case, each BD 
gets mapped to a core-VNI. The choice is up to the receiving PE and transparent 
to the transmitting PE!

Therefore, I don’t see any need for a new encapsulation and your proposal.

Cheers,
Ali

From: Wei Wang 
Date: Friday, August 1, 2025 at 12:50 AM
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 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

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

2025-08-01 Thread Wei Wang 
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) ___
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

[bess] 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) 
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 VxLAN VNI information in the normal 
VxLAN packet?



Best Regards



Aijun Wang

China Telecom









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



Sasha,

Thanks for your question as I couldn’t figure out what this draft was trying to 
do on my quick glance ☺



Aijun,

EVPN-VPWS (RFC8214) applies to both MPLS and VxLAN as described in the 
document. Furthermore, although RFC9784 is written with MPLS access network as 
an example, it can easily be applied to VxLAN access since a VPWS instance can 
be either per RFC8214.

So, in light of these two RFCs, are there anything that you want to do that is 
not covered by these two RFCs?



Cheers,

Ali







From: Aijun Wang mailto:[email protected]>>
Date: Thursday, July 24, 2025 at 10:54 AM
To: 'Alexander Vainshtein' 
mailto:[email protected]>>,
 [email protected]<mailto:[email protected]> mailto:[email protected]>>, 
[email protected]<mailto:draft-wang-bess-l3-accessible-evpn.

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

2025-07-30 Thread Wei Wang 
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) ___
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

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

2025-07-25 Thread Ali Sajassi (sajassi) 
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 VxLAN VNI information in the normal 
VxLAN packet?

Best Regards

Aijun Wang
China Telecom




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

Sasha,
Thanks for your question as I couldn’t figure out what this draft was trying to 
do on my quick glance ☺

Aijun,
EVPN-VPWS (RFC8214) applies to both MPLS and VxLAN as described in the 
document. Furthermore, although RFC9784 is written with MPLS access network as 
an example, it can easily be applied to VxLAN access since a VPWS instance can 
be either per RFC8214.
So, in light of these two RFCs, are there anything that you want to do that is 
not covered by these two RFCs?

Cheers,
Ali



From: Aijun Wang mailto:[email protected]>>
Date: Thursday, July 24, 2025 at 10:54 AM
To: 'Alexander Vainshtein' 
mailto:[email protected]>>,
 [email protected]<mailto:[email protected]> mailto:[email protected]>>, 
[email protected]<mailto:[email protected]>
 
mailto:[email protected]>>
Subject: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today
Hi, Sasha:

Using the concept of virtual segment in RFC 9784 to access the core EVPN 
service is similar with our proposal.
The difference is that in RFC 9784, the access network is one MPLS based 
network, the PW can be identified by the corresponding MPLS label.
But, in our proposal, the access network is one Layer 3 Native IP network, 
there is no MPLS deployed in the access network.

Then, some new solution (especially how to identify the logical session, how to 
transfer them via the control plane and how to encapsulate them in the VxLAN 
packet should be defined.

Does the above explanation address your concerns?
If so, we can add some procedure description for our proposal according to 
another expert’s comments.

Thanks!

Best Regards

Aijun Wang
China Telecom

From: [email protected]<mailto:[email protected]> 
mailto:[email protected]>> On Behalf 
Of Alexander Vainshtein
Sent: Thursday, July 24, 2025 5:48 PM
To: [email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>
Subject: [bess] My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today

Hi all,
Just to repeat my question/comment asked at the BESS WG session in Madrid today:

I have asked whether the authors considered using the PWs crossing the L3 
domains as Virtual Ethernet Segments as described in Section 1.3 of RFC 
9784<https://datatracker.ietf.org/doc/html/rfc9784#section-1.3>?

At the first glance, this could address all the problems with which this draft 
tries to cope.

Regards,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by othe

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

2025-07-25 Thread Aijun Wang 
Hi, Sasha:

 

The requirement is not PW communication, it is VxLAN based PW access to the 
EVPN backbone service.

As wei has presented in the BESS meeting, “classic” PW can’t meet the 
customer’s communication requirements.

 

We need Multipoint to multipoint communications, these “sites” are accessed via 
the “VxLAN based PW”, not the point to point communication. 

 

Aijun

 

From: [email protected]  On Behalf Of 
Alexander Vainshtein
Sent: Friday, July 25, 2025 10:58 AM
To: Ali Sajassi (sajassi) ; Aijun Wang 

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

 

Ali, Aijun and all,

I concur with Ali’s response.

 

I can also add that “classic” PWs can cross IP-only domains using MPLS in GRE 
transport tunnels (RFC 4023 <https://datatracker.ietf.org/doc/html/rfc4023> ). 
And nothing in 

>From my POV, this would address your problem just as well – without the need 
>for any new entities. 

I do not see any conceptual issue with using such PWs as Virtual Ethernet 
Segments as defined in RFC 9784.

 

My 2c,

Sasha

 

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

 

Sasha, 

Thanks for your question as I couldn’t figure out what this draft was trying to 
do on my quick glance ☺

 

Aijun,

EVPN-VPWS (RFC8214) applies to both MPLS and VxLAN as described in the 
document. Furthermore, although RFC9784 is written with MPLS access network as 
an example, it can easily be applied to VxLAN access since a VPWS instance can 
be either per RFC8214. 

So, in light of these two RFCs, are there anything that you want to do that is 
not covered by these two RFCs?

 

Cheers,

Ali

 

 

 

From: Aijun Wang mailto:[email protected]> >
Date: Thursday, July 24, 2025 at 10:54 AM
To: 'Alexander Vainshtein' mailto:[email protected]> >, [email protected] 
<mailto:[email protected]>  mailto:[email protected]> >, 
[email protected] 
<mailto:[email protected]>  
mailto:[email protected]> >
Subject: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Hi, Sasha:

 

Using the concept of virtual segment in RFC 9784 to access the core EVPN 
service is similar with our proposal.

The difference is that in RFC 9784, the access network is one MPLS based 
network, the PW can be identified by the corresponding MPLS label.

But, in our proposal, the access network is one Layer 3 Native IP network, 
there is no MPLS deployed in the access network.

 

Then, some new solution (especially how to identify the logical session, how to 
transfer them via the control plane and how to encapsulate them in the VxLAN 
packet should be defined.

 

Does the above explanation address your concerns?

If so, we can add some procedure description for our proposal according to 
another expert’s comments.

 

Thanks!

 

Best Regards

 

Aijun Wang

China Telecom

 

From: [email protected] <mailto:[email protected]>  
mailto:[email protected]> > On Behalf 
Of Alexander Vainshtein
Sent: Thursday, July 24, 2025 5:48 PM
To: [email protected] <mailto:[email protected]> ; 
[email protected] 
<mailto:[email protected]> 
Subject: [bess] My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today

 

Hi all,

Just to repeat my question/comment asked at the BESS WG session in Madrid today:

 

I have asked whether the authors considered using the PWs crossing the L3 
domains as Virtual Ethernet Segments as described in Section 1.3 of RFC 9784 
<https://datatracker.ietf.org/doc/html/rfc9784#section-1.3> ?

 

At the first glance, this could address all the problems with which this draft 
tries to cope.

 

Regards,

Sasha

 

 

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any

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

2025-07-25 Thread Alexander Vainshtein 
Ali, Aijun and all,
I concur with Ali’s response.

I can also add that “classic” PWs can cross IP-only domains using MPLS in GRE 
transport tunnels (RFC 4023<https://datatracker.ietf.org/doc/html/rfc4023>). 
And nothing in
From my POV, this would address your problem just as well – without the need 
for any new entities.
I do not see any conceptual issue with using such PWs as Virtual Ethernet 
Segments as defined in RFC 9784.

My 2c,
Sasha

From: Ali Sajassi (sajassi) 
Sent: Friday, July 25, 2025 2:10 AM
To: 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

Sasha,
Thanks for your question as I couldn’t figure out what this draft was trying to 
do on my quick glance ☺

Aijun,
EVPN-VPWS (RFC8214) applies to both MPLS and VxLAN as described in the 
document. Furthermore, although RFC9784 is written with MPLS access network as 
an example, it can easily be applied to VxLAN access since a VPWS instance can 
be either per RFC8214.
So, in light of these two RFCs, are there anything that you want to do that is 
not covered by these two RFCs?

Cheers,
Ali



From: Aijun Wang mailto:[email protected]>>
Date: Thursday, July 24, 2025 at 10:54 AM
To: 'Alexander Vainshtein' 
mailto:[email protected]>>,
 [email protected]<mailto:[email protected]> mailto:[email protected]>>, 
[email protected]<mailto:[email protected]>
 
mailto:[email protected]>>
Subject: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today
Hi, Sasha:

Using the concept of virtual segment in RFC 9784 to access the core EVPN 
service is similar with our proposal.
The difference is that in RFC 9784, the access network is one MPLS based 
network, the PW can be identified by the corresponding MPLS label.
But, in our proposal, the access network is one Layer 3 Native IP network, 
there is no MPLS deployed in the access network.

Then, some new solution (especially how to identify the logical session, how to 
transfer them via the control plane and how to encapsulate them in the VxLAN 
packet should be defined.

Does the above explanation address your concerns?
If so, we can add some procedure description for our proposal according to 
another expert’s comments.

Thanks!

Best Regards

Aijun Wang
China Telecom

From: [email protected]<mailto:[email protected]> 
mailto:[email protected]>> On Behalf 
Of Alexander Vainshtein
Sent: Thursday, July 24, 2025 5:48 PM
To: [email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>
Subject: [bess] My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today

Hi all,
Just to repeat my question/comment asked at the BESS WG session in Madrid today:

I have asked whether the authors considered using the PWs crossing the L3 
domains as Virtual Ethernet Segments as described in Section 1.3 of RFC 
9784<https://datatracker.ietf.org/doc/html/rfc9784#section-1.3>?

At the first glance, this could address all the problems with which this draft 
tries to cope.

Regards,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

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

2025-07-25 Thread Aijun Wang 
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?

 

Best Regards

 

Aijun Wang

China Telecom

 

 

 

 

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

 

Sasha, 

Thanks for your question as I couldn’t figure out what this draft was trying to 
do on my quick glance ☺

 

Aijun,

EVPN-VPWS (RFC8214) applies to both MPLS and VxLAN as described in the 
document. Furthermore, although RFC9784 is written with MPLS access network as 
an example, it can easily be applied to VxLAN access since a VPWS instance can 
be either per RFC8214. 

So, in light of these two RFCs, are there anything that you want to do that is 
not covered by these two RFCs?

 

Cheers,

Ali

 

 

 

From: Aijun Wang mailto:[email protected]> >
Date: Thursday, July 24, 2025 at 10:54 AM
To: 'Alexander Vainshtein' mailto:[email protected]> >, [email protected] 
<mailto:[email protected]>  mailto:[email protected]> >, 
[email protected] 
<mailto:[email protected]>  
mailto:[email protected]> >
Subject: [bess] Re: My question/comment about 
draft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today

Hi, Sasha:

 

Using the concept of virtual segment in RFC 9784 to access the core EVPN 
service is similar with our proposal.

The difference is that in RFC 9784, the access network is one MPLS based 
network, the PW can be identified by the corresponding MPLS label.

But, in our proposal, the access network is one Layer 3 Native IP network, 
there is no MPLS deployed in the access network.

 

Then, some new solution (especially how to identify the logical session, how to 
transfer them via the control plane and how to encapsulate them in the VxLAN 
packet should be defined.

 

Does the above explanation address your concerns?

If so, we can add some procedure description for our proposal according to 
another expert’s comments.

 

Thanks!

 

Best Regards

 

Aijun Wang

China Telecom

 

From: [email protected] <mailto:[email protected]>  
mailto:[email protected]> > On Behalf 
Of Alexander Vainshtein
Sent: Thursday, July 24, 2025 5:48 PM
To: [email protected] <mailto:[email protected]> ; 
[email protected] 
<mailto:[email protected]> 
Subject: [bess] My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today

 

Hi all,

Just to repeat my question/comment asked at the BESS WG session in Madrid today:

 

I have asked whether the authors considered using the PWs crossing the L3 
domains as Virtual Ethernet Segments as described in Section 1.3 of RFC 9784 
<https://datatracker.ietf.org/doc/html/rfc9784#section-1.3> ?

 

At the first glance, this could address all the problems with which this draft 
tries to cope.

 

Regards,

Sasha

 

 

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments. 

___
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

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

2025-07-24 Thread Ali Sajassi (sajassi) 
Sasha,
Thanks for your question as I couldn’t figure out what this draft was trying to 
do on my quick glance ☺

Aijun,
EVPN-VPWS (RFC8214) applies to both MPLS and VxLAN as described in the 
document. Furthermore, although RFC9784 is written with MPLS access network as 
an example, it can easily be applied to VxLAN access since a VPWS instance can 
be either per RFC8214.
So, in light of these two RFCs, are there anything that you want to do that is 
not covered by these two RFCs?

Cheers,
Ali



From: Aijun Wang 
Date: Thursday, July 24, 2025 at 10:54 AM
To: 'Alexander Vainshtein' , 
[email protected] , 
[email protected] 

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

Using the concept of virtual segment in RFC 9784 to access the core EVPN 
service is similar with our proposal.
The difference is that in RFC 9784, the access network is one MPLS based 
network, the PW can be identified by the corresponding MPLS label.
But, in our proposal, the access network is one Layer 3 Native IP network, 
there is no MPLS deployed in the access network.

Then, some new solution (especially how to identify the logical session, how to 
transfer them via the control plane and how to encapsulate them in the VxLAN 
packet should be defined.

Does the above explanation address your concerns?
If so, we can add some procedure description for our proposal according to 
another expert’s comments.

Thanks!

Best Regards

Aijun Wang
China Telecom

From: [email protected]  On Behalf Of 
Alexander Vainshtein
Sent: Thursday, July 24, 2025 5:48 PM
To: [email protected]; [email protected]
Subject: [bess] My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today

Hi all,
Just to repeat my question/comment asked at the BESS WG session in Madrid today:

I have asked whether the authors considered using the PWs crossing the L3 
domains as Virtual Ethernet Segments as described in Section 1.3 of RFC 
9784<https://datatracker.ietf.org/doc/html/rfc9784#section-1.3>?

At the first glance, this could address all the problems with which this draft 
tries to cope.

Regards,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

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

2025-07-24 Thread Aijun Wang 
Hi, Sasha:

 

Using the concept of virtual segment in RFC 9784 to access the core EVPN 
service is similar with our proposal.

The difference is that in RFC 9784, the access network is one MPLS based 
network, the PW can be identified by the corresponding MPLS label.

But, in our proposal, the access network is one Layer 3 Native IP network, 
there is no MPLS deployed in the access network.

 

Then, some new solution (especially how to identify the logical session, how to 
transfer them via the control plane and how to encapsulate them in the VxLAN 
packet should be defined.

 

Does the above explanation address your concerns?

If so, we can add some procedure description for our proposal according to 
another expert’s comments.

 

Thanks!

 

Best Regards

 

Aijun Wang

China Telecom

 

From: [email protected]  On Behalf Of 
Alexander Vainshtein
Sent: Thursday, July 24, 2025 5:48 PM
To: [email protected]; [email protected]
Subject: [bess] My question/comment about draft-wang-bess-l3-accessible-evpn-10 
at the BESS WG session today

 

Hi all,

Just to repeat my question/comment asked at the BESS WG session in Madrid today:

 

I have asked whether the authors considered using the PWs crossing the L3 
domains as Virtual Ethernet Segments as described in Section 1.3 of RFC 9784 
 ?

 

At the first glance, this could address all the problems with which this draft 
tries to cope.

 

Regards,

Sasha

 

 

Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments. 

___
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]