One of the frustrations of the SDN space (and, sadly, a lot of spaces in the world of tech) is that sometimes companies get so obsessed with washing their products in the sacred water of some new (and press-worthy) technology they miss a chance to make a good and valuable point about what they have. We see two examples of this phenomena, one from F5 and another from Juniper.
F5 announced it was acquiring LineRate, a company that says it’s specializing in Level 7+ SDN. The problem with this, of course is 1) there are only 7 levels in the OSI model, 2) the top four layers aren’t part of the network, they’re part of the endpoint and 3) the goals of SDN that are fairly widely accepted apply to the lower levels, the real three layers of the network. That’s one reason I personally resist labeling the overlay-segmentation approach of firms like Nicira as “SDN”; they’re “software-defined connectivity”.
The irony is that underneath all this fuzzy logic LineRate has a real point about applying SDN, particularly in its “purist” or centralized/OpenFlow form. Remember, SDN is really about how the network forwards packets, and there are a lot of things that happen in the network that aren’t packet forwarding in a direct sense.
If we go back to the OpenStack Quantum virtual network model, we see that a virtual network to them is a Level 2 VLAN with some service-creating elements attached. In most cases, this model would define only the network in the cloud data center. If we look at LineRate’s approach, we can see that their vision of things like load-sharing are perfectly fine features of one of those “service-creating elements” of a Quantum VLAN, to wit the “gateway” that links it to the outside world—to the users.
It’s also fair to say that any network technology that segments the data center LAN is either designed for multi-tenancy or it’s going to have to segment on something other than just tenants. If the former is true, it’s a pure cloud provider approach, and if it’s the latter then the only thing it could segment on is applications. If you’re going to segment the data center by application, you could also think about segmenting WAN traffic by application, which is what application performance management tools that LineRate has would do.
My point is that LineRate (and now F5) have a good position in the cloud. They might even have a role in connecting user traffic to an SDN, and they certainly provide a reasonable NFV story. So why not say all of this? Hey, I just said it in less than 500 words, and if I can so can competitors.
Getting taken out with the SDN wash isn’t just a LineRate/F5 problem. Juniper released a new white paper, in advance of an analyst event yesterday (which I missed because it’s too far to travel for a half-day event) to talk in more detail about their SDN strategy. The paper turns out to be a reprise of VP Bob Muglia’s blog after the partner event where Juniper introduced its SDN position.
The central point in any vendor’s SDN position is their implementation. It’s easy to talk about SDN goals and philosophies, but at some point you have to get on the road and travel. In the Juniper paper, that point is covered by the section “Getting from Here to There”. Essentially it offers four steps to SDN, which are to centralize management, extract services, centralize control, and optimize network and security hardware. While some of these points aren’t directly relevant to SDN implementation in my view, Juniper does at least include the truly critical point in any SDN strategy—centralizing control.
The thing is, it’s in this third and critical step of centralized control where things really get squirrely. For “centralize control”, Juniper jumps into a discussion of “service chaining”, or linking the NFV-virtualized functions that Network Functions Virtualization creates into a sequence that creates an experience. I blogged about this the first time Juniper referenced the concept in their partner conference, pointing out that it was really about NFV. But in this context, the key point is that it’s not defining how you centralize control of forwarding, and that’s what a separate, centralized, control plane does.
And here’s Juniper’s irony. Juniper’s PSD CTO Michael Beesley did an SDN talk in Tokyo and the slides were posted online. In this talk, he offered a picture of SDN on Slide 9 that I think captures what SDN really has to be for Juniper, which is a fusion of current network architecture and centralized control using some emerging IETF protocols. On Slide 13 the presentation describes “The Juniper Architecture” in a nice, explicit way—more explicit than most of Juniper’s rivals. Juniper also has a solutions brief “Software Defined Networking: Extracting More Value from Networking Infrastructure with SDN” from October 2012 that has the same elements and structure as the talk. There is nothing about service chaining in either the slide deck or the solution brief, but there is detail on what Juniper sees as the core of SDN—changes to Internet protocols to centralize knowledge of network state (BGP, ALTO) and use of MPLS and OpenFlow to selectively control traffic. This is what I’ve called the “distributed” model of SDN because it retains a reliance on current IP device behavior, adding an overlay for control. It’s a perfectly good model, and Juniper has apparently thought about it in detail, and even presented that detail. So why not present it now? As was the case with LineRate, Juniper risks a real story getting brushed aside by an SDN-wash.
As an industry, we’re way too easy in accepting extensions to basic ideas like SDN. It started with firm principles and goals, and it’s now just a big attractive industry billboard. Which puts us at risk of achieving SDN by “acclamation”; everyone declares they support it, we stop developing anything because, hey, we’ve already met the goal, and what we’ve done all along becomes the “new network”. Is that what we want? Not me, but you can speak for yourselves.