Hello, Joshua,

Sorry, my fault. You are right. I owe you two dollars.

Best regards

Chaoyi Huang ( joehuang )

-----Original Message-----
From: Joshua Harlow [mailto:harlo...@outlook.com] 
Sent: Friday, December 12, 2014 9:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit 
recap and move forward

So I think u mean 'proprietary'?

http://www.merriam-webster.com/dictionary/proprietary

-Josh

joehuang wrote:
> Hi, Jay,
>
> Good question, see inline comments, pls.
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
> -----Original Message-----
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Friday, December 12, 2014 1:58 AM
> To: openstack-dev@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.)
>
> Thanks,
> -jay
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to