There are very smart people involved in the development of Openflow. However, I suspect very few of them actively manage networks on a day-to-day basis. Now that the code is in the hands of network engineers, we can see what's needed to actually get this running in production networks.
When it comes to emerging technologies, this space between the development and actual production use - between developers and the network engineers in the trench - is something I find incredibly interesting. It's great to be involved in the development at the point you can provide substantive feedback into the actual product or technology.
And that is where we are today with Openflow. We have Openflow deployed to 4 "production" switches and have a wireless SSID in 3 buildings across campus that feeds into an Openflow switch. The cool thing is that it all pretty much works. The problem is that, when it doesn't work, it's a pretty big pain to figure out why. Yesterday I compared it to the early days of the GSRs when the tables on one of the linecards would get out of sync, but it's a bit worse because the "linecards" are spread across the whole campus and there are very few debugging tools available.
There are a number of debugging features that would be useful, but I think the most useful one would be a way to see the dataplane and control-plane packets at the same time. One way to do this would be for the switch vendors to allow you to add Openflow control-plane packets into a port-mirroring configuration. This would allow me to hook a sniffer up to a switch port and mirror both the traffic to/from a switch port and the Openflow control messages to the sniffer.
Why would this be useful ? One problem we're having right now is that some laptops take 1-2 minutes to get a DHCP lease on the Openflow network. Is the switch taking a long time to encapsulate the first DHCP message into an Openflow message and send it to the controller ? Is the controller taking a long time to send the packet-out and flow-add messages to the switch ? Are the Openflow messages getting lost along the way ? Today I have to run a tcpdump on the Openflow controller to capture control-plane packets and Wireshark on a laptop to capture the dataplane packets and then try to compare them without synchronized timestamps. This one little feature would have saved us a lot of headaches !