Re: [i2rs] Ephemeral State Requirements discussion

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

Juergen: 

I2RS Ephemeral Configuration - is configuration which needs validation, but
does not survive a reboot. 

I2RS data models which are "ephemeral at top node" and have operational
state.  In these models, the operational state is like all other operational
state.  

I suggest we focus on the I2RS ephemeral Configuration.  On this topic you
stated below: 
 
"Again, for configuration datastores, I can obtain the config and validate
it pretty much anywhere, on the device or offline at a controller. My
understanding is that this would not be true for I2RS'
ephemeral stat datastores; I would need some amount of additional data to do
something close to YANG's configuration datastore validation." 

Why is this not true for ephemeral datastore?  I am missing any reason why
you think this is true. 

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[e-mail]] 
Sent: Monday, June 06, 2016 1:44 PM
To: Jeffrey Haas
Cc: Susan Hares; 'Joel M. Halpern'; [e-mail]
Subject: Re: [i2rs] Ephemeral State Requirements discussion

On Thu, Jun 02, 2016 at 10:27:33AM -0400, Jeffrey Haas wrote:
> Juergen,
> 
> On Wed, Jun 01, 2016 at 11:19:53AM +0200, Juergen Schoenwaelder wrote:
> > On Tue, May 31, 2016 at 04:27:51PM -0400, Susan Hares wrote:
> > >>  How does ephemeral sitting next to the <applied> data store 
> > >>  provide the ability to augment configuration with ephemeral 
> > > > configuration or operational state with ephemeral operational state?
> > >
> > At the schema level, you will augment the schema tree. If the 
> > > current separation of /foo and /foo-state would go away, this will 
> > > likely get simpler (but this is orthogonal to the question how an 
> > > <ephemeral> datastore conceptually interacts with the other
datastores).
> > >
> > >At the data tree level, there is a magic merging (+) function 
> > >involved that takes configuration data from a configuration 
> > >datastore and data from an ephemeral data store and produces the 
> > >resulting operational state. The idea was to not further detail how 
> > >this is achieved and instead treat an ephemeral datastore pretty 
> >> much like any other control plane interface interacting with
<operational state>.
>>
>> While such a solution-space seems mostly right, I had been under the 
> >impression that the interactions necessary for validation meant that 
> >ephemeral needed to move up closer to the top of your diagram.
>>
> >Note that I'm not saying I2RS requires validation, however the lack of 
> >validation has been a contentious point in prior discussions.
>> 
> >To confirm my understanding, ephemeral configuration state in the 
> >model you're proposing above is treated as operational state (the 
> >output of the netconf <get> operation for config true elements)?

> For configuration datastores, we have a reasonably precise definition what
validation means. And this comes for a price, e.g., config true nodes are
not allowed to refer to config false nodes. The reason is that validate
should work on the configuration data and it should not depend on the
operational state a device is in.

My understanding is that I2RS wants to inject data that modifies state that
might be purely operational state, e.g., state in a routing table obtained
from a routing protocol. If this is correct, then the ephemeral state
datastore is closer to the ephemeral state and pretty detached from
configuration datastores and likely it needs its own validation rules (if
they are needed at all).
 

Again, for configuration datastores, I can obtain the config and validate it
pretty much anywhere, on the device or offline at a controller. My
understanding is that this would not be true for I2RS'
ephemeral stat datastores; I would need some amount of additional data to do
something close to YANG's configuration datastore validation.

/js

PS: I think 'ephemeral state datastore' is actually a misnomer. The
    fact that the datastore I2RS is looking for is ephemeral is a
    property of this datastore but there are likely more important
    characteristics that should determine its name. But I have no good
    suggestion and this is perhaps a discussion to have at some later
    point in time.

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