t has taken a while, but I think I understand how some flavours of SDN work.
In CiscoLand, at the hardware level, CEF is a flow based forwarding mechanism. All the higher layer routing protocols like bgp, ospf, rip, etc, are used to build that flow table. I think Cisco's ACI is designed to manipulate those flow tables directly through some set of off-box oob controllers. These flows are monitored through Netflow, sFlow, OpenFlow telemetry commands, and the like. So flows are integral to how networks work. How they are controlled is the question.
I used to be of the mentality that this central control created points of failure in the network. But if boxes can maintain state during a controller failure or outage, then it isn't so bad. In addition, many initial talking points mention that flow tables needed to be dynamically populated, which requires punting packets to the controller, which really slows things down.
But many networks have a reasonably static topology. This enables flow bundles to be pre-populated and thus hardware forwarding can be used for the majority of the traffic, if the flow rules are general enough. From a high level perspective, then the issues arise when network failures occur. How does the network heal itself around those failures points? Some answers I am still looking into.
In the open source world, Linux, in the kernel forwarding plane, also maintains a flow table. sFlow can be used to monitor flows. There are netflow add-ons to monitor those flows. Static routes and things like Quagga are used to define the rules for how flows are setup.
So, enters the concept of OpenFlow, which is a set of rules used to manage those flow tables directly. Either locally, or through some off-box controller. (I have been looking into Ryu at the moment).
When using layer 3 network protocols like bgp, et.al., the flow rules are typically defined based upon destination ip address.
With OpenFlow, flows can be specified on a number of different combinations of addresses, ports, mac addresses, encapsulations, ...
Now take that concept, and make the realization that you can create a distributed firewall, because the network itself can provide firewall and associated security features. Rather than creating flow rules based upon destination address, ... with the added granularity, flow rules can be specified that only specific types of traffic (eg port 80, or esp, or ...) go through various parts of the network, and traffic not matching those flow rules go somewhere else, say like a honey-pot or something.
And with various forms of encapsulation from edge to edge, various forms of vrf/vpn/segmentation are inherently supplied.
So, it is conceivable that the central points of congestion like big central firewalls can be eliminated, and the security and privacy can be distributed throughout the network. Kind of like MPLS/VPLS on steroids.
From the open source perspective, I have just started going through the examples for OpenVSwitch (OVS) and its companion product Open Virtual Networking OVN at Spinhirne's Blog . The examples show some single points of failures, but I think I know how to make those better. It is looking promising based upon what I've seen so far, but have more under-the-hood looking to do.