Progressing with draft-litkowski-rtgwg-uloop-delay-00 ?
Pierre Francois <pierre.francois <at> imdea.org>
2013-05-20 11:57:39 GMT
Dear rtgwg list members,
I would like to know your opinion about what we should do with
http://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-00 , that we presented in Orlando.
The idea was to avoid microloops occurring in the direct neighbourhood of a node shutting down or bringing
up a link in an IGP topology, by introducing some
fixed delay in the update of the FIB in the down case, and introducing a fixed delay in the propagation of the
LSP describing the link as up in the up case.
The solution is simple, will be released by some in the upcoming months, and the Orlando audience was
seeming to find it interesting to work on.
Alia mentioned the interest of comparing this solution with the state of the art before going further with
the doc, so here it comes.
Generally, compared to other solutions, local-delay does not provide full coverage, as it only avoids all
(but only) microloops occurring locally to the affected node. However,
in many networks, as shown by Stephane's analysis, it is already highly beneficial to have loop avoidance
there. Considering the simplicity of the approach,
this looks like a low hanging fruit.
Alia was considering a comparison with PLSN. (described in
http://tools.ietf.org/html/draft-ietf-rtgwg-microloop-analysis-01, expired 7 years ago ;) )
The differences with the PLSN approach are the following:
PLSN lets all routers having to converge for some destinations, try to understand the safety of their new
next hops, for each destination.
Based on this assessment, they either
1. Transiently use a safe, non post-convergence, set of next hops, to finally converge to the
post-convergence one, or
2. Transiently use old next-hops, to finally converge to the post-convergence ones.
Local delay can be defined as a subset of this approach:
Only the node local to the event applies the procedure.
Step 1 in PLSN is not applied, we only suggest the node to wait for a fixed time, no transient FIB state.
I was considering a comparison with oFIB, draft-ietf-rtgwg-ordered-fib , submitted to IESG as
informational.
local-delay can be defined as a subset of this approach:
While oFIB defines an ordering among all the nodes of the network, telling which node should wait for which
neighbours to be done with their update, before performing their own, local-delay tells the local node to
wait before fast convergence has happened in the rest of the network.
I think that despite the close relationships between these approaches, local-delay is worth being
documented on its own because:
It's simple, on its way to be supported, and provides loop avoidance where they happen to be the most
annoying.
Cheers,
Pierre.
RSS Feed