Open Stack

Colleagues,

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.

Best Regards,
Peter.

On Tue, Aug 30, 2016 at 4:48 AM, joehuang <joehuang at huawei.com> wrote:

> Hello, Jay,
>
> > The Telco vCPE and Mobile "Edge cloud" (hint: not a cloud) use cases
>
> 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].
>
> [1] http://www.etsi.org/images/files/technologies/MEC_
> Introduction_slides__SDN_World_Congress_15-10-14.pdf
> [2] http://www.etsi.org/technologies-clusters/technologies/mobile-edge-
> computing
>
> 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.
>
> ( Hope this reply in the thread :) )
>
> Best Regards
> Chaoyi Huang(joehuang)
> ________________________________________
> From: Jay Pipes [jaypipes at gmail.com]
> Sent: 29 August 2016 18:48
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [all][massively distributed][architecture]Coordination
> between actions/WGs
>
> On 08/27/2016 11:16 AM, HU, BIN wrote:
> > The challenge in OpenStack is how to enable the innovation built on top
> of OpenStack.
>
> No, that's not the challenge for OpenStack.
>
> That's like saying the challenge for gasoline is how to enable the
> innovation of a jet engine.
>
> > 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,
>
> That's the thing, Bin, those are *not* "basic" requirements. The Telco
> vCPE and Mobile "Edge cloud" (hint: not a cloud) use cases are asking
> for fundamental architectural and design changes to the foundational
> components of OpenStack. Instead of Nova being designed to manage a
> bunch of hardware in a relatively close location (i.e. a datacenter or
> multiple datacenters), vCPE is asking for Nova to transform itself into
> a micro-agent that can be run on an Apple Watch and do things in
> resource-constrained environments that it was never built to do.
>
> And, honestly, I have no idea what Gluon is trying to do. Ian sent me
> some information a while ago on it. I read it. I still have no idea what
> Gluon is trying to accomplish other than essentially bypassing Neutron
> entirely. That's not "innovation". That's subterfuge.
>
> > the innovation will never happen on top of OpenStack.
>
> Sure it will. AT&T and BT and other Telcos just need to write their own
> software that runs their proprietary vCPE software distribution
> mechanism, that's all. The OpenStack community shouldn't be relied upon
> to create software that isn't applicable to general cloud computing and
> cloud management platforms.
>
> > 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.
>
> Yes, indeed, but the people who created the self-driving car software
> didn't ask the people who created the cameras to write the software for
> them that does the self-driving.
>
> > WE NEED INNOVATION IN OPENSTACK in order to enable the innovation built
> on top of OpenStack.
>
> You are defining "innovation" in an odd way, IMHO. "Innovation" for the
> vCPE use case sounds a whole lot like "rearchitect your entire software
> stack so that we don't have to write much code that runs on set-top boxes."
>
> Just being honest,
> -jay
>
> > Thanks
> > Bin
> > -----Original Message-----
> > From: Edward Leafe [mailto:ed at leafe.com]
> > Sent: Saturday, August 27, 2016 10:49 AM
> > To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at lists.openstack.org>
> > Subject: Re: [openstack-dev] [all][massively distributed][architecture]Coordination
> between actions/WGs
> >
> > On Aug 27, 2016, at 12:18 PM, HU, BIN <bh526r at att.com> wrote:
> >
> >>> 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.
> >
> > 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.
> >
> >
> > -- Ed Leafe
> >
> >
> >
> >
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160830/bd0cff70/attachment.html>