IMHO, I wouldn't limit ourselves. If we expand our sight to view vCPE in its entirety, not any standalone VNF, it could be a cloud of vCPEs. It could be an enterprise cloud on top of enterprise vCPEs, or a community cloud across several organizations including vCPEs within residential communities.
There is another concept of "mobile cloud" where a cloud infrastructure is formed on top of mobile devices. Sounds crazy? Well, no one believed self-driving car could become reality so soon. >From telco perspective, those are the areas that allow innovation, and provide >telco customers with new types of services. We need innovation, starting from not limiting ourselves from bringing new idea and new use cases, and bringing those impossibility to reality. Thanks Bin -----Original Message----- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Saturday, August 27, 2016 2:47 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs On 08/25/2016 06:38 PM, joehuang wrote: > Hello, Ed, > > Just as Peter mentioned, "BT's NFV use cases e.g. vCPE, vCDN, vEPC, vIMS, > MEC, IoT, where we will have compute highly distributed around the network > (from thousands to millions of sites) ". vCPE is only one use case, but not > all. And the hardware facility to run "vCDN, vEPC, vIMS, MEC" is not in > set-box or single hardware, even in current non-cloud way, it includes lots > of blades, rack servers, chasises, or racks. Note that I have only questioned the use case of vCPE (and IoT) as "cloud use cases". content deliver networks, evolved packet core, and IP multimedia subsystem services are definitely cloud use cases, IMHO, since they belong as VNFs managed in a shared datacenter infrastructure. > A whitepaper was just created "Accelerating NFV Delivery with > OpenStack" https://www.openstack.org/telecoms-and-nfv/ Nothing in the whitepaper above has anything to do with vCPE. > So it's part of a cloud architecture, No, it's not. vCPE is definitely not a "cloud architecture". > the challenge is how OpenStack to run "regardless of size" and in "massively > distributed" manner. No, that is not OpenStack's challenge. It is the Telco industry's challenge to create purpose-built Telco software delivery mechanisms, just like it's the enterprise database and middleware industry's challenge to create RDBMS systems to meet the modern micro-service-the-world landscape in which we live. Asking the OpenStack community to solve a very specific Telco application delivery need is like asking the OpenStack community to write a relational database system that works best on 10 million IoT devices. It's just not in our list of problem domains to tackle. Best, -jay > Best Regards > Chaoyi Huang (joehuang) > ________________________________________ > From: Ed Leafe [e...@leafe.com] > Sent: 25 August 2016 22:03 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [all][massively > distributed][architecture] Coordination between actions/WGs > > On Aug 24, 2016, at 8:42 PM, joehuang <joehu...@huawei.com> wrote: >> >> Funny point of view. Let's look at the mission of OpenStack: >> >> "to produce the ubiquitous Open Source Cloud Computing platform that >> enables building interoperable public and private clouds regardless >> of size, by being simple to implement and massively scalable while serving >> the cloud users' >> needs." >> >> It mentioned that "regardless of size", and you also mentioned "cloud to me: >> lots of hardware consolidation". > > If it isn't part of a cloud architecture, then it isn't part of OpenStack's > mission. The 'size' qualifier relates to everything from massive clouds like > CERN and Walmart down to small private clouds. It doesn't mean 'any sort of > computing platform'; the focus is clear that we are an "Open Source Cloud > Computing platform". > > > -- Ed Leafe > > > > > > > ______________________________________________________________________ > ____ OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ______________________________________________________________________ > ____ OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
