Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Robert Wilton <rwilton@cisco.com> Thu, 28 July 2016 14:57 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 7494612D647 for <netmod@ietfa.amsl.com>; Thu, 28 Jul 2016 07:57:31 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 x3znByd9YE3D for <netmod@ietfa.amsl.com>; Thu, 28 Jul 2016 07:57:29 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E11612D606 for <netmod@ietf.org>; Thu, 28 Jul 2016 07:57:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10645; q=dns/txt; s=iport; t=1469717848; x=1470927448; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=56FsRH7J+y/a2mBF41EVvOvgiDxaVqyD9/LDK+O6GGM=; b=O44KtoiYYgTBFErIbg/mnMhwH5XOkYH5UYf2Mwi1w2bSB9TIsYdwIuNz fJwSA1TKM+ZKF8dA8qWHfmn+I0mjqjwVQrkXEfx16PfGkOgCjkw1SR1IE oxsDx/dQoq1GiF1tfi4IM/JtyL/8ovIiGWxDPO5Oq4P6ep2aC0d0WHNuL s=;
X-IronPort-AV: E=Sophos;i="5.28,434,1464652800"; d="scan'208";a="639777792"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2016 14:57:27 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6SEvQ2E013088; Thu, 28 Jul 2016 14:57:26 GMT
To: "Acee Lindem (acee)" <acee@cisco.com>, Ladislav Lhotka <lhotka@nic.cz>
References: <D3A935F0.6A4DC%acee@cisco.com> <eb15fd23-2c0a-50c4-1ebc-7c0e4867dfd8@cisco.com> <20160721174033.GB54646@elstar.local> <d18f5dd0-64d0-e223-88a9-faa4df4b7866@cisco.com> <DCB3EBBF-5EB1-4C8E-AA55-F59C4B5A8E4D@juniper.net> <bed9398c-0e6a-450e-d2ac-b381b6bebf87@cisco.com> <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com> <m24m79c1ja.fsf@birdie.labs.nic.cz> <D3BF8708.72620%acee@cisco.com> <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com> <D3BF9318.726F6%acee@cisco.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <ea2517cf-29a7-ca02-b96e-e74ea7fcc834@cisco.com>
Date: Thu, 28 Jul 2016 15:57:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <D3BF9318.726F6%acee@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/GB6S1ZJfzXtgBLryxKmacncvYW0>
Cc: netmod WG <netmod@ietf.org>
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: Thu, 28 Jul 2016 14:57:31 -0000


