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
