Hi netmod, Thanks very much to everyone that has considered the problem that we laid out on the last interim call. I think we’re starting to reach a common understanding.
If I can make some slight tweaks to the diagrams that have been distributed: And some further clarifying points/explanations: We have not been considering ephemeral and startup as separate items. As far as we see these, the startup is simply a subset of the intended state that happens to persist after a system reboot, or seed the initial set of intended states when the system restarts. Ephemeral state is simply intended state that is not persistent. Intended and applied/actualised state are views of the running configuration. All intention is written to the intended configuration (whether it be by CLI, a human, an NMS via NETCONF, a system agent, etc.) – which then transitions to becoming the applied/actualised configuration. This is based on either an explicit request to do so (‘commit’) or may be implicit. The success of the intended configuration becoming the applied configuration may be due to time deltas or condition, as Kent drew. In what we referred to as a ‘synchronous’ system – we expect the attempt to make the intended state transition to the actual state to be completed when the operation returns (e.g., after a <commit />) then the <ok /> should return only when this intention has been applied. We require the ability for an NMS to be able to see both the intended and the actual configuration – such that it can check whether its intention is currently the applied configuration, or has not yet been applied due to some external dependency (e.g., line card not plugged in). A portion of the operational state date (marked operational: true) is the set of variables that are not related to state that an external system can assert the value of — for example, a counter, or a negotiated protocol timer. We believe that there is an important advantage in being able to syntactically / structurally retrieve the set of state that is associated with some set of intended state. This is not ‘easy’ today, as there is no common way to link the two – especially as models are composed. This does not imply that we understand the semantics of that set of state – but simply that we can retrieve all state data that relates to a particular entity that we expressed some intention about (e.g., all state data that corresponds to a particular interface or BGP peer). This division is very important, since there is separation between elements of the NMS that interact with the network, and those that do need to understand the semantics/contents of the data leaves. For some OpenConfig operators, this separation of concerns is part of their current NMS software architecture. In terms of accessing subsets of leaves, we need to be able to: Retrieve the intended state – this is done with a method that does similar to get-config in NETCONF. Retrieve the actual + operational state of the device – done with a method similar to get. Retrieve only the operational state – done with a method such as get-operational. This means that we need to be able to distinguish intended/actual/operational variables leaves through the data model. We did not define a requirement for a get-actual type call in openconfig-opstate, but there may be solutions that do want something like this (as per Benoit’s mail to the netmod list yesterday, where it is referenced as get-config-false). We do not require that the two trees for intended and actual have identical paths in the data model. They are the same set of leaves – but it MUST be possible to check both. In openconfig-opstate then we consistently achieve this by having the same set of leaves (typically grouping FOO-config) that is included under both container config (where they are intended) and container state (where they are applied)). Since there is a common way to be able to relate these through the structure, then this is OK for us. Thanks again. Kind regards, Anees, Marcus & Rob. On 23 June 2015 at 16:44:36, Benoit Claise ([email protected]) wrote: Dear all, In order to clarify the situation, I compiled some points from my notes and created a couple of diagrams. This was initially created for my personal use, but if it helps with the discussion, please use it. The first open issue is terminology IMO. - intended, applied - synchronous/asynchronous There are two synchronous levels: the protocol (NETCONF) and network element implementation. As Kent mentioned: "Kent NETCONF is a synchronous protocol but state may change asynchronously." It would beneficial for the authors to explain what happens in the following NETCONF server two cases: - an example of (non-NETCONF) asynchronous: RPC and leaf update (first intended, then applied) - example of full NETCONF synchronous: RPC and leaf update. In this case, duplicate leaf. The second open issue is that it's not clear which exact features are requested: a breakdown per RFC6087bis, per YANG language, and per NETCONF would help. This is what I've been trying to do with the couple of attached pictures. I would like to get confirmation from the openconfig that the understanding is right. […snip images…] Some additional questions: - Don't we need an extra /startup for startup parameters? Or startup parameters will always be the intended configuration? - "The way we represent op-state must be consistent across all models" What if one of the models is not consistent? In that case, only the description will make the link between the config-false and config-true leaf, right? So don't we need that link anyway? That makes the link to "Ability to relate configuration to operational state must be consistent". _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
