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

2. 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.

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

4. …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

5. vFW use case - demonstration of the complexity

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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.

13. 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

14. 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

15. 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

16. THANK YOU;-)