Hi Aijun, Please, see inline.
чт, 11 сент. 2025 г. в 04:13, Aijun Wang <[email protected]>: > Hi, Igor: > > > > *From:* Igor Malyushkin [mailto:[email protected]] > *Sent:* Wednesday, September 10, 2025 4:50 PM > *To:* Aijun Wang <[email protected]> > *Cc:* Wei Wang <[email protected]>; Ali Sajassi (sajassi) <sajassi= > [email protected]>; Jeffrey (Zhaohui) Zhang <[email protected]>; > Selvakumar Sivaraj <[email protected]>; BESS <[email protected]> > *Subject:* Re: [bess] Re: VXLAN encapsulation question > > > > 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? > > 【WAJ】Correct > [IM]: Personally, I don't think this goal lies in the EVPN space (with VxLAN or MPLS). Maybe it is better to consult your network vendor? There are many sophisticated HQoS implementations that are capable of aggregation of different internal entities (IFL groups, subscribers, etc.). > > 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". > > 【WAJ】The process that you described is in the control plane, which can > group the MACs in different BDs to one bundle(MAC-VRF). But it can’t > achieve the goal of HQoS fashion. > [IM]: No, I described the process that takes place in a data plane. If you offer a modification of the header to add there "a bundle identificator" thus you must do an extra lookup at a data plane for every packet to accommodate this ID. I'm trying to say that these changes in a hardware pipeline does not require the changes of the header itself and general EVPN machinery. You already have all necessary data at egress. > The reason that having many BDs in one bundle is to isolate the traffic > from different branches of one customer(EVPN backbone service customer). > [IM]: This goal is already achieved by the current implementation. Traffic among different BDs are isolated, so put a branch in its own BD to isolate it too. > Best Regards > > > > Aijun Wang > > China Telecom > > > > > > > > ср, 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]
