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]> On Behalf Of Rob Shakir Sent: Friday, April 06, 2018 9:03 AM To: Peter Psenak (ppsenak) <[email protected]> Cc: [email protected]; [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] https://www.ietf.org/mailman/listinfo/lsr
