On Fri, Oct 03, 2014 at 07:44:14AM -0400, Russ White wrote: > 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:
And from there you pick an example and play reductio ad absurdum. :-) That's fine, doing that to specific use cases is helpful. However, I think part of the issue is that at the end of the day, this is an *interface* to the routing system. Being able to read state has always been pretty clear. We're spending all of our time debating the *write* semantics. They're tricky when they're crossing boundaries. The use cases where the configuration state we're injecting (configuration in the netconf sense, basically we've done a write operation) and it's completely disjoint from existing local configuration has always been pretty clear. Whether such things like in a unified datastore with local config or in something that requires a completely new protocol to set has never been an issue. Our issues all come when we want to interact with that local config - whether in an augmentation sense or a referential sense. For the moment, let's work through your reductio. > - 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. We already have BGP attributes getting "config" via other mechanisms. AIGP metric and the bandwidth extended communities are examples of these. We've previously talked about influencing of routing via programmatic changes to the cost community. > 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, I don't recall any cases where we're saying "go forth and meddle with things in a way that the underlying system isn't aware of". Matter of fact, for the IGP cases, we've explicitly put interference with the underlying LSAs as out of bounds because the protocols wouldn't deal with it. If you think we're specifically chartered to meddle with state in ways that don't make sense, I think you've gotten a bit lost. Not to mention I can't see someone supporting a model that has such impact. > - 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, Policy is dynamically changed in lots of ways. Again, it has to make sense in the system. As a random example, JUNOS has had ephemeral policy configuration for years. > 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. Policy is a table depending on one's perspective. > 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'. I want a way to be able to write "state" into boxes that influences behaviors based on configuration models. Those models define what one is trying to do. People want to do lots of things. And it's not so much "I". I already work on a platform that has a defined protocol and currently one language that lets me do this sort of thing. Customers want more broadly supported versions of such a thing and better models to get at and influence the device. > 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, Perhaps you are. Go forth with the knowledge that others want to do different things. - Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
