On Fri, May 2, 2014 at 11:07 AM, Thomas Nadeau <[email protected]>wrote:
> > 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. > > You seem to be suggesting that the I2RS behavior of forgetting all injected state if the router happens to reboot is not that useful, and therefore it needs to be saved in the background (best-effort). I think it is up to all the I2RS clients to always be around to receive some sort of agent-reboot event, and re-install any required I2RS config. I can't imagine any use cases where the operator thinks "I only need to install this RIB data until that router accidentally reboots". --Tom > > Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
