This syndicated post originally appeared at Zeus Kerravala's blog.
As most people who follow the networking industry know, Juniper outlined its vision for software-defined networks (SDN) at last week’s Global Partner Conference in Las Vegas. I’ve had a bit of time to digest the information, answered a number of questions about it, and I thought it was time to share my thoughts on what they announced and the impact to the industry.
First, summarizing what Juniper announced, they began the presentation with a number of myths regarding software-defined networks and then articulated Juniper’s principals of SDNs. I’m not going to repeat these, but if you missed the webcast, Jim Duffy’s article does a good job of highlighting them.
I first thought these were a bit of “motherhood and apple pie,” but more than one person told me that the way Juniper explained it was much clearer than had been laid out previously. I suppose I eat, live, and breathe this stuff most days, so I took some of what Juniper was discussing as common knowledge. But it isn’t for most people, particularly many of the channel partners in the audience, so kudos to Juniper for trying to simplify the message, unlike most of the startups that try to do so today.
With this announcement, Juniper becomes the first of the “brand name” network vendors to hit the market hard with an SDN vision. Brocade is much further along with products. HP has made a little noise with OpenFlow support, and we’re yet to hear from Cisco, but Juniper’s vision is the broadest to date.
While the message was in alignment with the industry, there were a few differences. First, while the BigSwitches and Niciras of the world promote the concept of centralized control, Juniper’s SDN vision is built on hybrid control. They will achieve this through supporting a traditional controller-based model with the acquisition of Contrail, but also offer less granular and arguably more scalable control through the use of BGP and XMPP. These protocols make sense as BGP support is pervasive across Juniper’s switches and routers and XMPP is currently being used to control hypervisors today. Through the use of BGP and XMPP Juniper can enable large-scale networks to have greater control of traffic (versus flows). Additionally, I’m in agreement with the concept of hybrid control. The thought of a central point of control for the network seems a bit inefficient. Agreed, there are certain control functions you want centralized, but there are a number that you do not.
Also, while almost every SDN vendor’s strategy has been centered on simplifying the datacenter (and Juniper’s is too), Juniper is also focusing on the problems caused by “service chains” at the service provider edge. At the edge, service providers often need to provision multiple services, such as firewalls, routing, intrusion prevention, etc., are “chained” together through multiple boxes. This isn’t by any means a new problem and way back at the turn of the century vendors such as CoSine, Shasta and Celox were trying to solve this problem. However, those products were fairly expensive and the economy went in the tank, causing SPs to focus on operational efficiencies instead of new services. Juniper’s SDN vision enables operators to build these service chains by inserting software-based network services into the flow instead of having to deploy an actual hardware appliance. In theory, the process of inserting services can be automated and done on an as-needed basis, and then removed just as easily.
Lastly, Juniper will be introducing a new software licensing model to support the new software-only products. How and when this gets implemented wasn’t all that clear, but the JunosV App Engine gives the company a strong development platform to build a number of new products that would fall under the new licensing agreement. In a follow-up call, Juniper was clear on the fact that none of the existing routers and switches would fall under this licensing model. This makes sense as there really isn’t a way to decouple from the router-based hardware and software.
The one big missing piece of the launch was any detail on product. I was half expecting to hear more details about the MX router that offers a number of virtual services today. In theory, the SDN strategy could be applied to MX first and can be used to kick-start the company’s SDN product strategy.
The lack of product detail does create some risk for Juniper. In a sense, the company went through this with Stratus/QFabric, when it announced its vision well ahead of the product. When the product was finally available, the company had ceded most of the momentum to the multitude of other vendors promoting their fabrics. In follow-up calls with industry people after (not competitors) there was a bit of the “more of the same” feeling, making it crucial that Juniper follows this up with related product announcements.
This was a good start, but over the course of this year, we do need to see consistent product announcements to support the vision and strategy.
Latest posts by Zeus Kerravala (see all)
- Forget Heliocentrism-Embrace the cloud and Zeus-centrism - April 17, 2017
- Avaya’s post-bankruptcy plan should not impact customers, partners - April 14, 2017
- There’s never been a better time for Cisco Services - April 12, 2017