Hi Aijun, It looks to me you are trying to tie several BDs (their associated VxLAN traffic in a data plane) together to process traffic in a HQoS fashion, where a bundle is an upper layer and its BDs are lower (and IFLs of these BDs are the lowest hierarchy). Right?
At this moment, I don't understand why having many BDs, where each one is identified by at least one VNI, we cannot infer their "parent" bundle without having any extra ID in a data plane. Let's say, we have traffic from VNI X, this traffic belongs to BD X, all that you need is to lookup some internal ID of the DB X in "BD to bundle lookup table". ср, 10 сент. 2025 г. в 10:13, Aijun Wang <[email protected]>: > Hi, Igor (and also Jeffrey, John etc.): > > > > The “bundle” identifier in the data plane can associate the traffic from > relevant BDs(identified by the current encoded VNI) together. > > > > The example of “bundle” traffic, can be traffic that belong to one > customer, who buy the EVPN core service, and then provides the backbone > EVPN service(bundle service) to its branches on different sites, which is > isolated by the BD(bridge domain) identifier. > > > > Having such “bundle” identifier in the data plane, can certainly give the > operator the capabilities to apply the consistent traffic policy to the > customer, and also the ability to sample/monitor/guarantee the customer’s > traffic on network devices. > > Or else, the traffic from different BD, but belong to the same bundle, can > only be treated as from different customer, which will certainly complex > the operation of the network. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* Igor Malyushkin [mailto:[email protected]] > *Sent:* Tuesday, September 9, 2025 6:06 PM > *To:* Wei Wang <[email protected]> > *Cc:* Ali Sajassi (sajassi) <[email protected]>; Aijun > Wang <[email protected]>; Jeffrey (Zhaohui) Zhang < > [email protected]>; Selvakumar Sivaraj <[email protected]>; BESS < > [email protected]> > *Subject:* Re: [bess] Re: VXLAN encapsulation question > > > > Hi Wei, > > Are there any reasons to have a bundle entity in a data plane? If yes, > what does it actually give us from the forwarding p.o.v? I mean, for L2 > traffic in question we have a unique ID in every incoming packet (an > encoded VNI value in this case) which allows us to find either a bridge > table to make a MAC lookup or a specific IFL to pass traffic without any > lookup at all. Where does a bundle come into play? > > > > вт, 9 сент. 2025 г. в 04:22, Wei Wang <[email protected]>: > > Hi Ali, > > > > "The traffic of the bundle doesn’t make sense IMO for L2 traffic because > L2 traffic is in context of <BD, EVI>." > > Does the context of <BD, EVI> in control plane or data plane? > > We hope to obtain the information of BD and bundle in the same time in > data plane. > > > > Best Regards, > > Wei > > > > Original > ------------------------------ > > From: Ali Sajassi (sajassi) <[email protected]> > > Date: 2025年9月9日 05:44 > > To: Aijun Wang <[email protected]>, 'Wei Wang' < > [email protected]>, 'Jeffrey (Zhaohui) Zhang' <[email protected]>, > 'Selvakumar > Sivaraj' <[email protected]>, 'BESS' <[email protected]> > > Subject: [bess] Re: VXLAN encapsulation question > > > > 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) <sajassi= > [email protected]>; Jeffrey (Zhaohui) Zhang <zzhang= > [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]> > *Date: *Sunday, September 7, 2025 at 7:18 PM > *To: *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 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]> > > Date: 2025年9月4日 23:18 > > 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, > > > > 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]> > *Date: *Thursday, September 4, 2025 at 12:04 AM > *To: *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 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]> > > Date: 2025年9月4日 13:01 > > To: Jeffrey (Zhaohui) Zhang <[email protected]>, Selvakumar > Sivaraj <[email protected]>, Aijun Wang <[email protected]>, > 'BESS' <[email protected]> > > Subject: [bess] Re: VXLAN encapsulation question > > > > Hi Jeffrey, > > > > Please see my comments inline ... > > > > *From: *Jeffrey (Zhaohui) Zhang <[email protected]> > *Date: *Wednesday, September 3, 2025 at 12:20 PM > *To: *Ali Sajassi (sajassi) <[email protected]>, Selvakumar Sivaraj < > [email protected]>, Aijun Wang <[email protected]>, 'BESS' < > [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]> > *Sent:* Wednesday, September 3, 2025 12:54 PM > *To:* Selvakumar Sivaraj <[email protected]>; Aijun Wang < > [email protected]>; Jeffrey (Zhaohui) Zhang <[email protected]>; > 'BESS' <[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]> > *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$ > <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] > <[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] > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
