Hi Robert, With dist-opt flood reduction running in leaderless mode it is possible for the operator to run Mesh-groups in some part of the network and introduce distopt flooding in other part where needed. The nodes configured with mesh-groups have to be upgraded to advertise, they are running a different flood reduction algorithm and the distopt algorithm will ensure the neighbors of the Nodes running meshgroups will always become reflooders and hence the CDS where distopt runs, is ensured correct flooding behaviour.
Some networks have the mesh-groups deployed where it’s a well defined part of the topology and reduces 50% back-flooding with mesh-groups configured. Has been deployed for many years and serving well. If an operator wants to keep that config and introduce distopt in other parts of the topology (during migration or otherwise), It’s a very valid usecase and can be supported with distopt algorithm. Rgds Shraddha Juniper Business Use Only From: Robert Raszuk <[email protected]> Sent: 27 November 2024 15:58 To: Peter Psenak <[email protected]> Cc: Tony Li <[email protected]>; Tony Przygienda <[email protected]>; lsr <[email protected]> Subject: [Lsr] Re: Another counter-example [External Email. Be cautious of content] > you are talking about mixing the manual mesh group with optimized flooding. I am talking about an accidental mix (legacy configuration at some nodes) not a planned one. And you either auto detect it and disable the ability to optimally flood or you push full responsibility to the operator. Thx, R. On Wed, Nov 27, 2024 at 11:16 AM Peter Psenak <[email protected]<mailto:[email protected]>> wrote: Robert, On 27/11/2024 10:32, Robert Raszuk wrote: Peter, My point was that this should be at least mentioned in operational considerations section if dynamic flooding is expected to work in mixed networks where some nodes support new algorithm and some do not your "regular flooding case". you are talking about mixing the manual mesh group with optimized flooding. I don't think we want to go that path. thanks, Peter On Wed, Nov 27, 2024 at 10:28 AM Peter Psenak <[email protected]<mailto:[email protected]>> wrote: Robert, On 27/11/2024 10:22, Robert Raszuk wrote: Peter, I am not sure if what Tony said is a requirement or an observation. > Note that combining routers that run the elected optimized algorithm > with routers that do run the regular flooding is not a problem. Note that static mesh groups can be present today too and you can't assume that it is either an optimized algorithm or full flooding. please do not compare apples with oranges. Static mesh groups are manually configured and if not done correctly can result in broken flooding. What we are discussing here is a dynamic flooding algorithm, not manual flooding blocking. thanks, Peter Thx, R. On Wed, Nov 27, 2024 at 9:58 AM Peter Psenak <[email protected]<mailto:[email protected]>> wrote: On 27/11/2024 00:18, Tony Li wrote: > A distributed algorithm computing a flooding topology must only > operate upon nodes running the same algorithm (and version). If > multiple algorithms (and/or versions) are running in the same network, > then any given algorithm and version defines a subgraph and the > algorithm can only optimize flooding within its own subgraph. Legacy > full flooding must be used between subgraphs of different algorithms > or versions. This is a new requirement for the flooding algorithm itself. This does not exist with the existing leader based election, as that guarantees that only one optimized flooding algorithm is ever present in the area. Note that combining routers that run the elected optimized algorithm with routers that do run the regular flooding is not a problem. thanks, Peter _______________________________________________ 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]
