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

From: Benoit Claise <[email-masked]>
Date: Sat, 01 Mar 2014 13:08:05 +0000

> 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:
Come on Adrian,
cutting and pasting some text from an different email thread between 3 
persons, out of context, here, doesn't help anything.
I specifically took care of mentioning in THIS email thread " First let 
me make sure that we agree on one terminology. The NETCONF/YANG 
terminology is in RFC 6244:"
>
> "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.
>
Regards, Benoit

---

From: Andy Bierman <[email-masked]>
Date: Sat, 1 Mar 2014 06:06:36 -0800

On Friday, February 28, 2014, ietfdbh <[email-masked]> wrote:

> Hi,
>
> Comments inline.
>
> David Harrington
> [email-masked] <javascript:;>
> +1-603-828-1401
> > -----Original Message-----
> > From: OPS-AREA [mailto:[email-masked] <javascript:;>] On
> Behalf Of Juergen
> > Schoenwaelder
> > Sent: Friday, February 28, 2014 3:43 PM
> > To: Adrian Farrel
> > Cc: 'ops-area'
> > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
> > NETCONF/YANG modules - part 2
> >
> > On Fri, Feb 28, 2014 at 08:16:19PM +0000, Adrian Farrel wrote:
> > > 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
> > > > configuration management and attempts to fix it failed. This is long
> > > > known and also documented in RFC 3535.
>
> 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.

IMO the problem has always been the lack of a transaction model.
An agent has to process a random set of varbinds in each message.
A complete row can be mixed with unrelated rows and spread across
multiple PDUs.  This is not how CLI works and not something operators
need.

The additional unwarranted complexity causes development schedules
to be longer than managers are willing to accept. It costs too much to
support SNMP Set.

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

I am not understanding this focus on persistence.
This is not an issue in agent implementation at all.

I understand the fallback feature of persisting to the next reboot.
This allows bad configuration to be dumped if the box is wedged
and needs a reboot to recover. I don't see this as a property of the
data model.  It seems more likely that the operator can decide
and the same data could persist or not, depending on the situation.
(E.g., IOS write mem command)

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

The reality is that router vendors do not agree on the meaning of
configuration.
That's why we have 3 definitions of a default leaf in NETCONF.
A lot of compromise has gone into a protocol that actually works for
every vendor. It would be nice to converge on one simple architecture
with no variance, but we are not there yet.

Andy

>
> 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?
>
> > >
> > > 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):
> >
> >    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].
> >
> > This kind of implies that the configuration data is persistent since it
> > needs to be there when the device re-initializes.
> >
> >    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.
> >
> > This means that routing protocols or dhcp or even things like i2rs
> > simply mess around with operational state.
> >
> >    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.
> >
> > 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
> >
> > --
> > 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/>
> >
> > _______________________________________________
> > OPS-AREA mailing list
> > [email-masked] <javascript:;>
> > https://www.ietf.org/mailman/listinfo/ops-area
>
> _______________________________________________
> OPS-AREA mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

From: t.petch <[email-masked]>
Date: Sat, 1 Mar 2014 21:58:51 +0000

----- Original Message -----
From: "ietfdbh" <[email-masked]>
To: "'Juergen Schoenwaelder'" <[email-masked]>;
"'Adrian Farrel'" <[email-masked]>
Cc: "'ops-area'" <[email-masked]>
Sent: Friday, February 28, 2014 10:31 PM
> [email-masked]
> > From: OPS-AREA [mailto:[email-masked]] On Behalf Of
Juergen
> I think a major part of the "brokenness" is that SNMP does not
recognize the
> An SNMP SET cannot specify whether a change 1) should be applied only
to the
applied
> applied to a startup config and not take effect until a system reboot.

David

Oh yes it can! I have done something like it many times while operating
a network.

All it takes is proprietary MIB modules that provide different objects
for the different purposes.  The IETF could have standardised such a
system - but didn't.  Now we have the multiple data stores of NETCONF
and so are moving in that direction.

Tom Petch

community
reboot.
> If the object doesn't specify such persistence, then any modification
of the
startup
running
> config and startup config when an SNMP SET modifies the running
config, when
Netconf
> or a CLI configures a device with a "running" config,  and a
subsequent SNMP
> state? Personally, based on what my equipment vendor co-workers called
it, I
means
> > [email-masked]
> [email-masked]

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 3 Mar 2014 13:37:49 +0000

Sorry for not replying to this thread - been traveling and busy all weekend...  One comment inline below:

> 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:
> 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?

	This is precisely what is the question: is the SET operation enabled in networks or not ?  I think the overwhelming answer is "no". The discussions that are rabbit holing into questions like "what is configuration?, "is it persistent, etc...?" are completely missing the point. The simple issue at hand is the fact that boxes in networks are programmed to reject ANY SNMP SET operations.  This is what Randy was channeling from operators the other day as well. We really need to listen to the operational feedback on this one. 

	--Tom

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Mon, 03 Mar 2014 16:22:57 +0000

On 3 Mar 2014, at 13:37, Thomas Nadeau wrote:

>> [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.
>> Operational state data is sometimes called ephemeral (or 
>> non-persistent configuration data), as opposed to the "configuration 
>> data" that is persistent.
>> 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).
>>
>> - 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?
>
> 	This is precisely what is the question: is the SET operation enabled 
> in networks or not ?  I think the overwhelming answer is "no". The 
> discussions that are rabbit holing into questions like "what is 
> configuration?, "is it persistent, etc...?" are completely missing the 
> point. The simple issue at hand is the fact that boxes in networks are 
> programmed to reject ANY SNMP SET operations.  This is what Randy was 
> channeling from operators the other day as well. We really need to 
> listen to the operational feedback on this one.

I agree Tom.  The larger question, at the end of the day, is how many 
models do we want to continue support.  Do we want to define MIBs for 
statistics, and NETCONF for configuration, going forward, or do we want 
to, over time, standardize on a single data model infrastructure 
(YANG?), that can then generate NETCONF, and possibly MIBs, if MIBs are 
still desired for operational data collection?  I'm in favor of a common 
data model definition, that can then be rendered into whatever protocols 
are deemed appropriate by the implementer.

Christopher

--
李柯睿
Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc
Current vCard here: http://www.asgaard.org/cdl/cdl.vcf

---

From: Thomas D Nadeau <[email-masked]>
Date: Mon, 3 Mar 2014 16:57:03 +0000

I'm not sure about the implementations, but models (yang) are definitely the right direction of you ask me.  translation from a common model is easier than one from every specific management protocol as (automated) code generation is a viable solution (see the direction odp is going).

Tom 

> On Mar 3, 2014, at 16:19, "Christopher LILJENSTOLPE" <[email-masked]> wrote:
> 
> I agree Tom.  The larger question, at the end of the day, is how many models do we want to continue support.  Do we want to define MIBs for statistics, and NETCONF for configuration, going forward, or do we want to, over time, standardize on a single data model infrastructure (YANG?), that can then generate NETCONF, and possibly MIBs, if MIBs are still desired for operational data collection?  I'm in favor of a common data model definition, that can then be rendered into whatever protocols are deemed appropriate by the implementer.
> 
> Christopher
> 
>> 
>>    --Tom
>> 
>> 
>>> 
>>> Regards, Benoit
>>> 
>>> 
>>> 
>>>