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

顾 戎 <gurong_cmcc@outlook.com> Mon, 04 April 2016 18:30 UTC

Return-Path: <gurong_cmcc@outlook.com>
X-Original-To: sdn@ietfa.amsl.com
Delivered-To: sdn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B796B12D14E for <sdn@ietfa.amsl.com>; Mon, 4 Apr 2016 11:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZhe0T9l_5os for <sdn@ietfa.amsl.com>; Mon, 4 Apr 2016 11:30:49 -0700 (PDT)
Received: from COL004-OMC2S15.hotmail.com (col004-omc2s15.hotmail.com [65.55.34.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128A012D61F for <sdn@irtf.org>; Mon, 4 Apr 2016 11:30:49 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com ([65.55.34.71]) by COL004-OMC2S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 4 Apr 2016 11:30:48 -0700
Received: from PU1APC01FT055.eop-APC01.prod.protection.outlook.com (10.152.252.58) by PU1APC01HT086.eop-APC01.prod.protection.outlook.com (10.152.253.131) with Microsoft SMTP Server (TLS) id 15.1.443.6; Mon, 4 Apr 2016 18:30:46 +0000
Received: from SG2PR02MB1101.apcprd02.prod.outlook.com (10.152.252.60) by PU1APC01FT055.mail.protection.outlook.com (10.152.253.106) with Microsoft SMTP Server (TLS) id 15.1.443.6 via Frontend Transport; Mon, 4 Apr 2016 18:30:45 +0000
Received: from SG2PR02MB1101.apcprd02.prod.outlook.com ([10.169.53.11]) by SG2PR02MB1101.apcprd02.prod.outlook.com ([10.169.53.11]) with mapi id 15.01.0447.027; Mon, 4 Apr 2016 18:30:44 +0000
From: 顾 戎 <gurong_cmcc@outlook.com>
To: "sdn@irtf.org" <sdn@irtf.org>
Thread-Topic: 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.
Thread-Index: AQHRjqAXAzmHsvTcck6gUhVW86xL4A==
Date: Mon, 04 Apr 2016 18:30:44 +0000
Message-ID: <SG2PR02MB1101E72883AD9D46C9705C968B9D0@SG2PR02MB1101.apcprd02.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=softfail (sender IP is 25.152.252.60) smtp.mailfrom=outlook.com; irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=fail action=none header.from=outlook.com;
received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 25.152.252.60 as permitted sender)
x-tmn: [IcNSgva0sdslRLtXttE+JE7mnwdbBWf/]
x-eopattributedmessage: 0
x-forefront-antispam-report: CIP:25.152.252.60; IPV:NLI; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:PU1APC01HT086; H:SG2PR02MB1101.apcprd02.prod.outlook.com; FPR:; SPF:SoftFail; MLV:ovrnspm; MX:1; A:1; LANG:en;
x-ms-office365-filtering-correlation-id: 56cfe077-0f9c-4dcd-16a9-08d35cb73bf1
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5061506196)(5061507196); SRVR:PU1APC01HT086;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:PU1APC01HT086; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT086;
x-forefront-prvs: 0902222726
Content-Type: multipart/alternative; boundary="_000_SG2PR02MB1101E72883AD9D46C9705C968B9D0SG2PR02MB1101apcp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2016 18:30:44.3016 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT086
X-OriginalArrivalTime: 04 Apr 2016 18:30:48.0309 (UTC) FILETIME=[1BD1A250:01D18EA0]
Archived-At: <http://mailarchive.ietf.org/arch/msg/sdn/bZIUP-DqrfCetmjUhsC1prRbKcw>
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.
X-BeenThere: sdn@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: List to Discuss SDN Research Group in the IRTF <sdn.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/sdn>, <mailto:sdn-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sdn/>
List-Post: <mailto:sdn@irtf.org>
List-Help: <mailto:sdn-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/sdn>, <mailto:sdn-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Apr 2016 18:30:54 -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/>