E2E Process Automation Alexis, Andreas, Bin, Catherine, Franck, Scott, Susana, Timo TSC-53 December, 18 2018

ONAP Objectives: extract from Architecture white-paper The ONAP platform allows end user organizations and their network/cloud providers to collaboratively instantiate network elements and services in a dynamic, closed control loop process, with real-time response to actionable events. In order to design, engineer, plan, bill and assure these dynamic services, there are three major requirements: A robust design framework that allows specification of the service in all aspects – modeling the resources and relationships that make up the service, specifying the policy rules that guide the service behavior, specifying the applications, analytics and closed control loop events needed for the elastic management of the service. An orchestration and control framework (Service Orchestrator and Controllers) that is recipe/policy-driven to provide automated instantiation of the service when needed and managing service demands in an elastic manner. An analytic framework that closely monitors the service behavior during the service lifecycle based on the specified design, analytics and policies to enable response as required from the control framework, to deal with situations ranging from those that require healing to those that require scaling of the resources to elastically adjust to demand variations.

Statement: a powerful set of framework… A large number of frameworks A huge footprint A large number of BPMN A large number of DG

…difficult to use Hard to use Lack of UI for A large number of requests / systems to deploy & configure for a simple service Robot, VID, Postman, SDC, CDS, CLAMP, HOLMES, POLICY etc… Poor functionality documentation / tutorial Lack of UI for Geographical location  management Subscriber management Cloud Region management  (Partially done by ESR GUI Portal) De-centralized design time and not well understood Topology Configuration Close loop Hard-coded values/workflow for use-cases Duck tape to make use case work; not re-usable Difficult to follow the process to create a new use case Can’t perform NETCONF push based on design activities But, we have a great community, great tools We are on road to simplify usage, but we must focus on

vFW use case - demonstration of the complexity https://wiki.onap.org/display/DW/Vetted+vFirewall+Demo+-+Full+draft+how-to+for+F2F+and+ReadTheDocs

The strech goal When What How Design-Time I onboard VNF I model services, configuration, rules Onboard Full VNF Package in a single tool Design service and LCM Preparation-Time Preparation-Time I prepare all data for instantiation phase Some tooling to help building the request Eliminate all requests that can be automated Preparation-Time OpenStack parameter checking (eg image name, flavor name…) List of parameters to fill => pre-JSON payload to be populated Run-Time I deploy in one call A single (complex) request to deploy&configure&test a service

ONAP Amsterdam/Beijing: A La Carte deployment Onboard VNF Package Define VNF Define Service Declare service/subscriber Declare tenant Declare Service Declare VNF Value VNF Parameters Deploy VNF Update A&AI Mount VNF Configure VNF preload heatbridge for each VNF

ONAP Casablanca: Macro deployment Onboard VNF Package Define VNF Define Service Define Blueprint CDS Declare tenant Create Service Mount VNF Configure VNF Declare VNF Deploy Update A&AI Service for each VNF for each VNF

Orchestration Status Changes for Casablanca Casablanca Orchestration Status Activate Shell object created in A&AI ChangeModel ChangeModel Assign Create Activate Inventoried Assigned Created Active Delete Deactivate Unassign (Delete in A&AI) Deactivate Inventoried Service/resource shell object created in A&AI Assigned Service/resource parameters allocated by SDN Controller Created The resource has been created (spun-up) in the Cloud infrastructures Active The service/resource is in active/operational state in the SDN Controller

Dublin Objectives Eliminate all hard-coded for use-case All specific code for use-cases should be extracted from the components No code change to support use case No BPMN creation for new service Consolidate parameters definition and post-instantiation configuration CDS, CCSDK, APPC, SDNC, VFC A single request to deploy & configure (complex) service Configure BuildingBlocks in SO Enhance documentation Provide tutorial, How-To guide

Dublin Objectives for deployment phase Onboard VNF Package Define VNF Define Service Define Blueprint Preparation Time Values Models A single request UI to configure (subscribers, clouds, …) Tooling to fill complex payload Create Service Mount VNF Configure Declare Deploy Update A&AI Service Test VNF Test Service Post-instantiation

Dublin Proposed Orchestration Status State Diagram Audit Checks, Cloud Update, Change Model, Preview & Change of Configuration Assignments Audit Check, Configuration Modify, Configuration Backup/Restore,Preview & Change of Configuration Assignments Preview & Change of Cloud & Configuration Assignments Ops Ops Ops Ops Create Ops Configure Assign Create Base, Incremental Activate Unassign Assigned Delete Created Reset/Rollback Configured Deactivate Active (Applies to VNF, VF-Module and VNFC/VM resource types) Terminate (Applies to VNF, VF-Module and VNFC/VM resource types) Two operations teams – check before creation, before configuration. Notes: State transitions from one state to another when the operation/action, e.g. configure, is successful. State transitions should not constrain the workflow, supporting multiple pauses / manual handling steps and multiple Ops teams. Pre-view and change of cloud and/or configuration assignments will require platform enhancements: visibility improvements, manual handling improvements, other. Any Contrail and other logic executed today by the SDN Controller during ‘activate’ action will have to be separated out (impact). Need to finalize all operations in above diagram, e.g. e2e create/terminate, including LCM operations. Need to capture state transitions for all resource types.

Dublin Objectives Enhance the SO Generic building block and Controller Design Studio (CDS) implementation in Casablanca release to support post instantiation. Enhance state transition to support entire lifecycle: instantiation and post- instantiation/configuration Identify/streamline operations exposed by SO to external clients Applicable to VNFs L1-L7 and PNFs Enabler for TOSCA model-driven orchestration Drive Framework and model reuse regardless of use case

Dublin Objectives to be discussed Have all design activities integrated within SDC Enhance analytic application support Migrate existing use case to new platform feature Deprecate former BPMN, move to model-driven configuration

Impacts on components for Dublin SDC Define specific service data CDS integration CCDSK, VFC? Post-instantiation support in CDS VNF configuration data SO Support configuration action Integration, UUI, A&AI ? Dedicated tool to populate data (eliminate Robot, REST API calls usage for end-users) Documentation Explain the various steps with simple examples

THANK YOU;-)