> Policy is dynamically changed in lots of ways. Again, it has to make sense in > the system.
What we need to do is separate policy from policy instruments... A community string, metric, etc., is _not_ a policy, it's a "policy instrument." In other words, an I2RS policy can change a community, but the reason you set the community is a policy, not the community. So what we are saying is two different things: 1. Find routes with a destination of 10.1.1.0/24; add community 1 to them. Do this this one time to route currently in the table. 2. For any route with a destination of 10.1.1.0/24, add community 1 to them starting now, and lasing until I tell you to do otherwise. The difference is subtle, but important. The first can take the semantic -- "set community 1 on routes matching 10.1.1.0/24." The second must take the semantic, "install a policy that examines inbound routes and sets community 1 on them if they match 10.1.1.0/24." If we're trying to do the second, we're trying to do the wrong thing. We shouldn't be programming policy into the box -- that's what netconf is for. We should be trying adjust individual routes based on a policy that's opaque to the box -- the routing process on box only sees the result of the policy, not the policy itself. > 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. So in JUNOS, you have the ability to instruct BGP to install a route map or RPL statement to change inbound routes, or to set a filter on inbound routes in addition to existing CLI configured filters, that the user can only see by examining the scripts running on the box as well as the actual CLI configured filters? I don't actually think you do... You probably have a set of instructions that configure something so new filters and policies show up in the CLI, and another set of options that will let you change actual routes, but I don't think you have a set of options that allow you to put in what is essentially an RPL statement without actually having that RPL statement show up in the configuration, or modify the inbound filter of BGP without modifying the configuration the user sees through other interfaces. Again, the difference is subtle, but important. If I2RS' goal is to replace RPL configurations in the CLU, then we've already stepped outside the bounds of the routing system, and into the bounds of netconf and the configuration/network management systems. > > 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. Sorry, Jeff, but I don't think the WG actually knows what it wants to do -- we don't have a carefully articulated well defined set of goals or definitions. As I read the use cases, I don't see _any_ use case that says, "I want to set an RPL based filter that changes every route received by the process, or acts as a nonconfigured filter on the box." What I see is, "I need to inject this route here, remove that route there, or modify that route over there." Completely different things. We need to know what "policy" means, and we need to know what a "route" means. We need to be able to state clearly and easily where I2RS ends, and where NETCONF begins. It's not that configuring policy is a "bad thing," it's that we need to scope the work to a reasonable set of actual work items, especially when there are other WG's working in the same space. Otherwise, we're just trying to boil the ocean -- a sure recipe for failure. To bring this back to the beginning -- we can play with how to build, store, etc., the YANG models all day long -- but unless we put some definitions around what I2RS is _not_ doing, we're never going to be able to make progress. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
