Juniper just completed their SDN event at their partner conference, and as is often the case they haven’t made things easy for those who, like me, are charged with analyzing the result. But we soldier on, and so let me jump right in.
At the high level, Juniper’s SDN strategy is really a Network Functions Virtualization strategy. For those who have followed my commentary on SDN and NFV through this blog, you may recall that I’ve suggested that SDN was effectively a subset of NFV, focusing on virtualizing and hosting the adaptive behavior of forwarding devices. You could do SDN without doing NFV and vice versa, something the NFV white paper suggested as well.
In the Juniper approach, SDN is essentially redefined as targeting the centralization of network-related functions rather than the adaptive control-plane functions. There are two ways that you could understand this.
First, in March of 2011 I published an issue of our technology journal Netwatcher wherein I described the QFabric launch and explained some of the things that I was told QFabric would do. One of those things was to link services along a data path between source and destination within the fabric. Juniper’s current SDN concept of service component chaining is identical to that, except that it’s not specific to QFabric. If you’re a subscriber to Netwatcher and have that issue, read it as a starting point.
Second, if you go back to the Juniper launch of the fall where they defined a new card that would host service features, you may recall that I commented at the time that the initiative seemed to be at odds with the already-defined carrier notion of NFV. What Juniper has done is to allow those service features to be hosted outside the special card on a standard server.
Both of these things end up in the same place, which is that for Juniper “Software Defined Networking” is about virtualizing “layer 7” service components and making them orchestrable as part of a service flow from packet source to packet destination. That’s what makes this hard to analyze, because on the one hand it’s a useful thing and on the other it’s not SDN.
NFV is something operators are serious about, something that creates the framework for the service layer of the future. Juniper is articulating an NFV strategy and that’s a first. Their collateral material on JunosV is explicit in the relationship between the concept and NFV goals, and even though Juniper didn’t get mentioned by operators in our survey (perhaps because the NFV external hosting connection wasn’t in the fall announcement; it wasn’t in my deck) they have now offered a useful NFV model.
The thing that separates it from being an SDN model is that “layer 7” reference made by Bob Muglia in his presentation. The real goal of SDN, what I’ve called “purist” SDN, is to centralize the control function. That would explicitly include the replacement of adaptive discovery with central control. Google’s SDN application is a poster child for that. Juniper isn’t talking about that at all, and in fact they are implying that the control processes remain largely distributed.
Years ago, Juniper’s CTO articulated what might have been the anticipatory form of the SDN principle: Centralize what you can, distribute what you must. I have to wonder why Juniper didn’t take their own advice here. With a few words, they could have created a complete NFV and SDN position, the first public example of that combination in the market. You have to wonder if they didn’t because they were defending their router proposition.
Cisco isn’t happy about purist-model SDN either, but they appear to be devising an alternative that is focusing on providing northbound API controls to permit cloud-to-network application requirements communication and also network-to-cloud status and telemetry to be exchanged. This distributed model of SDN isn’t “purist SDN” either but you can argue that it’s SDN because it meets the black-box test; it looks like an SDN at the external interface. If that’s a part of Juniper’s SDN story they didn’t express it. They also didn’t elaborate on the value that their Contrail buy brings. That will come in the 2014/2015 timeframe when Juniper indicated their SDN approach would be mature.
It may be that in 2015 Juniper will have an SDN approach that would pass the only objective tests I can use to define what an SDN is—either conformance with purist SDN models or support for the cloud-black-box interface-defines-service model. Right now they aren’t providing any proof points for either of those things.
The thing is, their NFV concept is potentially very good. We’re going to present an architecture for the network device of the future in our January Netwatcher, and it wouldn’t be hard for me to make the Juniper story supportive of that model. In fact, they are arguably on the way to the right answer that we’ve defined as their optimum path. If they’d have said this was their NFV approach I could have given them a solid thumbs-up for the story. But they didn’t, and they didn’t establish its credibility as an SDN story.
