Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2

From: Benoit Claise <[email-masked]>
Date: Fri, 28 Feb 2014 12:06:07 +0000

Dear all,

[I bcc'ed some people, with whom I discussed this issue privately. I 
want to make sure they're in the opsarea loop. Sorry, if you receive 
this email twice]

I discussed the following statement with the IESG. I ideally wanted to 
have this statement approved as an IESG statement before the beginning 
of the week, but I realize that it might need some more discussion among 
the OPS community...

    The OPS area recommends the use of NETCONF/YANG standards for
    configuration. IETF working groups are therefore encouraged to use
    the NETCONF/YANG standards for configuration, especially in new
    charters. SNMP MIB modules _creating and_ modifying persistent
    configuration state should only be produced by working groups in
    cases of clear utility and consensus to use SNMP write operations
    for configuration.

Btw, one IESG member insisted on having "_creating and_ modifying" 
instead of "modifying".

Let me focus on a more important issue.
First let me make sure that we agree on one terminology. The 
NETCONF/YANG terminology is in RFC 6244:

   o  Configuration data is the set of writable data that is required to
       transform a system from its initial default state into its current
       state [RFC4741  <http://tools.ietf.org/html/rfc4741>].

    o  Operational state data is a set of data that has been obtained by
       the system at runtime and influences the system's behavior 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.

    o  Statistical data is the set of read-only data created by a system
       itself.  It describes the performance of the system and its
       components.

Operational state data is sometimes called ephemeral (or non-persistent 
configuration data), as opposed to the "configuration data" that is 
persistent.
See RFC 6244 section 4.3.2.x for some useful examples.

The statement has been carefully crafted to cover the 4 different cases:

         SNMP NETCONF/YANG
+-----------------------------------------------------------------+--------------------------------------------------+
             Configuration data  | SHOULD NOT specify writable MIB 
modules    |  SHOULD use NETCONF/YANG          |
|-----------------------------------------------------------------+--------------------------------------------------|
      Operational State data  | Not clear guidelines at time point in 
time  (*)   |   SHOULD use NETCONF/YANG         |
+---------------------------------------------------------------------------------------------------------------------+ 

Let me focus on (*).
Some of you are telling: SNMPset is not enabled in networks, period. 
Don't specify new writable MIB modules, even for operational state data, 
it doesn't make sense.
Some others are telling: Note that this statement limits the discussion 
to configuration data. Note also that there is no standard way to modify 
operational state via NETCONF at this point in time (so it would be 
strange to discourage SNMP if there is no standardized alternative).

I believe we need some more discussion on this specific point. Please 
share your point of view:
- Should we keep the statement as it is, but better explain it? (which 
might require more background, so maybe a draft instead of a brief 
statement)
- Should we extend the statement and remove "persistent" from this 
sentence: SNMP MIB modules creating and modifying persistent 
configuration state should only be produced by working groups in cases 
of clear utility and consensus to use SNMP write operations for 
configuration?
- Something else?

Regards, Benoit

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 28 Feb 2014 13:38:03 +0100

IMHO we should define in Netconf/YANG how to handle  operational
state data.

Balazs

P.S. "Ephemeral configuration" is a much better name. It is writable
configuration and it effects how the node behaves. The name
"operational state" carries neither of these two meanings.

On 2014-02-28 13:06, Benoit Claise
wrote:

Dear all,

[I bcc'ed some people, with whom I discussed this issue privately.
I want to make sure they're in the opsarea loop. Sorry, if you
receive this email twice]

I discussed the following statement with the IESG. I ideally
wanted to have this statement approved as an IESG statement before
the beginning of the week, but I realize that it might need some
more discussion among the OPS community...

The OPS area recommends the use of NETCONF/YANG
standards for configuration. IETF working groups are therefore
encouraged to use the NETCONF/YANG standards for configuration,
especially in new charters. SNMP MIB modules creating and
modifying persistent configuration state should only be produced
by working groups in cases of clear utility and consensus to use
SNMP write operations for configuration.

Btw, one IESG member insisted on having "creating and
modifying" instead of "modifying".

state [RFC4741].

Operational state data is sometimes called ephemeral (or
non-persistent configuration data), as opposed to the
"configuration data" that is persistent.

The statement has been carefully crafted to cover the 4 different
cases:

SNMP
NETCONF/YANG

Operational State data  | Not clear guidelines at time point
in time  (*)   |   SHOULD use NETCONF/YANG         |

Let me focus on (*).

Some of you are telling: SNMPset is not enabled in networks,
period. Don't specify new writable MIB modules, even for
operational state data, it doesn't make sense.

Some others are telling: Note that this statement limits the
discussion to configuration data. Note also that there is no
standard way to modify operational state via NETCONF at this point
in time (so it would be strange to discourage SNMP if there is no
standardized alternative).

I believe we need some more discussion on this specific point.
Please share your point of view:

- Should we keep the statement as it is, but better explain it?
(which might require more background, so maybe a draft instead of
a brief statement)

for configuration?

- Something else?

Regards, Benoit

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ops-area

--
Balazs Lengyel Ericsson Hungary Ltd.
System Manager
ECN: 831 7320 Tel: +36-1-437-7320
Mobile: +36-70-330-7909 email: [email-masked]

---

From: t.petch <[email-masked]>
Date: Fri, 28 Feb 2014 12:38:41 +0000

----- Original Message -----
From: "Benoit Claise" <[email-masked]>
To: <[email-masked]>
Sent: Friday, February 28, 2014 12:06 PM
Subject: [OPS-AREA] configuration: writable MIB modules versus

> Operational state data is sometimes called ephemeral (or
non-persistent
>          SNMP NETCONF/YANG
+-----------------------------------------------------------------+-----
---------------------------------------------+
> modules    |  SHOULD use NETCONF/YANG          |
|-----------------------------------------------------------------+-----
---------------------------------------------|
> time  (*)   |   SHOULD use NETCONF/YANG         |
+-----------------------------------------------------------------------
----------------------------------------------+
> Some others are telling: Note that this statement limits the
discussion
> might require more background, so maybe a draft instead of a brief

Make it a draft, with an IETF Last Call.  It is too important for just
this list.

Tom Petch

> of clear utility and consensus to use SNMP write operations for

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Feb 2014 14:32:08 +0100

On 28 Feb 2014, at 13:38, Balazs Lengyel <[email-masked]> wrote:

> IMHO we should define in Netconf/YANG how to handle  operational state data.

I think the concept of operational state data should be defined in a way that is independent of NETCONF - the rules should be common for all protocols and other methods that read, create and modify operational state data. The /proc filesystem is IMO a good model.

A corollary to this is that YANG could be used for modelling operational state data under the assumption that its specification is protocol-neutral (which is currently not the case).

In contrast, configuration can be considered NETCONF-specific.

>  
> Balazs
> 
> P.S. "Ephemeral configuration" is a much better name. It is writable configuration and it effects how the node behaves. The name "operational state" carries neither of these two meanings.

My understanding is that operational state data may also include items that are by definition not writable.

Lada 

> 
> On 2014-02-28 13:06, Benoit Claise wrote:
>> Dear all,
>> 
>> [I bcc'ed some people, with whom I discussed this issue privately. I want to make sure they're in the opsarea loop. Sorry, if you receive this email twice]
>> 
>> I discussed the following statement with the IESG. I ideally wanted to have this statement approved as an IESG statement before the beginning of the week, but I realize that it might need some more discussion among the OPS community...
>> The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, especially in new charters. SNMP MIB modules creating and modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use         SNMP write operations for configuration.
>> Btw, one IESG member insisted on having "creating and modifying" instead of "modifying". 
>> 
>> First let me make sure that we agree on one terminology. The NETCONF/YANG terminology is in RFC 6244:
>>       state [
>> RFC4741
>> ].
>> Operational state data is sometimes called ephemeral (or non-persistent configuration data), as opposed to the "configuration data" that is persistent.
>>             Configuration data  | SHOULD NOT specify writable MIB modules    |  SHOULD use NETCONF/YANG          |
>>      Operational State data  | Not clear guidelines at time point in time  (*)   |   SHOULD use NETCONF/YANG         |
>> Some of you are telling: SNMPset is not enabled in networks, period. Don't specify new writable MIB modules, even for operational state data, it doesn't make sense.
>> Some others are telling: Note that this statement limits the discussion to configuration data. Note also that there is no standard way to modify operational state via NETCONF at this point in time (so it would be strange to discourage SNMP if there is no standardized alternative). 
>> 
>> I believe we need some more discussion on this specific point.  Please share your point of view:
>> - Should we keep the statement as it is, but better explain it? (which might require more background, so maybe a draft instead of a brief statement)
>> - Should we extend the statement and remove "persistent" from this sentence: SNMP MIB modules creating and modifying persistent configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration?
>> - Something else?
>> 
>> Regards, Benoit
>> 
>> 
>> 
>> 
>> 
>> 

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Feb 2014 06:26:33 -0800

On Fri, Feb 28, 2014 at 4:06 AM, Benoit Claise <[email-masked]> wrote:

>  Dear all,
>
> [I bcc'ed some people, with whom I discussed this issue privately. I want
> to make sure they're in the opsarea loop. Sorry, if you receive this email
> twice]
>
> have this statement approved as an IESG statement before the beginning of
> the week, but I realize that it might need some more discussion among the
> OPS community...
>
> configuration. IETF working groups are therefore encouraged to use the
> NETCONF/YANG standards for configuration, especially in new charters. SNMP
> MIB modules *creating and* modifying persistent configuration state
> should only be produced by working groups in cases of clear utility and
> consensus to use SNMP write operations for configuration.
>
> Btw, one IESG member insisted on having "*creating and* modifying"
> instead of "modifying".
>
> Some of you are telling: SNMPset is not enabled in networks, period. Don't
> specify new writable MIB modules, even for operational state data, it
> doesn't make sense.
> Some others are telling: Note that this statement limits the discussion to
> configuration data. Note also that there is no standard way to modify
> operational state via NETCONF at this point in time (so it would be strange
> to discourage SNMP if there is no standardized alternative).
>
> sentence: SNMP MIB modules creating and modifying persistent configuration
> state should only be produced by working groups in cases of clear utility
> and consensus to use SNMP write operations for configuration?
> - Something else?
>

Unless some WG is asking to use SNMP Set to edit operational state, I don't
see why new work (SNMPv4?) would begin, or even why guidance is needed
in this matter.

NETCONF already supports actions that can change operational state as
a side-effect.  A standard edit function to do the same could be added.
I am more concerned with the security and operational issues related
to editing operational state, than the editing mechanics.
Where is the standard audit log for example?

If we say "SHOULD use (whatever)", then it seems we are saying that
any WG can start creating editable state.  I don't think that is a good
idea.
It would be better to wait and see how it goes with I2RS before making
general guidelines.  IMO a protocol-independent architecture that
properly deals with the interactions between "running config", "ephemeral
config",
"operational state", and "statistics" is needed.

> Regards, Benoit

Andy

---

From: Randy Bush <[email-masked]>
Date: Fri, 28 Feb 2014 16:28:11 +0000

>        internal components or other systems via specialized protocols.

data are plural, please

i never understood the fantasy of this dichotomy.  all (non measurement)
data are operational.  i do not see a difference between configuring a
bgp peer, filters, interface up/down, ...  the dichotomy is in my use
models.  do i configure systems programatically or do i have banana
eater keyboard jockies running my network?  the former uses netconf or
expect and the latter use the cli.

none of them use snmp write.  i thought we made that point over a decade
ago.

randy

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Feb 2014 18:04:53 -0000

Top posting for the hell of it.

My "problem" with these definitions are that their use of passive voice mistakes
the view from the management station and the view from the node. Maybe this is
the point Randy has. From the node's perspective, it doesn't care where the data
came from (except maybe for prioritising it over other inputs). You don't
forward packets differently on routes learnt from an IGP compared with routes
programmed by an operator.

Curiously, the definitions here seem to be different from those that I just read
on a back-channel discussion with Benoit and others where we had:

"operational data" includes both state learned from the network and the
administrative state pushed to the various routing and such processes.

"configuration data" can be persistent or ephemeral - but it's all held by the
management side, whether that is CLI or NetConf.

I am also having serious difficulty with the concept of persistence because it
can be persistent in the management station or persistent in the node. (One
hopes the latter is a subset of the former.) 

Maybe operational state can be persistent (at the node) and no-one thought to
mention it? That could certainly complete the definitions.

Anyway, is there any reason why the draft IESG statement text uses
"configuration data" in all cases except "SNMP MIB modules creating and
modifying persistent configuration"? Why "persistent" in this one case? Does it
make any difference whether SNMP is used to write persistent or non-persistent
configuration data?

And lastly...
+1 to Randy. I thought the main thrust of what we were trying to do was describe
whether SNMP Set is valuable, and if so in what context.

Cheers,
Adrian

> -----Original Message-----
> From: OPS-AREA [mailto:[email-masked]] On Behalf Of Randy Bush
> Sent: 28 February 2014 16:28
> To: Benoit Claise
> Cc: ops-area
> Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
> NETCONF/YANG modules - part 2
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Feb 2014 19:57:17 +0100

On Fri, Feb 28, 2014 at 06:04:53PM +0000, Adrian Farrel wrote:

> "configuration data" in all cases except "SNMP MIB modules creating
> and modifying persistent configuration"? Why "persistent" in this
> one case? Does it make any difference whether SNMP is used to write
> persistent or non-persistent configuration data?

For an NMS, it is crucial to know whether something is persistent
configuration or dynamic operational state. Yes, a router's forwarding
plane does not care where the forwarding table entry came from.
However, those who have to troubleshoot things very likely want to
know whether a forwarding entry is coming from persistent
configuration or whether it is the result of some operational state
picked up at runtime. Similarly, when an NMS makes change, it likes to
know whether the change persists or not. CLIs often make clear
distinctions between changes that are persistent and stuff that is
forgotton on the next reload.

For SNMP MIB modules, exposing the difference is somewhat complicated
since you need to deal with StorageType objects to express what is
persistent (well and even StorageType allows freedom so that the
management system still has to guess). A simple operation such as
"show the persistent configuration" or "show the configuration used at
next reload" that every CLI supports is really hard to do with SNMP.
In contrast, tweaking operational state at runtime of stuff that is
there already is fairly easy. But even then, it often remains unclear
whether a change persists or not. Note also that some SNMP tools tend
to generate sequences of SNMP set requests to make a conceptual
change. This (a) causes the generation of temporary state and (b)
leaves it open when changes are actually committed to stable
storage. This all rasies costs (on both the device and the NMS side)
and makes things brittle. SNMP really is IMHO horribly broken for
configuration management and attempts to fix it failed. This is long
known and also documented in RFC 3535.

/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: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Feb 2014 20:16:19 -0000

Hi Juergen,

Thanks for the explanation of the difference between "configuration data" and
"persistent configuration data".

>From your final statement...
> SNMP really is IMHO horribly broken for

I take it that you would assert that the draft statement should read "SNMP MIB
modules creating and modifying configuration" leaving out the word "persistent"

Thanks,
Adrian

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: 28 February 2014 18:57
> To: Adrian Farrel
> Cc: 'Benoit Claise'; 'ops-area'

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Feb 2014 21:42:53 +0100

On Fri, Feb 28, 2014 at 08:16:19PM +0000, Adrian Farrel wrote:
> I take it that you would assert that the draft statement should read
> "SNMP MIB modules creating and modifying configuration" leaving out
> the word "persistent"

There are different terminologies around and depending on the one used
I may agree or not. I definitely agree with "SNMP MIB modules creating
and modifying persistent configuration" but that is likely not what
you want to hear. ;-)

In the NETCONF world, configuration data is pretty much synonymous
with what I think you call persistent configuration. (The term
'persistent' does never appear in RFC 3535 but then RFC 3535
distinguishes between 'configuration data', operational state data,
and statistics. RFC 6244 says (section 4.3.2):

This kind of implies that the configuration data is persistent since it
needs to be there when the device re-initializes.

This means that routing protocols or dhcp or even things like i2rs
simply mess around with operational state.

Given this terminology, I think what you call non-persistent
configuration is operational state data. For relatively simple things
that mess around with operational state (setting a threshold, turning
off an interface), SNMP's peek and poke model can work. For more
complex things, I personally would not recommend it but then I must
also note that there is no well established better generic solution
available in the IETF. Hence I believe it is right thing to limit
the statement to 'persistent configuration'.

/js

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 28 Feb 2014 17:31:19 -0500

Hi,

Comments inline.

David Harrington
[email-masked]
+1-603-828-1401
> From: OPS-AREA [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Friday, February 28, 2014 3:43 PM
> To: Adrian Farrel
> Cc: 'ops-area'
> > Thanks for the explanation of the difference between "configuration
data"
> and

I agree that SNMP is horribly broken for configuration management and
attempts to fix it have failed.
I think a major part of the "brokenness" is that SNMP does not recognize the
difference between startup config and running config.
An SNMP SET cannot specify whether a change 1) should be applied only to the
running config and NOT persist beyond system reboot, or 2) should be applied
to the running config and SHOULD persist across reboots, or 3) should be
applied to a startup config and not take effect until a system reboot. 

