Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
"t.petch" <ietfc@btconnect.com> Wed, 11 October 2017 09:43 UTC
Return-Path: <ietfc@btconnect.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 77D471331E7; Wed, 11 Oct 2017 02:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=btconnect.onmicrosoft.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 CsTEw5I6nAvv; Wed, 11 Oct 2017 02:43:35 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0134.outbound.protection.outlook.com [104.47.1.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97966128D0D; Wed, 11 Oct 2017 02:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z+kx4amaMVrw8oPFgP4087Vaw5vV9fRmmjJ/bM3lmUA=; b=ic9XKoPGDF20/LVTNJ7vaum0X34W7PhPCZZE/lp9mrPVFe5wWxavR2Ebwt6IaFBkazerfWEuP1DnvS7TKALgY/zsjGYWmGOe5aAS/cUSjmtHDxpgbozxyjFzxu4mDHL5m40Kl/Wbl9KGoJcvQYd2OIWymJP2C5ObMdEmWnvxfv4=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
Received: from pc6 (109.146.128.123) by HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 11 Oct 2017 09:43:31 +0000
Message-ID: <02aa01d34275$192f1840$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, rwilton@cisco.com
Cc: netconf@ietf.org, netmod@ietf.org
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com> <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com> <etPan.59dbd366.8bfdc1a.12f7@localhost> <a1af1cd1-9a61-9d1c-49d3-f1e031525f0a@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB9E2@SJCEML702-CHM.china.huawei.com>, <42819484-f9b5-4f06-dd58-23d9bc8c1ecc@cisco.com> <etPan.59dccc8e.149bf998.1428@localhost>
Date: Wed, 11 Oct 2017 10:41:10 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [109.146.128.123]
X-ClientProxiedBy: AM5P190CA0005.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:14::18) To HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 638d12da-f9c7-4f67-1ebd-08d5108c88d4
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR0701MB3003;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 3:P7t05Uzppd1CXrjuNlcoKCvSN+oY8P60r97E1NfDMuHZZVzFY7JnzoLRY/B1oFINcKndX4aFYgovi+EFZYMEKHfXNRDz2KYHzKdJiRlaVaWLh3yjEhQORGkQ99DOQ8slmGhoSUG2HidlTmpfh3NW/qt0O+jpBvg3OhGlYLW79MUoWqx8GGz2OAQRyDaJCQT1DJrbRwxHK2nx8IB9l7y3yEltDsL6fmuBl+JLw7donDdwuPJCKRI9Isu91sQfaBy9; 25:Fws6uM5yp4dsu7Spfb0PUOgQ3G+w6Nq80aF7oe/4sKbliHQaOyM4b7uy6cxW5zObsQeaGgg9Rdb/NAlnFFFQhG2UGdcCvAc4XAfhgZgLFnLyp/tX0kbmO7HEMGfYMfzZeI9nMYRv6BoCwzvfVow4aHS3ak47UKaNjgTG3TR4lFTEMvDAkCdF13a7/70a20ept5fuDI+1hUT/o5AiIydcx17D6uoBbWoo8YvAjNnA+jRooT71R3NOXYXzm6BeRJfaKV8jjHBoHwoLPpJW+ueetOFEEGgj58vuTYNl9qmppj9EwzMDPQc8v0Hwmu8XC2DCYUoZ3HvvAbDeU7jg5xb2jQ==; 31:UUJQ5nAFSHkJ2kAswt9oN41eBPyR+V4Lyhl5d7eDDU7zUNp/r4PzKO98Y3UudeLTHUoRsewL1NXqnymrW6v4LN9icHmRLersQXOckW2QaSvyJBImKJ/yJixzFCD3/B8IgIlhbCFFOk4I5YSxoKKhpyENerPilDD/z1ytUIwfC4anp5Ldc5raa9+ZNcvZLkuQJ9sxRx/tdM6+LgMYRGDKTUc0lrBlqbWaAgBuXZ3RUSw=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3003:
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(50582790962513);
X-Microsoft-Antispam-PRVS: <HE1PR0701MB300346E63C20C9CE1F4705A2A04A0@HE1PR0701MB3003.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3003;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 4:fHmJ407aviXIv+Vaj9qUaVxx/ZsHRWii9oKIDnkLliLsOJnmW13Z7cLhEnJ8swrHfbeCXU0AJGm3aV3wxbuHLkHi+V8q6chqHkhFFLcv+4XiCnOVNiDw08lR6Jrj1BxVKKPb2c78jyGW5JbcAf4kbRBv6ShQdVp16oZmmfM1rpdnceLwArPZyKWzM6vlNjLrPbe+hsVx47BogVsvPRQJGm8pRD8K4d3BD23bhDQM1uVWYW8rch7WH15mJaeIYlzIdd7inaJu3r7e5qnLPDWMFplJMDQivVl9DMhy9g54aqGyDQRq7LgkpXcl0GeN4XtW3DUZgEcNdlsHZV0I3KPHGw==
X-Forefront-PRVS: 0457F11EAF
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(51444003)(24454002)(60444003)(189002)(13464003)(377424004)(199003)(377454003)(105586002)(61296003)(966005)(44716002)(106356001)(14496001)(33646002)(110136005)(9686003)(97736004)(6306002)(50226002)(25786009)(4720700003)(101416001)(229853002)(316002)(68736007)(1456003)(4001150100001)(189998001)(50466002)(50986999)(93886005)(6666003)(86362001)(23756003)(54906003)(81816999)(76176999)(53936002)(81686999)(4326008)(6246003)(62236002)(16526018)(66066001)(84392002)(8936002)(5660300001)(81166006)(81156014)(8676002)(478600001)(6486002)(2906002)(2870700001)(7736002)(1556002)(6496005)(53546010)(116806002)(305945005)(44736005)(6116002)(47776003)(3846002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 23:Rs1Gosqh85SyHcjGHdaXwEktAmRFMx01Lf1klwrFPqmOOFcDvlaLfGZs/9O2vVEBp++Yv71i/NPQvgdqUkyVrVLH3OZw/tudn9lW24pVnRQqvFSddmz3GWFj+55actRvNq12H5q5s2irTOKEPTph8+uKSnjTIbC2lV/I+fgdUPfuPLQnMFSrtwCmw6s0GGqYnG2rnjKybJ+XVTojJI6MQ0ZUH1Aaek+fRWQ4E6b36aA+q0qNLALrjxDJJvJK1soUOC1j6iscl1XIqi8lPHpqiBM8ozihHhjW9nLaOCbXz1kIWKbe2d6Sy0gAv+4mGuey7vVJt/trBH1uHqGMQkuhOlOntIAQSo0LEF0CjqIX73d/rBdPYdqSvj4nGZ5XupIQ0CAVF1UnHGVS2Xtax7BNarPxLYgoU2Kb+mqUUlHwEXlTBTTUgMoISgjgImikwU/GWmr+0WU2NUFL4zm7r+aGjcFSJ2bVECH5dT6cLfogKPN2HJhqDbP1lezVXQ/qN2xWOp4xH129NUhv/Q9JydIF3C01xWXqDbwuBSCk4Lt8Ikf4yxxNrcADiyau+GjWeXDqa81U0pmabQgpDp1E3bfM4Yz/Mt4O0aGpQnlghFDM/kkWnykNL8nxpPmamkxU6qBPeKeznXACElCGI/EDTgyqneMpvnfyIyRm7pPwrAyb2VM9ICtLuHFMvq0k6RKx2PqMAAMWGwclcZDmu2X/aXg0HF8sgBvGauNIxNo9ktreY/xHODexa4d4f9rwNcsW4dH+Ii0iv+L/AY+uUr2C2+i8kU0L4yLN62+rZuftOY/btmW1bzFcr/6/D3B+QjEza4fXhUWtbQKTp4edIpVcTXujuIeasoI3VFfyATUTIRs/sm2fyuMPBKR+YBY8QlIdnkiYUGZS/vUD5mMsQsXAvXdBdFTq++ZnthO45lscB2/zq32nhkSuiD+0YOKq+x8tFpOluYL3iKWPaLem2r6ozMm7hIyeYrQs2AqtdJH75j8GzaeFYK4BIG/FDoSpWbPZO2w5+vy6iZw/wQ4LGIN1IINtjQ5rf4F8Fzgt9IXcbwlMPr24TSO/jNcor8k0Mr+kEcXHipk4YRmoEkTpBFaU0uyPicM9LsuScysp2ruS64Ebunkwsfo7B9Hyjq97SOS1ESgLPAmby4+AXsJncUSvQN5ABWS8ojBHRjfNBKTiEN0bMu0uyS7MgSU7vr73PzSe0nZ9aj53435++6YAx6HLAq9j08Lzo9Jjn3vAIpdDxcnpPzFDr5OvCyBbxMx147O5HZX7orAWWkj4Keg8FZluXTebPVU6PT4M9U7afRofopiVusupM3zfGHMHv7VE2K19y5oApZu14uqaDZu+yId2EYAE7nfeOeQvmVxZDdnwzDSR3NwuBKVIeJnp4Fvt7CjQx2FA7t3gmTmmRqw7Y8FZlcfB3z7lzduNliBj1ZMTyc90Zez8WWyRKISdTojQO9MI0dMm89mdsh5D4rdUFSofMOAI3mwyGFlZhuhnv2rIGRdN760OB+HKewkuBt+E060kfaq0kq8LLN37X8mNhilPSDM7ZmmA3YJQpe2nBTFofEvtLGNXUdQp2u7Yw3TEMaWF+DLUmf0odUGRRXaGu++9R8n+lA==
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:Ioh+mLqRSzJNBOmB2JG6ABxi0jcT03knwDmzwOHmu5xOWlKJjY19cKyijfBfA4UB0GbKZ37CfKi724hFe2YjOME4WYqgSvyan+p+zTH9dvIFX5tN7QQO3r58PQBdiwceemM++yBTlgDW3Io0NFjwoJp5p6HqCDRSYN05HeOGw3OmNKvXIzPVHi8V3gzOn/31eF1CPLhSET13dVgtlXtT/oAnodCuQ7P1thuyLCrKE9r2HbWShHIIPqFKevKdIXVE5KL24gQuyhoxeQM9htC1d/+LGxrkA4Ehf7lC0KkeXalrvk7liyI0licxZWj3taYyShopM3pxh39PK2Vbkk/X7w==; 5:sW3CgRE1gEY4Yk/dCrmoFFduqaJRKUNyqGMrMx+GxOLM7yjtk1vIKmW2nBn5e/pe1j/iSfk5fS17Ld7jE8p2BaFY7HVTBxt9TSljpOGQz1dORP5pCLmsc5Td7/r+OHgWZPU9udWQ4z9qSLZn9cVebdMUaauTuBqdwAPb0kb4VKI=; 24:SqP76PkPjdN2+5i5F8QPapbxHWgcYjzGe4u2EB1ce6wg5AU2Bin+S2fiVJjhsHWxekVcgargObMbQIMbacNHoSPKiCF5uEWRpQw1RyrHyzQ=; 7:yXlJYy0cTlhBsd06Pmom6CXhg7uLu17nycgf9jx6GelspSsM65hz3Zd9hQ9BO7qECGUMshoRjgklXlfSZ1BYXQoPC8aB1NFGkTF7jwXfLG0uQJSJfYxCbdUDiSYlKSndmVVbZF3Mp8pxeiVLHL8iJtsESeeZcQ7xDRWBJ6Cv/OXuFkqJkEebA8SNfj22C8HIHzab5ki4mzGyBPGugj6nMTi32RW4PL3QhFIJDcjDzv8=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2017 09:43:31.4236 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/JgqMQjIV1bwhuHao0rEcubSONi4>
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: Wed, 11 Oct 2017 09:43:43 -0000
Igor 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" <Igor.Bryskin@huawei.com> 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, Igor c From:Robert Wilton To:Igor Bryskin, Cc:Per Hedeland,netmod@ietf.org,netconf@ietf.org, 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'] | /te/connections/connection[name=/te/tunnels/tunnel[name='foo']/connectio ns/connection/name] 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 this: /te/tunnels/tunnel[name='foo'] | /te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnel s/supporting-tunnel/name] I'm an XPath novice, so the expressions might be wrong. https://www.freeformatter.com/xpath-tester.html 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, Rob > > I really appreciate your help, > > Igor > > > -----Original Message----- > From: Per Hedeland [mailto:per@tail-f.com] > Sent: Monday, October 09, 2017 5:21 PM > To: Igor Bryskin > Cc: mbj@tail-f.com; xufeng.liu.ietf@gmail.com; netconf@ietf.org; netmod@ietf.org > Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref > > Just to be clear: what we're suggesting is that you can use the > already-existing standard NETCONF XPath capability to achieve the desired > result - see https://tools.ietf.org/html/rfc6241#section-8.9 > > --Per > > 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. >> >> Igor >> >> *From:*Per Hedeland >> *To:*Martin Bjorklund, >> *Cc:*Igor Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org, >> *Date:*2017-10-09 15:12:22 >> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref >> >> On 2017-10-09 19:13, Martin Bjorklund wrote: >>> Igor Bryskin <Igor.Bryskin@huawei.com> 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 means >>> "union". >>> >>> 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 it >> is effectively the client that (perhaps based on the data model) decides >> what the leafref-leafs "mean" (in this case the single key of a single >> 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... >> >> --Per >> >>>> 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 server >>>> 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 number >>>> of request-response iterations depending on application/use case. >>>> >>>> Regards, >>>> Igor >>> >>> >>> /martin >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Per Hedeland [mailto:per@tail-f.com] >>>> Sent: Monday, October 09, 2017 12:06 PM >>>> To: Xufeng Liu >>>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org >>>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by >>>> leafref >>>> >>>> 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 >>>> could >>>> be for a non-key leaf, and/or the path could traverse list nodes, >>>> and/or >>>> 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 do >>>> believe Robert's suggestion of using an XPath filter could be a way >>>> forward. I *think* the filter expression would be something along the >>>> lines of >>>> >>>> /te/tunnels/tunnel[name='foo'] | >>>> /te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/pat hs/path/explicit-path] >>>> >>>> --Per >>>> >>>> On 2017-10-09 15:42, Xufeng Liu wrote: >>>>> 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>; 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 and the GET >>>>> *operations >>>>> on {+restconf}/ds/<datastore> described in >>>>> 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 >>>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > ------------------------------------------------------------------------ -------- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
- [netmod] Retrieving Information Pointed by leafref Xufeng Liu
- Re: [netmod] Retrieving Information Pointed by le… Kent Watsen
- Re: [netmod] Retrieving Information Pointed by le… Kent Watsen
- Re: [netmod] Retrieving Information Pointed by le… Per Hedeland
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Xufeng Liu
- Re: [netmod] [Netconf] Retrieving Information Poi… Robert Wilton
- Re: [netmod] [Netconf] Retrieving Information Poi… Per Hedeland
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Martin Bjorklund
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Per Hedeland
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Per Hedeland
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… Per Hedeland
- Re: [netmod] [Netconf] Retrieving Information Poi… Robert Wilton
- Re: [netmod] [Netconf] Retrieving Information Poi… Igor Bryskin
- Re: [netmod] [Netconf] Retrieving Information Poi… t.petch
- Re: [netmod] [Netconf] Retrieving Information Poi… Robert Wilton
- Re: [netmod] [Netconf] Retrieving Information Poi… Xufeng Liu
- Re: [netmod] [Netconf] Retrieving Information Poi… Robert Wilton