On Wed, Oct 1, 2014 at 3:05 PM, Juergen Schoenwaelder < [email protected]> wrote:
> On Wed, Oct 01, 2014 at 11:15:40AM -0700, Andy Bierman wrote: > > > > I don't agree that multiple ephemeral datastores are needed. Support for > > multiple clients within 1 datastore is needed. > > > > We can punt this but I believe we will be back discussing this again > in a couple of years. If multiple clients inject state (in an > uncoordinated way), certain things will go wrong. If we have no way to > separate multipe uncoordinated I2RS clients (e.g., by controlling the > priorities of different ephemeral datastores), then we will need hacks > with metadata to work around this. > > There are different priorities for clients. The collision management and cleanup are basically the same either way, because the agent is not required to remember state that got bumped. It that were true, then a separate datastore per client would be a feature instead of an implementation detail. Perhaps it is OK to ignore multiple ephemeral datastores now in order > to make progress. But I believe we are better off if things are > designed such that there can be multiple ephemeral datastores when > they are useful, that is we should not do anything to prevent having > multiple ephemeral datastores. > It's hard enough to agree on 1 ;-) IMO the ephemeral config always overrides the running config. That means in order to remove a static entry from the active config (but not the running config), there needs to be an operation for creating a "data instance deleted" entry in the ephemeral datastore. (Not a way to have I2RS actually delete entries from the running config). > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
