[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: [Lsr] Fwd: Open issues with Dynamic Flooding
From:       tony.li () tony ! li
Date:       2019-04-10 14:09:48
Message-ID: E049B570-ADEF-4AD7-B930-E735B6434A66 () tony ! li
[Download RAW message or body]


Hi Dave,

> So for my edification/education, this is a general behavior that in the absence of \
> any specific algorithm is postulated.  (?)


Yes.


> The piece I do not quite get is "adding until fixed".  Is the working assumption \
> that things have broken down to the point that there is no synchronization of the \
> topology and the repairs are "blind"?


Yes.  We are using a centralized algorithm and have had multiple near simultaneous \
failures that have partitioned the flooding topology. While the area leader can (and \
probably will) compute a new flooding topology that repairs everything, it cannot be \
easily distributed across the partition of the flooding topology.


> Hence "adding until fixed" is adding until IGP exchange appears to have  minimized \
> the changes in the LSDB from some previous state of the FT or some other criteria?  \
> 


Adding links temporarily to the FT should restore flooding, at which point an updated \
FT from the area leader can easily propagate.

Note that this is a convergence time issue: the new FT could slowly propagate, but it \
does require that each node at the partition unpack the new FT, install it, and then \
perform synchronization on the new links before proceeding.

Tony

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[prev in list] [next in list] [prev in thread] [next in thread]