Hi Tony, By the way, it seems that the slow convergence issue, as you mentioned before, is only associated with the flooding tree-based flooding reduction approaches.
If you believe the same issue could be triggered in the flooding reduction approach as described in (https://datatracker.ietf.org/doc/html/draft-xu-lsr-flooding-reduction-in-clos-01 ), please feel free to let me know, and I will verify it on our SONIC implementation. Best regards, Xiaohu 发件人: Tiger Xu <xuxiaohu_i...@hotmail.com> 日期: 星期一, 2024年11月25日 17:36 收件人: Tony Li <tony1ath...@gmail.com> 抄送: Acee Lindem <acee.i...@gmail.com>, lsr <lsr@ietf.org> 主题: [Lsr] 答复: 答复: 答复: Consensus Call on LSR WG work on "Leaderless Flooding Algorithm for Distributed Flood Reduction to allow reduced configuration, minimal blast radius, and ease of incremental deployment" Hi Tony, Thanks for your comments. We have implemented the LSP flooding reduction mechanism as described in (https://datatracker.ietf.org/doc/html/draft-xu-lsr-flooding-reduction-in-clos-01 ), which borrows ideas from the BGP route reflector mechanism, in SONIC. The test result shows no slow route convergence issue on the 5-stage CLOS network topology as mentioned in the above draft. Any further comments or suggestions are appreciated. Best regards, Xiaohu 发件人: Tony Li <tony1ath...@gmail.com> 日期: 星期六, 2024年11月23日 00:09 收件人: Tiger Xu <xuxiaohu_i...@hotmail.com> 抄送: Acee Lindem <acee.i...@gmail.com>, lsr <lsr@ietf.org> 主题: Re: [Lsr] 答复: 答复: Consensus Call on LSR WG work on "Leaderless Flooding Algorithm for Distributed Flood Reduction to allow reduced configuration, minimal blast radius, and ease of incremental deployment" Hi Xiaohu, I think we all would agree on wanting things to be simple and this being LSR, we will all agree that IS-IS and OSPF are the right answer. ;-) However, there are some downsides to using a reflector for flooding. The first is convergence time. Even in optimal conditions, you're suggesting bouncing updates through another system that has to amplify and retransmit the update multiple times. This will increase latency, especially if we're thinking of a dense WAN topology. Second, if there is a topology change, then this can affect the path of the update significantly. Yes, it would be best if one used multiple reflectors, but topology changes can still affect multiple concurrent reflectors simultaneously, resulting in increased convergence time. Tony On Fri, Nov 22, 2024 at 10:16 AM Tiger Xu - xuxiaohu_ietf at hotmail.com<http://hotmail.com> <mailforwa...@cloudmails.net<mailto:mailforwa...@cloudmails.net>> wrote: By the way, for the five-stage CLOS network topology, which has been widely used in large-scale data centers, to minimize the blast radius, it seems straightforward to utilize the matured multi-level ISIS or multi-area OSPF routing architecture whenever feasible. To make it easier to deploy and operate, it seems beneficial to learn the usage of the BGP route reflector, where the route reflectors are pre-configured rather than computing and /or distributing the flooding topology via some complex algorithms, IMHO. In a word, the simpler, the better. Best regards, Xiaohu 发件人: Tiger Xu <xuxiaohu_i...@hotmail.com<mailto:xuxiaohu_i...@hotmail.com>> 日期: 星期五, 2024年11月22日 13:14 收件人: Acee Lindem <acee.i...@gmail.com<mailto:acee.i...@gmail.com>>, lsr <lsr@ietf.org<mailto:lsr@ietf.org>> 主题: [Lsr] 答复: Consensus Call on LSR WG work on "Leaderless Flooding Algorithm for Distributed Flood Reduction to allow reduced configuration, minimal blast radius, and ease of incremental deployment" Hi Acee, I firmly believe it’s worthwhile to work on an additional mechanism for distributed flooding reduction, which is easier to deploy and has a minimal blast radius. Best regards, Xiaohu 发件人: Acee Lindem <acee.i...@gmail.com<mailto:acee.i...@gmail.com>> 日期: 星期一, 2024年11月18日 22:41 收件人: lsr <lsr@ietf.org<mailto:lsr@ietf.org>> 主题: [Lsr] Consensus Call on LSR WG work on "Leaderless Flooding Algorithm for Distributed Flood Reduction to allow reduced configuration, minimal blast radius, and ease of incremental deployment" During the IETF 121 LSR meeting, we had an excellent discussion of https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/ While the CDS flooding reduction algorithm itself was interesting, the main area of the discussion was distributed flooding reduction algorithm selection and its configuration and deployment. Today, we have RFC 9667 “Dynamic Flooding on Dense Graphs” which provides leader-based supporting both centralized and distributed flooding reduction algorithm selection. With the mechanism, an area leader is selected from among the OSPF routers in the area supporting flooding reduction and this leader selects the flooding reduction algorithm for the area. The question to be answered by this consensus call is whether or not we want to work on an additional mechanism just for distributed flooding reduction to allow for reduced configuration, minimal blast radius, and ease of incremental deployment. Please send your support or opposition to this list before Tuesday, December 3rd. As WG Co-Chair, Acee _______________________________________________ Lsr mailing list -- lsr@ietf.org<mailto:lsr@ietf.org> To unsubscribe send an email to lsr-le...@ietf.org<mailto:lsr-le...@ietf.org>
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
