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