...
| Requirement | Operator Near-term (2019) vs Long-term (Beyond 2019) | Operator feedback Consolidation | Comments |
|---|---|---|---|
1.Consolidated view of deployed management component micro-services (in Central and other locations such as Edge) and their relationship for central Orchestrator | AT&T - near-term Bell Canada - long-term Orange - long-term Swisscom - near-term TIM - near-term Verizon- near-term Vodafone - near-term | Near-term | |
2.For a given application configuration management mechanism is the same independent of location (Central and Edge), including dynamic configuration support | AT&T - near-term Bell Canada - long-term Orange - long-term Swisscom - near-term TIM - near-term Verizon- long-term Vodafone - long-term | Long-term | Clarification (added 4/11): The requirement indicates configuration management at both central and edge should be consistent. Having different mechanism to handle this at different site will be operational issue. |
| 3. In relation to No. 2, retain the capability to integrate with Central ONAP Policy and DMaap BusController (for secure topic/feed) | AT&T - near-term Bell Canada - long-term Orange - long-term Swisscom - near-term TIM - near-term Verizon - long-term Vodafone - long-term | Long-term | Clarification (added 4/11): This is relevant to #6 and should be treated under same priority. This is also existing capability in ONAP and will be required for Day0 in the target architecture for backward compatibility to existing components (DCAE, Policy) |
4.Retain the ability to support TOSCA artifacts distributed from SDC and CLAMP. | AT&T - near-term Bell Canada - long-term Orange - long-term Swisscom - near-term TIM - near-term Verizon - long-term Vodafone - long-term | Long-term | Clarification (added 4/11): This is relevant to #5 and should be treated under same priority. This is also existing capability in ONAP and will be required for Day0 in the target architecture for backward compatibility to existing components (DCAE, SDC, Policy, CLAMP). It is not mandatory to follow existing workflow. With regard to TOSCA support, the relevant standard is ETSI SOL 001. |
5.Design flow integration (SDC, DCAE-DS) and Standardized configuration modelling support by Central Orchestrator | AT&T - near-term Bell Canada - near-term Orange - near-term Swisscom - near-term TIM - near-term Verizon - near-term Vodafone - near-term | Near-term | Applicable only to management applications (Analytics, 3rd party etc.) which are on boarded after the basic ONAP components are up and running. |
6.Dynamic Control Loop flow deployment and support through CLAMP/Policy Integration by Central Orchestrator | AT&T - near-term Bell Canada - long-term Orange - near-term Swisscom - long-term TIM - near-term Verizon - long-term Vodafone - near-term | Near-term vs Long-term tie | Applicable only to management applications (Analytics, 3rd party etc.) which are on boarded after the basic ONAP components are up and running. Additional Clarification – If the application is using ONAP Control Loop flow, then it shall follow the approach suggested by CLAMP framework. |
7.Multi-tenant infrastructure management - Install relevant K8S clusters if they are not already present. | AT&T - near-term (for both a and b) Bell Canada - N/A - not an ONAP accountability. Orange - NO. No the ONAP purposes according to us. Swisscom - not in ONAP scope TIM - near-term Verizon - near-term Vodafone - near-term | Tie - 3 4 near-term, 3 No | Clarification – This also includes installation of other relevant VIMs (OpenStack etc.) besides K8S if needed. Can use open source K8S cluster API effort (https://github.com/kubernetes-sigs/cluster-api) as applicable to bring up K8S clusters on various Clouds (Amazon, Azure, OpenStack, VMware etc.) |
8. Support for non-K8S based workload deployment | AT&T - near-term Bell Canada - long-term Orange - long-term Swisscom - long-term TIM - near-term Verizon - near-term Vodafone - long-term | Long-term | Clarification – This is the ability for ONAP to deploy applications across heterogeneous env (k8s, openstack etc) |
...