Nominee’s bio and/or LinkedIn profile

David's LinkedIn Profile

How long have been working in the ONOS community?

I have worked in and around the ONOS community for about 4 to 5 years. When I was first introduced to ONOS it was before ONOS had opened it's source code to the public; which gave a limited opportunity for Ciena to work directly with ONOS. While Ciena supported ONOS, at that time Ciena started to develop with OpenDaylight (ODL). About 3.5 to 4 years ago Ciena shifted its technology focus from ODL to ONOS. Since this shift, my focus has been helping to harden ONOS  as well as help with the development of the CORD and VOLTHA solutions. I have been a member of the ONOS TST since the 2016 voting cycle.

What contributions have you made in the past to the ONOS community?

My past contributions to the ONOS community are more focused on architectural and directional input than high volumes of code. I did provide some of the original work, which has since been redone, for the Docker containerization of ONOS. I contribute to the community by providing help on the #slack channels and email list (as well as ask my share of questions). I have contributed to the community through public presentations at conferences and shows.

Most recently I have been developing a NETCONF/GNMI based driver for a Ciena device. This driver presents the Ciena device as a flow-oriented device that can participate in the Trellis fabric. During the development of this work, which I am working with Ciena legal to make public, I have submitted several JIRAs and patches to improve ONOS and the development of applications as external entities to ONOS's source code repository. This project is stored and builds in a separate repository from ONOS's core code.

I continue to be a vocal proponent of a disaggregated, micro-service based SDN controller that is lightweight, stable, scalable, and easy to deploy and operate. I have contributed toward this direction both in terms of conference talks as well as participation in the TST meetings.

 What are you actively working on in ONOS?

As stated above, my most current activities involved the development of a NETCONF/GNMI based driver for a Ciena device so that it can participate in the Trellis fabric. This work allowed me to dig into the bowels of ONOS and get a much better understanding of its interworkings as well as areas where I could see a need for improvement as we work toward ONOS-NG. In the less recent past, I have contributed to ONOS via the applications that are meant to support SEBA/VOLTHA.

At the last ONF Connect, with the help of a co-worker, we developed and presented on using machine learning (ML) techniques (linear inferencing) leveraging the Stratum P4 work that is part of ONOS.

While not directly related to ONOS, I developed the OFtee application that is an experiment to allow the development of OF based SDN applications independently of any controller. This works with both ONOS and ODL as it sits between an OF device and the controller and "tee"s certain OF messages to external applications for reactive processing. This work led to a relationship with individuals at Purdue who are now developing a GRPC bridge to allow the externalization of ONOS events to other processes.

Why do you feel you would be a good candidate for this position?

The short answer is that I have the outside perspective that is focused on producing a carrier class, production release. I bring the alternative perspective to a lot of architecture discussion, focusing on how to provide a quality core while providing the ability to independently develop solutions on top of ONOS.

Are there any changes you would like to bring to the community if elected into this position?

I think the ONOS community is a vibrant community with good participation. As such, I don't see any significant changes I would bring in terms of community organization or input. Where I see that I will have the most impact is to continue to push for a disaggregated, micro service based controller where only a few core capabilities are in process and other services (intents, analysis, troubleshooting) are external to this core process. I see a continued push for a smaller, lighter core process and use of off the shelf components instead of homegrown technologies. My focus is less on network research and more on delivering an SDN controller that can confidently be deployed in large customer production networks.