Subject: Re: [bess] About draft-wang-bess-l3-accessible-evpn

From: "Wei Wang" <[email-masked]>
Date: Mon, 22 Mar 2021 14:06:23 +0800

Hi Linda,

Glad to see your reply. Please see in-line.

Best Regards,
Wei
------------------ Original ------------------
From:                                                                                                                        "Linda Dunbar"                                                                                    <[email-masked]&gt;;
Date:&nbsp;Sat, Mar 20, 2021 00:54 AM
To:&nbsp;"Wei Wang"<[email-masked]&gt;;"Gyan Mishra"<[email-masked]&gt;;
Cc:&nbsp;"[email-masked]"<[email-masked]&gt;;
Subject:&nbsp;Re: [bess] About draft-wang-bess-l3-accessible-evpn

Wei, 
 
&nbsp;
 
Thank you very much for the answers. 
 
&nbsp;
 
I have two more questions about the draft. 
 
&nbsp;
  
Your draft states that CE-PE needs Layer 3 while as the &nbsp;EVPN requires Layer 2 access. For Layer 3 over CE-PE link, can’t you simply use the L3VPN? 
[WW] MPLS-based L3VPN is possible, but it requries the advertisement of MPLS labels across different AS boundaries, which is not a scalable solution.

EVPN has MPLS among the PEs. Your draft states VxLAN among the PEs. If it is simple VxLAN among the PEs, there is really no need to mention the EVPN, is it correct? 
[WW] Actually, EVPN supports not only MPLS forwarding plane, but also VxLAN (as mentioned in RFC8365: https://datatracker.ietf.org/doc/rfc8365/). In the mentioned scenario, EVPN is the control plane protocol to distribute the VNI/LSI information among PEs.

&nbsp;

&nbsp;
 
Linda Dunbar
 
&nbsp;
  
From: Wei Wang <[email-masked]&gt; 
 Sent: Friday, March 19, 2021 1:29 AM
 To: Linda Dunbar <[email-masked]&gt;; Gyan Mishra <[email-masked]&gt;
 Cc: [email-masked]
 Subject: Re: [bess] About draft-wang-bess-l3-accessible-evpn

&nbsp;
  
Hi Linda,

&nbsp;

Thanks for your reply. Please see in-line [WW].

&nbsp;

Best Regards,

Wei

&nbsp;

------------------ Original ------------------

From: "Linda Dunbar" <[email-masked]&gt;;

Date:&nbsp;Fri, Mar 19, 2021 02:50 AM

To:&nbsp;"Wei Wang"<[email-masked]&gt;;"Gyan Mishra"<[email-masked]&gt;;

Cc:&nbsp;"[email-masked]"<[email-masked]&gt;;

Subject:&nbsp;RE: [bess] About draft-wang-bess-l3-accessible-evpn

&nbsp;

Wei, 
 
&nbsp;
 
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,..”
   
&nbsp;
 
Is the VNI for Customer A in MAN3 same as the VNI in MAN2 &amp; MAN1?
 
[WW] The VNIs in different MANs are allocated independently, so the VNIs for Customer A may be different in MAN1-3. 
 
&nbsp;
 
You said “Only configure one VRF on each PE”,&nbsp; 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. &nbsp;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.
 
&nbsp;
 
Linda Dunbar 
   
On Tue, Mar 16, 2021 at 2:25 AM Wei Wang <[email-masked]&gt; wrote:

Hi Gyan, Sergey, Patrice and Jorge,

&nbsp;

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.

&nbsp;

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.

&nbsp;

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.

&nbsp;

Best Regards,

Wei

China Telecom

&nbsp;

------------------ Original ------------------

 From: "Gyan Mishra" <[email-masked]&gt;;

 Date:&nbsp;Sun, Mar 14, 2021 10:18 AM

 To:&nbsp;"Fomin, Sergey (Nokia - US/Mountain View)"<[email-masked]&gt;;

 Cc:&nbsp;"Wei Wang"<[email-masked]&gt;;"bess"<[email-masked]&gt;;

 Subject:&nbsp;Re: [bess] About draft-wang-bess-l3-accessible-evpn

&nbsp;

&nbsp;

Dear Authors

&nbsp;

I am trying to understand the purpose of this document.

&nbsp;

Is the goal for EVPN to be L3 accessible?

&nbsp;

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 &nbsp;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.&nbsp; 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. 

&nbsp;

I am not sure if that is what you are trying to accomplish?

&nbsp;

&nbsp;

If you are trying to achieve EVPN to IPVPN interworking see draft below:

&nbsp;

https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02

&nbsp;

DCI EVPN overlay 

&nbsp;

https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10

&nbsp;

&nbsp;

Kind Regards 

&nbsp;

Gyan

&nbsp;

On Fri, Mar 12, 2021 at 5:06 PM Fomin, Sergey (Nokia - US/Mountain View) <[email-masked]&gt; wrote:

Hi Wei,
 
&nbsp;
 
This draft presents a peculiar way of bringing something similar to bridge-domain/bridge-table concepts into IP-VRFs..
 
&nbsp;
 
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 &amp; data plane)).
 
&nbsp;
 
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.” -&gt; 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)
 
&nbsp;
 
--
 
