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

"Xufeng Liu" <xufeng.liu.ietf@gmail.com> Mon, 09 October 2017 13:42 UTC

Return-Path: <xufeng.liu.ietf@gmail.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 0347A134540; Mon, 9 Oct 2017 06:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Y9Rd5x4QNFAb; Mon, 9 Oct 2017 06:42:19 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3425E134544; Mon, 9 Oct 2017 06:42:16 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id l194so13590015qke.13; Mon, 09 Oct 2017 06:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.55.142.5 with SMTP id q5mr9434836qkd.83.1507556535343; Mon, 09 Oct 2017 06:42:15 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id y63sm4795200qky.75.2017.10.09.06.42.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 06:42:14 -0700 (PDT)
From: "Xufeng Liu" <xufeng.liu.ietf@gmail.com>
To: "'Igor Bryskin'" <Igor.Bryskin@huawei.com>, <per@tail-f.com>
Cc: <netconf@ietf.org>, <netmod@ietf.org>
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>, <eac8b96e-227b-347f-9c02-81718918ed08@tail-f.com>, <etPan.59da9a33.12305c3a.3f7f@localhost> <etPan.59daaeb6.6daf0f5d.4ba3@localhost>
In-Reply-To: <etPan.59daaeb6.6daf0f5d.4ba3@localhost>
Date: Mon, 9 Oct 2017 09:42:14 -0400
Message-ID: <049501d34104$6aa46670$3fed3350$@gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/netmod/ehV6wfU9C2gYBBcsTHWDTjBPP88>
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: Mon, 09 Oct 2017 13:42:22 -0000

Hi Per,

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] 
Sent: Sunday, October 8, 2017 7:04 PM
To: Igor Bryskin <Igor.Bryskin@huawei.com>om>; per@tail-f.com;
xufeng.liu.ietf@gmail.com
Cc: netconf@ietf.org; netmod@ietf.org
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:per@tail-f.com,xufeng.liu.ietf@gmail.com,

Cc:netconf@ietf.org,netmod@ietf.org,

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

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

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