- Toine Siebelink
- Tony Finnerty
- Zu Qiang (Ericsson)
- Joanne Liu Rudel
- Michela Bevilacqua
- Theodore Johnson
|ARCHITECTURE WORK||WIKI LINK|
|ARCHITECTURE FLOWS||ARCHCOM: InfoFlow - RunTime Config DB Information Flow|
|COMPONENT DESCRIPTION||ARC RunTime DB Component Description - R6 Frankfurt|
|PROJECT PROPOSAL||RunTime Config DB Project Proposal (Oct 25 2019)|
Project as part of CCSDK ( Yuriy Malakov )
R6 / R7
Read the Docs
R7 TSC /
Content / requirements
Requests for R7 Requirements are up.
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:
SUMMARY OF THE STEPS FOR RTCDB "HOW IT OPERATES" (Reference):
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 GuiLin Development|
PROJECT NAME DISCUSSION
|Renaming the Project|
RENAMING THE PROJECT ("Service" vs "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.
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