netmod-wg / opstate-reqs

draft-chairs-netmod-opstate-reqs
1 stars 0 forks source link

Provide a tighter definition of "applied configuration" #4

Open rgwilton opened 9 years ago

rgwilton commented 9 years ago

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:

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

mjethanandani commented 9 years ago

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:

einarnn commented 9 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

kwatsen commented 8 years ago

New terms were accepted in -00 draft (moving to DONE)