OK gents, sadly I’m losing the plot here...... My understanding of this whole endeavor is that:
- excessive flooding slows convergence - so we are seeking to define a reduced flooding topology - a failure that does not impact an FT adjacency is propagated throughout the topology and the effects of excessive flooding have been eliminated.... great. - a failure that does impact the flooding topology results in the topology trying to mend itself and slowing down convergence while at it.....potentially by a significant amount - And the current discussion is headed in the direction of what is the right heuristic to deal with this... Do I have this right? Just checking Dave -----Original Message----- From: Lsr <lsr-boun...@ietf.org> On Behalf Of Peter Psenak Sent: Tuesday, March 5, 2019 3:26 PM To: tony...@tony.li Cc: lsr@ietf.org Subject: Re: [Lsr] Open issues with Dynamic Flooding Hi Tony, On 05/03/2019 17:47 , tony...@tony.li wrote: > > Hi Peter, > >>>> Adding all links on a single node to the flooding topology is not >>>> going to cause issues to flooding IMHO. >>> >>> >>> Could you (or John) please explain your rationale behind that? It >>> seems counter-intuitive. >> >> it's limited to the links on a single node. From all the practical >> purposes I don't expect single node to have thousands of adjacencies, >> at least not in the DC topologies for which the dynamic flooding is >> being primary invented. > > > What if the node in question is one of the spines? Folks are building > systems that large… and it seems inevitable that port counts will only > grow. Toto, I don’t think that’s an AGS any more…. ;-) > > >> In the environments with large number of adjacencies (e.g. >> hub-and-spoke) it is likely that we would have to make all these >> links part of the flooding topology anyway, because the spoke is >> typically dual attached to two hubs only. And the incremental >> adjacency bringup is something that an implementation may already support. > > > LS topologies can have a very large number of adjacencies as well, > typically with multiple spines, so for a new spine, all of the of the > links may be unnecessary. ok, we talked bout the balance before - adding one link at a time to the FT may result in slow recovery, while adding all link is claimed to be dangerous. What is the right number? I feel that the increment value can be something that the implementation can choose or even make configurable, so the user can decide based on the particular topology and scale. We are not going to find the magic value I'm afraid. > > >>> Our simulations suggest that this is not necessarily optimal. There >>> are lots of topologies (e.g., parallel LANs) where this blanket >>> approach is suboptimal. >> >> the question is how much are true LANs used as transit links in >> today's networks. > > > As Xiaohu suggested, the management plane would be an obvious > application. Interconnects also seem likely. I believe his case is completely orthogonal to this discussion as in his case there is a single giant LAN used for flooding and we all know we can not optimize flooding inside a LAN itself. > > Let’s set the algorithmic parts aside. Do you have an objection to > supporting them in the signaling? will get complicated, especially for OSPF/OSPFv3. Also temporary flooding operation on LAN is tricky and sub-optimal. I don't really believe it's worth the complexity. my 2c, Peter > > Tony > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