The community string or context can be used to specify which "config store"
to apply a SET to, but such usage has never been standardized, and community
and context are so overloaded with proprietary uses that trying to use them
to standardize standardize config stores after the fact is not viable.
Around 1991-1992, there was an effort to try to standardize "temporal
contexts", but it got mired in the SNMP wars, and got dropped from SNMPv3.

While the SET message in the (v1,v2,and v3 versions of the) SNMP protocol
has no field to specify which config store should be affected, a MIB object
description CAN specify that a RW object's value MUST persist across reboot.
If the object doesn't specify such persistence, then any modification of the
value does not persist across reboot.
Putting this into startup vs running config store terminology supported by
Netconf (and by some CLIs), but not required of a netconf implementation,
the non-persistent modification (#1) happens to the "running" config, while
the persistent modification (#2) happens to both the running and the startup
config, while #3 only happens to the startup config.

Equipment vendors have had to deal with the relationship between the running
config and startup config when an SNMP SET modifies the running config, when
persistence is called for.

Part of the problem we have discussing this issue is terminology. If Netconf
or a CLI configures a device with a "running" config,  and a subsequent SNMP
SET modifies one of the configuration variables in a non-persistent manner,
is this still called the running config, or is this now called operational
state? Personally, based on what my equipment vendor co-workers called it, I
think the modifiable variable is still part of the running config; the
running configuration has simply been modified.
I think of operational state as all the information provided to a query -
that would include read-only values, current read-write values, plus
counters. I never think of operational state as something you can write to
with a SET or a Netconf edit command; you write to the running
configuration, which is then echoed in the reported state. I think this is
reflected in MIB-2 (RFC1213), where they defined  a RW object for
ifAdminStatus (the desired state of the interface) and a RO object for
ifOperStatus (the current operational state of the interface).

If Netconf configures a device, and an SNMP SET modifies it, does that means
it is now operational state? then what is it called if Netconf configures
the device, and then a subsequent netconf edit command modifies it? is it
still the running config, or is it now operational state? Does the act of
modifying the configuration change it from config to operational state, or
is it the act of querying it that changes it to operational state?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Feb 2014 23:45:22 +0100

> is it the act of querying it that changes it to operational state?

Since it is generally unclear what an SNMP set request modifies, your
questions can't be answered.

/js

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 28 Feb 2014 17:47:58 -0500

> the statement to 'persistent configuration'.

So here's where I have a problem with the statement.
People who have not been involved in the years-long debate in the OPS area
about what is configuration versus what is operational state (which is still
ongoing in the netmod list and now here) will have difficulty interpreting
the current statement because we do not clearly identify the distinction
between RW objects for "configuration" versus RW objects for relatively
simple things like setting a threshold, or turning off an interface.

Some argue that, since SET is not widely deployed, defining a RW object in a
MIB is a waste of resources. I disagree. Even though vendors might implement
an object RW, or only RO, the definition of the object is clearly specified.
This means the object, in RO form, is part of a standardized data model for
monitoring; in RW form, even if not used with SNMP SET, it becomes a
standardized *Information Model* for CLI implementers to follow (and
possibly other protocol implementers). So if a WG thinks a RW object is
potentially useful to monitor/manage their protocol, they at a minimum would
be standardizing an information model for that "knob". I think that is a
useful thing to do.

David Harrington
[email-masked]
+1-603-828-1401