Subject: Re: [nvo3] FW: New Version Notification for draft-yong-nvo3-frwk-dpreq-addition-00.txt

From: "Yves Hertoghs (yhertogh)" <[email-masked]>
Date: Tue, 5 Feb 2013 17:32:01 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Aldrin Isaac
Sent: Friday, January 11, 2013 01:05
To: Kireeti Kompella
Cc: [email-masked]; 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-masked]<mailto:[email-masked]>> 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.

---

From: Aldrin Isaac <[email-masked]>
Date: Wed, 6 Feb 2013 14:54:19 -0500

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-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [mailto:[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
> *On Behalf Of *Aldrin Isaac
> *Sent:* Friday, January 11, 2013 01:05
> *To:* Kireeti Kompella
> *Cc:* [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>; 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-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
> wrote:
>
> 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.****
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 6 Feb 2013 23:37:12 +0000

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-masked]]
Sent: Wednesday, February 06, 2013 1:54 PM
To: Yves Hertoghs (yhertogh)
Cc: Kireeti Kompella; [email-masked]; 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

Yves

From: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');> [mailto:[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>] On Behalf Of Aldrin Isaac
Sent: Friday, January 11, 2013 01:05
To: Kireeti Kompella
Cc: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>; Lucy yong; NAPIERALA, MARIA H
Subject: [nvo3] FW: New Version Notification for draft-yong-nvo3-frwk-dpreq-addition-00.txt

Hi Kireeti,

Best regards -- aldrin

Let me expand.

Kireeti.

---

From: Aldrin Isaac <[email-masked]>
Date: Thu, 7 Feb 2013 11:10:04 -0500

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-masked] <javascript:_e({},
> 'cvml', [email-masked]');>]
> *Sent:* Wednesday, February 06, 2013 1:54 PM
> *To:* Yves Hertoghs (yhertogh)
> *Cc:* Kireeti Kompella; [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>; Lucy yong; NAPIERALA, MARIA H
> *Subject:* Re: FW: New Version Notification for
> Hi Yves,****
> infrastructure up to applications and their data. ****
>
> ** **
>
> Best regards,****
>
> Aldrin****
>
>
> On Tuesday, February 5, 2013, Yves Hertoghs (yhertogh) wrote:****
>
> Aldrin,****
>
>  ****
>
>  ****
>  ****
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Aldrin Isaac
> *Cc:* [email-masked]; Lucy yong; NAPIERALA, MARIA H
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****