Hi Lucy, Different folks optimize for different problems.
In cases where there are many applications with special requirements (ex: very fast service response) and complex interdependencies, it becomes a good idea to design your system in a manner where any failure in a DC (including controllers) may result in a loss of a unit of service capacity (ex: one DC's worth), but not a systemic failure. Best regards, Aldrin On Wednesday, February 6, 2013, Lucy yong wrote: > Hi Aldrin,**** > > ** ** > > I interpret this as not much resource to share between individual > “availability zone”s. The resource may be for physical infrastructure and > applications. Is that right?**** > > ** ** > > For centralized control concept such as SDN, do you anticipate one > controller to control one “availability zone” or multiple?**** > > Thank ahead to share your insight.**** > > ** ** > > Lucy**** > > ** ** > > *From:* Aldrin Isaac [mailto:[email protected] <javascript:_e({}, > 'cvml', '[email protected]');>] > *Sent:* Wednesday, February 06, 2013 1:54 PM > *To:* Yves Hertoghs (yhertogh) > *Cc:* Kireeti Kompella; [email protected] <javascript:_e({}, 'cvml', > '[email protected]');>; Lucy yong; NAPIERALA, MARIA H > *Subject:* Re: FW: New Version Notification for > draft-yong-nvo3-frwk-dpreq-addition-00.txt**** > > ** ** > > 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] [mailto:[email protected]] *On Behalf > Of *Aldrin Isaac > *Sent:* Friday, January 11, 2013 01:05 > *To:* Kireeti Kompella > *Cc:* [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:**** > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
