Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Oct 2015 10:29:26 +0200

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.

   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 rewrite does not really address the questions that make up issue
#4. 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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 1 Oct 2015 10:37:51 +0100

Hi Juergen,

>       This data is colloquially referred to as the 'configuration' of

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.

>       components (e.g., control plane daemons, operating system
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.

> #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
I agree.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Oct 2015 11:48:22 +0200

On Thu, Oct 01, 2015 at 10:37:51AM +0100, Robert Wilton wrote:
> >>Again, let's tackle a hard issue before tomorrow's interim meeting - this 
> >>time the definition of "applied configuration":
> >>

Yes, I silently assumed that the configuration has gone through
validation.

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

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 1 Oct 2015 10:58:38 +0100

On 01/10/2015 10:48, Juergen Schoenwaelder wrote:
> line card and the ASICs finally have taken note of it?

>   I agree this is
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

---

From: Jonathan Hansford <[email-masked]>
Date: Thu, 1 Oct 2015 12:03:16 +0100

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;[email-masked]
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration"

Hi Juergen,

I agree.

Thanks,
Rob

> /js

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Robert Wilton <[email-masked]>
Date: Thu, 1 Oct 2015 13:12:46 +0100

I would presume that all the definitions and requirements can only be in 
the context of YANG and associated management protocols, otherwise the 
scope is too broad.

Thanks,
Rob

On 01/10/2015 12:03, Jonathan Hansford wrote:
>
> 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;[email-masked]
> *Subject: *Re: [netmod] opstate-reqs #4: Provide a tighter definition 
> of"applied configuration"
>
> Hi Juergen,
>
> >> Again, let's tackle a hard issue before tomorrow's interim meeting 
> - this time the definition of "applied configuration":
>
> >>
>

---

From: Jonathan Hansford <[email-masked]>
Date: Thu, 1 Oct 2015 13:18:54 +0100

It would be useful if that clarification were included up front for clarity.

Jonathan

From: Robert Wilton
Sent: 01 October 2015 13:12
To: Jonathan Hansford;Kent Watsen;[email-masked]
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"appliedconfiguration"

I would presume that all the definitions and requirements can only be in the context of YANG and associated management protocols, otherwise the scope is too broad.

Thanks,
Rob

From: Robert Wilton

Hi Juergen,

 

 

I agree.
 
Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 1 Oct 2015 13:27:10 +0100

On 30/09/2015 16:58, Kent Watsen wrote:
>
> Again, let's tackle a hard issue before tomorrow's interim meeting – 
> this time the definition of "applied configuration":
>
> But, as Robert states in the issue:
>
>     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.
>

Specifically for these three points:

>     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?

Requirement 1.D states

      D.  For asynchronous systems, when fully synchronized, the data
            in the applied configuration is the same as the data in the
            intended configuration.

So, if this requirement statement stands as being valid (which I think 
it should) then that would imply that the answer for both the two issues 
above must be "no".  The only question would be whether these need to be 
explicitly listed out?

>       - how does it relate to the state of the system after a 
> equivalent synchronous config commit (if at all)?

Again, I think that definition of requirement 1.D, along with the 
proposed definition of synchronous configuration operation vs 
asynchronous configuration operation, will provide a sufficient answer 
to this question.  I.e. that the state of the system after an 
asynchronous config operation must, when fully synchronized, be the same 
as the state of the system after an equivalent synchronous configuration 
operation completes and replies back.

Thanks,
Rob

>
>
> Already Mahesh and Einar have posted comments on the GitHub issue 
> tracker.   Please first read the comments posted there and then 
> continue the discussion here on the mailing list (not on the GitHub 
> issue tracker).
>
> PS: This issue is highly related to issue #5, which was also just 
> opened for discussion on the mailing list.
>
> Thanks,
> Kent
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Oct 2015 18:00:48 +0000

Thank you Robert for bringing the discussion back to the github issues.

Robert writes:

> 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?
>
> Requirement 1.D states

>
> So, if this requirement statement stands as being valid (which I think it should) then that would imply that the answer for both the two issues above must be "no".  The only question would be whether these need to be explicitly listed out?

[KENT] so I think I have to (begrudgingly) agree with your logic.    I have heard the operators state that they want the intended/applied comparison to be drop-dead simple.  To that end, it would not be possible to flatten templates or apply defaults, or make any other change - it needs to be as close as possible to a carbon-copy of the original intended configuration (where deviations are allowed only for cases like a missing line-card).  To this end, yes, I think that we could tack on a statement like the following:

That is, the intended configuration is a subset of the applied
configuration where omissions are only due to when the
configuration cannot be applied (e.g., a missing line-card).

What do you think?

>>  - how does it relate to the state of the system after a equivalent synchronous config commit (if at all)?
>>
> Again, I think that definition of requirement 1.D, along with the proposed definition of synchronous configuration operation vs asynchronous configuration operation, will provide a sufficient answer to this question.  I.e. that the state of the system after an asynchronous config operation must, when fully synchronized, be the same as the state of the system after an equivalent synchronous configuration operation completes and replies back.

[KENT] I agree with this, but I think it impacts issue #6 more so than issue #4 - right?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Oct 2015 11:56:59 -0700

On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen <[email-masked]> wrote:

> [KENT] so I think I have to (begrudgingly) agree with your logic.    I
> have heard the operators state that they want the intended/applied
> comparison to be drop-dead simple.  To that end, it would not be possible
> to flatten templates or apply defaults, or make any other change – it needs
> to be as close as possible to a carbon-copy of the original intended
> configuration (where deviations are allowed only for cases like a missing
> line-card).  To this end, yes, I think that we could tack on a statement
> like the following:
>

I am wondering why operators would want to compare 2 massive subtrees
in the first place, where 1 is static and the other is changing constantly.

Do they really want this complex task or do they just want to
determine if the intended config has been applied yet?

Andy

> proposed definition of synchronous configuration operation vs asynchronous
> configuration operation, will provide a sufficient answer to this
> question.  I.e. that the state of the system after an asynchronous config
> operation must, when fully synchronized, be the same as the state of the
> system after an equivalent synchronous configuration operation completes
> and replies back.
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Oct 2015 19:15:14 +0000

> determine if the intended config has been applied yet?

I think that it is more the latter.   And there have been suggestions for solutions to provide something like a yang-patch to describe just the diffs.  Makes sense to me!

K.

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Cc: Robert Wilton <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"

On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

What do you think?

Andy

Thanks,
Kent

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Robert Wilton <[email-masked]>
Date: Wed, 14 Oct 2015 22:28:07 +0100

On 14/10/2015 20:15, Kent Watsen wrote:
> I think that it is more the latter.   And there have been suggestions 
> for solutions to provide something like a yang-patch to describe just 
> the diffs.  Makes sense to me!

The NMS already knows the intended config since it sent it to the device 
in the first place, so in normal circumstances I would expect the NMS to 
only query the applied config (and possibly derived state at the same 
time) and then compare it to the NMS's view of the intended cfg for that 
device.  If the NMS is smart then it might be able to restrict most of 
the queries to only the device's applied config sub-trees that could 
possibly be out of sync, perhaps with periodic full synchronization checks.

Otherwise, I think that a function that returns just the diff may also 
be useful (the draft that I put forward also proposes a diff-cfg-only 
option).  However, it is also worth noting that the original 
requirements don't explicitly ask for this, so perhaps more of a nice to 
have than a formal requirement?

Thanks,
Rob

>
> K.
>
>
> From: Andy Bierman <[email-masked] <mailto:[email-masked]>>
> To: Kent Watsen <[email-masked] <mailto:[email-masked]>>
> Cc: Robert Wilton <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>     > So, if this requirement statement stands as being valid (which I
>     think it should) then that would imply that the answer for both
>     the two issues above must be "no".  The only question would be
>     whether these need to be explicitly listed out?
>
>     [KENT] so I think I have to (begrudgingly) agree with your logic.
>        I have heard the operators state that they want the
>     intended/applied comparison to be drop-dead simple.  To that end,
>     it would not be possible to flatten templates or apply defaults,
>     or make any other change – it needs to be as close as possible to
>     a carbon-copy of the original intended configuration (where
>     deviations are allowed only for cases like a missing line-card). 
>     To this end, yes, I think that we could tack on a statement like
>     the following:
>
>     > Again, I think that definition of requirement 1.D, along with
>     the proposed definition of synchronous configuration operation vs
>     asynchronous configuration operation, will provide a sufficient
>     answer to this question.  I.e. that the state of the system after
>     an asynchronous config operation must, when fully synchronized, be
>     the same as the state of the system after an equivalent
>     synchronous configuration operation completes and replies back.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 14 Oct 2015 22:43:58 +0100

On 14/10/2015 19:00, Kent Watsen wrote:
> think it should) then that would imply that the answer for both the 
> two issues above must be "no".  The only question would be whether 
> these need to be explicitly listed out?
>
> comparison to be drop-dead simple.  To that end, it would not be 
> possible to flatten templates or apply defaults, or make any other 
> change – it needs to be as close as possible to a carbon-copy of the 
> original intended configuration (where deviations are allowed only for 
> cases like a missing line-card).  To this end, yes, I think that we 
> could tack on a statement like the following:
>
> asynchronous config operation must, when fully synchronized, be the 
> same as the state of the system after an equivalent synchronous 
> configuration operation completes and replies back.
>

