Subject: [i2rs] Running and I2RS Ephemeral Config Interaction

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Sep 2014 19:52:13 -0400

I was tyring to understand the descriptions being used.

After looking back at the email, and talk to folks, there seem to be two 
different issues.

The first one is what happens the complete running config disappears.
As far as I am concerned, the device can do anything it wants, and 
whatever it does is probably wrong.  After all, for the running config 
to disappear there have to be very serious problems.

The second issue is what happens when something (foo) is deleted from 
the running config, but some property of that thing (foo/a) has been set 
by I2RS.  Unfortunately,as far as I can tell, there is not a good 
general rule.

Some examples:
If the operator takes down BGP, and deletes the full BGP configuration, 
then the presence of I2RS policy rules should not cause BGP to keep running.
On the other hand, if foo is a static route create by operations, and 
then I2RS modified the next hop for that route, I tend to suspect that 
the route I2RS has "created" by doing so should stay around even if the 
operator goes in a deletes the static route.

I suspect that the issue is determining what scope is being created when 
I2RS writes b/c/d/foo/a.  I don't think it is obvious or that there is a 
consistent rule.

Yours,
Joel

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 30 Sep 2014 17:35:10 -0700

> On Sep 30, 2014, at 4:52 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> After looking back at the email, and talk to folks, there seem to be two different issues.
> 
> As far as I am concerned, the device can do anything it wants, and whatever it does is probably wrong.  After all, for the running config to disappear there have to be very serious problems.

Yea

> 
> The second issue is what happens when something (foo) is deleted from the running config, but some property of that thing (foo/a) has been set by I2RS.  Unfortunately,as far as I can tell, there is not a good general rule.

The simple solution is to make the i2rs config changes apply immediately to the running config/state.

> Some examples:
> If the operator takes down BGP, and deletes the full BGP configuration, then the presence of I2RS policy rules should not cause BGP to keep running.
> On the other hand, if foo is a static route create by operations, and then I2RS modified the next hop for that route, I tend to suspect that the route I2RS has "created" by doing so should stay around even if the operator goes in a deletes the static route.
> 
> I suspect that the issue is determining what scope is being created when I2RS writes b/c/d/foo/a.  I don't think it is obvious or that there is a consistent rule.

If you make it just write to the running config, you have no issues.

Tom 

> 
> Yours,
> Joel
> 
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Sep 2014 21:23:09 -0400

There are multiple problems with "just copying it to running."
The primary one is that as per the I2RS WG rough consensus, the I2RS 
mods are not supposed to be preserved across a restart.
But if they are copied to running, and an operator then does a commit, 
they will get preserved.
In fact, if they get copied to running, and an operator then makes other 
changes and wants to commit them, he can't help but commit the I2RS changes.

Yours,
Joel

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 30 Sep 2014 18:34:32 -0700

The running config is by virtue not preserved until an action to save it is made.  Of the operator wishes to save the running config then yes they "commit" it.  

I honestly think we're making this harder than it needs to be.

Tom 

> On Sep 30, 2014, at 6:23 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> The primary one is that as per the I2RS WG rough consensus, the I2RS mods are not supposed to be preserved across a restart.
> But if they are copied to running, and an operator then does a commit, they will get preserved.
> In fact, if they get copied to running, and an operator then makes other changes and wants to commit them, he can't help but commit the I2RS changes.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Sep 2014 21:44:11 -0400

Thomas, the approach you propose would mean that whether the I2RS client 
wanted it or not, if an operator committed the config, he would commit 
the current state of the I2RS operations.

That strikes me as completely wrong, and more importantly as being an 
extreme violation of the WG agreements.

Yours,
Joel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Oct 2014 08:43:11 +0200

> operator goes in a deletes the static route.

If I2RS only modifies the next hop and the underlying route is delete
from config, then the route should be removed from the operational
state. If I2RS wants the route to persist even if the underlying
config goes away, then the I2RS client has to inject a complete
routing record overlaying the underlying route from config. I believe
this is actually simple as long as we keep it simple.

/js

-- 
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/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Oct 2014 08:47:35 +0200

Tom,

this is correct only if the NETCONF server supports the :startup
capability. During the interim, I said that there are certain
'synchronization points' at which the running datastore is made
persistent. What these 'synchronization points' are depends on the
capabilities of the NETCONF server. In other words, I2RS should assume
that the 'running configuration datastore' is generally persistent
(even if there may be periods where this is not true, until the next
'synchronization points' has been reached.

The main reason we discussed ephemeral datastores is that they will
never have any 'synchronization points'.

/js