Russ; Thanks for kicking off this discussion. Comments inline:
On Mon, Feb 25, 2013 at 2:59 PM, Russ White <[email protected]> wrote: > > Look at the attached (hopefully the attachment works --if not, I've > stashed a copy here, as well: http://www.riw.us/temp/router%20model.jpg). > > > What I am claiming is this is a useful model that will help us > understand what we want to do, and what we don't want to do --and, I > hope, it will lead to a better understanding of the difference between > policy, forwarding information, and configuration. > > I agree; this is an extremely starting place for the discussion. > IMHO: > > - 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. > - 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. > - I2RS should be in the business of injecting information at C (because > the current use cases demand it). In fact, C should be a bidirectional > interface that looks, to the RIB, just like an on-box routing process > (like either of the other two routing processes shown in the diagram). > > Strongly agree. > - I2RS should not mess with D. This is bad juju. > > Generally agree. > - I2RS should not mess with E, this is FORCES. > > Agree, as does the charter. > - I2RS should not mess with F, this is OpenFlow. > > Sorry, this is inaccurate. Openflow and ForCES actually have a significant amount of overlap in terms of functionality and targets, especially w/r/t to the simplified model you've drawn here. Both interact with a model of the forwarding plane via the control plane, with a somewhat arbitrary degree of complexity masking in the fp models based on the use case. Having said that, both I (and the charter) agree that I2RS doesn't have any business being here. > 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. > The second is that > assuming a local process really doesn't help us in any material way to > define anything. When we're in the process of building a data model for > interacting with BGP policy, for instance, how does saying, "well, the > local I2RS process has a data model that looks like x, which it > translates into data model y to talk through some local interface to the > BGP process," really help? The only thing I can see assuming a "local > process," does is add complexity. 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. Interaction with the RIB is clearly in charter , and I believe (as do you apparently) that this is best done without assumption of direct interaction with the actual RIB process, ie: this should be modeled as a separate 'I2RS' routing process and subject to some notion of relative protocol priority. So, thoughts... > > - Is this a reasonable model of a controlled device? > - What would you add? > - What would you subtract? > - What specific operation can you think of that doesn't quite fit into > the model as it's shown? > > Hopefully, this will kick off some discussion here, and bring us to a > place where we can go back to the two use cases the WG originally agreed > to restrict itself to, and make some progress in understanding how to > build the right pieces to support those use cases. > Again, thanks for starting this discussion on the list. best, -ed
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
