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:[email protected]] Sent: Monday, June 06, 2016 1:44 PM To: Jeffrey Haas Cc: Susan Hares; 'Joel M. Halpern'; [email protected] 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: +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
