Axians UK News and Insights

NFV Today = Software Soup and Pricing Palaver

Written by Axians UK | Sep 30, 2014 9:06:46 AM
“Software Defined Networking is going to simplify provisioning…”
“…make all our lives easier”
“…single pane of glass…”
“…zero touch provisioning…”
I’m sure you’ve heard phrases such as these over the past few months and years. I believe some of these assertions are true of SDN – in part at least. But with NFV today, it’s really not quite that clear cut.
I find that many of my customers assume that NFV solutions will decrease management complexity and simplify provisioning. My observation of such solutions today, is that the number of management touch points potentially increases – not decreases – with NFV.
Let’s take the vCPE use case. I have a working demo solution in my lab, with a “simple” L2 CPE and “Zero Touch Provisioning” for the end user – just plug and play! Let’s say your L3 vCPE is a virtual firewall, service chained into an Internet VRF via a PE router. Let’s consider the number of individual management touch points here.
  • Even though the CPE itself is “zero-touch”, some CPE provisioning still needs to be done by the Service Provider
  • Standard provisioning (probably) at the hub site aggregation device to connect the customer circuit the SP network
  • Work with OpenStack and/or favourite SDN Controller to provision the customer, spin up the virtual firewall, and connect into the relevant VPNs
  • Provisioning of the “out-of-the-box” virtual firewall, probably using existing standard firewall provisioning tools. Firewall rules, NAT etc needs to be configured somehow
Today, if you look at most of the big vendors, there are a number of software systems and components which need to be brought into play. The number of touch points has gone up, not down. And how many servers are required to provide the full service in a resilient fashion? In my lab, I count at least seven!
Most big vendors are realising they need to consolidate these management systems. ETSI have a Management & Orchestration Working Group (MANO) for NFV, which is providing reference architecture for NFV Orchestration. Many vendors are professing that their soon-to-be-released “NFVO” software will solve all of these issues in one fell swoop. Now I’m an optimist, but I’m not holding my breath for this utopia any time soon.
Vendors are  now focussed on how to license such solutions cost effectively – trying to switch from hardware-based  “tin-shifting”, to a usage-based software pricing model… and some are struggling with their maths, with some NFV solutions trying hard not to price themselves out of the game.
In short, I think NFV may have a bumpy ride trying to break out of the PoC lab, and into production networks. It will get there, and I’ll be there helping to guide the brave pioneers. The reward of course is incredible agility, flexibility and a much accelerated time-to-market. But be prepared for some software soup and pricing palaver along the way.