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":
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.
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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
