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

2015-10-15 Thread Jonathan Hansford 
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: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied 
configuration"



On 14/10/2015 20:15, Kent Watsen wrote:
Andy writes:
> 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?

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 <a...@yumaworks.com>
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen <kwat...@juniper.net>
Cc: Robert Wilton <rwil...@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied 
configuration"



On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen <kwat...@juniper.net> wrote:

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

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


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




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



___
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

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

2015-10-15 Thread Robert Wilton 

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: *netmod@ietf.org
*Subject: *Re: [netmod] opstate-reqs #4: Provide a tighter definition 
of"applied configuration"


On 14/10/2015 20:15, Kent Watsen wrote:

Andy writes:

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

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 <a...@yumaworks.com <mailto:a...@yumaworks.com>>
*Date: *Wednesday, October 14, 2015 at 2:56 PM
*To: *Kent Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>
*Cc: *Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>>, "netmod@ietf.org
<mailto:netmod@ietf.org>" <netmod@ietf.org <mailto:netmod@ietf.org>>
    *Subject: *Re: [netmod] opstate-reqs #4: Provide a tighter
definition of "applied configuration"

On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen <kwat...@juniper.net
<mailto:kwat...@juniper.net>> wrote:

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

 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?

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

I am wondering why operators would want to compare 2 ma

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

2015-10-15 Thread Kent Watsen 

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 <rwil...@cisco.com<mailto:rwil...@cisco.com>>
Date: Thursday, October 15, 2015 at 5:50 AM
To: Jonathan Hansford <jonat...@hansfords.net<mailto:jonat...@hansfords.net>>, 
Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, Andy Bierman 
<a...@yumaworks.com<mailto:a...@yumaworks.com>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied 
configuration"

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: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied 
configuration"



On 14/10/2015 20:15, Kent Watsen wrote:
Andy writes:
> 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?

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 
<<mailto:a...@yumaworks.com>a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>
Cc: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied 
configuration"



On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen 
<<mailto:kwat...@juniper.net>kwat...@juniper.net<mailto:kwat...@juniper.net>> 
wrote:

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 sys

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

2015-10-14 Thread Kent Watsen 

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

 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?

[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


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2015-10-14 Thread Andy Bierman 
On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen  wrote:

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


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


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

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

2015-10-14 Thread Robert Wilton 



On 14/10/2015 20:15, Kent Watsen wrote:

Andy writes:
> 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?

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 <a...@yumaworks.com <mailto:a...@yumaworks.com>>
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>
Cc: Robert Wilton <rwil...@cisco.com <mailto:rwil...@cisco.com>>, 
"netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org 
<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of 
"applied configuration"




On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen <kwat...@juniper.net 
<mailto:kwat...@juniper.net>> wrote:



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

  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?

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



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




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



___
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2015-10-14 Thread Robert Wilton 



On 14/10/2015 19:00, Kent Watsen wrote:


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


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


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





Thanks,
Kent




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2015-10-01 Thread Robert Wilton 

Hi Juergen,

On 01/10/2015 09:29, Juergen Schoenwaelder wrote:

On Wed, Sep 30, 2015 at 03:58:56PM +, 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

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

2015-10-01 Thread Juergen Schoenwaelder 
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 +, 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.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2015-10-01 Thread Juergen Schoenwaelder 
On Wed, Sep 30, 2015 at 03:58:56PM +, 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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2015-09-30 Thread Kent Watsen 

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

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.

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


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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod