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. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
