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

Ladislav Lhotka <lhotka@nic.cz> Thu, 28 July 2016 14:20 UTC

Return-Path: <lhotka@nic.cz>
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 C184D12D186 for <netmod@ietfa.amsl.com>; Thu, 28 Jul 2016 07:20:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.287
X-Spam-Level:
X-Spam-Status: No, score=-8.287 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, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 mScN5TA_ig3U for <netmod@ietfa.amsl.com>; Thu, 28 Jul 2016 07:20:42 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717EB12D58E for <netmod@ietf.org>; Thu, 28 Jul 2016 07:20:42 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:f15b:885a:a384:b102] (unknown [IPv6:2001:718:1a02:1:f15b:885a:a384:b102]) by mail.nic.cz (Postfix) with ESMTPSA id B3A3262F36; Thu, 28 Jul 2016 16:20:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1469715640; bh=5UM7pDdwz9lqha0EDWsRA8hKDApIV83JuEltqE3it4M=; h=From:Date:To; b=vVv+DnIjSqYTjF+ik5BzSP0SbDKb2fymSHuHRQ8ZQSiRlhphUURPF58t1Ae1sDNQv S7yeLyJ+mlEqWXlrdoiyyD36emM03Ri0JZI/+mwn1SnIIhr35gA7j9HIwlgrEy7Q5u 2CrrRCExkIP/FwVJeK15ASAC31lVWNRijfkEdfc0=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <D3BF8708.72620%acee@cisco.com>
Date: Thu, 28 Jul 2016 16:20:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <552008CB-F216-4578-A709-AE0613C2EFB9@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>
To: "Acee Lindem (acee)" <acee@cisco.com>
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/nEmXpRe4IR2yDAqoV4YsmpgXg34>
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:20:45 -0000

> 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.

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