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

2025-08-07 Thread Aijun Wang
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 ; 'Wei Wang' ; 
'Alexander Vainshtein' ; [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 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 

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

2025-08-06 Thread Ali Sajassi (sajassi)
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 
Date: Tuesday, August 5, 2025 at 7:49 PM
To: Ali Sajassi (sajassi) , 'Wei Wang' 
, 'Alexander Vainshtein' 
, [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: [email protected] [mailto:[email protected]] On 
Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, August 5, 2025 2:15 AM
To: Wei Wang ; Aijun Wang ; 
'Alexander Vainshtein' ; [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]>>
Date: Monday, August 4, 2025 at 1:31 AM
To: Ali Sajassi (sajassi) mailto:[email protected]>>, Aijun 
Wang mailto:[email protected]>>, 'Alexander 
Vainshtein' 
mailto:[email protected]>>, 
[email protected]<mailto:[email protected]> mailto:[email protected]>>, 
[email protected]<mailto:[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 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]>>
发件时间:2025年8月2日 02:17
收件人:Wei Wang mailto:[email protected]>>, Aijun Wang 
mailto:[email protected]>>, 'Alexander 
Vainshtein' 
mailto:[email protected]>>, 
[email protected]<mailto:[email protected]> mailto:[email protected]>>, 
[email protected]<mailto:[email protected]>
 
mailto:[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 ne

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

2025-08-05 Thread Aijun Wang
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: [email protected] [mailto:[email protected]] On 
Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, August 5, 2025 2:15 AM
To: Wei Wang ; Aijun Wang ; 
'Alexander Vainshtein' ; [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]> >
Date: Monday, August 4, 2025 at 1:31 AM
To: Ali Sajassi (sajassi) mailto:[email protected]> >, 
Aijun Wang mailto:[email protected]> >, 
'Alexander Vainshtein' mailto:[email protected]> >, [email protected] <mailto:[email protected]>  
mailto:[email protected]> >, 
[email protected] 
<mailto:[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 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]> >

发件时间:2025年8月2日 02:17

收件人:Wei Wang mailto:[email protected]> >, Aijun 
Wang mailto:[email protected]> >, 
'Alexander Vainshtein' mailto:[email protected]> >, [email protected] <mailto:[email protected]>  
mailto:[email protected]> >, 
[email protected] 
<mailto:[email protected]>  
mailto:[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]> >
Date: Friday, August 1, 2025 at 12:50 AM
To: Ali Sajassi (sajassi) mailto:[email protected]> >, 
Aijun Wang mailto:[email protected]> >, 
'Alexander Vainshtein' mailto:[email protected]> >, [email protected] <mailto:[email protected]>  
mailto:[email protected]> >, 
[email protected] 
<mailto:draft-wang-bess-l3-accessible-

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

2025-08-05 Thread Alexander Vainshtein
Dear sll,
I concur with Ali.

I do not see any reason for the solution described in his emails not addressing 
the problem described - without any need for new mechanisms.

My 2c
Sasha





Get Outlook for Android<https://aka.ms/AAb9ysg>


From: Ali Sajassi (sajassi) 
Sent: Monday, August 4, 2025 9:14:49 PM
To: Wei Wang ; Aijun Wang ; 
Alexander Vainshtein ; [email protected] 
; [email protected] 

Subject: [EXTERNAL] Re: [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 
Date: Monday, August 4, 2025 at 1:31 AM
To: Ali Sajassi (sajassi) , Aijun Wang 
, 'Alexander Vainshtein' 
, [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) 
发件时间:2025年8月2日 02:17
收件人:Wei Wang , Aijun Wang , 
'Alexander Vainshtein' , [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 
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 cri

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

2025-08-04 Thread Ali Sajassi (sajassi)
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 
Date: Monday, August 4, 2025 at 1:31 AM
To: Ali Sajassi (sajassi) , Aijun Wang 
, 'Alexander Vainshtein' 
, [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) 
发件时间:2025年8月2日 02:17
收件人:Wei Wang , Aijun Wang , 
'Alexander Vainshtein' , [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 
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, 202

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

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