Subject: [i2rs] Comments on last-write-wins (strawman)

From: Joe Clarke <[email-masked]>
Date: Tue, 5 Apr 2016 14:39:35 -0400

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 5 Apr 2016 16:48:25 -0400

Joe: 

<chair hat off>
This requirement that implementations provide "last write" and the ability
to "ephemeral" wins (by setting a configuration flag) is a good addition.  

I hope others will comment on this point. 
Sue

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joe Clarke
Sent: Tuesday, April 05, 2016 2:40 PM
To: [email-masked]
Subject: [i2rs] Comments on last-write-wins (strawman)

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-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Apr 2016 13:43:35 -0700

On Tue, Apr 5, 2016 at 11:39 AM, Joe Clarke <[email-masked]> wrote:

> what happens when the next write isn't from another I2RS Client, but
> instead a "normal" NETCONF client?
>
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

---

From: Joe Clarke <[email-masked]>
Date: Wed, 6 Apr 2016 11:29:08 -0400

On 4/5/16 16:43, Andy Bierman wrote:
>
>
> On Tue, Apr 5, 2016 at 11:39 AM, Joe Clarke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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?
>
>     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.
>
>

This would be my suggestion as well.

Joe