> 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. - 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? Where are the routing filters mentioned as a separate "thing" applied, and how are they applied? What are the elements of the filter object? What's the point of the "recipient routing table," piece of this model (since we're talking about data, not an action)? Why should "connected routes," and "static routes," be explicitly called out as different "types" of routing protocols? How are they special? > 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... All of which is what went into my thinking about moving to a different sort of model -- Rather than asking how to model a RIB, what if we tried to model the information needed to actually forward a packet at layer 3? In other words: - These are the tuples needed to build a solid routing table entry from which the device can build forwarding table entries - Add in the pieces we need for "policy," particularly the idea of preference (called admin distance in cisco, for instance) Is there anything else we would need? The other option is to simply realize there's no "right" model here. Just choose one that works, and move on with life. Otherwise, we're going to bog down in arguing about models, rather than getting real work done... And I'd really like to move to the "get real work done" phase of things, rather than chatting about different models for the next several years. :-) :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
