Over a million developers have joined DZone.

Maturity and Evolution of SDN

DZone's Guide to

Maturity and Evolution of SDN

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

A few weeks ago I read this article from Craig Matsumoto on SDN Central.

At first I read it with a bit of a smile, but for some reason it has actually started to bother me a little. In this article, Craig summarizes a talk by Scott Shenker about SDN and a proposal for an SDNv2 that would fix the things that are wrong with SDNv1. In a way this represents what is wrong with our industry. We create a new version or create a new name for a concept that is not particularly well defined to begin with, and in many interpretations is far broader than is assumed in the pre-fixed version.

Many folks still believe that OpenFlow defines SDN. And that all the limitations of a basic protocol invalidate or limit the capabilities of an evolving concept like SDN. Why do we feel such a need to increment a version of an undefined term to make it sound like we are creating something new and different?

In SDNv2, we would still have separation of control and date (at least all that work is not wasted), but there are three major differences between it and the “old” SDN concepts. Maybe I am alone in thinking that in my definition of SDN these differences were never not part of the SDN concepts.

Switching goes to the edge and becomes largely virtual, executed on x86 cores.

We have for decades worked on pushing complex packet handling to the edge because it is just simpler to scale the data path that way. Even in this model however, the core still needs to switch packets, but the core is certainly simpler. Most ISP networks have been engineered like this for about 2 decades. Most enterprise core networks are orders of magnitude simpler than all edge attachment points for that same reason.

The fact that switching at the edge can be done on x86 is not revolutionary. The actual hardware used to switch packets is not particularly relevant. Sure, using x86 makes it easier to build your own packet handling and forwarding mechanisms, but in reality, who besides a very select few can or will want to do that? Of course OVS and similar components will become a very significant part of the network, SDN or not. They already are in many places. It is less about the technology used to switch packets, it is about the point of control. The revolutionary part of this is that the initial policy enforcement point is extremely close (control and actual switching) to the application, in our view an absolute must where the network needs to go. And fundamental to SDN in any definition.

Middleboxes get included in SDN, where these middle boxes refer to L4-L7 appliances.

No network is complete without appliances (hardware based or virtual) that provide network services. The network does not end at L3. The separation of L1-3 network services and L4-L7 services needs to disappear and in most places already has. A network provides services at each of these layers. And all of them need to be available within the concept of SDN.

The network is opened up to third party services

This speaks to the ability of “SDN” to provide low level interfaces into the network to allow user to access virtualized portions of a network. One of the fundamental values of the SD part of SDN is the fact that you get programmable access to the network, for anything from provisioning to packet handling control to forwarding rules and policies. Across all layers of the network. Providing access to a virtualized instance of a network is one example of what that programmability can give you. Not a new notion that needs to be “fixed” in the new SDN. Programmable access to loadbalancers, firewalls, encryptors or any other network service you can imagine is core to the power of SDN.

Closed interfaces are not allowed.

We have to be open. Being open in common APIs, open in Open Source or any other definition of open is absolutely required to drive to acceptance and market success.

But let’s also remember that we live in a world of competition and any vendor of any product will look for advantages over their competitors. The market ultimately decides how much of a closed interface it tolerates. The vast majority of today’s networks are held together with some vendors’s secret sauce or proprietary function. Having closed interfaces does not make the network single vendor. The buyers actually decide, not those that intend to define a concept. As a consumer we have never been afraid of closed and proprietary solutions. The market leader in our space has many proprietary parts to their solutions.

Any solution needs to be open enough to allow for true multivendor deployments and installations. But each vendor also needs to create its differentiation and special value. Just like each customer will pick from those differentiations as part of their differentiation from their competitors.

Obviously we at Plexxi are 100% committed to the concepts of SDN. We believe the network has been stagnant and needs to change. It needs to evolve with the changes in IT towards IT’s third platform. But that does not happen by attempting to attach new tenets to a new version of SDN that fundamentally belong to networking in general and have always been part of what SDN stands for. In our vision anyways.

Networking technology is moving at a fast pace after being relatively stagnant for many years. And it’s not even the fundamentals of how we move packets around that is changing. We have finally realized that the network provides a set of services to applications. Those services are not static entities you provision once and never touch again. SDN as a concept or movement recognizes that the network needs to be moldable and accessible through programmatic interfaces. It is not about a specific protocol or mechanism to program switches. It is far more holistic than that.

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}