Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
Nominee’s bio (and/or LinkedIn profile)
How long have been working in the ONOS community?
I've started working on ONOS in October 2015 through my Internship at ONF, working on Southbound Integration, at the end of my internship I continued working part time with community focus until I joined full time at ONF in February 2017. You can find me on slack as @andreaas @andrea
What contributions have you made in the past to the ONOS community?
During my internship I built Support in ONOS for different southbound protocols, mainly NETCONF and REST, but also SNMP. I contributed to the development and enhancements of the whole southbound and drivers subsystem, with particular attention to FallBack providers and *Programmable classes (e.g. FlowRuleProgrammable). Many of these elements lay at the foundation of different use-cases and applications of ONOS today, such as ODTN and the P4 programmable data plane subsystems. I also worked on Alarms Subsystem. Since I joined full-time at ONF I worked in enhancing and supporting many use cases, such as Trellis, ODTN, P4 and P4 Runtime integration and lately SEBA and it's ONOS apps.
In 2018 and 2019 I was part of the Trellis Team the brought ONOS in production at COMCAST.
Since July 2018 I'm leading ve also the ODTN (Open Disaggregated Transport Network) project, building on the foundations of the ONOS platform we built a solution for Data Centre interconnect , integrating Openconfig Transponders, TAPI Open Line Systems and OpenRoadm ROADMS. ODTN went it's first field trial with Telefonica Del Perù in October 2019, where ODTN controlled two Edgecore packet optical transponders in both long-haul and short-haul scenarios. As ODTN lead I've led the path to a very strong collaboration with TIP and presented ONOS and ONF at many events (TIP summit, OFC, ECOC)with whiteboxes and open APIs, that underwent field trials in Telefonica Del Perù.
In 2019 i was part of the original µONOS team, creating the foundation of Since march I started also working with the µONOS team on the next generation of ONOS, micro-service based with gRPC interface and deployed on Kubernetes, my particular focus is onos-config, the configuration component of the new architecture, first demonstrated at ONF connect 19which is currently the base for SD-RAN and has been in production with AETHER.
I also ran multiple meet-ups and events as an ONOS ambassadors to share ONOS and spread the word about the project.
What are you actively working on in ONOS?
Currently I'm working with the SEBA and VOLTHA team, mainly contributing to ONOS for features, bug-fixes and design discussion related to VOLTHA, especially around scale support.. Paired with VOLTHA ONOS is now in production in DT and TT with hundreds of thousands of customers, thanks to the continuous bug-fixes and iterations myself and the VOLTHA team has done in the past two years.
We are currently working on the 2.5 LTS branch, and have integrated in the past we are just about to finish the porting of all the apps needed for controlling a POD to onos-2.2. Such porting enables the SEBA to rely on a much stronger platform with LTS relates of many components such ask KARAF, Java 11 and such. As part of the SEBA team I'm also working to support Deutsche Telekom workflows with ANY_VLAN support and FTTB flows, PPPoE, Mac-Learning, VoIP.
In ODTN we are working for better Openconfig integration and building the Stratum Integration.
I'm also doing bug fixes and small enhancements across all the Platform with particular attention to production deloyments.
WE fixed several bugs and made optimizations to allow ONOS to support 10240 subscribers with ~170K flows in the TUrk Telekom workflow. Improvements were also made to allow 4096 ports to come up simultaneously, without issues of synchronization.
µONOS In µONOS I'm keeping a close tab on the work in doing with onos-ran, although with little active contribution due to the focus on SEBA. At the same time we are working on a proposal to start developing the basis for µONOS control, with flows, ports, and packet handling.
Why do you feel you would be a good candidate for this position?
I feel I could be a good candidate because I'm deeply involved in the project and I deeply care about it's its success and adoption. Having worked with ONOS since a long time I believe I have a good understanding and knowledge of the platform that could enable me to evaluate strength strengths and weaknesses of different decision decisions that are made from an architectural and implementation point of view.
I also believe that my involvement in the community and brigades service provide deployments enables me to bring in new use-cases, ideas and a different perspective in the TST. My unique position as an European Employee could benefit has proven very beneficial for the TST to strengthen the relationship with European community, SPs and Vendors and continuously incorporate their feedback.
Also by sitting in the TST and at the same time being involved in SEBA leading the VOLTHA/SEBA project and leading ODTN I could make sure the needs of both projects are accounted for during the TST decisions.
Finally I'm familiar with both ONOS "classic" and µONOSµONOS, thus being capable of discussing and deciding for both projects.
Are there any changes you would like to bring to the community if elected into this position?
As TST member I'd particularly like to continue to put focus on production needs to make sure the platform is sound for the production deployments that it's currently in and is selected for in the future, with special care for DT and TT VOLTHA ones.
I'd like to continue pushing and advancing the interactions and the attention of the TST towards the community, both with ONF partners and members and with single ONOS contributors, working in an even greater synergy.
I'd like to expand the pool of people participating from Partners and Members of ONF and representatives of the community at large and thus making sure that the ONOS roadmap is aligned with the needs of anybody using and deploying the code.As TST member I'd particularly put focus on production needs to make sure the platform is sound for the production deployments that it's currently in and is selected for in the future.