Service provisioning orchestration¶
Goal¶
GP4L group is collaborating with the Polish NREN PIONIER on developing a generalized, reusable approach to orchestrating service provisioning.
The starting point for this initiative is the TM Forum standardized process of order to payment, encompassing all steps required to capture a service order, configure and test the service, set up monitoring, and fulfill the client order, including billing if necessary. By abstracting this process to define common steps in service provisioning, the goal is to provide a collaborative blueprint that can be adopted by other NRENs. The modular nature of the approach allows the creation of a repository of processes, sub-processes, and elementary tasks that can be reused across the community.
To facilitate reuse while maintaining flexibility, the PIONIER use-case employs the AirFlow orchestrator. AirFlow enables the definition of processes in the form of directed acyclic graphs (DAGs), with each DAG described independently, and each step in each DAG defined in a separate file. These files can be stored and managed in a Git repository, fostering a collaborative environment with high granularity. AirFlow, through its Operators, supports the use of different technologies (Python, Java, Bash, Jinja templates, etc.), allowing collaborative parties to implement different steps while remaining interoperable with a common high-level blueprint process.
This approach allows the community to build a repository of diverse implementations of the same steps, adapting to different components, APIs, or internal data models. However, to ensure efficiency, a set of collaborative principles must be defined for organizing the repository meaningfully, making it easy for each party to identify reusable components and determine areas requiring customization. For maximum reusability with minimum customization, contributors must follow a consistent approach, breaking down work into granular logical steps.
To demonstrate the practical implementation of this approach GP4L is developing the DAGs necessary to provision services in PIONIER.
Open source¶
The implementation of workflows is based on open-source software and, although it has been configured for validation within the PIONIER network, it can be reused to manage services in other networks.
The code of workflows (Airflow DAGs) is available in a public repository maintained by the GÉANT project.
The documentation for the network data model used to define resources and services is also available in a public repository.
Video demonstration¶
The video shows the pilot implementation of network service provisioning (L2 circuit) in the PIONIER Network with the use of orchestration and Single Source of Truth component.
The following video demonstrates the implementation of a workflow to configure a network interface.
The EVPN service workflow demo:
Onboarding a new network device workflow demo:
Service validation¶
Service providers must be confident that their services operate continuously and in accordance with established configuration parameters. An automated workflow for creating and managing services reduces the risk of human error; however, even so, running services should be regularly verified to ensure their correctness. This type of verification should also be automated, particularly when the number of services is large and their complexity/sophistication is high. Service providers must have control over and full up-to-date knowledge of the state of their infrastructure. To this end, it is important to develop mechanisms for the regular verification of running services and for checking the compliance of device configurations with what is declared in the Source of Truth (SoT) component. As part of the work on network orchestration, the GP4L team has implemented a workflow that periodically (once a day; the frequency can be modified by the administrator) retrieves information from the SoT and checks whether the state of the network is fully consistent with the state defined in the SoT. The workflow has been validated in the PIONIER network and is used as a production functionality of the network service management system in PIONIER. Reports on the validation performed are delivered by the workflow as entries in the Mattermost messenger.
A person analyzing the messages presented in Mattermost receives a summary of how many services have the status OK, FAIL, or VERIFY. In addition, a detailed table is displayed with the identifiers of L2 circuit service instances and their statuses (currently, the workflow implementation is adapted only for L2 circuit services). The OK status indicates successful validation, VERIFY indicates detected discrepancies between the information in the Source of Truth and the configuration read from the devices, and FAIL indicates a missing or unrecognized result. Additionally, the values MAAT_ERROR and LSO_ERROR are possible, informing respectively about a problem related to the SoT (the Maat application is used as this component) or the GÉANT LSO application (the component that activates Ansible playbooks). In the case of the VERIFY status, the report also includes detailed information about the detected discrepancies.