Gentlebeings, This discussion is producing far more heat than light. Can we please refocus our attentions?
I think that we all agree that the legacy parameters are no longer serving us well and that we need to reconsider our flooding parameters and mechanisms. If we fail to reach a constructive consensus, we will end up with a protocol that severely underperforms, hurting our end user experience and allowing other protocols to supplant what we’ve worked so hard for. It behooves us to all work together to find a common ground that allows all implementations to converge rapidly. At this point, arguing back and forth does not seem to be helping. Our goal is to enable rapid flooding of a large LSP database. We need everyone to be able to do this. While it may help an implementation to be rapid when operating with just itself, in today’s industrial environment, not being able to do this across implementations is not helpful. We need all implementations to be able to be performant. We have iterated on the points of the discussion repeatedly. Further repetition is not helpful. What is lacking is experimentation and facts. We need the results of running code. Packet traces with analysis of flow control mechanisms. Demonstrations of how particular parameters and mechanisms perform across implementations and across hardware platform classes. Comparisons of our flooding mechanisms with the throughput of other transport protocols. What is going to help all platforms be their best? Don’t just tell us what you think: prove it. The competition is not the other implementation. It is other protocols who will supplant everything. Regards, Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
