Apparently I sent the message to the wrong thread. Please ignore my last post. Sorry for inconvenience. Payam --------
Hi JP and others- Here are some comments, suggestions and questions. Thanks, Payam ------ - Document title: We know this document does not intend to describe the architecture of a PCE- A title such as "Architectural Framework for End-to-End Path Computation using Path Computation Elements" is more appropriate. - Section 3 (Definitions): "Inter-domain path computation may involve the correlation of topology, routing and policy information between domains." What exactly do you mean by correlation? More descriptive text is needed here, may be an example. - Section 4.3: In case the TED is supplemented through configuration or management plane, how do we deal with the address space? Does the TED use IP addresses as identifiers? Yes and no answers deserve to be discussed here. - Section 4.9.2: "Back-off times, alternate path computations, and crankback can help to mitigate this sort of problem, and PCE may also improve the chances of successful TE LSP setup." Suggest "computation of alternate paths" to avoid ambiguity. Also, suggest adding the fundamental solution where the PCE supports batch requests (multiple path computation requests between source and destination pairs) by design, i.e., the requests are not processed sequentially. - Section 5.4: "Multiple PCE path computation with inter-PCE communication involves coordination between distributed PCEs such that the result of the computation performed by one PCE depends on information supplied by other PCEs. This model does not provide a distributed computation algorithm, but allows distinct PCEs to be responsible for computation of parts (segments) of the path." 1- I believe you mean different or distinct PCEs instead of distributed PCEs. 2- We need to exapnd this part. Cooperation between PCEs can take one of two forms, which we refer to as model-based and ad hoc. In model-based cooperation (the case described here), PCEs have information on other domains (aggregate or detailed, available a priori or upon request), and the path (or a section of the path) is decided by one PCE at the end. There is another way the PCEs can cooperate, where they do not share any information, and they find the end-to-end path in an ad hoc fashion (similar to DSR). In this case, we have a distributed path computation. - Figure 5: Suggest adding a link between NMS and TED to show alternate ways for synchronization (the TED synchronization arrow does not suggest a possible link to NMS). - Section 6.3: Synchronization is a bad term for this section. You definitely are not suggesting we compute paths based on a synchronized global clock ;) Suggest "Simultaneous path computation" for the section title, "simultaneous processing of path computation requests" for "synchronized path computation", and "sequential processing of path computation requests" for "non-synchronized path computation" - Section 6.3: Suggest "better" or "closer to optimal" instead of "more optimal". - Section 6.3: "The involvement of more than one PCE in the computation of a series of paths is by its nature non-synchronized. However, a set of cooperating PCEs may be synchronized under the control of a single PCE. For example, a PCC may send a request to a PCE which invokes domain-specific computations by other PCEs before supplying a result to the PCC." Can you elaborate here? - Section 6.3: "Conversely, the PCC may issue a single request to the PCE asking for all of the paths to be computed in a synchronized manner. The PCE will then perform simultaneous computation of the set of requested path. Such synchronized computation can often provide more optimal results." The distinction is clearly important in computation and algorithms, however, this is not an attribute that can be exposed to or requested by the user- user should have a more descriptive requirement (e.g., two full disjoint paths with total cost of less than x - how the answer is derived, through simultaneous or sequential processing is not something the user should ask for (it is like the user asks for Dijkstra's algorithm to be used). - Section 6.6: Perhaps reliability instread of level of robustness? "JP Vasseur" <> wrote in message news:[EMAIL PROTECTED] > Hi, > > A new revision of draft-ietf-pce-architecture has been edited > addressing several comments related to the Policy aspects, which > requires a new Working Group Last Call. > > This email initiates a working group last call on draft-ietf-pce- > architecture-03.txt. > > The last call will end on January 3 at noon EST. > > Please send your comments to the mailing list and copy the chairs. > > Thanks. > > JP. _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
