Hi Adrian et al,
On Jan 5, 2006, at 11:49 AM, Adrian Farrel wrote:
Hi,
I agree with Payam on the path computation algorithm issue.
OK. Not that we're counting votes, but that's two votes.
When a PCC builds a path computation request, it applies a service
specific
policies so that the new service will meet SLA requirements. Hence
PCC
requires a particular set of constraints, their relaxation
strategy in
case
they could not fully be met, optimization criterias, timing
parameters,
etc.
but it should not control nor care which algorithm PCE selects to
satisfy
such a request.
I completely get your point that most computation constraints
should be
quantative/qualative.
But what if it *does* care about the algorithm given more than one
algorithm that meets the contraints?
For example, it believes that there is a bug in
Dijkstra_Improved_By_Adrian that means that bad paths are sometimes
generated. So it wishes to request the use of
Dijkstra_Improved_By_Igor.
That would be a classic example of a service specific policy.
Such a policy might simply dictate a choice between PCEs in which
case no
further action is necessary on the computation request. But if the
chosen
PCE supports both algorithms, how will you satisfy the policy?
Clearly, you can't have a parameter on the computation request that
says
"please use the algorithm with fewest bugs".
[Hint: if you say the answer is that the PCC must pass "policy"
information to the PCE, you will find that this is compatible with the
text in the I-D at the moment.]
Right. Another example ... Why wouldn't these two scenario be valid ?
(1) SLAs (qualitative or quantitative) are specified as objective
within the path computation request without mentioning any algorithm
(2) The PCEs advertise within their capability the ability to support
a set of Algorithms along with their respective characteristics (e.g.
in term of computational resource requirement (and consequently
computation speed), path quality (and thus optimality) and so on
A PCC may decide for some LSP to request the use of Algo_1 versus
Algo_2 as a policy constraint. Furthermore, for a single LSP the PCC
may decide to request a specific algorithm depending on the
circumstances (e.g. less optimal but fast if the LSP is down and more
optimal but slower for a reoptimization).
It looks to me that both scenario may be required.
At this point, in order to close on this last remaining open item,
I'd like to pool the WG - especially Service Providers, please voice up.
Thanks.
Besides, if a PCC requires, say, "Dijkstra_Improved_By_Payam_Torab"
algorithm, how it can then verify that the specified algorithm indeed
was or
was not used?
I don't see why/how that quesiton is relevant. When a PCC requests a
shortest path, how does it verify that the path returned is the
shortest
that was available at the time of computation?
Cheers,
Adrian
----- Original Message -----
From: "Payam Torab" <[EMAIL PROTECTED]>
To: "'Adrian Farrel'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, January 04, 2006 6:04 PM
Subject: RE: [Pce] Re: Working Group Last
callondraft-ietf-pce-architecture-03.txt
Hi Adrian- The list is down to one point (algorithm
specification by PCC) thanks to your patience.
How about...
"A PCE-Based Network Architecture"
[PT] Thanks. Any title other than "PCE Architecture" would satisfy
the purpose, and sorry for stress on wording.
Are you saying that it is not possible to compute a path unless all
identifiers come from the same name space? 'Cos that is clearly not
true -
the computation operates on an abstraction.
I still don't get your point.
[PT] My point was the following example, which you believe
is not a PCE question. So, we'll just assume TED avoids name space
clash, and it is a design issue that does not need standardization.
You imply that the model described assumes that "PCEs have
information
on
other domains (aggregate or detailed) availabel a priori or upon
request."
This is not the case. I think you are confused by the text...
Multiple PCE path computation with inter-PCE communication
involves
coordination between distinct PCEs such that the result of the
computation performed by one PCE depends on information
supplied by
other PCEs.
You assume that the "information supplied" is TE information. But it
doesn't say that. Perhaps we should clarify what this information is
since
it is less than clear.
We will update this to indicate that the information is "path
fragment
information".
[PT] Yes- I was assuming the information refers to TE information.
Adding that the shared information can be path information or TE
information will serve the purpose, and no distinction between
model-based and ad hoc is necessary.
let's look at where ad hoc routing fits in.
There are two cases:
1. ...
2. The alternative is that all of the routing is done before any
signaling
is started. In this case, each PCE computes a segment of the
path and
passes the request on to the next PCE to compute the next
segment.
The segment paths are returned to the initial PCE which is
able to
pass the full path to the PCC. But this is exactly the case
described
in 5.4. Clearly there are variables.
- Does the initial PCE send requests to more than one other PCE?
- Does the initial PCE suggest multiple border nodes?
- Do the downstream PCEs return multiple paths with different
qualities to allow the initial PCE to choose?
If the answer to these and other questions is "no" then you have
ad
hoc routing.
[PT] While ad hoc has a much simpler definition (simply no TE
information
and no presumption about the sequence of domains taken),
discussion
is now irrelevant and you addressed the question.
Now, many people have told us that they *do* want to be able to
specify
which algorithm is used. And this may be very valid because cheap
(small,
local, easily accessed) PCEs might not be able to perform
simultaneous
computation of very many paths at the same time. It would then be
necessary
for these PCEs to reject the request (so that the PCC could
redirect it
to a
more sophisticated PCE) or redirect the request itself.
[PT] This is a sad point that kills the black box elegance of this
work.
What happens if I come up with a modified or original algorithm in
my
PCE
that outperforms existing algorithms?
What if you do?
1. I do not have to exert control, just because I have control. I
can
leave the choice to the PCE.
2. However, if I don't trust your new algorithm, I should be able to
select a different one.
In reality all algorithms have positive and negative points.
- Some are more accurate at the cost of being slower
- Some optimise for one feature ahead of other features
- Some are newly developed and untrusted
- Some work poorly in certain network contditions
To say that the user is unable to select the algorithm, is like
saying
that the user is not allowed to set the constraints.
[PT] I am sure this is an old discussion that algorithm
specification
per se is meaningless, as implementation or CPU power may be poor
for example. The only meaningful requirements are quantitative
metrics on accuracy, performance etc. As I said, if people have
asked for algorithm specification, they have
indeed asked for other requirements addressed by the algorithms.
If I
am wrong, and PCC is indeed required to be able to specify an
"algorithm",
then please mention that in the document. The point is let's not
walk away here, and make a declaration on algorithm issue.
Since this is a dangerous issue, let's be clear: Algorithm opacity
is fundamental to the value of this work, and if someone is
interested
in specifying an algorithm, they are in fact interested in one or
more
high-level requirements that are addressed by that algorithm. These
high-level requirements can be negotiated at the time of discovery,
which is a much better time than in the middle of
making a request and getting disappointed by a cheap PCE. I suggest
we
spell this out in the document.
I think it is late to revisit this argument.
However, if the WG wants to change its mind, I guess that's fine.
Anyone else want to support Payam on this point?
[PT] Thanks. Being late for my comments, I respect any decision,
but would be disappointed if we target algorithm specification.
But, again, I think you have it on its head. The requirement that is
presented in the draft is that the PCC must be able to constrin the
PCE to
do synchronized computation. That is, the PCC must be able to say "I
know
this is more work for you, and I know it will chew up your CPU,
and I
know
it requires you to implement a more clever algorithm, but I insist
that
you use synchronized computation because I want the better quality
result
that will be produced."
[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)
But suppose a PCE says "I can do fast unsynchronized computation, or
slow
synchronized computation" That is, the PCE has two algorithms
available.
So the PCC chooses this PCE to service its request. How will the PCE
know
which algorithm to use?
[PT] Ok. Although absolute requirements such as max path computation
time
are better in this case, I can also see they are hard to measure and
therefore hard to request.
- Section 6.6: Perhaps reliability instread of level of robustness?
Will you settle for the text suggested to Dimitri...
- the levels of resiliency, reliability and robustness of the
path
resources
[PT] Yes- thanks.
Thanks,
Payam
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
