On May 2, 2014:1:33 PM, at 1:33 PM, Andy Bierman <[email protected]> wrote:
> > > > 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 Right. If we take that approach we need to have a way of the i2rs "protocol" to signal that the config needs to be saved "soon". That is, its not done in real time, but rather as a background process. Its probably. This can either be through a single keyword that is added under the i2rs-config section, or per element or even per-element, if we decide to be more granular. --Tom > > > > --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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
