Speaking as a WG member: I think a distributed flooding algorithm is more robust and will converge faster when there more than one concurrent failure in the flooding topology. Additionally, if there is a node failure of the flooding leader and that node is a node is on flooding topology, there could be greater delays.
The same solution suggested for the centralized approach of flooding on the union of the old and new topologies could be used for transitions. However, prune to the newer topology could be quicker since it should be easier to assure downstream neighbors have converged on the new topology than the whole domain. Thanks, Acee From: Lsr <[email protected]> on behalf of "Les Ginsberg (ginsberg)" <[email protected]> Date: Saturday, April 7, 2018 at 3:47 PM To: Robert Raszuk <[email protected]> Cc: "[email protected]" <[email protected]>, Rob Shakir <[email protected]>, Tony Li <[email protected]>, "Peter Psenak (ppsenak)" <[email protected]> Subject: Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt Robert – I think discussion of RIFT belongs in the appropriate WG – not here. Flooding “as is” isn’t relevant here – since “as is” would mean as the IGPs do it today. Whether the flooding topology is calculated/advertised by a designated node or is calculated in a distributed fashion clearly a different flooding topology from the one IGPs use today is required or we will have accomplished nothing. Les From: Lsr <[email protected]> On Behalf Of Robert Raszuk Sent: Saturday, April 07, 2018 10:44 AM To: Les Ginsberg (ginsberg) <[email protected]> Cc: [email protected]; Rob Shakir <[email protected]>; [email protected]; Peter Psenak (ppsenak) <[email protected]> Subject: Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt Les, Isn't RIFT effectively a new flooding algorithm - while not strictly designed to be used within current link state protocols - it has the potential to achieve what you and Peter are proposing isn't it ? My personal take here would be to progress dynamic flooding *as is* with the use of DR/DIS as flooding oracles. If you or anyone however would like to propose a new flooding algorithm to link state protocols I think nothing stops you to write a separate draft on that and call it say -optimal-flooding-. Best, Robert. On Fri, Apr 6, 2018 at 10:06 PM, Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: I think this discussion has already gone much too far in the direction of customized flooding optimizations. Such is the nature of the engineering mind – give us a problem to solve and we’ll come up with a plethora of solutions. The right perspective (for me anyway) is this: IGPs have been popular as distribution mechanisms in part because of the reliability of their flooding process. This wasn’t easy to achieve – and those of us who have been in the business long enough have seen attempts to create something equivalent fall flat on their face because they couldn’t handle the corner causes. Simple yet robust has been the guiding principle and both IGPs do this well. It is also useful to remember that bandwidth utilization for IGP flooding is not a problem which we need to solve. It has been demonstrated – even long ago with much less bandwidth than we have today – that IGP flooding bandwidth isn’t a concern. So proposals which suggest we might need to come up with an algorithm that optimizes for bandwidth or SRLGs or whatever criteria one could imagine seem unnecessary – as well as incestuous. And they certainly complicate the problem. I agree with Peter’s suggestion that a common decentralized algorithm is desirable. It will simplify problems associated with reconvergence which I think is key. And I don’t think we really need to support multiple algorithms – it was nice of Peter to allow for that – but as we see now everyone is concerned about the upgrade issues that come with introducing a new algorithm. Let’s agree on one algorithm and be done. A variant on https://tools.ietf.org/html/rfc6325#section-4.5.1 is one such candidate. Les From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of Rob Shakir Sent: Friday, April 06, 2018 9:03 AM To: Peter Psenak (ppsenak) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt Peter, How do we transition between algorithms in the approach that you suggest? Do all non-stub devices need to be upgraded to support the new algorithm before such time as we can use it? (I think so, because otherwise some non-stub device cannot be guaranteed to flood to its downstream stub devices - so we may end up isolating some devices if any device transitions before all nodes support it). The advantage of having something advertised is that one can compute it centrally - and keep the per-node functionality simply obeying the advertised flooding graph. From an operational perspective, this means that one can introduce new experimental flooding topology computation approaches in a manner that is decoupled from needing to do software upgrades across the whole network. I can also implement non-standard flooding topology computations based on the network topology which could be only applicable to that particular network (consider if I wanted to do something like take into account shared-risk information in the algorithm to allow the most-SRLG disjoint flooding topology or so). This is in addition to the points Tony made. I think this centralised-computation-and-flooded approach is elegant. If the error handling behaviour for not being able to parse the flooding topology is to revert to flooding everywhere, then it seems non-destructive too. Cheers, r. On Fri, 6 Apr 2018 at 08:50 Peter Psenak <[email protected]<mailto:[email protected]>> wrote: Hi Tony, if we start with a single standardized algorithm, that is easy to implement and deploy. We can leave the door open for additional algorithms to be defined later together with the selection mechanism. I have the feeling that the dependency of the "flooding topology" on the flooded data is going to bring more complexity, than the selection of the distributed algorithm to be used, if we ever need to support more then one. thanks, Peter On 06/04/18 17:19 , [email protected]<mailto:[email protected]> wrote: > > Hi Peter, > > Thank you for your comments. > >> while I appreciate the flexibility associated with the centralized >> computation of the flooding topology, it has some drawbacks as well: >> >> 1. "flooding topology" must be flooded. This makes the flooding >> dependent on the flooded data itself. > > > Absolutely true. If the computation of the topology is incorrect, that > would certainly be a bug. > > >> 2. The extra flooding of "flooding topology" adds some delay in the >> convergence towards the new "flooding topology”. > > > Since we distribute the flooding topology before there are topology > failures, it would seem like the latency is not a significant concern. > > >> Have you considered the distributed computation of "flooding topology" >> using some standardized algorithm? > > > Yes, Kireeti raised this in London as well. There are some practical > issues with this. How do we ever converge on an algorithm? > > There are many perspectives on what an adequate flooding topology might > be. Different administrations have different considerations and risk > tolerances. > > Debugging is going to be more challenging, as inconsistencies between > two nodes with different ideas of the topology will be difficult to > detect until there is a catastrophic failure. > > I’m trying to do something practical, and it seems like doing this in a > centralized fashion is the quickest, easiest, and most robust way forward. > > >> Eventually we can support multiple standardized algorithms. A node can >> advertise support for several algorithms and the "active" algorithm is >> selected based on some criteria that would guarantee that all nodes in >> the flooding domain select the same one. > > > Seems like that would also require some administrative input. > > So, I agree that that’s a technical possibility, but I think that > there’s significant problems in making that work. I prefer to focus on > something that we can implement more quickly. > > Tony > > _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
