Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

Hi Per,

Basically, what we need is a way for a client to request something like this:

get <XPath> joint with <XPath1, XPath2, ..., XPathn>

with a server interpreting the request as follows:
if a node pointed by XPath contains a pointer (e.g. key leafref) matching one of the XPath from the "joint with" list, then the server must provide the entire body of the node pointed by the pointer, otherwise, just the pointer (as it happens today, that is, when no "joint with" list specified).

We think that this would allow for the client to optimize the number of request-response iterations depending on application/use case.

Regards,
Igor  

-----Original Message-----
From: Per Hedeland [mailto:per@tail-f.com] 
Sent: Monday, October 09, 2017 12:06 PM
To: Xufeng Liu
Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

I understand your use case, but a leaf of type leafref does not in
general identify a single node in the data tree - the leafref path could
be for a non-key leaf, and/or the path could traverse list nodes, and/or
the "target" list could have multiple keys and thus multiple
leafref-leafs be required to identify a specific list entry.

Thus it seems to me that your use case is not a reasonable basis for a
new protocol operation. My XPath foo isn't very good either, but I do
believe Robert's suggestion of using an XPath filter could be a way
forward. I *think* the filter expression would be something along the
lines of

 /te/tunnels/tunnel[name='foo'] | /te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/paths/path/explicit-path]

--Per

On 2017-10-09 15:42, Xufeng Liu wrote:
> Hi Per,
> 
>  
> 
> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
> *Sent:* Sunday, October 8, 2017 7:04 PM
> *To:* Igor Bryskin <Igor.Bryskin@huawei.com>; per@tail-f.com; xufeng.liu.ietf@gmail.com
> *Cc:* netconf@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:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
> 
> *Cc:*netconf@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:*netconf@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 and the GET operations
> on {+restconf}/ds/<datastore> described in  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
> Netconf@ietf.org <mailto:Netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf
> 