VMware's Bruce Davie brought some fireworks to the Open Networking Summit last week with a feisty presentation, driving a wedge between the concepts of network virtualization and SDN.
An interesting occurrence at this year’s Open Networking Summit was around the definition of Software-defined networking (SDN). At the opening session, ONS chair Guru Parulkar highlighted something he called “SDN washing” – which is when networking vendors essentially take their existing technologies and try to re-label them as SDN products in attempt to cash in on some of the hype and popularity that has arisen around OpenFlow and SDN. Since the first Open Networking Summit in 2011, the industry has seen no shortage of SDN washing; this was clearly most noticeable early on when the term SDN first became common. At that time, the initial response from most vendors seemed to be an attempt to demonstrate that each individually had a stranglehold on all things innovative, and that these academics pushing this new OpenFlow stuff really didn’t understand networking. According to most vendors at the time, ‘real SDN’ was whatever each vendor happened to have already been working on. But the folks at ONF held firm on their definition, and as time has passed vendors have accelerated their support for newer and more open and innovative efforts.
Dr. Parulkar laid down a clear definition for SDN and some clear positive benefits for the industry, network operators and consumers if open, standard frameworks win over proprietary and vendor-driven offerings.
And after the opening remarks, almost every presenter made a point to give a definition of SDN that was nearly identical to the ONF definition – that is until VMware’s Bruce Davie made it to the stage. Dr. Davie’s distinction, however, was a bit unexpected; he did not contest the SDN definition that the ONF gave, but instead proclaimed that SDN and network virtualization (via hypervisor overlays) are two entirely separate things. What Dr. Davie was referring to as ‘network virtualization’ involves recent advancements that enable server hypervisors to establish tunnels to each other, thereby creating a separate virtual network that is somewhat independent of the physical network upon which it happens to reside. All leading virtualization and cloud software providers are now incorporating hypervisor tunneling into their solutions, and this effort is similar too, but independent from the advancement of OpenFlow and SDN in physical networking hardware.
While some may see this distinction as splitting hairs, this is a significant distinction to be made – and for enterprises in particular, a little controversy to drive a point may be worthwhile. SDN was never just supposed to be about OpenFlow, but ‘SDN washing’ has occurred in many cases where switch vendors appeared to want to slow the pace of innovation in SDN to prolong the sales of previous generation product lines. This caused an increased focus on OpenFlow, specifically as THE example of SDN. ONS is not a little academic conference at Stanford anymore and now has tremendous global visibility. Its popularity has risen so quickly it has gained widespread attention in enterprise IT while much of the topics being discussed at the conference are still in the developmental stage well before these technologies are ready for enterprise consumption.
These factors have contributed to increasing confusion among enterprises as to when, how and where SDN benefits will be delivered. But for the enterprise, one thing is absolutely clear: The first wave of SDN value in the enterprise data center will be delivered via Network Virtualization Overlays. If you are in enterprise IT and are looking to take advantage of all the compelling benefits of SDN, don’t wait to hear what is happening with OpenFlow hardware or in the next wave of physical switches. If you haven’t started planning an overlay network for your virtualized environment, my advice would be to do it today…heck, if you could rewind time and start planning this last year, you should. The majority of value that enterprises can get from SDN today can be delivered through hypervisor overlay networks. I would go a step further and say the future evolution of SDN technologies cannot be delivered effectively until enterprises first roll out hypervisor overlay networks. Why? Because hypervisor overlay networks will fundamentally change the role of what the physical network does and the value it provides.
When VMware and server virtualization technologies started becoming popular over a decade ago, the traditional method of providing network services fundamentally changed. For servers, there was an immediate positive impact, but in the network, policy and service configuration has never been successfully adapted and is still optimized for the same methods used in the client server era. This has resulted in a hodge-podge of new competing ideas and a lot of bubble gum and band-aid approaches to providing network services to virtual servers.
Prior to server virtualization, there wasn’t such a thing as vmotion. Once a server was configured it remained relatively static, making it easy to associate network policy with a physical port on a physical switch. And from the beginning of the client-server era, this was how networks were configured: a network engineer figured out the static application profile of the server, then put a static network configuration on the physical switch port(s) the server was connected to. The network didn’t have any understanding of what was actually connected to its port, but would apply the configured policy to whatever traffic was received through this port. The physical switch a server directly connects to, known as the ‘access layer’ (or access switch), has always had a special purpose – this was THE location at which value-added services provided by the network were applied. The access switch can change bits in each of the packets of data to classify how other networking devices in the path between a server and a client should treat the traffic. This pattern placed added significance to the access switch – much of the value networking vendors have been working to provide to keep prices and margins high in networking switches was around services provided at this interface.
However, when server virtualization is used, it fundamentally changes the relationship between the server and the physical access switch. First, virtualization increased the quantity of applications that generally ran on a physical server. In the past, it was common to see a 1:1 application-to-server ratio. Today, it is common to see a 20:1 ratio of different virtual machines running on a single physical server. Because physical networking devices are even today still optimized to provide network services based on a physical switch port, traditional switches are incapable of intelligently distinguishing which traffic is being sent by which VM.
Next, and perhaps more importantly, virtual machines are conducive to dynamic migration, so not only is there now a large number of logical servers connected to a single physical switch port, these servers also do not remain static – another thing traditional networking devices are completely incapable of dealing with. So today the network team needs to open a trouble ticket to manually move the configuration associated with a virutal machine to the physical switch ports the new physical server is conncted to in order to move a virtual machine. Now all of that gets REALLY complicated … for example when moving the policy in the above example, if we are moving the virtual machine to another physical server that already has 19 other VM’s on it, the policy that needs to be moved would need to be rationalized with the policy that already exists on that switch port which may not even be possible.
The result in my experience has been a significant proliferation of one-off approaches to application deployments combined with a significant dumbing down of network service provisioning in virtualized environments. Today if you look in a textbook, the best practices for configuring the data center network are identical to what they have been since the beginning of the client server era. First when preparing to deploy an application: figure out what network services are needed by the application, configure an access list to identify different traffic classes and then mark or block each packet so it gets appropriate treatment. However due to the immense complexity and the critical need for agility, very few enterprise IT departments even attempt to do this for the vast majority of applications. Server virtualization brought with it massive improvements in speed, agility, operational streamlining and beyond … but the network hasn’t been ready for that change.
As a result, in most environments the network is providing a small fraction of the value-added services that are used to justify the cost premiums of many network switching platforms. Instead traditional network vendors had been standing in the way of a solution to this problem by continuing to prop up legacy ideals of how physical networks should be configured and what functions they should provide. In practice most of value-added network services have been dumbed down to simply using vlan based segmentation between traffic classes and even for this simple requirement, traditional networking still fails miserably as switches from leading vendors are generally still completely unable to dynamically update vlan requirements to support an automated virtual machine migration.
Server virtualization did however come with a solution to this problem – the hypervisor switch – a place where networking service policies can be configured easily during application provisioning and remain associated with the virtual machine when it moves. But this approach has been mired in political battles and obfuscated by years of attempts by vendors for alternative approaches aimed at unnaturally keeping all network services within physical networking devices. Whether that made sense or not was secondary to leading networking vendors whose primary objective was making their own products as relevant and as margin-rich as possible. Now to be fair, especially in the early days of server virtualization most were focused on stuffing as many VM’s as possible into a server and did not want to share CPU and Memory for networking requirements. While there is truth to this – this is a solvable dilemma that has already been solved for practical purposes today. But there has been no shortage of competing methodologies that have added to the confusion around delivering network services in virtualized environments, and today there is still competing messaging around whether to use hypervisor switches or used specialized NICs or specialized methods to provision per-vm policy in the physical access switch.
Today however there should be no more confusion around this issue, it is very clear the hypervisor switch is the natural and best fit for provisioning application-related network policy & services. Hypervisor switches are rapidly growing to better support the few remaining access-layer capabilities they don’t yet support well. And while there still may be competing ideas there is one primary factor that has sealed the nail in the coffin of competing methodologies: the cloud.
Another thing we saw a lot of at Open Networking Summit was the rising maturity of Infrastructure-as-a-service (IaaS), which is rapidly growing to support complex enterprise requirements and native layer-2 connectivity options that can make cloud-based infrastructure act just like infrastructure on the premise. The new wave of enterprise-ready IaaS services now becoming available are attractive not only from a cost standpoint, but in most cases offer far more agile management tools and unique capabilities most enterprise IT environments cannot yet deliver. It is astoundingly clear that enterprise IT needs to start delivering comparable services to cloud providers at a low price point and also have an intelligent hybrid cloud strategy so that IT can provide governance and control of cloud services for the enterprise.
You may be wondering what all this has to do with the server access layer – here is the punchline: all the methods competing with virtual switches for controlling network services have specific contingencies in physical hardware that the virtual machine environment resides on. And if your virtual machine needs to use a piece of hardware to provide a critical service, then when that virtual machine moves, it not only needs to move to another location with the same hardware, it also requires a separate mechanism to transport the configuration for that hardware to the new location. This complicates virtual machines migrations when moving to another server whether on-premise or to the cloud … and this forms the basis by which several vendors are looking to find a new vendor lock-in strategy. When virtual machines are transported, they do not carry information with them about how the physical hardware is configured. So, if an enterprise believes a specific hardware configuration is needed, then that virtual machine can only be transported to a hybrid/public cloud partner that supports the same hardware and the proprietary mechanism used to transport the hardware configuration. The more networking services that are added to this mix, the more complex the vendor lock-in becomes. This can also be true even when using some virtualized network services so it is very important and also very possible to avoid these extensively locked-in scenarios. The last thing that enterprises need today, especially as they move towards adopting cloud technologies, is increased vendor lock-in – it should be the opposite – increased consumer empowerment. And if awareness around this issue is not raised many enterprises could end up locked into an entire service-chain of lock in built on lock-in built on lock-in all the way up into the cloud.
A lot of what we are discussing here is fundamentally new, and correspondingly there will be proprietary methods to address newer aspects of cloud-based network service-provisioning in the near term while we are waiting for de facto and de jour standards to emerge. But just how temporary and locked-in each solution will be varies tremendously, and if enterprise consumers are smart about their approach today there is already ample information to help customers go down the right path. While this is a topic for another post, perhaps the most clear and substantive piece of guidance is to avoid hardware contingencies as much as possible, and if you have a critical need to deploy anything that is contingent on physical hardware today, work to understand the path to migrate towards a virtualized service and plan expedited migration to virtualized services as they become feasible for your environment. Microsoft and VMware are trying to move away from vendor-specific hardware requirements for their private-cloud environments, though of course these vendors private-cloud solutions will be optimized to work with their own hybrid public cloud offerings – but that does not have to mean lock-in. The key focal point here will be around the standards evolving to associate a virtual machine’s required network policy with the virtual machine container itself. And today beyond a single virtual machine’s individual networking policy, increasingly applications need to be deployed in clusters with specific network requirements for the entire cluster … and using virtualized networking is the most flexible way to prepare these applications and their required topologies and service chains for portability. The rise of OpenStack has made a substantive impact on this effort and though VMware and Microsoft are not OpenStack … industry pressure stemming from OpenStack to encourage robust compliance with OpenStack are aggressively pushing vendors in an increasingly open direction where hopefully as hybrid cloud solutions mature we will see vendor differentiation happen around toolsets and not around trying to create closed approaches to lock down virtual machine network policies and virtual network requirements.
Now with all that said, what does this mean to OpenFlow, ONS and the SDN community? My take is, it should change nothing. This is the same exact perspective that enterprises should have had a year ago, and that perspective is that network virtualization overlays are ready to go right now, and you can get started right away with whatever physical infrastructure you have in place. While I don’t question the motives of the core Nicira team, I do think many at VMware would not like a perceived need for new hardware to encumber purchases of vcloud and advanced hypervisor networking software. Putting private-cloud type architecture on traditional/legacy physical network architecture will work in most cases but it will have significant performance challenges and will limit the amount of applications that can be successfully ported into an orchestrated private-cloud environment, but that should not be a deterrent to get started with what you have today. And if you are at a stage where you can plan for a network hardware refresh, there has already been highly significant innovation in physical hardware resulting in platforms that can fully support the needs of advanced hypervisor networks today, empowering enterprises to move forward with full confidence these platforms will deliver massive value throughout their lifecycle.
The new class of network switching hardware now becoming available is built on what I call the ‘triple convergence’ combining the impact of 3 significant industry inflections. 1st, the evolution of public cloud networks was based on Clos/Spine-Leaf architecture with ECMP & L3 Multipathing. 2nd, the evolution of enterprise fabrics had been focused on distributed systems, convergence, DCB & L2 Multipathing and then 3rd, SDN has created a significant inflection that impacts both of these earlier paradigms. These 3 areas each have significant strengths and each had been competing with the other to claim king of the hill for the future of the network. But today a relatively new class of devices has emerged that delivers the strengths and benefits of each of these paradigms. This new class of hardware is optimized for the Clos/Spine-Leaf architecture while adding support for enterprise fabric requirements and SDN. This provides the proper foundation for virtualized and cloud applications while also providing a performance and capability boost even for traditional and legacy applications. Clos architectures or enterprise-optimized Clos designs such as Dell’s Active Fabric (which I help work on in my ‘day job’) – these can provide one common data center architecture that can optimally support the triple convergence laying a foundation to optimally support cutting edge and future requirements along with the kitchen sink requirements that enterprise IT has to support today. I will go into more detail about this in a future post – and also want to note this is not a Dell commercial, many other vendors are now supporting high-density Clos-optimized platforms – the brand name that happens to be printed on the front of the box is completely secondary to the technology it supports.
This new class of hardware can optimally deliver the maximum benefits of enhanced programmability in the physical infrastructure while maximizing the benefits that can be provided by hypervisor overlay networks. The migration to advanced hypervisor networking will be very analogous to the initial deployment of server virtualization where initially only a relatively small percentage of applications were supported as VM’s and over time as technology matured support increased and now the vast majority of new applications are built to run in virtual environments. Likewise, only a subset of applications will be able to work optimally in a dynamically orchestrated elastic private cloud today, just how many apps and how much benefit will be largely contingent both on the maturity of the software and also on the maturing of the hardware to support these newer capabilities. So what is happening in OpenFlow will grow to unlock a continuing stream of value over time, but both the hardware and software available today are ready to go and can immediately start to deliver all of the most immediately relevant benefits that enterprises care about today. Everything enterprises want, need and can absorb today is ready, so my guidance would be to get an NVO strategy, get some good Clos-optimized hardware and that alone will keep enterprise IT very busy while providing massive value for years to come.
While OpenFlow and other methods to address SDN in the physical network will have a major impact, it is network overlays that pave the way for the SDN revolution in networking to take hold and have its fullest impact. And it is for this reason that attention needs to be brought, whether the means be controversial or not, the future of the evolution of SDN for enterprise data centers is contingent upon more practical deployments and advancements in virtual overlay networks. We should not be thinking about how merchant silicon should evolve to support legacy DC use cases and features; instead we should be thinking about how data center targeted silicon should be evolving in a post-NVO world … this will drive the type of cost-benefit in hardware people have hoped to see from SDN. We shouldn’t be focusing on how we can be using OpenFlow to manipulate flows to best trombone and take suboptimal network paths to inject physical appliances into east-west traffic flows; instead should be focusing on applying advanced network services inside the virtual network to take advantage of the cost, agility and portability/flexibility benefits of this approach. We should not be focusing on how enterprise applications will ‘talk’ directly to the physical network, but instead be thinking about how application requirements will be delivered to the virtual infrastructure which will then distill the application requirements into a very different type of request to the physical network as needed. This buffer space in the hypervisor network is important to limit the quantity of network change requests emanating from the applications to the physical network – the physical network needs to grow more dynamic but that doesn’t mean it will be chatting constantly with hundreds of applications as the virtual network may grow to do. This abstraction will help to bring the best combination of benefits from an increasingly dynamic, programmable fabric that still requires rock-hard stability.
Where I part way’s with Dr. Davie is around the definition of SDN. I consider advanced hypervisor networking to be part of SDN. But I also part ways with Bethany Meyer’s description of overlays as a mere example of a SDN application. And while I appreciate ONF’s focus on preventing vendors from positioning their existing solutions as superior to a controller-based approach – I also don’t agree that SDN is only controller-based or always has to physically separate control and forwarding planes. The SDN movement would not have happened without a lot of academics & major industry players fighting to make it happen … but ultimately the SDN movement is about changing the industry primarily for the benefit of industry consumers and the advancement of the internet and the associated good it can bring to society. While we can debate where we cross the t’s and dot the i’s this does not highlight the real value of what the SDN movement is where much like the term ‘cloud’ it may be fuzzy, but from a 10,000 foot view everyone is fully aware of the revolutionary impact that the bucket of things we simply call ‘the cloud’ is having across the whole fabric of society.
I am less concerned with what SDN is and more concerned with what it means to the people whom it benefits. SDN is about the fact that a decade ago 90% of the world’s knowledge of networking software was locked into private closed door meetings and the vast majority of people trying to innovate in networking were doing so within restricted, closed paradigms – and today we have a rapidly growing, open body of developers who are now empowered to take new approaches which will emanate from the foundation we are laying in place. The ‘cloud’ evolves at the pace which it does today only because we have opened up the underlying technologies to the eyes and minds of millions across all of society. There are no special people with special brains in this world we all have unique insights and unique value to contribute and the more that more people can be involved the more we can together innovate and bring real meaningful change. And the more people that engage in this effort the more it will be apparent that innovation is really about us, it’s about all of us, coming together and working towards a common goal. And the more of us that join in and contribute to this effort the harder it will become for a greedy rich few to steal away innovations for their own benefit. Innovation was never about some elite people in a closed environment trying to get rich, innovation is about solving real problems that affect real people, and today our entire society is afflicted by a LOT of problems. I love computer and internet technology because of the amazingly positive impact it can have on the many ills that plague our world today. And the more this is open, the more we can rapidly innovate and rapidly disseminate knowledge and innovation so it can be applied to all those who desperately need new applications of technology to solve challenges in their own lives. The networking of computing technologies is to this century what electricity was to the last, it is a foundational technology that is changing the entire fabric of society – as Dr. Vint Cerf elegantly outlined in his excellent presentation.
SDN is nothing more than doing networking the way that it should have always been done, opening up the development paradigm and building an open source community so we can help make sure we are applying the latest technologies and so vendors cant as easily use dark corners and secrets to manipulate consumers and industries. And SDN is not any one thing, it isn’t just about enterprise campus, or data center, or SP wan, or software defined radio access networks or sensors or any one or any group of things … it is about disseminating knowledge across society to share information on how to best network things whether that be TCP/IP, Bluetooth, DWDM or anything. SDN is about the fact that just a few years ago less than 10% of the billions of microprocessors that got shipped were attached to the network and today this is changing, rapidly. That can mean a whole lot of value, a lot of jobs, careers and industries to be built and the more we open and share the knowledge the more people will be able to benefit. There is no magical Noah’s ark of legacy networking; the SDN movement is simply about bringing the best that science can offer, as openly as possible, for the benefit of society.
Disclaimer: I am a Dell employee but thoughts and opinions shared in this blog are my own and are not necessarily those of Dell or its affilliates.
