Subject: [netmod] Configuration Data versus Operational State Data versus Statistics

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Sep 2009 21:35:08 +0200

Hi,

I propose to add a section to the architecture document defining and
discussing the difference between configuration data, operational
state data, and statistics. I attaching some draft writeup explaining
the background, providing a definition and some examples we discussed
here on the list. I am also including a section discussing potential
approaches to deal with operational state data. This is more for
discussion rather than inclusion in the architecture document.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Sep 2009 09:53:37 +0200

(speaking as a contributor)

I believe that this is an important subject, and it's good to deal with
it in the architecture document. 

The scope seems to exceed NETCONF architecture. It's good to have the
distinction made and the concepts well defined. My question is however -
what is the role of NETCONF (and YANG) in retrieving or reporting
statistics information? I rather see a future network management
architecture using NETCONF for configuration data. I am not so sure
about operational state data - would it be NETCONF, or rather SNMP doe
operational status retrieval and notifications, or SYSLOG - if we deal
with alarms? Is there a good case to use anything else than SNMP to
retrieve statistics information? 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, September 01, 2009 10:35 PM
> To: [email-masked]
> Subject: [netmod] Configuration Data versus Operational State 
> Data versusStatistics
> 
> Hi,
> 
> I propose to add a section to the architecture document 
> defining and discussing the difference between configuration 
> data, operational state data, and statistics. I attaching 
> some draft writeup explaining the background, providing a 
> definition and some examples we discussed here on the list. I 
> am also including a section discussing potential approaches 
> to deal with operational state data. This is more for

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Sep 2009 09:53:42 +0200

> state data, and statistics. I attaching some draft writeup explaining

I support inclusion of this text in the architecture document. The
distinction between operational state data and statistics is crucial.

> discussion rather than inclusion in the architecture document.

In the second paragraph of Example 2 you write:

"However, there are usually provisions to overwrite the discovered
attributes with static configuration data, ..."

Depending on implementation, operational state and configuration
parameters may be so tightly coupled that they are effectively
indistinguishable. For example, I can directly write certain values in
the /proc filesystem, so they are by definition configuration data, but
the write immediately changes operational data in the kernel.
Conversely, any change of such a parameter in the kernel is immediately
reflected in the /proc filesystem.

Lada

> 
> /js
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Wed, 2 Sep 2009 11:31:25 +0200

Juergen

Promising.

The problem I have is that the primary focus of YANG is the schema tree and
I find the data tree, which I assume is the focus here, ill-defined.  When
people
give definitions in terms of a configuration database, I cannot relate it to
the data tree.  Here the reference is to datastores which, in YANG, only really
figure in the text we have tidied up as part of XPath.

How simple this is in SMI; I need something more tangible here.

What is the data tree made of ?  Is it a pre-requisite that there is a data node
in the schema tree?

Is there a distinction between its constituent and the value thereof?

When do its constituents come into being?

Um

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 01, 2009 9:35 PM
Subject: [netmod] Configuration Data versus Operational State Data
versusStatistics

> discussion rather than inclusion in the architecture document.

--------------------------------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Sep 2009 13:53:22 +0200

> retrieve statistics information? 

There is no explicit NETCONF architecture I am aware of. Second, RFC
4741 explicitely spells out support for configuration data and state
data retrieval - this is why we have get and get-config.

I think the IETF is ill advised if it wants to mandate which protocol
to use for certain data since this will remain a deployment issue
taking into account tools available to an operator, the familiarity
with protocols and supporting tools, authentication and security
issues, ...

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Sep 2009 05:05:19 -0700

> How simple this is in SMI; I need something more tangible here.

amen to that!

I am not convinced at all that the database management model
we have created, laden and dependent on so much meta-cruft,
is going to provide any interoperability improvement beyond
where we are now with SNMP/SMIv2.   It may get much worse instead.
I do not agree that SMIv2/SNMP experience and BCPs are
irrelevant to NETCONF/YANG.

I do not consider a default value to be so special that it
warrants all the complexity it is adding to the protocol.
There are going to be so many kinds of default data, mandatory data,
and optional data, it may be too hard for newbies to learn.

> When do its constituents come into being?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Sep 2009 14:03:18 +0200

Juergen Schoenwaelder píše v St 02. 09. 2009 v 13:43 +0200:
> On Wed, Sep 02, 2009 at 09:53:42AM +0200, Ladislav Lhotka wrote:
> 
> > 
> Writing to /proc changes operational state - the act of writing to
> /proc does not consitute creation of configuration. Writing to /proc
> becomes configuration if you create a persistent config file that
> writes to /proc again when the box reloads its configuration.

