On Fri, May 2, 2014 at 10:10 AM, Thomas Nadeau <[email protected]>wrote:
> > On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman <[email protected]> > wrote: > > > > > On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder < > [email protected]> wrote: > >> On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote: >> > On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: >> > > I picture the operational state as the mixing bowl for the 2 config >> sources >> > > and data learned from protocols and system events. It seems >> > > both NETCONF and I2RS would be able to pick the data is cares about >> > > out of that. >> > >> > I think this is what I'd like to see personally. >> > >> > > This is a weakness in YANG that may get improved in YANG 1.1. >> > > Since it is officially just for NETCONF, there are no mechanisms >> > > (other than vendor extensions) to tag the data as specific to >> > > some subset of protocols. >> > >> > As I mentioned elsewhere, I'm hoping we don't go down the path of >> "editable >> > operational state", instead configuration semantics for our purposes. >> >> At some point in time, we need to get the terminology sorted out. NC >> has well defined configuration datastores and YANG has a well defined >> concept of configuration data (config true). NC kind of assumes that >> data in configuration datastores has an associated concept of >> persistence (e.g., changes to <running/> persist unless you have an >> explicit <startup/>, <candidate/> is a temporary scratch pad). >> >> We are talking about another writable datastore (or potentially >> multiple of them). Some call the data in this writable datastore >> configuration, others prefer to use a different term to avoid a clash >> with what NC and YANG consider configuration. If we could find a good >> name for such writable datastores, I likely make communication much >> simpler. >> >> And yes, I think the model that the contents of the configuration >> datastore, the writable datastore(s) as well as the information >> learned dynamically from various control plane protocols all lead to >> the final operational state. (In fact, one could consider a model >> where control plane protocols all conceptually come into the system >> via additional control protocol specific writable datastores.) >> >> So, can we find a name for these 'other writable datastores' and then >> use that term instead of 'writable operational state', 'ephemeral >> config', 'i2rs datastore', etc.? >> >> > I imagine I2RS will be completely separate from NETCONF and it should > have its own datastore -- so "i2rs-config" is appropriate because I2RS is > the > only protocol using that datastore. The combined "operational state" > is not editable. > > > Yes, that makes sense. Then if at some point in time you want to save > the running config (i2rs), the system has to explicitly copy it over. But > until then, > its separate. The only question is: what is the complete running config > represented as? > And what if Netconf wants to modify the running config (i.e.: and the RIB > in particular)? > > That copy-to-local-config feature would be extra, outside the scope of the i2rs-config. IMO, the i2rs-config datastore has these properties: - editable with I2RS using the I2RS owner-priority access control model - only field validation; YANG datastore validation is ignored, except for mandatory=true|false and min/max-elements - data is never saved across a reboot; never saved to NV-storage like NETCONF config - data does not time out; The system or external I2RS client must remove any data to cleanup - the system uses the priority values to determine if local-config or i2rs-config wins wrt/ operational values; the system must install the correct config if priorities change --Tom > > Andy > > It is tempting to generalize the problem so the solution works for any > protocol (not specifically I2RS) and any data (not specifically RIB data). > But that would be out of scope. Understanding the interaction between > local-config and i2rs-config is certainly in scope. There is lots of work > left to be done there, so if it seems fuzzy to you, that's probably why ;-) > > > > >> /js >> > > Andy > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
