...
| Topic | Discussion | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Calendar Entry | Calendar now open for editing ... but how? | ||||||||
R6 CCSDK-based Solution | Project as part of CCSDK ( Yuriy Malakov )
| ||||||||
| R6 Frankfurt | In release requirements page: M4 March 5, 2020 Frankfurt Release Requirements (TSC has already approved Green status for U/C). CCSDK, SDN-C - Dan Timoney MVP (min viab. product) discussed on SDN-C call. Req not totally clear, schema model. Take what is in ConfigDB; finalize the Data Model approach.
| ||||||||
R7 Project Proposal | RunTime Config DB Project Proposal (Oct 25 2019) Project Proposal work to be done during R6. Project Proposal for R7. Presentation at Arch S/C and TSC during R6.
| ||||||||
R7 Separate Component |
Email from Dan Timoney My understanding from Sandeep was that this work was very much a stretch for Frankfurt. So, I’m okay with work starting in Frankfurt, as long as its structured so that it’s a separable component (i.e. as long as, if it’s not completed in Frankfurt, the platform is not fundamentally broken). I would NOT support creating a separate repository, since there is a fair amount of overhead involved in maintaining each repository on an ongoing basis – both machine and human resources. The Linux Foundation itself has been pushing back on the number of repositories the ONAP projects have and there is now a new approval process needed in order to add new ones. If a new repository is needed, then this team will need to convince me why no existing repository can be used AND will need to provide a resource who is willing to maintain that repository (i.e dealing with security vulnerabilities; policing code coverage ; doing release builds, etc). | ||||||||
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
| ||||||||
| Renaming the Project | RENAMING THE PROJECT ("Service" vs "Database") Database The original idea was a configuration database available at Runtime. Use cases to store. Historical been with the project since the beginning. Service Since working on project proposal, it has grown, the same argument works against use. 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. 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" Data Layer Service RunTime Configuration DataBase → "technology" State (of Network) Database Configuration Operations Database (C.Op.DB) / Swami Golden Configuration Database / Fred Policy Topology Configuration RunTime Service Exo-Inventory Database | ||||||||
| R7 Proposal | R7 GUILIN PROPOSAL Executive Summary - The Run-Time Configuration Database (or possibly / Data Persistency Service / we are discussing the final project name) will be continued from the R6 Frankfurt work. This The R7 GuiLin work will include: software enhancements to the RAN simulator, ; improvements to the schema design , and handling; integration with CM Notify new R7 CMNotify DCAE development, ; and API updates into the database. The project will ALSO kick off the work needed to create make this project a stand-alone components / projectONAP component in parallel. This work will entail nominating a PTL, Setting ; setting up a software repository, and transitioning the existing R6 database software into the new repository. Business Impact - The ability to configure a RAN network (CU/DU) PNF and VNF with ONAP is a critical business function because configuration management is a core LCM/OAM operation. The project has been presented at the TSC and Architecture sub-committees, with acknowledge business impacts to enhance the operation of data-handling within ONAP to improve and augment LCM operations. Business Markets - This project applies to any domain (wireless, transport, optical, and wireline) that ONAP may manage. It is not a market or geographical specific capability. It is expected the that scaled ONAP installations such as Edge ONAP deployments will also deploy the database across these installations. Funding/Financial Impacts - This use case project represents a large potential OPEX savings for operators because of the ability to configure networks saving time and expenses. Organization Mgmt, Sales Strategies - There is no additional organizational management or sales strategies for this use case outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | ||||||||
SUPPORTING FILES
| Description | File |
|---|---|
...