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

"Xufeng Liu" <> Wed, 11 October 2017 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D1FF1321BB; Wed, 11 Oct 2017 11:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 D3c99pXkQPZl; Wed, 11 Oct 2017 11:43:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A79D4126B6D; Wed, 11 Oct 2017 11:43:30 -0700 (PDT)
Received: by with SMTP id n69so3115321lfn.2; Wed, 11 Oct 2017 11:43:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=DXQuH2GvGEvfWesAoKhn3+aDbdxx5SjmdtA3GQUOjJU=; b=ZzORWY/7YXf+IWeQZFhLs6yYHzAJWqwg63393KHea5RVDDQiikSQArTHzUbvgTOcrC l2c289gMkmgmWk4YO/2XLJC1VxivA8sOcFbg6o3Mt8KTLxfjTk+VUQuc1vo0lidItuIH 5+NiI+K/W2DYUKrJ0pIonpoAXckVkIxdACm4L3j3mts9U73YUlz1G5UfIIX0W43GvNXk iwmMHSkSFhCY/yT5yoAfwftkhhV/2d+070HpoYeg4qVUI1LdPyord5mEaS3U3pH6zfSt OMz2JXCs6ns5gMz6YBsTStr0LsxZN24chtX8h+X0zslydRavGAziHsT4Ts+bVbezrKWf 94VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=DXQuH2GvGEvfWesAoKhn3+aDbdxx5SjmdtA3GQUOjJU=; b=EyPfONhbtGxC5tNQU+JLxH5bOKSyWdL8jgIMVxXjTGKRTd0zILy/RQoT45dTThoG0U ZXVL8cya9C/K9pYB6U1cfnA6YmLV5kQzft3A+ftrdIlYy9KJJK54SHX+2p38jgX4/zvg kWI0QriB8lJ1qX+jFRpLg2wSgSAK5gyVcJCYHb2WjbrBUVO4NveuGYh6nvsojhVXBzbo O7KGhS5HbOEAxG9mwi4/8vADB21feJlzCdC4PDwYJ94VxUJ7f9QYIn/JxoO2eJupUnf5 MaY7NC78oV0aqTJA4tsVkM45ezk9377NTIXBRxR1aM9+dNoR4ekW8Egq+ZCImhL85GhJ bAmA==
X-Gm-Message-State: AMCzsaVkKGwSfkr6SGcV38NCtTZQHrCvq8xiyADmWmvMnQPjjOhIwNyr ktYc/n64dr4LgvSSxSdFxjI=
X-Google-Smtp-Source: AOwi7QBvhWURS5xe0sCzJd81NJounZ4Olp/x7yk5Kh5aufBswq/4A3nFnw9A2tK36BLxOW4Z1OwuRg==
X-Received: by with SMTP id x25mr225444lja.83.1507747408337; Wed, 11 Oct 2017 11:43:28 -0700 (PDT)
Received: from xliuus ( []) by with ESMTPSA id c74sm2396082lfe.49.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 11:43:27 -0700 (PDT)
From: Xufeng Liu <>
To: 'Robert Wilton' <>, "'t.petch'" <>, 'Igor Bryskin' <>,,
References: <049501d34104$6aa46670$3fed3350$> <> <> <> <> <etPan.59dbd366.8bfdc1a.12f7@localhost> <> <> <> <etPan.59dccc8e.149bf998.1428@localhost> <02aa01d34275$192f1840$> <>
In-Reply-To: <>
Date: Wed, 11 Oct 2017 14:43:23 -0400
Message-ID: <06f901d342c0$d368ef60$7a3ace20$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_06FA_01D3429F.4C5E0620"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJCNZXzN3NA433K0RCvmhmflzyYmgKC1LefAcsn3JUB/odxSQE23kEDAuNnxDoDMQ9GzwGJDtqqAhsXenABrAz8bQJe5yd1AUnHAMOhTIwD4A==
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: Wed, 11 Oct 2017 18:43:36 -0000

Hi Rob,


Thanks for the proposal. I think that the subtree does help, to a certain extend. The approach is worth mentioning to the implementers, though the remaining XPath is still complicated and could be worse for a more complex model. The good thing about the approach is that this is what we already have today. I agree with Tom on that NETCONF should have a better solution, but that may require protocol changes and need to cover more generic cases as Per described.



