...
TOPIC | DESCRIPTION |
---|---|
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 |
RECORDING
Date | Zoom Recording | Audio Only | |
---|---|---|---|
| |||
| |||
|
TSC Answers | |||
| PoC | ||
| |||
| |||
ATTENDEES WEEKLY ROSTER
Date | Attendees | Topic |
---|---|---|
| TSC Answer Discussion Architecture S/C presentations | |
| Benjamin Cheung Bruno Sakoto Toine Siebelink Samuli Silvius Swaminathan Seetharaman Joanne Liu Rudel Tony Finnerty Mike Elliott Theodore Johnson Marcin Krasowski Timo Puha Andy Mayer Vimal Begwani Bob Papa Ciaran Johnston Zu Qiang (Ericsson) Michela Bevilacqua Shankar N.K. Junfeng Wang Oskar Malm Marc-Alexandre Choquette Chuyi Guo | Bell Canada & State Management 5G Service Modeling & C&PS - TSC Answers/Response Michela - introduction of Cell Model Continue Cell discussion at |
| TSC Answers discussion Amar Kapadia in ONAP R6 Solution Brief | |
| Benjamin Cheung Toine Siebelink Tony Finnerty Oskar Malm Ciaran Johnston Zu Qiang (Ericsson) Fred Feisullin Michela Bevilacqua Bruno Sakoto Theordore Johnson Mike Elliott Joanne Liu Rudel Marc-Alexandre Choquette Samuli Silvius N.K. Shankar Junfeng Wang Claudio David Gasparini | |
| Benjamin Cheung | |
| Benjamin Cheung | |
TBD | (TBD) | R6/R7 Demo of C&PS (the week of TSC) what was done (Ted J.), Deep Dive on Proposal; API I/F. |
Joint Discussion with Harmonization Team | ||
Joint Discussion with Network Slicing Team | ||
Joint Discussion with OOF/SON/PCI team | ||
...