> It does. One other point that Jason Coleman, Jason Sterne and I were > discussing yesterday is how we handle config in this same pane of glass > model. That is, if I want to override a route via config, how would > that work with existing ephemeral state? > > The idea proposed was to be able to assign a priority to those [static] > routes that would, in essence, make them ephemeral with the associated > priority. This would allow one from the CLI participate in the I2RS > process.
Static routes are always the monster under the bed for this sort of stuff... The main problem (it seems to me) is how they've been implemented over the years -- I don't know enough about every implementation to know if treating them as "just another process" would be painful. Here's where some folks currently maintaining actual code stepping in and saying, "this would be really painful," or, "this wouldn't be a problem," would be really helpful. If it's going to be painful, then we might need some way to indicate which clients can do what. I think the main problem with this entire way of looking at things is Joel's point on complexity, particularly in the agent. It would also be helpful to try and nail what that complexity looks like, and if there is any way to reduce it, such as -- Would treating a complete set of "things" as a single "object" that cannot be broken apart be helpful? What do those sets of things look like? Would limiting this sort of capability to a small number of objects in the model be helpful in some way? IE, this doesn't seem useful to me for links, but it does for routes. Can we figure out what the use cases are, and try to limit the number of objects for which such a capability is to a minimal number? Would it be helpful to combine these two concepts? IE, only objects that can be treated as a "single atomic thing" can have a backup? Is it useful to tie these concepts together to limit the scope of adding more than one plane to the object? I don't know the answers here, just trying to find a middle path that works, and doesn't introduce too much complexity in return. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
