USE CASE REALIZATION MEETING (Notes Nov 21, 2018)

Overview of Plug and Play Use Case:

5G - PNF Plug and Play

Dublin Plug and Play Enhancements:

Link to presentation:

5G_UC_for_Dublin_NETCONF_Nov_22.pptx

Discussion of Evolution of Plug and Play Use Case with Step 35 to 37. SO to SDN-C interaction (API calls). and Support from SDN-C (Controller) to PNF with NETCONF Support (in addition to Ansible).

QUESTION: Is TLS supported today in ONAP? ANSWER: Yes, TLS is used in DCAE for VES (not mutual TLS until Dublin), HV-VES over TLS and FTP over TLS for bulk PM.

ACTION ITEM: SDN-C (Dan Timoney) would need to make the "assign" function the API & have the PNF as "first class citizen". GR APIs are structured in a way which has an API per resource type (e.g. service-topology-operation (service level), vnf-topology-operation (VNF level)) need NEW PNF topology operation (within that new API would have assign action). Look at corresponding API for VNF adapt it for PNF in SDN-C.

ACTION ITEM: Configure function (APP-C/SDN-C) lack of official support for PNF. Needs to be developed. Configure API today defined in LCM API. Update: In the meeting stated that GR API also defines configure action, this is not correct.

ACTION ITEM: For configuration with NETCONF over TLS the NETCONF client implementation must be selected. Currently looking at ODL built-in client. A service logic plugin is also needed to access the NETCONF client from directed graphs. Branch on the API dispatcher support for DG connected to the PNF/VNF type; other option is shared DG within that graph you have a selection. This assumed you have a way to configure the controller w/ the necessary data. This process is called "Self-Service"; a user of ONAP can install template/blueprints into the controller & then associated w/ the PNF/VNF type the controller does a look-up: Ansible or NETCONF etc. Blueprint can also be per service type in the future.

QUESTION: What does VENDOR need to provide? does it need to provide the DG? ANSWER: In some cases can be possible to have generic DG, but flexibility with custom DG can be useful in some scenarios.

QUESTION: Isn't the API associated 1:1 w/ the DG? ANSWER: Depends on API and controller. The LCM API in SDN-C/CCSDK doesn't have dynamic selection of DG today, "basic" dispatcher. Always looks for DG w/ a certain name based on operation to perform. If you look in APP-C the Dispatcher is more advanced you can do a resolution as part of the dispatching step select a certain DG based on the VNF type.

QUESTION: Will all actions use the same protocol per NF? ANSWER: Should be per operation. NF will support one or several protocols per operation. Operator could make decision at design time (New Design studio), if there is a preference communicating w/ PNF w/ a particular protocol when creating the artifacts.

NF to Controller Association - SO how does it know which controller (NF - to - controller association). Controller internal flags to decide on a protocol per target;