Versions Compared

Old Version 124

changes.mady.by.user Adarsh m

Saved on

compared with

New Version 125

changes.mady.by.user Adarsh m

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Requested ByRequirementsSuggested Priority (high - Middle -Low)Current Status
Thomas Vachuska
Thanks for the demo of the YANG utilities at today’s TST meeting. While a lot of good work was done in the last release, I was a little bit surprised that the codec functionality was pushed off to the next release - and that NB-related concerns superseded SB-related ones. In my view, this is the basic value of using the YANG models - as it provides the ability to consume/produce XML payloads that are complaint with the model in a structured manner via Java API.
We have a set of use-cases for this to control/configure devices via NETCONF. Presently we have to accomplish this using hand-crafted XML and we were hoping to use the YANG tools-generated codecs for this. Consequently the SB use of YANG is of much more importance to us than the NB use of YANG - at least for the near-term.
In the Hummingbird release we need to be able to use the YANG tools generated artifacts together with our existing NETCONF sub-controller to produce driver implementations for several packet and optical devices. For this reason, I would like to request that this work be prioritized over anything else with respect to other YANG-related work. In order for that to happen, I think a number of other important questions will have to be answered and accounted for in the overall design of the YANG utilities:
  • Generated code for device models needs to be able to facilitate interactions with multiple devices that support the same model. This means that generated code should be stateless and avoid singleton service pattern. It should also take care not to intertwine transport concerns with encoding concerns (it should really only cover the latter).
  • Generated code should avoid commingling of code that is pure codec and not expected to be touched by humans versus RPC skeletal code whose innards are expected to be manually ‘implemented’ by humans and checked-in. This should simplify code re-generation as the model evolves
HighreviewingCompleted
Ali Al-ShabibiJSON or JSON-Schema Intermediary Representation. It would be nice if we could go from YANG to JSON or JSON-Schema because from this IR format we can easily go to XML or JSON or some other format that another protocol may want to use. As you probably know, Netconf is only one of the southbound to deliver payloads other ones such as gRPC or REST can be used.medium Completed
Marc De Leenheer

Support for OpenROADM YANG models. The specification contains two parts, a service-level model (NB) and a device-level model (SB). The first phase has already started, we want to integrate the device model into ONOS by early Q3 2016. In Q4 we will do the service level models. This is high priority work in collaboration with AT&T.

http://openroadm.org/home.html

high Completed
Aihua GuoIn order to support the use of standard IETF YANG models as an NBI for hierarchical SDN control, it is expected that the following YANG data constructs be supported in the H releases: augment (partially supported in G release), identity, feature/if-feature, when, must, leafref, path, require-instance. These data constructs are defined by YANG 1.1, and most of the IETF YANG models contain those constructs written in YANG 1.1.high 

...