Subject: [nvo3] Is it too earlier to make a choice from L2 and L3-based NV solutions?

From: Xuxiaohu <[email-masked]>
Date: Tue, 31 Jul 2012 17:33:00 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 31 Jul 2012 19:41:16 +0200

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
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 31 Jul 2012 20:06:46 +0200

Thomas,

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.

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).

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.

Best regards,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 31 Jul 2012 18:05:35 +0000

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,

Best regards,
Robert.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 31 Jul 2012 18:22:10 +0000

[Xiaohu] I have the same concern. If somebody believes it's worthwhile to pursue this direction, It would be better to prove what distinct advantages this NVE-ToR signalling can provide compared to the orchestration system based approach. In addition, I disgree to the claim made in this draft that ARP is not a starting point. If the VM profile has already been provisioned by some means, e.g., using the orchestration system, the gratuitous ARP packet generated by the moved VM could actually be interpreted as a notification of VM attachment event.  As for the claim that ARP can not realize VM detachment notification, IMHO, it heavily depends on what specific NV technology is used. Take the VPLS as an example, the flooding of the gratiutous ARP packet could be interpreted by the old NVE to which the moved VM was previously attached as a implicit withdraw.

Best regards,
Xiaohu

Best regards,
R.

_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Jon Hudson <[email-masked]>
Date: Tue, 31 Jul 2012 11:49:41 -0700

You are assuming a single vendor hypervisor environment with a single management tool. 

This is not a safe assumption

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 31 Jul 2012 19:58:35 +0000

Not exactly. The orchestration system could allocate network and VM related provisioning tasks to the Network manager and the VM manager respectively which in turn perform the corresponding provisioning task since network managers from many vendors have already been able to support 
northward interfaces. Furthermore, if DC operators want standard northward interfaces, should the to-be-formed SDN (note that the SDN here doesn't mean Openflow) WG or other WG be responsible for such standardization work.

Best regards,
Xiaohu
________________________________________
发件人: Jon Hudson [[email-masked]]
发送时间: 2012年8月1日 2:49
到: Xuxiaohu
Cc: [email-masked]; [email-masked]
主题: Re: [nvo3] draft-kompella-nvo3-server2nve

---

From: Lucy yong <[email-masked]>
Date: Tue, 31 Jul 2012 21:37:46 +0000

[[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,

Best regards,
Xiaohu

Hi Xuxiaohu,

Best regards,
Robert.

---

From: James Kempf <[email-masked]>
Date: Tue, 31 Jul 2012 20:50:49 -0400

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 

> 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]
> 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
> 
> 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
> 
> 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,
> >
> > 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.
> > 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