Hi Per,
From: Igor Bryskin [mailto:igor.brys...@huawei.com] Sent: Sunday, October 8, 2017 7:04 PM To: Igor Bryskin <igor.brys...@huawei.com>; p...@tail-f.com; xufeng.liu.i...@gmail.com Cc: netc...@ietf.org; netmod@ietf.org Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref 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:p...@tail-f.com,xufeng.liu.i...@gmail.com, Cc:netc...@ietf.org,netmod@ietf.org, 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:netc...@ietf.org,'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? [Xufeng] The "get" operation is the NETCONF/RESTCON <get> protocol operation, or the <get-data> operation described in <https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01> https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET operations on {+restconf}/ds/<datastore> described in <https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00. We have a list of leafref values because in this example model, each tunnel contains a list of paths, each of them contains a leafref. The "get" returns a value for each instance of such a leafref, which (as a string value) will be used as a constraint (foreign key) to retrieve the instance of an explicit-path in the model above. 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 > netmod@ietf.org <mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ Netconf mailing list netc...@ietf.org <mailto:netc...@ietf.org> https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
