Hi Aijun, Just go three emails down. The answer to your question is ALREADY there !! I am copying it here just in case:
"The traffic of the bundle doesn’t make sense IMO for L2 traffic because L2 traffic is in context of <BD, EVI>. However, for L3 traffic (symmetric IRB), one can define bundle to mean EVI in which case the traffic for EVI (IP-VRF) is identified by MPLS label-2 or VNI-2 (from RT-2). " Ali From: Aijun Wang <[email protected]> Date: Sunday, September 7, 2025 at 11:29 PM To: Ali Sajassi (sajassi) <[email protected]>, 'Wei Wang' <[email protected]>, 'Jeffrey (Zhaohui) Zhang' <[email protected]>, 'Selvakumar Sivaraj' <[email protected]>, 'BESS' <[email protected]> Subject: RE: [bess] Re: VXLAN encapsulation question Hi, Ali: VNI-1 and VNI-2 in RFC 9135 are used to identify the MAC-VRF or IP-VRF, right? It is different from the scenario of VLAN-aware bundle service. Let’s make the question more straightforward: Can the bundle identifier and BD identifier coexist in the VxLAN encapsulation of “VLAN-aware bundle service”? If it can, where are them in the data plane? And please give the encapsulation example. Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Ali Sajassi (sajassi) Sent: Monday, September 8, 2025 1:12 PM To: Wei Wang <[email protected]>; Ali Sajassi (sajassi) <[email protected]>; Jeffrey (Zhaohui) Zhang <[email protected]>; Selvakumar Sivaraj <[email protected]>; Aijun Wang <[email protected]>; 'BESS' <[email protected]> Subject: [bess] Re: VXLAN encapsulation question Hi Wei, From: Wei Wang <[email protected]<mailto:[email protected]>> Date: Sunday, September 7, 2025 at 7:18 PM To: Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>>, Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>, Selvakumar Sivaraj <[email protected]<mailto:[email protected]>>, Aijun Wang <[email protected]<mailto:[email protected]>>, 'BESS' <[email protected]<mailto:[email protected]>> Subject: [bess] Re: VXLAN encapsulation question Hi Ali, As you said, "However, for L3 traffic (symmetric IRB), one can define bundle to mean EVI in which case the traffic for EVI (IP-VRF) is identified by MPLS label-2 or VNI-2 (from RT-2). " In the VXLAN encapsulation, where is VNI-2 placed? Ali> VNI-1 and VNI-2 are carried in label-1 & label-2 fields of RT-2 as described in RFC9135. Cheers, Ali Best Regards, Wei Original ________________________________ From: Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>> Date: 2025年9月4日 23:18 To: Wei Wang <[email protected]<mailto:[email protected]>>, Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>>, Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>, Selvakumar Sivaraj <[email protected]<mailto:[email protected]>>, Aijun Wang <[email protected]<mailto:[email protected]>>, 'BESS' <[email protected]<mailto:[email protected]>> Subject: [bess] Re: VXLAN encapsulation question Hi Wei, The traffic of the bundle doesn’t make sense IMO for L2 traffic because L2 traffic is in context of <BD, EVI>. However, for L3 traffic (symmetric IRB), one can define bundle to mean EVI in which case the traffic for EVI (IP-VRF) is identified by MPLS label-2 or VNI-2 (from RT-2). Cheers, Ali From: Wei Wang <[email protected]<mailto:[email protected]>> Date: Thursday, September 4, 2025 at 12:04 AM To: Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>>, Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>, Selvakumar Sivaraj <[email protected]<mailto:[email protected]>>, Aijun Wang <[email protected]<mailto:[email protected]>>, 'BESS' <[email protected]<mailto:[email protected]>> Subject: [bess] Re: VXLAN encapsulation question Hi Ali, As you said "In data-plane VNI always identifies a BD for both VLAN-aware bundle service, VLAN-based service, and VLAN bundle service." I'm curious about that if we wan to distinguish the traffic of a bundle on the data plane, how could we achieve it? Best Regards, Wei Original ________________________________ From: Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>> Date: 2025年9月4日 13:01 To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>, Selvakumar Sivaraj <[email protected]<mailto:[email protected]>>, Aijun Wang <[email protected]<mailto:[email protected]>>, 'BESS' <[email protected]<mailto:[email protected]>> Subject: [bess] Re: VXLAN encapsulation question Hi Jeffrey, Please see my comments inline ... From: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>> Date: Wednesday, September 3, 2025 at 12:20 PM To: Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>>, Selvakumar Sivaraj <[email protected]<mailto:[email protected]>>, Aijun Wang <[email protected]<mailto:[email protected]>>, 'BESS' <[email protected]<mailto:[email protected]>> Subject: RE: [bess] Re: VXLAN encapsulation question Hi Ali, Thanks for your clarification. Ali> You’re welcome Juniper Business Use Only From: Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>> Sent: Wednesday, September 3, 2025 12:54 PM To: Selvakumar Sivaraj <[email protected]<mailto:[email protected]>>; Aijun Wang <[email protected]<mailto:[email protected]>>; Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>; 'BESS' <[email protected]<mailto:[email protected]>> Subject: Re: [bess] Re: VXLAN encapsulation question [External Email. Be cautious of content] 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. Zzh> I forgot about the RFC7348 base; however, only the EVPN talks about those different service models, so if I want to match the encapsulation to the service models I want to get the answers from RFC8365 (which currently only provides partial answers). Ali> It is implicitly there but if we want to make it explicit, then we can simply change the sentence in section 5.1 from This mode of operation in [RFC7348<https://datatracker.ietf.org/doc/html/rfc7348>] maps to VLAN-Based Service in [RFC7432<https://datatracker.ietf.org/doc/html/rfc7432>], where a tenant VID gets mapped to an EVI. to: This mode of operation in [RFC7348<https://datatracker.ietf.org/doc/html/rfc7348>] can map to VLAN-Based Service or VLAN-Aware Bundle Service in [RFC7432<https://datatracker.ietf.org/doc/html/rfc7432>], where a tenant VID gets mapped to a BD. Section 5.1.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: Zzh> My question is not about what to use to identify the BT/BD (let’s forget about that one). I just want to get a simple and clear answer from the RFC whether/when the VLAN is included in the encapsulated frame. 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. Zzh> Section 5.1 is specifically about encapsulation, and it specifically mention vlan-based and vlan-bundle, so it is natural/important to include vlan-aware bundle as well. BTW – does the option of including the vlan tag (e.g. for passing .1P bits or avoiding tag removal/audition) apply to vlan-based as well? Ali> We can change the sentence in section 5.1 as I suggested above. And the option of carrying tag for .1p bits or avoiding tag/removal/addition also applies to VLAN-based service (but as previously mentioned and as it is stated in both RFC 7348 and RFC8365, the default mode is to strip it). Zzh> For the VLAN-Bundle service, the reason I have the question is that the text mentions “an *option* of including an inner VLAN tag in the encapsulated frame” – I wanted to confirm that for the VLAN-Bundle that is mandatory. Ali> The draft says “VxLAN provides an option of including inner VLAN tag …”, which means RFC7348 provides an option …. The option that is provided by RFC7348 MUST be used if we want to provide VLAN-bundle service. If you want to create an errata so that we can incorporate these clarifications, I am fine with it. Thanks for reviewing these documents and paying careful attention. Cheers, Ali 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. Zzh> I hope the above explains why I had these questions (again, please forget about issue how to identify the BT/BD). Zzh> Thanks. Zzh> Jeffrey Cheers, Ali From: Selvakumar Sivaraj <[email protected]<mailto:[email protected]>> Date: Monday, September 1, 2025 at 4:43 AM To: Aijun Wang <[email protected]<mailto:[email protected]>>, 'Jeffrey (Zhaohui) Zhang' <[email protected]<mailto:[email protected]>>, 'BESS' <[email protected]<mailto:[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]<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!HLiopGnAVNJstDNrf3QL0LvigYTp0pOKbQQ29koU6KZ9azStYREbdVDklnsJEMmG521a3MoBQMaewqipn62Q63Tb$<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]> [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]
