Juniper exec gets into nitty-gritty of SDN plan

Muglia emphasizes new software model flexibility, says Juniper's revenue mix will shift

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.

Bob Muglia

Bob Muglia, executive VP, Software Systems Division, Juniper

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

RECENT: Juniper CEO Johnson talks software, the company's recent challenges and key future directions

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.

Under your strategy, will hardware be relegated to fast, dumb forwarding?

We will provide customers with the flexibility of packaging. Many customers are going to want to purchase all of the four planes, or three of the four planes, within a single physical box. We will continue to provide that all self-contained in one unit. We are changing, though, and allowing them the flexibility to take the services and move them onto a rack of x86 servers and into the cloud. We see four delivery options. We don't care which option the customer chooses because the business model for software allows customers to transfer the license between devices as they choose. This is very much a business model that provides a great deal of flexibility for customers and provides them the ability to purchase software capacity based on what their usage needs really are. It is also a business model that we see providing us with tremendous growth of opportunity as a company in the software space. So no, these devices are not dumb; they're actually quite smart. There's quite a bit of flexibility, and it's good for customers and good for Juniper.

So whatever commoditization might happen on the hardware side you'll make up through additional software revenue?

We will see a shift of our revenue stream from being predominantly hardware -- almost entirely hardware-based -- to much more of a mixture of hardware and software.

Will it be predominantly software?

I'm a software guy so I might say yes, but that's a very long-term perspective. Not in the next five years, for sure.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Must read: 10 new UI features coming to Windows 10