Date

Attendees


ARCH WORK

ARCHITECTURE WORKWIKI LINK
ARCHITECTURE FLOWSARCHCOM: InfoFlow - RunTime Config DB Information Flow
COMPONENT DESCRIPTIONARC RunTime DB Component Description - R6 Frankfurt
PROJECT PROPOSALRunTime Config DB Project Proposal (Oct 25 2019)

R6 DISCUSSION

TOPICDISCUSSION

R6

CCSDK-based Solution

Project as part of CCSDK ( Yuriy Malakov  )

  • ACTION: Sandeep Shah Presentation of new architecture with CCSDK (Yuriy Malakov ). How much bandwidth/capacity does Sandeep Shah have.
  • ACTION: Development demo & progress (1) ORAN Yang models & data schema not available yet (waiting) & 5G Service Modeling U/C: 3GPP TS28.541/TS28.540. maps to a data structure we want to support. (2) can proceed to Dockerize solution. R4 MariaDB solution. could extend the model. (3) Review work from Ted. waiting for project.
  • ACTION: Give RC0 status - Sandeep Shah on RC0 status. Set up call with Sandeep Shah

R7 DISCUSSION

TopicDiscussion

R6 / R7

ReadtheDocs

Read the Docs

  • ACTION: Update ReadtheDocs https://git.onap.org/integration/tree/docs - Jira under Integration - invite team for review - invite PTL (Morgan R.) -Gerrit PTL submission +1 from reviewers. committer/Morgan +2 (someone in Integration project will do the Merge)
  • New project → Repo → DOC directory (RST) in that Repo Andreas Geissler  → Signoff for R6 May 2020; M0 for R7. If we are approved by TSC as a new project → create a new Repo

R7 TSC /

Project Proposal

