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:

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? ANSWER: User name & Password, then TLS support; additionally other Functions such as VES events for High volume open a secure connection w/ ONAP.

ACTION ITEM: SDN-C (Dan Timoney) would need to make the "assign" function the API & have the PNF as "first class citizen". API are structured in a way which has a API per resource type (e.g. service topology operation/service level, VNF operation) need NEW PNF topology operation (within that new API would have a API). 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. Generic Resource API. Configure function is not fully supported in the controller and it doesn't have PNF support. LCM Configure is likely to be TRANSPORT; Run-time "full" Configure, configures the Application.

ACTION ITEM: SDN-C is new plug-in needed or could Open Day Light client be called. SO will make to API based on type of VNF/PNF proper protocol would be selected. 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/blue prints into the controller & then associated w/ the PNF/VNF type and then controller does a look-up; performance on an instance, which should I do? A Ansible/NetConf.

QUESTION: What does VENDOR need to provide? does it need to provide the DG?

QUESTION: Isn't the API associated 1:1 w/ the DG? Depends on API. the LCM API in SDN-C doesn't have dynamic selection of DG, "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: Different Actions for Different Interfaces. For any particular I/F it will support the full suite. ANSWER: should be per operation. When you have a NF model for each operation, you specify the list of I/F. .e.g. for upgrade/configuration don't just need to pick NetConf or Anisible (could be both). DG artifact and then Associate a particular operation with a particular DG. Flexibility. New Design studio towards the controller where modeled data could be made available to the controller to know which protocol to use, the advancement is a particular vendor may support a single operation using more than one protocol. Decision could be made at operator run-time, 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;