cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
37
Views
1
Helpful
3
Replies
Highlighted
Cisco Employee

Native Netconf vendors

Team ,

when a vendor supports native NETCONF do we just let the customer compile the vendors YANG files?  Reason I ask is it seams for Juniper we still deliver a NED that may or may not be based on the latest release.  I assume this will be the goal as it allows the customers to just compile the version they need.  I understand this puts the onus on the customer to test and keep up to date.

Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: Native Netconf vendors

My 2c on this.

The process of:

- taking the yang files from a netconf/yang device

- run ncs-make-package on those files

- load that package (NED) into NSO

- execute NSO sync-from

Is usually a bit involved.

We've gone through this process a number of times with tail-f ConfD customers that wanted to use NCS in EMS like solutions.

Usually the devil is the details there, the yang files contain all kinds of quirks, like tailf:hidden statements, sometimes refs to yang files that are the result of MIB->YANG compilation.

Sometimes transforms, from low->high level yang.

In the best of worlds, the device has this in perfect order, and you can just take the yang files (over NETCONF) and compile them.

That's usually not the case though.

Actually, we should provide some set of tool for ConfD developers to facilitate this process. This has been suggested many times but was never implemented.

As for Juniper yang files, we need to test the juniper yang files internally before we recommend this path to anyone. I'm betting there will be bumps in the road here. AFAIK no one has even tried to connect NSO to Junos yang/netconf

Also, their NETCONF impl isn't fully std compliant, so it may very well be the case that their yang/netconf isn't either. We may be forced to do some hackery on the NSO side to make that work. Needs to be tested first.

View solution in original post

3 REPLIES 3
Cisco Employee

Re: Native Netconf vendors

My 2c on this.

The process of:

- taking the yang files from a netconf/yang device

- run ncs-make-package on those files

- load that package (NED) into NSO

- execute NSO sync-from

Is usually a bit involved.

We've gone through this process a number of times with tail-f ConfD customers that wanted to use NCS in EMS like solutions.

Usually the devil is the details there, the yang files contain all kinds of quirks, like tailf:hidden statements, sometimes refs to yang files that are the result of MIB->YANG compilation.

Sometimes transforms, from low->high level yang.

In the best of worlds, the device has this in perfect order, and you can just take the yang files (over NETCONF) and compile them.

That's usually not the case though.

Actually, we should provide some set of tool for ConfD developers to facilitate this process. This has been suggested many times but was never implemented.

As for Juniper yang files, we need to test the juniper yang files internally before we recommend this path to anyone. I'm betting there will be bumps in the road here. AFAIK no one has even tried to connect NSO to Junos yang/netconf

Also, their NETCONF impl isn't fully std compliant, so it may very well be the case that their yang/netconf isn't either. We may be forced to do some hackery on the NSO side to make that work. Needs to be tested first.

View solution in original post

Cisco Employee

Re: Native Netconf vendors

Guess we are in the NED business for some time which is good from a revenue perspective.

Cisco Employee

Re: Native Netconf vendors

Haha,

Also worth to mention here then are the negatives we have when we use e.g a CLI NED.

- All of device is not modeled

- No stats, that has to be programmed manually (in the NED)

- Sometimes, depending on the device some really really awful quirks.

   The Fortinet NED springs to mind, which has a lot of the following construct

> show running

a

b

> set c

> show running

a

b

c

d

I.e when setting certain fields, it additionally set a few more behind the scenes.

This wreak havoc with the NED - this can be partially solved in the NED but it requires work and is error prone.

So, NETCONG/YANG is clearly superior to this.

Content for Community-Ad
August's Community Spotlight Awards
This widget could not be displayed.