Anees Shaikh <[email protected]> wrote:
> Hi Martin,
>
> On Wed, Jun 24, 2015 at 1:03 PM, Martin Bjorklund <[email protected]> wrote:
>
> >
> > 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?
> >
>
> yes
>
>
> >
> > 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?
> >
>
> don't think of this as necessarily related to NETCONF terms (we didn't) --
> the commit operation on a system might be explicit or implicit as Rob
> mentioned. Transition to applied/actualized here doesn't mean copying from
> one datastore to another.
It wouldn't necessarily mean that in NETCONF either. Even if we
represented actual as a data store in the protocol, it's a conceptual
entity.
> It simply means that the config that is written
> to the running config may be applied at some later point. On some systems
> today, they translate a single configuration push to a series of CLI
> equivalents followed by an explicit command (again, per the CLI) -- there
> is no separate commit request required from the NMS; in this case the
> 'commit' is implicit from the perspective of the NMS.
>
>
> > 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.
> >
>
> Yes, that is clear now.
>
>
> >
> > It is not possible to write something into NETCONF's running data
> > store (intended config) and prevent it from being used internally.
> >
>
> Understood, for NETCONF behavior. But one could imagine a system that
> requires an explicit commit command to apply (or start applying) the
> configuration that was pushed to the running config.
But why would you call the config that exists before this explicit
command "intended"? If I copy all my config to a local file, with the
intention of applying it later, is that local file my "intended
config"? Hopefully not. My current "running" is still intended until
I replace it.
> You could argue that
> the config has to be staged somewhere analogous to a candidate datastore,
> but it could also just be a simple cache. In short, whether the transition
> from intended running to actual running is implicit or explicitly triggered
> is independent of NETCONF.
>
>
> > * 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?
> >
>
> No, if the system supports pre-configured interfaces (the favorite example
> it seems), it should apply the configuration and return when it has been
> applied. It is a valid applied configuration because the system supports
> pre-configured interfaces. The NMS should know that the "ok" that was
> returned doesn't necessarily mean that the interface is present and active
> -- and it would learn that from the oper-state value for the interface
> being set to not-present.
Rob wrote:
The success of the intended configuration becoming the applied
configuration may be due to time deltas or condition
So can you give an example of when the "commit" would hang until a
dependency have been fulfilled?
/martin
> > > * 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 probably have a different view of what that is :-)
>
>
> >
> > > * 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.
> >
>
> yes, a bit of confusion here. The actual configuration state (what has
> been applied) and the operational state are all part of the state, and
> marked config: false (or operational: true when that support is
> implemented). So the <get> should return all of the config: false nodes
> including applied config, counters, negotiated values, etc. You're right
> of course that is also returns the intended config (config: true nodes).
>
> >
> >
> > /martin
> >
> >
> > thanks.
> -- Anees
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
