Hi Linda,
Thanks for your reply. Please see in-line [WW].
Best Regards,
Wei
------------------ Original ------------------
From:
"Linda Dunbar"
<[email protected]>;
Date: Fri, Mar 19, 2021 02:50 AM
To: "Wei Wang"<[email protected]>;"Gyan
Mishra"<[email protected]>;
Cc: "[email protected]"<[email protected]>;
Subject: RE: [bess] About draft-wang-bess-l3-accessible-evpn
Wei,
You said
??we allocate one VNI for all customers in each MAN, and configure only one VRF
on each PE, which can simplify the configuration work during deployment. On
PEs,..??
Is the VNI for Customer A in MAN3 same as the VNI in MAN2 & MAN1?
[WW] The VNIs in different MANs are allocated independently, so the VNIs for
Customer A may be different in MAN1-3.
You said ??Only configure one VRF on each PE??, don??t you need to
configure the VRFs for all Customer A, B, C on each PE?
[WW] In our solution, VNIs on PE are not allocated to customers, but for the
"Customer Group", which can be divided according to many criteria, for example,
the customers whose traffic will be transmitted among the same groups of PEs.
So each PE just need to maintain one VRF for a group of customers, and
use LSI to distinguish the traffic of different customers in the same group.
Linda Dunbar
On Tue, Mar 16, 2021 at 2:25 AM Wei Wang <[email protected]> wrote:
Hi Gyan, Sergey, Patrice and Jorge,
In fact, we are considering the following scenario:
where Backbone is EVPN domain, and MAN1-3 are Layer-3 network. VNIs in MAN1-3
are independently allocated, which may lead to the overlap of VNI in different
customer sites.
If there are 3 customers who need cross domain networking: A, B, C.
In general, we allocate 3 VNIs for the 3 customers in each MAN, and configure 3
VRFs on each PE to maintain the VPN routes of them.
In our solution, we allocate one VNI for all customers in each MAN, and
configure only one VRF on each PE, which can simplify the configuration work
during deployment. On PEs, the VRF can be divided into 3 sub-tables according
to LSI information to maintain the VPN routes of customers.
To Gyan: in the two documents you mentioned, a device (Interworking PE / GW) is
needed for routing conversion and redistribution, which is not needed in our
solution.
Best Regards,
Wei
China Telecom
------------------ Original ------------------
From: "Gyan Mishra" <[email protected]>;
Date: Sun, Mar 14, 2021 10:18 AM
To: "Fomin, Sergey (Nokia - US/Mountain View)"<[email protected]>;
Cc: "Wei Wang"<[email protected]>;"bess"<[email protected]>;
Subject: Re: [bess] About draft-wang-bess-l3-accessible-evpn
Dear Authors
I am trying to understand the purpose of this document.
Is the goal for EVPN to be L3 accessible?
The way this has been done the past in a DC fabric environment using EVPN ESI
single or all active multi home is from the DC fabric from the Border
leaf or Border spine that terminates the NVO3 overlay vxlan/vxlan-gpe/Geneve
the DC core L3 box for DCI inter connect can act as a ??fusion?? router and
terminate both tenant VRF and underlay peer and fuse the VRF overlay and global
table underlay routing to provide access between overlay and underlay as well
as external L3 reachability out of the fabric. All the Type-2 Mac-IP and
Type-5 prefix can be converted imported as IPv4 AFI SAFI-1 so the Type-2 in
SAFI-1 BGP RIB as host route and Type-5 shows as subnet prefix.
I am not sure if that is what you are trying to accomplish?
If you are trying to achieve EVPN to IPVPN interworking see draft below:
https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02
DCI EVPN overlay
https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10
Kind Regards
Gyan
On Fri, Mar 12, 2021 at 5:06 PM Fomin, Sergey (Nokia - US/Mountain View)
<[email protected]> wrote:
Hi Wei,
This draft presents a peculiar way of bringing something similar to
bridge-domain/bridge-table concepts into IP-VRFs..
One significant problem, in my opinion, is that you not only introduce a new
dataplane dependency; but also propose to _redefine_ VXLAN-GPE header semantics
(instead of just using it, or GENEVE). I would assume you have to go to nvo3
WG for the proposed VXLAN-GPE format changes (either with the full draft or
splitting it into 2 parts (control & data plane)).
Additionally, I would like to see more text on the motivation of the proposed
solution. In the abstract you make a point that ??This draft ?? proposes a new
solution which can simplify the deployment of layer-3 accessible EVPN
service.?? -> this simplicity is not obvious at all, and one may argue that
this solution is more complex compared to the existing ones (such as draft
inter-subnet-forwarding with multiple IP-VRFs)
--
Sergey
From: BESS <[email protected]> On Behalf Of Wei Wang
Sent: Friday, March 12, 2021 12:14 AM
To: linda.dunbar <[email protected]>; jorge.rabadan
<[email protected]>
Cc: bess <[email protected]>
Subject: [bess] About draft-wang-bess-l3-accessible-evpn
Hi Linda and Jorge,
Thanks for your comments at IETF110 meeting, and I think I need
to explain our considerations for the newly defined LSI (Logical Session
Identifier) concept.
Question 1, from Linda Dunbar, "Is the usage of LSI same as the RD for VPN
route distinguish?"
Answer: LSI(Logical Session Identifier) is mainly used for distinguishing the
different logical sessions between CE and PE device. Such session can be
established via Vxlan, IPsec, or other tunnel technologies that can span layer
3 network.
The LSI information should be transferred via the control plane and forwarding
plane. In control plane, we try to use Ethernet Tag ID/newly defined ESI type
to transfer, its purpose is to further distinguish the cusomer routes within
one provider VRF. In forwarding plane, this information should be inserted into
some place of the exising VxLAN encoding, as proposed in our
draft:https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.1
Question 2, from Jorge Rabadan. "The ESI shouldn't be used to distinguish the
route-type 5, it is mainly used for multi-homing purpose"
Answer: Currently, we are considering using two methods to identify the routes
that associated different LSI:
Method 1: Ethernet Tag ID, which is similar with its
usage in layer 2 vlan environment.
Method 2: Newly defined ESI type(type 6)
We think both methods are approachable:
Method 1 requires also the update of
https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11(Ethernet
Tag ID is set to 0 for route type 5), may arises some confuse with its
original defintion.
Method 2 requires the extension of ESI type (as described in:
https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.2).
The original purpose of ESI (mulit-homing) can also be preserved.
I hope the above explanations help.
Comments and questions are always welcome.
Best Regards,
Wei
China Telecom
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
--
Gyan Mishra
Network Solutions Architect
M 301 502-1347
13101 Columbia Pike
Silver Spring, MD
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
--
Gyan Mishra
Network Solutions Architect
M 301 502-1347
13101 Columbia Pike
Silver Spring, MD
Wei Wang
China Telecom
Wei Wang
China Telecom_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
