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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
