Juniper's SDN Strategy Looks Beyond OpenFlow
January 15, 2013
2013 may be the Year of the Snake on the Chinese calendar, but in the networking world it's the Year of SDN. As I wrote last week, "2013 should mark the point when SDN moves from being a debate topic to a serious technology alternative for network upgrades and redesigns."
This week, Juniper Networks added fuel to the SDN fire by announcing its SDN strategy, although the company emphasized vision over concrete details. One element is clear, however: Juniper's interpretation of SDN decidedly at odds with the conventional wisdom that's accrued around OpenFlow. Although the networking cognoscenti largely agree about SDN in the abstract--it's all about separating networking functionality into distinct, conceptual and easily disaggregated layers--in reality there are several different approaches.
- Client Windows Migration: Expert Tips for Application Readiness
- Thwart off Application-Based Security Exploits: Protect Against Zero-Day Attacks, Malware, Advanced Persistent Threats
- Best Practices for Security and Compliance with Amazon Web Services
- Why a New Business Model is Needed for SSL Certificates
- State of Cloud 2011: Time for Process Maturation
- SaaS 2011: Adoption Soars, Yet Deployment Concerns Linger
In his keynote at Juniper's Global Partner Conference, Bob Muglia, executive VP of software solutions and ex-Microsoft heavyweight, described what the firm sees as the four planes of networking, which OpenFlow devotees will immediately notice is twice as many as they are accustomed to: packet forwarding, flow control, network services and system management.
While OpenFlow addresses the first two, Juniper, like Cisco with its onePK vision, sees the realm of SDN more holistically. In fact, both in his prepared remarks and at a later press conference with Juniper founder and CTO Pradeep Sindhu, Muglia was quite dismissive toward OpenFlow. Stating that "OpenFlow is just a protocol, and probably not the most important one," Muglia claimed that OpenFlow doesn't solve the more important problems a broader SDN approach can address. Although both executives paid lip service to Juniper's commitment to OpenFlow in its routers and switches, the L2 packet processing protocol is clearly not central to its strategy.
Sindhu was equally disparaging, characterizing OpenFlow as an interesting early attempt, a nice research project if you will, but something he expects to evolve into a more complete, and presumably more useful, protocol in the future. In the meantime, he said, Juniper's recently acquired Contrail SDN controller will use, and extend, BGP and XMPP, which are already supported in most of Juniper's hardware as control protocols.
It shouldn't come as a surprise that Juniper rejects the OpenFlow-fueled notion of dumb, commoditized, merchant silicon switches as nothing more than packet-pushing marionettes manipulated by a master brain in the sky. Like Cisco, it still derives almost 60% of its revenue from routing and switching hardware. And while its strategy does acknowledge the need for centralized control, as Muglia highlighted in his keynote, Juniper's SDN approach isn't primarily about centralized flow control. Muglia claimed that networks are inherently decentralized and that, in Juniper's SDN world, considerable intelligence will stay at the edge.
Next Page: SDN's Challenge to Incumbents