Genuinely ‘open NFV’ gives operators the ability to change tack according to technical and commercial developments. It enables them to shop around for best of breed solutions and blend a mixture of, say, migration-oriented hybrid solutions with white or grey-box CPEs and connect them all to their choice of orchestrator. It also dramatically improves their negotiating power.
Yet, despite appearances, few NFV vendors practice ‘genuinely open NFV’ and instead disguise how they intend to close and lock the front door once their customer has stepped inside.
There are five common traps that vendors set for operators as they entice them toward ‘open NFV’ contracts:
1) Charging for third-party connections
One of the world’s biggest orchestrator providers makes bold claims concerning openness, but then charges the operator prohibitively if they ask to connect third-party devices. How does $40k per device type sound? Sounds like hidden lock-in to us.
2) Scare-mongering
Frequently, vendors will claim openness but then quickly close down as the multi-vendor solution is being specified: ‘We have tested that combination and we’ve got to tell you that it’s very difficult to make it work. It isn’t impossible, of course, but it will take an awful lot of integration work and support from us [subtext: expensive] and frankly the other vendor has a way to go to demonstrate the maturity of their solution in your [our] environment. On the other hand, our own solution plugs right in and works straight away…’
3) Northbound open, southbound closed
Despite marketing their openness with a REST API for northbound communications to other management applications, several vendors have opted to either deploy proprietary messaging protocols in the southbound interface of their management applications (which communicates with the device being configured) or to wrap proprietary extensions around an otherwise open protocol. Buyers beware; this means that only its product will be able to interoperate with the management layer.
4) The performance question
If the scare-mongering doesn’t work, vendors often look to discredit the performance of a multi-vendor solution relative to its own proprietary offering: ‘Sure, we support other vendors, but our solution works far better when linked to our own VNFs and orchestrator.’ Operators would be well advised to dig further here. A review of the extent of the performance testing, the similarity between the lab setup and the proposed field environment and the performance testing data itself, should soon reveal the integrity of this claim.
5) The grey-box trap
‘Yes, don’t worry. Our NFV solutions are based on open standards. We support NETCONF and YANG and our grey-boxes include x86 support, one of the most ubiquitous computing platforms in the world!’ So, if that’s the case, to what extent is the proprietary hardware necessary? Perhaps it can be justified in the case of high-speed switching but the more common use case is to support routing or SD-WAN and here the performance benefit is more questionable. As well as dependence on the proprietary hardware for core network functions, there is also the question of cost where essentially the user is paying for two compute platforms in the same appliance.
These traps are mostly based on the allure of ease of integration. Yet genuine interoperability happens by design; there is a big difference between supporting open standards and designing solutions that freely operate in an open environment. In the main, if a vendor supports NETCONF and YANG, and can demonstrate that its solution can either configure and manage third-party devices or host third-party VNFs, then its claim to openness has at least some validity.
Virtualization is a once in a generation chance for operators to take back control of their networks. To do so, however, operators must resist the siren calls of many vendors, whose appeal is based on the seductive lure of an easy life rather than on delivering the real benefits of openness.
