Hi Tony, The whole process of temporary flooding is much more clear for me. Thank you for your explanation!
Best Regards Xuesong From: Tony Li [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, May 12, 2020 1:03 AM To: Gengxuesong (Geng Xuesong) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [Lsr] Questions about draft-ietf-lsr-dynamic-flooding-04 Hi Xuesong, Thank you for giving detailed proof, and it is very helpful to understand the mechanism. As I understand, it is showed in the proof that if there is proper temporary flooding in R = E - E* - E’, same connectivity could be achieved by the flooding topology F’ just as G’. I agree with this. I’m glad it helped. The problem for me now is how to enable the temporary flooding properly. Here is an example: <image001.png> The solid line presents the physical link inside flooding topology, and the dashed line presents the physical link out of flooding topology. From the view of me, when multipoint failure happens, node 3 is supposed to enable the temporary flooding between 3 and 4, in order to connect with the nodes inside the red box, while the other dashed line between node 1 and node nobody is not supposed to do temporary flooding although node 1 is connected to the failed link directly. It seems a little unclear for me about how the node itself could decide whether a dashed line should do temporary flooding or not in this case. The problem that you’re asking about is partition detection. To explain this, I’ve taken the liberty of adding some more labels to your diagram. To start, each node has its link state database and the flooding topology. Each node should receive link state updates from nodes in its partition, but will not receive updates from other nodes, thus the link state database is partially inconsistent and must be treated with care. For example, node 2 will see updates from nodes 1, 6, and 7, informing it of the failure, but it will not receive an update from node 8. Now, the job of each node is try to compute the partitions of the flooding topology. In particular, each node needs to understand which nodes are in its partition. A node cannot know all of the partitions that exist, but it turns out that that’s irrelevant. Once a node understands which nodes are in its partition, then it is a simple matter to see which links should be enabled for temporary flooding. If a neighbor is in the same partition (e.g., nodes 1 and 5), then adding the link adds no value. If the neighbor is not in the same partition (e.g., nodes 3 and 4), then it becomes a recovery link. The actual computation of the partitions is straightforward, with one caveat: we always want to perform a two-way check for connectivity. An implementation should be doing this during SPF already, so this should be familiar. The reason for doing this is quite clear: in node 2’s link state database (LSDB), the LSP for node 8 will show connectivity to node 1 even after the failure. However, node 1’s LSP will clearly show that the adjacency has failed. We can only infer connectivity when we see both sides of the adjacency are up. Given this, the specific algorithm that you choose is an implementation detail. You could do a breadth-first search or a depth-first search. Our implementation chooses to walk the entire flooding topology, building a tree of the partitions that it detects. [IPR note: we have a IPR claim for this approach, with the “don’t sue us, we won’t sue you” terms.] I hope this helps. Regards, Tony [cid:[email protected]]
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
