Hi Ali,
After reading RFC8214, I think it is aim to propose a P2P communication
solution by letting EVPN support VPWS. But for the senario shown in Figure 2 of
https://datatracker.ietf.org/doc/draft-wang-bess-l3-accessible-evpn/,
communication between multiple C-A (or C-B) may involve point-to-multipoint and
multipoint-to-multipoint communication (Perhaps this poinit has not been
clearly explained in the draft, and we will make modifications when updating
it), which cannot be supported by EVPN-VPWS.
Best Regards,
Wei
原始邮件
发件人：Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org>
发件时间：2025年3月25日 00:27
收件人：Aijun Wang <wangai...@tsinghua.org.cn>
抄送：'Jeffrey Zhang' <zzh...@juniper.net>, 'BESS' <bess@ietf.org>,
draft-wang-bess-l3-accessible-e...@ietf.org
<draft-wang-bess-l3-accessible-e...@ietf.org>, 'Jorge Rabadan'
<jorge.raba...@nokia.com>
主题：[bess] Re: draft-wang-bess-l3-accessible-evpn
Hi Aijun,
Please read the RFCs carefully before introducing your own interpretation! I
basically quoted the last sentence of the paragraph for you and you started
your reply with “No”!! Again, the last sentence says:
“In other words, if one tries to define data-plane and control-plane behavior
for this service interface, one would realize that it is the same as that of
the VLAN-based service.”
This means contrary to EVPN (multipoint service) where the control-plane and
data-plane behaviors are different for the two interface types, in EVPN-VPWS
(P2P service), they will be the same and thus the two maps to the same
behavior and thus no need for VLAN-aware service interface for P2P EVPN-VPWS.
I am getting the impression that you keep persisting on your own point of view
without taking my comments into account and without fully understanding the
existing RFCs. If you still not clear on why that is, then I would recommend
to talk to your hardware/switch vendors so that you fully understand the
existing RFCs.
This is my last email on this topic as I believe I have exhausted explaining
this topic.
Cheers,
Ali
From: Aijun Wang <wangai...@tsinghua.org.cn>
Date: Sunday, March 23, 2025 at 8:19 PM
To: Ali Sajassi (sajassi) <saja...@cisco.com>
Cc: 'Jeffrey Zhang' <zzh...@juniper.net>, 'BESS' <bess@ietf.org>,
draft-wang-bess-l3-accessible-e...@ietf.org
<draft-wang-bess-l3-accessible-e...@ietf.org>, 'Jorge Rabadan'
<jorge.raba...@nokia.com>
Subject: 答复: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi, Ali:
No. The reason that they are same is because “Contrary to EVPN, in EVPN-VPWS
this service interface maps to a VLAN-based service interface (defined in
Section 2.1); thus, this service interface is not used in EVPN-VPWS. “.
That is to say, there is no requirements to define “VLAN-Aware Bundle Service
Interface” for EVPN-VPWS.
And, one further question is, the EVPN-VPWS solution is to cross connect the
VPWS, via the EVPN backbone-----There is no need the MAC lookup at the
disposition PE. But for our mentioned scenario, it is not the VPWS like
communications----the hosts located behind the different CEs needs to
communicate with each other, via the MAC lookup on the egress PEs.
As discussed before, we need the LSI information to be encapsulated within the
VxLAN header(or reuse the VLAN field of the original Ethernet frame) to
identify the different BDs on the egress PE, to let the egress PE accomplish
the right MAC lookup
The control plane needs also to extend to transfer the LSI information.
Or else, would you like to describe the control plane/forward plane procedures
to accomplish the above aim, based on RFC 8214/RFC 9744?
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表
Ali Sajassi (sajassi)
发送时间: 2025年3月23日 12:52
收件人: Aijun Wang <wangai...@tsinghua.org.cn>
抄送: Aijun Wang <wangai...@tsinghua.org.cn>; Jeffrey Zhang
<zzhang=40juniper....@dmarc.ietf.org>; BESS <bess@ietf.org>;
draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan
<jorge.raba...@nokia.com>
主题: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi Aijun,
If you read the last sentence of that paragraph carefully, it says that for
EVPN-VPWS, control-plane and data-plane behavior are the same for vlan-based
and vlan-aware bundle services. Thus no need to define the latter.
There are other paragraphs that explain this further …
“In terms of route advertisement and MPLS label lookup behavior,
EVPN-VPWS resembles the VLAN-aware bundle mode of [RFC7432] such
that
when a PE advertises a per-EVI Ethernet A-D route, the VPWS service
instance serves as a 32-bit normalized Ethernet Tag ID. The
value of
the MPLS label in this route represents both the EVI and the VPWS
service instance, so that upon receiving an MPLS-encapsulated
packet,
the disposition PE can identify the egress AC from the MPLS label
and
subsequently perform any required tag translation. For the
EVPL
service, the Ethernet frames transported over an MPLS/IP network
SHOULD remain tagged with the originating VLAN ID (VID), and any
VID
translation MUST be performed at the disposition PE. For the
EPL
service, the Ethernet frames are transported as is, and the tags
are not altered.
The MPLS label value in the Ethernet A-D route can be set to the
Virtual Extensible LAN (VXLAN) Network Identifier (VNI) for VXLAN
encapsulation as per [RFC7348], and this VNI will have a local
scope
per PE and may also be equal to the VPWS service instance
identifier
set in the Ethernet A-D route. When using VXLAN
encapsulation, the
BGP Encapsulation extended community is included in the Ethernet
A-D
route as described in [EVPN-OVERLAY]. The VNI is like the
MPLS label
that will be set in the tunnel header used to tunnel Ethernet
packets
from all the service interface types defined in Section 2.
The
EVPN-VPWS techniques defined in this document have no dependency on
the tunneling technology.”
Cheers,
Ali
From: Aijun Wang <wangai...@tsinghua.org.cn>
Date: Friday, March 21, 2025 at 9:12 PM
To: Ali Sajassi (sajassi) <saja...@cisco.com>
Cc: Aijun Wang <wangai...@tsinghua.org.cn>, Jeffrey Zhang
<zzhang=40juniper....@dmarc.ietf.org>, BESS <bess@ietf.org>,
draft-wang-bess-l3-accessible-e...@ietf.org <draft-wang-bess-l3-accessible-e...@ietf.org>,
Jorge Rabadan <jorge.raba...@nokia.com>
Subject: Re: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi, Ali:
I reviewed roughly RFC8214, and found the following
description(https://www.rfc-editor.org/rfc/rfc8214.html#section-2.3):
Contrary to EVPN, in EVPN-VPWS this service interface maps to a
VLAN-based service interface (defined in Section 2.1); thus, this
service interface is not used in EVPN-VPWS. In other words, if one tries
to define data-plane and control-plane behavior for this service interface, one
would realize that it is the same as that of the VLAN-based service.
So, there is no LSI aware bundle service now.
Should we define it then?
Aijun Wang
China Telecom
On Mar 21, 2025, at 10:30, 【外部账号】 Ali Sajassi (sajassi)
<saja...@cisco.com> wrote:
Aijun,
Cool!, So in terms of encapsulation, you agree that we can use existing VxLAN
encapsulation (with inner VID if needed). In terms of concept of backhauling
traffic, RFC 8214 and RFC 9744 do cover the concept.
Cheers,
Ali
From: Aijun Wang <wangai...@tsinghua.org.cn>
Date: Thursday, March 20, 2025 at 4:32 PM
To: Ali Sajassi (sajassi) <saja...@cisco.com>
Cc: Aijun Wang <wangai...@tsinghua.org.cn>, Jeffrey Zhang
<zzhang=40juniper....@dmarc.ietf.org>, BESS <bess@ietf.org>,
draft-wang-bess-l3-accessible-e...@ietf.org <draft-wang-bess-l3-accessible-e...@ietf.org>,
Jorge Rabadan <jorge.raba...@nokia.com>, Ali Sajassi (sajassi)
<saja...@cisco.com>
Subject: Re: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi, Ali:
I understand your proposal and think you understand also our aim after my
presentation and offline discussions.
As I responded to Jorge, it’s reasonable to reuse the VLAN field within the
Ethernet itself to transfer the LSI information. By doing so, we can avoid the
extension of the VxLAN itself and may be more easier to be implemented.
We still think it’s necessary to define the LSI concept and
configure/allocate/distribute it by the operator——the VLAN information that you
mentioned on the CE, is located/configured under/behind the CE device, not the
LSI(or VLAN for layer 2 aware bundle service) that is located between CE and PE.
And, maybe there is no VLAN allocation under/behind CE.
Aijun Wang
China Telecom
On Mar 21, 2025, at 05:51, Ali Sajassi (sajassi) <saja...@cisco.com> wrote:
Hi Aijun,
As I was explaining to you at the mic, what you are trying to do already exists
and it works better than your proposal! Here are a few points to explain it in
a further details:
Your draft doesn’t explain what issues or gaps currently exist in existing EVPN
RFCs/drafts, and instead jumps into a proposal of needing LSI field in VxLAN
header.
None of the EVPN experts are clear about what you are trying to do (including
myself) and that’s why the questions from Jeffrey and Jorge.
As I mentioned at the mic, my guess is that you are trying to backhaul traffic
from CEs to PEs (per figure-2) and then map the traffic to different EVPN
service interfaces on PEs. For that the existing VxLAN constructs as explained
in both RFC 7348 and RFC 8365 do the jobs and nothing else is needed.
Furthermore, because CE does VxLAN encapsulation, it is not a CE but rather a
PE and that’s one of the reasons for confusion when reading your draft.
VxLAN encapsulation allows for VLAN ID to be carried after VxLAN header and as
explained in RFC 8365, that can be used to provide VLAN bundle (or VLAN aware
bundle) service.
So here why you don’t need any new field (LSI field) in VxLAN header for
traffic backhauling over MAN and mapping them to EVPN service interfaces at the
PEs (in figure-2).
If VLAN based service mapping is needed at the PE, the VNI itself is sufficient!
If VLAN bundle service mapping is needed, then you carry VLAN ID after the
VxLAN header per RFC 8365 (inner VLAN ID)
If VLAN-aware bundle service mapping is needed, then you can either use VNI or
inner VLAN ID
Why existing RFC7348 and RFC8365 are better than your proposal? That is because
when you need to provide (b) above, you don’t need to do any VLAN ID
provisioning on PEs because they will be transparent to them. Whereas in your
proposal you need to configure LSIs on PEs!
It doesn’t need a new field to do the job
It doesn’t have any backward compatibility issues and interworking issues
because it uses existing RFCs!
Cheers,
Ali
From: Aijun Wang <wangai...@tsinghua.org.cn>
Date: Thursday, March 20, 2025 at 8:02 AM
To: Jeffrey Zhang <zzhang=40juniper....@dmarc.ietf.org>
Cc: Aijun Wang <wangai...@tsinghua.org.cn>, BESS <bess@ietf.org>,
draft-wang-bess-l3-accessible-e...@ietf.org <draft-wang-bess-l3-accessible-e...@ietf.org>,
Jorge Rabadan <jorge.raba...@nokia.com>
Subject: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi, Jeffery:
Yes, they are related to the MAC lookup, which can assure the traffic isolation
in LSI based/LSI bundle/LSI aware bundle environment.
The related forwarding plane extension and control plane extension are only
necessary for LSI aware bundle environment——in this situation, the destination
MAC of incoming traffic will be looked up within the specified LSI BD domain
only.
If there is no LSI value(which is different from the VNI value of backbone
EVPN) associated with the income traffic, the above aim cannot be accomplished.
Aijun Wang
China Telecom
On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang
<zzhang=40juniper....@dmarc.ietf.org> wrote:
Hi Aijun,
My quote of RFC7432 is in this context:
“If your intention is to avoid the MAC lookup on the egress PE (which the draft
does not talk about)” …
Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will
come back with more comments.
Jeffrey
Juniper Business Use Only
From: Aijun Wang <wangai...@tsinghua.org.cn>
Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>
Cc: Aijun Wang <wangai...@tsinghua.org.cn>; BESS <bess@ietf.org>;
draft-wang-bess-l3-accessible-e...@ietf.org; Jorge Rabadan
<jorge.raba...@nokia.com>
Subject: Re: [bess] draft-wang-bess-l3-accessible-evpn
[External Email. Be cautious of content]
Hi, Jeffery:
Thanks for your analysis.
Let’s try again to converge based on our current mutual understandings.
First, the conclusion, the solution proposed in this document is
necessary.
Here is the reasoning:
What you quoted at
https://www.rfc-editor.org/rfc/rfc7432.html#section-9.2.1 is just the
traditional layer 2 access EVPN services or one of our layer 3 accessible EVPN
service(“LSI based EVPN services”), the protocol extensions proposed in
draft-wang-bess-l3-accessible-evpn is mainly for “LSI Aware Bundle EVPN
services”, which is not covered by the current RFC7432, or any other existing
EVPN related services.
For example:
A PE may advertise the same single EVPN label for all MAC addresses
in a given MAC-VRF. This label assignment is referred to as
a per
MAC-VRF label assignment.
—-The above description corresponds to “Layer 2 VLAN Bundled EVPN Service”
Alternatively, a PE may advertise a unique
EVPN label per <MAC-VRF, Ethernet tag> combination. This
label
assignment is referred to as a per <MAC-VRF, Ethernet tag> label
assignment.
—-The above description corresponds to “Layer 2 VLAN Based EVPN Service”
As a third option, a PE may advertise a unique EVPN
label per <ESI, Ethernet tag> combination. This label
assignment is
referred to as a per <ESI, Ethernet tag> label assignment.
—-The above description corresponds to “LSI Based EVPN Service”.
As a
fourth option, a PE may advertise a unique EVPN label per MAC
address. This label assignment is referred to as a per MAC
label
assignment.
—-The above description is just for some very specific situations, and is not
in the scope of current “Layer 2 Access EVPN Service” or the corresponding
newly proposed “Layer 3 accessible EVPN service”
All of these label assignment methods have their
trade-offs.
The choice of a particular label assignment methodology
is purely local to the PE that originates the route
Aijun Wang
China Telecom
Aijun Wang
China Telecom
On Mar 17, 2025, at 05:12, Jeffrey (Zhaohui) Zhang
<zzhang=40juniper....@dmarc.ietf.org> wrote:
Hi Aijun,
Now that the -08 revision has been published, let me bring this discussion to
the WG. The email thread has some details that help clarify the intended use
case and why the proposed solution is not needed or not good.
The draft does not clearly state it, but based on our discussions below, the
PE-CE connection is a PW that terminates into the EVPN PE. There are two
previous points that I want to re-emphasize here. I'll then explain why your
proposed solution is not needed in my view.
- There are already deployed solutions of PWs terminating into VPN service
PEs, including EVPN, w/o any protocol extensions
- On the EVPN side, there is no difference between "a PW terminates into a
PW-PE, which then connects to EVPN PE via a physical L2 connection" and "a PW
terminates into the EVPN PE directly"
Your solution requires the ingress EVPN PEs to put on the PW information that
is used on the egress side. That is just unnecessary and not appropriate.
In the true L2 connection case, the MAC lookup on the egress PE leads to local
forwarding information, including the outgoing AC and perhaps VID translation
information.
In the PW terminating into EVPN PE case, the same lookup leads to local
forwarding information, including the PW information, which is *local* and
should not be advertised other EVPN PEs for them to put into the VXLAN header.
If your intention is to avoid the MAC lookup on the egress PE (which the draft
does not talk about), it is an orthogonal issue (nothing to do with PW
terminating into EVPN PE) that is already solved. Per RFC7432:
A PE may advertise the same single EVPN label for all MAC addresses
in a given MAC-VRF. This label assignment is referred to as
a per
MAC-VRF label assignment. Alternatively, a PE may advertise
a unique
EVPN label per <MAC-VRF, Ethernet tag> combination. This
label
assignment is referred to as a per <MAC-VRF, Ethernet tag> label
assignment. As a third option, a PE may advertise a unique
EVPN
label per <ESI, Ethernet tag> combination. This label
assignment is
referred to as a per <ESI, Ethernet tag> label assignment.
As a
fourth option, a PE may advertise a unique EVPN label per MAC
address. This label assignment is referred to as
_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org
_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org
