Hi, I agree with Payam on the path computation algorithm issue.
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. 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? Igor ----- 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
