cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
659
Views
0
Helpful
3
Replies

How to map cisco-ios (NED) yang models to our own service yang models?

ckempapu
Level 1
Level 1

Hello NSO's,

     Missing to bring the cisco-ios (NED) yang model to my new service yang model,

I am importing "tailf-ned-cisco-ios.yang", in my created Yang model, it leads to come compilations error, any help appreciated.


Regards,

Chandrakala K

1 Accepted Solution

Accepted Solutions

alam.bilal
Cisco Employee
Cisco Employee

Hi,

Generally, we don't want to "bring" device models definitions into service models. The high-level idea is to keep the service-models abstracted from the device level details if possible. This de-coupling between the service and device layers and allows for easy portability and migrations in the future.

Having said that, sometimes service designers, in their service design want to "refer" to elements of the device-model. An analysis of this approach should be done to ensure service models remain vendor/device agnostic as much as possible.

Once decision is made to refer to device's model, just look at the makefile under the package's src directory. Look for the comments:

## Uncomment and patch the line below if you have a dependency to a NED

## or to other YANG files

# YANGPATH += ../../<ned-name>/src/ncsc-out/modules/yang \

#       ../../<pkt-name>/src/yang

We should see the above for a package generated using "ncs-make-package". Example:

balam@nso-dev:~/servicex/src$ ncs-make-package --service-skeleton java-and-template servicex

Then in the service's yang file import the moduled defined by the NED.

View solution in original post

3 Replies 3

alam.bilal
Cisco Employee
Cisco Employee

Hi,

Generally, we don't want to "bring" device models definitions into service models. The high-level idea is to keep the service-models abstracted from the device level details if possible. This de-coupling between the service and device layers and allows for easy portability and migrations in the future.

Having said that, sometimes service designers, in their service design want to "refer" to elements of the device-model. An analysis of this approach should be done to ensure service models remain vendor/device agnostic as much as possible.

Once decision is made to refer to device's model, just look at the makefile under the package's src directory. Look for the comments:

## Uncomment and patch the line below if you have a dependency to a NED

## or to other YANG files

# YANGPATH += ../../<ned-name>/src/ncsc-out/modules/yang \

#       ../../<pkt-name>/src/yang

We should see the above for a package generated using "ncs-make-package". Example:

balam@nso-dev:~/servicex/src$ ncs-make-package --service-skeleton java-and-template servicex

Then in the service's yang file import the moduled defined by the NED.

Hi Bilal Alam,

   The below warnings/errors pop up after the import of NED model, and un-comment the  YANGPATH.

Please let me know "if this is ok and can proceed".

Few of them I copied here.

/home/sandbox/nso-4.4.2/bin/ncsc  `ls zbfw-ann.yang  > /dev/null 2>&1 && echo "-a zbfw-ann.yang"` \

              -c -o ../load-dir/zbfw.fxs yang/zbfw.yang

/home/sandbox/nso-4.4.2/src/ncs/yang/tailf-ned-cisco-ios.yang:800:32: warning: illegal character after \

/home/sandbox/nso-4.4.2/src/ncs/yang/tailf-ned-cisco-ios.yang:801:9: warning: illegal character after \

/home/sandbox/nso-4.4.2/src/ncs/yang/tailf-ned-cisco-ios.yang:801:26: warning: illegal character after \

/home/sandbox/nso-4.4.2/src/ncs/yang/tailf-ned-cisco-ios.yang:5119: warning: when tailf:cli-drop-node-name is given, it is recommended that tailf:cli-suppress-mode is used in combination. using tailf:cli-drop-nodename in a list child without using tailf:cli-suppress-mode on the list, might lead to confusing behaviour, where the user enters the submode without being able to give further configuration.

/home/sandbox/nso-4.4.2/src/ncs/yang/tailf-ned-cisco-ios.yang:5119: warning: when tailf:cli-drop-node-name is given, it is recommended that tailf:cli-suppress-mode is used in combination. using tailf:cli-drop-nodename in a list child without using tailf:cli-suppress-mode on the list, might lead to confusing behaviour, where the user enters the submode without being able to give further configuration.

Regards,

Chandrakala K

These warnings are from the NED's model. I've seen similar ones when building NEDs. They look harmless to me.