Software-defined networking (SDN) promises to virtualise networks, allowing switches, routers and VLANs to be configured through software.
In theory, decoupling the network control plane from the physical hardware allows IT departments to change network configurations on the fly and add to its infrastructure with minimum disruption.
TechRadar Pro talks to Dominique Vanhamme, head of networking at Dell EMEA, to talk Dell’s SDN strategy and the challenges it presents.
TechRadar Pro: With the immense amount of work going into creating proprietary solutions in the sphere of SDN today, where does Dell fit in?
Dominique Vanhamme: We have been developing technology in the space of software-defined networking for a couple of years now and our strategy has always been centred on offering openness to our customers instead of creating a proprietary solution.
The feedback we have received from both our customers and other organisations is that distinct, proprietary SDN solutions from vendors are immensely unappealing, both in terms of investment in the hardware and implementation and the fear of being locked into a path which may prove unsuccessful in the long run.
Every business has its own unique networking structure and idiosyncrasies, so trying to shoehorn them into a proprietary approach doesn’t take into account specific requirements.
Therefore our SDN strategy is about migration through openness; offering our customers multiple paths to adopting SDN through interoperable devices designed to support a variety of different networking standards. We understand that organisations want the easiest solution for them, and we have invested significantly to give them the best choice and support to follow that path.
TRP: How does Dell’s recently announced partnership with Cumulus Network fit into this strategy?
DV: Our partnership with Cumulus is the culmination of a strategy we have been sharing all through last year; to fill a critical gap in the market by demonstrating the true potential of open-source in the future of the software-defined data center.
We have been very active in developing SDN functionality with all our networking devices, releasing products and software that can support the growth of Open Networking.
It’s been a year since we released our first SDN capable switch, the S4810 with open flow and sub-microsecond average latency and we continued to invest in these areas up to our most recent N-series Campus switches which can now bring OpenFlow to the campus.
Cumulus Network share our vision of an Open Networking Era, in which an open ecosystem of partners offer choice and optionality to a broad set of customers. So this partnership provides a new disaggregated networking model based on fixed-configuration switches and open-source operating system. It is a perfect alignment of our open-source commitment with Cumulus’ success.
TRP: What is the significance of an open source approach to SDN?
DV: It fits an overall request from customers for an open framework in which they can develop their own functionality. We have seen for a good while now the great demand for open frameworks through the growth of the OpenFlow developer community and the popularity surrounding the Open Compute Programme.
SDN is making significant progress in the networking market and open source is definitely an area where we believe there is movement; breaking the silos and providing customers with the option of having an open environment which gives them a freedom of programmability.
It must be said though that the open source approach will not work for everyone as not every customer has a dedicated Linux team capable of running their network. Not every organisation will have an existing data centre structure which supports open standards, nor can they easily upgrade to one.
We have seen a lot of early uptake in financial organisations, cloud and host providers as well as Web 2.0 organisations. In all instances, these organisations have large-scale, agile data centres which can really benefit from the cost reductions and increased control and manageability which an open source approach to SDN offers. It is from these industries that we are seeing the use cases.
For other businesses where an open source skillset is lacking, legacy networking architecture is too expensive to replace wholesale or networking is not a key priority for IT, more gradual paths of SDN migration are better suited.
TRP: What are the other paths available for businesses looking to move to SDN?
The SDN path we see the most activity in at the moment is the one being driven by virtualization companies like VMware and Microsoft; based on a hypervisor-based network virtualization model usually referred to as NVO (network virtualization overlay).
In this model, much like server virtualization, the introduction of virtual switches allows an organisation to run multiple virtual networks on a single physical network, while each virtual network retains the characteristics of running as a physical network.
We have been working closely with both VMware and Microsoft as this virtualization technology progresses – the new Dell S6000 switch is the first VMware NSX capable switch in the market – and whilst progress towards adoption will be quite gradual over the coming year, the virtualization route does inspire confidence from vendors due to the previous success in virtualization within the server.
The third approach encompasses a programmable framework where individual switches retain their control plane functions yet through an Application Programming Interface (API), allow control of the switch’s local data plane functions.
Lots of large organisations still rely on legacy networking architectures which would be far too expensive to rip and replace in its entirety and this approach has the main advantage of making use of existing infrastructure alongside new interoperable networking technology which is phased in slowly.
As part of our strategy to offer multiple paths to SDN and support these legacy-reliant customers, Dell switches offer SDN capability whilst providing interoperability with legacy programmatic interfaces including Telnet/CLI, TCL, REST, SNMP, Perl and Python scripting, and the upshot of this is that these large organisations can bring in these APIs for SDN through this gradual yet painless integration.
TRP: What issues do you see customers and vendors facing when choosing a path towards SDN?
DV: As SDN is very much in its infancy, trust from customers is essential to foster. SDN is an exciting new step for networking, but reservations are natural in an industry which by nature prefers tried and tested technology to invest in.
Whilst the benefits of adoption are well speculated taking the leap and making investments requires faith in the ability of the chosen vendor to deliver. This process is further complicated in instances when a specific migration path is suggested by vendors that threaten to lock customers into specific upgrades.
Proprietary solutions carry the inherent risk of taking the customer down a route which eventually transpires to be less cost effective, yet locks the client in, so that moving to a different solution presents