On 28/07/2016 15:48, Acee Lindem (acee) wrote:
>
> On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
> Cisco)" <rwilton@cisco.com> wrote:
>
>>
>> On 28/07/2016 15:20, Ladislav Lhotka wrote:
>>>> On 28 Jul 2016, at 15:57, Acee Lindem (acee) <acee@cisco.com> wrote:
>>>>
>>>> Hi Lada,
>>>>
>>>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
>>>> <netmod-bounces@ietf.org on behalf of lhotka@nic.cz> wrote:
>>>>
>>>>> Robert Wilton <rwilton@cisco.com> writes:
>>>>>
>>>>>> On 26/07/2016 21:36, Kent Watsen wrote:
>>>>>>> <Rob Wilton writes>
>>>>>>>
>>>>>>>
>>>>>>> So my thinking is that if we can't merge "foo-state" into "foo" then
>>>>>>> instead we should have consistent rules that explicitly state that
>>>>>>> for
>>>>>>> all IETF models "foo" and "foo-state" are separate trees with a
>>>>>>> consistent naming convention and structure.  That should hopefully
>>>>>>> allow tooling to programmatically relate the two separate trees
>>>>>>> together.  It may give a path to allow "foo-state" to be merged into
>>>>>>> "foo" in future, but once IETF has standardized 600+ models with
>>>>>>> separate sub-trees, I cannot see that they would get merged back
>>>>>>> together again.
>>>>>>>
>>>>>>> What other alternatives are available?  As a WG we need to tell the
>>>>>>> other WGs how the IETF YANG models should be structured.
>>>>>>>
>>>>>>> In short, unfortunately I think that we have probably already missed
>>>>>>> the opportunity to merge "foo" and "foo-state" subtrees together ...
>>>>>>>
>>>>>>> </Rob Wilton>
>>>>>>>
>>>>>>> Firstly, I’m trying to get a sense of how big a problem this
>>>>>>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
>>>>>>> counters, not opstate].
>>>>>>>
>>>>>> RW:
>>>>>> By counters, I think that we also mean any config false nodes that
>>>>>> don't
>>>>>> directly represent "applied configuration", right?  E.g. is an
>>>>>> interface
>>>>>> operationally up or down.
>>>>>>
>>>>>>>     I know about RFC 7223, which was done out of consideration for
>>>>>>> system-generated interfaces, but how many other such models are
>>>>>>> there
>>>>>>> envisioned to be?
>>>>>>>
>>>>>> RW:
>>>>>> - Any models that augment RFC 7223 and have config false nodes will
>>>>>> be
>>>>>> impacted.
>>>>>> - I thought that quite a lot of other IETF models that are in the
>>>>>> process of being standardized have a top level split between "foo"
>>>>>> and
>>>>>> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
>>>>>> has
>>>>>> this split.  I suspect that all the routing models will be structured
>>>>>> similarly.
>>>>> Correct. One reason is that the core routing model envisions
>>>>> system-controlled RIBs.
>>>>>
>>>>>> - Although it is perhaps worth pointing out that I think that the
>>>>>> OpenConfig modules effectively have exactly this same issue (e.g.
>>>>>> they
>>>>>> have a combined interfaces tree keyed by config true leaves), and
>>>>>> they
>>>>>> pragmatically just ignore the issue of system created interface
>>>>>> entries.
>>>>> The NETMOD WG considered this issue quite important in the past.
>>>>>
>>>>> My impression from the OpState discussion is that we are on the quest
>>>>> of
>>>>> the philosopher's stone, trying to find a shortcut where none is
>>>>> possible in general. The long session in Berlin concentrated on the
>>>>> life-cycle of a single parameter that's somehow configured, then
>>>>> manipulated, and eventually ends up as operational state. IMO this
>>>>> is too simplistic, the relationship between configuration and state
>>>>> can
>>>>> be much more complex. RIB is one example - it combines contributions
>>>>> from configuration (static routes) and derived state (routing
>>>>> protocols).
>>>> If one were to support the Applied-Config data store, it be comprised
>>>> of
>>>> only the current state of the configured static routes.  The complete
>>>> RIB
>>>> would still need to be accessible in separate data nodes.
>>> Yes, but I didn't talk about intended-applied. I understand that
>>> another goal of OpState is to unify config and (true) state and get rid
>>> of the foo and foo-state dichotomy in the data model. I am sceptical
>>> about it.
>> The goal is/was to unify where the only reason that they were split was
>> because the lifetime of the configured containing datanode may differ
> >from the operational containing datanode.  E.g. interfaces vs
>> interfaces-state was split to allow for system created interfaces that
>> were not configured, but other than this reason the split seems quite
>> artificial and not particularly helpful.
>>
>> OpenConfig is modelling interfaces and interfaces-state as a single
>> list.  It would be kind of helpful if IETF models and OpenConfig models
>> could be consistent in this regard, and I prefer the combined list
>> approach used by OpenConfig interfaces (on the assumption that we can
>> solve the technical problems associated with this approach - which I
>> think that we can).
>>
>> I've no particular issue with a RIB existing under routing-state. But
>> personally, if it was the ISIS specific routing table, I would prefer it
>> to be under a single top level ISIS container on the assumption that you
>> cannot really have an ISIS routing table if ISIS isn't actually running
>> on the device.
> Don’t confuse a global RIB instance with an IS-IS local RIB instance.
> These are separate tables (although the former may contain active entries
> from the latter) and both would be interesting from an operational
> perspective.
Sorry, I wasn't trying to -  I should have written "a global RIB" 
instead of "a RIB" ;-)

I am suggesting that a global RIB could reasonably go under a path like 
"routing-state/rib" (because it is not tidied to a particular protocol), 
but that the IS-IS specific RIB instance could go under 
"routing/isis/rib" (because it can surely only exist if IS-IS is running*).

