Networking is a pretty competitive business at all levels, and network operators promoting SDN or NFV believe those technologies increase competition and improve pricing. Both SDN and NFV promote competition in an official sense, but that won't stop vendors from trying to gain competitive advantage. Might that threaten competition itself, and if so can we address the risk?
Software-defined networking (SDN) competition risk number one is supplier credibility. Who do you scream at if your open source controller fails? How deep are the pockets of white box switch vendors in supporting new requirements or even repairing problems? Who integrates and stands behind these loosely coupled SDN ecosystems? Many users find the answers to these questions unsatisfactory, and so they're inclined to look to their current vendors to "evolve" them to SDN. That's not broadening the competitive landscape much.
SDN risk number two is the evolutionary inertia risk. We aren't going to get to SDN by the out-with-the-old approach, particularly in the enterprise. Evolving to SDN means starting without it, and adding SDN-ish features to legacy devices. Of course, not all vendors see SDN evolution as requiring OpenFlow control. For example, Cisco's Application Centric Infrastructure model delivers software control with legacy technology. That doesn't change the competitive landscape either.
The solution to these issues is to rely on hosted virtual switching wherever server performance permits. Even if we want to have real "white boxes," the best way to get them would be to create an active vSwitch market that would strike fear into major switch vendors' hearts. The virtual switching threat would be all the more powerful if supported by large vendors that buyers would find extremely credible.
Network functions virtualization (NFV) is a much more complicated problem. There are three broad categories of "product" in NFV. The largest in terms of investment is NFV infrastructure (NFVi), which means the servers and switches that build virtual functions and connect them into services. Next are the virtual network functions (VNFs) that provide service features, and then there's the NFV management and orchestration software that drives all of this. What's the competitive situation in these three areas?
It's critical to operators that NFVi be as open and competitive as possible to reduce capex. NFVi isn’t directly used by NFV, it's accessed through an Infrastructure Manager (IM or VIM for the "virtual" form). In theory, any two infrastructure managers that understood the same commands would work interchangeably, and if we had infrastructure managers for every vendor’s servers and network gear we’d be open and competitive.
The challenge is that we don't have a firm picture of what commands to an infrastructure manager would look like, nor do we have a specific model of how many commands you could have. NFV must be able to support many IMs to open up vendor choices and even implementation choices, and there needs to be a set of common commands or models that IMs for various types of infrastructure have to understand.
VNFs are the functional key to NFV. If you don't have them there's nothing to deploy, so it doesn’t matter how efficient your deployment might be. We have a pretty large number of hopeful VNF suppliers out there, and even a good number of different business models, ranging from free open source to commercial license to pay-as-you-go or even third-party hosted.
The risk to a competitive VNF market lies in different onboarding (preparing a VNF to be used) practices per implementation of NFV. The best approach would be to say that any piece of software that can run in the cloud can be onboarded to become a VNF without change. Nobody seems to be saying that, but clarity in the onboarding processes could make it clear whether VNFs are portable. VNF providers should cite their own onboarding requirements, and suppliers of NFV implementations should tell us what they can accept from VNFs.
The NFV implementation itself, meaning management and orchestration (MANO), is the final point of competitive risk. To have competitive MANO we need to have specifications that make the complete NFV business case and that cover all the issues that could arise at each NFV interface. We're working toward these goals but we're not there yet, and that means that a successful piece of NFV software would almost certainly have to be pre-standard or non-standard.
This is the hardest issue to address because there seems little hope that we could have true MANO competition without the next round of European Telecommunications Standards Institute (ETSI) NFV ISG changes to the specifications. In the meantime, the best solution would be to forget for the moment the goal of supporting any MANO implementation interchangeably and go for supporting a bunch at the same time.
NFV "federation" or the building of services across separate NFV software stacks could at least let operators harmonize multiple implementations. Federation also requires an extension to current specifications, but it's probably more realistic to shoot for that one thing than to hope all the open MANO issues could be resolved quickly.
None of these issues will be hard to resolve, and all will likely be addressed over time. The sooner the better, though, because innovation and competition go hand in hand.
— Tom Nolle, President/Founder/Principal Analyst, CIMI Corp., special to The New IP