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