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)? --Tom > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
