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

"Xufeng Liu" <> Mon, 09 October 2017 13:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0347A134540; Mon, 9 Oct 2017 06:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y9Rd5x4QNFAb; Mon, 9 Oct 2017 06:42:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3425E134544; Mon, 9 Oct 2017 06:42:16 -0700 (PDT)
Received: by with SMTP id l194so13590015qke.13; Mon, 09 Oct 2017 06:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=WSSF92VqfmwMslo6VurRPTBUBg4q1ZAUEhBDwwYhdGg=; b=kS2GvBwmDwoeGmK+B2UnEEdnATjK6J3ePcBqIFa1gkzRKd1D7coShbaWLNJYyA/4yK 6bJ11jOWtEflFa/oNfTmqhfBHZz3egn27iZODyXsJwnZgcXY4kLyGLE334VbhZ3MkzGI ZTl+fGczIx/d0qm6wlBcw6FdAIrxZV7K8esARE80ANC8osxsOB13BU+AOShaaJjtX1Wo g5LuoQtlEtDLqjO6MAheAZdZ0s1Gs1VmB+dWZwQPqMj3qFKiHb6GROR/qxhaYcC8YrmV +svknTR76IV5ckuLMUJ73NkBK/gpK4rrPTkRU/0UVAlmNk8SuvZZWLGnnmGx3RCEbC8G dPpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=WSSF92VqfmwMslo6VurRPTBUBg4q1ZAUEhBDwwYhdGg=; b=sKrq+DtgRGLchvp5cVV+0PrXtnapI7prh/dYuOFImtuFl2m+PizJE8G1SaSwI7zglO 41YoF/CjWoyWAETVH+jJkoPQdVXf/eQ2qxvTQFi33KIDvcGHX/G2ULJxlvvMAFIhaVW5 oPKEOgNW1tE5PV4clXAjXSjfFrB/4CTIjmdsKMEp+L+Bh4qK6ynjzlzKg1dxE9nTprwx bKyifuAjYiE67mgKpoYZym8Ds7XelsJC8g/iz2/RGsvXVTfSu274GoG2r7u/iEtr8N9N hANPzE0+RyxT32UvQW2VIE67hIPZfFMI3b2atUumSSr7DEZFW7yfXHuTqQO2R7jX8yEv 4GgA==
X-Gm-Message-State: AMCzsaUQq6KAeXqMSoCMdRB/+UkTlhw5RanJlzYuyElH8rlCVp42PKT0 ErFhw/8f9voGaJOebnqndII=
X-Google-Smtp-Source: AOwi7QC7xQ7NUpQ8B//s8yr/0hHbkCzh/hF5iR+G0pXwUDRLEKBI4ZXj3nfW0swCIWMOeHmn+/l1+A==
X-Received: by with SMTP id q5mr9434836qkd.83.1507556535343; Mon, 09 Oct 2017 06:42:15 -0700 (PDT)
Received: from xliuus ( []) by with ESMTPSA id y63sm4795200qky.75.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 06:42:14 -0700 (PDT)
From: Xufeng Liu <>
To: 'Igor Bryskin' <>,
References: <033601d33ee7$bd359810$37a0c830$>, <>, <etPan.59da9a33.12305c3a.3f7f@localhost> <etPan.59daaeb6.6daf0f5d.4ba3@localhost>
In-Reply-To: <etPan.59daaeb6.6daf0f5d.4ba3@localhost>
Date: Mon, 09 Oct 2017 09:42:14 -0400
Message-ID: <049501d34104$6aa46670$3fed3350$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0496_01D340E2.E39CB180"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJRlvjQguq0FpBEphzfpMnulw/GOQFkJZc0AsOBiP0AqC3rDqG4V7HA
Content-Language: en-us
Archived-At: <>
Subject: Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Oct 2017 13:42:22 -0000

Hi Per,


From: Igor Bryskin [] 
Sent: Sunday, October 8, 2017 7:04 PM
To: Igor Bryskin <>;;
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,


From:Igor Bryskin,,,,

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.


From:Per Hedeland

To:Xufeng Liu,,'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?  ->
> 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
<> and the GET
operations on {+restconf}/ds/<datastore> described in


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".


> 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
> <> 

Netconf mailing list <>