Hi Ketan,
发件人: Ketan Talaulikar <[email protected]> 日期: 星期二, 2024年11月26日 19:50 收件人: Acee Lindem <[email protected]> 抄送: lsr <[email protected]> 主题: [Lsr] Re: 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/All, Before answering the question of the consensus call, I think it is really important that the mechanism for signaling of flood reduction enablement, capabilities, selection of algorithm, etc. be independent of the algorithm definition by itself. This is the best and the right way to ensure that the signaling mechanism is developed in a manner that would support the development and deployment of any existing or potentially new algorithm for flood reduction. Coming to the consensus call itself, I would like to break my response as follows: 1. Leaderless * Not necessarily or I am not convinced as yet. If we see RFC9667, for the distributed model, all that the “leader” is doing is selecting the algorithm to be used. I don’t see an issue with that. We have successfully deployed FlexAlgo where the FAD is configured on two (and rarely more) routers and flooded through the area/level. We just didn’t call those routers advertising FAD as “leader” but the concept for distributed flood reduction with RFC9667 can be seen as somewhat similar. Perhaps we want to improve the mechanism in RFC9667 to have flood reduction only in part of the network – i.e., flood reduction is only enabled in part of the network (where it is really needed) and there can be other parts where the normal flooding happens. I believe this is already possible unless I have missed something. [Xiaohu] I fully agree with you that there is no need to define a procedure for leader selection. A simple configuration on some or all routers is good enough. 1. Flooding Algorithm for Distributed Flood Reduction * Yes to distributed flood reduction [Xiaohu] If any flooding domain is limited within the scope of a three-stage CLOS network, especially for the minimal blast radius purpose/benefit, there is no need for flooding/synchronizing the algorithm for distributed flooding reduction as well, IMHO. 1. to allow reduced configuration * What do we mean by this? Each router will have algorithm(s) that it supports – I expect we want each of them to be configured for whether flood reduction and specific algorithm is actually enabled by the operator. This is especially important if we wanted to limit flood reduction to a specific part of the network. The Dynamic Flooding sub-TLV of RFC9667 does convey this to other routers in the network and it could potentially be used for computing the flooding topology in a distributed manner. * Then comes the configuration to select the specific algorithm to be used – this could be done on all the routers (kind of like configuring FAD on all routers and no need to flood it) or could be done on a couple of routers (leaders) (same as what is widely done for FlexAlgo today) [Xiaohu] Exactly, the flooding reduction-specific algorithm enablement could be configured on partial or even all routers. 1. minimal blast radius, * this one I didn’t quite understand – are we talking about a pathological state where all “leaders” go down or become unreachable? 1. and ease of incremental deployment * Definitely, but again what extra do we need to do here? [Xiaohu] IMHO, the above two goals could be easily achieved by leveraging the multi-level/multi-area routing architecture. Best regards, Xiaohu I believe it will help us make progress if there is a separate individual draft that captures this and other detailed requirements (we can leverage RFC9667 – including leaving out what may be seen as not necessary). Then evaluate the signaling mechanism for the distributed model in RFC9667 and again leverage what is useful – then add/remove as required. Thanks, Ketan On Mon, Nov 18, 2024 at 8:12 PM Acee Lindem <[email protected]<mailto:[email protected]>> wrote: During the IETF 121 LSR meeting, we had a very good 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 -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
