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

Balazs Lengyel <balazs.lengyel@ericsson.com> Tue, 02 August 2016 16:41 UTC

Return-Path: <balazs.lengyel@ericsson.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 9589012D096 for <netmod@ietfa.amsl.com>; Tue, 2 Aug 2016 09:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.487
X-Spam-Level:
X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 ZQssaRfLdxTw for <netmod@ietfa.amsl.com>; Tue, 2 Aug 2016 09:41:01 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA80F12D0D3 for <netmod@ietf.org>; Tue, 2 Aug 2016 09:41:00 -0700 (PDT)
X-AuditID: c1b4fb3a-0618b980000009bd-74-57a0cd1a1f22
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id FB.9A.02493.A1DC0A75; Tue, 2 Aug 2016 18:40:59 +0200 (CEST)
Received: from [159.107.198.46] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.301.0; Tue, 2 Aug 2016 18:39:57 +0200
To: Robert Wilton <rwilton@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Xufeng Liu <xufeng.liu.ietf@gmail.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> <044701d1e833$d7ec0380$87c40a80$@gmail.com> <3E6E6E31-953D-4C6D-B3E8-45020A027A78@gmail.com> <D3BE83EE.71EC9%acee@cisco.com> <7950d76e-9b2a-7f7f-2c55-05fce26af6ba@cisco.com>
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
Message-ID: <f3174c0e-1fb6-d5ed-c455-067f7850f649@ericsson.com>
Date: Tue, 02 Aug 2016 18:39:57 +0200
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: <7950d76e-9b2a-7f7f-2c55-05fce26af6ba@cisco.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM2K7rq702QXhBh9/MlpMfjuP2eL0m3Vs FvMvNrJanDjXx2xx5fgfJgdWjym/N7J67Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZx14/ YS/oP85UcWiTSANjwxLGLkZODgkBE4l1ix8zdTFycQgJrGeUmLtuAQuEs5pRov/CerAqYYEo iWvXXjGDJEQEljNKPOy9ANWyn0XiftNSZpAqZgF5iSMvlzGB2GwCRhJT+8+zgNi8AvYS7zb3 gNksAioSPd83snUxcnCICsRIrO9LgCgRlDg58wlYCaeArcTxzgYWiJH6Etfv3GeFGd+8dTbY KiEBDYmHF/6yTmAUmIWkfRaSlllIWhYwMq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECAzi g1t+W+1gPPjc8RCjAAejEg+vQt/8cCHWxLLiytxDjBIczEoivD2nF4QL8aYkVlalFuXHF5Xm pBYfYpTmYFES5/V/qRguJJCeWJKanZpakFoEk2Xi4JRqYJzbltH3dMPJcMZLpg8WhSuJi1wo 3Ckwd392m7DpV+2XHjOdncvupX8/3W845UWi9z/Z6fc9/vsZq+turbuk8WvqU8tPMT39pp6t vuz+7uvUWflsVKNYvzKHuOXJWNgJT53dZD3FcFnyE32eoqsHvQ8qHpu+slz/l9TCXQ98Mv53 LDObn5yVo8RSnJFoqMVcVJwIAKoUGqJeAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/QjhecILjhp5QrG-9HQKCqUocq34>
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: Tue, 02 Aug 2016 16:41:03 -0000

I don't know if we can make them a rule, but IMHO single-rooted modules are definitely easier to use. E.g. just as a single example: we only need one set of access control rules. Similar double handling is needed often.  I don't like foo-state trees.

Balazs


On 2016-07-28 17:00, Robert Wilton wrote:



On 27/07/2016 20:44, Acee Lindem (acee) wrote:


From: netmod <netmod-bounces@ietf.org> on behalf of Mahesh Jethanandani <mjethanandani@gmail.com>
Date: Wednesday, July 27, 2016 at 9:07 PM
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Cc: netmod WG <netmod@ietf.org>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Robert mentions IS-IS, and if I look at OSPF, I see a clear separation of rw and ro nodes. 

Right - and this separation is based on the routing and routing-state split in the ietf-routing-cfg model. In general, ietf-routing-cfg specifies that all control plane protocol YANG models should adapt this structure. Anyone who thinks collapsing all the models one config/state tree is simply a matter of moving a few counters should taking a better look at the existing drafts. I outlined the options in the E-mail thread prior to IETF 96.  Now, with the context of IETF 96 behind us, I believe more NETMOD participants will understand the options. To review the options specified in the previous E-mail thread. 

   1. Do nothing - allow them proceed as they are with multiple ways of
       representing the applied configuration. This would provide visibility to
       the data independent of whether or not the device supported the revised 
       data-stores supporting implicit retrieval of the applied configuration.
   2. Prune out the redundant data nodes except those required as list
        keys, etc, since they can be obtained from the applied state data store.
  3. #2 plus collapse the config (read-write) and  system-state
       (read-only) into common containers. No more branching of
       <model-name>-config and <model-name>-state at the top level of the model.

Prior to IETF 96, I don’t believe we had selected a direction. However, I believe we agreed on option #1 in order to allow the publication of these models within the next year. We’d still be able to avail the benefits of applied vs intended configuration on network devices supporting these data stores.
My take is that I think that the leaning at IETF was towards 2.

I.e. I think that we ruled out 1.  I.e. the models must not have separate nodes to represent applied configuration because that will be solved by the datastore solution.

But it feels a bit inconsistent that the models don't need to have explicit leaves for foo vs foo-applied (because it will be solved by datastores), but the models do still need explicit leaves for foo vs foo-state (even though this could/should also be solved by an operational state datastore - noting that both draft-schoenw and draft-wilton propose a solution to this problem).

My preference, if we can get quick consensus would be to do 3, or if consensus is not possible for 3, then we should fallback to doing 2, as the next best option.  But whatever the decision, I favour agreeing a direction quickly so that the other WGs know what to put in the RFCs.

Thanks,
Rob


Thanks,
Acee 





On Jul 27, 2016, at 11:22 AM, Xufeng Liu <xufeng.liu.ietf@gmail.com> wrote:

The assumption of “I suspect that all the routing models will be structured similarly” is not correct. Very few models in routing area structure this way.
 
Regards,
 
- Xufeng
 
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: Wednesday, July 27, 2016 1:05 PM
To: Kent Watsen <kwatsen@juniper.net>; netmod WG <netmod@ietf.org>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
 

 

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


 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" class="" rel="nofollow">https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani





_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod" rel="nofollow">https://www.ietf.org/mailman/listinfo/netmod



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod" rel="nofollow">https://www.ietf.org/mailman/listinfo/netmod

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com