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://datatracker.ietf.org/doc/draft-wang-bess-l3-accessible-evpn/ 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]