The original question that I was responding to was recorded in the 
description of issue #4, but I agree that this is also effectively 
covered by the proposed descriptions for #6 anyway.

Thanks,
Rob

---

From: Jonathan Hansford <[email-masked]>
Date: Thu, 15 Oct 2015 09:55:01 +0100

The NMS only knows the intended config if it is the only NMS capable of changing that device’s config. That may not always be the case.

Jonathan

From: Robert Wilton
Sent: 14 October 2015 22:28
To: Kent Watsen;Andy Bierman
Cc: [email-masked]
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration"

The NMS already knows the intended config since it sent it to the device in the first place, so in normal circumstances I would expect the NMS to only query the applied config (and possibly derived state at the same time) and then compare it to the NMS's view of the intended cfg for that device.  If the NMS is smart then it might be able to restrict most of the queries to only the device's applied config sub-trees that could possibly be out of sync, perhaps with periodic full synchronization checks.

Otherwise, I think that a function that returns just the diff may also be useful (the draft that I put forward also proposes a diff-cfg-only option).  However, it is also worth noting that the original requirements don't explicitly ask for this, so perhaps more of a nice to have than a formal requirement?

Thanks,
Rob

K.

From: Andy Bierman <[email-masked]>
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen <[email-masked]>
Cc: Robert Wilton <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"

