> - If a process wants to inject information at A, then it can simply > participate in the routing protocol in question --so I2RS doesn't really > need to do anything there. In fact, I would argue that injecting > information at A without participating in the protocol could be very > dangerous, and we don't want to go there. > > Not sure I agree here, and, given the use cases I see cropping up, not > sure others do either.
I'm actually very concerned about the direct injection of information into the local database of a protocol --because I'm not certain what sort of "rules," we could follow here to ensure the loop freeness of the protocol's algorithms once we start down this road, nor can we be certain an operator working at 2am on a routing problem will be "okay," with a route they don't understand the origin of, can't trace down to an originating device, etc. There might be solutions to these problems, but I don't see any immediately available answers (nor do I think we've even worked out what the problems might be), so I'm hesitant to claim injecting information at "A" a "good idea." So put me in the column, "this might be okay, but I need to be convinced we've spent a good amount of time thinking through whether or not this is a good idea before we do it." > - I2RS should be in the business of injecting information at B. We can > discuss whether that should be through configuration or not (IMHO, it > should be). > > Agree with the first part. W/r/t use of configuration, it's not clear > on whether this can achieved solely via config given the proposed > ephemeral nature of some forms of I2RS policy and the generally > persistant nature of config on most devices. Having said that, it is > clear that some portion of policy injection will reside in config. The problem here is somewhat the same as above --if changes aren't recorded in the configuration, how much complexity are we adding to the network management problem verses removing from the network management problem? If an engineer has to look at multiple outside processes to understand why specific things are happening, rather than a single configuration set, what the impact going to be on MTTR? Are we shooting ourselves in the foot to get to a faster draw stroke? Again, more information needed... > Now, to return to the idea of a "local process." There are several > issues to assuming a "local I2RS process." The first is that it > restricts implementation in a way that might be unacceptable in all > situations. Smaller devices with only partial I2RS interfaces might find > it painful to build a separate process, with all that entails, just to > support some simple commands from an I2RS controller. > > It really depends on how we how we design modularity and capability > negotiation for the protocol, and what portion of the capability set we > define as being mandatory in the core protocol. I don't think having a > separate process is a bad thing regardless. > > You seem to suggest something similar above in your comments regarding > injection ->(C), so perhaps I'm misunderstanding. My general argument would be this: Whether or not there's a local process is outside the scope of the WG to mess with. We should deal with the data models and protocol(s) on the wire, not with defining a new "routing process," the interfaces we expect that new process to have with other processes on the box, and other stuff. The number of processes, interfaces between those processes, and other "internal stuff," should be left to implementers --to encourage interesting ways of doing things, and to simplify the problem at hand... > Yep, I'm pretty sure I'm not understanding your argument here. There > are clearly use cases that would involve direct injection of state > independent of a ancillary distributed protocol, say, for example, > injection of ephemeral PBR state for a variety of security use cases. In this case, you would simply define the data model and the bits in the protocol that tell the router what PBR state you'd like to achieve, and leave it up to the coder to determine who on the local box receives that information, and how they act on it. It could be that some implementations already have PBR processes, while others don't, and others might handle PBR in their BGP process (yes, I'm making stuff up here) --I don't think we, as a WG, want to be saying things like, "you must have a local I2RS process, and it must do this, and not do that." :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
