Re: [netmod] Follow up on the openconfig oper status and the NETMOD interim

[Anees Shaikh <[e-mail]>]

Hi Kent,


<snip>

>
>
>
> > If I can make some slight tweaks to the diagrams that have
> > been distributed:
>
> This looks like a variant of the picture I posted here:
> http://www.ietf.org/mail-archive/web/netmod/current/msg12738.html.   On
> one hand I'm happy to see this because no one had acknowledged the pic
> previously, but on the other hand, I'm concerned that you felt the need to
> draw another picture, implying there still being a gap...
>
> Actually, when looking at your picture, substituting running for intended,
> I think your picture is essentially the same as represented here:
> http://www.ietf.org/mail-archive/web/netmod/current/msg12729.html.  Of
> course, without ephemeral, running==intended, so your picture isn't wrong
> either.  I think the only difference is that your picture shows slides 2-4
> together, whereas mine had distinct slides.  Is there a more significant
> difference in your mind?
>

we actually took your followup picture as the basis for the one we drew,
i.e., the one with slides 3 and 4 combined (
http://www.ietf.org/mail-archive/web/netmod/current/msg12738.html).  You'll
see the main difference is that the applied config (what you call actual)
is part of the state (i.e., config: false
data).



> > * Intended and applied/actualised state are views of
> > the running configuration.
>
> Yes, but more precisely, running==intended when there is no ephemeral
> config, right?
>

I guess that's right, but as Rob said, we have not really considered a
separate type of config called ephemeral.  I personally view what we are
calling ephemeral as just control coming through a config channel (e.g.,
the i2rs case)



>
>
> > * 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.
>
> Yes but, again, the clients are interacting with the "running" and/or
> "ephemeral" (not directly to "intended").  The important bit is that
> "ephemeral" can override "running", so the "intended" is actually the
> result of a merge operation of sorts...
>

here by intended config, we mean what the intended change to the running
config is.


>
> > * 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.
>
> I see.  As stated on the call last week, NETCONF/RESTCONF are currently
> only "asynchronous" by this definition, as neither has any statement
> regarding *when* intended becomes operational wrt <ok/> or 200 OK.
> Dipping into design for a sec, it might be interesting to add an optional
> commit flag indicating that the server should not respond until
> actual==intended...
>

yes ... this is really down to implementations.  In some platforms, the
response comes back
once all involved downstream services have validated and applied the
requested config -- that would be considered synchronous in the way we have
been thinking about it.


>
> > * 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).
>
> Understood, at least for leafs that get a protocol negotiated value, which
> may account for just 1% of the configuration.   Dipping again into design,
> I was hoping we might use [XML/JSON] attributes, for instance:
>
>      leaf duplex {
>        type enumeration {
>          enum "half";
>          enum "full";
>          enum "auto";
>        }
>        config true;
>      }
>
>   get-config from running:
>        <duplex>auto</duplex>
>
>   get-operational:
>        <duplex intended="auto">full</duplex>
>

In the proposal laid out in the draft, you would be able see any
differences between intended, actual, and operational with <get> operation
since it would return config: true (intended) and config: false (actual +
negotiated) nodes.   I would view this a little differently as  (not really
netconf syntax):

get-config from running:
  <duplex>auto</duplex>

get:
  <duplex path=config/>auto</duplex>
  <duplex path=state/>auto</duplex>
  <negotiated-duplex path=state/>full</negotiated-duplex>

get-operational:
  <negotiated-duplex path=state/>full</negotiated-duplex>

In particular, notice that the actual config part of the state reflects the
intended value (either immediately or eventually), and if there is
additional state required to reflect a negotiated value, that is a separate
leaf marked operational: true in the model.



>
>
> Less understood is how to support the conditional enablement cases
> (https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00) such
> as plugging in a line card, or installing a license, or time-of-day.  For
> these, it's not clear what <get-operational> would return...
>
>
>
> > * 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.
>
> This is what I think config=false should be used for going forwards.  That
> is, as the example above shows, config=true simultaneously defines some
> nodes returned by <get-operational/>, thus we only need config=false to
> define the non-config based nodes like counters.
>

Agree this label makes sense, but if we agree that the applied (actual)
config is part of the state, then we would still need a way to get the
different types of state separately, i.e., the applied config vs. the
counters, negotiated values, etc.


>
> > * 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.
>
> Thanks for clarifying the motivation.  Looking at
> draft-openconfig-netmod-opstate, this requirement appears to be supported
> through tree-structure alone.  Is this solution sufficient or is there
> also a need to have something more explicit like XPath pointers in the
> data-model?
>

We've been able to make a good deal of progress with the data model pattern
in the draft and, at least at here internally, our NMS exploits that
structure to set and retrieve the different types of data we want to
compare.  We're still gaining experience with it.

thanks!
-- Anees



>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>