John Chambers said a while ago that the “white box” players were dead and that Cisco had at least helped to kill them. This is the sort of Chamberesque statement that always gets ink, but we always have to dig into those sorts of statements. “News” means “novelty” not “truth”.
The whole white-box thing was in large part a creation of the hype engine (media, analysts, and VCs) linked to SDN and later NFV. The idea was that SDN and NFV would displace proprietary network devices. Since software has to run in something, the “something” left behind when the last vestiges of proprietarism were stamped out was white (for purity, no doubt) boxes. SDN, in particular, was seen as the launch point for a populist revolution against big router/switch vendors.
Why didn’t this work? Well, let me start by posing two questions to you. First, “What brand of car do you drive?” Second, “What brand of milk do you buy?” You likely have a ready answer to the first and no idea on the second. The reason is that milk is a commodity. White-box switches are by definition featureless commodities, right? One instance is as good as another. So let’s now pose a third question. “Who spends money to advertise and promote a featureless commodity?” Answer, “Someone soon to be unemployed.”
Not good enough? Let’s look at another angle, then. You’re going into your CFO’s office to buy a million dollars’ worth of network goodies. “Who makes it?” asks the CFO. Choice 1: “Cisco.” Choice 2: “I don’t know, it could be anybody.” Which answer is best?
Still not good enough? Third slant, then. You’re called into the CEO’s office because the network is down and nothing that was supposed to be working is working. CEO’s question: “Well, who do our lawyers call to file the suit?” Choice 1: “Cisco.” Choice 2: “Gosh, I think their name is ‘FlownAway Switching’ this week but it’s changed a couple times since we installed.” How far into orbit does the CEO go for each of these choices?
There’s solid facts behind the whimsy here. Companies want stuff to work, and most would admit they could never hope to test every choice fully. They rely on “reputation”, which means that the name is widely publicized, the product concept seems to be market-accepted, and the vendor is large enough to settle a lawsuit if it comes to that.
The point here is that it’s true in one sense that Cisco killed the white-box movement. Had Cisco spent its marketing money and skill promoting featureless, commodity, switch/routers, the movement would have succeeded—and Chambers would have been gone a lot quicker. Incumbents will never fund their own demise, so the deep truth is that natural market forces killed white boxes, for now at least.
These same market forces impact SDN and NFV more broadly. One of the interesting things about NFV, for example, is that the standards-science-and-technology teams tend to like network vendor implementations of NFV while the CIO and CFO tend to like computer-vendor implementations best. The reason is simple; you want NFV to be offered by a vendor with a lot of skin in the game. If infrastructure transformation through NFV means a shift to servers, why not pick a server vendor? They have more to gain and lose.
I think that announcements of server products or partnerships by Alcatel-Lucent and Ericsson reflect this truth, and also the flip side, which is that if NFV is going to be a consultative sell (and if it’s not then I don’t know what would be!) it makes sense that vendors would be more inclined to stay the course if they could benefit strongly from a successful outcome. Think of an orchestration player going through all the hoops of NFV orchestration and management validation to get perhaps a couple million out of a multi-billion-dollar deployment.
I also think there are support issues here. NFV and SDN both present the operators with a dilemma. On one hand they are all committed to a “no vendor lock-in” position and extremely wary about having a vendor create one or more NFV silos. On the other hand they’re wary about being gouged on integration and professional services.
What they should want is what you could characterize as “open product suites”, meaning that they want SDN and NFV to be based on principles/architectures that at least open up the areas where most product spending will happen. Thus, perhaps the most important single piece of NFV is what I’ve been calling the “Infrastructure Manager”, a subset of which is the ETSI VIM. If every piece of current or future hardware that’s useful in service deployment can be represented by an IM and orchestrated/managed, then operators have openness where it counts.
Getting to that point is really about the MANO/IM interface, just as getting to a universal and open vision of SDN is really about how the northbound interfaces talk with whatever is northbound. An SDN controller is a broker for NaaS. You need to be able to describe the connection model you’re looking for in a totally implementation-independent way, and then translate that model into network setup for whatever is underneath.
That works with NFV too, but it’s more complicated because NFV deploys functional elements and connects things, so the scope of what has to be modeled is greater. People have proposed YANG as a modeling language for NFV MANO interfaces, but YANG is best used as a connection model. We have some insight into what process models should look like with OpenStack, but OpenStack also has connection models (via Neutron) and these models are currently limited to things that application/cloud applications would want to set up, which means IP subnets and VPNs and so forth.
It’s the management of these abstractions that creates the challenge for both, however. If I have an intent model in abstract, and I’m going to realize that intent through resource commitments, then I need to have three things. First, I need to know what the management of my intent model would look like. Yes, I have to manage it because that intent model is what the customer is buying. Second I have to know what the management of the committed resources is like, because you can’t fix virtual problems. Finally, I have to know the derivations or bindings that describe how intent model management can be derived from the real resource management.
Where is all this stuff in SDN and NFV? Nowhere that’s even proximate to utility. Thus, we’re forced to presume that if SDN and NFV are adopted, current management practices and tools will be less useful because we’re losing the ability to manage what we’re selling, or at least disconnecting that from the management of the real resources used for fulfillment. We can’t do fault tracking when we can’t see the connection; we can’t present a user who bought a firewall or a VPN with the need to manage real resources that wouldn’t in the user’s mind even be part of such a service. Virtualization, to work, must be transparent, and transparency can be achieved only by abstraction.
I see some signs that there are operators in the NFV process who agree with this position, and we may be able to fix things at the specification level. The question is whether we could define a suitable abstraction-based vision of IM/VIM and its interface with MANO or northbound apps in time to test the full range of service lifecycle processes for NFV and SDN. If not, we’re going to have a hard time putting together a convincing field trial, and a hard time ever making anything other than “current boxes” winners.