Valid point of view but there are other solutions possible to the whole thing as well that don't precondition mesh-group node lift up, if consensus passes and we start to work on details of the necessary leaderless signalling in some framework that's part of operational considerations then would be my take ...
thanks -- tony On Wed, Dec 4, 2024 at 9:25 AM Peter Psenak <[email protected]> wrote: > Hi Shraddha, > > so you define mesh-groups to be a separate flooding algorithm itself, > requiring all routers using them to be upgraded. By the time you do that, > you can also replace mesh-groups with the distop on all routers and be done > with it, instead of trying to solve the coexistence of the two. > > thanks, > Peter > > On 04/12/2024 07:48, Shraddha Hegde wrote: > > 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]> <[email protected]> > *Sent:* 27 November 2024 15:58 > *To:* Peter Psenak <[email protected]> <[email protected]> > *Cc:* Tony Li <[email protected]> <[email protected]>; Tony Przygienda > <[email protected]> <[email protected]>; lsr <[email protected]> > <[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]> 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]> 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 <ppsenak= > [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] > To unsubscribe send an email to [email protected] > > > > > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
