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

["Acee Lindem (acee)" <[e-mail]>]

From: netmod <[e-mail]<mailto:[e-mail]>> on behalf of Andy Bierman <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 12, 2016 at 1:27 PM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[e-mail]<mailto:[e-mail]>>
Cc: netmod WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure



On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton <[e-mail]<mailto:[e-mail]>> wrote:


On 12/07/2016 18:05, Andy Bierman wrote:


On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton <[e-mail]<mailto:[e-mail]>> wrote:

Hi Andy,

On 12/07/2016 17:17, Andy Bierman wrote:


On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>> wrote:
Acee,

    I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

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


I would really like to understand what problem (3) is supposed to solve.
My personal view is that I think that it makes the models simpler, with less duplication.

E.g. I also see that it makes it easier for a client to fetch all of the information associated with a particular feature in a single sub tree rather that needing to merge data from two separate config & state sub trees.


This is your opinion.
I think separate makes it easier to read, especially if the monitoring data
is relevant regardless of how associated configuration was done.
This is easily achievable by filtering (e.g. only return config false leaves + config true structural nodes).



Filtering is not widely implemented or implemented correctly.

IMO it is up to the data model designers how they want to organize their data.
I have not heard any valid reasons why a generalized solution is even needed,
let alone why separate config and state needs to be avoided.

There is definitely value in having model conventions. One argument for collapsing the config and state is that once you have the implicit retrieval of the applied state, there is much less operational state that isn’t redundant.

There is also requirement #4 in https://www.ietf.org/id/draft-ietf-netmod-opstate-reqs-04.txt. However, I know you’ve never been a fan of this document.

Thanks,
Acee






Andy





Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary configuration mechanisms.
(e.g., the way the SNMP world has worked for 30 years)
I thought that it was config that was originally driving YANG because there is already a solution for state data (SNMP).  Hence, I would have thought that the most common case would be that YANG is used just for config, or config & state.  So, I think that it makes sense to optimize models for these scenarios.


This is marketing.
Do you have any technical arguments?
Yes, I gave them below: I don't see that merging config and state prevents entities from only monitoring state if they wish.

Thanks,
Rob





If you forbid separate monitoring subtrees and force the data to be co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.
Both datastore draft solutions allow for system created config entries.  So in both drafts the operational state datastore can instantiate whatever config nodes are necessary to parent config false state nodes.

I also don't think that separate monitoring subtrees are going to be banned, they should be used where appropriate.  It is just that it will be no longer be required to have separate state subtrees purely because of potential differences in the lifetime of config vs state objects (e.g. interfaces vs interfaces-state).

I would be very happy if "interfaces" and "interfaces-state" could be merged into "interfaces" as a new/updated interfaces YANG model that draft models could be updated to use.  I understand that would be a impactful change to make (but seemingly mostly on IETF models that haven't yet been standardized).  But I hope that we are going to have to live with the YANG model structure for a long time, and if we still have an opportunity to "fix" a fairly big wart then I think that it would be good to do so.


I can't say if the pre-provisioning model in ietf-interfaces should be generalized.
I have not seen any good general solutions for combining config and state.



Rob

Andy


  Why is that progress?


Andy






_______________________________________________
netmod mailing list
[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/netmod