LONDON -- Broadband World Forum -- Four years after the ETSI white paper, NFV has moved from concept to testing and into reality for some functions, but with reality comes growing pains around ROI, skill sets and a new challenge: software licensing.
During a presentation on Wednesday, Don Clarke, principal architect of network technologies at
CableLabs , editor of the now infamous
European Telecommunications Standards Institute (ETSI) white paper, reflected on the last four years: "When I look back at this whole technology, I think of it as an analogy with a child. You bring it to life and as soon as it starts to walk, it starts to make mistakes and it gets hurt. By the time it gets to about four years old, it's beginning to start to be sensible but it's not until much later that it starts to reach maturity," he said. "I would say even four years on, we're not there yet. We've got some ways to go."
While questions remain around where operators should deploy NFV to receive ROI, Clarke said he's still seeing major challenges around the migration to a software environment especially around NFV software license management. "I've been approached by several small software vendors at conferences and they don't see how they can interact with a very large operator with licensing. It's a very complex process," he said.
As such, Clarke said that ETSI is undertaking a new study on license management in an NFV world which it hopes to complete by mid-2017. The work will address and include the following:
The impact of software licenses on NFV total cost of ownership
User demands for flexible, scalable and highly dynamic license models
Removing the barrier to entry for software providers (big and small) by simplifying complex and error-prone service provisioning and license renewal operations
Including architecture support in NFV MANO for multiple VNF provider licensing models
Supporting service continuity if VNF licenses are not available
Working with TM Forum for license management's impact on OSS/BSS
— Elizabeth Miller Coyne, Managing Editor, Light Reading
Customer54848, User Rank: Light Beer 10/26/2016 | 2:46:54 PM
Complex issue that does require a lot of thought. This is a very worth goal for sure. Working for a vendor and selling into large telco carriers I have seen the challenges personally for at least a few years.
Typically network gear in the PNF world used to be sold based on criteraias like sessions carried, Tput rating per dedicated function etc.
The NFV world is way difefrent, customers now have the expectation that the underlying hardware is paid for separately and the software license for the VNF is bought from best of breed vendors, and since the operators are prime integrators and responsible for hardware, they can arbitraily add more and more powerful hardware to get better performance without having to spend any $'s ever again .
Throw in things like DPDK/SRIOV , faster compute , it only keeps getting more challenging.
Whle logical to think this should be true, it fundamentally breaks te business mode for vendors who need recurring source of revenue to improve prodcts and stay viable in the market place.
I suspect having a uniform mthod of licensing that is acceptable to operators and vendors is going to be hard. But neverthe less a formal study would be very helpful to highlight the challenges of balancing expectations, benefits and cost/revenue potential in this brave new world of VNF and NFVi
arikyakir, User Rank: Light Beer 10/21/2016 | 2:44:49 AM
The license issue is a model and integration based Hi
As i see, the license model is 2 layers issue-
For the infrastructire use (how many services, how many VNFs per service, how many reources consumed?)
And for the VNF vendors as mentioned, they provide a VM image file, sometimes link to licensing system, but as the VM instances are constantly spawned, removed etc., keeping track of the usage makes a big different from the traditional physical shipment and inventory tracking.
Attempts to solve that sums to OSS counting services using KPIs from the NFV MANO, but it still pose issues of reliability in some cases
The vendors of MANO parts need to assemble a simple mechnism with plain interface to BSS, such approach, if ETSI will standartize it, will force the vendors to be aligned , without impacting each ones approach for internal implementations>
I see the vendors and the providers are looking for standards for some topics which are not in the "core business" (at least for the vendors). the licensing business falls under that and is indeed a great place to standartize
Carol Wilson, User Rank: Blogger 10/20/2016 | 10:34:26 AM
Major issue here This is going to be a significant issue and I don't think it will just impact smaller companies - I think the impact is going to be industry-wide, which seems to be what ETSI is trying to address here. '
It's good to see some formal activity in this space.
To save this item to your list of favorite Light Reading content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
(3) | 
Digg
Del.icio.us
Reddit
Tweet This