> I note the reference to ISIS which I find significant. My experience is more of > OSPF but appreciate that that is rare with Operators. However, both are Link > State and so very different to BGP which makes me think about the use of > RIB. The NETMOD routing-cfg started with RIBs, dropped them and then > reinstated them (after consulting with I2RS), whereas for me, RIBs are BGP > (as defined in RFC4271) and OSPF has an equivalent in LSDB, which is very > different in detail (as much research as Lada has done across three differing > platforms, I am not certain that the NETMOD has sufficient routing expertise > to get this perfect:-(.
There are two different "RIBs," at least in theory -- vendor implementations may vary. To try and separate things out, let's describe a few tables, see if that's a complete description, and then try to name these things. - There is the set of all the reachability information received by any given process. I would correlate this to the BGP-RIB-IN, or the LSDB in OSPF or IS-IS. - There is the set of best paths determined by the particular process. I would correlate this to the SPT in OSPF or IS-IS, and the BGP best path table. - There is the set of paths actually installed in the local device memory, and off of which the local forwarding tables are built. Each process running on the device installs reachability information into this table, and there is some arbitration method within each implementation designed to determine which process "wins," when there are multiple installs for the same destination, as well as "callbacks" for when routes are removed, and even perhaps "backup routes," and the like. - There is the set of forwarding table entries actually used for forwarding traffic. Note there may be two layers of these, but they typically include mac header rewrites, tunnel headers, and the like -- none of which any of the "ribs" described above would contain (they would only contain a next hop, not the actual rewrite information). If there are any I've missed, please feel free to add them in. This draft is supposed to be addressing use cases that are centered on the third one above in a "generic" way (not specific to some routing protocol, etc.). > REQ1 last sentence should probably include removing process I'm fine with including this, but I can't think of a use case off the top of my head... > REQ2 I think is about source-based routing but it does not quite say that, > rather reading as if source or destination routing were equally valid options It intends to say that both source and destination routing are equally valid options from the perspective of installed stuff into the RIB (#3 above). > REQ3 again the wording seems odd - I think you mean that traffic with a given > destination (or source?) prefix should be discarded, but that is not what it > says This is akin to remote triggered black holes -- a route to interface null0, which can be targeted either through the source (source routing) or the destination. > REQ4 I find vague, as I do anything with the word policy in it:-( Something > concrete (communities, MED, ...) would help This isn't really MED (that would fall into the BGP use cases draft), but rather mostly focused on setting the next hop, backup routes, source routes, and other places where you might forward based on things like port numbers, etc. > REQ6 makes me wonder what is a RIB when it is not local I suppose it could be remote in some way. Think of the RIB of a virtual router that then installs routes using OpenFlow into a remote switch -- is the RIB remote, or the FIB? I don't really know... I guess it might make more sense just to take the word "local" out here. > REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like something > more concrete. Again, I wonder if it is technically possible to present > information in a consistent manner given the difference in underlying > concepts of protocols. This is actually restricted to the RIB (#3 above) by the context of the draft, but it might be useful to add some restrictive language here. > REQ9 - again all embracing and as such, probably impossible, at least as > written. Limiting it just to BGP and a link-state protocol, again that seems > challenging. Again, this is implied to be restricted to the RIB (#3 above) by the context of the draft. Adding some restrictive language here might be useful, or it might be overkill (your choice :-) ). > REQ10 - policies again, and it is unclear who is doing the time management. > Some configuration protocols do have timer-based facilities, but not > NETCONF; do you mean here that I2RS must have functionality based on > timers (e.g. between 08:00 and 17:00 EDT, route this via Europe and Japan?) Time based processing here generally means, "last route installed wins, given all equal preferences otherwise," or perhaps, "time is the tiebreaker." This area might need work, as this makes the final state non-atomic (order dependent). The problem is there's no way to ensure everyone is using different preference levels, etc. Any thoughts here welcome. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