If an in-memory database is allowed as the configuration datastore, it
could be coupled with the internal parameters in a similar way as in
the /proc filesystem, and persistence can be also guaranteed.

Perhaps we should really treat configuration as a "config file", or XML
document in the NETCONF context.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Sep 2009 13:43:47 +0200

/js

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 09:47:17 -0400

>reflected in the /proc filesystem.

There is writable data that is not configuration data.
Examples:
- file system contents
- software images
- EPROM contents
- the time in "shutdown at <time>"
- counters that can be cleared
- non-config copies of config data (like I can say "hostname foo",
  but the real configured value for hostname remains in /etc/rc.conf).

/proc would follow this, since the values you are writing aren't
really configuration data.  Register values in a running process
are not configuration data.

The flow from configuration data into operational data is not
a straight-forward path.  There are twists and turns, and
often out-right hacks.  I think the scenarios where configuration
parameters and operational state are coupled by Goldberg-esque
machinery are more common that the tightly coupled cases.

  http://dashboards.tv/images/rube-goldberg.jpg

So what do we call this writable non-configuration data?

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 02 Sep 2009 16:30:04 +0200

> There is writable data that is not configuration data.

Sure, but in the definition of "configuration data" from RFC 4741 the
only distinguishing feature is that they are writable. It is really hard
to tell what configuration data is in general, also because "initial
default state" can mean different things. What we could say though is
that a valid configuration for a given device is an XML document that
conforms to the advertised YANG modules.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 10:45:25 -0400

>conforms to the advertised YANG modules.

We can clarify "initial default state" in 4741bis, but the idea
that configuration is instructions to tell the box to get into
a desired state should be the basis.  I don't think we can
define configuration in terms of YANG module content or compliance.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Sep 2009 08:52:47 -0700

> define configuration in terms of YANG module content or compliance.

To me -- that is the problem. The protocol needs to
be made more complicated to match YANG.

I do not agree with you at all that a leaf instance
that happens to contain a default value somehow
changes from data to meta-data, then back to data
again when the value is not the default.

I think what we have now is good enough.
Description statements can deal with all
this complexity for now.

I do not see any value in coupling the CM protocol
to the DML, such that simple OPS procedures require
perfectly accurate schema definitions and meta-data
to synthesize the leaf instances that happen to contain
their default value at the moment.

It is one thing to tag the object definitions
with more and more meta-data (is assigned-by the
last, or just the last for this month?).

It is quite another to impose this as MUST meta-data on the
NETCONF protocol, because operators do not want to see the data all
the time.  That is a presentation layer problem.

CM bandwidth is a fraction of the bandwidth for monitoring.
I don't think we are helping operators by suppressing YANG defaults.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Sep 2009 18:18:59 +0200

I do not disagree with any of those. I am just making the observation
that the set of categories that you started to define exceed the scope
of NETCONF. After all we do not want to have configuration data,
operational state, and statistics redefined again and again for each
protocol. 

While mandating which protocol is used for certain data seems to be a
futile exercise, proving some guidance about what tools are fit for
specific operations can be expected to happen at some stage. After all
we are not designing all protocols (NETCONF included) as good and fit
for all kinds of management operations. 

Dan

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, September 02, 2009 2:53 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [netmod] Configuration Data versus Operational 
> State Data versusStatistics
> 
> > I believe that this is an important subject, and it's good to deal 
> > with it in the architecture document.
> > 
> > distinction made and the concepts well defined. My question 
> is however 
> > - what is the role of NETCONF (and YANG) in retrieving or reporting 
> 4741 explicitely spells out support for configuration data 
> and state data retrieval - this is why we have get and get-config.
> 
> I think the IETF is ill advised if it wants to mandate which 
> protocol to use for certain data since this will remain a 
> deployment issue taking into account tools available to an 
> operator, the familiarity with protocols and supporting 
> tools, authentication and security issues, ...
> 
> /js
> 
> --

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 11:56:04 -0400

>again when the value is not the default.

Wait, we just agreed on all this after a month of noise.  Please
don't start sliding back into poor terminology and confusion.

A leaf instance in the configuration database does not change from
data to meta-data.  Meta-data describes the data, so a default value
for a leaf is meta-data.  A configured value for a leaf is data.
If there is no configured value for a leaf, then there is no data.
The leaf instance does not change, it either exists or it doesn't.

>I don't think we are helping operators by suppressing YANG defaults.

We're circling again:  this is your opinion, not shared by the
entire WG.  We have flexibility on the YANG spec to allow your code
to work in this way, while allowing others to work in more traditional,
simpler ways.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 14:28:24 -0400

