On Tue, Apr 5, 2016 at 11:39 AM, Joe Clarke <[email protected]> wrote:
> I wanted to follow up to my comments from the meeting and to the strawman > I-D. The example shown in the meeting where ephemeral config overlays the > running config in a single pane of glass makes a lot of sense. However, > what happens when the next write isn't from another I2RS Client, but > instead a "normal" NETCONF client? > > In that case, the last-write-wins rule takes effect, and the pane of glass > holding the ephemeral config "shatters" leaving the running config as the > derived state. I realize this is the default, but I definitely see use > cases where I would not want the running config to win if it's the last > write. > > As such, I'd like it to be mandatory that implementations include both the > last-write-wins and the ephemeral wins options. What I see in the default > case is that I may change the running config, which triggers an update to > the I2RS Client holding the current ephemeral config, that Client then > re-makes its change to overlay running, and now I have state churn that I > may not want. > > I am confused by last-write wins, especially since all this stuff about client priority is intended to provide first-one-wins to prevent flapping. Also, the static intended config (running datastore) is validated and managed independently of the I2RS ephemeral data. NETCONF clients can update /foo all day but it has no affect whatsoever on the applied /foo config because I2RS is always higher priority. I think the I2RS client has to delete ephemeral /foo in order for the static /foo to be used by the server. Joe > > 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
