The Cisco ONE announcement has something for everyone. There is an OpenFlow component; there is a reaffirmation of Cisco’s support of overlay networks; and then, maybe most interesting, there is onePK, an improved way of “scripting” network administration tasks and an SDN approach you might call “make the most out of what you already have.” That all sounds like a laudable goal, but what does it really mean?

SDN motivation comes in many forms from a revolutionary restructuring of the network equipment business to an improvement over today’s scripting solutions. The most important problems thought to be addressed by SDN solutions tend to concern improving network management automation (e.g., provisioning virtual networks, on demand). Thus onePK, which centers on improving today’s automation via scripting, is an understandable offering.

This leads directly to the seemingly simple question “what does it mean to script a switch?” It’s actually a really complicated question, with an uncertain answer (at least for me). Switches are communication appliances but defined very differently from conventional server applications. A switch is defined by the protocols supported (e.g., routing protocols) but little is said about how that support is implemented (the focus is on the ends, not the means) or how the internal state of the switch reflects these actions. Switches respond automatically to local changes in network topology (e.g., to assure there aren’t forwarding loops) and indirectly to non-local changes through the messages received by adjacent switches. Scripting is a way to read and write some of the internal state of the switch, but what exactly does that have to do with the state of the network?

Switches are programmed in the “management plane.” Much of this is to define network specific policies: how important are various flows, what flows are permitted and which prohibited, and so on. These policies in turn become the means by which the switch reacts to new flows, and local and distant changes in the network. Many CLI commands are used to change or query these policies. But the goal of SDN goes much further. Through our SDN system we would like to literally control the state of the network (that’s certainly the result of direct use of OpenFlow). Most CLI commands are one big step removed and deal with the policy definitions, not the network state directly.

Is that a fatal flaw with onePK? That too is unclear to me. It depends I guess on how much we want to do differently with our SDN approach. onePK is a great way of making existing solutions better (think of it as programmatic CLI scripting). Many of the practical (certainly enterprise) applications of SDN solutions have been for tasks that onePK can probably solve. So I’m personally all for the approach, certainly to the point where the limitations are better understood. There is a lot of valuable IP and knowledge embedded in today’s network systems that will have to be recreated in an OpenFlow solution, not to mention the formidable problem of designing an OpenFlow controller that balances complexity, availability, distribution and performance. We won’t see OpenFlow replacements for today’s network systems soon or maybe ever (that’s OK, that’s not the intent). onePK asks the question of how far we can improve today’s network systems with better scripting. It’s an important question.