Re: [netmod] Retrieving Information Pointed by leafref

Kent Watsen <kwatsen@juniper.net> Fri, 06 October 2017 21:57 UTC

Return-Path: <kwatsen@juniper.net>
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 6A1F9133090; Fri, 6 Oct 2017 14:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 uf6aXb2b0sMz; Fri, 6 Oct 2017 14:57:40 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0105.outbound.protection.outlook.com [104.47.42.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86D713239C; Fri, 6 Oct 2017 14:57:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cPok1KRDHSJkgqYKXwslqDQglP22TwAULRyG/MbVLiU=; b=DC5Xg8wEE4zoPApOTQaWxvVlprURUb3DTrDPCaerhB986q7b/7MhNnrpi+DGwIkZ80KGj5fZG3BFUhKBW3zKkRwY3CahuL2oiaoSJnmYWgluFY01/D7PFRKdiRdQMCVEyLSO+TeSdnef1wAnTBu5lKmA98iyZtzEvPdzV7f1a6E=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB273.namprd05.prod.outlook.com (10.141.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 6 Oct 2017 21:57:38 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.026; Fri, 6 Oct 2017 21:57:38 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>, 'NetMod WG' <netmod@ietf.org>
Thread-Topic: [netmod] Retrieving Information Pointed by leafref
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/v//yKSAgAABvQA=
Date: Fri, 6 Oct 2017 21:57:38 +0000
Message-ID: <A0D27483-4417-4696-B366-D472E7A6B6E1@juniper.net>
References: <033601d33ee7$bd359810$37a0c830$@gmail.com> <277614BE-7ECA-409C-B817-83464860CE05@juniper.net>
In-Reply-To: <277614BE-7ECA-409C-B817-83464860CE05@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:67R7Yt4FxHgdVZCl2vKYTWJDBHgkFByMoPAOgevaI0Qud83gPn3V7QaiDffND3PoMfLyhbpUDQ5Yn0PMGXQqerzm3rvJwgB3xattlBzu3UUUmOrmkAkKQtriF4T20JLvEHzDQShDc9ASeYjU1Braun/m6yusFJ8yn2gvGS3vDiXIV5Ikj9FDFlSO2VPVw68XUuejy2+cQPqqsPzrFn8CnfFJXrLaFjq13AbGiznWffSVZV0fPQio/31N1ooyxUBxStmyVhYlD5VJnuSVC+fW7wMLKY6j7zu4xklSWEAzZCYgiiEiO/VKACFKVLlfGzwox5feF0taa/uV4rkcXWLT1A==; 5:+ZEUSRwWilFRR9aPO3eH6b89j16tC18JXJ7wUxrS7O4vGHShO/hsQgKgdy9ppZivO9Vi29NYwfmKuc9jYgb97cENqd7E31hIlr0lPqsbcr11o8piSrUqpqRgYghlQUNKTPl8m6IvCtwx14CzqYz/5g==; 24:Iig1m1tc/IxWlpX9kSgrm7VwlXKvq6j+D1ipu11tDC73fXgYOePjANzWx0I0p0WsL6vuaOo+P0Cbq60NCU/782hygTuAdGQZbSHq5OBDwH0=; 7:1PecZBqiEB3u4Ev2JD0dYxiWixFCJ3UjtnN2PjzCMNPhyV6D9yJGv9EjwUh/C4loWO8a3Ws76QN0nRrCto6riAHdKAifSD59fipFuBgXUCIVhiu+Wr5AQKIMrdse8OP4hL2PK5ulq5S9q29S9mwMP+6dMnZePCDALjzABEDPJDuXgfx+xE7sKKROykNK4YczJ9zuUEiyIKWBOiXjsDaSF9DjGsXsTUjPhSR34jHepnA=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 695df127-03a6-48c8-53b0-08d50d0542c6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB273;
x-ms-traffictypediagnostic: BLUPR05MB273:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: <BLUPR05MB273B17132224FA5C6B128E6A5710@BLUPR05MB273.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(12181511122)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB273;
x-forefront-prvs: 0452022BE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(377454003)(199003)(24454002)(189002)(101416001)(6246003)(86362001)(105586002)(82746002)(53546010)(66066001)(83506001)(14454004)(106356001)(39060400002)(110136005)(33656002)(58126008)(3280700002)(2950100002)(3660700001)(68736007)(2501003)(83716003)(316002)(36756003)(5660300001)(189998001)(7736002)(6436002)(6506006)(2900100001)(6116002)(478600001)(305945005)(3846002)(102836003)(25786009)(50986999)(76176999)(54356999)(2906002)(53936002)(99286003)(97736004)(8676002)(6512007)(77096006)(6486002)(229853002)(8936002)(81166006)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB273; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <927BF3AE8C95244094D04DCE9EC665F0@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2017 21:57:38.7678 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/BTK5eOgOSMKT-Q0eqzRKT1cSwu0>
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: Fri, 06 Oct 2017 21:57:42 -0000

[Sorry, fat-fingered the send button]

Here's how the paths might be altered:
-  ../../../../../explicit-paths/explicit-path/name
+ /explicit-paths/explicit-path/name

Back to your question, I guess that something could be done, but I'm unsure if how important it would be relative to other work going on in the NETCONF WG.  It will be interesting to see what other opinions are.

K. // contributor




On 10/6/17, 5:11 PM, "netmod on behalf of Xufeng Liu" <netmod-bounces@ietf.org on behalf of xufeng.liu.ietf@gmail.com> 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 tunnel’s information based on the tunnel name, the “get” operation returns a list of leafref’s pointing to the paths of the tunnel. 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.
We’d 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 leafref’s?
Comments and suggestions are appreciated.
Thanks,
- Xufeng