We had an opportunity to sit with Jonathan Davidson, Juniper’s EVP/GM for Development and Innovation, at the Juniper NXTWORK conference. The format was “Ask me anything.”

So we did. Here’s a summary of the conversation. Please note, these responses are not direct quotes.

1. What’s the message from Juniper to the enterprise?

For the enterprise to truly secure a modern network, it must rethink legacy security designs. How does a company build secure connectivity from the central core to the branches? How can public and private clouds be secured? How do we get beyond the idea that a tough exterior leaving a chewy interior is good enough? Single box firewall solutions aren’t enough any more.

Juniper’s Software Defined Secure Network (SDSN) helps here, today with Juniper infrastructure. Tomorrow, even with some non-Juniper hardware. The key is to secure whatever the underlying infrastructure is.

2. What’s Juniper’s wireless story?

Partnerships. Juniper doesn’t see great value in building their own wireless hardware, when there are wireless companies with excellent solutions they can partner with. Juniper customers see Aruba, Aerohive, and Ruckus among the best-of-breed solutions available. Juniper has won deals where these partners were part of the proposal.

3. Yes, but didn’t Brocade’s acquisition of Ruckus complicate that partnership?

Not at this point. We’re still working with Ruckus and involving them in deals where Ruckus technology is a good fit for the customer.

4. Isn’t there a desire to own your own wireless infrastructure to make a tighter integration with the new SDSN?

Juniper believes that enforcement at the switch uplink port to an AP is going to be good enough in the majority of cases. That gives us IP and MAC filtering right at the AP edge, giving us a consistent enforcement strategy that we’re happy with. Trying to set up filtering on APs themselves is unpredictable, and generally there’s not a lot of filtering available.

5. How is Juniper’s SD-WAN story shaping up?

Juniper doesn’t emphasize SD-WAN specifically because there is a product offering that is broader than simply SD-WAN. We wanted to build a platform that, in general, connectivity services could be built upon. And so, we have the NFX (network functions anything) hardware platform, coupled with Contrail as the software platform.

These pair with a service designer tool that allows connectivity services to be created via drag and drop, creating a service catalog. Those services can then be chosen and implemented as appropriate. It’s an open system, designed to be flexible. This is what the Cloud CPE solution is all about.

SD-WAN startups and products tend to be closed. The SD-WAN platform uses virtual network functions built by the SD-WAN company. They are easy to use, but they offer just a few services. A nice GUI. Application-based routing. That’s about it.

SD-WAN solutions might play well in the enterprise for a while, but the long-term bet for this technology is on the service providers. Most WAN services flow through the SPs. Most operational expertise for WANs is found at the SPs. And Juniper knows how to deal with SPs. Juniper knows how to sell to SPs, partner with them, and build applications for them. This will be the real SD-WAN story over time.

6. When does hardware stop mattering from a Juniper perspective?

Hardware will always be interesting. Even so, the bias of Juniper is towards merchant silicon first. Leveraging merchant silicon reduces the cost to bring a product to market. So if it solves customer issues, why not use it? On the other hand, merchant silicon doesn’t always meet all customer needs. In that case, Juniper has the engineering power and prowess to spin their own silicon.

7. But aren’t large shops looking to commodity hardware and virtual network functions to reduce costs and increase flexibility?

Yes. But x86 is never going to be general-purpose packet mover. Too many inefficiencies at scale. There’s a big difference between packet forwarding for distributed VNFs and aggregate network forwarding.

8. What about the programmability of the Barefoot Networks’ Tofino chip, which offers lots of speed and flexibility?

There is decent speed in the chip by today’s standards, but there’s always a tradeoff made between flexibility and performance. You can only cram so much capability into a die. And that’s the tradeoff they made. The chip is highly programmable using P4, but with what chipmakers are working on for the next generation of silicon, today’s Tofino speed won’t be that impressive tomorrow.

That’s not to say Juniper would never work with Barefoot on a Tofino-based product. We built the Trio chip in the past, and it’s infinitely programmable. We also know that engineers who get a little time with P4 and Tofino walk away going, “That was cool!” If the customer need was there and Tofino solved the problem, we’d consider it.

9. Besides OpenContrail, what are Juniper’s major contributions to open source?

OpenContrail is definitely our biggest contribution this far. We’ve also contributed to ONIE and Ansible. You’ll see some more intellectual property moves in this area over time. But Juniper isn’t overly keen to get involved with ODL or ONOS. Why throw a bunch of developers at those projects when there are specific customer needs Juniper can focus on that open source isn’t meeting? For example, the Northstar controller was highly customer-driven, designed and produced to meet specific customer requirements.

10. Is Juniper interested in subscription models for hardware or software consumption?

We believe the company needs to add new offerings in that direction. Subscription approach not only makes for a predictable revenue stream, but also gives customers a pay-as-you-grow model. For example, we’ve been doing this for years with the MX-80 platform. Depending on licensing, that box could do 5, 10, 20, 40, or 80Gbps. That made for some logistical challenges for us that we’ve learned from.

The larger point is that Juniper wants to remove all blockades from the sales process. If pay-as-you-grow is what the customer needs to succeed, then we want to support that. There will be more of these offerings in the future.

Our thanks to Juniper for access to Jonathan during NXTWORK, and our thanks to Jonathan for his time.