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

"Acee Lindem (acee)" <acee@cisco.com> Thu, 28 July 2016 15:38 UTC

Return-Path: <acee@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 C9A1012D0AE for <netmod@ietfa.amsl.com>; Thu, 28 Jul 2016 08:38:43 -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_H3=-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 qL5vaLLA9bsO for <netmod@ietfa.amsl.com>; Thu, 28 Jul 2016 08:38:41 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753B512B024 for <netmod@ietf.org>; Thu, 28 Jul 2016 08:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11298; q=dns/txt; s=iport; t=1469720321; x=1470929921; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ffHOn5hAb2tMd3jS+8tPLjLUoDW9rEykbHHkyx1ae+g=; b=BF4HRNPW9UF6zQ1SaO4cb9vId42azmuKSMT8Y6Nmsmp/QwXotUJ7jH/M rRJGuKFNsOyjAUjYqXcrlBH5IBZE4d7grmISL6TTfaQxqAR1OtAXhzK0H K40wCW1QMffcaRonHjde/bubWMJFYRYi5FFcJ8PVvSpETuBmD0YqWpdNv E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AvAgC3JppX/5RdJa1dg0VWfAa4b4F9JIUvSgIcgRc4FAEBAQEBAQFdJ4RcAQEEAQEBIRE6BAcQAgEIGAICJgICAiULFRACBA4FGQKIDggOrX+NVQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQGJdoQqFhcjgkeCWgWZMgGOfI8/jC6DdwEeNoISHIFMbogCfwEBAQ
X-IronPort-AV: E=Sophos;i="5.28,434,1464652800"; d="scan'208";a="129273571"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2016 15:38:40 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6SFce9F018438 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Jul 2016 15:38:40 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 28 Jul 2016 11:38:38 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 28 Jul 2016 11:38:39 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Thread-Topic: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
Thread-Index: AQHR25JaeXwJZYUBL0Wtuo0RKdx74KAt95XBgAABTICAAEmBAP//0qiA
Date: Thu, 28 Jul 2016 15:38:39 +0000
Message-ID: <D3BF9ED2.7273E%acee@cisco.com>
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>
In-Reply-To: <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.197]
Content-Type: text/plain; charset="utf-8"
Content-ID: <970A10F3B526FA4BB5BB86D7ADB17527@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/0Ck8JZcCC3SrLc_sfNuo6oYiCKQ>
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 15:38:44 -0000


On 7/28/16, 10:20 AM, "Ladislav Lhotka" <lhotka@nic.cz> 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.

Suffice it to day that in a combined tree there will be state that has not
corresponding config. For example, the populated global RIB instances
would fall into this category.

Thanks,
Acee 



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