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?
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] 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
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$
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]