*Note that I explicitly mean "running" here, as opposed to "configured", 
since both "opstate drafts" allow the operational state datastore to 
contain config true datanodes for things that are running but not 
explicitly configured.

Cheers,
Rob

>
> Thanks,
> Acee
>
>
>
>> Cheers,
>> Rob
>>
>>> Lada
>>>
>>>> Thanks,
>>>> Acee
>>>>
>>>>
>>>>
>>>>> After all, most real devices have some configuration mode and "show"
>>>>> commands. They are separate even though there is certainly some
>>>>> relationship between their data.
>>>>>
>>>>> Lada
>>>>>
>>>>>>> Is this issue currently blocking models from progressing, or are we
>>>>>>> getting ourselves wrapped around a hypothetical?
>>>>>>>
>>>>>> RW:
>>>>>> I think that it is blocking models from progressing.
>>>>>>
>>>>>> The current guidance for "intended vs applied" is clear.  I.e. there
>>>>>> must not be "config false" leaves in the IETF YANG data models to
>>>>>> represent "applied config".
>>>>>>
>>>>>> But there is no clear guidance for the rest of operational state that
>>>>>> isn't applied config.  The other WGs need clear guidance (effectively
>>>>>> now) to ensure that they can start publishing models as RFCs.
>>>>>>
>>>>>>
>>>>>>>    If RFC 7223 is an outlier, then we can address it as a special
>>>>>>> case
>>>>>>> (perhaps via the related-state/related-config YANG annotations).
>>>>>>> What
>>>>>>> do you think?
>>>>>>>
>>>>>> RW:
>>>>>> Personally, I would like one common convention that applies to all
>>>>>> IETF
>>>>>> YANG models.
>>>>>>
>>>>>> Idealistically I would like foo and foo-state to be merged because I
>>>>>> think that will make the models easier to use and maintain in the
>>>>>> long
>>>>>> term, but I don't know if we are just too late to go in that
>>>>>> direction.
>>>>>>
>>>>>> It seems to me that the NETMOD WG really should try to come to a
>>>>>> decision quite quickly on this, but I don't know how to encourage
>>>>>> that.
>>>>>>
>>>>>> A virtual interim on just this topic perhaps?
>>>>>>
>>>>>>> Next, regarding paths forward (assuming 7223 is not an outlier), I’m
>>>>>>> thinking the opposite.  I’m quite sure that we would never merge the
>>>>>>> 600+ models with separate subtrees back together again.  So I’m
>>>>>>> thinking we immediately merge foo and foo-state in all active YANG
>>>>>>> models (so that the YANG “conceptual” models are stable and good)
>>>>>>> *and* then we use your idea to programmatically generate the
>>>>>>> “foo-state” tree, presumably only when needed.  This foo-state tree
>>>>>>> could be generated offline by tools and provided as a second YANG
>>>>>>> module in drafts.  In this way, servers (opstate aware or not) can
>>>>>>> advertise if clients can access the foo-state tree (an opstate-aware
>>>>>>> server may still advertise it for business reasons, and it can
>>>>>>> ‘deprecate’ the tree when no longer needed).   We could do the same
>>>>>>> without tools today by just using a feature statement on, for
>>>>>>> instance, the interfaces-state container, but I like pushing for
>>>>>>> tooling upfront so that we’re guaranteed mergeability later.
>>>>>>> Thoughts?
>>>>>>>
>>>>>> RW:
>>>>>> So the generated "foo-state" tree would contain a copy of all config
>>>>>> false nodes in the YANG schema and a "config false copy" of any
>>>>>> config
>>>>>> true nodes in the YANG schema that are required to provide parental
>>>>>> structure for the descendant config false nodes.
>>>>>> - The Xpath expressions would also need to be adjusted, and possibly
>>>>>> some of those might break (or need to be fixed by hand).
>>>>>> - Groupings might be a problem, but potentially they could be
>>>>>> expanded.
>>>>>>
>>>>>> Technically this solution might work, but is it possible to get
>>>>>> everyone
>>>>>> to agree that this is the right direction to go in before we spend
>>>>>> time
>>>>>> on this?
>>>>>>
>>>>>> Thanks,
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>> Kent // as a contributor
>>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> -- 
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>> .
>>>