You are here

OpenDaylight Developer Spotlight: Madhu Venugopal

Madhu Venugopal

OpenDaylight is an open source project and open to all. Developers can contribute at the individual level just like any other open source project. This blog series highlights the people who are collaborating to create the future of SDN and NFV.

Madhu Venugopal is a Senior Principal Software Engineer at Red Hat Inc. He is currently involved in Software-Defined Networking (SDN) and Network Virtualization solutions in the Office of the CTO at Red Hat. Prior to Red Hat, he worked for Cisco Systems for more than a decade. During his time at Cisco Systems, he worked on various networking technologies: SDN, protocol development, distributed forwarding architectures, multiple generations of forwarding ASICs, network optimizations for video applications and virtualization. He is very passionate about open source software, helping develop other community contributors and believes strongly in the fact that open source software will define the standards of tomorrow. He is on Twitter at @MadhuVenugopal.

How did you get involved with OpenDaylight? What is your background?

I am fortunate to have been part of the Cisco Team from day one that researched and developed the Cisco ONE Controller. Early in the OpenDaylight project, Colin Dixon and David Erickson created a proposal for the main controller that merged code from Cisco ONE and another controller. I am extremely proud and humbled for being one of the earliest committers and contributors to this project that has the potential to redefine networking for next-generation applications and networks.

Prior to OpenDaylight, I spent a decade in developing various networking technologies including:

  • Unicast and Multicast protocol development;
  • Custom driver development for various distributed forwarding platforms;
  • Network optimizations for video and virtual desktop applications; and
  • Virtualization.

What projects are you working on for OpenDaylight? Any new developments to share?

I am currently active in the OpenDaylight Controller Platform, OVSDB Southbound plugin and OpenDayLight User eXperience (dlux) projects.

After the successful implementation of the controller platform's clustering support, the current migration to a Model-Driven Service Abstraction Layer (MD-SAL) is the newest development. In my opinion, the OVSDB Southbound Plugin project is one of the most exciting projects with a lot of potential and expectations for the Hydrogen release. The OVSDB project contributors are working very hard at building a solid platform to integrate the OpenDaylight Controller (and other projects) with OpenStack and Open vSwitch. With OVSDB getting wider adoption beyond Open vSwitch, developing a solid extensible OVSDB plugin is one of our top priorities. It is also the most diverse project with contributors from various community members.

OpenDaylight dlux (pronounced “deluxe”) is the newest project approved by the Technical Steering Committee (TSC) in October, and it stands for “DayLight User eXperience”. If there is one thing that I learned through my experience in the past decade, having a solid management story is critical for the adoption of any product/project. The objective of dlux is to provide that unified management through user-friendly tools that is developed on the REST API exposed by the controller and other projects. The dlux project is also a community submitted project that was sourced from feedback and code submissions from the OpenDaylight user community.

People have different definitions for Software-Defined Networking (SDN) depending on how they’re using the network. What’s your definition of SDN?

I have come to believe that the definition for SDN is intentionally vague and rightly so. Having a specific definition might unintentionally box a technology transition like SDN to specific use-cases/deployment scenarios. Having such rich and different definitions for SDN from various folks in the industry is the strength of SDN, and I for one would like to embrace it.

Summarizing a few definitions that I have heard:

  • Separation of control-plane and data-plane;
  • Programmability;
  • Defining the cloud networking;
  • Network virtualization;
  • Next-generation network management; and
  • Network agility and operational simplicity.

I think SDN covers a wider scope and can hold all of these definitions and more.

From your perspective, what are the major benefits of making OpenDaylight an open source project?

Major long-term benefits of making OpenDaylight an open source project follow similar or same reasoning as any other major open source project (such as the Linux kernel). These are amply covered by various articles such as: "What is Open Source" and "Why Open Source." Having seen OpenDaylight's Controller platform evolve, I have seen many benefits from a developer perspective:

Growth from handful of developers with similar expertise to hundreds of developers with varied expertise and experience contributing for a common goal;

  • The humbling opportunity to work with some of the brightest developers in the industry across vendor boundaries with extensive expertise in both software development and networking;
  • Improved software quality in a very short time. (Please refer to eWeek's Linux kernel review. Dated, but still holds the truth);
  • The pleasure to work closely with non-vendor community and industry experts like Brent Salisbury; and
  • As a result of OpenDaylight's diversity and collaborative spirit, I have witnessed an exponential growth in the communities knowledge, effort and inspiration. It is even more remarkable that OpenDaylight is still less than a year old.

What advice would you give to someone just getting started in an open source project?

OpenDaylight is a unique project where there are equal opportunities to participate and contribute for both software engineers and network engineers. Also, SDN blurs the line between software and network engineers. This provides an opportunity for a mixed expertise and collaboration by sharing the experience with one another.

For software engineers, the best way to get started is to download the code, start hacking and work with industry leading network experts to understand the deployment challenges facing today's networks.

For network engineers, this is an opportunity to work closely with some of brightest software engineers who have developed the networking products that they have operated and architected for many years but may have never had a glimpse at what takes place in the development process. We are already witnessing OpenDaylight team members from the community take this great opportunity to evolve their skill-sets and computational understanding with the encouragement and camaraderie that such an epic project brings to the table. In addition of gaining programming and software design expertise, it is the very rare opportunity to influence the future of networking.

  • Join the discussion at IRC channel #OpenDaylight at;
  • Join the mailers;
  • Participate in TSC and Technical Work Stream Meetings, which are open to everyone; and
  • Participate in HackFests and Virtual HackFests that occur on IRC along with the great conversations in channel that happen daily.

What is the best piece of developer advice you’ve ever received?

Rough consensus and running code. Vice versa.