At their Global Partner Conference today, Juniper announced their new SDN strategy. Kevin Johnson, CEO, talked about how Pradeep Sindhu, Juniper’s CTO and Founder was instrumental in one of the early efforts to separate the control plane from dataplane, and then introduced Bob Muglia, Bob Muglia, EVP Software Solutions Division, to go into their new strategy in detail.

Juniper’s 7 Myths of SDN

Muglia stated out by stating the 7 myths of SDN (we have our own too) and attempted to debunk them:

• Myth 1: SDN applies only to datacenter: Juniper believes it applies to most of the network (our take: no surprise given their strength in SPs)
• Myth 2: SDN only applies to CapEx reduction: Juniper believes most of it is OpEx savings (our take: again, no surprise, don’t want to hurt those HW margins until the SW business is up and significant – having said that, I would agree that the scaling and automation aspect can save significant amount of money)
• Myth 3: SDN is only about software innovation: Juniper believes it will also require hardware innovation (our take: I tend to agree with him – just look at the number of pieces of equipment stuck implementing only a subset of OpenFlow 1.0 because the silicon has limited capabilities)
• Myth 4: SDN is all about centralization: Juniper believes that distributed intelligence will continue since networks are inherently decentralized (our take: yes, these swings are never absolute, latency of speed of light is not zero, and some local resiliency will be needed)
• Myth 5: SDN is only about OpenFlow: Juniper believes that OpenFlow is just a protocol and while important, it is not the most important protocol for SDN (our take: I think the industry moved away from SDN=OpenFlow a long time back)
• Myth 6: SDN is going to happen immediately: Juniper believes that SDN will take time (our take: given that Juniper has limited offerings today, certainly an understandable stance. At the same time, the reality is that there are still today only limited SDN deployments in full production mode)
• Myth 7: SDN is going to take forever: Juniper believes that small steps today are already possible (my take: not sure where this one came from—we’ve never heard this from the customer base, Juniper must be talking to different customers)

Regardless, Muglia did concur with what we are hearing from customers that are challenging about networks: configuration is complex, it is CLI-based and device by device today, prone to errors, and the networking industry in general is slow to respond to feature request and innovates too slowly.

Two Major SDN Initiatives

Muglia then spent the bulk of the rest of his presentation to cover the two key elements of their new announcement: a new centralized control, management and services stack built on top of Junos Space that will run externally on virtualized x86 platforms, and a new innovative pricing model that looks more like something from Microsoft than Juniper (surprise, surprise).

SDN Announcement #1: The New Junos Stack and the world’s dumbest orchestration system

Juniper intends to separate their networking software into four layers: management, services, control and forwarding. And intends to provide centralization around some of these layers. In particular, there will be a new centralized controller that is part of their new software stack including the JunosV App Engine. The new controller will be built on (drumroll….) technology acquired from Contrail Systems. Essentially, the new stack looks like:

• Custom Applications running on top of
• Junos Space, on
• Juniper Linux Service VMs with the
• Contrail Controller VMs running the control plane
• That interacts with the JunosV App Engine which provides forwarding, Junos services, configuration management etc

The key use case that the controller will target initially is SDN Service chaining: using software to virtually insert services into the flow of network traffic, replacing a physical activity today. They anticipate rolling out this new feature in the 2014 timeframe, using the MX and SRX platforms coupled with their new offload software architecture, allowing services to run either on (a) VMs on a line card with a Linux-based hypervisor orchestrated by what Muglia called the “world’s dumbest orchestration system”, JunosV Orchestration, or (b) an external rack of servers running standard x86 servers with VMware or other virtualization technology.

Muglia covered how this stack needs to integrate with orchestration system such as VMware or OpenStack, or OSS/BSS systems driving these elements at service providers. And also provide a few concrete examples of service chaining in the datacenter and at service providers involving:

• Chaining of routers to firewalls to load-balancers to VMs
• Inter-VM chaining from web server to middleware server
• Mobile service edge LTE deployment, from edge router to EPC (evolved packet core) to firewall, and then DPI (deep packet inspection), PCEF (policy and charging enforcement function) and finally NAT

SDN Announcement #2: Juniper is an Enterprise Software Company?