>document in the NETCONF context.

This is essentially what we've done, but left breadcrumbs to allow
the same organization to be used to retrieve operational data.  The
details of how these breadcrumbs works are fairly weak, and I'm not
sure we'll be able to work them out via email.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Sep 2009 12:16:09 -0700

> sure we'll be able to work them out via email.

I don't think breadcrumbs are a good substitute for
retrieving operational data.  Perhaps the no-revision-module
can be fixed, but the complexity, reliance on a complete
set of meta-data, and deviations-redefined-defaults are all too
fragile.

An operator will read the YANG module, see that the default
that is never allowed to change is set to '10'.  The number '10'
will get plugged into hardwired scripts to deal with
NETCONF's lack of basic support for complete data retrieval.

Except '10' will not be correct if there are any deviations
which break the contract.

The YANG-default + synthesis-of-all-deviations is not intuitive,
and turns the YANG-default from a constant into a
complicated-to-derive variable that is potentially different for
every session.

The YANG default needs to be a true constant, never affected
by anything like the deviation-stmt.  The server must remember
any original defayult (or lack of one), and use that as its
test for filtering defaults.  This has a much higher
chance of interoperability and usability.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 15:54:08 -0400

>which break the contract.

We're circling again:  a deviation is a declaration of broken-ness.
If your application wants to assume that none of your devices are
broken, ignore deviaations completely.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Sep 2009 21:06:53 +0200

> operational state, and statistics redefined again and again for each

RFC 3535 explains that SNMP failed to make the necessary distinction.
We are trying to learn from this mistake and make a proper distinction
between configuration and operational state data now. I am concerned
if we are being told that we should not make this step because going
forward might overlap with some other protocols (that failed to make
this distinction).

> for all kinds of management operations. 

I am all in favour of documenting properties of protocols so that
people can easily make informed implementation / deployment decision.
And it is also good to declare dead protocols dead (this reminds me of
COPS-PR and SPPI).

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 6 Sep 2009 12:08:42 +0200

> Sent: Thursday, September 03, 2009 10:07 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> We are trying to learn from this mistake and make a proper 
> distinction between configuration and operational state data 
> now. I am concerned if we are being told that we should not 
> make this step because going forward might overlap with some 
> other protocols (that failed to make this distinction).

This is not what you are told, by me at least. I support this work. What
I am saying (as a contributor) is that I think that we need to write a
set of definitions for configuration data, operational state and
statistic that are not YANG specific, so that we can reuse them for
other protocols. 

> I am all in favour of documenting properties of protocols so 
> that people can easily make informed implementation / 
> deployment decision.
> And it is also good to declare dead protocols dead (this 
> reminds me of COPS-PR and SPPI).
> 

We had this discussion in the OPSAWG meeting. We are looking for 'Moving
COPS-PR to Historical' contributions.

Regards,

Dan

---

From: "tom.petch" <[email-masked]>
Date: Tue, 8 Sep 2009 09:57:06 +0200

----- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Ladislav Lhotka" <[email-masked]>
Sent: Wednesday, September 02, 2009 1:43 PM

Juergen

It sounds as if you want 'copy running start' as implemented in many,
if not most, network devices and specified in NETCONF.

Changes executed by CLI affect only the 'running' one and will be
lost at the next boot unless a user enters 'copy run start' whereupon
those changes seen as configuration by the device are incorporated
in the 'start' configuration file.

But, the way I've seen this implemented, which I suspect holds true
for many if not most people, is that changes executed by CLI 
do become part of the 'running' datastore and do show up in any 
display or retrieval of configuration.  That too is my reading of
RFC4741.

I don't see any impact on YANG.  Did you have something in
mind?

 Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Sep 2009 13:46:35 +0200

> I don't see any impact on YANG.  Did you have something in

I just wanted to clarify that changing /proc on Unix systems means
changing operational state and not configuration. There is no other
hidden message.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 08 Sep 2009 13:56:25 +0200

> changing operational state and not configuration. There is no other

The point is that "running" is volatile in the same way as the /proc
subsystem and on the other hand the contents of /proc behaves exactly
like files and directories, so I fail to see the difference. If /proc
was instead represented in XML, it could be a perfect model for
"running".

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Sep 2009 14:02:46 +0200

On Tue, Sep 08, 2009 at 01:56:25PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v ??t 08. 09. 2009 v 13:46 +0200:
> > 

