Re: [netmod] OpsState and Schema-Mount

[Ladislav Lhotka <[e-mail]>]

> On 10 Aug 2016, at 23:54, Alex Campbell <[e-mail]> wrote:
> 
> I think in this case it would make sense to implement both the hypothetical standard module's state data (which would be device-agnostic, such as a boolean value indicating whether each configured rule is active) and also a device-specific module providing access to the more detailed internal state.

Right, that's one option, but for smaller devices (which could be, e.g., OpenWRT routers) it may be an overkill.

If standard state data are in a separate module, an implementor can choose to implement them or not.

Lada

> 
> ________________________________________
> From: netmod <[e-mail]> on behalf of Ladislav Lhotka <[e-mail]>
> Sent: Wednesday, 10 August 2016 11:39 p.m.
> To: Andy Bierman; Robert Wilton
> Cc: netmod WG
> Subject: Re: [netmod] OpsState and Schema-Mount
> 
> Andy Bierman <[e-mail]> writes:
> 
>> On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton <[e-mail]> wrote:
>> 
>>> Hi Andy,
>>> I don't properly understand the points that you are making, please see
>>> clarifying comments/questions inline ...
>>> 
>>> On 08/08/2016 22:51, Andy Bierman wrote:
>>> 
>>> 
>>> 
>>> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <[e-mail]> wrote:
>>> 
>>>> Acee writes:
>>>>>   Then I see no YANG language barriers in collapsing config and state
>>>> trees
>>>>>   - the model root just needs to be “config true”.
>>>> 
>>>> Great, I think we’re all agreed.  Can we now discuss the text I proposed
>>>> for 6087bis?  - here’s the link to my proposal:
>>>> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>>>> 
>>>> 
>>> IMO this effort to avoid 2 containers is not well thought out.
>>> Some concerns:
>>> 
>>> 1) modularity
>>>    placing the monitoring objects within the configuration means the
>>> monitoring
>>>    cannot be used on its own
>>> 
>>> If it is one module with two top level augments (foo and foo-state) then
>>> this problem still exists.  Hence, please can you clarify why converging
>>> them on a single root node means that monitoring cannot be used on it own?
>>> Wouldn't a device need to use deviations in both cases to strip out the
>>> config nodes that they are not supporting?
>>> 
>>> 
>> Before the "rule" I can choose to place monitoring in its own module
>> without any reliance on other modules.  If the monitoring does not
>> share indexing, what value is there in putting it in the config tree?
>> I see none except a poor attempt at model classification.
> 
> Sometimes it may indeed make sense to keep configuration and state data
> schemas in different modules. For instance, it may be useful (or even
> necessary) to have common configuration but different state data for
> different implementations, e.g. when devices use vastly different
> internal architectures.
> 
> One example are packet filters: while it may be possible to have a
> common configuration for Linux nftables and Cisco ACLs, monitoring or
> debugging either implementation requires access to what the system is
> doing under the hood, i.e. system-specific state data and counters.
> 
> Lada
> 
>> 
>> 
>> 
>>> 
>>> 
>>> 2) access control
>>>    placing the monitoring data within configuration means the
>>> monitoring-only clients
>>>    need write permission turned on for the nodes they can access for
>>> read-only
>>>    This relies on granular and complex NACM rules which require regular
>>> maintenance.
>>> 
>>> Again, I don't quite follow this, in the specific example that I have
>>> regarding putting a RIB under a config true NP container, I would have
>>> thought that NACM read access would have been sufficient for a
>>> monitoring-only client.  Is that not the case?
>>> 
>> 
>> 
>> If the monitoring is rooting under config=true nodes, then those config=true
>> nodes need to be created somehow.  A client with write access is probably
>> required.
>> 
>> 
>> 
>>> 
>>> 
>>> 3) YANG conformance
>>>    placing the monitoring data inside the configuration means the
>>> configuration
>>>    will be required for conformance; it is not likely to be just 1 NP
>>> container.
>>> 
>>> Similar to my response to the first question, I thought that conformance
>>> was done on a per module base, not a per sub-tree basis.  So even if you
>>> have top level 'foo' and 'foo-state' as part of the same module don't you
>>> run into the same conformance problem?
>>> 
>>> 
>>> 
>> Much easier to solve the conformance since /foo-state does not need any
>> objects from /foo
>> to exist first.  Creating the /foo container means that all config=true
>> requirements for
>> that container must be implemented (or complex deviations used)
>> 
>> 
>>> 
>>> 4) pointless;
>>>   given that new RPC operations are needed to access applied config, the
>>> only data not
>>>   affected (and moved under the config container anyway) is stuff that
>>> does not share
>>>   the same indexing, or counters which are not part of the opstate
>>> problem.
>>> 
>>> Sorry, I don't really follow this one.  The original opstate draft put
>>> forward by OpenConfig was asking for both applied-configuration and derived
>>> state (e.g. statistics and other state) to be co-located under the same
>>> structures.  The original discussions focused on applied configuration, but
>>> when this was being discussed more recently the desire for a solution to
>>> the co-located derived state was also discussed - which is why both
>>> draft-schoenw-netmod-revised-datastores-01 and
>>> draft-wilton-netmod-refined-datastores-01 propose solutions to this
>>> problem.
>>> 
>> 
>> 
>>> There are also benefits to merging this data:
>>> 
>>> 1) Having co-located config and state data means that clients can easily
>>> request config and state for a related object in a single request
>>> 1b) Having co-located config and state makes it easier for clients to code
>>> - they don't need to unify data across two (potentially different
>>> structures/indexes).
>>> 1c) Having a single structure, means less copying of the same organization
>>> structure into both config and state sub trees (which could be a source of
>>> bugs)
>>> 
>>> 2) Having a single root makes schema mount work more nicely, it avoids a
>>> duplicate hierarchy.
>>> 
>>> 3) Finally, I also agree with Kent, in that merging these makes the models
>>> easier to read and removes a historical wart.
>>> 
>>> 
>> 
>> I don't agree with any of these "benefits".
>> The protocol can be made to solve these problems. (1) is already solved.
>> (1b) is pure speculation about implementation cost.
>> (1c) also makes subjective implementation assumptions
>> The new problems that are raised just make YANG worse and full of CLRs
>> that confuse people trying to learn YANG.
>> 
>> 
>> 
>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
>>> 
>> Andy
>> 
>> 
>>> 
>>> 
>>> 
>>> Andy
>>> 
>>> 
>>> Hint: the first few edits are just nits...skip over the first few
>>>> paragraphs until you start seeing large blocks of changed lines...
>>>> 
>>>> Kent // as a contributor
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> 
>>> 
>>> 
>>> 
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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