Re: [Netconf] operational state (WAS: New WGLC for a proposed new WG Charter ...)

[Ladislav Lhotka <[e-mail]>]

"t.petch" <[e-mail]> writes:

> ----- Original Message -----
> From: "Ladislav Lhotka" <[e-mail]>
> To: "t.petch" <[e-mail]>; "Juergen Schoenwaelder"
> <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, August 29, 2012 10:13 AM
>> "t.petch" <[e-mail]> writes:
>>
>> > ----- Original Message -----
>> > From: "Juergen Schoenwaelder" <[e-mail]>
>> > To: "t.petch" <[e-mail]>
>> > Cc: "Martin Bjorklund" <[e-mail]>; <[e-mail]>
>> > Sent: Sunday, August 26, 2012 10:23 PM
>> >> On Tue, Aug 21, 2012 at 11:17:32AM +0100, t.petch wrote:
>> >>
>> >> > I prefer 'ephemeral configuration' to operational state, since we
>> >> > have resolutely stated for 10 years than state is read only
> whereas
>> >> > configuration is written, so now to have writable state seems a
>> >> > bigger somersault than to have ephemeral configuration.
>> >>
>> >> I do not know why you believe that state is necessarily read only.
>> >
>> > Because most of what we have produced says so:-( and what we have
>> > produced reflects the discussions on the list).
>> >
>> > I remain unconvinced about the concept of operational state, that it
>> > is a meaningful concept.  Reading what the operators asked for in
>>
>> It is difficult to argue about these concepts without having their
> definintion. These premises make sense to me though:
>>
>> 1. Each device has a set of system parameters/structures that
> *directly* influence the device
>> behaviour, no matter how they were set (operator action, factory
> default, protocol, ...). I'd
>> suggest to define this set as the "operational state" of the device.
> Operators need to be able to
>> have one or more interfaces for viewing (a subset of) this set.
>
> Right, I have no problem with this, only that it is new and different to
> what we have previously discussed and is, for me, a fundamental change
> of view.  I always have had a problem with the Netconf/netmod split of
> configuration and state, seeing it as artificial.  Rather, what you
> define above, is what I would have called, pre-netmod/conf,
> configuration, by and large, with or without the epithet 'ephemeral', as
> I think that many others would do.  It does not matter how the routing
> (/forwarding) table entry got there, the routing table is part of the
> configuration.

Hmm, according to my definition, a routing table is a part of operational state. The term "configuration" is limited to the stuff explicitly written by the client/manager.

>
> I have always read RFC3535 as wanting
> - how to get a new box from the manufacturer operational
> - how to get a failing box working again by a variety of means
> and the netmod/conf view of configuration has focussed on the first
> which, while
> important, is not the whole story; and now we are starting to look at
> the whole story.
> Well, except that we are not, because it has been ruled out of scope pro
> tem:-(

Do you mean it has been ruled out of scope because Bert didn't accept my fourth charter item? It is not how I see it - in fact, I believe there is now a general consensus that the "whole story" has to be addressed. The only problem is that nobody has proposed anything concrete so far, and Bert rightly demanded that such proposal(s) be first submitted as individual drafts.

Lada

>
> Tom Petch
>
>> 2. In order to be able to control the device, operators need an
> interface for specifying their instructions for intended changes to the
> operational state and, consequently, device behaviour. I'd suggest to
> call these instructions a configuration. The device takes a submitted
> configuration and applies it according to a certain algorithm depending
> on the configuration, active network protocols, built-in policies etc.
>>
>> Examples of configuration interfaces are:
>>
>> - NETCONF (or CLI), where the operator's instructions have to be
> installed as the "running configuration".
>> - Unix init scripts, where the instructions are essentially shell
> scripts.
>> - RESTful interface, where the operational state is exposed as a set
> of resources and some of them may be modified via HTTP methods.
>>
>> Of course, the hard part is to define the relationship and
> interactions between a configuration and operational state. In the
> simplest case, a configuration parameter directly maps to an operational
> state parameter - the device may accept the configured value or not.
>>
>> But there are also more complicated mappings, e.g.:
>>
>> - One configuration parameter may disable a subsystem, i.e. a subtree
> in operational state.
>> - A list of configured entries get merged to a larger list which is a
> part of the operational state. An example is the routing table that
> contains static routes (= configuration) as well as routes learnt from
> routing protocols.
>>
>> > RFC3535,
>> > "Some devices make it very hard to determine
>> >         which parameters were administratively configured and which
>> >         were obtained via other mechanisms such as routing
>> >         protocols."
>> > I always think of the routing table and think that that is
> by-and-large
>> > a unique, if very common, problem and that trying to extrapolate
> from
>> > the routing table to all the other data in a box is not helpful -
> there
>> > is
>> > nothing else like a routing table.  The ARP cache has some
> similarities
>> > but is much simpler; MPLS FECs may be the other example.
>> >
>> > A separate problem is the interface up/down.  An operator has
> configured
>> > an interface as up and the box says down, because it knows best -
> the
>> > line
>> > card just blew a fuse.  This does have parallels elsewhere, with
> DHCP,
>> > and may be worth generalising but has little conceptually in common
>> > with routing tables IMO.
>>
>> Right, so the operator gave an instruction/request but the device
> knows better and doesn't accept it: the up/down parameter in operational
> state remains down.
>>
>> >
>> > Statistics are different in other ways.  Read only, but only sort
> of; it
>>
>> I think that statistics should be put aside and not considered a part
> of operational state - at least for the purpose of this discussion.
>>
>> Lada
>>
>> > is
>> > valuable to have a reset, so that counters may go to zero at
> midnight
>> > or some such.  SMI recognised statistics as different with Counters
>> > and that was good to have.  It struggled with the sheer volume of
> data -
>> > I once set a MIB walk going on the RMONMIB and if I had not shut
>> > the box down after several days, it would probably still be going
> some
>> > years later.  But I see nothing in common with the routing table
> problem
>> > and the interface status problem, just how to get meaningful
> information
>> > from masses of raw data, ie do the maths in the box and ship out the
>> > summary - and SMI did look at that but it did not seem
>> > to catch on.
>> >
>> > Tom Petch
>> >
>> >
>> > RFC
>> >> 6244 has some material in sections 4.3 and 4.4. The recommendation
>> >> given in section 4.4. is not really workable, as we find out
> working
>> >> on real data models in NETMOD.
>> >>
>> >> The first issue is that there is no standard way to retrieve
>> >> operational state other than duplicating large parts of the data
>> >> models, which seems costly and counter intuitive to modelers (who
> tend
>> >> to put config false objects next to config true objects). The get()
>> >> operation gives you a blend of operational state and configurat
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>
>

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