cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1487
Views
0
Helpful
6
Replies

how to see the ports of a selected router by use of leafref { path " deref(...)...}

erdemk
Level 1
Level 1

Dear Experts,

 

I have read the examples in the community, but couldn't manage this. May some one help please..

I have the following YANG file.

Desired output : Whenever, operator selects a dest-router, would see in dest-router-port the available interfaces of the selected dest-router.

What would i enter for leafref-path for "dest-router-port" ?  ( information available below in yang file )

Also, is there any other nso facility that i can have a look , like may be a log file, for /package/src/make all xpath problems

Many thanks in advance.

 

 

YANG file : 

 

module vodafone {

    namespace "http://com/poc/vodafone";

    prefix vodafone;

    import ietf-inet-types {

        prefix inet;

    }

    import tailf-common {

        prefix tailf;

    }

    import tailf-ncs {

        prefix ncs;

    }

    import tailf-ned-cisco-ios  {

        prefix ios;

    }

    import tailf-ned-cisco-ios-xr {

        prefix cisco-ios-xr;

    }

    typedef port {

        type string {

            tailf:info "[0..9]/[1..3]/[0..48]";

            pattern "[0-9]/[1-3]/([0-9]|[1-3][0-9]|4[0-8])";

        }

    }

 

    container topology {

        list cer-branch {

            key cer-branch-name;

            leaf cer-branch-name {type string;}

            leaf cer1 {

                type leafref {

                    path "/ncs:devices/ncs:device/ncs:name";

                }

            }

            leaf cer2 {

                type leafref {

                    path "/ncs:devices/ncs:device/ncs:name";

                }

            }

            list cer-branch-devices {

                key cer-branch-device;

                leaf cer-branch-device {

                    type leafref {

                        path "/ncs:devices/ncs:device/ncs:name";

                    }

                }

            }

        }

    }

    list redfiber {

        key name;

        leaf name {

            type string;

        }

 

        uses ncs:service-data;

        ncs:servicepoint redfiber-servicepoint;

 

        container fix {

            leaf cer-pair {

                type leafref {

                    path "/topology/cer-branch/cer-branch-name";

                }

            }

            leaf dest-router {

                type leafref {

                    path "/topology/cer-branch/cer-branch-devices/cer-branch-device";

                }

            }

            leaf dest-router-port {

//                type string;

                type leafref {

                    path "deref(../dest-router)/../cer-branch-device/ncs:config/ios:interface/ios:GigabitEthernet/ios:name"; // bad argument value "deref(deref(../dest-router)/../cer-branch-device)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name", should be of type path-arg

                    //path "deref(../dest-router)/../cer-branch-device/ncs:device/ncs:config/ios:interface/ios:GigabitEthernet/ios:name";    // the node 'device' from module 'tailf-ncs' (in node 'cer-branch-device' from 'vodafone') is not found

                    //path "deref(../dest-router)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name";     // the node 'config' from module 'tailf-ncs' (in node 'cer-branch-devices' from 'vodafone') is not found

                }

            }

        }

    }

}

 

 

1 Accepted Solution

Accepted Solutions

Hello Urban,

Thanks for your answer. Appreciated.

Referring to what you mentioned 'vendor specific xpaths in the model might not be the "best practice"', i agree that vendor specific yang is not desired, but i think eventually there will be instances that operators will be willing to see the available interfaces. Then in this case, how can we do this ?

Thanks in advance.

View solution in original post

6 Replies 6

erdemk
Level 1
Level 1

sorry for confusion, leaf dest-router-port part of yang file is like following. while i was copy-pasting, i have pasted the wrong part. 

thanks..

erdem

 

 leaf dest-router-port {

//                type string;

                type leafref {

                    path "deref(deref(../dest-router)/../cer-branch-device)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name";
; // bad argument value "deref(deref(../dest-router)/../cer-branch-device)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name", should be of type path-arg

                    //path "deref(../dest-router)/../cer-branch-device/ncs:device/ncs:config/ios:interface/ios:GigabitEthernet/ios:name";    // the node 'device' from module 'tailf-ncs' (in node 'cer-branch-device' from 'vodafone') is not found

                    //path "deref(../dest-router)/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name";     // the node 'config' from module 'tailf-ncs' (in node 'cer-branch-devices' from 'vodafone') is not found

 

i managed it with a must statement as floows..

still appreciate if some one could help with path statement without a must..

regards..

leaf dest-router-port {
    type leafref {
        path "/ncs:devices/ncs:device/ncs:config/ios:interface/ios:GigabitEthernet/ios:name";
    }
    must "current() = deref(deref(current()/../dest-router))/../ncs:config/ios:interface/ios:GigabitEthernet/ios:name";
}

Hey,

try something like this:

 

path "/ncs:devices/ncs:device[ncs:name=deref(current()/../dest-router)]/ncs:config/ios:interface/ios:GigabitEthernet/ios:name";

 

P.S. It might even work without deref. Also, make sure that device names will be actual IOS devices, right now things will break otherwise. A when statement checking the device type upfront might be a good idea.

 

P.P.S. I would tell you that these kind of vendor specific xpaths in the model might not be the "best practice", however I think that you really want this to happen so... just consider that there will be a lot of yang in case you will want to make this model multi-vendor.

Hello Urban,

Thanks for your answer. Appreciated.

Referring to what you mentioned 'vendor specific xpaths in the model might not be the "best practice"', i agree that vendor specific yang is not desired, but i think eventually there will be instances that operators will be willing to see the available interfaces. Then in this case, how can we do this ?

Thanks in advance.

Yeah this is one of those ungrateful situations when it comes to NSO.

 

Depends on the bigger picture:

If BSS is involved, maybe it would make more sense to do rest calls from there. So when your operator is filling out a BSS web form, the BSS will be doing multiple REST calls towards NSO to fetch interface info as provisioning options. Makes life easier and "proper" from NSO modeling perspective, however will probably cause more dev work on the BSS.

 

On the other hand maybe your BSS is not as flexible or easy to work with, so in that case it might make more sense to break the YANG modeling best practice and do it directly on the NSO since NSO is flexible.

 

Or maybe you only have NSO... in that case you don't have other options but to do xpaths.

 

 

I see..

Thank you very much..

regards

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the NSO Developer community: