Juniper continued to develop its Contrail/SDN strategy, with an announcement it was open-sourcing a version of its Contrail SDN controller, which is also available via a traditional commercial-support license. The move says a lot about the SDN space, and it also may give a hint as to how Juniper might (emphasis is important here) exploit and differentiate SDN.
In a real sense, SDN is an ecosystem building from the bottom up. We started with OpenFlow, a research-driven protocol to control forwarding table entries, and we’re working up toward some hopefully useful applications. One critical element in that climb is the SDN controller that translates notions of “routes” and “services” into forwarding commands. A controller is a necessary condition for OpenFlow but not a sufficient one; you need applications that convey service/route intelligence to the controller. That’s where all the SDN strategizing comes in.
The APIs that link what I call “service models” to OpenFlow controllers are those infamous “northbound APIs”, infamous because everybody talks about them but there’s relatively little substance provided. We count nearly 30 controllers on the market or in open source today, and as far as I can tell none of them share northbound APIs. That’s where this ecosystem stuff comes in, because if you need services for SDN you need service models and translation of those, via northbound APIs, to OpenFlow (or something). If you make it too hard to get your controller you won’t get anybody to author those northbound apps and you have no service models and no real SDN utility. So you open-source your controller to encourage development.
Juniper will obviously get some takers for this approach, and in fact some were announced. The challenge Juniper faces is that Cisco’s OpenDaylight has much broader support and much wider name recognition. Given that the average user doesn’t know anything about those northbound APIs, it’s fair to say that “all in a name” applies here more than usual. For our CloudNFV initiative, we have very strong interest from the open source community in a Service Model Handler for OpenDaylight, but none so far for Contrail.
So what does Juniper do about this? I think there are two tracks they can take. First, they can shine a light on the whole question of service models and northbound APIs to make prospective users/buyers understand what’s going on there. Second, they can start applying their API principles to real network issues in a conspicuous way so that their platform is perceived to have immediate value. NFV might be a useful place to start.
For two possible paths to visibility, Juniper has two barriers to confront. First, any organized appreciation for service models in SDN will have the effect of making the path to SDN adoption a lot clearer, and you can implement SDN using software switches/routers. That could cut into the sale of real switches and routers, and so Juniper like other network equipment vendors has been a bit reluctant to trot out a strong service model story. Second, this is a software ecosystem and Juniper is fundamentally a hardware company. If you look at things like the cloud, you see Juniper building not a developer program but a channel program. They want people out there pushing Juniper boxes. That’s a problem when you’re trying to build an ecosystem north of a vendor-independent standard.
Juniper has some interesting assets with Contrail. I’m of the view that SDN is a two-layer model, with an agile software-based layer controlling connectivity and a deeper hardware layer managing traffic. This model would normally require some form of cooperative coupling between the layers, and Contrail extends that coupling to the exchange of address information. I think it could easily be made to provide service-model communication from the application down through transport and across to adjacent branch or data center sites. In short, it would be a decent framework for a cloud-like ecosystem and a nice way to frame service models in a general way. It would be, providing Juniper articulated that view—and believed in it.
And of course there’s the time factor. A move to establish a Contrail SDN ecosystem would likely provoke a response from Cisco and OpenDaylight, and there’s little question who would win if the battle became a long slog. What Juniper needs is a strike, a strong and sensible program to create and publish a vision of future networking that is compelling because it’s sensible. I don’t think that’s all that difficult to do at this point; you can see what networking-as-a-service has to look like already, and how it has to be created. The cloud, SDN, and NFV have combined to give us all the pieces we need to bake a nice cake. We just need a baker.