There have been some LinkedIn discussions regarding my blog on Juniper’s Wandl buy, and some comments have opened the broader question of whether policy management and path computation might be a factor in the deal, even to the point where they might be incorporated into Juniper’s Contrail SDN controller as a result of the buy. So the question is whether 1) there’s a link between traffic analytics and path, policy, or SDN control, 2) whether this might be behind the Juniper buy, and 3) if so, is it good enough reason. To get to these answers we’ll have to excurse a bit into Cisco’s Cariden deal as well.
At a very high level, there are two views of how networking will evolve. In one view, current adaptive network protocols and devices are enhanced to make networks more responsive to business and application needs. Think of it as “adapting with boundaries”. In the other, we step away from the notion of adaptive network behavior in favor of more explicit and centralized control. You might have expected that we would argue this was the “legacy versus SDN” choice, but both sides call their approach “SDN” so we’re kind of deprived of that easy out.
There are also two views of what drives “evolution” of networks. In one view, it’s driven by traffic. The goal of networking, under this view, is to handle traffic efficiently so as to reduce the overall cost of both network equipment and network operations. In another view, evolution is driven by services, meaning differentiable things that can be sold. This particular dipole could be called the “Internet versus managed services” or “dumb versus smart”, but everyone salutes the Internet and nobody wants to be dumb so that characterization isn’t helpful either.
We can also say that there are two visions of where we care about any of the other visions. One says that the “core” is the heart of the network and that big iron and bit-pushing are what it all comes down to. The other says that the great majority of profit today, and credible future profit, would involve services with traffic topologies that span a single metro. They say that revenue per bit in the core is the worst in the industry, so why invest there. Their opponents say that’s why you have to invest there. Users don’t care because they don’t understand how we build networks anyway.
What everyone sort of agrees on is that you have to optimize something, somewhere and that’s likely to demand that you understand what’s going on. So we can presume that there would be a kind of marriage of data-gathering and analytics that would present a vision of operations, likely now and in the past, and would be able to support decisions of some sort based on that vision. We could apply that knowledge in a number of ways, and in fact we could use it to support any of the poles of any of the visions we’ve cited here.
Traffic engineering in the core of an IP network is usually accomplished using MPLS, through a process of path computation. That means that you can use traffic knowledge to drive PCE processes that would optimize handling in an IP core, and Wandl or Cariden can certainly be used that way. You could also use the traffic knowledge to drive a wider scope of policy management processes in the network, even perhaps out to the edge, to increase the span of control. So Wandl could be used for that too.
In a centralized SDN model where we replace traditional adaptive IP with something else, the presumption is that the central control process is what manages paths, so it’s that process that needs the knowledge of traffic. Since Wandl (and of course Cariden and other Wandl-competitors) can provide traffic knowledge, it could be used to couple that knowledge to an SDN controller. In fact, if we presumed that SDN devices, lacking adaptive behavior, might also lack some of the traffic knowledge that’s necessary to do adaptive routing, you could argue that SDN might need traffic knowledge more than legacy networks would.
What all of this adds up to is that you can in fact say that traffic analytics are useful whether you’re thinking SDN or legacy, core or metro. So we answer our first question.
Could Juniper have thought this was a good reason to buy Wandl? Here, of course, we’re getting into something very subjective and somewhat unknowable, which is how any vendor thinks about something. Certainly it might be useful to have multi-vendor traffic/network analytics given that virtually every carrier network is multi-vendor. And $60 million isn’t a lot of money these days; Apple bought social-media analytics company Topsy for five times that much.
My problem is that this is the kind of “so cheap I can’t refuse it” justification, which isn’t enough. The best strategy for Juniper would seem to be to provide a data-gathering interface to any analytics platform out there rather than to seize on a single one and hope it’s adopted universally by operators. They could do that with Wandl, with whom they already have a partnership. So just “getting” the data doesn’t seem to be enough of a reason to buy them.
We could say that Juniper bought Wandl because Cisco bought Cariden, but while that’s possible in one sense it’s illogical in another. Cisco needs to minimize the SDN revolution at all costs because they’re the networking establishment. We’re in a market that thinks that analytics, even if you don’t do anything different with the results, is a revolution. So add analytics to POIPN (Plain Old IP Neworking) and you have SDN? As I’ve said before, you can affect software control without centralization, OpenFlow, or any of that stuff. That’s been Cisco’s angle.
The problem is that it can’t be Juniper’s. You can’t become a come-from-behind winner in traditional networking by aping every move of the market leader, unless you want to be a price leader. Guess who’s the price leader? Huawei. Juniper needs to take SDN further, take networking further, if it wants to gain market share on Cisco.
We can’t say whether Juniper believes that Wandl will suddenly make it a market leader, but if they do they’re delusional. More is needed, and so we’ve answered our last questions. But that obviously raises another, which is what “more” might be.
To me, both SDN and NFV signal that operators believe that there’s a fundamental problem with the notion of uncontrollable, adaptive, networking. That problem isn’t just “utilization” either because fiber improvements are making it possible to lower the cost of transport bit-pushing. The problem is that this model of networking is associated with commodity connectivity and that’s never going to be profitable enough for deregulated operators to survive on. I’ve heard all the presentations about how the price/cost line on bit-pushing is about to cross. They’re right. You can slow the process a little by fiddling with utilization or fiddling with capital costs, but in the long run even opex enhancements aren’t enough. You have to sell more, which means you have to create networks that are subservient to services. That starts at the top, where the services are, which is why the cloud and NFV are important.
I think Cisco knows this, and they’re just waiting for the right moment to jump off the old bits and onto the new. Cariden is useful to them while they’re in titular denial. The question is whether Juniper sees the future too, and Wandl doesn’t answer that question.