no tailf:cli extentions for juniper junos

[erdemk]

Hi,

I have a question for understanding the NSO logic.

As far as i understand , the innovation of Tailf at the time was, generate Yang files with the addition of tailf:cli-xxx-xxx (yang cli extentions). With the help of these extentions, Cisco NSO becomes aware of the device's relational-data-model. From this point onwards,  Fastmap algorithm which depends on the status of these data-models ( ie services ) was developed. And a lot of other features and functionalities are added on top of it.

So, my question is , in the examples which are in the delivery pack, why do yang models for cisco and alu routers include tailf:cli-yang-extentions but yang model for juniper junos do not include tailf:cli-yang-extentions. May be, i do not know, it is because juniper router is used with netconf. If it is so, isn't it still necessary to know the device's relational-data-model for netconf based implementations ?

Many thanks in advance. 

[vleijon]

The CLI annotations are not as central as you might think - and FASTMAP does not depend on them. If you look in the documentation you will find that there are multiple kinds of NEDs (CLI, NETCONF, SNMP, Generic) - each has a different way of getting the data from the device.

What tailf:cli-xxx does is that it helps render a parser for the CLI-language (and, a parser is also a generator!). Originally this was used in ConfD to help modify the CLI that was presented to the user, but then later on it was used to generate an automatic parser for what is called "CLI NEDs" in NSO. It gives a translation between the CLI-format and a NETCONF/YANG format for the configuration.

This gives us a convenient way to create CLI NEDs and a good way of rendering the CLI for the device. But, if every CLI NED was programmed by hand, the result would still be the same (it would just require more work to create the NEDs). What is important is that we have a data model for every device - but that is just the yang model, the annotations don't really help with that.

Hopefully this helps clarify things a little bit.

[erdemk]

Hello Viktor,

Thanks for quick reply, and i took some time to think..

As far as i understand, i still think that relational-data-model for devices is key for NSO in action, at least for CLI NED and SNMP NED cases. A YANG model without relational-data-model is not enough for Fastmap algo to do its magic. Whether this is performed by programming by hand or cli-annotations is not actually the point. As of now i dont really know Netconf NED, but for CLI NED and SNMP NED , annotations ( or device's relational-data-model ) plays a key role. May you confirm on this, or am i on the wrong page ? 

Also, You wrote :  

But, if every CLI NED was programmed by hand, the result would still be the same (it would just require more work to create the NEDs). What is important is that we have a data model for every device - but that is just the yang model, the annotations don't really help with that.

Isn't this conflicting, or i am looking from different direction to the sentence ?  in the sense that, " if the CLI NED was hand written result would be same , meaning it would also have the info which annotations would bring" vs "important thing is the yang model, but not the annotations"

Kindly appreciate your response.

Thanks in advance.

[vleijon · Accepted solution]

I think you are getting on the right track. The important thing is how the yang model is translated to the device native format - which is what you refer to as the relational data model. I was trying to say that it doesn't matter how this mapping is performed - that using annotations is just an easier way of creating the mapping than writing the code by hand.

It is worth mentioning that FastMap actually works on a higher level, you can use fastmap without ever touching a device! Though this is a pretty rare use-case since most NSO users want to modify the network it does happen, especially in what we call Reactive Fastmap-type services.

[erdemk]

Thank you for the clarification.