Hi Jean-Philippe, all I'm waking up a bit late on this thread...
Please see inline > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de JP Vasseur > Envoyé : samedi 7 janvier 2006 14:41 > À : [EMAIL PROTECTED] > Objet : [Pce] Working Group Last Call on > draft-ietf-pce-architecture-03.txtended > > WG, > > Working Group Last call on draft-ietf-pce-architecture-03.txt > ended has ended on January 3. There were several points > discussed on the list that all came to a resolution, except > one that relates to the ability for the PCC to request from > the PCE the use of a specific path computation algorithm. > This was listed as a requirement by several individual in the > past, three others recently mentioned that they were opposed >to it. If I well remember we add a long discussion a few monthes ago on this aspect and it was agreed that the request should not specify the algorithm but rather the objective function. And we updated the generic requirement ID to account for the result of that discussion by the way. I fully agree here with Payam, Igor and Dimitri. As already pointed out a few monthes ago, the PCC should IMO only indicate the objective it wants to achieve and then the PCE can select, in its algo box, an algorithm that achieves these objectives. Algortithms definition and selection is definitely a local implementation issue and should not be standardized. The algo selection should stay a local PCE decision that depends on various parameters (PCE capacities, PCE current load...). Also there are plenty of (G)MPLS path computation algorithms with plethora of variants, that differ with regards to the optimality, CPU consumption and computation time. What about if PCE support twenty distinct algorithms? As we all agree here, algorithm standarization does not make sense, hence a mechanism would be required to indicate to PCCs the characteristic of all these algorithms and the PCC would have to be able to understand all these characteristics before to make a selection... That' being said, it would be good to add, as a requirement, that the request must allow indicating whether computation time is an issue or not for the PCC (i.e. whether the PCC is hurried or not!). Then the PCE can select an appropriate algo. This could be achieved in a best effort way by using a simple bit flag in the request: H=0 means that the PCC is not hurried and the PCE should not care about computation time and should rather favor optimality when selecting an algo. This is the case for instance when setting up a new LSP or asking for a reoptimization. H=1 means that the PCC is hurried and the PCE should favor low computation time when selecting an algo. This is the case for instance when asking for an alternate path after failure (path restoration). Also, as suggested by Payam, this could be more sophisticated, and a PCC may also optionally indicate a computation time bound. A PCE that has the capability to predict the computation time of a given algo, based on the algo type and its current CPU load, can select an algorithm that best fits the optimization objectives and time constraints. Also, there are some algorithms (like for instance Lagrange relaxation based algorithms used for computation of delay bounded minimum cost paths) that progress toward an optimal solution and can stop when time is over and return the best computed path. Such approach would allow controlling the tradeoff "optimality vs computation time" in a really flexible manner, and this sounds definitely much better than a specific algorithm indication. To conclude I would suggest not standardizing any algo selection procedure but rather relying on objective functions that account for optimization criterias and time constraints. Anyway, one could still rely on yet not defined proprietary PCEP objects, if it really wants to support a proprietary PCC algo selection procedure... Best Regards, JL > > So we now need to close on this. Please voice you opinion. > > Once we'll get an agreement on the list, thanks to Adrian for > posting a new revision incorporating the changes. > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
