Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
https://wiki.onosproject.org/display/ONOS/YANG+Runtime
Design Considerations
Framework components must be model-agnostic
- e.g. runtime, protocol adapters, information store
- must be capable dealing with any potential model
- cannot be linked with the model-specific objects
- hence must deal with data in a neutral format, i.e. raw tree
Applications should be model-aware
- e.g. applications that implement network services
- must understand the semantics of the model to operate
- raw tree representation not expressive or application friendly
- hence should deal with data in domain-friendly model objects
Model-agnostic Tree View
Consider a simple device model
- device has a number of attributes and a number of ports
- each port has a number of attributes
Spread across several tree layers
- data produced by tree augmentation
- data accessed by tree traversal
Model-specific Object View
Rich data types, e.g. Device, Port
- domain-friendly abstractions
- idiomatic Java usage
Consolidates multiple tree layers
- data created through constructors
- data accessed via accessors
- device.swVersion() or device.getPorts()
Model Object & Tree Views
Toolchain facilitate both model-agnostic tree
view and model-specific object views
Toolchain must allow conversion between them
Model ←→ Tree View
Mutable vs Immutable
Immutable data is safer in multi-threaded apps
- free of side-effects when shared by caller
- memory efficient - a single copy can be shared by many threads
… but apps need to easily mutate data
Model objects are mutable
- modified via idiomatic constructors and setters
Tree views are immutable
- constructed via builders
- immutable once constructed
Configuration of Devices
- Goal is to enable a network operator to seamlessly configure devices from different vendors and to verify the configuration with minimal or no human intervention
- Offers significant OPEX savings and vendor independence for network operators
- Offers vendors faster integration of their products into operator’s networks
Configuration of Services
● Goal is to 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
● Provides network operators with agility to deploy new services with reduced OPEX
● Offers vendors opportunity to support many services on their devices
Reference of Applications
Schema Aware Applications:
Applications who are aware about the YANG data structure and operates on that.
Example: L3VPN, PCE, SFC
Schema Un-aware Applications:
Applications who are not aware about the YANG data structure and wanted to operate in schema agnostic way.
Example: RESTCONF, NETCONF, Store
Enhancement with YANG 2.0
| YANG Tools (1.11) + YMS | YANG Tools (2.0) + Dynamic Config |
Generated Classes | Tied to YMS; no common basis between models | Common ancestor for all models; model-agnostic and model-specific access; friendly API for apps |
Storage | Ad hoc; models serialized and stored at the discretion of application | Any and all models in a single store |
Protocols | RESTCONF and NETCONF are tightly coupled and integrated with YMS | RESTCONF and NETCONF can be maintained independently; new protocols (e.g. gNMI are easier to add) |
New Models | Applications must be made aware of all models at compilation time; cannot be stored by YMS | Applications can interact with new models or augmentations at runtime using the model-agnostic interface |
Live Compilation | Not available; introduction of new models requires recompilation | YANG models can be introduced and compiled at runtime (e.g. from a device) |
Modularity and Maintainability | YMS and onos-yang-tools are tightly coupled making maintenance difficult and usage is brittle | YANG tools, dynamic config manager and store are implemented in a modular fashion; they can be evolved and maintained independently from one another; generated classes are not tied to the dynamic config store |
Reference
https://wiki.onosproject.org/display/ONOS/YANG+Compilerhttps://wiki.onosproject.org/display/ONOS/YANG+Runtimehttps://wiki.onosproject.org/display/ONOS/YANG+utilshttps://wiki.onosproject.org/display/ONOS/L3VPNFuture
To be planned:
1) YANG 1.1 version.
2) OpenConfig YANG integration to ONOS.
3) YANG Library based on RFC 7895.
4) YANG GUI enhancement for live compilation.