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.
Joe
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
