Adrian, Please, see in-line.
Igor ----- Original Message ----- From: "Adrian Farrel" <[EMAIL PROTECTED]> To: "Igor Bryskin" <[EMAIL PROTECTED]>; "Payam Torab" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, January 05, 2006 11:49 AM Subject: Re: [Pce] Re: Working Group Last callondraft-ietf-pce-architecture-03.txt > 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. > IB>> Suppose a PCC explicitly asks for the Dijkstra_Improved_By_Igor. Nothing would prevent the PCE to still use the Dijkstra_Improved_By_Adrian because: a) PCE believes that all problems that happened in the past now are fixed; b) It takes less resources (and hence cheaper) while providing the same or better results. PCC gets the response and thinks that the Dijkstra_Improved_By_Igor was used. Now, if the paths prove still not to be good, PCC is even more confused because it believes that Dijkstra_Improved_By_Igor has the same problems as Dijkstra_Improved_By_Adrian used to have :=). To me requesting a particular path computation algorithm sounds as useful as requesting by an RSVP speaker from its peer a specific algorithm for label allocation or resource reservation. Note that there are precedents when a protocol speaker requires a particular algorithm from its peer. For instance, a Radius server may request MD5 or MD5 Ses or MD5 AKA algorithm for the digest computation. But this is necessary because both client and server must run the same algorithm for the operation to succeed. This is very different from the case of PCC-PCE communication. > 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.] > > > 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? IB>> Well, the resulting path will asumabely come with its cost. PCC could send the request to some other PCE and get the path with a lesser cost and choose the second path. The point is that PCC only can evaluate quantative characteristics visible from outside of the PCE. Igor > > 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
