On Wed, Oct 1, 2014 at 6:18 PM, Andy Bierman <[email protected]> wrote:
> > > 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). > To quote the I2RS Architecture, "6.3. Interactions with Local Config Changes may originate from either Local Config or from I2RS. The modifications and data stored by I2RS are separate from the local device configuration, but conflicts between the two must be resolved in a deterministic manner that respects operator-applied policy. That policy can determine whether Local Config overrides a particular I2RS client's request or vice versa. To achieve this end, either by default Local Config always wins or, optionally, a routing element may permit a priority to be configured on the device for the Local Config mechanism. The policy mechanism in the later case is comparing the I2RS client's priority with that priority assigned to the Local Config. When the Local Config always wins, some communication between that subsystem and the I2RS Agent is still necessary. That communication contains the details of each specific device configuration change that the I2RS Agent is permitted to modify. In addition, when the system determines, that a client's I2RS state is preempted, the I2RS agent must notify the affected I2RS clients; how the system determines this is implementation-dependent. It is critical that policy based upon the source is used because the resolution cannot be time-based. Simply allowing the most recent state to prevail could cause race conditions where the final state is not repeatably deterministic." Now - if we have to decide that the CLI always wins, that is one option. I, personally, would be quite opposed to the idea that I2RS would always win. That does not give recovery mechanisms to the operators when and if something goes wrong. Regards, Alia > > > >> /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
