Happy Friday everyone! Today’s first highlighted TFI2014 speaker is John Giacomoni!

John Giacomoni is a Senior Architect at F5 Networks focussing on SDN as well as both the kernel architecture and go to market strategy for the LineRate product. John has focussed his 15+ year career on bringing deep systems technologies to market in new and interest ways as an entrepreneur, researcher, and OS/networking architect/programmer. Most recently F5 Networks acquired LineRate Systems, an SDN company, where John raised initial capital as the founding CEO and later CTO. LineRate Systems’ SDN technology was based on John’s research and dissertation work dating back to 2003. Additional notable projects that John has worked on include NCSA Mosaic, Argus Systems Groups’ Pitbull Trusted Operating System (certified), and a performance visualization system for Google.

Take it away John!

tl;dr SDN excites me because we can finally see a path towards being able to treat the network, and the rest of the computing infrastructure via SDDC, as a programmatically controlled utility where the infrastructure immediately responds to the needs of services and applications. However, the morass of SDN definitions (OpenFlow, Overlay Networking, Service Chaining, Vendor Neutral, etc.) has only served to confuse and paralyze most customers. In conversations with customers I define SDN as follows:

“SDN is a family of architectures (not technologies) for operationalizing networks with improved time to market, reduced risks, and reduced operating expenses by centralizing control into a control plane that programmatically controls and extends all network data path elements and services via open APIs.”

SDN and the Network of the Future:

The past few years have rekindled my excitement in networking for the first time since I discovered the NSFNET in the late 80s and realized the potential of a globally interconnected set of networks. As a computer scientist, software engineer, and entrepreneur I believe our focus has been on satisfying consumer needs by refining techniques grounded by static topologies.

SDN and SDDC (SDN’s infrastructure wide version) finally offer us a solid path towards achieving the promise of a true utility computing model where the utility can span the globe and be programmatically reconfigured “instantaneously” based on the needs of the consumer via services and applications.

Defining SDN:

Having followed SDN since 2011 and earlier, I find it endlessly fascinating and frustrating that we get a new definition of SDN every 1-2 years in spite of the general sense of agreement that SDN is the future of networking. In my opinion, the trouble stems from trying to scale the description of useful but point technologies into something all encompassing.

Instead we should be focusing on a holistic definition that encompasses most of the problems suffered by participants in the SDN discussion. In doing so we can actually have a open discourse about problems and solutions without having to argue whether OpenFlow or Overlay Networking is the best expression of SDN – both are useful but neither is sufficient. The result of these arguments, outlined in more detail below, is that we’ve created a tower of babel type situation with most of the customers that I have spoken with being paralyzed by confusion.

Instead I offer the following definition that helps them understand the types of problems that can be addressed by SDN and how they can move forward today without choosing poorly.

“SDN is a family of architectures (not technologies) for operationalizing networks with improved time to market, reduced risks, and reduced operating expenses by centralizing control into a control plane that programmatically controls and extends all network data path elements and services via open APIs.”

Problems with Existing SDN Definitions:

In very broad strokes I’ve seen a rough correspondence of definitions to the 4 major eras of “media defined” SDN with each successive era convinced they’d cracked the nut and achieved SDN nirvana:

1. History-2011: Abstraction and network protocols at the packet level
2. 2011-2012: OpenFlow
3. 2012-2013: Overlay and Virtual Networking
4. 2013-2014: Service Chaining

Confusingly, each of these eras has its own set of technologies and a definition that explains how these technologies are the apex of SDN to the exclusion of other technologies. This is not surprising as primarily customers and vendors with a agendas have defined each of these eras. What we are seeing are solutions in search of a problem that get lots of hype and then slowly fade. This is sad as each of these eras can contribute to customer problems when viewed viewed as a tool to solve the operational problems that network operators are suffering today.

Adding additional complexity to the situation is the desire for a universal set of APIs that can describe the totality of networking devices in use today and those that may yet be invented. This idea began as early as the ONFs initial definition of SDN that included a requirement for a ‘vendor neutral API’ to allow data plane devices to be swapped out at will. This desire makes sense in the context of OpenFlow being used to implement stateless packet forwarding rules with minimal logic built on switching fabrics.

However, customers are pushing that this concept be taken to extremes such that it applies to all 7 layers of the OSI stack including stateless layer 4 firewalls, stateful layer 4 firewalls, layer 7 traffic managers, and even application layer firewalls. While I am certainly not all knowing, I can see only two realistic paths forward. Either we as an industry define a simplistic set of APIs equivalent to Amazon’s ELB or OpenStack’s LBaaS (the production equivalent of writing a book in notepad) or we define APIs with sufficient complexity that one might as well write one’s networking policy definitions with a C++ compiler. In my opinion a productive compromise is to acknowledge that there is a reason why services are complex and that there will be some amount of work when switching vendors but that at the same time vendors need to focus on delivering elegant (not obfuscated) APIs.

In closing SDN presents us with an exciting path to a new era in computing provided we can provide a useful definition that we can all move forward and solve real problems.

Join us a week from today (22 August) to discuss all this and more at The Future of the Internet 2014: Defining Software Defined Networks – register today!