OpenDaylite Summit

Executive Director Neela Jacques makes his opening remarks at the ODL Summit

It is no secret that the IT industry is evolving, and the stereotype of the basement-dwelling ‘IT guy’ is quickly fading away. IT departments that only know systems and command-line interfaces (CLIs) are no longer enough to support modern businesses. In fact, the main concept of DevOps is bringing software engineering and IT together to automate infrastructure management and service delivery, and to drive day-to-day operations.

At the end of September 2016, I had the opportunity to attend the OpenDaylight Summit in beautiful Seattle. I saw many presentations covering a wide variety of software-defined networking (SDN) applications and use cases. But wait, hold up, what the heck is SDN!? By definition, SDN is an architectural approach to network design that uses open protocols and provides programmability to network elements, allowing them to be more dynamic, manageable, and adaptable. OpenDaylight, in particular, is the Linux Foundation’s realization of SDN.

Throughout the history of networking, network elements have typically been magic black boxes created by vendors to play certain roles in the network. Network engineers are typically knows as ‘CLI Jockeys,’ which speaks volumes about the tedious, vendor-specific tasks they often face. SDN aims to open source these network elements and allow users to tailor them to their individual functionality needs.

Let’s take a step back and talk about the various ‘planes’ in a network to help us understand the true value of SDN:

Imagine you’re the engineer of a large metropolitan transit system. Busses have designated routes that have been developed by city planners, and at their core they are designed to transfer people efficiently from place to place throughout the day. Now imagine that the busses are data packets that are part of a data flow in a network, and the people inside the busses represent that actual data. Visually, we can represent the roads in the city as the network links, such as an ethernet cable, and bus stations represent other network elements that have routes to different locations.

  • Control Plane: The control plane is the method by which these routes are learned. In the case of the transit system, the people riding the busses have to review all available bus routes to figure out the best way to reach their destination. In computer networking, this is done by routing protocols.
  • Data Plane: The data plane is the actual movement of the packets in the network. In the case of the transit system, this is the bus driver stepping on the gas and following the route. In computer networking, this is the router receiving incoming data packets and forwarding them over a network link based on what was learned from the control plane.
  • Management Plane: The management plane is the handling of packets that are intended for the network device itself. In the transit system analogy, this could be maintenance workers making repairs at a bus station. In computer networking, this is used for configuration changes, monitoring, troubleshooting, etc.

Network elements often muddle these three planes together, making them more static in their deployments. SDN is essentially a programmatic decomposition of these three planes, which:

  1. Leads to better separation of the planes, resulting in much higher uptime.
  2. Allows for independent evolution along these paths.
  3. Through the distributed software control plane, creates a clear separation of duties and manages complexity.

Network function virtualization (NFV), a concept that is complementary to (but not dependent on) SDN, aims at decoupling the various functions of a network device and defining them in software. Take a look at this article for a more detailed description. NFV allows for new network functions to be rolled out in days instead of months. It also enables businesses to scale quickly and effectively. SDN and NFV are typically most effective when combined.

The interesting points that stuck with me from this conference can be best summarized as this:

  1. OpenDaylight is only one particular realization/implementation of SDN, and there are many others.
  2. No single company’s product or solution is completely reliant on OpenDaylight on its own, or even SDN on its own.
  3. Thinking in terms of SDN helps, but it is far from a be-all, end-all networking solution.
  4. IT departments and providers can no longer think of the network as providing support to the product: the network IS the product.

What am I getting at here? The future of IT is not wed to the products or offerings of any single vendor. Rather, it’s dependent on the ability of every company to integrate different open source products together to fit their individual needs and drive innovation in the areas of service delivery, operations, infrastructure, etc.

Open source communities all around the world are leading the way to this DevOps future, and we at AppliedTrust are always dedicated to solving your hard IT problems so you can make the world awesome. If you’re interested in integrating SDN or any open source project into your IT portfolio, please do not hesitate to give us a call at 303.245.4545.

For more information about OpenDaylight and detailed use cases, please visit https://www.opendaylight.org/