Subject: [netmod] new issue: configuration versus state data

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Apr 2014 15:40:45 +0200

* a better model for configuration versus state data is needed

** Description

In YANG 1.0, the distinction between configuration and state data is
based on the value of the boolean "config" property. State data
(config false) may be embedded within configuration but not vice
versa.

Whilst this model may be useful for closed devices with tightly
controlled configuration interfaces, it is not satifactory for open
systems in which NETCONF and/or RESTCONF may not have exclusive
control over configurable operational parameters.

In such an open system, the design of a data model must take into
account that operationally used values may be different from those
that appear in NETCONF/RESTCONF configuration datastores - because
they may have been changed through other management interfaces or
mechanisms. In such a situation, it makes no sense to bundle
operational state data such as statistics with NETCONF config data
that are not operationally used.

Due to the backward compatibility rules for YANG 1.1, it may be
impossible to enforce a new config/state-data model, but nevertheless
the new model may be formulated as a recommendation, e.g. in 6087bis.  

** Solution

This is not a complete solution but only a suggestion of principles on
which a solution could be based:

- A separate (conceptual) datastore containing state data,
  i.e. parameters that are really used by the device is needed. No
  management interface will be allowed to lock the state datastore.
- Every management interface (which includes NETCONF and
  RESTCONF) will specify the set of writable parameters,
  i.e. parameters that may be modified through that management interface.  
  Some data, such as statistics, may be "absolutely read-only".
- Every management interface specifies a particular discipline and
  workflow for eventual modifications of state data. For NETCONF this
  means the well-known framework of configurations datastores,
  commits, locks etc.

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

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Fri, 11 Apr 2014 14:28:01 +0000

I did not understand the following, is the suggestion that YANG   to have a locking mechanism ? or commit verify approach ? or all of them

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Friday, April 11, 2014 6:41 AM
To: [email-masked]
Subject: [netmod] new issue: configuration versus state data

** Description

In YANG 1.0, the distinction between configuration and state data is based on the value of the boolean "config" property. State data (config false) may be embedded within configuration but not vice versa.

Whilst this model may be useful for closed devices with tightly controlled configuration interfaces, it is not satifactory for open systems in which NETCONF and/or RESTCONF may not have exclusive control over configurable operational parameters.

In such an open system, the design of a data model must take into account that operationally used values may be different from those that appear in NETCONF/RESTCONF configuration datastores - because they may have been changed through other management interfaces or mechanisms. In such a situation, it makes no sense to bundle operational state data such as statistics with NETCONF config data that are not operationally used.

Due to the backward compatibility rules for YANG 1.1, it may be impossible to enforce a new config/state-data model, but nevertheless the new model may be formulated as a recommendation, e.g. in 6087bis.  

** Solution

This is not a complete solution but only a suggestion of principles on which a solution could be based:

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Apr 2014 08:29:37 -0700

Hi,

I don't think open vs. closed system has anything to do with this issue.
Neither NETCONF or RESTCONF has any charter to edit operational state.
This is not something YANG 1.1 can or should add to a protocol.

The problem needs to be clarified.  What is broken?
It seems the problem stated here is an inability to identify
operational values different from configuration values?
This is supported by using separate objects (oper/admin-status
or interface/interface-state).

If and when the I2RS WG decides to use RESTCONF or NETCONF
for editing operational state, then the requirements will need to be
understood
and changes can be made, at that time.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Apr 2014 18:20:08 +0200

> I don't think open vs. closed system has anything to do with this issue.

Closed systems that control all user access to a device usually try to make sure that the configured value in fact is the state value.

On a normal Linux system that runs NETCONF, the user can change operational state by other means, e.g. via shell utilities, direct writes to /proc, or SNMP.

> The problem needs to be clarified.  What is broken?

Example:

container top {
  leaf foo { … }
  leaf bar { config false; … }
}

Now, if the operational value of “foo” is not the same as the configured value, a reply to <get> will contain the *configured* value of “foo” and the real operational value of “bar”. IMO, this is broken.

The solution in some of the core modules is to separate the trees (interfaces and interfaces-state), so at least this could be formulated as a guideline, but I can also imagine other changes that are compatible with YANG 1.1 restrictions. 

> for editing operational state, then the requirements will need to be understood

This is not directly related to I2RS, although I2RS could benefit from a general solution of this issue.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Apr 2014 09:35:21 -0700

On Fri, Apr 11, 2014 at 9:20 AM, Ladislav Lhotka <[email-masked]> wrote:

> Closed systems that control all user access to a device usually try to
> make sure that the configured value in fact is the state value.
>
> On a normal Linux system that runs NETCONF, the user can change
> operational state by other means, e.g. via shell utilities, direct writes
> to /proc, or SNMP.
>
>
I think it is data-model specific whether it even possible for operational
values to differ from configuration.

>   leaf foo { ... }
>   leaf bar { config false; ... }
> }
>
> Now, if the operational value of "foo" is not the same as the configured
> value, a reply to <get> will contain the *configured* value of "foo" and
> the real operational value of "bar". IMO, this is broken.
>
>
But NETCONF and YANG do not claim that "foo" represents anything other than
the
configured value.  A new protocol operation could be somehow inform the
client
of this situation, but that doesn't change YANG.

> The solution in some of the core modules is to separate the trees
> (interfaces and interfaces-state), so at least this could be formulated as
> a guideline, but I can also imagine other changes that are compatible with
> YANG 1.1 restrictions.
>
>
Yes -- when the data model designers know the operational values
can be different, this is the traditional approach.  Not sure
why it is broken.

> general solution of this issue.
It would help to have specific solutions that maintain
backward-compatibility
with the YANG 1.0 config-stmt.

I agree that an operational datastore is a good way to define new a
non-persistent edit target, with its own validation rules. But this is
something to be designed in the protocol and supported in YANG,
not the other way around.

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Apr 2014 19:03:39 +0200

> values to differ from configuration.

In our core models this is possible for pretty much every parameter that has any meaning outside NETCONF.

> But NETCONF and YANG do not claim that "foo" represents anything other than the
> configured value.  A new protocol operation could be somehow inform the client

Yes, I thought get2 was intended to allow this but now after reading the I-D again it doesn’t seem to be the case - even with “operational” source, it will return only "config false" data.

> can be different, this is the traditional approach.  Not sure

The idea of mixing config with state data is IMO broken.

> It would help to have specific solutions that maintain backward-compatibility

Well, I think there has to be *the* operational state datastore that’s used by all management interfaces. Is there any reliable solution for SNMP competing with NETCONF?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Apr 2014 11:56:21 -0700

> has any meaning outside NETCONF.
I doubt that.
A new operation like <get-operational> (that you and Martin proposed
many IETFs ago) could be defined that provided retrieval of the operational
value
for config=true nodes.

Andy

> Yes, I thought get2 was intended to allow this but now after reading the
> I-D again it doesn't seem to be the case - even with "operational" source,
> it will return only "config false" data.
>
> >
> >
> Well, I think there has to be *the* operational state datastore that's
> used by all management interfaces. Is there any reliable solution for SNMP
> competing with NETCONF?
>
> Lada
>
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > >
> > > Andy
> > >
> > >

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Apr 2014 21:01:41 +0200

On 11 Apr 2014, at 20:56, Andy Bierman <[email-masked]> wrote:

> many IETFs ago) could be defined that provided retrieval of the operational value
> for config=true nodes.

Yes, there we tried to define the state datastore but I wasn’t very happy with the result.

Lada