Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

TimeItemWhoNotes
10 MinOverview of PNF Plug and Play

Overview of Plug and Play Use Case:

5G - PNF Plug and Play

Dublin Plug and Play Enhancements:

5G - PNF Plug and Play (Casablanca carry-over items)
30 minCarry over items for Plug and Play EvolutionOskar Malm

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 NETCONF Support (in addition to Ansible).

QUESTION: Is TLS supported today in ONAP? ANSWER: User name & Password, then TLS support; additionally other Functions such as VES events for High volume open a secure connection w/ ONAPYes, 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". API GR APIs are structured in a way which has a an API per resource type (e.g. service-topology-operation /(service level), VNF operationvnf-topology-operation (VNF level)) need NEW PNF topology operation (within that new API would have a APIassign 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. 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 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 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 This assumed you have a way to configure the controller w/ the necessary data. this This process is called "Self-Service"; a User user of ONAP can install template/blue prints blueprints into the controller & then associated w/ the PNF/VNF type and then the controller does a look-up; performance on an instance, which should I do? A Ansible/NetConf: 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 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: Different Actions for Different Interfaces. For any particular I/F it will support the full suite. ANSWER: should Will all actions use the same protocol per NF? 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-timeNF 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;


5G Model & PNF Onboarding[NEXT WEEK] Discussion of 5G Platform (Internal) Information & Data Model and mapping from ETSI SOL 001 to the Platform Info/Data Models.

Inventory SyncingFred FeisullinSyncing of A&AI overhead policy when VNF pushes inventory (state changes) polling for the Delta

...