> It's important to be really cautious and not conflate this as being just as > simple as "static routes". For cases that look just like a routing protocol, sure. > But some of these cases are closer to extending existing configuration state, > not injecting new forwarding state.
So the case we're aiming for is to be able to change, say, the community string on a BGP route that's sitting in the BGP table, rather than in the RIB... Two things: - I consider this use case unwise. If you want to change the community string (or MED, or Local Pref, or AS Path) on a BGP route, then change the config so the route is impacted through normal processing on the router, rather than touching the route directly through an outside interface. Changing the config so the route is modified moves the problem out of the (strict bounds of the) I2RS space, and into configuration proper, where the operator can see the change in the config, etc. Playing with routes as they sit in the local protocol table without changing the configuration, and hence without telling the protocol what we're doing, is just asking for routing loops and other problems, and doing so from the outside so the operator must look in multiple places to figure out why the problem occurred is just asking for trouble and long MTTRs, IMHO. - If we insist on playing with routes in the local protocol tables, then we need to restrict ourselves to touching _routes_, those individual ephemeral things that change over time, don't persist over a reboot, and aren't configured on the box in any static way. Here, again, just like when interacting with the RIB, we should touch the _route_, not the policy, so the same rules apply as I pointed out in my original email -- if the route is updated, the agent needs to be notified, which then needs to notify the application, which needs to re-apply the policy if needed. Some implementations might allow the agent to be programed to react to route changes, but that's completely out of scope here -- it's a local agent problem. To put it another way -- we're trying to implement a policy from an external box by way of directly touching routing information. We are _not_ trying to influence how the router processes routes. We're _not_ configuring or modifying policy, we're modifying routing information in various tables. Different things entirely. Where we are running into problems is that we didn't start with a clearly defined set of objectives or definitions. "Configuration" means "slow," while "control plane" means "fast" -- a poor definition that's essentially opened every possible configuration semantic up to I2RS control. "Policy" is the community string on a BGP route -- not, it isn't. Policy is what happens to that route because it carries a specific community string or the reason the community string is changed, not the community string itself. We're mixing all these different things up; expecting to have a clear cut solution to a muddy problem. Ain't happenin'. If we back up and think through what it is we're trying to _do_, we can take this whole problem of "when do we write to the configuration" off the table. We're touching _routes_, not policy, no matter which table or database they happen to live in. Routes are _always_ ephemeral, and the policy indicators (those things policies use to do things to a route, or expressions of policy) carried in the route are always ephemeral -- so there shouldn't even be a discussion about writing something to a configuration. There shouldn't be anything "writable" in anything I2RS modifies on the router, plain and simple. If there is, then we've gone out of scope, IMHO. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
