On 01/10/2015 10:48, Juergen Schoenwaelder wrote:
On Thu, Oct 01, 2015 at 10:37:51AM +0100, Robert Wilton wrote:
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.
Yes, I silently assumed that the configuration has gone through
validation.
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.
The examples were there in the original text but I factored them out
into text that went into parenthesis. I think it is good to include
the examples since we do have an open debate what 'applied' really
means - is something applied if the kernel knows about it or is
something applied if the kernel has communicated it all the way to a
line card and the ASICs finally have taken note of it?
I agree this is
a very grey area and we probably need to add text below the definition
of the term 'applied configuration' that acknowledges that this is
grey area and the definition of applied configuration is fuzzy here by
design.
I agree.
The definition of applied configuration should be tight enough that it
is sufficient to be useful to the operators, but fuzzy enough that it is
pragmatically feasible for the wide range of devices to actually comply
with the definition.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
