Hi Yves, Many large enterprises treat a physical DC as an "availability zone" and minimize as much dependencies across availability zones --- from physical infrastructure up to applications and their data.
Best regards, Aldrin On Tuesday, February 5, 2013, Yves Hertoghs (yhertogh) wrote: > Aldrin,**** > > ** ** > > Would those enterprise cloud customers as you call them have the same > requirements as far as georedundancy/location-independence , or would they > rather deploy two different complete instances of their ‘virtual > datacenter’ at different locations and use traditional techniques to offer > resilience ?**** > > ** ** > > Yves**** > > ** ** > > *From:* [email protected] <javascript:_e({}, 'cvml', > '[email protected]');> [mailto:[email protected]<javascript:_e({}, > 'cvml', '[email protected]');>] > *On Behalf Of *Aldrin Isaac > *Sent:* Friday, January 11, 2013 01:05 > *To:* Kireeti Kompella > *Cc:* [email protected] <javascript:_e({}, 'cvml', '[email protected]');>; Lucy > yong; NAPIERALA, MARIA H > *Subject:* [nvo3] FW: New Version Notification for > draft-yong-nvo3-frwk-dpreq-addition-00.txt**** > > ** ** > > 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]<javascript:_e({}, 'cvml', '[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
