SDN – What’s in a Name? Part 1

Software Defined Networking (SDN) has been around since 2011 or so and, along with network virtualization, is the networking industry’s response to server virtualization, which has been around for much longer. Despite being such a hot topic in forums, there is unfortunately a lot of uncertainty as to what SDN actually means, let alone what vendors promise to deliver. What SDN is depends on who you ask. It is comforting to know that at least the acronym is defined as the Security community has been calling for Security Defined Networking!

One of the more commonly accepted definitions of SDN is that it is the separation of the Control Plane and the Data Plane enabled by a centralized Controller. Under this definition Southbound APIs are needed between the Controller and the switches. Well known examples are OpenFlow and NETCONF. Likewise, Northbound APIs are needed between the Controller and the users. However, as Ivan Pepelnjak mentions, there are no Northbound APIs defined yet. Commercial (e.g. HP, NEC, and IBM) and Open Source (e.g. NOX and POX) Controllers already exist today. Whether they are actually shipping or have only been announced are defined on SDN Central.

Another way of thinking of SDN is that it is a programmatic way of isolating Virtual Overlay Networks from each other and from physical networks. In other words, SDN extends Virtualized Data Centers and Virtual Overlay Networks, thereby ensuring VM mobility in a scalable manner. (Overlay networks themselves are not new. The Internet itself started as an overlay layer to PSTNs. Ironically, fast forward a couple of decades and now VoIP is overlaid on IP networks.) Virtualized networks need overlays to support multi tenancy and VM mobility (elastic demand of virtual machines). Under this definition, the programmability that SDN offers can enable VM mobility in a flexible and agile manner. Common use cases of VM mobility are bringing up entire Data Centers during rolling brownouts, and being able to launch Dev Test environment on the fly.

As you can see, the definitions have nothing to do with each other. However, people try to find commonalities in them. In parts 2 and 3, I will detail the approach taken by some networking vendors to claim their SDN compliance.


Welcome to my blog!

I have been planning, designing, building, implementing, analyzing, operating, and supporting networks since 1996. Not to mention the things they glue together. I have worked for networking vendors, been a customer of networking vendors, and delivered professional services to customers of networking vendors. I am CCIE #11857 and rubbed shoulders with Milton Friedman apologists while earning my MBA at Chicago Booth. (I personally subscribe to the Richard Thaler libertarian paternalism school of thought, better known as Nudging.)

With this varied background, occasionally I feel the need for an outlet when I sense déjà vu in the networking industry or process an acquisition announcement or learn about a cool new feature or something along those lines. Hence I’ve started this blog.

I hope you find my musings interesting, informative, and perhaps even helpful. I look forward to discussing topics related to LANs, WANs, SDNs, Data Centers, IPv6, and yes, even Cloud. Moreover, I will try to make it more than just about the technology.

And in case you were wondering, No, my next post will not be entitled SYN-ACK. Unless there has been a man-in-the-middle attack.

— Umair Hoodbhoy


Software Defined & Intent Based Networking Blog Posts

Musings on Cloud, Multi-Cloud, Networking