Hi Russ, thanks for reading the draft (again). My responses are inline.
Russ White <[email protected]> writes: >> Any comments about the approach of draft-ietf-netmod-routing-cfg-09? > > I've commented on this draft in the past... > > IMHO: > > - It's not well enough defined for what we really want to get to here. 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. > - It doesn't seem to be well organized > > For instance --why is there a difference between "rw > main-routing-tables," and "rw routing-tables?" When would I choose to > use one or the other? Unfortunately, it is not sufficient to look just at the graphical representation of the data tree in sec. 4. In the "ietf-routing" YANG module (sec. 6), you can see that "main-routing-table" is essentially only a *pointer* to a routing table. Its purpose is the following: There must be at least one routing table per address family, but there may be more, either built-in or user-defined. Each router instance then uses the "main-routing-table" pointers for designating the main routing table for each AF. Main routing tables are special in that - direct routes are always installed in them, - by default, all routing protocols instances are connected to them (this can be reconfigured). Incidentally, until rev. -05 of the draft, the main routing tables were distinguished from the others by special prescribed names such as "main-ipv4-unicast", but then Wes Hardaker in his review objected (see http://www.ietf.org/mail-archive/web/netmod/current/msg07106.html, item 3) that using magic names was a bad idea. So we finally agreed to use an explicit pointer. > > Where are the routing filters mentioned as a separate "thing" applied, > and how are they applied? What are the elements of the filter object? The draft doesn't include any data model for specifying route filters. When the NETMOD WG was discussing the current charter, I actually proposed that the routing model would also include route filtering, but the prevailing opinion was that this task was too complicated and better left to experts. And indeed, it will IMO be pretty difficult to come up with a vendor-neutral filter specification that can be mapped somehow to the existing route filtering frameworks. So yes, the "route-filter" entries in the current data model are mere placeholders, and the plan is that one or more route filtering data models will be developed and plugged into the prepared slots via augmentation (which IMO is one of YANG's killer features). What the existing data model does specify are the places where route filters can be applied. It is - between a routing protocol and its connected routing table, and - between a routing table and its recipient routing tables. I had the impression from the previous discussion in this ML that this might suffice for I2RS purposes. > > 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. So, using this data model, the standard redistribution of routes from "proto A" to "proto B" will be configured like this: +---------+ +---------+ | proto A | | proto B | +---------+ +---------+ | ^ | ^ v | v | +---------+ +---------+ | table A |--------->| table B | +---------+ +---------+ Here, table A/B is the connected routing table for proto A/B, respectively, and table B is a recipient routing table for table A. A route filter can be applied at every edge in the above graph. > > 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". > >> A route is defined there as an extensible container, and future modules >> (e.g., those defining data models for routing protocols) are expected to >> augment this container with new attributes. This augmentation is described >> in sec. 4.4.2 (Defining New Routing Protocols), and and example is shown in >> Appendix B for RIP. >> >> 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? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
