Re: [netmod] Retrieving Information Pointed by leafref

Kent Watsen <kwatsen@juniper.net> Fri, 06 October 2017 21:51 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 6CE1513239C; Fri, 6 Oct 2017 14:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-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 jdJDIhDsMtR8; Fri, 6 Oct 2017 14:51:29 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0097.outbound.protection.outlook.com [104.47.34.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A70C124F57; Fri, 6 Oct 2017 14:51:29 -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=0LFV3z6TsVJNBadER+j/hu1r1GK8L5mDxFGEDdXuL48=; b=C6MUoGq8M6BvkPaQcGRyMgMzC0sNNboH+zS/dPtW7F7JwXhZL9mAqSg4D9gLl34coL0ZYuLtsL0VLBZ2fWYYk/4Ag6AFu1QkckX31ZLOU4jTxFQte9jIBQ8zJXN4VE7fjjAyFAu6lfkNT+l/Oklg922Ym/7S1Mp850cD9YOW5tU=
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:51:27 +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:51:27 +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//yKSA
Date: Fri, 06 Oct 2017 21:51:27 +0000
Message-ID: <277614BE-7ECA-409C-B817-83464860CE05@juniper.net>
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>
In-Reply-To: <033601d33ee7$bd359810$37a0c830$@gmail.com>
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:T6GSmLc4Y1KgNBhMjcv+MueWDBB78k+AKk4uv0KMzcagHvUQ/EhvUwaBV2ZDM3ig5yBlgA7XwV+pFoUbVayvaDZ/6/6wJ+5syV3WXLEP5ZnNUBCCK53rxXKSiHV3xxEJowc2PQmNUS9p7QdniTya4Dvf+1cncZHO16V03eYhavYdtPWTA1oGi1/ssM0MukC2+fY41UsqT71aKmtqGbkxNSmZKqIxyzcj5qDAc0MX6TlNnEgUoIfhiPCbDEhir3v9nR/z0qDGoxHp73QlywIiw8P6MsnRPn62DR9rbgEbQ9cLe+bsi338O/7/+pvmP8Q6Z4GYvgp1nA5mnUR3fOISDA==; 5:gn1qioeD0qVj0k09NcVpDHj6P3daFAZu8TG51BEk1Bs2KmtAEVAU4pN6R8q037/MICyk8WIZNTnsPcKCSYrQfOYGZ8mrRkPsLoee5pmyMmcc+INPaJCrRIAj09gP+1oN+wJbVkDyu/2d0TWXpaR2Fg==; 24:jOz6u8NMG596nyNe6W/K7M3bYmMdOpYMh3X8c30hexdNAkngZUTB91HOP2Efnu9froxU6jWcUS1MElS+x0tkyKyA7KzGKt+Lx8wViQvIIZM=; 7:s8yfRJE6+5Q/jfNmrCm/7/J7vW7JrS7AU/28Mg81AZrynkSpA9/pGj7+z5qN/Ynn8HGNI3GUPrxeudpt4/k4G7JoUq8rGrAd9rADlARhgyiRwLNv6zH9sHIHthu4TOdVgYcacaNvVknxmI8IN5tjn/GuzT46F61asv40upqyEnnpQ2HbsRy2ab9w7iZrPiJCH+aQWrRIYawFqoS/uq07pOkPfW2WcHAaXKdw3pNuLZk=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: dfc2d85f-a71b-434a-377c-08d50d04657a
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:(21748063052155);
x-microsoft-antispam-prvs: <BLUPR05MB2731484A8C5E3A3825164F2A5710@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)(346002)(376002)(39860400002)(377454003)(199003)(24454002)(189002)(101416001)(6246003)(86362001)(105586002)(82746002)(66066001)(83506001)(14454004)(106356001)(39060400002)(110136005)(33656002)(58126008)(3280700002)(2950100002)(3660700001)(68736007)(2501003)(83716003)(316002)(36756003)(5660300001)(189998001)(7736002)(6436002)(6506006)(2900100001)(6116002)(478600001)(3846002)(102836003)(25786009)(50986999)(76176999)(54356999)(2906002)(236005)(53936002)(6306002)(99286003)(54896002)(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: multipart/alternative; boundary="_000_277614BE7ECA409CB81783464860CE05junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2017 21:51:27.5081 (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/HiTIumIW57UK0-LvoUlbtIZHGbA>
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:51:31 -0000

My experience is that clients get the entire config in one call, and then can perform such resolutions locally.

BTW, really long relative paths are harder to read than an absolution path.
../../../../../explicit-paths/explicit-path/name
On 10/6/17, 5:11 PM, "netmod on behalf of Xufeng Liu" <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org> on behalf of xufeng.liu.ietf@gmail.com<mailto: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