Hi Luigi, Thank you very much for your comments.
I am appending the full text of an “Operational Considerations” section that I propose to add. To directly answer your questions, please see inline below. > The section has to cover the same points as in Section 4 of RFC 9667. If for > any specific aspect RFC 9667 is what should be used, please state explicitly > so. Particular attention should be paid to the following questions: - Do all > nodes need to support this algorithm, or flooding should work in hybrid > deployments, where part of the nodes only support classic flooding? Partial deployment is fully supported. Legacy nodes will flood on the flooding topology, plus additional adjacencies. This satisfies the needs of the algorithm but will not provide the benefits of Dynamic Flooding. > - Should > the use of several algorithms (when they will exists) in the same deployment > be > avoided? The algorithm in this document is a centralized algorithm. It is not possible to use multiple centralized algorithms simultaneously. The case of multiple distributed algorithms is really a question for RFC 9667 and should not occur because the Area Leader indicates the correct distributed algorithm to use. Tony P. has done additional work on leaderless dynamic flooding and has proposed mechanisms that allow multiple distributed algorithms to co-exist. Please see draft-ietf-lsr-distoptflood for his work on this. > - How does the node calculating the flooding topology deploy such a > configuration to the other nodes? The flooding topology is distributed using the TLVs found in RFC 9667. This is not configuration. This is 100% dynamic. > - Can this be deployed incrementally (i.e. > not all nodes at the same time)? Answered above. > - What happens in case of failure of a node? Please see RFC 9667, Section 6.8.6. > Is the the flooding not completed because arc paths are not interrupted? I’m sorry, I don’t understand the question. I think you’re asking about the impact of node failure. As you might expect, there are transient conditions. On a node failure, the immediate result is that the node will stop flooding. Yes, this impacts the flooding topology, but this is exactly why we choose to construct a biconnected flooding topology: even with the loss of a single node, the flooding topology will remain connected and flooding should eventually converge. In a few seconds, the adjancencies to the node should fail. This will cause adjacencies to be withdrawn, resulting in changed advertisements from the adjacent nodes. This is then flooded. This will then be detected by the Area Leader, which will then recompute and reflood a new flooding topology. This should cause the area to transition to a new biconnected flooding topology, eliminating the risk of a second failure. > ## **Nits** > > In section 1.1.2, bullet point 4, "Section Section 6" => "Section 6" Fixed. Regards, Tony Proposed text: 6. Operational Considerations The operational considerations for this algorithm are the same as for any centralized algorithm as described in [RFC9667], and are all derived from that document. The Area Leader election mechanism must be operating correctly and elect a single leader that all area nodes must converge on eventually. If there is no agreement on the Area Leader, there will be inconsistency throughout the area. As the Area Leader election algorithm is taken directly from the well-proven Designated Intermediate System election algorithm, we do not anticipate many operational issues in this function. An implementation SHOULD provide an indication of its Area Leader. The Area Leader then must advertise the Area Leader sub-TLV and specify that it is using a centralized algorithm. This seems like this is very low operational risk as this is a constant value. Only the Area Leader executes the algorithm found in this document. The Area Leader then advertises its results in the Flooding Path TLV and Area Node IDs TLV. If there are operational issues with any centralized algorithm, they can be detected by comparing these results to the actual physical topology. Each node in the area is responsible for parsing these results and understanding its role in the flooding topology. An implementation SHOULD provide an indication of which adjacencies are on the flooding topology via some management plane mechanism. The details of this mechanism and implementation dependent and out of scope for this document. Partial deployment of Dynamic Flooding is fully supported. If a node does not support Dynamic Flooding, then it is a legacy node and supports standard flooding, which implies that it floods on all interfaces. Thus, it is satisfying the expectations of the algorithm and flooding on the flooding topology. Of course, it will also flood on adjacencies that are not part of the flooding topology, and it will not help to reduce the flooding in the area. The largest operational risk for Dynamic Flooding comes from topological changes, as detailed in [RFC9667], Section 6.8. If an implementation does not handle the partition of the flooding topology and temporary flooding correctly, it will result in partial flooding and inconsistent routing. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
