Hi Huaimo,
> Computing a whole backup path between two end nodes of a failure and enabling > temporary flooding at each hop of the path will guarantee that these two end > nodes are connected on the FT, thus the FT partition caused by multiple > failures is fixed. The backup path is not a guarantee. Consider the case of other link or node failures along the backup path. In particular, consider the case when the destination node failed. There will be no working backup path. In fact, everything along the computed backup path may have failed. > Enabling temporary flooding on a link attached to one or each of the two end > nodes may not connect the two end nodes of the failure on the FT in some > cases when the backup path has multiple hops, thus may not fix the FT > partition created by multiple failures. It’s true that just adding one link may not heal the partition. This is exactly why we feel we need to iterate. Each iteration increases the size of the partition (or decreases the cut set, depending on how you want to look at it) and because the graph is finite, we are guaranteed to converge. Partition repair in the face of imperfect and insufficient information is a hard problem. We shouldn’t be expecting a closed form solution. Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
