- Silicon Valley's 19 Coolest Places to Work
- Is Windows 8 Development Worth the Trouble?
- 8 Books Every IT Leader Should Read This Year
- 10 Hot Hadoop Startups to Watch
Network World - Front-and-center in Juniper's SDN strategy is a new software business model that will emphasize variable packaging and licensing of software to implement the company's software-defined networking design. Bob Muglia, executive vice president of Juniper's Software Systems Division, shared some finer points of the company's plan with Network World Managing Editor Jim Duffy.
Do you plan to separate your Junos software into four separate planes and offer these as separate products or licenses?
Yes. These are already present in Junos software but monolithically connected together. We don't have it separated yet in the way we actually deliver the technology to customers. But what we are planning to do is very much separate the planes and enable customers to scale their solution on a service-by-service basis.
BACKGROUND: Juniper finally talks SDNs
Which protocols besides OpenFlow is Juniper advocating or helping define?
We're going to look at a whole set of things that happen in the industry and in general, not focusing this announcement on embracing specific protocols. We will watch what happens in the industry and we do have some additional opinions. We think that BGP [Border Gateway Protocol] will be an incredibly important protocol. We will see some extensions to BGP to enable distribution of state. We will also embrace VXLAN [Virtual Extensible LAN] and NVGRE [Network Virtualization using Generic Routing Encapsulation] as data path protocols for Layer 2. I think MPLS will remain an important data path protocol. Frankly, I think OpenFlow has been overhyped in terms of its relative role in all of this. Some of the other protocols, in terms of management, have yet to full emerge.
Is Juniper working on defining the northbound API from network elements up to the controller and orchestration levels in an SDN?
It's between work on our Junos Space team and the Contrail team we just acquired. Both of those teams are doing a fair amount of work in that effort. A standard has not yet emerged so we're still open to what happens there.
Back in September you mentioned that Juniper was looking to garner industry support around an open source controller as a third "standard" alternative to those being developed by Cisco/Insieme and VMware/Nicira. Is that still the plan?
Our thinking has evolved since then. We do see a role for open source [being] key components in this. We've come to recognize -- that I did not recognize in August -- the role of the controller is to provide the same functionality across an entire environment. As such, we no longer think that would be done through open source. There are components of the solution that would be done in open source: for example, integration into OpenStack. Certainly, Open vSwitch will be done through open source. Certainly, the integration into the management systems of OpenStack will be done through open source. But we don't think the whole thing is going to go open source ... we don't think the whole controller is going to go open source.