I have to say that after an amazing Day 2 at the Open Networking Summit, I am convinced that OpenFlow and Software Defined Networking (SDN) are not only here to stay, but they will define the future of networking. I speak to a lot of enterprises about Software Defined Networking, and outside of the academic and development communities; it is still a new and somewhat unfamiliar term. With the protocol soup of new technologies being launched into the enterprise space, some may wonder how I can be so bullish, and the answer is simple: I just spent the day listening to nearly every major technology company, web portal, carrier and the leading academic researchers in networking, and they laid out an iron-clad case. Perhaps the greatest proof point for enterprises of the growth of SDN was Cisco's announcing support for OpenFlow, stating that SDN is "the next evolution of networking."
Day 2 of the summit began with summit chair's Guru Parulkar and Dan Pitt, noting that the turnout for the summit demonstrates that OpenFlow and SDN are no longer just science experiments, but are now seen as the future of networking.
I was able to record all of the sessions again today, but I have only had time to get a few of the videos up. Because I will be adding videos as I have time over the next few days, I have placed the links on my personal blog www.thetaoofinnovation.com under the open networking summit tab.
Nicira CTO and OpenFlow Inventor, Martin Casado: Origins of OpenFlow and Software Defined Networking.
In this presentation Martin provided a historical narrative of OpenFlow, what has made OpenFlow successful, and what he thinks we need to keep it successful. OpenFlow got its roots when Casado was working to support Federal DOD networks, trying to protect information that was sensitive to national security and human lives. He observed constant conflict and complexity trying to implement security policies and getting them to work in harmony with routing. Also of concern was that in highly sensitive environments, deploying new applications or moving servers was arduous. He also discovered that often his team would have to artificially impose poor architecture by doing things like reducing redundancy so as to have single choke point for security. There was a constant battle between what his team wanted to deploy, and the architectures that could be deployed with commercial equipment. The problems he was experiencing were not related to what he was trying to accomplish, but rather they were simply limitations of the way that networking technologies had been implemented. In his presentation, Martin provides further details of how these experiences lead him to develop OpenFlow.
UC Berkeley professor Scott Shenker: The Future of Networking, and the Past of Protocols
Shenker highlighted differences between networking and other fields of Science. He noted that Computer Science teaches basic principles, but networking teaches a big bag of protocols. He noted that networking has a huge academic community, publishes more protocols, and standards than any other computer-related discipline, yet the industry is still not innovating at near the same pace as as open systems. Why is Networking Lagging behind? Shenker observed that this lag is because the network requirements are so critical and so complex, and because we the industry have gotten so good at creating powerful and stable systems. However he also noted that this is both a blessing and a curse.. Simply put, the people who are best at mastering complexity are generally not good at extracting simplicity. Every other field that has matured past networking has done so by boiling the principles to their absolute most basic elements, to their very essence, and it is through this effort to extract simplicity that we are able to innovate. "Modularity based on abstraction is the way things get done". However in networking we have not done a great job at abstracting, we generally do not have any recognized abstraction layers. We do not have powerful control plane abstractions. We have to have each device manage its own state. We have protocols that do not provide guaranteed communication, and we accept this as the way things should be. He noted that if you presented these constraints to a programmer their typical response would be to redefine the problem. He noted that Only people who love complexity would embrace this model. Shenker stated that SDN is defined precisely by these three abstractions: distribution, forwarding, and configuration. This is not simply a trend, but can be derived by decomposing the network control problem and that the principles of SDN are foundational elements in the science behind network technologies. "This spells the end for distributed protocols, this is the beginning of the software era of networking". Shenker then noted that the culture of software communities is very different from the network community and observed that our the very nature and culture common in networking will have to change to be more like the software development community. "Software is king now, it is going to be a software oriented culture that is going to rule our field, and that is what will be hard for us to deal with." In the future things will be very different, we will look back not thinking we were wrong, but realizing that we had been naïve.
Stanford Professor Nick Mckeown: How SDN will Shape Networking.
Mckeown stated that SDN will empower network owners by allowing them to customize to their local needs. He noted that routers support more than 6000 RFC's, and that not implementing many of these features will not only reduce complexity and cost, but also should improve reliability. Another key value of SDN is the ability to significantly improve the time of innovation through use of abstraction layers and software. He highlighted a demonstration being given for Mininet, which can simulate thousands of network elements to enable rapid prototyping. SDN will also enable technology exchange between partners, and with universities. Mckeown also noted that SDN will enable supply chain diversity, and provide a robust foundation for networking technologies. "Abstracting the complexity of the underlying physical hardware will greatly speed the growth of networking."
Princeton Professor Jen Rexford: Frenetic, A programming language for OpenFlow networks
Rexford observed that routers have an order of magnitude greater amount of code than a space shuttle, and that the languages used to write this code was not designed to solve the challenges we are facing today. Her team is working to create a language that raises the level of abstraction for the programmer to program effectively on a software defined network. Frenetic simplifies the programmers' life, and also provides a run-time system. Rexford Highlighted numerous examples demonstrating how network programming is tricky and complex, and then demonstrated how much simpler these tasks would be using Frenetic.
Georgia Tech Professor Nick Feamster, Software Defined Network Management
Network Management is Hard! Software defined networking makes it easier for network operators to evolve network capabilities, but does it make networks easier for operators to deploy and manage?
Why is network management hard?
1. Configuration is complex and low-level
2. Network state is dynamic, things change constantly!
a. Yet, configuration is static and poorly integrated with the network.
b. Instead, network configuration should be dynamic.
3. Too much complexity is exposed (Even simple home use devices ask for several pieces of information that laymen don't understand)
4. Network devices are heterogeneous
a. Many components bolted on after the fact, they each have their own monitors, alarms, syslogs, traps etc, many of which are completely overlapping. It does not work like a system.
Feamster went on to describe how the simplicity enabled by OpenFlow and SDN enable a fundamentally simpler approach which can be used to make more powerful and simple network management tools. Feamster also noted that many home internet service providers now have usage caps, but there really isnt a good way to monitor and ensure that usage caps arent violated. He gave a very cool demo based on Georgia Tech's project BISmark of a very easy to use app that can monitor usage and block users once the usage cap is exceded. I highly recommend checking out the video.
Igor Gashinsky, Chief Architect Yahoo, Warehouse Scale Data Centers
Data centers being built to exceed >2 million VM's. He identified a problem with topology discovery: Routers spend about 30% of their CPU cycles recalculating topologies that often have not even changed.. Yahoo considered that they already had topology information in a database, so why not use SDN to program how the network to use a transactional database to maintain network state. Yahoo is also looking to use SDN to drive new levels of automation. Today the configuration management tools are "Awful", but the simplicity of SDN will lead towards much better automation tools. Yahoo is tired of waiting for vendors to fix bugs, or not being able to access new hardware because the vendor is working out bugs. They can just work out the bugs themselves or build the features they need. They feel that SDN will significantly improve the pace of innovation, primarily due to abstraction between layers.
Rainer Weidmann, Deutsche Telecom, Data Center 2020
DT has a joint project with Intel to develop greener data centers, and they see SDN as a significant enabler of greener IT. DT has done significant analysis in optimizing every aspect of how the data center can be optimized. They are looking to use SDN to enable elastic tree, reduce, power and heat, and drive new levels of automation to solve several additional challenges not related to power consumption.
Ken Duda, Arista Networks, The Data Center is Different
"The Data Center is particularly ripe territory for OpenFlow to make a difference." "I know where my mac addresses are, why does my network need to learn them." Ken highlighted all of the many things that networks do today, that they shouldn't need to do, and why SDN is the right model to address these challenges.
Albert Greenberg, Microsoft: Manage the data center as we do the servers
Why MS likes SDN: Much faster, simpler innovation. Ability to update features, without upgrading a thousand switches. "Zero Human Touch, predictable, highly reliable." IAAS providers need SDN to deal with the super-fast churn of VM's and services. Cloud data centers have tremendous pressure to innovate and drive down costs, and are also being tasked with a phenomenally high rate of new service offerings. To meet these demands they need simplicity, rapid prototyping and deployment." Greenburg noted that the industry needs to leverage the already proven model of systems management to take lessons learned.
Samrat Ganguly, Redefining Network Virtualization for the cloud and datacenter network with OpenFlow
Ganguly discussed the numerous business challenges that NEC is solving today with their OpenFlow controller, as well as many challenges that will be solved with OpenFlow and SDN. Some features he mentioned were the ability to automatically discover network paths, automatically avoid loops, automatic load balancing and many other features, all much faster than Spanning Tree. He noted that SDN improves reliability through constant awareness of network and device state.
David Jent, Indiana University, SDN's for Enterprise Solutions; We Can Do This
IU is one of the centers in the academic community for network technology. They are also one of the largest University systems in the United States, which is also one of the largest and most complex networks in the world. IU started to pursue OpenFlow and SDN a few years ago, they saw it as an opportunity to take a leading position in what they believe is the future of how networks will operate. IU started to develop an internship and a teaching curriculum for SDN, using their large production SDN environment.
Guido Appenzeller, Big Switch Networks, Network Virtualization for the Enterprise Data Center
Server Virtualization is driving changes in traffic patterns, which causes problems in the way networks have traditionally been run. He highlighted a study which found that moving to a private cloud environment drives a 3-6x increase in network trouble tickets. Big Switch is trying to achieve the goal of virtualizing the network such that virtual topologies can be built, torn down and adjusted on an as needed basis. They are also building different network views, where certain roles can have a global view, while team level admins can only administer the network elements which they have been assigned. Appenzeller noted that arbitrary virtual topologies could span multiple locations, and the abstract view provided to the administrator could mask the complexities of the physical network, and shield lower level administrators from even seeing any element of how other virtual topologies may be provisioned, providing assurance, simplicity and security for multi-tenant environments.
Charles Clark, HP Flexible Enterprise Networks