Hi, Sasha:
Yes, I read these paragraphs carefully. Doesn’t it mean that the “VLAN” should be encapsulated within the Ethernet packet, to identify the BD, together with the VNI, that identifies the EVI? That’s to say, for “VLAN aware bundle” service, we need VLAN+VNI encapsulation. And, then, for “LSI aware bundle” service, we need LSI+VNI encapsulation, which the current VxLAN based EVPN doesn’t provide. Best Regards Aijun Wang China Telecom From: Alexander Vainshtein [mailto:[email protected]] Sent: Thursday, August 7, 2025 3:33 PM To: Aijun Wang <[email protected]> Cc: 'Ali Sajassi (sajassi)' <[email protected]>; [email protected]; [email protected]; 'Wei Wang' <[email protected]> Subject: RE: [EXTERNAL] RE: [bess] Re: My question/comment aboutdraft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today Importance: High Aijun, Quoting from Section 6.3 of 7432bis (the relevant text is highlighted): In the case where a single VLAN is represented by different VIDs on different CEs and thus VID translation is required, a normalized Ethernet Tag ID (VID) (i.e., a unique network-wide VID in context of the EVI) MUST be carried in the EVPN BGP routes. Furthermore, the advertising PE SHOULD advertise the MPLS Label in the Ethernet A-D per EVI and Inclusive Multicast routes and MPLS Label1 in the MAC/IP Advertisement routes representing both the Ethernet Tag ID and the EVI, so that upon receiving an MPLS-encapsulated packet, the advertising PE can identify the corresponding bridge table from the MPLS EVPN label and perform Ethernet Tag ID translation ONLY at the disposition PE -- i.e., the Ethernet frames transported over the MPLS/IP network MUST remain tagged with the originating VID, and VID translation is performed on the disposition PE. The Ethernet Tag ID in all EVPN routes MUST be set to the normalized Ethernet Tag ID assigned by the EVPN provider. In the text above “VLAN” is the synonym of a BD in an EVI. Hopefully these notes will be useful. Regards, Sasha From: Aijun Wang <[email protected] <mailto:[email protected]> > Sent: Thursday, August 7, 2025 10:15 AM To: 'Ali Sajassi (sajassi)' <[email protected] <mailto:[email protected]> >; 'Wei Wang' <[email protected] <mailto:[email protected]> >; Alexander Vainshtein <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: [EXTERNAL] RE: [bess] Re: My question/comment aboutdraft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today Hi, Ali and Sasha: if you use single VNI(this VNI is used to identify the EVPN instance, not the access circuit) to represent a BD, it is VLAN-Based Service, not VLAN-aware bundle service. Please note, for VLAN-Aware Bundle service, “an EVPN instance consists of multiple broadcast domains (e.g., multiple VLANs) with each VLAN having its own bridge table”. If you use only single VNI, how to differentiate the different BDs in the EVPN instance that identified by such VNI? Please gives the example that can detail the packet encapsulation schema in the VLAN-Aware Bundle service. Best Regards Aijun Wang China Telecom From: Ali Sajassi (sajassi) [mailto:[email protected]] Sent: Thursday, August 7, 2025 1:23 AM To: Aijun Wang <[email protected] <mailto:[email protected]> >; 'Wei Wang' <[email protected] <mailto:[email protected]> >; 'Alexander Vainshtein' <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: Re: [bess] Re: My question/comment aboutdraft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today Hi Aijun, No, VLAN-aware bundle service does NOT require the use of two identifiers in data-plane. Your assumption is incorrect, and you can simply use a single VNI to represent a BD in VLAN-aware bundle service as I mentioned in my previous emails. Cheers, Ali From: Aijun Wang < <mailto:[email protected]> [email protected]> Date: Tuesday, August 5, 2025 at 7:49 PM To: Ali Sajassi (sajassi) < <mailto:[email protected]> [email protected]>, 'Wei Wang' < <mailto:[email protected]> [email protected]>, 'Alexander Vainshtein' < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]> Subject: RE: [bess] Re: My question/comment aboutdraft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today Hi, Ali and Sasha: VLAN-aware bundle service Does require the use of the two identifiers: VLAN+VNI, right? That’s the reason that LSI-aware bundle requires also two identifier: Access VNI(aka LSI)+VNI. Please note here the Access VNI(aka LSI) is equivalent to “VLAN” in VLAN-aware bundle service. If there is no both VNI+LSI combination in the packet, there is no possibility to achieve the effect of the different BDs(identified by the LSI) within one EVPN instance(identified by the VNI in EVPN backbone). Best Regards Aijun Wang China Telecom From: <mailto:[email protected]> [email protected] [ <mailto:[email protected]> mailto:[email protected]] On Behalf Of Ali Sajassi (sajassi) Sent: Tuesday, August 5, 2025 2:15 AM To: Wei Wang < <mailto:[email protected]> [email protected]>; Aijun Wang < <mailto:[email protected]> [email protected]>; 'Alexander Vainshtein' < <mailto:[email protected]> [email protected]>; <mailto:[email protected]> [email protected]; <mailto:[email protected]> [email protected] Subject: [bess] Re: My question/comment aboutdraft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today Wei, As I mentioned before in my previous email, the implementation of VLAN-aware bundle service does NOT require the use of two identifiers (VNI + LSI in your lingo). When traffic is L2 forwarded, then a single L2-VNI can be used to identify the BD for VLAN-aware bundle service and when traffic is L3 forwarded, then a single L3-VNI can be used to identify the L3-VRF. WHY DO YOU WANT TO COMPLICATE IT AND USE BOTH VNI + LSI (in your lingo)? Cheers, Ali From: Wei Wang < <mailto:[email protected]> [email protected]> Date: Monday, August 4, 2025 at 1:31 AM To: Ali Sajassi (sajassi) < <mailto:[email protected]> [email protected]>, Aijun Wang < <mailto:[email protected]> [email protected]>, 'Alexander Vainshtein' < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]> Subject: Re: [bess] Re: My question/comment aboutdraft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today Hi Ali, Customer service segmentation is based on the Logical Access Identifier (LSI, i.e., access VNI) rather than the VLAN information in the original customer data. The main reasons are as follows: 1) The original customer data may not contain VLAN information. If this field is to be reused, it would be necessary to convert LSI/VNI to VLAN on the ingress PE side and then convert VLAN back to LSI/VNI on the egress PE side. Such conversions also require extensions in the control plane to transmit the corresponding relationship between LSI/VNI and VLAN. In addition, at the forwarding plane, the VLAN space is limited, making it unable to accommodate more branch customers under the same EVPN. 2) In our solution, service segmentation is based on branch sites within each metropolitan area network, rather than the VLAN information within the sites. Best Regards, Wei 原始邮件 _____ 发件人：Ali Sajassi (sajassi) < <mailto:[email protected]> [email protected]> 发件时间：2025年8月2日 02:17 收件人：Wei Wang < <mailto:[email protected]> [email protected]>, Aijun Wang < <mailto:[email protected]> [email protected]>, 'Alexander Vainshtein' < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]> 主题：Re: [bess] Re: My question/comment aboutdraft-wang-bess-l3-accessible-evpn-10 at the BESS WG session today 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 < <mailto:[email protected]> [email protected]> Date: Friday, August 1, 2025 at 12:50 AM To: Ali Sajassi (sajassi) < <mailto:[email protected]> [email protected]>, Aijun Wang < <mailto:[email protected]> [email protected]>, 'Alexander Vainshtein' < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[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) < <mailto:[email protected]> [email protected]> 发件时间：2025年8月1日 00:59 收件人：Wei Wang < <mailto:[email protected]> [email protected]>, Aijun Wang < <mailto:[email protected]> [email protected]>, 'Alexander Vainshtein' < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[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 < <mailto:[email protected]> [email protected]> Date: Wednesday, July 30, 2025 at 6:34 PM To: Ali Sajassi (sajassi) < <mailto:[email protected]> [email protected]>, Aijun Wang < <mailto:[email protected]> [email protected]>, 'Alexander Vainshtein' < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[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) < <mailto:[email protected]> [email protected]> 发件时间：2025年7月26日 01:03 收件人：Aijun Wang < <mailto:[email protected]> [email protected]>, 'Alexander Vainshtein' < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]>, <mailto:[email protected]> [email protected] < <mailto:[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 <[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: <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]> On Behalf Of Ali Sajassi (sajassi) Sent: Friday, July 25, 2025 1:10 AM To: Aijun Wang < <mailto:[email protected]> [email protected]>; 'Alexander Vainshtein' < <mailto:[email protected]> [email protected]>; <mailto:[email protected]> [email protected]; <mailto:[email protected]> [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: <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]> On Behalf Of Alexander Vainshtein Sent: Thursday, July 24, 2025 5:48 PM To: <mailto:[email protected]> [email protected]; <mailto:[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 <https://datatracker.ietf.org/doc/html/rfc9784#section-1.3> 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]
