> The basic problem I have with your description is that it treats over-writes as > normal and desirable, and assumes that the priority handling is producing > the correct results. If we actually believed that, I suppose making them > more efficient would be sensible.
After talking to Jeff a bit, I actually think we're probably trying to solve two different sets of problems in the same set of documents... The original idea of a "tight loop to the RIB" is sharing space here with a longer term, more static (but ephemeral) idea. It might be better if we actually split these two sets of requirements up. In the "tight loop to the RIB" case (represented by every use case I original put in the doc's I originally presented at the beginning of the WG), I'm pretty certain overwrites by multiple clients with callbacks in a very short time period are going to be a normal case -- two processes installing the same prefix in the RIB is a common situation in normal routing, and, in fact, something I would expect. Think of the case where a flow or destination needs to be redirected for some short period of time, and then traffic rerouted back to the pre-existing path, particularly in cases like software defined perimeter, or putting the user on a dead end network so they can only reach an authentication server, or redirecting a flow temporarily for traffic engineering purposes -- all of these could include entries that last under a second in the table. The "ephemeral configuration" situation is more akin to a static route -- if there are two, there's probably some error (perhaps). In reality, I've configured many pairs of static routes over the years such that if the first next hop is pulled from the table, the second next hop should be _immediately_ installed -- there's no time to wait for a round trip to the controller, so I don't know if I accept the premise that two static routes installed by two different controllers is a misconfiguration on its face. It might be good to separate these two use cases and their attendant solutions, rather than burying the "tight loop to the RIB" under more complex mechanisms designed for the apparent "long term ephemeral state" solution. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