No, /proc includes all sort of operational state and statistics. It is
by no means a configuration datastore. The /proc analogy to running is
fundamentally flawed.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 08 Sep 2009 14:13:23 +0200

> No, /proc includes all sort of operational state and statistics. It is

These would be "config=false" nodes. Nothing in YANG prevents me from
mixing config with non-config nodes. Do you think it is in principle
impossible to write a YANG module for /proc?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Sep 2009 15:02:57 +0200

On Tue, Sep 08, 2009 at 02:13:23PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v ??t 08. 09. 2009 v 14:02 +0200:

Show me a Unix system that does have copy /proc to kernel parameter
startup mechanism. The naming of many things in /proc is runtime
dependent and really bad for this purpose (see why things like sysfs
have been invented). And since /proc is a kernel data export mechanism
(originally invented to make process information accessible), you lack
all the config that goes into user space processes.

But to answer your question: YANG allows to write a module for /proc -
I believe it is modelling error to do so.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 08 Sep 2009 15:28:40 +0200

> I believe it is modelling error to do so.

I am not advocating that /proc be really used as "running", I just claim
a real "running" implementation can use the same mechanism that /proc
uses for some writable parameters, effectively making a single item both
operational and config data. This is where this thread started.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Sep 2009 17:57:57 +0200

> operational and config data. This is where this thread started.

And I continue to disagree. Operational data and config data are not
the same beast. Something written to /proc is operational state and
not config. The far better analogy is /etc/sysctl.conf and sysctl -a
since this actually exists on some Unix systems and is being used for
configuration.

The mechanics of pushing something into the kernel or reading
something from the kernel is implementation detail, and /proc, /sysfs,
sysctl(3), netlink(3), ... are just a few of the mechanisms you find
on Unix systems (one of the more painful aspects of Unix systems).

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 08 Sep 2009 10:35:41 -0700

> on Unix systems (one of the more painful aspects of Unix systems).

I agree with you.
If /proc data was available in NETCONF,
it would be config=false.  /proc is just the user-space
read-only monitoring data -- not the restricted-to-root
kernel-space configuration data.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Sep 2009 06:07:44 +0200

> the same beast. Something written to /proc is operational state and

Conceptually, yes. Nonetheless, some parameters may be modelled and
implemented so that any change in the operational value is immediately
reflected in "running". In some cases, this might just be the right
thing to do.

For example, if I use a hardware switch for turning off WiFi (i.e.
changing the operational status) and then fetch "running", I actually
want to see in the configuration that WiFi is turned off. But I can also
turn off WiFi by writing 0 to the same node via edit-config.
This single parameter then clearly satisfies both of your definitions:

- Configuration data is the set of writable data that is required to
  transform a system from its initial default state into its current
  state. [RFC 4741]

- Operational state data is a set of data that has been obtained by
  the system at runtime and influences the system's behaviour similar
  to configuration data. In contrast to configuration data,
  operational state is transient and modified by interactions with
  internal components or other systems via specialized protocols.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Sep 2009 07:02:00 +0200

On Wed, Sep 09, 2009 at 06:07:44AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v ??t 08. 09. 2009 v 17:57 +0200:

Once again, any information in /proc is not persistent. Its not
config.  If you now want to discuss hypothetical hardware switches for
WiFi, please start a separate thread.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Sep 2009 07:12:05 +0200

> WiFi, please start a separate thread.

As Tom pointed out, "running" is not persistent either.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Sep 2009 09:01:30 +0200 (CEST)

> As Tom pointed out, "running" is not persistent either.

Depending on capabilities, running can be persistent.  The only time
it is not persistent is if you have the distinct startup capability.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 09 Sep 2009 09:15:40 +0200

> it is not persistent is if you have the distinct startup capability.

Yes, but persistence by itself is not what discriminates config data
from operational status data.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "tom.petch" <[email-masked]>
Date: Wed, 9 Sep 2009 15:04:36 +0200

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
Sent: Wednesday, September 09, 2009 9:15 AM

Juergen

You did say

> Writing to /proc

which suggests to me that there are items of data in /proc which I might
regard as configuration.  Can you give me some examples of what
you had in mind in this statement?

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Sep 2009 16:42:00 +0200

On Wed, Sep 09, 2009 at 03:04:36PM +0200, tom.petch wrote:
> > Martin Bjorklund p????e v St 09. 09. 2009 v 09:01 +0200:

I want to get out of this thread. There is no standard /proc to begin
with. Run a find to locate writable files in /proc and then study what
is inside and see whether that meets your notion of configurable
object. But then again, /proc is all about operational state and a
IMHO a bad template for modeling config. Look into /etc instead.

/js