Thanks Adrian- I snipped the resolved parts. See inline
for the rest.
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.- I don't think there is anything here that specifies that the computedpath must be end-to-end. Quite to the contrary, in fact.
[PT] Every path is end-to-end. What I meant is how we end up at the destination using PCEs, i.e., how PCEs take us from one end to another.- You are right that the document does not describe the architectureof a PCE. Rather it describes the architecture of a PCE-basedmodel. But the title doesn't say it describes the architecture of aPCE.This is such a small point. Do we really need to make a change?
[PT] The current title is "Path Computation Element (PCE) Architecture", which means the same thing as the architecture of a PCE. Sorry, this is a wrong title. Now I'm having a struggle myself finding the right title- based on your input, "Architecture for Path Computation Using a Path Computation Element (PCE)" is a better title. This way we also have room if we really want to have a document on PCE architecture.> - 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.I'm not sure I understand your question. The TED can use whatever identifiers it finds convenient. The only requirement is that the output should be useable by the PCC to generate signaling messages, and that the input could be generated from information taken from the IGP-TE. Both of these operations could utilise a mapping function.Is there some specific case underlying your question?
[PT] PCE is bringing together path computation functionalities in management plane and control plane. I was concerned about the identifiers used for network elements which do and do not have a control plane. As long as these IDs are assigned from the same pool we are fine. This is almost always the case (NMS assigning addresses to all elements), but I thought we need to mention that. Note this is the first time a common database TED is allowed to be supplemented by the two planes. For example, a switched connection appearing as a link in TED (an FA-LSP for example) needs to have an Id. How do we make sure this Id is not the same as the Id assigned to a transport link with no control plane?
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.It is hard to see how multiple PCCs could arrange for batched processing without removing any sense of real time computation. Perhaps this is your point? In order to guarantee non-conflicting computation, it is necessary to batch all computations together on single centralized server performing all computations "simultaneously".
[PT] Batch processing simply means processing multiple requests together. This is a PCE feature and PCCs have no knowledge or control over it. PCE may choose to wait to receive multiple requests, or the case that makes more sense is PCE is busy with a task at hand, and once done there are one or more requests in the queue, and PCE processes them together. So, it is invisible to PCC.But, our point is that even this does not guarantee LSP establishment. The sentence after the one you quote says...However, a single, centralized
PCE is not viewed as a solution that can guarantee TE LSP
establishment since the potential for network failures or contention
for resources still exists where the centralized TED cannot fully
reflect current (i.e., real-time) network state.So I don't think your proposed solution is *the* fundamental solution.
[PT] well we are not talking about going to the moon, so when I say fundamental I mean -the- best algorithmic solution given all the existing requests at the time- any path computation result is of course subject to blocking. Now, beyond the choice of words:The text is about computing two or more paths, which could happen in response to requests by one or more PCCs. One PCC may make multiple path computation requests for different source-destination pairs (different sources could be different starting interfaces on the same node for example). The ability to process these requests together (flow-based computation) is -the- best solution. Even in case the requests arrive from multiple PCCs, batch processing is indeed the best solution to the problem described here, and if we want to hint at any solution we should at least mention the best one.So, here's a shot at the paragraph, which actually sits nice with the second part: "Batch processing of all requests, back-off times, computing alternate paths, and crankback can help to mitigate this sort of problem, and PCE may also improve the chances of successful TE LSP setup. However, a single, centralized PCE is not viewed as a solution that can guarantee TE LSP establishment since the potential for network failures or contention for resources still exists where the centralized TED cannot fully reflect current (i.e., real-time) network state."
> 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.In your second case, how is the route known by the PCC? Isn't it the case that the PCEs share the computed route fragments?
[PT] Yes and no- they share route fragments, but these fragments are not limited to each domain , rather they end at destination. Suggest looking at DSR ad hoc routing. With -zero- topology information shared between PCEs, a complete end-to-end path can be computed in a distributed fashion.
> - 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).When you say "user" do you mean the PCC?In the first instance the PCC MUST be responsible for this level of determinism. That is, if it makes two separate requests for paths, simultaneous computation cannot be performed. But nevertheless the requests would be valid...1. Compute me a path from A to B with least cost.2. Compute be a path from A to B that is disjoint from the previous path and which has least cost.Thus, the PCC already has some control over whether simultaneous computation is requested.
[PT] Not true. As described above PCE may choose to batch process the requests and process these two requests (and possibly many more in the queue) together. We should not assume any correlation between how the requests are sent and how they are processed. Therefore, the starting paragraph in Section 6.3 also needs to be modified, as multiple PCC requests does not necessarily mean non-synchronized path computation (unless explicitly requested, which we'll address in the next bullet).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? It may never get called because its algorithm is not listed in the PCC list of algorithms. 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.So, is synchronized vs. non-synchronized an algorithmic requirement, or a high-level requirement? My view is that it is a (poorly defined) algorithmic requirement. I can think of a high-level requirement but believe it is outside the scope (e.g., total cost should be within x% of the solution that is found by processing n requests at the same time).The point is we should drop the whole idea of asking for synchronized or non-synchronized computation. The better approach is to have the PCC learn the PCE capabilities at the time of discovery and decide not to choose a PCE because it cannot satisfy a more high-level requirement.> - Section 6.6: Perhaps reliability instread of level of robustness?Oooh!Having spent some time with Mr. Webster, I conclude that Reliable and Robust are adequate synonyms.
[PT] Sorry about being picky for certain words, but there are tons of material on assigning reliability functions (standard term in reliability engineering with clear definition based on the resource failure rate and resource age) to network elements/resources, and using reliability as a metric in path computation- Suggest you do a search for "computing the most reliable path".
_______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
