Hi Kireeti, I believe the assessment about eliminating the role of Ethernet in an all-IP world makes sense for many scenarios, but not all.
It certainly makes sense for a "consumer cloud" (Google, Amazon, etc) but might not be the best choice for SPs that want to be in the "enterprise cloud" business. In the consumer cloud each VM is a destination and generally VM networking is fully in the control of the SP -- here the consumer doesn't care so much about how things connect so long as they just do. In the enterprise cloud, the details of the stuff in between source and destination does matter. Many enterprises tend to customize their services (comprised of apps, policy, security, load balancing, networking, monitoring, etc) to meet their particular goals, challenges, differentiate themselves from their competitors, etc. For example, some enterprise customers would want to operate their own virtual SRX firewall. Using IPVPN for where enterprise customers need subnets reminds me of how SPs pushed IPVPN on customers in the early part of the last decade when what the customers wanted was Ethernet. If an SP is only interested in delivering consumer cloud, then "route IP, bridge non-IP" makes sense -- this is a large piece of the market, but it doesn't cover all of it. Maybe it should be "route _known_ IP and bridge other", but then what's the point? In addition to this, I'm perplexed when I see discussion of inefficient routing (tromboning) in Ethernet approach and none about route scaling challenges in /32 IPVPN approach and its solution (route aggregation) which brings us back to the same problem. Best regards -- aldrin On Monday, December 17, 2012, Kireeti Kompella wrote: > On Dec 17, 2012, at 10:18 , "NAPIERALA, MARIA H" <[email protected]> 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
