On 24/08/16 20:37, Jay Pipes wrote:
On 08/24/2016 04:26 AM, Peter Willis wrote:
Colleagues,
I'd like to confirm that scalability and multi-site operations are key
to 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). BT would therefore support a Massively
Distributed WG and/or work on scalability and multi-site operations in
the Architecture WG.
Love all the TLAs.
I think you mean ETLAs ;)
It seems to be an unfortunate occupational hazard of working in
networking that over time one loses the ability to communicate with
people using, you know, words. (I used to work in networking, but the
good news is I'm still optimistic the damage is reversible ;)
I've asked this before to numerous Telco product managers and engineers,
but I've yet to get a solid answer from any of them, so I'll repeat the
question here...
How is vCPE a *cloud* use case?
From what I understand, the v[E]CPE use case is essentially that Telcos
want to have the set-top boxen/routers that are running cable television
apps (i.e. AT&T U-verse or Verizon FiOS-like things for US-based
customers) and home networking systems (broadband connectivity to a
local central office or point of presence, etc) be able run on virtual
machines to make deployment and management of new applications easier.
Since all those home routers and set-top boxen are essentially just
Linux boxes, the infrastructure seems to be there to make this a
cost-savings reality for Telcos. [1]
So I just heard of this today and looked it up. And unsurprisingly the
explanations were mostly unclear and sometimes conflicting. (If you want
to marvel at a rare instance of perfection in the genre of complete
gibberish, check out http://www.telco.com/index.php?page=vcpe) However,
I didn't come away with the same understanding as you.
My understanding is that they're taking stuff which used to run on edge
devices (i.e. your home router or set-top box) and instead running them
in the cloud:
http://www.nec.com/en/global/solutions/tcs/vcpe/index.html
http://searchsdn.techtarget.com/definition/vCPE-virtual-customer-premise-equipment
Basically as last-mile networks get faster, the bottleneck is no longer
edge network bandwidth but the flexibility of the edge devices. So the
idea, as I understand it, is to not run _more_ on them but to run _less_
and make use of the network bandwidth available to move a bunch of
services into the cloud where they can be more flexible.
(Honestly, this sounds like the most cloud-y use case since those
thermostats where you can't turn on the air conditioning without asking
Google what they think about it first.)
Where I'm guessing this differs from other cloud use cases is that you
want the newly-virtualised services running as close as possible to the
edge. The user is essentially making the provider part of their layer 2
network, so there's a number of drawbacks to having all of the
virtualised services running in a single centralised cloud:
- It'd add a ton latency at a point where applications aren't expecting it.
- It'd start pushing some of your local traffic over the core network,
where bandwidth is still very much scarce.
- It's really hard to keep a large number of layer 2 networks segregated
from each other all the way through the core network (Ethernet gives you
only 4094 to play with).
So I'd imagine that what they want to do is run a small cluster of Nova
compute servers in e.g. your local telephone exchange, plus keep very
tight control over how the workloads running on them are connected to
actual physical networks. Then think about how many telephone exchanges
there are in, say, Britain and it's obvious why they are interested in
ensuring OpenStack can cope with massively distributed architectures.
Hopefully somebody who had heard of this stuff before today will jump in
and correct all of the incorrect assumptions I have made. Remember: use
your words! :P
cheers,
Zane.
__________________________________________________________________________
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
