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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
