Hi JP, > [PT] Ok. I see. My point was asking for "synchronized" is as > meaningless as asking for "Dijkstra": I can come up with a > synchronized algorithm that performs worse than a non-synchronized > version with respect to a metric. But, going with the popular > assumption that "Synchronized" means "better paths at the price > of more CPU time", as ill-defined as it is and as long as this > meaning is clear to every one, no objection. Reading Section 6.3, > I think confusion can be minimized if you swap the second and > third paragraphs (removing "conversely" at the beginning) >
Here I fundamentally disagree and please see the discussion that took place on this on the list and requirements ID. There are many cases where synchronization is required. A simple case: computation of N diverse paths ... Other cases are so as to minimize call set failure due to double bw allocation and so on. Unless the WG desires to change this of course. [PT] Fully understand that there are nice algorithms to handle multiple path computations, with diverse paths perhaps the most important. The point is the ill definition of "synchronized": What does it really mean to PCC? to PCE? To illustrate, assume PCC asks for diverse paths and "synchronized" processing. PCE from vendor A has implemented a sophisticated algorithm that it calls synchronized (may be close to popular diverse computation algorithms). PCE from vendor B computes 1000000 alternate paths and finds disjoint paths between them, but claims it is synchronized. PCE from vendor C just cheats and processes the requests sequentially and succeeds in this example. As a PCC, you will not know the difference- and what is the point of asking for something that PCC cannot verify? What are the requirements that you as a PCC can detect, measure and verify? You can ask for a computation time of one second or less. It is up to PCE to make the best decision based on its current load (requests from other PCCs), etc. to pick the best among algorithms it supports, which may be proprietary and unnamed. You may even ask multiple PCEs and give them different requirements and pick between the paths returned. The reality is PCEs will provide better algorithms everyday, and providers will test these PCEs with known topologies, etc. to make sure they work ok with respect to algorithms. So, that was the point, but I am ok with the document at this stage, as the interface to PCE is flexible enough to support any requirements, and over time correct requirements will emerge, as we understand more. Thanks, Payam _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
