Re: [netmod] Retrieving Information Pointed by leafref

[Kent Watsen <[e-mail]>]

My experience is that clients get the entire config in one call, and then can perform such resolutions locally.

BTW, really long relative paths are harder to read than an absolution path.
../../../../../explicit-paths/explicit-path/name
On 10/6/17, 5:11 PM, "netmod on behalf of Xufeng Liu" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

During the design team discussion for TE and MPLS YANG modeling, we have received a request from implementers: How to minimize the number of NETCONF/RESTCONF RPCs to improve operation efficiency? Especially for the case when the operator or client software needs to retrieve the object contents pointed by a leafref.
For example, given the following simplified TE tunnel model,

+--rw te

    +--rw explicit-paths

    |  +--rw explicit-path* [name]

    |     +--rw name                      string

    |        +--rw explicit-route-object* [index]

    |           +--rw index                   uint32

    |           +--rw explicit-route-usage?   identityref

    +--rw tunnels

    |  +--rw tunnel* [name]

    |  |  +--rw name                   string

    |  |  +--rw paths

    |  |  |  +--rw path* [name]

|  |  |     +--rw explicit-path?  -> ../../../../../explicit-paths/explicit-path/name

when the client tries to retrieve a tunnel’s information based on the tunnel name, the “get” operation returns a list of leafref’s pointing to the paths of the tunnel. The client needs to issue at least one more “get” operation to retrieve the path information about the given tunnel. The request is to combine these two operations into one.
In the RDBMS SQL world, “join” can be used when SQL “select” is performed, but NETCONF/YANG currently does not have this capability.
We’d like to ask whether such a request is considered reasonable.
If the request is reasonable, the next question is how to proceed. This seems to be a protocol issue rather than YANG modeling issue. Is it acceptable to add a new operation to achieve such a <get-data> operation with expanded leafref’s?
Comments and suggestions are appreciated.
Thanks,
- Xufeng