[Lsr] Re: draft-ietf-lsr-dynamic-flooding-algorithm-04 ietf last call Opsdir review

[Tony Li <[e-mail]>]

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.