> There are certainly (intentional) gaps that will have to be filled, but IMO > the data model could serve as a basis for I2RS, too. Unless, of course, you > think something is wrong with it, in which case I'd like to hear the details > so that we can improve it. I do believe though that we should eventually > work, as much as possible, with the same data models - after all, the > underlying router will be the same for both NETCONF and I2RS.
Well, what I would prefer is something that is smaller and lighter, and definite in what it touches, but leaves room for development in later iterations. In other words, I would probably prefer a bottom up approach, rather than a top down one. >> What's the point of the "recipient routing table," piece of this model >> (since we're talking about data, not an action)? > > Some implementations (Cisco IOS) use the concept of "redistributing" routes > directly between routing protocol instances while others (JUNOS, BIRD routing > daemon) let each protocol first put its routes into a routing table and then > pass it form there to other protocols, routing tables or the forwarding > table. I believe the latter approach is more general. Actually, no. Cisco IOS doesn't redistribute directly between routing instance, it only redistributes from the routing table into a protocol. I don't want to get into a lot of mechanics, but while the user interface implies direct redistribution, this simply isn't how it's done in the code. Redistribution is, in all the implementations I know of, effectively a filter the receiving protocol puts into the RIB/protocol interface to say, "when you get a new route matching these criteria (with the source protocol being a criteria), send the route information as well." I could be wrong about this -- I don't know every implementation as well as I should -- but I'm pretty sure this is how it's always coded. Even in the case of import/export, what happens is normal redistribution followed by an inter protocol callback to get the information the routing table doesn't have (to fill in metrics and the like). So... I think we can model all of these as a part of the policy between the RIB and each protocol -- we don't need a separate and special "channel." >> Why should "connected routes," and "static routes," be explicitly called >> out as different "types" of routing protocols? How are they special? > > It is not our invention, JUNOS and BIRD deal with direct and static routes in > terms of routing (pseudo-)protocols. As for the "direct" pseudo-protocol, it > requires no configuration and can actually appear only in the > "source-protocol" attribute of routes. On the other hand, "static" instances > have to be configured - their configuration inlcudes the list of static > routes that will then appear in routing tables with source protocol set to > "static". But if they're both just another flavor of a protocol, why not just call them a protocol with some special bits, rather than calling them a different "kind" of protocol process? That's one of the points, to me, of working from the bottom up -- don't make distinctions at the model level that can be made more simply by flipping some property bits at a lower level. >>> It means that the definion of route is not fixed but depends on the modules >>> supported by the device. >> >> Which isn't going to work if you're actually trying to insert routes to >> a number of different devices across a diverse network... > > If the network is heterogeneous, it it IMO quite appropriate to make use of > specific capabilities of each type of device. In NETCONF this can be easily > done because each device starts the session with advertising its capabilities > to the manager. Why this isn't going to work in I2RS? But it means we're back to square one --any off box process that wants to work with the local RIB on a wide variety of boxes must poke through the documentation (almost never complete, by intention) of each of those boxes, and build an internal data model that can be used for that individual box. This lays the problem of data modeling squarely on the shoulders of the application developer. I'd prefer a least common denominator set of things we know we need to build a RIB (not a forwarding table a RIB), from the start, and then build where we see more stuff we can do in the future. Start small and grow up, don't start big and try to fill out the details --IMHO. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
