...
Scenario | External system to be provisioned | Baseline approach | Reflections | Have Interface Interact With ESR | Project PTL | Feedback From | |
|---|---|---|---|---|---|---|---|
Connection to cloud infra | Address and capabilities of VIM managers (e.g. openstack port) | Mult-VIM: will register/unregister VIM with ESR, the register VIM from ESR portal and need the health check function of VIM. | 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 | Avi from amdocs (avi.chapnic@amdocs.com) | |||||
| VF-C: get the VIM addresses from ESR. | Yes | ||||||
| SO: will not interact with VIM directly | No | jin xin | |||||
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: ? | ONAP SDN-C: For SDN-C, we are considering use of ESR for managing credentials with external SDN controllers as a "stretch goal" for release 1. Ultimately we do see a benefit to using ESR, but if we find that we cannot do so in release 1 without jeopardizing our dates, then we would just use local properties files for release 1 (as we did in our seed code) and integrate with ESR in a later release. | Yes | 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 EMS directly. Only have interfaces with other ONAP Components: AAI, Policy,SDC, MSO, DCAE etc. | No | Catherine Lefevre | |||
| VF-C: manage EMS addresses from ESR | Yes | ||||||
| Other | DCAE: DCAE will not collect the data from external system? | Lusheng Ji |
...