The table bellow describes the problem and how it is or isn’t addressed today
Scenario | External system to be provisioned | Baseline approach | Reflections | Have interface interact with ESR | Project PTL |
|---|---|---|---|---|---|
Connection to cloud infra | Address and capabilities of VIM managers (e.g. openstack port) | Mult-VIM: will register/unregister VIM with ESR. | Yes | ||
| VID: manually input the VIM addresses and connection information to the portal, and sent this info to MSO which later call controllers which interact with all of these systems (VNFMS , VIM , EMS) | No | ||||
| VF-C: query VIM from ESR. | Yes | ||||
| SO: will not interact with external system directly | No | ||||
Connection to transport | SDN controller address’s and capabilities | vendor sdn controler which managed by VIM is not in the scope of ESR. How about the vendor sdn controller managed by ONAP SDN-C? There is a request about API used to verify that platform is available from SDN-C release plan. ONAP SDN-C: ? | no response | ||
Connecting to S-VNFM | S-VNFM and capabilites | VF-C: manage VNFM addresses from ESR | Could be part of the tosca/heat template | Yes | |
EMS (Element Management System) | EMS address and capabilities | APP-C: will not interact with external system directly. Interfaces with other ONAP Components: AAI, Policy,, MSO, DCAE etc. | No | ||
| Other | DCAE: DCAE will not collect the data from external system | No | Lusheng Ji |
...
ESR will supplies both portal and API to manage(register/query/delete/update) the external system, but will not deploy the external system. (Here external system means that the systems already exsist somewhere, but not included in ONAP, such as VIM/VNFM/EMS/vendor SDN controller)
ESR will check whether the external systems are reachable, but will not do the fault analysis.
...