- Xufeng


From: Netconf [] On Behalf Of Robert Wilton
Sent: Wednesday, October 11, 2017 6:49 AM
To: t.petch <>; Igor Bryskin <>;;
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref


I've also been thinking about this problem a bit more :-)

The XPath solution works, but the expression isn't particularly nice to write, and I suspect that implementations may struggle to implement it efficiently (if they support XPath filtering at all).

A nicer solution here might be to allow the XPath filters to be combined with a subtree filter along the lines of a more advanced type of "Attribute Match Expression" sec 6.2.2 of rfc6241.

E.g. rather than this XPath filter:

/te:te/te:tunnels/te:tunnel[te:name='foo'] |

Here is example of what a subtree filter combined with an XPath filter could potentially look like (which of course isn't valid NETCONF/YANG today):

<filter type="subtree-xpath">
  <te:te xmlns:te="...">
    <te:tunnels te:name="foo"/>
      <filter type="xpath" select="te:name = ../te:tunnels/te:tunnel[te:name='foo']/te:connections/te:connection/te:name)"/>

Any opinions on whether this would be beneficial or is this just reinventing the wheel?


On 11/10/2017 10:41, t.petch wrote:

Thinking laterally, this is a problem that DNS encountered a few decades
ago and solved, by allowing the server to include additional information
not specifically requested that the server can see is going to be needed
for the next step, so if the client asks only about a CNAME, then the
server can provide the relevant IP address as well.
I suspect that the current rules for Netconf do not allow the server to
send anything not explicitly requested, which is a shame (IMO).
The DNS approach works very well, in fact I do not think we would
survive without it.
Tom Petch
----- Original Message -----
From: "Igor Bryskin"  <> <>
Sent: Tuesday, October 10, 2017 2:35 PM
Hi Rob,
This helps a lot. What you wrote will work.
The only difference is that if we would have the "joimt with" clause as
we proposed, the server would be able to tailor the te-tunnel
presentation to the client's requirements, e.g. substituting the
connection pointers with connection bodies, while, according to your
suggestion, the server will provide the te-tunnel body as is, and then
augment it with the cobbection information, thus, leaving
for the client to "shuffle " the received data. But I do agree, this
would be a minor inconvinience for the client, the important thing is
that the client will get all the data in one piece.
Thanks a lot,
From:Robert Wilton
To:Igor Bryskin,
Cc:Per Hedeland,, <,> ,
Date:2017-10-10 06:41:04
Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
Hi Igor,
On 09/10/2017 23:11, Igor Bryskin wrote:

Hi Per,
This is a good news, but, please, help us out.
Consider, we have a node - "te-tunnel" - which among other attributes

has two key leafref lists:

1) each member of the 1st list points to a "connection" supporting the

te-tunnel. All connections supporting all te-tunnels are stored in a
single list of connections.

2) each member of the 2nd list points to a supporting "te-tunnel" -

the te-tunnel in question depends on. All te=tunnels including the
te-tunnel in question, are stored in a single list of te-tunnels.

The question: how the client can retrieve via a single request all

attributes of the te-tunnel in question along with all parameters of all
connections supporting the te-tunnel, but with just pointers to
supporting te-tunnels (so that the interested client can use the
pointers to retrieve full data via subsequent separate requests) ?
I think that it might be something like this (for tunnel name foo):
   /te/tunnels/tunnel[name='foo'] |
E.g. in English, this should equate to something like:
Return all information for tunnel foo AND ALSO
Return all information for all connections where the connection name
matches one of the connections listed in tunnel foo.

Likewise, how the client can ask for full data of the te-tunnel and

all supporting te-tunnels and just pointers for supporting connections?
If my xpath above is right, then this would be something roughly like
   /te/tunnels/tunnel[name='foo'] |
I'm an XPath novice, so the expressions might be wrong. might be useful. E.g. if
you can construct a simple XML instance tree of your data, you could
validate whether the XPath expression works.
I hope that this is of some help,

I really appreciate your help,
-----Original Message-----
From: Per Hedeland []
Sent: Monday, October 09, 2017 5:21 PM
To: Igor Bryskin
Cc: <> ; <> ; <> ; <> 

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


