1. Open Network Automation Platform (ONAP) Controller Architecture Proposal
DRAFT

2. Where we agree Common use of the ONAP architecture framework
Common view of service orchestrator
Follow common set of VNF Guidelines and packaging
Combined from OPEN-O and Open ECOMP
Data model
Present the same view/requirements to outside world regardless of which path is selected
Common mediation layer -> OpenStack, VMWare, cloud, etc.

3. Areas of disagreement Different operators have different requirements
Workflows for controlling VNFs may take different paths based on operator requirements
(runtime instantiation)
ETSI MANO
VNFM functionality
VNF characteristics (e.g., complex vs. simple)
Network/operating region characteristics
Need flexibility to meet operator requirements

4. ONAP Controller Proposal
Pros:
Flexible
APIs already exists
Easier initial integration
Cons:
May need 2x feature development
Functional overlap
Service Orchestrator
APP-C
Policy
A&AI
VF-C
VNFs
DCAE