Configuration Persistence Service Project

  • ACTION: PERFORMANCE - Open (#@#) open items to get ballpark figures for # API requests.
  • ACTION: LIFECYCLE - find out the Lifecycle State "enumerations" - is "incubation" right?
  • ACTION: TSC Step #2 - Ben sent the TSC asking for slot. TSC. M4. RC0 bumped by a week. Q1 Who will be contributors. Joanne → Catherine.
  • ACTION: Virtual Meeting - What is our deadline? April 21-23. Subcommittee meeting (LA USA). planning virtual plannig / presentations. M0 wiki: https://wiki.lfnetworking.org/display/LN/2020+April+Virtual+Technical+Event
  • ACTION: Peer Review Process Step #1 - ONAP Projects ... Ready for PEER REVIEW? What is involved in that? What's the process? submit to the TSC? Ask Kenny what is PEER REVIEW? Presentation to ARCH S/C
  • ACTION: ID PTL/Contributors - who will be contributors, who wants to be the PTL. Resources & Committers from Ericsson (Tony Finnerty), AT&T, IBM (Sandeep) commitment in R7.
  • Race Condition Simultaneous requests to update the same info - Config Controller Persona / writers update / APPC VFC SDNC / EMS does update / New yang model will change, SDNR change in network SDNR does go device gets new Yang model puts into the Database. incremental Yang model / PNF package yang model → schema (1 time activity) DB configuration - when you get a config change notification you get all the information you need parameter:newvalue. / who is the MASTER of the data? the mediator / Mirror data - Use Case / the owner controller-persona to update / database update writer

R7 Guilin

Content / requirements

Requests for R7 Requirements are up.

Guilin release - functional requirements proposed list

Timeline -  Sign-off for R6 is May 7. Historically M0 kickoff for R7 is May 7th

PROPOSALS FOR R7 GUILIN FOR WHAT WE PLAN TO BE DOING IN R7:

  1. R7 Project Proposal (identify PTL, Project proposal, setup repo)
  2. =STEP 0= (Design time), (Setup DB) Yang Model development ORAN specification Yang Model in line with 3GPP. SQL structure.
  3. =STEP 0= Schema design/setup & API
  4. =STEP 1= CMnotify generated by RanSIM extended (final standard format).
  5. =STEP 1= VES generation, Nokia Simulate DU → simulate VES CMNotify message.
  6. =STEP 1-6= CMNotify (Nokia) Integration Step 2,3,4 with SON work Step 1,5,6
  7. =STEP 5/6= Mapping CMnotify contents into DB
  8. =STEP 5a= New Development for Independent component to get VES off of DMaaP
  9. =STEP 6= API Updates
  10. =STEP 6= Interface to RTCDB (writing DB from SDN-R or RCDB-stand-alone-component)

SUMMARY OF THE STEPS FOR RTCDB "HOW IT OPERATES" (Reference):

  • STEP 0: Design time, Setup DB schema & API (Onboarding).
  • STEP 1: xNF (RAN Simulator) GENERATES a VES CMNotify - Wipro SON (R6 Done)
  • STEP 1a: Simulator of VES CMNotify/"Standardsdefined/CM" (Nokia) (R7)
  • STEP 2: DCAE VES Collector RECEIVES the CMNotify (VES) - Nokia (R7)
  • STEP 3: DCAE PROCESSES VES Event- Nokia (R7)
  • STEP 4: DCAE PUBLISHES onto DMaaP - Nokia (R7)
  • STEP 5: CCSDK (Controller) LISTENS to DMaaP - Sandeep Shah  (R6 Done) → (R7)
  • STEP 5a: RTCDB (stand-alone component) LISTENS to DMaaP (R7 new)
  • STEP 6: RTCfgDB UPDATES DB with info - Sandeep Shah / Techmahindra (R6 Done) → (R7)

A&AI FLOWS:

STEP 1...6: Initial A&AI setup of DB (the setup of the DB with the initial set of all xNFs a "getall")

STEP 1...6: A&AI Update (e.g. a new xNF is added or deleted)


R7 TopicDescription & Links

Usage of CPS -

OOF/SON/PCI (Cell info)

E2E Network Slicing (Slicing info)

Harmonization (Stnd-Def VES)

Virtual F2F mentioned the C&PS project.

Those other use cases have dependency to Use cases.

We need to attend U/C weekly meetings; sync

Guilin (R7) - Use Cases (and Requirements in Use Cases)

Guilin release - functional requirements proposed list

Interaction & Dependencies Use Case

Interaction spreadsheet

Sync between these teams.

Joint meeting - Invitee on a particular in the schedule

TSC Project Proposal

Configuration Persistence Service Project

Project Home Pagesample-landingpage Project Home Page
Project Repository

Create Repo: Resources and Repositories (Deprecated)

Process to create Repo. Ticket

Architecture S/C

Architecture Proposal

ONAP Architecture Review process:Project Architectural Review Requirements and Process (Draft) to M1 Project PTLs/Feature Sponsors request a review by email from the chair of the arch subcommittee. The chair of the arch subcommittee creates a JIRA issue for the review and emails a link to the project PTL. The project PTL/Feature Sponsor adds the JIRA issue link to the architecture review JIRA task in the M1 epic, as confirmation that a review has been requested.

R7 Wiki PageConfiguration & Persistency Service R7
R7 GuiLin Development

CMNotify specification

  • (Watch for): R6 VES 7.1.1 Baselined https://gerrit.onap.org/r/c/vnfrqts/requirements/+/100876  (VES Event Reg review) and https://gerrit.onap.org/r/c/vnfrqts/requirements/+/100867 (VES Event Listener review)
    R7 VES 7.2 review open new updates to the VES listener should include CM VES event. Participate review.
  • ACTION: R7 VES Common Header update to align with 3GPP SA5 (CR) Nokia/ ATT/ Orange/ Ericsson. Presentation for Monday 2PM UTC on Alla's Req S/C call. "ONAP-ORAN Harmonization". Vimal, Marge, Cormac, Damian. Domain "Standards-Defined" NameSpace "3GPP-CM-xxxx"


PROJECT NAME DISCUSSION

TOPICDESCRIPTION
Renaming the Project

RENAMING THE PROJECT ("Service" vs "Database")

Database

#1 HISTORICAL PRECEDENCE - The original idea was a configuration database available at Runtime. Use cases to store. Historical been with the project since the beginning. Name Inertia. Operators will use. Historical precedence within AT&T. SON & Slicing depend on this project (scope)

#2 Contents that it holds - Contents is configuration parameters from the network. Name reflects the initial content of database.

Service

Since working on project proposal, it has grown, the same argument works against use.

#1 QUALIFIERS - A wide variety of qualifiers could be put there and it still won't cover. Would move to something more abstract. Abose and beyond a standard IT database. For example service information, policy information, CLAMP information, exo-inventory (information outside of A&AI), topology information, application information - it is conceivable that many other types of information could before. Config if someone wants to add additional information a place to hold information. e.g. in Bell Canada's case they store more than just configuration, the Operational Data & Current state of network. Collectors that gather metrics in VES consumed put in stateDB. Tied to inventory objects in A&AI self-link from A&AI want to know about interface PNF trying to keep two together, the configuration & the metrics representative what is currently happening in the network. state of I/F being up-down that's more of a state vs a configuration. OpenDaylight Operational data store. Scalability. Collectors & StateDB is yang-driven if collector follows yang-model data store can hold-values. Monitoring interface track as state.

#2 Confederation of Databases - Core/Edge/Far Edge - Historical DB - current DB

#3 MEANS VS ENDS - Database is a "means" technology not an "end" goal

An engine, hubcap is a part of a automobile that provides a service: vehicular motion. A database is a specific technology and implementation.

Requirements around for current data & historical (temporal) careful not to talk about the technology. Potentially more than one database.

Data Persistency Service → "functional" / Zu Tony Ben

Configuration & Persistency Service / Joanne Tony Ben

Operational Persistency Service / Bruno Tony Ben

Run-Time Configuration DataBase → "technology"

State (of Network) Database → what is state of network (storing more than just config)

Configuration Operations Database (C.Op.DB) / Swami

Golden Configuration Database / Fred

(RunTime)(Operational)(Persistency) Policy Topology State Network Configuration Service Exo-Inventory Database

SUPPORTING FILES

DescriptionFile




RECORDING

RecordingFile
Zoom

zoom_0.mp4

Audio Only

audio_only.m4a

Chat

playback.m3u

Action items

  •  



2 Comments

  1. Michela Bevilacqua

    HI, 

    About Interaction & Dependencies Use Case point for Rel 7, we should split more clearly the implementation effort that will be progress in relation to a specific ONAP Rel 7 requirement. Any other requeriment can refer to external implementation defining the external requirement as a depedency.

    In the context of ConfigDB,. today we have 3 requirements overlapping around CM notification and ConfigDB:

    1) Mobility Harmonization: CM notification

    2) ConfigDB

    3) SON.

    A proposed way forward is

    • CM notification implementation in ONAP will be part of req 1). 
    • SON requirement will refer to req 1) and 2)  as dependencies.

    Can we discuss and agree a possible way forward as this one with the different key contacts for the 3 requirements above ? 


    1. Benjamin Cheung

      Michela,


         This is really good thanks! We will incorporate this! Let's make this an agenda item in the next meeting Friday May 1


      -Ben