Hi Joel, Thanks, I think I didnt explain our problem correctly.
In our case we have a leafref pointing to a te tunnel name, which happens to be a key to lookup the (axilary) tunnel. We need a way to include the entire tunnel body (not just a name) into the get response. This is to optimize the number of iterations between the client and the server. As Xufeng put it something similar to SQL join, Igor From:Igor Bryskin To:[email protected],[email protected], Cc:[email protected],[email protected], Date:2017-10-08 17:36:47 Subject:Re: [Netconf] [netmod] Retrieving Information Pointed by leafref Hi Per, In a nutshell we would lika for a netconf client to have a way to instruct the server on whether in response to the get request the server needs to provide the entire body of a datastore node pointed to by a leafref or just a pointer to said node, so that the node's body could be retrieved by a subsequent separate request. This is requested by implementors who want to optimise rhe number of interactions between a client and its server. Cheers, Igor From:Per Hedeland To:Xufeng Liu, Cc:[email protected],'NetMod WG', Date:2017-10-08 14:01:27 Subject:Re: [Netconf] [netmod] Retrieving Information Pointed by leafref On 2017-10-06 23:11, Xufeng Liu 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 tunnels information based on the tunnel > name, the get operation returns a list of leafrefs pointing to the paths > of the tunnel. Sorry, I'm afraid I don't follow. Can you explain exactly what your "get" request is (protocol and payload), and where the "list of leafref's" (whatever that may be) occurs in the reply? JFYI, in case there is some fundamental misunderstanding here: a leaf of type leafref has a single value - *one* of those that satisfy the leafref constraint, in case there are multiple "candidates". --Per > 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. > > Wed 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 leafrefs? > > Comments and suggestions are appreciated. > > Thanks, > > - Xufeng > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ Netconf mailing list [email protected] https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
