Re: [Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction
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 On Behalf Of Acee Lindem (acee) Sent: Wednesday, May 29, 2019 4:48 AM To: Huaimo Chen ; Tony Li ; lsr@ietf.org 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 mailto:lsr-boun...@ietf.org>> on behalf of Huaimo Chen mailto:hc...@futurewei.com>> Date: Wednesday, May 29, 2019 at 1:27 AM To: Tony Li mailto:tony...@tony.li>>, "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>> 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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
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 on behalf of Huaimo Chen Date: Wednesday, May 29, 2019 at 1:27 AM To: Tony Li , "lsr@ietf.org" 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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction
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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
