[i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
Kent Watsen <kwatsen@juniper.net> Tue, 14 February 2017 03:02 UTC
Return-Path: <kwatsen@juniper.net>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D611A1294CC; Mon, 13 Feb 2017 19:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.789
X-Spam-Level:
X-Spam-Status: No, score=-3.789 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_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 hPl6mCCWyk4Y; Mon, 13 Feb 2017 19:02:24 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0114.outbound.protection.outlook.com [104.47.41.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B698C1293F3; Mon, 13 Feb 2017 19:02:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hLkIyLOuu8Z6/2uOqj+UD7smsePCHxed3zy4DZeheWM=; b=d609NY3+G0oWuzYbrEjBn1kKA+q+M0KHx5MpwNCVTf3a43GIs+0k5gPJ/yvbMPqbudiihFjULguvZmo5NhKoRRFvhgunV2lf50v54mQU+WUsFXXNNDUvFQ2oclApy2/z91wWePJxc8DVBAwb9CzCGFr2J2d1/7CMvV0QpyQYYfA=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 14 Feb 2017 03:02:22 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0919.011; Tue, 14 Feb 2017 03:02:22 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "i2rs@ietf.org" <i2rs@ietf.org>
Thread-Topic: modeling options for draft-ietf-i2rs-yang-network-topo
Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9g==
Date: Tue, 14 Feb 2017 03:02:22 +0000
Message-ID: <AA7FA7D3-ED7B-4482-BBAC-7144E4944D92@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1e.0.170107
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: 02dbe24f-0457-4317-5611-08d45485e5db
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1444;
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:aSi0uQhztQPy0I00bJszzc0Ck0iOieRDyTThXZ+zwiHDghWuKuWmpQf7xIeUczeJ8tP4Q50tO5wO7Ru7+YMEj/dHeeEJyMDPoELOVPumEDvMMQR8nrBrV3MCnoB1eCI5HPrPqp8Jum4YmeWzH6ECbt8mK9R3xlFebHni3IE4k54tQ7x/UzFtzb9seJNrrfKU40reqr9qpBxnqtaPoE/ve40oBcpRyJiJUwevqqfhVuB7wdNAOaEXAWRB4CR/d0W/h31L5CXkUveaHDImUck/FQoogl/oSwzeDMsqnXjK9dbczGJdh2JirGdI/h2P3ucJT3bJN08ffM0GF2zNJohZUaCbo1JfFi5TBrEKuTtLKi4FP41X1V/cOD9lB22dmmT0IyX6wS8JfyGDa+3qwNVWAlf6/5qOT0FSIenlAMAdSZkDFKywyfYBePB/+o8wPBuKIpw15fVr+kohadTS4gBNz7unEal74it6jYTxiYQOjJUYG4ILaURjMELnHGJ7VoDqbFKZy4f0t5ylzlHXx48SYA==
x-microsoft-antispam-prvs: <BN3PR0501MB14449C1D1A10345829CE9440A5580@BN3PR0501MB1444.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444;
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39410400002)(39850400002)(39450400003)(199003)(189002)(52314003)(53754006)(6512007)(25786008)(6436002)(6306002)(6506006)(54356999)(5640700003)(99286003)(101416001)(83716003)(7736002)(6486002)(305945005)(83506001)(82746002)(50986999)(77096006)(6916009)(4001350100001)(3280700002)(86362001)(2906002)(53936002)(38730400002)(3660700001)(2900100001)(450100001)(122556002)(33656002)(97736004)(110136004)(4326007)(8936002)(8676002)(92566002)(81166006)(230783001)(81156014)(189998001)(66066001)(36756003)(68736007)(3846002)(102836003)(6116002)(2351001)(105586002)(106116001)(2501003)(5660300001)(106356001)(81003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.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: <067BE61197D8D34584B8EBC789B28B00@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 03:02:22.8722 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/U-7WmZk5aVRT79zW4DL1xiNBWiU>
Cc: yang-doctors <yang-doctors@ietf.org>
Subject: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2017 03:02:27 -0000
Hi All, It's been quiet on the list as a small group of us (Alex, Xufeng, Pavan, and myself) went offline to discuss for a bit before bringing back to the group, which I'm doing now. Regarding resolving the modeling the issue, we went through nearly a dozen ideas that we've narrowed down to two. We discussed the pros/cons, but since we each emphasize different values, we were unable to reach a consensus amongst ourselves. We're hoping that bringing the discussion here will bring more perspectives and resolve this issue. OPTION 1: separate /foo and /foo-state trees -------------------------------------------- This option was/is described here: https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. PROS: a) does NOT break legacy clients (how we got here) b) consistent with convention used in many IETF modules c) able to show if/how opstate may differ from configured values CONS: a) questionably valid YANG leafref usage b) complex server implementation (to handle require-instance false) c) eventually the module would need to migrate to the long-term solution, which would result in needing to also rewrite all modules that have augmented it (e.g., ietf-te-topology). d) leafref path expressions really only work for configuration data, though a clever server could have a special ability to peak at the opstate values when doing validations. Of course, with require-instance is false, the value of leafref based validation checking is negated anyway, even for config true nodes, so this may not matter much. OPTION 2: explicit client-option to also return tagged opstate data ------------------------------------------------------------------- This option takes a couple forms. The first is module-specific and the second is generic. In both cases, the idea is modeled after the with-defaults solution (RFC6243), wherein the client passes a special flag into <get-config> causing the server to also return opstate data, having a special metadata flag set, intermingled with the configuration data. 2A: Module-specific version module foo { import ietf-netconf { prefix nc; } import ietf-yang-metadata { prefix md; } md:annotation server-provided { type boolean; } container nodes { config true; list node { key "name"; leaf name { type string; } leaf dependency { type leafref { path "../node/name" require-instance false; } } } } augment /nc:get-config/nc:input { leaf with-server-provided { type boolean; } } } For instance: <get-config> <source> <running/> </source> <with-server-provided/> </get-config> <data> <nodes> <node> <name>overlay-node</name> <dependency>underlay-node</dependency> </node> <node foo:server-provided='true'> <name>underlay-node</name> </node> </nodes> </data> PROS: a) does NOT break legacy clients (how we got here) b) having all data in one merged tree is simpler to process than two separate queries. c) module doesn't have to be rewritten for revised-datastores; the 'with-server-provided' switch would just not be passed by new opstate-aware clients. CONS: a) inconsistent with convention used in many IETF modules b) unclear how to model 'with-server-provided' for RESTCONF (just use a description statement to define a query param?) c) unable to return the opstate value for any configured node (is it needed here?) d) requires server to support metadata, which is a relatively new concept and maybe not well supported by servers. e) only changes presentation-layer (doesn't change the fact that 'server-provided' data is not configuration), thus the leafref path expressions still don't work quite the way as desired, though a clever server could have a special ability to peak at the opstate values when doing validations. Of course, with require-instance is false, the value of leafref based validation checking is negated anyway, even for config true nodes, so this may not matter much. 2B: Generic version The generic version is much the same, but rather than letting the solution be limited to this one module, the idea is to generalize it so it could be a server-level feature. Having a generic RPC to return data from more than one DS at a time was something that was discussed ~1.5 years ago when we were kicking off the opstate effort. The PROS and CONS are similar, but there are additional CONS in the generic case. The main ones being 1) how to simultaneously return both the config and opstate values for a node (split at the leaves) and 2) how to handle some YANG statements such as presence containers and choice nodes. For this reason, (2B) is NOT considered a viable solution and is only here so that it's clear that it was discussed. If there are any other options people want to suggest, please do so now! Thanks, Kent
- [i2rs] modeling options for draft-ietf-i2rs-yang-… Kent Watsen
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Martin Bjorklund
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Kent Watsen
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Robert Wilton
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Martin Bjorklund
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Alexander Clemm
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Martin Bjorklund
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Alexander Clemm
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Martin Bjorklund
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Alexander Clemm
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Kent Watsen
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Martin Bjorklund
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Xufeng Liu
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Xufeng Liu
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Susan Hares
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Susan Hares
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Xufeng Liu
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Susan Hares
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Martin Bjorklund
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Xufeng Liu
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Xufeng Liu
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Martin Bjorklund
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Kent Watsen
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Susan Hares
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Kent Watsen
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Andy Bierman
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Martin Bjorklund
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Susan Hares
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Martin Bjorklund
- Re: [i2rs] modeling options for draft-ietf-i2rs-y… Susan Hares