[openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

joehuang joehuang at huawei.com
Fri Dec 12 01:42:51 UTC 2014

Hi, Jay,

Good question, see inline comments, pls.

Best Regards
Chaoyi Huang ( Joe Huang )

-----Original Message-----
From: Jay Pipes [mailto:jaypipes at gmail.com] 
Sent: Friday, December 12, 2014 1:58 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

On 12/11/2014 04:02 AM, joehuang wrote:
>> [joehuang] The major challenge for VDF use case is cross OpenStack 
>> networking for tenants. The tenant's VM/Volume may be allocated in 
>> different data centers geographically, but virtual network
>> (L2/L3/FW/VPN/LB) should be built for each tenant automatically and 
>> isolated between tenants. Keystone federation can help authorization 
>> automation, but the cross OpenStack network automation challenge is 
>> still there. Using prosperity orchestration layer can solve the 
>> automation issue, but VDF don't like prosperity API in the 
>> north-bound, because no ecosystem is available. And other issues, for 
>> example, how to distribute image, also cannot be solved by Keystone 
>> federation.

>What is "prosperity orchestration layer" and "prosperity API"?

[joehuang] suppose that there are two OpenStack instances in the cloud, and vendor A developed an orchestration layer called CMPa (cloud management platform a), vendor B's orchestration layer CMPb. CMPa will define boot VM interface as CreateVM( Num, NameList, VMTemplate), CMPb may like to define boot VM interface as bootVM( Name, projectID, flavorID, volumeSize, location, networkID). After the customer asked more and more function to the cloud, the API set of CMPa will be quite different from that of CMPb, and different from OpenStack API. Now, all apps which consume OpenStack API like Heat, will not be able to run above the prosperity software CMPa/CMPb. All OpenStack API APPs ecosystem will be lost in the customer's cloud.  

>> [joehuang] This is the ETSI requirement and use cases specification 
>> for NFV. ETSI is the home of the Industry Specification Group for NFV. 
>> In Figure 14 (virtualization of EPC) of this document, you can see 
>> that the operator's  cloud including many data centers to provide 
>> connection service to end user by inter-connected VNFs. The 
>> requirements listed in
>> (https://wiki.openstack.org/wiki/TelcoWorkingGroup) is mainly about 
>> the requirements from specific VNF(like IMS, SBC, MME, HSS, S/P GW
>> etc) to run over cloud, eg. migrate the traditional telco. APP from 
>> prosperity hardware to cloud. Not all NFV requirements have been 
>> covered yet. Forgive me there are so many telco terms here.

>What is "prosperity hardware"?

[joehuang] For example, Huawei's IMS can only run over Huawei's ATCA hardware, even you bought Nokia ATCA, the IMS from Huawei will not be able to work over Nokia ATCA. The telco APP is sold with hardware together. (More comments on ETSI: ETSI is also the standard organization for GSM, 3G, 4G.)

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list