Subject: Re: [nvo3] draft-kompella-nvo3-server2nve

From: Thomas Morin <[email-masked]>
Date: Wed, 01 Aug 2012 12:09:34 -0700

Hi Robert,

Robert Raszuk:
> The desire to have NVE in the hypervisor is dictated from the need to
> build high speed IP based DC core including all tiers where devices
> there do not need to keep any excessive state other then the basic
> routing information how to carry already encapsulated packets to a next hop.

This is one of the motivations, but not necessarily the only one.

> You slides have demonstrated the need to put CLOUD OS information to the
> DC network (dotted lines) which completely prevents one to create low
> cost high capacity IP core as it is quite unlikely that many vendors
> would be able to deliver sufficient intelligence to integrate with CLOUD
> OS (leave alone the aspect of cost).

I don't necessarily agree with you here. I'd actually be careful about 
monolithic statements about cost, in general.

In this particular case the kind of interactions between the CloudOS and 
the DC network may very much depend on your needs and on the 
application, and may reduce down to mostly no interaction in some cases 
(one reason for the line to be dotted, the other being that even if 
their are some interactions, they are not in the critical path of VM 
instantiation and VM mobility related actions).

I think there is definitely a space where just the right amount of 
interaction happens between the CloudOS and DC network devices, with a 
balanced additional effort on the network device vendor side.

> Thinks like tenant virtualization local VLAN assignments are already
> provided today by DC orchestration system when the VM is created. I do
> not think that asking NVE TOR for this information as well as other
> network information of VMs is a good direction at all.

Let's clarify two things:
- first of all, the draft allows VLAN allocation by the server *and* 
allocation by the ToR (although one slide of our presentation only 
highlighted one)
- second, about what you suggest above: "local VLAN assignment [...] 
provided today by DC orchestration",  having VLANs assigned by the DC 
orchestration or cloud OS is something that does exists, *but* AFAICT 
this is not about a *local* ID used only between the server and ToR (in 
fact, it is precisely because it is local that you don't need to 
coordinate the allocation at the DC orchestration level)

Thanks,

-Thomas

---

From: Jon Hudson <[email-masked]>
Date: Wed, 1 Aug 2012 16:23:31 -0700

Thank you!!!!!!

Many users believe that their L2 switches are running L3 code because they set a static ipaddr on the management interface.

Limiting possible solutions by caging NVo3 to L2 or L3 is.....not an efficient use of the valuable NVo3 resources.

On Jul 31, 2012, at 5:50 PM, James Kempf <[email-masked]> wrote:

> Is anybody going to care if the WG makes a choice? People are out there deploying stuff.
> 
> I don't think the WG should make a choice. I think it should confine itself to the charter.
> 
>        jak 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Lucy yong
>> Sent: Tuesday, July 31, 2012 2:38 PM
>> To: Xuxiaohu; [email-masked]
>> Cc: [email-masked]
>> Subject: Re: [nvo3] Is it too earlier to make a choice from 
>> L2 and L3-based NV solutions?
>> 
>> Hence, I believe it's too earlier to make a choice between L2 
>> and L3-based VN approaches at this stage. In other word, the 
>> NVo3 problem statement and requirement drafts should be more 
>> generic without focusing too much on specific approaches/solutions.
>> 
>> [[LY]] I think that both L2 or L3 VN should be address by the 
>> WG, period. We should let operator pick which they use.
>> 
>> Lucy
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Xuxiaohu
>> Sent: Tuesday, July 31, 2012 1:06 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: [nvo3] Is it too earlier to make a choice from 
>> L2 and L3-based NV solutions?
>> 
>> Hi Robert,
>> 
>> I fully agree with you that there are use cases for both approaches.
>> 
>> However, based on the assumption that there will be only one 
>> PS doc to be accepted as claimed by WG chairs and the fact 
>> that there are many common places between L2 and L3 based NV 
>> approaches (e.g., multi-tenancy, support of VM mobility 
>> without renumbering, etc),  I believe it would be better to 
>> make the problem statement more generic, with more focus on 
>> the problem itself, rather than focusing too much on specific 
>> solutions.
>> 
>> Best regards,
>> Xiaohu
>> 
>> ________________________________________
>> 发件人: Robert Raszuk [[email-masked]]
>> 发送时间: 2012年8月1日 1:41
>> 到: Xuxiaohu
>> Cc: [email-masked]
>> 主题: Re: [nvo3] Is it too earlier to make a choice from L2 and 
>> L3-based NV solutions?
>> 
>> Hi Xuxiaohu,
>> 
>> I would not really say that this is too early.
>> 
>> I think there is already substantial evidence that this WG 
>> needs to work on both L2 and L3 based solutions.
>> 
>> If this is in one or two problem statements documents I think 
>> it really does not matter provided that the document honestly 
>> reflects both needs.
>> 
>> I am not sure what can change in weeks or months to come 
>> which would allow to dismiss one of the above spaces. I see 
>> the real use cases for both for at least next few years.
>> 
>> Best regards,
>> Robert.
>> 
>> 
>>> Hi all,
>>> 
>>> As stated in the current NVo3 WG charter, the current  task 
>> for NVo3 
>>> is to define the data center network problems and requirements.
>>> 
>>> IMHO, one major driver for a large VLAN or subnet aross 
>> multiple racks 
>>> even multiple data center is to allow VM mobility without 
>> renumbering. 
>>> To support this, we can either use MAC-based forwarding (i.e., 
>>> L2-based NV) or host-route based forwarding (i.e., L3-based NV). Of 
>>> course, some may argue that server cluster is another driver.
>>> As far as I know, there are still some legacy cluster technologies 
>>> which heavily rely on L2 connectivity (e.g., using non-IP 
>> protocol for 
>>> cluster membership keepalive), however, there are also some cluster 
>>> technologies which can run well on L3. And most importantly, those 
>>> vendors of legacy cluster technologies have already upgraded or 
>>> started to consider upgrading their cluster technologies to support 
>>> L3. Hence both L2 and L3 approaches have their own target scenarios.
>>> 
>>> As we already know, each approach has its pros and cons, 
>> for example, 
>>> L2-based NV is more applicable (i.e., it can support both IP and 
>>> non-IP traffic), and L3-based NV is more scalable (e.g., 
>> the flooding 
>>> domain and MAC domain associated with the extended subnet can be 
>>> partitioned and therefore be confined within a very small scope).
>>> For those data center operators who still have some L2 applications 
>>> running in their data centers, they can choose L2-based NV, 
>> otherwise, 
>>> they can choose L3-based NV.
>>> 
>>> Hence, I believe it's too earlier to make a choice between L2 and 
>>> L3-based VN approaches at this stage. In other word, the 
>> NVo3 problem 
>>> statement and requirement drafts should be more generic without 
>>> focusing too much on specific approaches/solutions.
>>> 
>>> Best regards, Xiaohu _______________________________________________
>>> nvo3 mailing list [email-masked]
>>> https://www.ietf.org/mailman/listinfo/nvo3
>>> 
>>> 
>> _______________________________________________
>> nvo3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nvo3
>> _______________________________________________
>> nvo3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nvo3
>> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Lucy yong <[email-masked]>
Date: Thu, 2 Aug 2012 03:35:37 +0000

Fully agree.
Lucy

-----Original Message-----
From: Jon Hudson [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2012 6:24 PM
To: James Kempf
Cc: Lucy yong; Xuxiaohu; [email-masked]; [email-masked]
Subject: Re: [nvo3] Is it too earlier to make a choice from L2 and L3-based NV solutions?

Thank you!!!!!!