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

Ladislav Lhotka <lhotka@nic.cz> Thu, 28 July 2016 14:58 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 B6EBE12B042 for <netmod@ietfa.amsl.com>; Thu, 28 Jul 2016 07:58:29 -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 RHBYXFHmhd_8 for <netmod@ietfa.amsl.com>; Thu, 28 Jul 2016 07:58:27 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E7112B024 for <netmod@ietf.org>; Thu, 28 Jul 2016 07:58:26 -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 50D1C61EB6; Thu, 28 Jul 2016 16:58:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1469717905; bh=CNKwJC7Gczf95Zp6IUA1An7eyC1OQ9vSFdkW1LQg5Rg=; h=From:Date:To; b=xxlBSqItXnuMc1I43VjBww3K/ILRo5w8GSGtA1PS3vuFyw5e4DS8cYvvNjjkB8e4B 3ZkeiVgafMIItH4SLVPDk814posbT3AvO2t1pE4aA4ZWbh4DXSHDU1BO5lfGmPD4S5 pZJdTbRoq7VS8EykVG84P2sjTdyYWmW03HlNPNI4=
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: <D3BF9318.726F6%acee@cisco.com>
Date: Thu, 28 Jul 2016 16:58:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D143AD6-3062-4777-B0F8-81ACB655C32E@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>
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/ZdQPbMcioHHq9qEOr0W3ktaDfR4>
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:58:30 -0000

> On 28 Jul 2016, at 16:48, Acee Lindem (acee) <acee@cisco.com> 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.

Right. I believe the term RIB was originally coined for a data structure that was internal to BGP, so this sometimes causes confusion.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C