I'm not sure that my XPath foo is good enough, but would NETCONF's XPath
filter solve this problem?
Thanks,
Rob
On 09/10/2017 14:42, Xufeng Liu wrote:
Hi Per,
*From:* Igor Bryskin [mailto:[email protected]]
*Sent:* Sunday, October 8, 2017 7:04 PM
*To:* Igor Bryskin <[email protected]>; [email protected];
[email protected]
*Cc:* [email protected]; [email protected]
*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:*[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?
*/[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
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
Netconf mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
