If the only problem we want to solve is the RIB, and specifically the
creation of alternative RIB entries, then a VERY different approach
would take care of the problem. The existing RIB models already
recognize that there are multiple creators. So if we only need to
handle alternative RIB entries, that mechanism to could be generalized
easily to avoid even panes of glass complexity.
But if we want one client to be able to modify part of a RIB entry, or
if we want to be able to work with things other than RIB entries, then
all of the issues that were discussed several years ago come back into play.
So if you want to argue that we should solve only the small problem,
that is defensible. But it is a big change in our scoping to date. And
from where I sit it would not particularly help us solve the larger
problem, which does need to be addressed.
Yours,
Joel
On 11/4/15 7:31 PM, Russ White wrote:
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
