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 <[email protected]>
Sent: Thursday, July 31, 2025 4:34 AM
To: Ali Sajassi (sajassi) <[email protected]>; Aijun Wang
<[email protected]>; Alexander Vainshtein
<[email protected]>; [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)
<[email protected]<mailto:[email protected]>>
发件时间：2025年7月26日 01:03
收件人：Aijun Wang <[email protected]<mailto:[email protected]>>,
'Alexander Vainshtein'
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<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 <[email protected]<mailto:[email protected]>>
Date: Friday, July 25, 2025 at 1:50 AM
To: Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>>,
'Alexander Vainshtein'
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<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?
Best Regards
Aijun Wang
China Telecom
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>> On Behalf
Of Ali Sajassi (sajassi)
Sent: Friday, July 25, 2025 1:10 AM
To: Aijun Wang <[email protected]<mailto:[email protected]>>;
'Alexander Vainshtein'
<[email protected]<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 <[email protected]<mailto:[email protected]>>
Date: Thursday, July 24, 2025 at 10:54 AM
To: 'Alexander Vainshtein'
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<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
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]>
<[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]
