SDN Vendors' Internal Tug-of-War Doesn't Bode Well For Customers

Networking vendors are experiencing internal conflict as they try to integrate SDN into their products lines. Customers will face the fallout.

Tom Hollingsworth

January 9, 2014

3 Min Read
NetworkComputing logo in a gray background | NetworkComputing

Software-defined networking is a very polarizing topic. For every proponent of this revolutionary networking trend, you find a detractor who doesn't believe SDN will be a long-term solution to networking issues. It's not just on the customer side of things, either. Vendors are having a tug-of-war with SDN internally. The fallout from these battles is going to affect customers as well.

Traditional networking vendors have been trying to find a way to integrate SDN with their existing product lines. For companies like Brocade and Extreme, this means embracing protocols like OpenFlow. OpenFlow still needs work to be a complete replacement for traditional forwarding technologies, but the future is bright.

Other companies take a different approach. Cisco started down the SDN road through API interfaces to IOS through the onePK development model. Recently, Cisco has introduced a parallel SDN effort with the Application Centric Infrastructure model, thanks to a spin-out, spin-in model from Insieme. Insieme accomplished a radical shift in thinking that may not have been possible from inside Cisco at the time. ACI and onePK seem to be trying to accomplish similar goals, although ACI is at a higher architectural level.

Inertia at traditional networking vendors is hard to overcome. It becomes almost impossible when mixed with more traditional thinking about licensing. Juniper bought Contrail for its SDN expertise over a year ago. A recent article suggests the Contrail integration hasn't gone smoothly. While some of the integration issues have been attributed to CTO Pradeep Sindhu, I think recently departed vice president Bob Muglia is also at fault.

Muglia is a former Microsoft exec with experience in software. However, his ideas about the licensing around that software hamper effective deployment of SDN. Muglia believed that the costs of developing SDN strategies should be recovered quickly. To that end, he suggested any number of radical licensing ideas, such as licensing a device by the number of flows that the box used or licensing devices to run the open source Puppet orchestration software agent.

Software licensing is a hindrance at best to the customer bases that deploy that software. When given equally capable SDN solutions that differ only in the complexity and cost of licensing, customers will almost always opt to use the less complicated or less costly option.

[Read why Tom Hollingsworth thinks the debates over OpenFlow, NSX and ACI miss the point in "Focus on SDN Tools Obscures SDN Benefits."]

Eventually, customers will face the fallout of traditional networking vendors SDN inexperience. If vendors are pouring time and effort into support of protocols like OpenFlow, it may lead to a reduced focus on existing product lines in favor of integration with "new" models that support the roadmap.

There is also the chance that vendors will attempt to recover development costs through higher licensing. In other cases, the dichotomy between methodologies could lead to confusion in production deployments. Should customers embrace OnePK or wait for a fully developed ACI solution? Will Contrail's SDN configuration be 100% compatible with my existing Juniper deployment? Or will have to retrain my employees?

Ultimately, vendors are going to back the products customers demand every time. The key for people looking at SDN today is to tell the vendors exactly what they are looking for: If you want support for a particular protocol, you need to be explicit when talking to your vendor representatives. If you favor one approach over another, you need to communicate that through all available channels. Vendors want to sell winners. Help them stack the deck in your favor.

About the Author

Tom Hollingsworth

nullTom Hollingsworth, CCIE #29213, is a former VAR network engineer with 10 years of experience working with primary education and the problems they face implementing technology solutions. He has worked with wireless, storage, and server virtualization in addition to routing and switching. Recently, Tom has switched careers to focus on technology blogging and social media outreach as a part of Gestalt IT media. Tom has a regular blog at http://networkingnerd.net and can be heard on various industry podcasts pontificating about the role technology will play in the future.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights