I can live with that model.
Simplified and repeated:
If an object is deleted in running, and the object itself was not
created as a whole in I2RS, then the object, and any changes to elements
within the object, is also deleted in the I2RS ephemeral store, even if
some I2RS clients had written some of those elements.
I would expect I2RS to generate notifications of those deletions.
This gives us a consistent operating paradigm, with a means for I2RS
clients to be more explicit about their intent, without creating
significant complexity.
Yours,
Joel
On 10/1/14, 2:43 AM, Juergen Schoenwaelder wrote:
On Tue, Sep 30, 2014 at 07:52:13PM -0400, Joel M. Halpern wrote:
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.
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
