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

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>
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
Netconf@ietf.org <mailto:Netconf@ietf.org> 
https://www.ietf.org/mailman/listinfo/netconf