Hi Jean-Louis,
On Jan 12, 2006, at 1:16 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote:
Hi Jean-Philippe, all
I'm waking up a bit late on this thread...
No pb, still worth it !
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...).
Perfect ! We've got a WG consensus on this point that we can now close.
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...
Great, thanks.
JP.
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