Sergey
 
&nbsp;
  
From: BESS <[email-masked]&gt; On Behalf Of Wei Wang

 
        
Sent: Friday, March 12, 2021 12:14 AM
 To: linda.dunbar <[email-masked]&gt;; jorge.rabadan <[email-masked]&gt;
 Cc: bess <[email-masked]&gt;
 Subject: [bess] About draft-wang-bess-l3-accessible-evpn

 
       
&nbsp;
  
Hi Linda and Jorge,

 
        
&nbsp; &nbsp; 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.

&nbsp;

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

&nbsp;

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:

&nbsp; &nbsp; &nbsp; &nbsp;Method 1: Ethernet Tag ID, which is similar with its usage in layer 2 vlan environment.

&nbsp; &nbsp; &nbsp; &nbsp;Method 2: Newly defined ESI type(type 6)

&nbsp;

&nbsp; &nbsp; We think both methods are approachable:

&nbsp; &nbsp; 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.

&nbsp; &nbsp; 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.

&nbsp;

&nbsp; &nbsp; I hope the above explanations help.

&nbsp; &nbsp; Comments and questions are always welcome.

&nbsp;

Best Regards,

Wei

China Telecom

 
_______________________________________________
 BESS mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/bess

-- 

Gyan Mishra
 
Network Solutions Architect  
 
M 301 502-1347
 13101  Columbia Pike 
 Silver Spring, MD

&nbsp;

 

_______________________________________________
 BESS mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/bess

-- 

Gyan Mishra
 
Network Solutions Architect  
 
M 301 502-1347
 13101 Columbia Pike 
 Silver Spring, MD

&nbsp;

 

&nbsp;

Wei Wang

China Telecom

&nbsp;

   
Wei Wang

China Telecom

---

From: "Wei Wang" <[email-masked]>
Date: Mon, 22 Mar 2021 14:11:03 +0800

Hi Gyan,

&nbsp; &nbsp; Glad to see your reply. Please see in-line.

Best Regards,
Wei
------------------ Original ------------------
From:                                                                                                                        "Gyan Mishra"                                                                                    <[email-masked]&gt;;
Date:&nbsp;Fri, Mar 19, 2021 10:06 PM
To:&nbsp;"Wei Wang"<[email-masked]&gt;;
Cc:&nbsp;"[email-masked]"<[email-masked]&gt;;
Subject:&nbsp;Re: [bess] About draft-wang-bess-l3-accessible-evpn

Hi Wei

Thanks for the clarification.

So this draft addresses situation where the VNI is not globally unique and so overlapping VNI name space in which case you allocate a VRF per customer.&nbsp; So with this draft you eliminate the resources overhead of 1-1 mapping VRF to Customer and with VSI analogous to ESI MAC VRF you can group customers based on criteria and group their Mac tables as sub tables into a common group VRF. 
[WW] Correct.

How does that provide customers VRF type isolation requirements by customers?
[WW] The customer isolation can be achieved by sub-tables which are identified by LSI.

Thanks 

Gyan

On Thu, Mar 18, 2021 at 3:36 AM Wei Wang <[email-masked]&gt; wrote:

Hi Gyan,

Best Regards,
Wei
------------------ Original ------------------
From:                                                                                                                        "Gyan Mishra"                                                                                    <[email-masked]&gt;;
Date:&nbsp;Thu, Mar 18, 2021 09:27 AM
To:&nbsp;"Wei Wang"<[email-masked]&gt;;
Cc:&nbsp;"Patrice Brissette (pbrisset)"<pbrisset=[email-masked]&gt;;"jorge.rabadan"<[email-masked]&gt;;"[email-masked]"<[email-masked]&gt;;"Fomin, Sergey (Nokia - US/Mountain View)"<[email-masked]&gt;;
Subject:&nbsp;Re: [bess] About draft-wang-bess-l3-accessible-evpn

Hi Wei 

If you are stretching EVPN DCI over SR or MPLS core and not doing any IP VPN to EVPN gateway translation function, then you don’t need define any VRFs on the PEs unless the PE is terminating the NVO3 overlay which usually is not the case. &nbsp;

The DCI core box border spine / border leaf / shared border box would terminate the NVO3 tunnel within the DC.
[WW] Do you mean to build NVO3 tunnel directly between MSEs in different MANs? It obviously works, but it requires VNIs in MAN1-3 to be globally unique, and the scenario we are considering does not meet this requirement (VNIs in MAN1-3 are independently allocated, which may lead to the overlap of VNI in different customer sites).

Kind Regards 

Gyan 
&nbsp;

Best Regards,
Wei
China Telecom

------------------ Original ------------------

Dear Authors

DCI EVPN overlay 

Kind Regards 

Gyan

Hi Wei,
 
&nbsp;

&nbsp;

&nbsp;

&nbsp;
 
--
 
Sergey
 
&nbsp;

 
 
&nbsp;
  
Hi Linda and Jorge,

&nbsp;

&nbsp;

&nbsp;

  
&nbsp;

&nbsp;

Best Regards,

Wei

China Telecom

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

Wei Wang
China Telecom

-- 

Gyan Mishra

Email [email-masked]

M 301 502-1347

Wei Wang
China Telecom