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
