Unconvinced, Unreconstructed, and Unrepentant: A Reply to Professor Friedman’s Response

Software defined networks are poised to dramatically simplify deployment and management of networks. OpenFlow, in particular, is becoming popular and starts being deployed. While the definition of the “northbound” API that can be used by the new services to interact with an OpenFlow controller is receiving considerable attention, the traditional, “southbound”, API that is used to program OpenFlow switches is far from perfect. In this paper, we analyze the current OpenFlow API and its usage in several controllers and show semantic differences between the intended and actual use. Thus, we argue for making the OpenFlow API clean and simple. In particular, we propose to mimic the process that exists in the Python community for deriving changes that result in a preferably only one, obvious way of performing a task. Toward this end, we propose three OpenFlow Enhancement Proposals: i) providing positive acknowledgment, ii) informing the controller about “silent” modifications, and iii) providing a partial order synchronization primitive.QC 20150704</p