Hi Aijun, пт, 12 сент. 2025 г. в 16:35, Aijun Wang <[email protected]>:
> Hi, Igor: > > On Sep 11, 2025, at 17:44, Igor Malyushkin <[email protected]> wrote: > > > 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.). > > > [WAJ] there is no HQOS implementation that based on the BD identifier and > also the bundle identifier in VxLAN environment. > [IM]: And how is it linked to VxLAN? What if we need to further aggregate entities? For instance, we want to unite traffic from different bundles into a single entity, let's name it a customer. In theory, it is possible to have lots of customers in a common EVPN VLAN-aware service. Do we need yet another ID in the header for this? Later we can introduce a customer group and so on... > >> 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. > > > [WAJ] The HQOS policy is not intended only at the egress PE. > [IM]: But in ingress we do not have VxLAN-encapsulated traffic, don't we? In this case, we already have many different options to apply HQoS that are already today. > 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. > > > [WAJ] Yes. I just want to explain “why having many BDs in one bundle”. We > are on the same page for the usage of BD. > > > >> > 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] > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
