Hi, Igor: Hi Aijun,
Please, see inline. 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.
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.
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 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) <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? "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. Subject: [bess] Re: VXLAN encapsulation question |
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). " 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 Hi Wei, 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
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 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
Hi Jeffrey, Please see my comments inline ... Hi Ali, Thanks for your clarification. Ali> You’re welcome Juniper Business Use Only [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] maps to VLAN-Based Service in [RFC7432], where a tenant VID gets mapped to an EVI. to:
This mode of operation in [RFC7348] can map to VLAN-Based Service or VLAN-Aware Bundle Service in [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. - 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!
- 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 >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 [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$ 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] _______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
|
