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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Note that RFC5243 style optimization is incompatible w the definition of IS-IS CSNPs which have a Starting LSPID/Ending LSPID in the PDU header. As per ISO 10589 Section 7.3.15.2c, any LSPIDs within the advertised range which are NOT mentioned are presumed to be NOT present in the sender’s database.

Fully agree with Acee that this discussion is out of scope for Dynamic Flooding.

   Les




From: Lsr <[e-mail]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, May 29, 2019 4:48 AM
To: Huaimo Chen <[e-mail]>; Tony Li <[e-mail]>; [e-mail]
Subject: Re: [Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction

Huaimo,

There have been various proposals for reducing DB synchronization over the years. This is not a new idea and let’s not mix it with dynamic flooding. As Tony replied, the IS-IS and OSPF mechanisms only specify the LSP/LSA headers to determine what has changed. Unless you do something similar, you don’t know how to “send the other end node the LSP/LSAs that are changed during the time period.”.

Note that while there have been many proposals, AFAIK, this optimization is the only one that was standardized - https://datatracker.ietf.org/doc/rfc5243/

This is out of scope for dynamic flooding. If you wish to pursue this as a independent item, please look the previous proposals and list discussion before retreading old ground.

Thanks,
Acee

From: Lsr <[e-mail]<mailto:[e-mail]>> on behalf of Huaimo Chen <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, May 29, 2019 at 1:27 AM
To: Tony Li <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction


Hi Tony,



    A possible enhancement on LSDB re-synchronization is described below for discussions.


    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. 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.

    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.

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

    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.

    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.

Best Regards,
Huaimo