USE CASE REALIZATION MEETING (Notes 2018-11-21) Netconf

Date

Nov 21, 2018

Attendees

  • @Benjamin Cheung

  • @Oskar Malm

  • @Arun Gupta

  • @Xiang Li[CMCC]

  • @Lukasz Rajewski

  • @Ulas Kozat

  • @Gerard Hynes

  • @wangyaoguang

  • @Floyd Goldstein

  • @N.K. Shankaranarayanan

  • @LR

  • @Kevin McDonnell

  • @Rebecca Lantz

  • @Szabolcs Hutvagner

  • @Albino Pinho

  • @Timo Perala

  • @Manoop Talasila

  • @Peter Loane

  • @Zu Qiang

  • @Gerard Kelly

Goals

Discussion items

Time

Item

Who

Notes

Time

Item

Who

Notes

10 Min

Overview of PNF Plug and Play

@Benjamin Cheung

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 min

Carry over items for Plug and Play Evolution

@Oskar 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 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;



5G Model & PNF Onboarding

@Chesla Wechsler , @Gil Bullard, @Andy Mayer

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



Inventory Syncing

@fred feisullin

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

SUPPORTING DOCUMENTS

DOCUMENT

FILE

PRESENTER

DOCUMENT

FILE

PRESENTER

NetConf in PnP Service Configuration

WIKI

5G - Configuration with NETCONF

@Oskar Malm

NetConf Presentation



@Oskar Malm

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

(see Nov 28, Use Case Realization)

USE CASE REALIZATION MEETING (Notes 2018-11-28) Inventory Mgmt

@fred feisullin

Action items