Subject: Re: [Netconf] [OPSAWG] config persistence

From: t.petch <[email-masked]>
Date: Mon, 2 Jun 2014 10:46:49 +0100

----- Original Message -----
From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
To: "Andy Bierman" <[email-masked]>; "Ladislav Lhotka"
<[email-masked]>
Cc: "Netconf" <[email-masked]>
Sent: Saturday, May 31, 2014 12:23 AM
Subject: Re: [Netconf] [OPSAWG] config persistence

I think NETCONF is explicit about the semantics of the running
configuration.
The system MUST be aware of the desired state of the system as embodied
in the running datastore.  The system uses that information, along with
all
sorts of other information, to perform its functions.  The resulting
operational
state will be data model and implementation specific.

I understand the text above identifies running datastore with "desired
state" (vs. operational state ?)

>From RFC 6241:
"running configuration datastore: A configuration datastore holding
      the complete configuration currently active on the device."
"A configuration datastore is defined as the complete set of
configuration data that
   is required to get a device from its initial default state into a
desired operational state."

I could not find a definition of "active configuration" in the RFC.
But considering the second snippet, I understand that, in the absence of
stimuli, the contents of the running datastore and the operational state
must be eventually consistent.
Is this correct?

<tp>
Reading that question, I am uncertain whether or not you are using the
terminology as NETCONF does.

Configuration, as you quote, is what it take to get the box up, but is
restricted to what you might put in through the CLI, or some such.  The
rest of the data on the box is state, which can be divided into
read-only statistics and operational state, the latter being the data
learnt from protocols - DHCP, BGP, NTP, IS-IS ... - and data generated
by the box when, eg, a card is hot plugged and the box dynamically
generates an entry in the interface list for it.

So, the "running datastore" consists of the running configuration,
statistics and operational state.  The operational state does not exist
anywhere else, in NETCONF terminology, so there is nothing for it to be
consistent with; and it is only as stable as the protocols that update
it, whereas the running configuration stays the same until it is updated
by NETCONF (or, perhaps, by another configuration protocol, such as CLI,
SNMP, ... although little is said in the NETCONF RFC about the
interactions between the different ways of configuring a box, a topic
that recurs on this list).

The active configuration is not defined AFAIK but I think is clearly the
configuration that the box is currently using, as appears in the running
configuration datastore, as distinct from a configuration in the
candidate, startup or user-defined configuration datastores.

Note that in RFC6241, almost every use of the term datastore is
qualified by the term configuration, hinting, but never quite saying,
that the use of the term datastore without qualification means something
more general, and I have used "datastore" in that way just above using
quotes to suggest that my use thereof is a bit flaky.  Most other RFC
are not so precise in the use of the term datastore and use it without
qualification when the context makes it fairly clear that configuration
datastore is implied.  And in an e-mail, when someone uses the term
datastore, it may be impossible to tell whether they have a
configuration datastore or some other kind of datastore in mind:-(

Tom Petch

That would mean that if the desired state would stop being operational
(say this is caused by some permanent failure) or could not be made
operational, the running datastore contents should change.

Thanks,

Alberto

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

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>