> So, if this requirement statement stands as being valid (which I think it should) then that would imply that the answer for both the two issues above must be "no".  The only question would be wheth…
[KENT] so I think I have to (begrudgingly) agree with your logic.    I have heard the operators state that they want the intended/applied comparison to be drop-dead simple.  To that end, it would not be possible to flatten templates or apply defaults, or make any other change – it needs to be as close as possible to a carbon-copy of the original intended configuration (where deviations are allowed only for cases like a missing line-card).  To this end, yes, I think that we could tack on a statement like the following:

What do you think?

Andy

Thanks,
Kent

---

From: Robert Wilton <[email-masked]>
Date: Thu, 15 Oct 2015 10:50:42 +0100

Hi Jonathan,

Yes, of course, in the general case your statement is completely true.

I think that my premise would still hold if either:
  - there is coordination of the intended configuration between multiple NMS
  - responsibility for parts of the configuration is split between 
multiple NMS and they are each independently responsible for ensuring 
that their part of the configuration has been programmed correctly.

My point is really that I would more naturally expect the definitive 
configuration for a device to be known and held (perhaps in a 
distributed fashion) somewhere in the operators management network, not 
on the device itself.

Thanks,
Rob

On 15/10/2015 09:55, Jonathan Hansford wrote:
>
> The NMS only knows the intended config if it is the only NMS capable 
> of changing that device’s config. That may not always be the case.
>
> Jonathan
>
>
> *From: *Robert Wilton
> *Sent: *14 October 2015 22:28
> *To: *Kent Watsen;Andy Bierman
> *Cc: [email-masked]
>     I think that it is more the latter.   And there have been
>     suggestions for solutions to provide something like a yang-patch
>     to describe just the diffs.  Makes sense to me!
>
>
> The NMS already knows the intended config since it sent it to the 
> device in the first place, so in normal circumstances I would expect 
> the NMS to only query the applied config (and possibly derived state 
> at the same time) and then compare it to the NMS's view of the 
> intended cfg for that device.  If the NMS is smart then it might be 
> able to restrict most of the queries to only the device's applied 
> config sub-trees that could possibly be out of sync, perhaps with 
> periodic full synchronization checks.
>
> requirements don't explicitly ask for this, so perhaps more of a nice 
> to have than a formal requirement?
>
> Thanks,
> Rob
>
>
>
>     K.
>
>     *From: *Andy Bierman <[email-masked] <mailto:[email-masked]>>
>     *Date: *Wednesday, October 14, 2015 at 2:56 PM
>     *To: *Kent Watsen <[email-masked] <mailto:[email-masked]>>
>     *Cc: *Robert Wilton <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     *Subject: *Re: [netmod] opstate-reqs #4: Provide a tighter
>     definition of "applied configuration"
>
>         > So, if this requirement statement stands as being valid
>         (which I think it should) then that would imply that the
>         answer for both the two issues above must be "no".  The only
>         question would be whether these need to be explicitly listed out?
>
>         [KENT] so I think I have to (begrudgingly) agree with your
>         logic.    I have heard the operators state that they want the
>         intended/applied comparison to be drop-dead simple.  To that
>         end, it would not be possible to flatten templates or apply
>         defaults, or make any other change – it needs to be as close
>         as possible to a carbon-copy of the original intended
>         configuration (where deviations are allowed only for cases
>         like a missing line-card).  To this end, yes, I think that we
>         > Again, I think that definition of requirement 1.D, along
>         with the proposed definition of synchronous configuration
>         operation vs asynchronous configuration operation, will
>         provide a sufficient answer to this question.  I.e. that the
>         state of the system after an asynchronous config operation
>         must, when fully synchronized, be the same as the state of the
>         system after an equivalent synchronous configuration operation
>         completes and replies back.
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 15 Oct 2015 16:54:52 +0000

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.

Kent

From: Robert Wilton <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 15, 2015 at 5:50 AM
To: Jonathan Hansford <[email-masked]<mailto:[email-masked]>>, Kent Watsen <[email-masked]<mailto:[email-masked]>>, Andy Bierman <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration"

Hi Jonathan,

I think that my premise would still hold if either:
 - there is coordination of the intended configuration between multiple NMS
 - responsibility for parts of the configuration is split between multiple NMS and they are each independently responsible for ensuring that their part of the configuration has been programmed correctly.

My point is really that I would more naturally expect the definitive configuration for a device to be known and held (perhaps in a distributed fashion) somewhere in the operators management network, not on the device itself.

Thanks,
Rob

Jonathan

From: Robert Wilton
Sent: 14 October 2015 22:28
To: Kent Watsen;Andy Bierman
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration"

Thanks,
Rob

K.

From: Andy Bierman <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>

On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

           intended configuration.

What do you think?

Andy

Thanks,
Kent