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

Igor Bryskin <Igor.Bryskin@huawei.com> Sun, 08 October 2017 21:36 UTC

Return-Path: <Igor.Bryskin@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744F9132A89; Sun, 8 Oct 2017 14:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AhSISIoCbH5; Sun, 8 Oct 2017 14:36:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FD5132320; Sun, 8 Oct 2017 14:36:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXC18750; Sun, 08 Oct 2017 21:36:21 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 8 Oct 2017 22:36:20 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.207]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000; Sun, 8 Oct 2017 14:36:08 -0700
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: "per@tail-f.com" <per@tail-f.com>, "xufeng.liu.ietf@gmail.com" <xufeng.liu.ietf@gmail.com>
CC: "netconf@ietf.org" <netconf@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [Netconf] [netmod] Retrieving Information Pointed by leafref
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/gBsqhSA///GxXk=
Date: Sun, 8 Oct 2017 21:36:07 +0000
Message-ID: <etPan.59da9a33.12305c3a.3f7f@localhost>
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>, <eac8b96e-227b-347f-9c02-81718918ed08@tail-f.com>
In-Reply-To: <eac8b96e-227b-347f-9c02-81718918ed08@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_etPan59da9a3312305c3a3f7flocalhost_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59DA9A55.00B0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9c1704efd10219ce476efdd10cc12770
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/G_NU2Pv_9CjBf4F8mD7T2Iwgk_s>
Subject: Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Oct 2017 21:36:26 -0000

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?

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
> https://www.ietf.org/mailman/listinfo/netmod
>

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf