> If objects that are always intended to be ephemeral are never going to > conflict (but may lie on top of) local config, there is never a conflict. > There is simply referential integrity issues if the underlying local config is > deleted and ephemeral config remains. > > If the objects are always disjoint, there is never a conflict. > > But if you permit an ephemeral object to override a local config one within > the schema, we have this issue. Our options would appear to be:
A lot of this discussion centers around the concept of a "configuration change" and, more specifically, "static routes." This is actually what I was trying to avoid early on by separating the concept of configuration state from the concept of forwarding state... But, since we are here, one possible point -- If I2RS is treated as, essentially, an alternate "protocol process" running off box, rather than "yet another configuration mechanism," then this problem falls out. There would be no such thing as a "static route installed by I2RS," there would only be routes installed in the local routing table that would be persistent only if the I2RS agent makes certain to reinstall it after any "system event" that causes the route to fall out of the table. Policy within a protocol (though I generally don't like the idea of modifying individual routes at the protocol level) would be treated the same way -- not as a route map or RPL statement "configured" on the device, but as an individual change to an individual route. If an update is received for this route, the local agent must remodify the route, rather than assuming any modifications made would be persistent across updates to that specific reachability information. If this is all true, then there _should be_ no problems with something being configured in two places -- if a single piece of reachability information is installed into the local routing table twice, normal processing rules apply, regardless of the source (generally speaking, the route with the lower admin distance wins, no matter the source). I2RS would never "configure" a "static route," but rather attempt to install a piece of reachability information into the routing table, which then either succeeds or fails, depending on the processing rules involved. The static route configuration isn't touched by I2RS, so there's no issue of "which configuration wins." I hope all that made sense. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
