Open Networking Foundation has this nice and crisp definition of SDN:

[SDN is] The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.

Using this definition it was easy to figure out whether certain architecture complies with ONF definition of SDN. It was also easy to point out why it was ridiculous.

In case you can’t be bothered to read the whole blog post, here’s a short summary of my opinion of this definition. It’s a slide from my Introduction to SDN presentation, which is part of the SDN workshop as well as numerous SDN presentations I had in the last years.

While the ONF web site still features their marketing definition of SDN, I wanted to dig deeper while writing my Centralized Control != Centralized Control Plane blog post (read also the follow-up post), and focused on SDN Architecture 1.0 document (published in June 2014).

The SDN Architecture document was obviously written by people with real-life networking experience (as opposed to academics and marketers) and contains a large number of really interesting statements (see also RFC 1925, section 2.4).

If you’re even remotely interested in SDN, you (RFC 2119) SHOULD take the time to read it and think about what it’s trying to say and what the implications are.

Let me quote a few of those statements (obviously out of context – but then I told you to read the whole document, right?).

Please note that I’m not bashing the SDN Architecture document. Its authors did a marvelous job; I’m just pointing out what happens with a seemingly simple concept once someone tries to implement it and gains some operational experience.

The descriptive overview of SDN contains this note:

The concept of a data plane in the context of the SDN architecture includes traffic forwarding and processing functions. A data plane may include the necessary minimum subset of control and management functions.

Exactly what I’ve been saying for years – you cannot run linecard protocols (BFD, LACP, LLDP…) from the central controller. Section 4.2 of the document agrees with my sentiment:

The data plane implements forwarding decisions made in the controller plane. In principle, it does not make autonomous forwarding decisions. However, the controller plane may configure the data plane to respond autonomously to events such as network failures or to support functions delivered by, for example, LLDP, STP, BFD, or ICMP.

Did you notice that they talk about controller plane and not control plane? It’s also worth noting that the current version of OpenFlow doesn’t provide any functionality in this direction. For more details, watch my OpenFlow Deep Dive webinar.

Section 4.3.4 (Delegation of control) is a nice summary of the fundamental shift caused by exposure to real-life problems (all emphases are mine):

Although a key principle of SDN is stated as the decoupling of control and data planes, it is clear that an agent in the data plane is itself exercising control, albeit on behalf of the SDN controller. Further, a number of functions with control aspects are widely considered as candidates to execute on network elements, for example OAM, ICMP processing, MAC learning, neighbor discovery, defect recognition and integration, protection switching.

A more nuanced reading of the decoupling principle allows an SDN controller to delegate control functions to the data plane, subject to a requirement that these functions behave in ways acceptable to the controller; that is, the controller should never be surprised. This interpretation is vital as a way to apply SDN principles to the real world.

I don’t know who wrote the SDN Architecture document, but the parts I’m really interested in sound like a description of Big Cloud Fabric architecture ;)

Finally, I found this gem in section 4.3.2 (SDN controller):

Controller components are free to execute on arbitrary compute platforms, including compute resources local to a physical NE [network element].

To summarize:

• Components of the control plane can be implemented in the data plane;
• SDN controller can delegate some of the functions to the data plane network elements;
• Controller components can reside on network elements.

Takeaway: Based on this broad definition, almost anything with a central control element (aka NMS or orchestration system) can be called SDN (so SDN is really becoming as meaningful as cloud).