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

[Kent Watsen <[e-mail]>]

[As an individual contributor]


Hi Rob and OC team,


> 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.

Indeed!


> 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 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.

Yup


> * Intended and applied/actualised state are views of
> the running configuration.

Yes, but more precisely, running==intended when there is no ephemeral
config, right?


> * 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...


> * 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...


> * 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>


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.


> * 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?


Thanks again,
Kent