Re: [i2rs] Ephemeral State Requirements discussion

["Susan Hares" <[e-mail]>]

Juergen: 

A misconception you have below is that I2RS data models have mostly state.
There are the types of data models: 

1) ephemeral only - configuration and operational data 
2) mixed configuration - ephemeral augmentations to configuration
(bgp-global-config example used for config)
3) mixed operational state - ephemeral augmentations to operational state
(bgp-global-config  example used for state) 
4) some combination of 2 and 3 

Sue 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 31, 2016 2:49 PM
To: Joel M. Halpern
Cc: [e-mail]
Subject: Re: [i2rs] Ephemeral State Requirements discussion

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.

Sue: Not true.  See often repeated statements. 

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

Why are you assuming the applied data store.  It could also be done at the
intended data store before the data is resolved.   Example usage is:
ephemeral route overwrites a normal RIB Route and then needs to resolve
next-hop.   (See I2RS Ephemeral RIB and overwriting local configuration). 

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

I2RS RIB Data Model is a Yang model.

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

This does not answer Joel's question.  How does the I2RS client read an
applied I2RS RIB Data Model? 

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

Sue: Again, at what stage does this 

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

Sue: It would be good to see some definition of a "magical +" function in
order to review your specification. 

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

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

Sue:  Why is this the only place.  Why not a merge at the intended
configuration>?   "It seems people" - seems to indicate some source of
input.  Can you share this input to your design? 

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

Sue: Does this mean you feel you can ignore the I2RS requirements if you
feel it does not meet your architectural model? 


/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>

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