Russ White <[email protected]> writes: >> 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.
The decision between top-down and bottom-up is always difficult, but in this case we hardly had any choice. One reason is technical: YANG is essentially designed for the top-down approach. One module defines the top-level skeleton and other modules can then fill in details via augmentation. Another reason is that the initial (core) YANG modules have been developed by the NETMOD WG, in order to break the chicken-and-egg problem. And we couldn't start with a very specialized stuff such as routing protocols, this should be left to experts in other WGs. Most of the complexity is a consequence of the stated objective that vendors should be able to map this data model to their proprietary models and/or CLI logic. > >>> 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. Either way, it can be represented using the data model. > > 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. An implementation is free to stick to just one routing table (per address family) and then it is exactly as you write: all protocol have no choice but to connect to this table and most of the complexity goes away. > > 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." The data model allows for multiple routing tables per address family, because this is what some implementations support. As I said, you are free to limit yourself to a single RIB/routing table and then there is no such channel, and what remains are only import and export filters between the single RIB and each routing protocol. > >>> 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. I am not sure I understand what you mean but, as a matter of fact, the two pseudo-protocols are *not* modelled as a different kind of protocol. For instance, configurations of "static" and "bgp" protocol instances will be entries of the same "routing-protocol" list. > >>>> 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. If the off-box process uses NETCONF/YANG, it can learn the capabilities of each box from their hello packets, and then peruse the machine-readable representation of their data models. > > 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. Nothing prevents you from using the common denominator if it is sufficient. Cheers, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
