[c-nsp] Virtual CPE / NFV

[James Bensley]

On 22 July 2016 at 00:42, CiscoNSP List <CiscoNSP_list at hotmail.com> wrote:
> Hi Everyone - Slightly off topic, but am hoping some of the brains trust on the list can provide some feedback/experience in the vCPE/NFV area.
>
> We predominantly provide L3VPNs to customers, supply the CE (TYpically over spec'd to allow for future growth), and as this model "works", it is quite resource intensive (Provisioning CE, deploying), and makes the value add proposition a little more challenging (i.e. providing cloud-based services, firewall, IPS etc)....vCPE (theoretically, anyway!), looks like a much "better" model...i.e. CE lives on our "core" infrastructure, allowing for more dynamic(Simple/Fast/flexible), deployment of value add services(i.e. Its done all on the Core), and it also provides better scale to customer tails (L2 to customer(Instead of L3, scale/bandwidth growth is "easier"?))
>
> Ive spent a little time reading up on Cisco's offerrings in this area, and who in the market place is using this type of model (successfully), but would appreciate any feedback from anyone who is currently using this type of a model, or is considering moving in this direction...and also any feedback from anyone who thinks its not a mature enough model (yet) to be considering...It seems a logical path forward from our current way of doing things, but devils always in the detail, and I imagine there are a number of complexities/challenges to overcome to deploy successfully.
>
> Thanks in advance for all replies :)


So I think this is quite do-able, I've looked into this a couple of
years ago but on one wanted to do it with me [1] so I dropped it. This
is just off-the-top of my head so take it with a pinch of salt...

The major requirements and restraints I identified are as follows (I
looked at how I could shoe-horn this into $dayjob's specific
environment so the usual "your scenario is not my scenario" caveat
applies):


CE Hardware:

- We still need a low price low spec CE to go on the end of our
circuit at the customer site so that when the circuit shows as down
from our exchange end (CLEC/CO end) we need to know it’s our
circuit/CE rather than the customer terminating on their downed kit,
so we need something we can ping and poll.

- Following on from the above, we might need something on site that
can provide basic QoS if the WAN circuit is slower than the LAN
connectivity at is a choke point.

- It wasn’t easy to find a device that was good and cheap and fast in
these respects, also we probably want a variety from 10Mbps to 10Gbps
etc, without having 10 different models or vendors of CE.



vCPE Software:

- The vCPE software needs to support everything our customers are used
to, we can’t just run Linux VMs with iptables and OpenVPN, we need
CSRv style feature rich vCPEs but they need to be cheaper, but also
include 365x24x7 vendor support so something like pfSense wouldn’t do
either, and also be light on resources so we can spin up lots of them.

- Scaling the vCPE hypervisors is difficult at low traffic volume
level PoP sites; el-cheap-o server won’t do, we need dual compute
style nodes with automatic failover and fencing, in the case of vCPEs
a hypervisor death means multiple sites down, the traditional model of
hardware CPEs means one CPE death == 1 site down. It’s hard to get
good/reliable high availability for pennies. For larger PoPs it would
of course be easier to justify the cost of some beefy nodes.

- Rack space, power and cooling are an issue at many of our existing
PoPs. In the UK we provide LLU services in many telephone exchanges
across the land, retrofitting this to existing PoPs would be a chore.
In some places we'd need to aggregate back to further up the topology,
but then the end sites are further away from their layer 3 gateway.
This introduces many issues, like we don’t want inter-site traffic for
two customer offices hanging off of the same PoP going half way up the
country and back.


Today things might be better in terms of hardware price / performance
/ space ratio etc (it seems that way to me with minimal
investigation).


Other commercial issues cropped up too:

- How will we sell this? It’s not had years of trials and live
customer usage, so not many of our existing customer base will go for
this.

- How will we support this? We probably can’t match the SLAs of our
current hardware based offering (probably in the future, but at that
time, no).

- Usual cruft about in-house training required for any skills deficit
and OSS and BSS systems need to be brought into line etc.


Just some food for thought.

Cheers,
James.


[1] Worlds smallest violin etc etc...