Re: [Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction

[[e-mail]]

Hi Huaimo,


>     The current method: Whenever an existing link/adjacency L is added to the flooding topology (FT for short), a full LSDB re-synchronization is requested and executed over link L.


Please recall that this is a set of CSNPs in IS-IS and a Database Summary in OSPF.  Neither is particularly large or painful to deal with and is periodically transmitted (in good implementations) anyway. All this does is to ensure prompt convergence of any differences.  The only subsequent bandwidth and processing is to deal with actual database differences.

We are NOT sending the full database, just the differences.


> Even though the adjacency between two end nodes over link L is already there and their LSDBs are the same in most of situations, the full LSDB re-synchronization is executed, which consumes the power for processing IGP messages and the link bandwidth for transferring IGP messages. This may cause some issues if some links are added to the FT frequently.


Unless the topology is in some significant churn, we should expect the FT to be quite stable.  There is no good reason to change it.


>     Considering the cases where the LSDBs may be out of synchronization around the time period from a link on the current FT down to link L added to the FT for some reason such as a new FT computation. This period should be short in general.


A single link down is not likely to cause a database difference, as the FT is bi-connected and the data would transfer through the existing path.  More likely, we would end up with a race condition, where new data would circulate both via the long, old path and a new shorter path. This of course, will resolve itself.


>     Method A: Let one end node of link L send the other end node the LSP/LSAs that are changed during the time period.


This requires that all nodes remember what LSPs/LSAs have NOT been sent down all links during flooding.  While this is not impossible, the state retention is significant, on the order of # of LSP/LSA times the number of adjacencies.  This is very similar to the games that we have to play with update distribution in BGP.  It is a complexity that it would be very nice to avoid.


>     In general, the LSDBs are mostly synchronized among some nodes (i.e., the number of LSP/LSAs changed is mostly zero) when link L not on the FT is added to the FT. In this case, Method A almost does nothing, i.e., there is no link state with changes that needs the end node to send its adjacent node over link L.


The key word here is almost.  When this method might provide some benefit, there would necessarily be work to be done.  If there is an error, we would end up with database synchronization issues.  

The database synchronization mechanisms are very robust, simple and light weight.


>     Method B: Combine the current method with Method A. If the number of LSP/LSAs that are changed is small, then use Method A; otherwise, use the current method.


If we use the database synchronization, then there is no need to try to remember deltas. They will automatically work themselves out.

Tony