|
Hi,
JLLR> This depends on the
application. For some applications you may want a path with a minimum
delay..
I
absolutely agree. Indeed delay (like bandwidth..) is a
QoS requirment and could be different for
every request.
However, in section 6.1.17 it is mentioned for
example:
"Maximize
the residual bandwidth on the most loaded link"
that deals with Traffic Engineering optimization, and it not related
to QoS application requirements
JLLR> The PCE can reject a
request..
Agree, however, do you think that some objective functions indicated
in section 6.1.17 will be ever accepted by a PCE belonging to a different
domain?
Best regards
Filippo
----- Original Message -----
Sent: Thursday, February 16, 2006 5:20
PM
Subject: RE: Objective functions in PCECP
(draft-ietf-pce-comm-protocol-gen-reqs-04.txt)
Hi Filippo
Please see inline
Hi JL,
Ok for
the distinction, however, I still think objective functions should
not be included in PCECP.
It is
not clear to me why PCC should require different objective functions for
different requests.
JLLR> This depends on the
application. For some applications you may want a path with a minimum delay,
for other applications you may want a shortest cost delay
bounded path, for other applications you may want
a delay bounded widest path (e.g. upon blocking case, if the requested
bandwidth cannot be fit one may want the widest path),
etc....
Moreover, in
case of PCE-PCE request, a PCE could affect TE
optimization also within other domains.
JLLR> This is up to the PCE
to apply local policies and to filter request parameters. The PCE can
reject a request if the requested objective function is not
allowed.
Also note that inter-AS
specific aspects are beyond the scope of this draft. This should be covered
in the PCECP inter-AS requirement draft.
Best
Regards
JL
Thank
you
Filippo
----- Original Message -----
Sent: Thursday, February 16, 2006
12:13 PM
Subject: RE: Objective functions in
PCECP (draft-ietf-pce-comm-protocol-gen-reqs-04.txt)
Hi Filippo
Please note that "MAY include" =/= "MUST support the
inclusion"...
>As a general comment: is it
really a must to include in a communication protocol information
that may be common for all requests?
>maybe something could be better done
through configuration
No the inclusion is a MAY, but the protocol MUST allow you to
do it if you want...
Regards,
JL
Hi,
In section 3 (Introduction):
[..] The path computation request [..] MAY
also include an objective function.
In the rest of the document, MUST is always
used instead of MAY
One comment about the use of "MUST" related
to objective functions.
In my view some information are
request-specific (source, dest, bandwidth..),others are general (e.g.,
objective functions), i.e. they should be the same for every request.
For example, what about the overall network resource utilization (i.e.
optimization) if PCC requires different objective functions for
different requests?
As a general comment: is it really a
must to include in a communication protocol information that may be
common for all requests? maybe something could be better done
through configuration
Thank you
Filippo
|
