Name

ODL SAF (Service Automation Framework), as in “OpenDaylight Service Automation Framework”

Repo Name

odlsaf

Description

SAF is a service automation framework built to extend the capabilities of OpenDaylight to help Service Providers and Enterprises automate service provisioning and monitoring. With complete life cycle management for service definitions, services can be provisioned using YANG and then translated and mapped to individual devices via any southbound interface.

SAF is integrated with Camunda workflow engine and leverages the industry-recognized BPMN.  The BPMN patterns that are relevant to service automation have been identified and implemented. This additionally provides asynchronous transaction queuing functionality (& history) not available currently in ODL itself.

SAF is integrated with OpenDaylight Plastic to provide the seamless capability to translate config from vendor-specific to a neutral, common way of managing device config.

To provide better control and provisioning of any network functions (PNF/VNF/CNF), SAF has the transaction management capabilities listed below:

   - pre-config

   - post-config

   - rollback

   - cancel

SAF is fully compatible with OpenConfig YANG models. 

SAF is integrated with Napalm and ntc-rosetta to provide the ability to manage multi-vendor devices seamlessly via CLI-YANG. 

SAF is based on Microservice architecture and deployment is based on K8S.

Scope

This would be an OpenDaylight Self managed Project.

The scope of the proposal is to open source all of the SAF components and the integration layers between Camunda, NAPALM and ntc-rosetta.

This includes the following : 

  • WFE API that has the capability to create Workflow and associate with devices
  • Predefined Java and Python Camunda delegates/scripts for transaction management
  • APIs to leverage ODL Plastic
  • Governance for Service discovery 
  • DeviceDB for inventory management
  • OpenConfig YANG models and mapping functions

Resources Committed (developers committed to working)

Initial Committers

Vendor Neutral

License is compatible (Eclipse Public License - v 1.0)

Meets Board Policy (including IPR)

4 Comments

  1. Abhijit Kumbhare

    The name sounds too much like OpenSAF (https://en.wikipedia.org/wiki/OpenSAF). Maybe Service Automation Architecture or System? Or Framework for Service Automation?

    1. Jeff Hartley

      We're certainly open to suggestions; keep them coming!

  2. Olivier Dugeon

    The proposal sounds very good, and I have just some questions:

    • You mention Camunda/BPMN as interface to SAF. Do you take into account the work already done within ONAP? In other terms, is SAF could replace the DigiGraph provided by ONAP SDN-C component and make interface between the Service Orchestrator (Camunda) and the SDN-C (OpenDaylight)? Or it is a new way to integrate OpenDaylight within ONAP?
    • Some OpenDaylight projects (e.g. BGPCEP) already implement OpenConfig. How SAF will articulate with these projects?
    • For SP, many use cases require a network inventory for the Service Orchestration. Is SAF will provide such inventory database?
    • Do you plan to incorporate some persistency in SAF? I mean to push configuration back after a reboot for example

    1. Jeff Hartley

      1. This was designed to be deployed without requiring ONAP or any other framework, however it can certainly be used alongside SDN-C projects however folks see fit.  In other words, this project is quite successful deployed standalone AND ~integrated with other such frameworks, even CRMs.   The "vision pitch" is simply to complete some use-case gaps in ODL, yet that does not exclude it from a multitude of other uses.
      2. YMMV – there is not any hard binding to any particular set of yang models, either standard or invented.  OpenConfig is simply one of the more popular sets that early adopters have used.   Also note that the explicit RestConf paths will differ significantly between existing projects (such as BGPCEP) and this.
      3. There is a "DeviceDB" that is best thought of as "extended mount information" rather than "The Big Inventory."  It contains just enough information to accommodate multi-vendor, multi-SBI, multi-translated use-cases  (such as "vendor A via netconf, vendor B via CLI, and vendor C via API, each with Plastic translations and their own SBIs).  I.e., unique identifiers passed as inputs into Plastic and/or specific mounting systems.  But it should not be thought of as a comprehensive ConfigDB nor CRM-style inventory of HW/ports/licenses/etc.  That's outside the scope of this project, and most sites already have their own unique "Big Inventory" system(s) already.
      4. TBD – outside the current scope (see previous answer/same), but in deployments this is always an important question.  At some point it might make sense to find a small/fast/light/generic project, or create one, in the open-source arena.  Again, many folks have this in-place already, but just want to get away from their proprietary systems toward open-source.