<div dir="ltr">Colleagues,<div><br></div><div>An interesting discussion, the only question appears to be whether vCPE is a suitable use case as the others do appear to be cloud use cases. Lots of people assume CPE == small residential devices however CPE covers a broad spectrum of appliances. Some of our customers' premises are data centres, some are HQs, some are campuses, some are branches. For residential CPE we use the Broadband Forum's CPE Wide Area Network management protocol (TR-069), which may be easier to modify to handle virtual machines/containers etc. than to get OpenStack to scale to millions of nodes. However that still leaves us with the need to manage a stack of servers in thousands of telephone exchanges, central offices or even cell-sites, running multiple work loads in a distributed fault tolerant manner.</div><div><br></div><div>Best Regards,</div><div>Peter.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 30, 2016 at 4:48 AM, joehuang <span dir="ltr"><<a href="mailto:joehuang@huawei.com" target="_blank">joehuang@huawei.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello, Jay,<br>
<span class=""><br>
> The Telco vCPE and Mobile "Edge cloud" (hint: not a cloud) use cases<br>
<br>
</span>Do you mean Mobile Edge Computing for Mobile "Edge cloud"? If so, it's cloud. The introduction slides [1] can help you to learn the use cases quickly, there are lots of material in ETSI website[2].<br>
<br>
[1] <a href="http://www.etsi.org/images/files/technologies/MEC_Introduction_slides__SDN_World_Congress_15-10-14.pdf" rel="noreferrer" target="_blank">http://www.etsi.org/images/<wbr>files/technologies/MEC_<wbr>Introduction_slides__SDN_<wbr>World_Congress_15-10-14.pdf</a><br>
[2] <a href="http://www.etsi.org/technologies-clusters/technologies/mobile-edge-computing" rel="noreferrer" target="_blank">http://www.etsi.org/<wbr>technologies-clusters/<wbr>technologies/mobile-edge-<wbr>computing</a><br>
<br>
And when we talk about massively distributed cloud, vCPE is only one of the scenarios( now in argue - ing ), but we can't forget that there are other scenarios like vCDN, vEPC, vIMS, MEC, IoT etc. Architecture level discussion is still necessary to see if current design and new proposals can fulfill the demands. If there are lots of proposals, it's good to compare the pros. and cons, and which scenarios the proposal work, which scenario the proposal can't work very well.<br>
<br>
( Hope this reply in the thread :) )<br>
<br>
Best Regards<br>
Chaoyi Huang(joehuang)<br>
<span class="">______________________________<wbr>__________<br>
From: Jay Pipes [<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>]<br>
</span>Sent: 29 August 2016 18:48<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
<div class="HOEnZb"><div class="h5">Subject: Re: [openstack-dev] [all][massively distributed][architecture]<wbr>Coordination between actions/WGs<br>
<br>
On 08/27/2016 11:16 AM, HU, BIN wrote:<br>
> The challenge in OpenStack is how to enable the innovation built on top of OpenStack.<br>
<br>
No, that's not the challenge for OpenStack.<br>
<br>
That's like saying the challenge for gasoline is how to enable the<br>
innovation of a jet engine.<br>
<br>
> So telco use cases is not only the innovation built on top of OpenStack. Instead, telco use cases, e.g. Gluon (NFV networking), vCPE Cloud, Mobile Cloud, Mobile Edge Cloud, brings the needed requirement for innovation in OpenStack itself. If OpenStack don't address those basic requirements,<br>
<br>
That's the thing, Bin, those are *not* "basic" requirements. The Telco<br>
vCPE and Mobile "Edge cloud" (hint: not a cloud) use cases are asking<br>
for fundamental architectural and design changes to the foundational<br>
components of OpenStack. Instead of Nova being designed to manage a<br>
bunch of hardware in a relatively close location (i.e. a datacenter or<br>
multiple datacenters), vCPE is asking for Nova to transform itself into<br>
a micro-agent that can be run on an Apple Watch and do things in<br>
resource-constrained environments that it was never built to do.<br>
<br>
And, honestly, I have no idea what Gluon is trying to do. Ian sent me<br>
some information a while ago on it. I read it. I still have no idea what<br>
Gluon is trying to accomplish other than essentially bypassing Neutron<br>
entirely. That's not "innovation". That's subterfuge.<br>
<br>
> the innovation will never happen on top of OpenStack.<br>
<br>
Sure it will. AT&T and BT and other Telcos just need to write their own<br>
software that runs their proprietary vCPE software distribution<br>
mechanism, that's all. The OpenStack community shouldn't be relied upon<br>
to create software that isn't applicable to general cloud computing and<br>
cloud management platforms.<br>
<br>
> An example is - self-driving car is built on top of many technologies, such as sensor/camera, AI, maps, middleware etc. All innovations in each technology (sensor/camera, AI, map, etc.) bring together the innovation of self-driving car.<br>
<br>
Yes, indeed, but the people who created the self-driving car software<br>
didn't ask the people who created the cameras to write the software for<br>
them that does the self-driving.<br>
<br>
> WE NEED INNOVATION IN OPENSTACK in order to enable the innovation built on top of OpenStack.<br>
<br>
You are defining "innovation" in an odd way, IMHO. "Innovation" for the<br>
vCPE use case sounds a whole lot like "rearchitect your entire software<br>
stack so that we don't have to write much code that runs on set-top boxes."<br>
<br>
Just being honest,<br>
-jay<br>
<br>
> Thanks<br>
> Bin<br>
> -----Original Message-----<br>
> From: Edward Leafe [mailto:<a href="mailto:ed@leafe.com">ed@leafe.com</a>]<br>
> Sent: Saturday, August 27, 2016 10:49 AM<br>
> To: OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
> Subject: Re: [openstack-dev] [all][massively distributed][architecture]<wbr>Coordination between actions/WGs<br>
><br>
> On Aug 27, 2016, at 12:18 PM, HU, BIN <<a href="mailto:bh526r@att.com">bh526r@att.com</a>> wrote:<br>
><br>
>>> From telco perspective, those are the areas that allow innovation, and provide telco customers with new types of services.<br>
>><br>
>> We need innovation, starting from not limiting ourselves from bringing new idea and new use cases, and bringing those impossibility to reality.<br>
><br>
> There is innovation in OpenStack, and there is innovation in things built on top of OpenStack. We are simply trying to keep the two layers from getting confused.<br>
><br>
><br>
> -- Ed Leafe<br>
><br>
><br>
><br>
><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>