The definition of intended configuration makes no reference to YANG. The network operator may be using multiple methods to configure aspects of the system, some of which may not be reflected in the YANG model. For the purposes of these discussions, is the intended configuration just that defined using the YANG model or all intended configuration?
From: Robert Wilton Sent: 01 October 2015 10:38 To: Kent Watsen;netmod@ietf.org Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration" 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
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
