How to deal with hardcoded E2E NW Slicing model, spike
Discusdons started with E2E NW Slicing Team, to be continued next week
2
Which Simulator to use? NetConf Simulator Netopeer v2
Nokia
Ericsson
Honeycomb(?)
Rahul Tyagi Ericsson more lightweight, more experience. Available CSIT standard setup
Swaminathan Seetharaman mentione 'Honeycomb' simulator they used before. Need to investigate if it supports get-schema method over RESTConf/NetConf
Need to check if we can use it with E2E NW Slicing model
3
Should (ONAP) dmi-instance be as separate (springboot) application Could be part of DMI Manager
DMI-Instance interface should be an open standard
Tony Finnerty and Team to allow easy integration of future 3rd part DMI-Plugin instances a separate application with its own REST Interface is required
This scenario will demonstrate configuration management using NCMP.
...
DMI Registry
DMI Plugin (instances) e.g. ONAP DMI-Plugin
Component Impacts; Suggested User Stories
#
Project/Component
Description
Suggested Stories
Comments
1
CPS/NCMP
create rest interface on northbound for GET/POST/PUT/DELETE to access yang data. Note. Currently driven by "E2E Network Slicing" Use Case mix of CPS-CORE and NCMP Interface
Ensure all (CPS-Core) Read operations are mirrored
Remove/migrate? 'hardcoded generic models used in H release"
Spike API for Update and Delete Operations
consider 'bypass' option
interfaces for yang data are: operational, intended, pass-through (selection can be done by enum)
check with netconf-sim if current nw slicing yang model can be imported including its imports.
2
CPS/NCMP/DMI-Registry
Create dmi-registry. Data Model Inventory Interface (DMI)
'Internal service' no public Java or REST API
responsibilities are
Store & retrieve cm-handle/dmi-since mapping in yang modelled CPS data table.
include additional data (key-value pars as provided by dmi-Plugin)
Dmi manager is to select the dmi instance at runtime for cm handle for a northbound (write) request
create new module for dmi-registry
create yang-model (ncmp-dmi-registry) in cps repository for cm-handle->dmi-pluginmapping. To store relations between cm-handle (anchor) and dmi-plugin (instances)
Create anchor with model from step 2 in new (ncmp-admin) dataspace?! (once upon deployment)
create API to
create new dmi-plugin entry during registration
create API to
Register cm-handle->dmi-plugin entry when new cm-handle
Get dmi-plugin for given cm-handle
Delete cm-handle->dmi-plugin registration
Delete dmi-plugin ? TBC
separate stories for data and model.
3
CPS/NCMP/DMI-Plugin
Common standard (REST and Java?) interface for extensibility
create dmi pluginfor onap. For production its responsibility of admin to provide instance of dmi.
At first, on A&AI change event over DMaap, create mapping for cm-handle and dmi instance and sync yang model and data.
Filter (register) only yang modelled xnf instances's cm-handle, based on event header information of Node
dmi plugin instance (onap-dmi) have sdnc connector to access sdnc.
call get/post/put/delete towards restconf interface (forward northbound write requests)
Defined and Agree common (java?) Interface
create module dmi-onap-plugin Rest and Impl modules
create sub-module dmi-notification-handler
create sub-module dmi-adapters
create sub-module dmi-rest and dmi-plugin
create infra for separate spring boot application and docker image for dmi-plugin
extract dmi-plugin into separate container consensus on rest interface is needed.