Hi Jeffrey, RFC8365 was written to be consistent with RFC7348 because it is adding EVPN control plane to the VxLAN data plane defined by NVO3. So, if you look at RFC7348, it talks about inner VLAN tag handling and how it should NOT be sent unless configured otherwise.
Section 5.3 of RFC8365 describes how to construct EVPN BGP routes for VLAN-aware bundle service (3rd para). Using this section along with section 5.1 (VxLAN encapsulation), you will have your answer about VLAN-aware bundle service - i.e., data-plane encapsulation is like VLAN-based service similar to that of RFC7432. In data-plane VNI always identifies a BD for both VLAN-aware bundle service, VLAN-based service, and VLAN bundle service. The difference among them is in control plane route advertisement. So, to answer your questions specifically: 1. For VLAN-aware bundle service, VLAN tag is not included (by default) unless configured otherwise (for passing .1P bits transparently or avoiding tag removal/addition). Even when you include the tag, the tag is NOT used for forwarding. It is the VNI that identifies the BD! 2. For VLAN bundle service, as stated in the section 5.1 of RFC8365, the tag is included in the encapsulated frame but again it is NOT used for forwarding decision. The tag just gets passed transparently to the host per RFC7432 procedure. Frankly, I don’t see any issues with the existing specifications in the RFC8365. Can we wordsmith it a bit better? Sure, but it will be just wordsmithing. Cheers, Ali From: Selvakumar Sivaraj <[email protected]> Date: Monday, September 1, 2025 at 4:43 AM To: Aijun Wang <[email protected]>, 'Jeffrey (Zhaohui) Zhang' <[email protected]>, 'BESS' <[email protected]> Subject: [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]> Date: Monday, September 1, 2025 at 12:27 To: 'Jeffrey (Zhaohui) Zhang' <[email protected]>, 'BESS' <[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!HLiopGnAVNJstDNrf3QL0LvigYTp0pOKbQQ29koU6KZ9azStYREbdVDklnsJEMmG521a3MoBQMaewqipn62Q63Tb$ for LSI bundle service. Aijun Wang China Telecom -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jeffrey (Zhaohui) Zhang Sent: Friday, August 29, 2025 4:58 AM To: 'BESS' <[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] To unsubscribe send an email to [email protected] _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
