Hi, Rob Shakir <[email protected]> wrote: > 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.
As Andy pointed out, there is some overlap in what you describe below with how NETCONF already works. This raises some concerns, see below. > * Intended and applied/actualised state are views of the running > configuration. In NETCONF terms, I think intended config is the "running" data store. Do you agree? In your picture, it is clear that the schema for "intended" and "applied/actual" is the same. Good. > * 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. This part is not clear to me. Again in NETCONF terms, "commit" is an operation to copy the contents of the candidate data store into the running data store. But if we agreed that running equals intended, I don't see what the explicit request would be to transition intended / running into applied/actual? In NETCONF, as soon as something is written into running (via an explicit edit-config towards running or via commit), that data is starting to be used internally in the system. NETCONF does not state that the write request must not return until the data has been "applied", so both asynchronous and synchronous implementations seems to be ok. It is not possible to write something into NETCONF's running data store (intended config) and prevent it from being used internally. > * 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. Ok. But see below. > * 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). Are you saying that in a synchronous system, if I write the config of a card that is not plugged in, my <commit/> will hang until the card has been 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. Ok, but there is a simpler solution to this ;-) > * 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). Ok. > 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. Actually, this is not what NETCONF's <get> gives you. It will give you intended + operational. But we could define a new rpc that gives you this in NETCONF. > + 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. /martin > > 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
