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 - How does SO know which controller to use (NF - to - controller association).

QUESTION: What component (SO-Controller) interwork pattern should be used ? Couldn't SO be decoupled from knowing controller capabilities. If SO made asynchronous call via DMAAP message bus, controller instance could take messages based on controller API call type and target PNF that it knows it has the capabilities to fulfill.

Controller internal flags to decide on a protocol per target;