On May 2, 2014:2:49 PM, at 2:49 PM, Andy Bierman <[email protected]> wrote:
> > > > 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). Not necessarily. I am just saying that its an option that someone might want to use. > 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". Yes, exactly. I didn't mean to imply it was mandatory to eventually save the running config; just that if you want to, we should bake this capability in. --Tom > > > --Tom > > > Andy > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
