I agree that we MAY start from defined router model with defined I2RS use-cases, so both not each separate. I argued before that we SHOULD define both parts of communication that includes the router but my ideas may be ignored,
AB On 2/25/13, Russ White <[email protected]> wrote: > Y'all: > > Because of a long and protracted exchange off list with a number of > folks, I've come to the conclusion that we can't (really) start with a > data model --even working from the use cases to a data model seems to be > difficult. I think we need to come to agreement on what a router looks > like first. > > No, not blue, grey, green, or... :-) > > 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). > > Let's ignore the question of whether or not there is some sort of I2RS > local process --more on this in a sec. > > Note I'm not claiming: > > - This is the only possible model for a router's operation > - This is a model that is widely used and deployed > - This is a model that contains every piece of a possible router > > 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. > > 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. > > - 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). > > - 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). > > - I2RS should not mess with D. This is bad juju. > > - I2RS should not mess with E, this is FORCES. > > - I2RS should not mess with F, this is OpenFlow. > > 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. 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. > > 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. > > :-) > > Russ > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
