Hi, comments inline:

On 26 Dec, 2012, at 11:33 AM, Lucy yong wrote:

> Kireeti,
>  
> It seems that you make EVPN and IPVPN orthogonal now: If IP, use IPVPN, if 
> not, EVPN.
>  
> Do you also see that the end system can be distinguished this way?

A NVE could support both services, IPVPN and EVPN. The guest/tenant should have 
no need to understand the method of communication chosen by the hypervisor. 

>  
> Using IP VPN for all the IP applications is good in one way, but it requires 
> the substantial changes on all the hosts/hypervisor and require the behavior 
> changes on the VM/physical server. Giving millions VM/servers are there, will 
> this realistic?   Why do we ask all the tenant systems to change behavior in 
> order to use of IPVPN?

The changes necessary to support IPVPN or EVPN are located on the NVE. Likely 
this would be a kernel loadable module to the bridging an routing stack. I 
think the changes proposed are highly realistic given the current ecosystem of 
SDN/Cloud companies that are doing all sorts of interesting things in the 
networking stack of hypervisors. 

Best, 
Truman

>  
> IMO, IPVPN is very useful for many applications and it is also  necessary to 
> support multi-tenancy in DC without changing tenant system behavior.
>  
> Thanks,
> Lucy
>  
> From: [email protected] [mailto:[email protected]] On Behalf Of 
> Kireeti Kompella
> Sent: Friday, December 21, 2012 10:21 PM
> To: NAPIERALA, MARIA H
> Cc: Thomas Narten; [email protected]; Aldrin Isaac
> Subject: Re: [nvo3] Multi-subnet VNs [was Re: FW: New Version Notification 
> for draft-yong-nvo3-frwk-dpreq-addition-00.txt]
>  
> Hi Maria,
>  
> On Dec 20, 2012, at 13:36, "NAPIERALA, MARIA H" <[email protected]> wrote:
> The question is what problem does EVPN solve?
> 
> Pure layer 2 traffic. Yes, it does exist, and needs to be dealt with 
> properly. But just that. 
> In the context of DC, EVPN can only address packets bridged in the same VLAN. 
> If most packets are routed then EVPN, even if all the complexity problems are 
> addressed, doesn't achieve anything for the traffic that is routed. I believe 
> it is the wrong tradeoff to design a solution around EVPN (i.e., around 
> bridging).
> 
> Agreed.
>  
> Kireeti. 
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to