Hi Aijun,
Juniper Business Use Only
From: Aijun Wang <wangai...@tsinghua.org.cn>
Sent: Saturday, March 22, 2025 6:05 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] Re: draft-wang-bess-l3-accessible-evpn
[External Email. Be cautious of content]
Hi, Jeffery:
No. We just want the MAC address lookup within the specific BD(identified by
LSI)of one MAC-VRF on the egress PE.
Zzh> Good. In that case, your reply dated “Monday, March 17, 2025 7:06 AM” does
not provide additional information to my email marked with “On Mar 17, 2025, at
05:12” in this thread.
Zzh> Now that you mention mac address lookup is within the specific BD
(identified by LSI), what’s the purpose of VNI field in the proposed header?
That may be a moot point though.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|S|R|R|I|R|R|R|R|D|R|R|A|R|R|R| LSI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The “traffic isolation” refers mainly that the source mac can only communicate
with the destination mac within the same BD of the LSI, which is similar with
the requirements of VLAN aware bundle service.
Zzh> Existing EVPN service already provide traffic isolation.
Zzh> An EVPN AC is always layer 2, whether it is physical connection all the
way to the CE, or it is physical connection to a PW PE (and then PW towards the
CE), or it is PW directly from the EVPN PE (your case), it does not matter.
Zzh> In summary, there is nothing new on the EVPN side, and my conclusion in
the email marked with “On Mar 17, 2025, at 05:12” in this thread remains.
Zzh> Thanks.
Zzh> Jeffrey
Aijun Wang
China Telecom
Aijun Wang
China Telecom
On Mar 21, 2025, at 10:52, Jeffrey (Zhaohui) Zhang
<zzhang=40juniper....@dmarc.ietf.org<mailto:zzhang=40juniper....@dmarc.ietf.org>>
wrote:
Aijun,
You did not answer my question. Is it that you want to avoid a mac lookup on
the egress PE?
Also, can you elaborate “traffic isolation”?
Jeffrey
Juniper Business Use Only
From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Sent: Thursday, March 20, 2025 10:01 PM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>
Cc: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>;
BESS <bess@ietf.org<mailto:bess@ietf.org>>;
draft-wang-bess-l3-accessible-e...@ietf.org<mailto:draft-wang-bess-l3-accessible-e...@ietf.org>;
Jorge Rabadan <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Subject: Re: [bess] Re: draft-wang-bess-l3-accessible-evpn
[External Email. Be cautious of content]
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<mailto: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<mailto:wangai...@tsinghua.org.cn>>
Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>
Cc: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>;
BESS <bess@ietf.org<mailto:bess@ietf.org>>;
draft-wang-bess-l3-accessible-e...@ietf.org<mailto:draft-wang-bess-l3-accessible-e...@ietf.org>;
Jorge Rabadan <jorge.raba...@nokia.com<mailto: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<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7432.html*section-9.2.1__;Iw!!NEt6yMaO-gk!EVS8RAEKl0m4mLCuOqpNzbkMSq2HFrRlHCebswm9hv4cNcjVIUouszlapK9Cr_XiqJ9ekoWkbuol07Bc7idetStS$>
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<mailto: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<mailto:bess@ietf.org>
To unsubscribe send an email to bess-le...@ietf.org<mailto:bess-le...@ietf.org>
_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org
