Hi, Selvakumar:
>In all services, the bridge table is identified using the VNI But there is no identifier to identify the bundle in the data plane, for the "VLAN-aware bundle service". Then, it is difficult to apply QoS policy, or statistic purpose data collection in bundle mode. >explore double VxLAN encapsulation instead of protocol changes and custom modifications to VxLAN header? It is difficult to accomplish the aim via the double VxLAN encapsulation. The reason is that the VxLAN encapsulation should be end-to-end. When the PE1 receives the VxLAN encapsulation packet(CE1,PE1) that traverses the MAN from the CE1 device, it must first decapsulate it, and then encapsulate the original frame into one new VxLAN encapsulate packet(PE1,PE2) The proposal in https://datatracker.ietf.org/doc/draft-wang-bess-l3-accessible-evpn/ achieves actually the "double tagged" (one for bridge domain, one for bundle) purpose, but with only one VxLAN header. Best Regards Aijun Wang China Telecom From: Selvakumar Sivaraj [mailto:[email protected]] Sent: Monday, September 1, 2025 7:43 PM To: Aijun Wang <[email protected]>; 'Jeffrey (Zhaohui) Zhang' <[email protected]>; 'BESS' <[email protected]> Subject: Re: [bess] Re: VXLAN encapsulation question >1. What about vlan-aware bundle? Is the vlan tag included in the encapsulated frame? There is no text for that. >2. For vlan bundle service, is the vlan tag optional or mandated in the encapsulated frame? In the context of VLAN-aware and VLAN-based services, the VLAN tag is optional. A scenario where the VLAN tag is carried is when the .1P bits need to be preserved end to end. >We are also wondering how to implement the "VLAN-aware bundle service" in the data plane. Data plane sees no difference between the three service types w.r.to identifying the bridge domain. In all services, the bridge table is identified using the VNI. >for LSI bundle service. For the scenarios captured in the document, did you explore double VxLAN encapsulation instead of protocol changes and custom modifications to VxLAN header? VxLAN packets that are received CE traverses the MAN network and reaches PE which then encapsulates the received frame in VxLAN encapsulation and sends it to other PE''s. Receiving PE decapsulates the outer VxLAN header and forwards it to the CE. Thanks, Selvakumar Juniper Business Use Only From: Aijun Wang <[email protected] <mailto:[email protected]> > Date: Monday, September 1, 2025 at 12:27 To: 'Jeffrey (Zhaohui) Zhang' <[email protected] <mailto:[email protected]> >, 'BESS' <[email protected] <mailto:[email protected]> > Subject: [bess] Re: VXLAN encapsulation question [External Email. Be cautious of content] Hi, Jeffrey: There are several occurrences for "VLAN-aware bundle service" in RFC 8365, but they focus mainly on the control plane advertisements, not the encapsulation data plane. We are also wondering how to implement the "VLAN-aware bundle service" in the data plane. If there is none, should we consider to standardize it? This is also the reason of extension that is described in https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-bess -l3-accessible-evpn/__;!!NEt6yMaO-gk!HLiopGnAVNJstDNrf3QL0LvigYTp0pOKbQQ29ko U6KZ9azStYREbdVDklnsJEMmG521a3MoBQMaewqipn62Q63Tb$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-wang-bess -l3-accessible-evpn/__;!!NEt6yMaO-gk!HLiopGnAVNJstDNrf3QL0LvigYTp0pOKbQQ29ko U6KZ9azStYREbdVDklnsJEMmG521a3MoBQMaewqipn62Q63Tb$> for LSI bundle service. Aijun Wang China Telecom -----Original Message----- From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jeffrey (Zhaohui) Zhang Sent: Friday, August 29, 2025 4:58 AM To: 'BESS' <[email protected] <mailto:[email protected]> > Subject: [bess] VXLAN encapsulation question Hi, RFC8365 says: VXLAN encapsulation is based on UDP, with an 8-byte header following the UDP header. VXLAN provides a 24-bit VNI, which typically provides a one-to-one mapping to the tenant VID, as described in [RFC7348]. In this scenario, the ingress VTEP does not include an inner VLAN tag on the encapsulated frame, and the egress VTEP discards the frames with an inner VLAN tag. This mode of operation in [RFC7348] maps to VLAN-Based Service in [RFC7432], where a tenant VID gets mapped to an EVI. VXLAN also provides an option of including an inner VLAN tag in the encapsulated frame, if explicitly configured at the VTEP. This mode of operation can map to VLAN Bundle Service in [RFC7432] because all the tenant's tagged frames map to a single bridge table / MAC-VRF, and the inner VLAN tag is not used for lookup by the disposition PE when performing VXLAN decapsulation as described in Section 6 of [RFC7348]. I have two questions: 1. What about vlan-aware bundle? Is the vlan tag included in the encapsulated frame? There is no text for that. 2. For vlan bundle service, is the vlan tag optional or mandated in the encapsulated frame? I also wonder if "and the inner VLAN tag is not used for lookup by the disposition PE when performing VXLAN decapsulation as described in Section 6 of [RFC7348]" should be part of the reason (the text follows "because ..."), or the following text is better? ... This mode of operation can map to VLAN Bundle Service in [RFC7432] because all the tenant's tagged frames map to a single bridge table / MAC-VRF, *though* the inner VLAN tag is not used for lookup by the disposition PE when performing VXLAN decapsulation as described in Section 6 of [RFC7348]. i.e., s/and/though/ In fact, I wonder if "because" should also be changed to "where". Thanks. Jeffrey Juniper Business Use Only _______________________________________________ BESS mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ BESS mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
