Hi Juergen,
On 01/10/2015 09:29, Juergen Schoenwaelder wrote:
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.
Is this the configuration that the operator sent to the device, or the
configuration that the device has accepted? In normal circumstance
these would be the same, but they would differ if the configuration
wasn't semantically valid and hence rejected by the system.
If your agree that it is the latter then would it be beneficial for the
description to include it?
E.g. perhaps something along the lines of:
intended configuration - this data represents the configuration
state that the network operator intends the system to be in, and that
has been accepted by the system as valid configuration. 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 text looks OK to me, although I wonder if it wouldn't be better to
not have the examples of system components, but I don't mind if they remain.
This rewrite does not really address the questions that make up issue
#4.
I think that is OK. I don't see that the other points necessary need to
be addressed in the description. I think that it would be sufficient if
they are expressed as requirements (or non requirements).
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.
I agree.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
