Subject: [Sdn] Seeking for comments and suggestions about two drafts related with the SDN/NFV co-deployment in cloud datacenters presented in the morning. I summerized my ideas in the mail. Hope it's better for understanding.

From: 顾 戎 <[email-masked]>
Date: Mon, 4 Apr 2016 18:30:44 +0000

Hi, dear all.

I have made the presentation in a rush this morning. So I accept the advice from chairs to express my ideas in the mail-list. Hope that it's better for understanding.

As there are two drafts related in my presentations. It will be grateful of you to go through the draft and comments on that.

One is the updated version of the draft of problem statement of SDN and NFV co-deployment in cloud datacenters.

https://datatracker.ietf.org/doc/draft-gu-sdnrg-problem-statement-of-sdn-nfv-in-dc/

The updated contexts are:

(1) Network architecture changes when the bare-metal servers are brought in. SDN ToR and the openstack modules such as ironic and neutron should be brought in or be partically influenced.

As in the bare-metal server scenario, SDN TOR should be acted as the vtep. And the openstack ironic module are used to power the server and install the operating systems.

(2) Hypervisor:

When other hypervisors rather than KVM is accepted, something should be noted is that the virtual switch bonding with the hypervisor may not be controlled by the SDN controller. Solutions are eager to be found out. And I give out two solutions in another draft which I will introduce in the below.

(3) Cloud datacenter enlargement

In the simulation test, when 300 virtual machines are created at one time, it takes about 30 minites of the controller to download the flow table. So when the cloud datecenter is enlarged, the co-current performance should be taken into consideration. Besides, the openstack or Controller or forwarding devices have a limit on the number of virtual machines created. So when taking into how to enlarge the cloud datecenters, there should be considered.

(4) Data center interconnection

There are no trial and scheme of SDN datacenters belongs to different vendors interconnected with each other. Besides, when SDN datacenters interconnects with traditional datacenters, some extra devices should be added in the traditional datacenters.

Another new draft is about the decoupling shceme for hypervisor from SDN architecture which gives out two solutions according to the problems of hypervisor.

https://datatracker.ietf.org/doc/draft-gu-sdnrg-problem-statement-of-sdn-nfv-in-dc/

<https://datatracker.ietf.org/doc/draft-gu-sdnrg-problem-statement-of-sdn-nfv-in-dc/>In thinking over some commercial hypervisors which is bonding the virtual switch without the control of SDN controller, there are two solutions:

(1) substituting the virtual switch of hypervisor with the virtual switch which can be controlled by the SDN controller. However, the limitation relies on that the private interface of hypervisor should be open.

(2) Using one virtual machine acting as the virtual switch by directing all the traffic through the virtual machines. The limitation relies on the private interface partially and the virtual machine can be the bottleneck of performance.

Other solutions are eager to be found out.

<https://datatracker.ietf.org/doc/draft-gu-sdnrg-problem-statement-of-sdn-nfv-in-dc/>