Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
Robert Wilton <rwilton@cisco.com> Wed, 13 July 2016 09:43 UTC
Return-Path: <rwilton@cisco.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 37B1C12D6B5 for <netmod@ietfa.amsl.com>; Wed, 13 Jul 2016 02:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level:
X-Spam-Status: No, score=-15.808 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 UYtK1m1XkZAm for <netmod@ietfa.amsl.com>; Wed, 13 Jul 2016 02:43:51 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A81512D5D6 for <netmod@ietf.org>; Wed, 13 Jul 2016 02:43:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16855; q=dns/txt; s=iport; t=1468403030; x=1469612630; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=tVRM3MrOZnF48W0yCDHI0+3lckvpgYvkyZ9J2ACW39k=; b=XV2VgXWPHciMbfgjBAIaCJp5m+YsSYMvwqNJAktw2UeZAVkMf8nBiWaV YQX+SVeacc80jOIEiFt1ugX8nmr20woAToR1EXhOaAYYiTQCSSG9iBQf5 EnBdGLEBqIand1cDauvRfYQfWUHAv20e13mpD3g8YAmEN2Ag9Tm76F/4Y Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CFCwBeDIZX/xbLJq1SBwOEFCpSs3aFBIF6IoUsSgKBaRQBAQEBAQEBZSeEXAEBBAEBAWUHEAkCCxAIJwcbDB8RBgEMBgIBARcDiAoIDr9iAQEBAQEBAQEBAQEBAQEBAQEBAQEBHAWGJYF4glWEGUkmhRQFmRyJC4VMgWuEWYMLI4U9kBceNoIJHIFNOzKJNwEBAQ
X-IronPort-AV: E=Sophos;i="5.28,356,1464652800"; d="scan'208,217";a="678240467"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2016 09:43:48 +0000
Received: from [10.63.23.50] (dhcp-ensft1-uk-vla370-10-63-23-50.cisco.com [10.63.23.50]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6D9hlsl016033; Wed, 13 Jul 2016 09:43:48 GMT
To: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, netmod WG <netmod@ietf.org>
References: <D3A935F0.6A4DC%acee@cisco.com> <02b5661f-22e0-6ccc-89d2-ef0370c4e87c@labn.net> <CABCOCHSH5wC3-VbAF6tXOc+3tSxpC3a0MA23YEkUFEBojoo25w@mail.gmail.com> <2b35a279-3c13-8b39-6e93-6c5e9d3ba2c2@cisco.com> <CABCOCHTOEY4dZM+bduWZ5N-k8dB_uO8=mdqtYQV0ktC6-TPyBw@mail.gmail.com> <3deb9416-e012-e8e3-43e2-be0d090a707a@cisco.com> <CABCOCHSnWaiUPqtpQpND0m3WYy6aYOTJJfJNEe5295bttuy_zw@mail.gmail.com> <D3AAA2CF.6B279%acee@cisco.com> <CABCOCHSa5ECo-j42uMFCqQOU7hUf4qYiDACu+269zd9Rgthafg@mail.gmail.com> <20160712190709.GA36335@elstar.local> <CABCOCHTSshuiihRkpzG=ppMROYcg0AFqtDM=t9A2==mT7gqvrQ@mail.gmail.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <0534179e-41f9-89a4-e8d7-f4c41cb6140e@cisco.com>
Date: Wed, 13 Jul 2016 10:43:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <CABCOCHTSshuiihRkpzG=ppMROYcg0AFqtDM=t9A2==mT7gqvrQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------640D3CBAC16679B46C9BF8BF"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/yfuQBqXkBPpY7nF0ZOp9a22l_Do>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 13 Jul 2016 09:43:53 -0000
Please see RW: inline On 12/07/2016 20:15, Andy Bierman wrote: > > > On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de > <mailto:j.schoenwaelder@jacobs-university.de>> wrote: > > On Tue, Jul 12, 2016 at 11:36:03AM -0700, Andy Bierman wrote: > > Yes there is value in modeling conventions in general. > > I am trying to understand the value of this specific convention. > > > > If I have an RPC that asks for applied state, then it doesn't > really matter > > how the config and state is organized. There is only overlap in > the objects > > if the data model is designed that way. > > > > Whether or not an edit is applied yet is a property of the > implementation, > > not the data model. > > The current /foo and /foo-state approach requires some amount of > duplication. If the trees contain some nested lists of lists, you have > to at least replicate all the key leafs in the schema definition. For > a small model, this is not a bit deal; for more complex models, this > becomes complex and there are possible sources of errors. If it is > possible to simply data models, this may be a long-term win. > > > > It only requires duplication if you insist on modeling opstate objects. > IMO an RPC + notification approach is far superior. RW: Are you thinking of a single global notification of convergence? Although such a scheme may be sufficient if the configuration is changing infrequently, it is not sufficient for a system in which configuration is changing frequently (e.g. say to provision very short lived tunnels across a data center network). If the client is interested when a particular config change has converged then a global converged flag: (i) may be delayed a long time (if at all) after the config change has completed (because other subsequent config operations are in progress) (ii) may be hard to relate back to the original config change Hence, I think that there are only 2 technical solutions to this problem: (a) reporting/notifying the state of the applied configuration nodes (as per the requirements stated in draft-ietf-netmod-opstate-reqs, and covered by the all the various solution drafts) (b) report the success/failure of the particular config operation. My opinion, is that as network configuration becomes more dynamic, and programmatically controlled then (a) is the easier solution and more robust to failure over (b). But both approaches can be supported by devices. > In this approach I only need to identify the intended config object > and retrieve (or be notified) of the applied-state transition. RW: This is only part of the solution, since metadata can only be used when nodes exist in the YANG data tree. So, this method alone cannot indicate configuration that is applied by the device and is in the process of being deleted. That is primarily why draft-wilton-netconf-opstate-metadata-00 offers metadata both on the "persistent" datastore and "operational state datastore". > > The reason why we have the /foo and /foo-state convention is, I > believe, the design of the NETCONF <get/> operation, which assumes > state and config can be represented together in a single tree. And we > have carried this further into YANG (e.g., the way contexts are > constructed for xpath expressions). In hindsight, I am not sure the > consequences of the <get/> design were that well thought through - but > I am not complaining, at that time we did not have YANG nor did we > have experience with bigger data models written in YANG. Is it worth > fixing it? This is a tough question and I understand that people have > different opinions and also different views on where we are on the > lifecycle of this technology. The challenge, as always, is to evolve a > technology along with its usage and upcoming new requirements. If the > evolution is too fast, you risk fragmentation since people will then > run many different versions. If evolution is too slow or stops > entirely, you pave the way for complete replacements of the > technology. > > I think it is worth to step back for a moment and to think about where > we like to be in 5 or 10 years from now when we discuss architectural > questions. > > > > We have read-only foo-state because we have only been standardizing > monitoring data for the last 30 years. I completely agree that if the > state depends > on the config in order for an instance to exist, then co-locate the > config and > state and share the node naming. > > > But modeling admin-state and oper-state with the same object is not a > requirement. RW: I agree, but when the oper-state exactly of a node reflects the applied admin-state then I see no benefit in having a separate duplicate "config false" node. Rob > Being able to determine if the intended config is applied yet is a > requirement. > This can be done with protocol operations so it is 100% data model > neutral. > > > > /js > > > Andy > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
- [netmod] OpsState Direction Impact on Recommended… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Rob Shakir
- Re: [netmod] OpsState and Schema-Mount Robert Wilton
- Re: [netmod] OpsState and Schema-Mount Ladislav Lhotka
- Re: [netmod] OpsState and Schema-Mount Alex Campbell
- Re: [netmod] OpsState and Schema-Mount Ladislav Lhotka
- Re: [netmod] OpsState and Schema-Mount Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Juergen Schoenwaelder
- Re: [netmod] OpsState and Schema-Mount Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Andy Bierman
- Re: [netmod] OpsState and Schema-Mount Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Ladislav Lhotka
- Re: [netmod] OpsState and Schema-Mount Andy Bierman
- Re: [netmod] OpsState and Schema-Mount Juergen Schoenwaelder
- Re: [netmod] OpsState and Schema-Mount Robert Wilton
- Re: [netmod] OpsState and Schema-Mount Robert Wilton
- Re: [netmod] OpsState and Schema-Mount Ladislav Lhotka
- Re: [netmod] OpsState and Schema-Mount Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Andy Bierman
- Re: [netmod] OpsState and Schema-Mount Andy Bierman
- Re: [netmod] OpsState and Schema-Mount Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Acee Lindem (acee)
- Re: [netmod] OpsState and Schema-Mount Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Juergen Schoenwaelder
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Robert Wilton
- Re: [netmod] OpsState and Schema-Mount Ladislav Lhotka
- Re: [netmod] OpsState Direction Impact on Recomme… Balazs Lengyel
- [netmod] OpsState and Schema-Mount Balazs Lengyel
- Re: [netmod] OpsState Direction Impact on Recomme… Balazs Lengyel
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState Direction Impact on Recomme… Juergen Schoenwaelder
- [netmod] Corollary to [OpsState Direction Impact … Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Lou Berger
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Ladislav Lhotka
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Ladislav Lhotka
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Ladislav Lhotka
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Ladislav Lhotka
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Mahesh Jethanandani
- Re: [netmod] OpsState Direction Impact on Recomme… Xufeng Liu
- Re: [netmod] OpsState Direction Impact on Recomme… thomas nadeau
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Alex Campbell
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Rob Shakir
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Juergen Schoenwaelder
- Re: [netmod] OpsState Direction Impact on Recomme… Lou Berger
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Lou Berger
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman