- In order to catch up with the schedule of release 1, developers need to align the detailed information about APIs and data model inside project and cross projects, such as interaction sequence, interface parameters, and the structure of service template.
- Reduce the risk of misunderstanding and rework.
- Make sure we can accomplish M3 API& Model Freeze - this date is Aug 11, 2016 before the meeting, and it has been changed to Sept 1, 2016 later according to the latest OPEN-O Sun Release Plan.
OPENO Userstory Residential
Please refer to the URL [[GSOAPI_Documentation]]
- NS template adds the outputs field to indicate the outputs of the NS. NFVO and SDNO return the outputs field in the Query NS SBI's response.The Service Designer supports the outputs field.The Catalog supports the outputs fields parse and query.
- The structure of request or response in the SDNO NBI is the same as the NFVO NBI
OPEN-O GSO NSD Specification
Common LCM Micro Service
To add a micro Service ,named LCM Common ,provided the NBI for GUI invoke,and invoke the GSO NFVO SDNO's NBI.HUAWEI and ZTE develop the service together.
Assignment of GUI
firstname.lastname@example.org email@example.com firstname.lastname@example.org
- GSO needs to complete the node type definition before Aug 18
- GSO NFVO SDNO need to instantiation base on the OPENO use case before Aug 20
- HLD LLD of GUI and discuss Assignment with ZTE
- HLD LLD of Common LCM Micro Service and discuss Assignment with ZTE
NS&VNF CSAR Model Specification
NSD TOSCA Specification
NSLCM API Specification
Align L2VPN & L3VPN adapter interfaces
We have gone through L2VPN & L3VPN sbi adapter interfaces with newest interfaces, and make all details clear save for 6 issues list below:
1. network-side static router not found in api?
2. what's the actual meaning of besteffort/sharing?
3. what's the difference between mplstepolicy in top level and mpletepolicy in ParticularConstraint, how to use it?
4. how to express underlay id in API, e.g. PW id in controller.
5. for non-protect how to express? especially for PW
6. driver how to cope with unsupported attributes? what's the rule.
Site2DC Networking clarifying
We discussed networking in site2DC scene, and made an detailed solution:
1. for SFC in POP, ZTE will provide VASes, SFF, physical Bras (only for classifier), and controller. vCPE will direct traffic into SFC with VLAN tag.
2. for SFC in POP, SFC keep vlan tag as tenant id, and firewall configure need handle VLAN tag.
3. for DC, ZTE dc controller will create VNFs, vAPPs, and VLs, Huawei Controller will convert vlan to vxlan, and make router, gateway, ipsec ,and SFC over physical devices.
Site2DC SDNO Open-Tosca Model
We discussed networking in site2DC scene, and agreed on a rough model:
1. there should be a site2DC connection in top level of model.
2. site2DC connection depends on three segment: access vxlan, wan ipsec, DC vxlan.
SDNO provide template in catalog, and provide NBI for GS-O
We discussed GS-O and agreed:
1. SDNO should provide three SSAR, for Resident2Internet(operator), Enterprise2DC(operator), and Enterprise2DC(tenant)
2. SDNO provide NBI similar to NFVO ([[File:NSLCM API Specification-v0.1.pdf]]), but not same, NFVO specified attributes will be removed, and some minor changes.
SDN-O traffice design & implementation for monitoring & visualization & Steering & Optimization
1. Introduce TE+ Traffic optimize architecture to SDN-O project team, and also workflow and key technology
2. Confirm the API and inter-action between Monitor module/Optimizer module and Common Services(Micro-service Bus)
3. Define API and parameter between Monitor module and SDN-O Resource Manager(BRS)
4. Confirm the inter-action between TE-Driver Driver Manager?in release 1 the modules register within Micro-service Bus?the Monitor and Optimizer module communicate with other modules via Micro-service Bus
5. Define TE-Driver and controller NBI , provide the document to define the NBI of controller
6. Confirm the future work and code to be submitted of the four modules following graph of architecture 1
Driver Mgr. API & interaction sequence with SDNO/NFVO/driver
Sequence diagram: SDNO invokes SDN Controller service
Sequence diagram: NFVO invokes VNFM service
- SDNO will use Driver Mgr. in Sun release and SDNC Controllers must register themselves to the Driver Mgr.
- Driver Mgr. is not a must-have feature for NFVO in Sun release, each VNFM driver sub-project can decide if the driver should be registered to Driver Mgr. according to the manpower and timeframe
External System Register(ESR)
- ESR should check the connection between the O and the External System when it is registered to ESR
- ESR should promote the user if O can't establish connection to the External System
- External System should be allowed to be registered to ESR even if the connection is not ready yet
- Driver mgr. need to add a Restful API for the connection check to be used by ESR
- email@example.com add a Restful API for connection check in the Driver Mgr. API document wiki page
- Driver developers Implement the check API for drivers
- Saw jin explained the functionalities and scope of Protocol Stack
- Protocol Stack acts as a proxy between a none-NETCONf aware client and a NETCONF server. Client sends a plain request to NETCONF Protocol Stack Microservice, then NETCONF Protocol Stack Microservice translate the request to a NETCONF request and send the request to the NETCONF server
- Restful Stack Protocol should not be included in the scope
- firstname.lastname@example.org add some diagrams and descriptions in the Common Service release plan wiki page to explain the functionalities and scope of Protocol Stack
- email@example.com remove the Restful Stack Protocol from the Common Service release plan wiki page
A repository to accommodate cross-projects utility
- A repository is needed for cross-projects utility
- This would be a sub-project of Common service
- firstname.lastname@example.org will propose a sub-project under Common Service to TSC to accommodate the cross-projects utility
- Sukesh asked for the file registration of microservice.
- Registration by file is supported but only used by Microservice Bus internally and not recommended to other services to register
- The config files are located in a local directory of the host node of Microservice Bus
- The config files will not be dynamically reloaded at runtime due to performance reason
- The plugin mechanism to integrate the Auth plugin and Driver Mgr. Plugin to Microservice Bus
- email@example.com will share the Microservice Bus plugin mechanism to Sukesh as soon as it's ready
- firstname.lastname@example.org presented the service list wiki page : [[OPEN-O Services List]]
- email@example.com presented the swagger and metrics mechanism of Microservice Bus : [[Common_Service:Microservice_Bus_API_DocumentationSwagger_and_Metrics|Swagger_and_Metrics]]
- Developers register the services to the service list wiki page
- Developers add swagger and metrics implementation for each microservice according to the specification
- firstname.lastname@example.org will post the SDN-O WAN service template draft for discussion in the next week
- email@example.com will post the NFV-O domain service template draft for discussion in the next week
- firstname.lastname@example.org will post the GS-O E2E service template for discussion as the WAN and domain service template are ready
- email@example.com identify the gap between the current implementation and desired functionality of Model Designer according to the service template draft
TOSCA simple profile extension for Plan
Plan is missing in the TOSCA simple profile, the NFVO, SDNO and Model Designer developers suggest add a keyname in the service template definition
- firstname.lastname@example.org will talk with Arthur and Tal to confirm how the Common Parser handles the extended keyname