Re: [i2rs] Ephemeral State Requirements discussion

["Joel M. Halpern" <[e-mail]>]

Would a fair paraphrase of the point you are making here be
that the <ephemeral> data store could sit next to the <applied> data 
stored rather than either below or combined with it?

Yours,
Joel

On 5/31/16 2:48 PM, Juergen Schoenwaelder wrote:
> On Tue, May 31, 2016 at 02:27:12PM -0400, Joel M. Halpern wrote:
>
>> If I understood you correctly Juergen, you are suggesting using your
>> document:
>> https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
>> as a basis for addressing the I2RS requirements.
>
> No. All I am saying is that there are discussions underway basically
> triggered by openconfig ideas and that we need to find a common
> architectural model for the various datastores different groups like
> to have. The I-D cited above is input to this discussion. The
> discussion goes beyond I2RS concerns but still I2RS concerns should be
> considered by this discussion.
>
>> I am having trouble understanding how the approach in your document would
>> work for ephemeral configured information.
>> 1) The document says that such information is treated like other control
>> protocols.
>> 1a) How would one use NetConf or RestConf to write this?
>
> Via an ephemeral datastore. The difference is that this ephemeral
> datastore primarily interacts with operational state. This actually
> seems consistent since I2RS tends to favor to relate to state more
> than to config.
>
>> 1b) How would the controllable relationship with conventional configuration
>> be realized
>
> The ephemeral datastore overwrite, right? So an implementation pulls
> from the <applied> config datastore and the ephemeral datastore and
> the (+) function gives content from the ephemeral datastore
> preference.
>
>> 1c) How would the descriptions of this information be provided? (Arguably,
>> this last is not a requirements question, but it would help in understanding
>> your proposal.
>
> A YANG module. Perhaps I do not understand the question.
>
>> 2) Similarly, since operations have been segregated by datastore, how would
>> an I2RS client read the configured information to tell what was being
>> applied?
>
> Be careful with 'applied' since there now is an 'applied' datastore
> with very specific meaning. But in general, a client that wants to
> read one of the configuration datastores simply reads that datastore.
>
>> 3) How would the I2RS requirement for priority of operation be applied?
>
> It is the magic (+) function that merges <applied> config with
> <ephemeral> config leading to operational state.
>
>> 4) How would the requirement for reversion to configured values upon removal
>> of an I2RS modification be done?
>
> The magic (+) function would have to take care of it.
>
>> It is very hard as a reader to tell if your approach is acceptable, better
>> than, or worse than, the one we have on the table.
>
> I understand. The alternative model is to have <ephemeral> somewhere
> between <applied> and <operational state>. But then it seems people
> want <ephemeral> really behave more like other control plane protocols
> that also typically interact directly with <operational state>.
>
>> As far as I can tell, in terms of a consistent architecture for data stores,
>> both approaches consist of creating extra data stores when needed.
>
> Yes. But details matter. For example, <intended> and YANG
> configuration datastore validation are one thing, I tend to believe
> that I2RS validation really means something different. Hence I am
> pointing out that we need the I2RS requirements but then we
> (NETMOD/NETCONF people) also need to come up with an architectural
> model that considers things that are beyond I2RS' scope.
>
> /js
>