Is OpenFlow SDN worth it?
Configuring and managing networks through protocols is an admirable goal, but the benefits of using OpenFlow protocols for abstraction aren't readily apparent in every business case, writes Technically Speaking's Loring Wirbel, communications and applications analyst. Loring explores what exactly is gained by control plane abstraction, writing that although much emphasis has been placed on OpenFlow "changing the islands of virtualization," the protocol really isn't that different from various hardware-based protocols, such as Cisco's label-switched routing or Ipsilon's IP switching.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Loring says that in each use case that includes OpenFlow products, those conducting the work need to pay attention to the price of software-based controllers, because the same capabilities could be gained for less by actually adding more hardware. In closing, Loring writes that networking will inevitably move up the protocol stack, but that doesn't necessarily mean that an OpenFlow SDN topology is the best choice for an existing hardware-based network.
Read Loring's full post on whether or not OpenFlow-based SDN is really worth it.
Debunking SDN myths
Packetqueue.net's author Teren Bryson -- a network engineer who became an IT director -- tackles common SDN evangelist claims in a recent blog post. He writes that SDN myths and marketing are "fogging up" the landscape, although he does think that SDN will eventually make its way into networks.
Included in his list are the following myths: SDN will lower costs, SDN will eliminate network engineers, and the universal one -- SDN is a disruptive technology. Bryson ends his post writing that although SDN is exciting, it's critical that the industry doesn't get too wrapped up in the promise and "religious fervor" of new technology to the point that it forgets what's real versus what's marketing speak.
Check out Packetquque's post in its entirety documenting some of the most common SDN myths.
The state of SDN and network virtualization
Colin Dixon, researcher at IBM Research, took to his Cyberpunkture blog to break down the current state of SDN and network virtualization. Recent quotes by Bruce Davie from VMWare seem to portray SDN as old and network virtualization as the next big thing -- something Dixon feels is slightly off-base.
Dixon goes on to highlight at a study out of UC Berkley that looks at a five-year retrospective of SDN. Included in the study is a breakdown of how network virtualization is the "killer app" for SDN and will most likely outlive it. Dixon argues, however, there are two main issues that this model doesn't address -- needing a higher-level policy description instead of a switch configuration, and the fact that network virtualization doesn't help with composing different network control programs. Both of these issues, however, are currently being explored within the OpenDaylight project and in The Frenetic Project, which includes academic research.
View Dixon's whole post dedicated to SDN, network virtualization and the future of the network.
Using affinities in a Plexxi network
In the second installation of a two-part series, blogger Jason Edelman writes about using affinities -- or relationships between systems -- in a Plexxi network in order to make the network more adaptive to applications. Plexxi, Edelman writes, is using advanced algorithms and affinities to properly distribute traffic and apply policy on networks.
Edelman writes, though, that there are other places where affinities make sense besides on Plexxi switches. He includes a few examples of where and adds that he would like to see the company explore what could be done with Open vSwitch and its controller.
Check out Edelman's thoughts on affinities and how Plexxi can capitalize on its "algorithmic intelligence."
Vendor lock-in and software
Hardware isn't the enemy, at least when it comes to vendor lock-in, writes Plexxi's Mike Bushong on the company blog. Instead, it's the software that results in lock-in and prevents many from switching solutions, and with architecture upheaval due to technologies such as SDN and network virtualization, the focus on vendor lock-in is growing.
Bushong writes that as customers look into plans for the future, they need to not only be aware of vendor lock-in, but also of two points that are key to making a decision when opting for a vendor: Is the product a point of control, and is it designed for integration? At the end of the day, Bushong writes, every solution has some manner of "stickiness," so the questions should be, "How many things does it touch, and how easy is it to replace?"
Take a look at Bushong's full post explaining the impact of vendor lock-in on software systems.
OpenDaylight spotlights its developers
In a new series on the OpenDaylight blog, developers on the project are featured, beginning with Brent Salisbury, network architect and software hacker. Salisbury answers how he got involved with the OpenDaylight project, new developments he's working on, and his definition of SDN. The Q&A with Salisbury also includes advice on how to become involved in the OpenDaylight project and its benefits.
Check out the full Q&A with Salisbury, which includes resources for those looking to get involved with the OpenDaylight project.