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