OpenFlow is nothing more than an interface into the forwarding table of a network device. By allowing external entities to program the forwarding tables of our network devices, we are allowed a level of agility that does not exist in today's networks.
Is OpenFlow SDN?
A common misconception about OpenFlow is that it is SDN, which isn't true. It is in the spirit of SDN, but it is not the definition of SDN. It is an enabler of SDN, but it is not the definition of SDN. It is a natural manifestation of SDN, much like the concept of an external controller, but it is not the definition of SDN. It is not a component of SDN, because that would imply that SDN relies on it. Rather, OpenFlow is an embodiment of the principles that SDN represents, which can be boiled down to: separation of concerns. Our "consumers" (network devices) should not be making the decisions on their behavior because they have a limited (and inevitably out-of-sync) view of the network as a whole. The methods used to disperse network topology data is unreliable in the context of synchronicity.
What's a flow?
A flow is a set of defining traits about an item of traffic, of which we can use to delegate behavior. OpenFlow has vision down to the Layer 4 headers of the packet, meaning we can categorize traffic based on not only source IP and destination IP, but source port and destination port. We can then define a "flow" as "packets" that have a matching combination of qualities, and by qualities, we could mean "source IP", "destination IP", "source port", "destination port", and any combination of those values.
What can we do with a flow?
There are four actions that can take place based on a flow's properties. We can either drop the data (in the event that "drop" is the assigned action for a flow), accept the data (in the event that "accept" is the assigned action for a flow AND we have an outgoing interface in our flow table or an outgoing flow processor to send the data to), modify the data's header fields, or send the data to the OpenFlow controller so it can be evaluated (in the event we don't have a matching entry for this flow in the flow table). Upon finishing its evaluation of the data, the controller will send back the instructions of what the switch should be doing with data that match's that flow's characteristics.
What's the point of OpenFlow?
By removing the responsibility of generating its own forwarding table (usually figured out through the use of routing and switching protocols), we allow the network devices to become cheaper and more stable (rather than being a jack of all trades, it becomes a master of pushing packets). The financial benefits are obvious and important, but the true value of OpenFlow is in the agility and freedom it gives us. The freedom we gain is in the form of no vendor-lock. When network devices become truly dumb devices and the brains are offloaded to an external entity, we no longer have to worry about cross-vendor support in protocols (other than OpenFlow), because there are no protocols figuring out the best paths anymore, nor do we have to worry about vendors supporting protocols, for the same reason. The agility we gain is in the form of fast failing experiments. For example, rather than pushing new class of service config out to dozens or hundreds of devices manually over multiple maintenance windows only to find out it doesn't work, we can instead make a single change at the external OpenFlow controller and monitor the results immediately. If the resulting behavior is unexpected, we can rollback to the previous behavior in what could be considered instantaneous when compared to the conventional process of committing changes to network devices. By allowing this kind of agility, we are saving man-hours and increasing the speed of innovation.