Software-Defined Networking: Part 2

M. Spanbauer
M. Spanbauer

Summary Bullets:

  • NEC, IBM BNT, HP, and Juniper have committed to support and released OpenFlow-capable code.
  • The greatest impediment to mass-market adoption will be commercial support.

If you have read the trade magazines and press materials around network technology over the last six to twelve months, you have noticed a decided uptick in the number of articles that focus on SDN and OpenFlow.  These articles have covered the topics from the technology vendor perspective, as well as highlighting the academic and research communities’ support and interest in it.  There are commercial products available today through a joint effort from NEC and IBM.  HP announced the general availability of OpenFlow-capable switch software on a large swath of its switches, and Juniper committed to supporting OpenFlow within the SDK for its Junos developer community.  This is a demonstration of the networking community’s belief that there is promise and a bright future for this enabling technology.  Though conceived originally within the academic world for the purpose of network control and segregation to enable researchers, it has long since been perceived as a solution for certain ailments in the enterprise to address the scale and flexibility of networks.  It is clear with the increase in inquiries from both enterprises and observers, however, that interest in this movement is reaching critical mass.  The question is: When will it be commercially available, at scale, and supported in complex environments?

Support is perhaps the biggest hurdle that stands in the way of adoption of OpenFlow.  In order for product networks to adopt and deploy OpenFlow, ‘enterprise-class’ support must be made available.  This is not as simple as troubleshooting a single switch, which can in itself be complicated depending on the logging capability and probes one may have on/in the network, but rather will span multiple devices, multiple disciplines, and (the greater challenge) quite possibly multiple vendors.  Enterprises must be confident that this investment promise outweighs the risks and challenges in order for it to be considered.  They will not have the luxury of the early adopters (Google, Facebook, etc.) that have software programming staffers who can assess and recode or tune the network as needed.  Instead, they will be dependent on support contracts spanning multiple vendors or left to their own resources.  New support models that mimic other industries will spring up, and as a result, the network may resemble a service more than a CapEx investment.  It is too early to say precisely how enterprises will consume this technology, but one thing is certain: Eventually, it will change everything.

3 thoughts on “Software-Defined Networking: Part 2

  1. Mike, you raise a good point re the the support issue. But I think there is also a big issue around the scope, expectations and applicability of OpenFlow that need to be resolved to get the greatest benefit from this architecture. My own view is that SDN as a whole has great potential but OpenFlow in itself is not a ‘one size fits all’ solution. It is a component. Ongoing work needs to address the context in which to apply this type of ‘off box’ vs ‘on box’ orchestration. The centralized nature of the control function also raises a number of practical reliability/uptime challenges versus distributed or federated control. Blending OpenFlow with other network programmability solutions will generate the most rewards. It would be great if the ONF could sponsor some activity to investigate integration scenarios. This is an evolution, not a revolution.

    Another concern I have is around the issues being sited as being addressed by OpenFlow. Physical network complexity has implications on performance that cannot be addressed through simplification at the management layer. It has to be addressed within the network itself. A number of scenarios ‘fixed’ by OpenFlow, as presented at the CloudNet event we were both at recently, were actually symptoms of poor network design or configuration, not a management issue (eg. convergence times). I discuss more in my blog . Will be really interesting to see how this technology develops.

    1. There are many questions that remain Nigel, I do agree. One thing has generally been true of promising technology though, which is that enterprise customers will find new and interesting ways to use it that the vendor(s) themselves did not predict. I feel that OF/SDN will be one of these. Your own toolset, launched last year enabling OF in the Junos SDK may be one of the easiest ways for customers to experiment with OF and apply it in new and interesting ways.

      Regardless, OF/SDN has certainly provoked some interesting (and sometimes heated) networking discussions.

  2. No one likes to make changes to a complex network, enterprises included. To add or move any device, an IT team must touch multiple switches, routers, firewalls, Web authentication portals, etc. and update ACLs, VLANs, QoS, and other mechanisms using device-level management tools. In addition, network topology, vendor switch model, and software version all must be taken into account. The more tiresome manual work is needed, the greater the risk of small, hard to locate but potentially disruptive errors.

What do you think?

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.