Russ White <[email protected]> writes: >> 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:
The present data model is just a skeleton, and additional YANG modules will be needed to define configuration and state data for individual routing protocols, route filters etc. On the other hand, the data model is quite specific in terms of how the components - protocols, routing tables and route filters - are allowed to interact. It is important to get this part right - also for the purposes of i2rs. > > - 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. Actually, there is no such division. Static routes are represented using a special (pseudo)protocol of the type 'static'. A list of static routes is then a part of the configuration of this protocol, but static routes will also appear in a routing table, but being state data there. > > - 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. They are not handled differently. They appear normally in routing table(s) with the 'source-protocol' attribute set to 'direct', and their appearance is triggered by the configuration of IP addresses on interfaces. > > - 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. Whilst each routing protocol is connected to exactly one routing table per address family, the configuration may specify, for every routing table, one or more "recipient routing tables", so the routes may indeed be shared among multiple tables, subject to route filters. > > 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. Assuming that policies = route filters, the I-D specifies such points: route filters may be applied (i) between a routing protocol and its connected routing table, and (ii) between a routing table and its recipient routing table. The figure in sec. 4 shows an example. Thanks, Lada > > :-) > > Russ -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
