One of the fascinating things about SDN is that it’s become even fuzzier than the cloud. We can’t agree on anything about it these days, including the very basic question of how we’d recognize an SDN if we saw one. This level of uncertainty is magnified when we have SDN-related announcements, because more often than not they don’t really announce the details. We’re left to speculate on what SDN is and then on whether this new thing is SDN is not.
Juniper’s decision to buy Contrail is one of these two-degrees-of-speculation things. Juniper had previously talked about an SDN vision that had the basic layered structure that I’ve been calling for in assessing SDN functionality. You need cloud exposure at the top, network telemetry at the bottom, and SDN in between. One of Juniper’s key technical guys, Kireeti Kompella (a self-described “MPLS Fiend” who even had that as his title on his business cards at one point) went to Contrail and that’s led to speculation that Contrail is one of those spin-in plays we’ve come to know and love. Cisco and Alcatel-Lucent both have spin-in strategies for SDN already.
But what are they spinning in with the Contrail deal? Kompella spoke at a technical conference at one point and talked about the Contrail approach as an “OpenFlow compiler”, a software product that took network functional requirements and converted them to OpenFlow commands that created a suitable network. If you took this literally, then Contrail is a kind of SDN supercontroller, enveloping likely all three of the layers of SDN I’ve been talking about. The question is whether we should take this literally.
Contrail is in stealth mode, but “stealth” today means more “coy” than “silent”. The company’s blog talks about the dualistic nature of virtual and physical networking for the cloud, suggesting that the two will evolve in parallel. They also go through a laundry list of what’s wrong with various network technology solutions to the problems of SDN—problems including the scalability in the number of hosts. A particularly interesting point one blog makes is that you really should limit VLANs to about 500 hosts maximum to avoid multicast issues.
Virtual networks are either overlays or they’re embedded and implemented on network devices. Nicira is an overlay strategy, and things like VxLAN are embedded virtual approaches. If Contrail goes overlay, they would have to address how the “real” network gets “software-defined” since overlay networks are just traffic to the underlying infrastructure. If Contrail goes embedded, they have to address how you can define a new network protocol as a startup without simply contributing it as a standard and losing control. If that happens, what did Juniper pay over $170 million for?
It would seem that at the minimum, Contrail could look like a cloud DevOps tool, something that takes virtual directions and then tunes physical infrastructure as required, perhaps as an implementation of a cloud API like Quantum. That would be helpful, I think, but it doesn’t raise the SDN bar relative to Juniper’s competitors. So, following my usual practice of looking for the BEST possible play, Contrail might be mixing DevOps and virtual overlay principles.
Imagine that the “upper-Contrail” looks a lot like Nicira and a lot like the “Cloudifier” layer in my SDN model. It presents a virtual set of network services to the cloud just like Nicira does and just like Quantum expects. One part of those services is the flexible segmentation that we’ve come to know as part of cloud virtual networks; you can define as many virtual networks as you want independent of lower-layer protocols. Another part of the services COULD be a way of centralizing and supporting things like topology discovery without spanning tree, and multicasting without using the low-level Ethernet tool. Agent-based multicast, for example, might mean sending a multicast message to a virtual agent who then distributed it to the members of your virtual network.
The lower-Contrail could look more like DevOps, manipulating the northbound interfaces of current standard protocols and creating and controlling the real infrastructure behaviors that the sum of the virtual networks demands. This would be a pretty decent thing for an avowed MPLS fiend to work on, I’d say. The lower-Contrail could also be made to work with current network devices or with OpenFlow devices, making the “OpenFlow compiler” characterization true, and it would harmonize the physical and virtual evolution that Contrail’s blogs talk about.
So is that what Contrail is doing? If it is, it could be significant enough to not only justify the $170 million price of the deal but also Juniper’s SDN strategy. It could be a contender, and thus Juniper could become one in a single stroke. But of course I have no idea whether this is what Contrail is doing (I really don’t, for those who might wonder if I have inside information). And Juniper hasn’t been a company to swing for the seats with that sort of aggressive positioning in the past. Contrail could still be little more than a way of provisioning Juniper boxes for the cloud, something that may have some tactical value but would have no strategic value. In fact, it would call into question whether Juniper really has any SDN plans at all.
We have, then, not only two degrees of speculation about Contrail, but three degrees of speculation about spin-ins. Alcatel-Lucent, Cisco, and now Juniper are pinning part or all of their SDN hopes on stealth projects. It’s nice to read a good mystery but it’s kind of expected that in the end you’ll find out who did what. Hopefully we’ll find that out with all this SDN steath positioning too.