> Whatever the model is, I would hope that it is consistent with what we > already have in this document: > > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09
Looking at this document, it seems more like a data model for a routing table, rather than an actual model of how different processes interact to build a routing table... Some specific points: - I would say separating "static routes," and "routing protocol processes," is a false division --a static route is nothing more than a human injecting topology information a routing protocol might normally inject. The primary difference is not in the way the routes are handled by the routing table, but in that there is no feedback mechanism for static routes. - What this document calls "direct routes," are really just routes injected by the local routing process; these are treated differently because they have an administrative distance set so other routing processed cannot overwrite them. I don't think these should be seen as being handled "differently" by the RIB. - While it is sometimes true that a single routing protocol process only interacts with one RIB on the device, it is also true that it might interact with multiple RIBs on the device. This is something we need to be careful of in the I2RS design. Overall, I think the models match well enough to work together... The model in the netmod document would need to have policy application/injection points added to give it the fullness I think we need for I2RS. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
