Re: [Pce] Re: Working Group Last call ondraft-ietf-pce-architecture-03.txt

Hi,

On Jan 4, 2006, at 6:09 AM, Payam Torab wrote:

> 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  
> computed
>   path must be end-to-end. Quite to the contrary, in fact.
> [PT] Every path is end-to-end.
Nope, as pointed out in my previous email, a PCE may be responsible  
for the computation of a path segment. This part of a path is not an  
end to end path.
> What I meant is how we end up at the destination using PCEs, i.e.,  
> how PCEs take us from one end to another.
There are many possible ways. One of the possible procedure has been  
described some time ago in draft-vasseur-ccamp-inter-domain-path- 
comp-00.txt  (Scenario 2) and will be resurrected soon. One can  
expect separate IDs proposing different models.
>
> - You are right that the document does not describe the architecture
>   of a PCE. Rather it describes the architecture of a PCE-based
>   model. But the title doesn't say it describes the architecture of a
>   PCE.
>
> 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.
I'll follow up on the list on the proposal ... trying to quickly  
converge here.
> > - 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?
Not sure to see your point here ...
>
>  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.
Again, this is not correct. It is fundamental for the PCC to be able  
to have a control over it, at least for its own set of requests.
> 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.
Quite frankly I do not think that the discussion on the optimality of  
the so called global optimization and local optimization belongs to  
this ID at all. In this case, even in the case of global optimization  
you could also discuss many different algorithms ... Again, does not  
belong to this ID.
>
> 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."
Does not hurt to add this text although that sounds pretty obvious ...
>
> > 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.
>
The control of the algorithm used by the PCE is entirely optional. On  
the discovery requirement aspect, you may want to discuss this in the  
context of draft-ietf-pce-discovery-reqs-02.txt
> 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.
Note that this has been discussed quite a few times within the WG  
with a consensus to be able to request for synchronized or non- 
synchronized computation (see requirements ID and solution ID).
> 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".
Thanks.

JP.
>
>