Last week at Interop, Juniper offered a bit more detail on its Contrail stuff. I didn’t get any press release on this, perhaps because Juniper has done a number of SDN announcements already and considered this a follow-up. At any rate, the additional detail offers some color on what might distinguish Juniper’s approach from others. It’s a story that makes sense, though I still have concerns about the targeting.
The launch point of the Interop preso on what Juniper is calling the “JunosV Contral Controller” is a discussion of the traditional SDN model, which uses the notion of mother-may-I forwarding of packets. A source emits a packet and the first switch kicks it to the controller for instructions. That might set up a complete route or only a hop, in which case the process would repeat itself. There’s a strong implication in the traditional view of OpenFlow that you’re setting up fairly granular flows, perhaps per relationship. As I’ve pointed out many times, the mother-may-I idea is simply unworkable; the only rational approach to SDN is to presume that the controller would preconfigure paths based on connection policy. If the controller knows where a packet should go when it’s first presented, it knew all along. I think most vendors with serious SDN positions have accepted that premise; the question is how to make it work.
What Juniper proposes instead is the two-layer SDN model I’ve mentioned in connection with some other announcements, but with a twist. As always, overlay virtual networking in the software/Hypervisor layer is the top of the structure and network equipment is at the bottom. If you let SDN control only the software virtual network, you create agility where there’s no inertia and little in the way of scalability issues. The underlying network (IP in Juniper’s case) would be a network of physical things, the overlay a network of virtual things. Obviously I agree with this model; I’ve promoted it in blogs before.
Juniper makes another point I agree with, and perhaps even more strongly. They point out that OpenFlow was designed to be a packet-forwarding-control protocol that optimized its structure to the nature of forwarding tables in real devices. For other missions, this specialization is pretty seriously sub-optimal, and “other missions” includes the control of virtual switches. An XML payload in XMPP or OVSDB are better approaches for the vSwitch control mission (XMPP perhaps a better general approach for control exchange).
The Contrail approach is to integrate the forwarding management of the software virtual switching overlay across devices and downward to the physical network by essentially extending the MPLS VPN (RFC 4364) into the virtual switching overlay, creating a software-hosted BGP IP-VPN PE. This replaces traditional vSwitching with something more integrated and also likely more scalable. Contrail also promises cross-controller federation to support services/applications that cross provider boundaries.
I actually like this approach and I wish Juniper had been more specific on how it would work earlier on. I don’t see why it couldn’t be made an end-to-end approach too, meaning that it could be extended out to branch offices, although Juniper doesn’t show that on their slides. It would seem to address, given that extension, both the needs of cloud computing (enterprise and providers) and the emerging requirements for NFV (which Juniper does mention in passing in their material). More details on end-to-end and also on the federation support would be helpful, of course, and without them I can’t give Juniper’s approach the same endorsement for covering the enterprise waterfront that I gave to the Alcatel-Lucent/Nuage announcement. In the federation space, BGP federation covers only connectivity and it’s not clear whether further integration via XMPP might not be required or at least valuable in inter-cloud or NFV missions.
The biggest positioning issue we see for Juniper is its continued reluctance to shift its emphasis from SDN (where a report just cited Juniper saying no cost savings would be generated) to NFV. I’m not trying to promote a new hype wave here, just acknowledge that you have to shoot new concepts ahead of the market to get a clean shot and avoid the clutter. To showcase the vision Juniper has, SDN isn’t far enough ahead.
NFV demands coherent integration of cloud/network technology for service creation, federation of providers at both levels, and significant management integration. All of this should be music to Juniper’s ears. Their IPsphere initiative was the first carrier-supported standards activity to address cloud technology for network services, the first to formally federate, and the first to develop a management approach to hybrid network/IT services. There must still be some people there who remember the period; if so, Juniper should trot them out. They’d make a heck of a lot of sense at this time, enhance Juniper’s NFV stance, and perhaps find some real traction points for what’s a decent implementation.