We just completed the Euro17 LSO Hackathon, the 4th in a series of events within MEF accelerating the standardization and adoption of MEF’s LSO Architecture. The LSO Architecture enables Lifecycle Service Orchestration, or LSO, an agile approach to automating network service lifecycles for coordinated management and control across all network domains responsible for delivering an end-to-end connectivity service (e.g., carrier ethernet, IP VPN, MPLS, etc.).
The LSO Hackathons encourage the creation and enhancement of reference implementations that use the APIs and interfaces being defined within MEF. The outputs of the hackathon include for the following:
validation of evolving APIs/standards
feedback into MEF technical committees
creation of software defined networking (SDN) controller plugins, interfaces to network orchestration solutions, etc.
They also promote collaboration across related standards development organizations (SDOs), such as IETF and TM Forum, and with open source communities, such as OpenDaylight, OpenStack, PNDA, etc. Benefits of this collaboration include:
increased awareness, open discussions
support for LSO APIs in relevant open source projects
more running code, e.g. sample code, utilities, test tools
The Euro17 Hackathon was April 24-26 in Frankfurt, Germany, in conjunction with MEF’s Q2 Member Meeting. Contrary to what you might think when you hear the word hackathon, LSO Hackathons are collaborative, featuring friendly competition. They are meant to break down silos, connect people from different companies and technical disciplines, and facilitate sharing perspectives, tips, and ideas. Participants have a common goal, to increase the pace and quality of LSO APIs and implementations. The hackathon is open to everyone, not just MEF member companies, and participation is free.
Participants at the Euro17 hackathon rallied around three main projects.
The teams worked extremely well together, kicking things off Monday, continuing through Tuesday, and wrapping up in time to present their results to fellow hackathon participants and the MEF community at large late afternoon Wednesday.
The results presentations covered the following:
Recap of problem being solved and plan to solve it
What was actually accomplished?
Lessons learned, feedback for technical committees, and next steps
The LSO Sonata Release 1 team consisted of a mix of local and remote. Local participation is encouraged to get the most of the hackathon, but these team proved that remote participation can work well with the right mix of participants. Companies involved included AT&T, TI Sparkle, and Cataworx. A prototype version of Sonata serviceability and ordering APIs were used to simulate a customer placing an order and multiple service providers exchanging information about that order. Information obtained from the ordering APIs was mapped internally by implementations through the Legato level to ultimately interact with OpenDaylight via Presto API to activate a connectivity service ordered by a customer.
A subproject within the team involved the creation of a simple service that exposed a subset for the Sonata API, which when triggered, mapped Sonata requests through the Legato interface level and it into corresponding Presto requests. Following the hackathon, the plan is to open source this code and have an instance running in MEFnet that is enhanced to support a larger set of APIs over time.
The LSO Presto Release 1 team used the latest Presto API defined by the Network Resource Provisioning (NRP) project within MEF and added support for this API to OpenDaylight Unimgr. This was used as the basis for supporting the Presto API interaction by the LSO Sonata R1 team. The team also enhanced the Unimgr driver framework that facilitates the definition of multiple different network element drivers for interworking with equipment from different vendors and open source projects. They also created a template to make the creation of new drivers more straightforward. The code developed will be contributed upstream to OpenDaylight as part of the Nitrogen release.
The LSO Analytics via PNDA project worked on building some big data analytics for LSO deployments using PNDA, an open source platform for network data analytics. The first goal was to collect a lot of data. This was accomplished by collecting data from syslogs from Cisco ASR9Ks hosted within MEFnet using logstash, and from interface counters and frame delay measurements available via OpenDaylight. This information was ingested by PNDA as live data feeds from which time series graphs were generated. While the team did not achieve their ultimate goal of creating a closed loop system that made real time changes to the network based on result of analysis of the data, they made it clear that such a system could be realized in the future.
All the project presentations and recordings of the kickoff and wrap-up from the hackathon are available on the agenda page of the Euro17 LSO Hackathon wiki.
Having survived the hackathon and accomplished great things, the participants took to the streets of Frankfurt for some well-deserved celebration.
Thanks to our sponsors for the Euro17 hackathon, without whom all this great work would not have happened. As you might expect, they are already looking forward to the next hackathon at MEF17, November 13-15 in Orlando, Florida. We hope you join us there.
Hi, Question: I'm trying to change interface ip address using ncclient. Rather than changing the IP, it keeps adding a secondary IP instead. Is there a way to change the existing ip rather than keep adding new secondary IP? ...
We are NOT finding the UM models that are in IOS-XR in the documentation. This documentation is very helpful for new engineers to start the automation and would be great if you could do the updation soon.
Sample of models am pasting he...
I need to know if this is possible using API over switches 9200Is necessary to verify the "error disable" status in any interface on the switches due to violation by "port security" an them perform shutdown and no shutdown to this interface.
It is my understanding that the issue is that the CU surpases the ".maxResults" of 1000. Based on my research, exceeding this threshold will impact production by creating timeouts. Is that right?
In addition, to override this limit, we need to edi...
Networking Automation and Analytics Knowledge Base
For one-on-one help with these products, you can open a ticket at https://developer.cisco.com/site/support/. For other products, please contact Cisco TAC at https://www.cisco.com/c/en/u...