> It is quite clear that caching is not required to meet a <1 second loop.
Given several comments on the list recently that RESTCONF isn't going to be able to meet these sorts of timers, I'm not certain... Further, I'd like to see a timer that's tighter than 1sec -- fast reroute needs to happen in <250ms in many networks. It seems like this particular area leads to "we don't have enough information right now to decide?" > We as a group concluded that over-write and other forms of collision are > errors. Calling an overwrite an error, and stating it isn't something we should optimize for, are two different things. :-) I don't think they're an error, even if you consider multiple controllers/clients. I think part of the problem might be we're thinking about different sorts of data here -- I don't think having three different processes overwriting the route to 10.1.1.0/24 with a different next hop, and expecting the second highest priority to take over when the highest priority is removed, is an error -- I'm willing to listen to the case, but I know this sort of thing is configured all the time in real networks (and not just for static routes). I can see how it would be considered an error in the case of setting up a new interface, or modifying a virtual topology, but this is what makes me suspect we have two different (and heavily interrelated) problems in hand. I think we might need to separate the case of "RPC to the RIB" and "ephemeral overlay state" in some way in our heads, even though we need to make certain we know how these things interact with one another. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