Just to be clear: what we're suggesting is that you can use the
already-existing standard NETCONF XPath capability to achieve the


result - see
On 2017-10-09 21:52, Igor Bryskin wrote:

I agree. For example, a leafref may point not to a singls entity, but

to a list of entities, and the client might want to expand all of them
into the joint get response.

*From:*Per Hedeland
*To:*Martin Bjorklund,

Bryskin,,, <,,> ,

*Date:*2017-10-09 15:12:22
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by


On 2017-10-09 19:13, Martin Bjorklund wrote:

Igor Bryskin  <> <> wrote:

Hi Per,
Basically, what we need is a way for a client to request something
like this:
get <XPath> joint with <XPath1, XPath2, ..., XPathn>

... which is what Per's expression does!  Note that "|" in XPath


But as Per explained, it only works in some cases (when the leafref
acts a "single pointer").

Well, that particular expression works only in that case - but since


is effectively the client that (perhaps based on the data model)


what the leafref-leafs "mean" (in this case the single key of a


list), other cases can be handled the same way. E.g. multiple
leafref-to-key leafs that together give the keys of a multi-key list
just amounts to a slightly hairier XPath filter...

with a server interpreting the request as follows:
if a node pointed by XPath contains a pointer (e.g. key leafref)
matching one of the XPath from the "joint with" list, then the


must provide the entire body of the node pointed by the pointer,
otherwise, just the pointer (as it happens today, that is, when no
"joint with" list specified).
We think that this would allow for the client to optimize the


of request-response iterations depending on application/use case.


-----Original Message-----
From: Per Hedeland []
Sent: Monday, October 09, 2017 12:06 PM
To: Xufeng Liu
Cc: Igor Bryskin; <> ; <> 
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
I understand your use case, but a leaf of type leafref does not in
general identify a single node in the data tree - the leafref path
be for a non-key leaf, and/or the path could traverse list nodes,
the "target" list could have multiple keys and thus multiple
leafref-leafs be required to identify a specific list entry.
Thus it seems to me that your use case is not a reasonable basis

for a

new protocol operation. My XPath foo isn't very good either, but I


believe Robert's suggestion of using an XPath filter could be a way
forward. I *think* the filter expression would be something along


lines of
   /te/tunnels/tunnel[name='foo'] |


On 2017-10-09 15:42, Xufeng Liu wrote:

Hi Per,
*From:* Igor Bryskin []
*Sent:* Sunday, October 8, 2017 7:04 PM
*To:* Igor Bryskin  <> <>; <> ;
* <mailto:*> 
*Cc:* <> ; <> 
*Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed


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


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


*From:*Igor Bryskin
*To:*, <> ,
*Cc:*, <> ,
*Date:*2017-10-08 17:36:47
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
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


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,
*Cc:*,'NetMod WG',
*Date:*2017-10-08 14:01:27
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
On 2017-10-06 23:11, Xufeng Liu wrote:

During the design team discussion for TE and MPLS YANG modeling,


have received a request from implementers: How to minimize the


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


tunnel name, the get operation returns a list of leafrefs


to the paths of the tunnel.

Sorry, I'm afraid I don't follow. Can you explain exactly what


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


*operation, or the <get-data> operation described in
* and the


on {+restconf}/ds/<datastore> described in*
*/ /*
*/We have a list of leafref values because in this example model,


*tunnel contains a list of paths, each of them contains a leafref.


*get returns a value for each instance of such a leafref,
which (as a string value) will be used as a constraint (foreign


to retrieve the instance of an explicit-path in the model above./*
JFYI, in case there is some fundamental misunderstanding here: a


type leafref has a single value - *one* of those that satisfy the
constraint, in case there are multiple "candidates".

The client needs to issue at
least one more get operation to retrieve the path information


the given tunnel. The request is to combine these two operations


In the RDBMS SQL world, join can be used when SQL select is
performed, but NETCONF/YANG currently does not have this


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


issue. Is it acceptable to add a new operation to achieve such a
<get-data> operation with expanded leafrefs?
Comments and suggestions are appreciated.
- Xufeng
netmod mailing list <>   <> <>

Netconf mailing list <>   <> <>

Netconf mailing list <>

netmod mailing list <>


netmod mailing list <>