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

[Andy Bierman <[e-mail]>]

On Wed, Jun 24, 2015 at 7:57 PM, Anees Shaikh <[e-mail]> wrote:

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

The NETCONF WG has been asked by the I2RS WG to work on ephemeral
data (or configuration or whatever), so it is also high priority.

I2RS is not really "just control coming through a config channel".
It allows a controller to override device config and state in a standard way
based on machine-readable data models.  Instead of hand-coding
control protocols completely from scratch, after writing long complicated
RFCs,
just write a YANG module, turn the crank, and integrate. (That's the plan,
anyway ;-)



Andy



>
>>
>>
>> > * 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
>>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>