Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
Martin Bjorklund <mbj@tail-f.com> Tue, 14 February 2017 16:41 UTC
Return-Path: <mbj@tail-f.com>
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 AC4ED1293DC for <i2rs@ietfa.amsl.com>; Tue, 14 Feb 2017 08:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AMLHh6tcnsPX for <i2rs@ietfa.amsl.com>; Tue, 14 Feb 2017 08:41:08 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C48E5128E19 for <i2rs@ietf.org>; Tue, 14 Feb 2017 08:41:07 -0800 (PST)
Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id CF46A1AE034F; Tue, 14 Feb 2017 17:41:06 +0100 (CET)
Date: Tue, 14 Feb 2017 17:41:06 +0100
Message-Id: <20170214.174106.332845199336010868.mbj@tail-f.com>
To: kwatsen@juniper.net
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net>
References: <AA7FA7D3-ED7B-4482-BBAC-7144E4944D92@juniper.net> <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/W4SV2sgd-gF98O3PvRCaepzYr2A>
Cc: i2rs@ietf.org
Subject: Re: [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 16:41:10 -0000
Kent Watsen <kwatsen@juniper.net> wrote: > > > [moving yang-doctors to BCC] > > > >> 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 > > > > What does this mean? > > I'm referring to how the description statement explains that > the server may look to operational state in order to resolve > the leafref, which is to result in behavior similar to > pre-configuration in RFC 7223. Ok, I didn't pay close attention to the proposal in the quoted email. I would design this a bit differently. The config true leaf "dependency" should have a leafref to the config false node name, with require-instance false. The description should explain that the configuration item will be used by the server if all dependencies exist. When the configuration item is used, it shows up in the config false list. This way, the leafref usage is valid and straight forward. > >> b) complex server implementation (to handle require-instance false) > > > >Can you elaborate on this one? > > This is primarily a reflection of the CON listed above, in that > it seems that a server would need to have special handling for > when dependencies transition from being present to not-present > and vice versa, much like the code to handle when a physical > card is plugged in or removed. Yes, but I think this is inherent to the problem at hand. Even with the config true solution defined in the current draft, it is not clear how things that were created by the server would be deleted (if there were references to them). > Note: I should've listed this as a CON for OPTION 2 as well. > > > > >> 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; > >> } > >> } > >> } > > > > I don't think this solution is substantially different from the > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just moved > > a config false leaf to a meta-data annotation. This solution suffers > > from the same problems as the solution in > > draft-ietf-i2rs-yang-network-topo-10. > > There are two primary differences: > > 1) It doesn't break legacy clients The solution in the draft doesn't break legacy clients either - there's a config false leaf among the config true. No problem. > , because it requires the client to > explicitly pass a 'with-server-provided' flag in the <get-config> > request in order to get back the extended response. Likewise, it > doesn't break backup/restore workflows, as the server can discard > any 'server-provided' nodes passed in an <edit-config> operation. Huh? This goes against the defined behavior of 6241 + 7950. This is the main problem with the solution in the current draft. If a client sends a <get-config> for data in running, the server cannot send back data that is not in running. > Lastly, it doesn't break <lock>/<unlock>, as there is no comingling > of opstate data in the 'running' datastore. > > 2) It doesn't say anything about how the opstate data is stored on the > server. The opstate data is not modeled at all. This approach > only defines a presentation-layer format for how opstate data can > be returned via an RPC. The server is free to persist the opstate > data anyway it wants, perhaps in an internal datastore called > 'operational-state' or in an uber-datastore with the opstate data > flagged with a datastore='oper-state' attribute. Regardless, it's > an implementation detail, and the conceptual datastore model is > preserved. You are essentially defining a new operation, but do it by modifying the semantics of an existing one. I don't think this is a good idea; it is better to define a new rpc. /martin
- [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