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
On 9/30/14, 9:34 PM, Thomas Nadeau wrote:
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 protected]> wrote:
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
On 9/30/14, 8:35 PM, Thomas Nadeau wrote:
On Sep 30, 2014, at 4:52 PM, Joel M. Halpern <[email protected]> wrote:
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.
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 protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
