Goal
- Dynamic Configuration of Devices
- Enable a network operator to seamlessly bring up/down and configure devices from different vendors and to verify the configuration with minimal or no human intervention.
- Dynamic Configuration/Provisioning of Services
- Enable a network operator to seamlessly configure and provision a service on the network comprising many devices from many vendors with minimal or no human intervention
Story
- Dynamic Configuration Story slide is a reference to our vision and view how this dynamic configuration system works. It basically covers both device configuration and service provisioning.
- Story document:
Documents
- Dynamic Configuration Design Requirement
- Brigade DynConfig for ONOS Build.pdf
- Dynamic Configuration Design Document
Roadmap
Phase 1: Target ONS 2017 (April, 2017) - Demo 1, Demo 2
- ONOS Release “I” (now)
- APIs definitions for YangCompiler, YangRuntime, and DynamicConfigStore
- ONOS Release “J”
- Refactoring & code restructuring: YangCompiler, YMS -> YangRuntime,
- Implementation of DynamicConfigService & Store
- Implementation of RESTCONF & NETCONF Apps
- Sharding of subtrees will be opportunistic
Phase 2
– Demo 3 (Multi Vendor Device)
– ONOS Release "K" & “L”
- Sharding of subtrees
- Transactional updates
- Performance optimizations
- Driver model based on Behaviors
- Explore Common Driver Architecture (Add a new device without code release -)
Requirements to Dynamic Configuration Brigade
Here is a requirement holder, which includes the features, bug fixing, etc.
Requirements Description | Suggested Priority | contact (email) | comments and feedback |
---|---|---|---|
YANG Store Service notification API should support multiple operations on different node and subtree | high | ||
Augment is required by L3VPN. the changes in yang tools in reflect to the recent architecture refactoring should support this. | high | patrick.liu@huawei.com | |
Weekly Meeting and Brigade Event
From 8am to 9/10 am (PST) on each Thursday morning.
Dial-in Info
Please join my meeting from your computer, tablet or smartphone.
You can also dial in using your phone.
United States : +1 (872) 240-3212
Access Code: 199-251-813
Date | Meeting and Event | Meeting highlights | Action Item |
---|---|---|---|
12/13/2016 | Agenda Gaurav on recent code changes in builder, model object, model converter and data node. Store APIs |
| YANG runtime API will be discussed in next meeting (Gaurav) Use case of merge operation during configuration (Vinod) Demo 1 requirement from SP (Thomas) Need close coder review on store APIs (Thomas) |
12/08/2016 | Agenda review DataNode definition (Gaurav) Review of Dynamic Config Service APIs (Sithara)
|
| |
12/5/2016 | Agenda
| ||
11/29/2016 | Agenda
|
| can Vinod help to make a summary about datanode discussion? |
11/22/2016 | Agenda
|
| Vinod will look into Path definition |
11/17/2016 weekly meeting | Agenda
| this meeting is rescheduled to 8-9am of 11/18/2016
| Patrick send out the link to the requirement holder. |
11/15/2016 Sprint Planning | Ibis Release Sprint# 3 planning | 11 Dynamic-config and 4 yang-tools JIRA tickets are planned key milestones:
| |
11/10/2016 weekly meeting | Agenda:
|
| Ibis Sprint #3 Planning |
11/3/2016 weekly meeting | Canceled because of ONOS Build Event | ||
11/2/2016 Team Meet together | Brigade team meet together at ONOS build in Paris
|
| |
10/27/2016 weekly meeting | Agenda:
| Review Design Requirement document
| |
10/20/2016 weekly meeting | Introduction to current YMS, ElasticConfig subsystem, etc. and also Common Driver Idea.
| Need a system level model transform diagram to show NB model to SB model transform |
How to get involved
Help needed
- 1-2 developer for configuration Store, who is/are required to work with ONOS distributed core team to implement Store Mechanism, Application API, and advanced store features etc. Location can be local or remote.
- 1-2 QA engineer, whose responsibility will be setup related testing environment in ON.LAB, design stress and regression testing plan and testing cases, write automation script, work with developer on any issues by stress and regression test. Local resources are preferred.
- Invite 3 (at least) vendors to join the brigade. These vendors will provide one or two L3 devices with NETCONF and device model ready. Engineers are required to work with Brigade team to integrate their devices into the demo environment. They are required to know their device model and is able to help brigade team to debug any issue seen during the integration.
Contact the brigade:
- Add Slack channel, other communication channel
brigade-dynconfig@onosproject.org
Brigade Leader:
- Patrick Liu
Brigade Members:
- Gigamon : Venkata Narayana Tata;
- Fujitsu: Aarun, Satoshi
- Huawei: Gaurav, Henry, Patrick, Sithara, Vinod
- ON.LAB: Brian, Ray, Thomas
- Verizon: Viswanath KSP, Jay Simha, Venkat Sravan, Vipul Malgotra
========= Announcement Please: the information below are under construction in reflect to the latest view, design and requirements.
Demo (under construction)
- Use ONOS YANG Utils to translate IETF L3SM L3VPN model to JAVA application framework
- Enable and disable L3VPN service on ONOS controller through dynamic configuration
- Add a new device through modifying ONOS driver configuration (.xml) file.
- Configuration data persistency. the initial consideration is through a 3 node ONOS cluster. more node clustering setup will be considered upon request.
- Demo topology is still under construction.
Scope (Under Construction)
Build a model driven architecture in ONOS to dynamically install/update/remove the configuration for NETCONF enabled devices. In the first release, we will use L3VPN as a use case and build related applications on top of this architecture to demonstrate how this architecture works. This project will be based on and integrate the results from existing projects (e.g. YANG Utils, YMS, etc) and create new several components when necessary. In the demo, we plan to use multi-vendor devices as network element in our demo setup. to be specific, five components are involved
1. YANG Utils. This tools is used to translate YANG defined service/network model and device model into JAVA code. After Releases "G" and Release "H" hard working, current YANG Utils can meet this brigade requirement and no new features are required for this brigade.
2. We need build L3VPN application and provide configuration interface to allow user enable/disable and configure L3VPN service on each device dynamically. This is a brand new application, which will be based on IETF L3SM L3VPN model. Please see L3VPN project proposal page for the implementation details
3. In order to make ONOS internal application development easier, we will use YMS to manage ONOS YANG-based services. The minimum requirement by this brigade is brokerage service, RESTConf, XML/JSON codec, etc. This part is pretty much L3VPN related, see L3VPN project proposal wiki for the dependency and development plan. For external application, it could request ONOS resource and topology service. We don't require YMS to provide the API for ONOS core services in our short team plan. This is required by our long term plan.
4. Distributed Configuration Store. This is expected to provide a powerful distrusted data store primitive DocTree to application to store their configuration. It provides two consistency models- eventual and strong consistency model. The operation rate targets to support 10-12K operations per second. We hope this will meet most of the application's configuration requirement. Store operation for APIs include get/put/update/delete. APIs are under construction. For more details of this store and the service to access this store, please refer to Dynamic Configuration Subsystem.
5. Device Driver. This is a new component. The target is to build a service and device independent driver. When a new device( from same vendor or different vendor) is added, it is not required,we hope, to build a new driver any more. In our current on-going design, this is achieved through modifying ONOS driver configuration file (in .xml format) by the results of comparing a "standard" device model with vendor's device model. Based on the comparison results, we category this into three group: SAME, RULE, and TRANSFORM. Driver will handle them differently.
1) SAME: both models are same (namespace can be different). In this case, we only need modify driver configuration file (.xml).
2) RULE: Vendor's device model can be translated into standard model by policy. For example, some construct missed, device mode is subset of standard model, etc. In this case, we only need modify ONOS driver configuration file (.xml)
3) TRANSFORMER: Vendor's device model cannot be translated or mapped to "standard" model through policy. Because the "Standard" device model is from IETF or a standard organization, we hope this case is not common. In this case, a new transformer code is required to translate the standard model to this special device model.
Short-term focus in 2016
Use IETF L3SW model in building both network layer application and network element layer application
Use 3-5 devices from different Vendors as network elements in the Demo setup
New components to be built
L3VPN Application. This is an external application (off-platform) that handle network model.
Ne L3VPN App. This is an ONOS internal application that processes device model. Its north bound interface is defined by IETF.
Configuration Store. This is used to store configuration of device.
Driver Mechanism. This is an service and device agonistic mechanism
Long-term focus in 2017
- Performance Assessment and do the enhancement if necessary
- Transactional Operation on Configuration Store