On Wed, Sep 30, 2015 at 03:58:56PM +0000, Kent Watsen wrote:
> 
> Again, let's tackle a hard issue before tomorrow's interim meeting - this 
> time the definition of "applied configuration":
> 
> https://github.com/netmod-wg/opstate-reqs/issues/4
> 
> Currently, draft-chairs-netmod-opstate-reqs has this definition:
> 
>    o  applied configuration - this data represents the state that the
>       network element is actually in, i.e., that which is currently
>       being run by particular software modules (e.g., the BGP daemon),
>       or other systems within the device (e.g., a secondary control-
>       plane, or line card).
>

I think the phrase "represents the state that the network element is
actually in" is what we so far call operational state. I think what
people mean with applied configuration is way more narrow. Perhaps you
mean 'configuration state' instead of 'state'. This also applies to
the definition of 'intended configuration'. So here is a potential
rewrite of the definitions in draft-chairs-netmod-opstate-reqs-00.txt

   o intended configuration - this data represents the configuration
     state that the network operator intends the system to be in.
     This data is colloquially referred to as the 'configuration' of
     the system.

   o applied configuration - this data represents the configuration
     state that the network element is actually in, i.e., the
     configuration state which is currently being being used by system
     components (e.g., control plane daemons, operating system
     kernels, line cards).

This rewrite does not really address the questions that make up issue
#4. But let me again state that often the component consuming
configuration state is not able to remember whether a piece of its
state originated from a configuration subsystem or something else.  An
interface often only knows the set of addresses it has and it does not
know where the addresses originating from (a command line tool, a
configuration subsystem, a dhcp daemon, ...). And in order to
understand what a device is doing, it is necessary to look at all the
state (addresses in the example) of a component (an interface in the
example). I think it is a requirement that it is easy to retrieve all
operational state of a component.

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

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to