On 4/5/16 16:43, Andy Bierman wrote:
On Tue, Apr 5, 2016 at 11:39 AM, Joe Clarke <[email protected] <mailto:[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.
This would be my suggestion as well. Joe _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
