Dynamic configuration brigade

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:
  • Dynamic-Config-Story-v0 1.pdf
    
    

Documents

1. Dynamic Configuration Design Requirement
2. Brigade DynConfig for ONOS Build.pdf 
   
   

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
• 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. 

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.

https://www.gotomeet.me/onlab

You can also dial in using your phone.

United States : +1 (872) 240-3212

Access Code: 199-251-813

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 Elastic Config 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