With Microsoft DNA injected into Juniper, it came as no surprise that Juniper was embarking on a new licensing scheme—it was a bold move nevertheless. Muglia unveiled the second key element in their announcements today, Juniper Software Advantage, a new software licensing and maintenance model that is transferable, elastic and platform agnostic. We’ve been saying at SDxCentral (like in our recent presentation at TEC) that SDN is an enterprise software play and that it wasn’t clear networking vendors would get it and make the changes necessary. Juniper is certainly pushing the envelope with this announcement. The new framework licenses based on key metrics such as throughput and user/subscriber counts and is agnostic to where the software actually runs – on Juniper MX, or on a VM in an x86 box. The example Muglia provided was around licensing 10Gbps of FW, Juniper doesn’t care if the customer runs 2 5Gbps on two VMs, or spreads it out on networking equipment. And Juniper will count on contractual enforcement as opposed to actual software enforcement (to avoid network outages and irate customers), with true-ups or true-downs annually (Oracle users will be familiar with this).

To be clear, the licensing does not impact any existing products, and they will start rolling out the licenses this year on SW product, most likely around Junos Space.

The 4 step process to SDN

Juniper was clear that all these changes will take time and put a SDN roadmap together for customers to embark on:

• Step 1: TODAY - Centralize management – using Junos Space
• Step 2: Q2 2013 - Migrate services to virtual machines (JunosV App Engine) – ala NFV (network function virtualization) that service providers are discussing
• Step: 3: 2014 - Deploy Contrail controller to start doing service chaining
• Step 4: 2014/2015 – new HW capabilities for security and networking to optimize service chaining performance

Tidbits from the Post Announcement Media Call

Post announcement, a couple of interesting points were made in the media and analyst call:

• There was some backtracking on OpenFlow support, given how they are now depositioning OpenFlow. Muglia played down some of it by saying they expect OpenFlow to evolve but the reality is that OpenFlow is now apparently a second tier protocol for them. Especially since Contrail is primarily based around BGP and XMPP (which is in reality more of a transport than anything)—or least that’s how it was positioned.
• Big Switch, which was previously touted as Juniper’s control plane partner and solution, has been relegated to backstage – no surprise, and as we have said, no major networking company is going to hand out control to anyone else. They are all going to build their own or acquire one.
• The software licensing scheme will have no impact for a while on Juniper – so don’t expect to see Microsoft SW-type margins at Juniper. But they expect the HW component of the prices to decline as the SW component grows.
• While they talked about orchestration and hypervisor and service chaining in VMs, they are clearly lacking a virtual switch. Juniper’s position is that they will integrate with KVM and OpenStack, and particularly OVS. And will interact with VMware and Microsoft through whatever standard protocols exist (which are limited).
• Juniper believes that a new protocol is necessary for service chaining and they pointed to NFV as a customer-led initiative that is pushing requirements forward.
• Juniper is planning on building cloud services, particularly security cloud services, in the future, and we’ll see how this plays with the overall service chaining aspect (note: this was from a private question we asked post-event)

What This All Means

Given all the information and announcements by Juniper today, here’s our take on it:

• No immediate change for Juniper customers – given all the hype around QFabric in the past (and it was a good feat of engineering and had real benefits) but the slow uptake in the marketplace, we suspect customers will similarly take a wait-and-see attitude on Juniper’s new SDN strategy
• OpenFlow as defined today will become a 2nd-class citizen at Juniper as they push forward their new software stack with “industry-standard open protocols”, whatever those are in the future
• Juniper has now announced its own controller and Big Switch’s future with them is unclear
• While bold, the licensing scheme will go through many iterations as customers and Juniper come to grips with what all this means – unlikely we’ll see a jump to cloud-type licensing (pure subscription) until we sort out the meaning of enterprise-type licensing in the new networking concept. Just the tracking of these licenses is a large project in and of itself (licenses tied to boxes tend to be easier to track)—unless all management and control truly centralizes
• Service chaining is as real a customer use case as network virtualization /overlay in the datacenter – we’ve heard about this one from multiple enterprises and service providers that we consult with and this comes as no surprise. There are challenges in deploying such chains though (based on our work and experiments for some of these customers) and we look forward to seeing how Juniper intends to solve those.

All in all, this continues to bolster our prediction in 2013 that every networking company will be an SDN company!