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

----- Original Message -----
From: "ietfdbh" <[email protected]>
To: "'Juergen Schoenwaelder'" <[email protected]>;
"'Adrian Farrel'" <[email protected]>
Cc: "'ops-area'" <[email protected]>
Sent: Friday, February 28, 2014 10:31 PM
> Comments inline.
>
> David Harrington
> [email protected]
> +1-603-828-1401
> > -----Original Message-----
> > From: OPS-AREA [mailto:[email protected]] On Behalf Of
Juergen
> > Schoenwaelder
> > Sent: Friday, February 28, 2014 3:43 PM
> > To: Adrian Farrel
> > Cc: 'ops-area'
> > 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.
> 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.

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

> 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?
>
> > >
> > > 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]
> > https://www.ietf.org/mailman/listinfo/ops-area
>
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area