Re: configuration: writable MIB modules versus NETCONF/YANG modules - part 2

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

> Hi,
>
> Comments inline.
>
> David Harrington
> [email protected] <javascript:;>
> +1-603-828-1401
> > -----Original Message-----
> > From: OPS-AREA [mailto:[email protected] <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 protected] <javascript:;>
> > https://www.ietf.org/mailman/listinfo/ops-area
>
> _______________________________________________
> OPS-AREA mailing list
> [email protected] <javascript:;>
> https://www.ietf.org/mailman/listinfo/ops-area
>

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