Re: [netmod] Retrieving Information Pointed by leafref
Per Hedeland <per@tail-f.com> Sun, 08 October 2017 18:01 UTC
Return-Path: <per@tail-f.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 3B15913314B; Sun, 8 Oct 2017 11:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 YCbd7cBkgBgd; Sun, 8 Oct 2017 11:00:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 786CC1320D9; Sun, 8 Oct 2017 11:00:59 -0700 (PDT)
Received: from pluto.hedeland.org (81-228-155-109-no289.tbcn.telia.com [81.228.155.109]) by mail.tail-f.com (Postfix) with ESMTPSA id 9AC4A1AE018C; Sun, 8 Oct 2017 20:00:57 +0200 (CEST)
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>
From: Per Hedeland <per@tail-f.com>
Cc: netconf@ietf.org, 'NetMod WG' <netmod@ietf.org>
Message-ID: <eac8b96e-227b-347f-9c02-81718918ed08@tail-f.com>
Date: Sun, 08 Oct 2017 20:00:57 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <033601d33ee7$bd359810$37a0c830$@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/BuRQQblqKxSmGAibJOdDPiF5ZcU>
Subject: Re: [netmod] 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 18:01:01 -0000
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 >
- [netmod] Retrieving Information Pointed by leafref Xufeng Liu
- Re: [netmod] Retrieving Information Pointed by le… Kent Watsen
- Re: [netmod] Retrieving Information Pointed by le… Kent Watsen
- Re: [netmod] Retrieving Information Pointed by le… Per Hedeland
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Xufeng Liu
- Re: [netmod] [Netconf] Retrieving Information Poi… Robert Wilton
- Re: [netmod] [Netconf] Retrieving Information Poi… Per Hedeland
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Martin Bjorklund
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Per Hedeland
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Per Hedeland
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Per Hedeland
- Re: [netmod] [Netconf] Retrieving Information Poi… Robert Wilton
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… t.petch
- Re: [netmod] [Netconf] Retrieving Information Poi… Robert Wilton
- Re: [netmod] [Netconf] Retrieving Information Poi… Xufeng Liu
- Re: [netmod] [Netconf] Retrieving Information Poi… Robert Wilton