Provide a tighter definition of "applied configuration"

[rgwilton]

The definition of "applied configuration" is slightly vague, and there seems to be multiple interpretations of it on the WG alias, and hence a tighter specification of it would be useful.

In particular:

• does it include support for templating (as per openconfig-netmod-opstate-01 section 7.3.)?
• is it allowed to represent system created objects that have no corresponding configuration?
• how does it relate to the state of the system after a equivalent synchronous config commit (if at all)?

This issue tracks the predominant concern discussed in the thread that begins here:

• http://www.ietf.org/mail-archive/web/netmod/current/msg13528.html

[mjethanandani]

To this list I would add the question of whether applied configuration is a reflection that the configuration was written to a given location or does it imply that the configuration has taken effect. The difference can be as subtle as the example I cite in the netmod mailing list. Assume that the intended configuration was of assigning a IP address to an interface. Is applied configuration:

• The fact that the IP address was written to a register in hardware?
• An independent verification of the fact that the given interface can send/receive IP packets with that IP address?

[einarnn]

First, I think this is a very grey area.

My opinion is that the intended vs applied should at least initially go down as far as the management plane components that are consuming the configuration, and the applied configuration should start off representing whether or not the management plane thinks it has correctly configured the underlying control protocol components and data plane components correctly. I think that mandating it represent anything like the two examples Mahesh gives above is not feasible as the details of how configuration transition from the management plane to the data plane will differ across vendors and even across a single vendor's platforms.

I think, however, we need to plan for behavior like:

1. Management plane agent accepts configuration as valid, kicks off the sequence of actions that takes a configuration and instantiates it in the data plane.
2. Applied config is "updated" to match intended config.
3. Underlying data plane asynchronously signals back that it cannot support the requested configuration.
4. Applied config updates to not match intended config.

[3] above could happen as a direct result of [1] or it could even happen as the result of some other operation entirely. For example, a change to ACL configuration that results in a failed TCAM recompilation that causes collateral damage (this is a very real possibility in, for example, access switching).

[ggrammel]

suggest to explicitly spell out a verification process that SHOULD automatically be triggered when applying the intended config, but SHALL be supported when triggered by the client. Spelling out such operation may also simplify the discussion about synchronous and asynchronous

[kwatsen]

These terms were edited on today's call resulting in the following:

  * 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.

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

    NOTE: The system's ability to report applied configuration accurately
    may be limited in some cases, such as when the the configuration
    goes through an intermediate layer without an ability to inspect the
    lower layer.

If no objection is raise by tomorrow, this issue will be moved to the
EDIT state and I'll plan to make the change in the draft before Monday's
cutoff.

Moving issue to VERIFY state.

[kwatsen]

No objection made. Making edit to draft. Moving to REVIEW state.