Russ, I think this diagram is a good start at defining the interface points. I have a couple clarifying questions.
1. Within your Routing Process boxes, I think what you mean by "A" is the injection of the same type of raw data the routing process receives from normal protocol neighbor (e.g., LSAs for OSPF, paths/NLRI for BGP). By "B," I think you mean injecting items that are the product of the routing protocol's processing of this raw data (i.e., protocol-specific routes). Am I understanding you correctly on this? "B" is not a modification to the routing protocol logic itself, is it? Would it be clearer to have another box below the Policy cloud to represent the set of routes the protocol computes, with the Policy cloud representing the internal protocol logic that transforms the input data into routes? 2. Does the RIB in your diagram include all routes from all sources or just best routes (those to be used for forwarding)? 3. Is the policy cloud hovering above the RIB box applying whatever rules the implementation uses (e.g., admin distance) to select best routes? Maybe also rules for filtering routes accepted from various sources? I'm trying to understand the difference between "C" and "D." 4. Can you clarify why you think injecting at "D" is "bad juju"? Presumably, "D" says "x is the best route to destination N, regardless of anything anyone else says"? Thanks, Rob > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Russ White > Sent: Monday, February 25, 2013 5:59 PM > To: [email protected] > Subject: [i2rs] Router Models > > 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
