Aldrin, The solution Maria and Kireeti lean to is the L3 overlay only solution. Pedro's end-system draft propose one solution for the L3 overlay only in DC. However the draft requires a substantial changes on the host OS system, and the architecture is very different from the physical enterprise network. In this solution, there is no L2 overlay at all. Each TS has to establish a tunnel with the overlay first hop router directly. That can be via a p2p or mp2p model.
I see the application space for this such as IP mobility but don't see it can fit for a tenant virtual network. Because this architecture requires that individual TSes MUST use a security mechanism to join the VPN first. For DC multi-tenancy, DC operator can create a tenant virtual network and assign VM and network appliance resource to associate with the tenant virtual network. Then tenant places and run the application on the resource. DC operator can move these VMs for server resource optimization while tenant application is running. This application is very different from IP mobility application, where TS can move on its own and need to request "join" the network again when it changes the network access point. Thus, I do not see that this stone can hit two birds. Kireeti, sorry to cut-in ahead. Regards, Lucy From: Aldrin Isaac [mailto:[email protected]] Sent: Monday, December 17, 2012 10:37 PM To: Kireeti Kompella Cc: NAPIERALA, MARIA H; Lucy yong; [email protected] Subject: Re: FW: New Version Notification for draft-yong-nvo3-frwk-dpreq-addition-00.txt Kireeti, How is the bridging and routing functionality you describe implemented on say a hypervisor? Would there be a routing instance (VRF) connected to one or more bridging instances (EVI)? I call this IRB, although I'm sure there is a lot more involved with implementing it on dedicated hardware. Also, given that (1) you want host specific routing because it gives you the shortest path to anywhere, and (2) since IP is the Internet[work] protocol (my networks, my partners networks, my services and the world in general), it would seem to me that the NVE has a lot of /32 routing information to bear. What's the plan of aggregation, and then what of shortest path? Also, as I noted some time ago, currently IP routing is generally stable at the expense of Ethernet since today router configuration is generally static, whereas bridges have to deal with plug and play and lousy end station software. When the IP tables start churning, will IP still be the good ole IP of yester year? Best regards -- aldrin On Monday, December 17, 2012, Kireeti Kompella wrote: On Dec 17, 2012, at 10:18 , "NAPIERALA, MARIA H" <[email protected]<javascript:;>> wrote: > Intra-subnet traffic can be also handled by a layer 3 overlay. Let me expand. I see the need for E-VPN for non-IP traffic. This is real, and is not met by IP VPNs (news flash!) For IP traffic, whether intra and inter-subnet, IP VPNs suffice. The solution is simple: route if IP, bridge if not. Yes, one could do IRB, but why? IRB brings in complications, especially for multicast. I'm sure someone suggested this already, so put me down as supporting this view. A NVE that supports both E-VPN and IP VPN for a given tenant simply sends IP traffic to the IP VPN and sends the rest to E-VPN. How this happens is implementation specific. Note that this assumes that the NVE intercepts ARPs and responds to them with the same MAC. Does anyone see a problem with this? If there is a case for _only_ intra-subnet traffic, one may create an E-VPN to handle both IP and non-IP; but I suspect this is a rare case. >From that point of view, I would like to see E-VPNs in the data center >*always* coupled with IP VPNs, and only dealing with non-IP traffic. This may appear drastic, but I think operationally, this is will simplify things. As always, I am open to alternate suggestions, provided they are presented without religion or politics. I'm especially keen to hear from those deploying. Kireeti.
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
