I agree with Rob & Tony. Converging on single algorithm across zoo of vendors is not going to happen bearing in mind that every single change to such algorithm will require a massive 1000s nodes software upgrade each time.
Note that even if IETF converges industry may not and that is a practical aspect. With current proposal this is just one time upgrade. Thx, R. On Fri, Apr 6, 2018, 18:02 Rob Shakir <[email protected]> wrote: > 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]> 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] 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] >> https://www.ietf.org/mailman/listinfo/lsr >> > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
