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

From: "Payam Torab" <[email-masked]>
Date: Tue, 3 Jan 2006 12:56:30 -0500

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-masked]...
> 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-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Jan 2006 21:13:45 -0000

Hi Payam,

Thanks for your interest in this document.

Responses in line.

Cheers,
Adrian

> End-to-End Path Computation using Path Computation Elements" is more

I think I disagree. There are a couple of points.
- Architecture and Framework have meanings established by usage
  within the IETF (in fact the PCE WG has already been around the
  houses once discussing whether to use "architecture" or "framework").
  The document as it stands describes an architecture.
- 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.
- 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?

> What exactly do you mean by correlation? More descriptive text is needed

Hmmm. I guess that by "correlation" we meant that there may be a need to bring together in mutual realtionship the topology, routing and policy information that exists in the separate domains. I suppose an example would be that in order to perform inter-domain path computation we might need to pull together routing information from both domains.

I'm sturggling to find a way to say this different from what I typed. Maybe someone else can suggest some text.
 
> 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?

> paths" to avoid ambiguity.

Yes.

> Also, suggest adding the fundamental solution

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".

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.

> of the path." 
> 1- I believe you mean different or distinct PCEs instead of distributed PCEs.

Yes.

> 2- We need to exapnd this part. Cooperation between PCEs

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?

> for synchronization (the TED synchronization arrow does not suggest a

Yeah, probably. The text covers this pretty well, however.
Actually, we debated removing the TED synchronization arrows as beyond the scope of PCE.

> computation requests" for "non-synchronized path computation"

Synchronization is from the verb, to synchronize.
Synchorinze - to make synchronous
Synchronous - happening at the same time; occurring together; simultaneous

So I don't see that changing "synchronized" for "simultaneous" has any gain.

In fact, in the third paragraph we use both "synchronized" and "simultaneous" to make double sure that we are understood.

> - Section 6.3: Suggest "better" or "closer to optimal" instead of "more

Agreed.

> computations by other PCEs before supplying a result to the PCC." Can you

Well, consider four domains:
  B
 / \
A   D
 \ /
  C

A PCC in domain A may request a pair of diverse paths from an ingress in domain A to an egress in domain B.

Let us assume that there are multiple domain border nodes between domains B and D, but between no other domains.

The PCE for domain A may request paths from the domains B and C. The PCE for domain B may return several candidate paths. The PCE for domain A will now request paths through domain D to the egress and considering the entry points into domain D from domains B and C.

Once the results are in, the PCE for domain A can select a pair of disjoint paths. (Disjointedness being necessary in domains A and D).

HOWEVER, this example of how one might decompose a request is entirely implementation-specific. There are other applicabilities of PCE cooperation that might achieve this differently.

> 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.

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.

> - Section 6.6: Perhaps reliability instread of level of robustness?

Oooh!

This sent me scampering to the CCAMP P&R drafts to find the definitions of reliable and robust. Unfortunately not there :-(

Having spent some time with Mr. Webster, I conclude that Reliable and Robust are adequate synonyms. The reason that I don't like to use "reliable" is an old networking joke...

    You can rely on our product completely. It fails *every* Tuesday.

However, I also note that we should include Resilience. So the bullet now reads...

   - the levels of robustness and resilience of the path resources

---

From: [email-masked]
Date: Wed, 4 Jan 2006 00:49:07 +0100

adrian - some hints inline

Hi Payam,

Responses in line.
 
Cheers,
Adrian

 
 
[dp] point has been already discussed; so, ok but only if there is no 
other document planned that is going to describe the PCE architecture

> What exactly do you mean by correlation? More descriptive text is needed
 
Hmmm. I guess that by "correlation" we meant that there may be a need to 
bring together in mutual realtionship the topology, routing and policy 
information that exists in the separate domains. I suppose an example 
would be that in order to perform inter-domain path computation we might 
need to pull together routing information from both domains.
 
I'm sturggling to find a way to say this different from what I typed. 
Maybe someone else can suggest some text.

[dp] the notion of correlation could be replaced by "association of 
topology, routing and policy information of two or more domains from which 
specific relationships may be deduced in order to help in performing path 
computation."
 
> 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.

 
Yes.
 
> between source and destination pairs) by design, i.e., the requests are 
not
 
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".
 
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.

 
Yes.
 
> 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?

Yeah, probably. The text covers this pretty well, however.
Actually, we debated removing the TED synchronization arrows as beyond the 
scope of PCE.

 
So I don't see that changing "synchronized" for "simultaneous" has any 
gain.
 
In fact, in the third paragraph we use both "synchronized" and 
"simultaneous" to make double sure that we are understood.

[dp] don't think the issue is on sync'ing computation but on combining 
e.g. protected and protecting path computation to avoid trap problem; so i 
would suggest making use of the term "separated" or "disjoint" vs "joined" 
path computation

Agreed.

A PCC in domain A may request a pair of diverse paths from an ingress in 
domain A to an egress in domain B.
 
Let us assume that there are multiple domain border nodes between domains 
B and D, but between no other domains.
 
The PCE for domain A may request paths from the domains B and C. The PCE 
for domain B may return several candidate paths. The PCE for domain A will 
now request paths through domain D to the egress and considering the entry 
points into domain D from domains B and C.
 
Once the results are in, the PCE for domain A can select a pair of 
disjoint paths. (Disjointedness being necessary in domains A and D).
 
HOWEVER, this example of how one might decompose a request is entirely 
implementation-specific. There are other applicabilities of PCE 
cooperation that might achieve this differently.

 
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.
 
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.
 
Oooh!
 
This sent me scampering to the CCAMP P&R drafts to find the definitions of 
reliable and robust. Unfortunately not there :-(

[dp] p&r deals with resiliency issues and to clarify these terms

resiliency = ability of a system to reach and maintain an acceptable level 
of functioning and structure with one or more of its components 
malfunctioning 

reliability = ability of a system or component to perform consistently its 
required functions under stated conditions for a specified period of time

robustness = the degree to which a system or component can function 
correctly in the presence of invalid inputs or stressful environment 
conditions

Having spent some time with Mr. Webster, I conclude that Reliable and 
Robust are adequate synonyms. The reason that I don't like to use 
"reliable" is an old networking joke...

However, I also note that we should include Resilience. So the bullet now 
reads...

---

From: "Payam Torab" <[email-masked]>
Date: Wed, 4 Jan 2006 06:09:21 -0500

Thanks Adrian- I snipped the resolved parts. See inline for the rest.
Payam

  - 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. What I meant is how we end up at the
destination using PCEs, i.e., how PCEs take us from one end to another.

  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.

  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?

  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.

  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."

  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.

simultaneous computation cannot be performed. But nevertheless the requests
would be valid...

  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.

  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".

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 4 Jan 2006 12:26:18 -0000

Thanks Dimitri,

>>> - 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.
>>

If the working group thinks "association" is a more acceptable word than
"correlation", I'm easy with that.

The second half of your sentence is useful. Thanks.

> would suggest making use of the term "separated" or "disjoint" vs
"joined"

I don't get it. None of these terms (including the one we currently have
in the I-D) has any meaning without an accompanying definition. So why is
it so important to change the word? I prefer to use a word that sits
naturally in the language.

> correctly in the presence of invalid inputs or stressful environment

Well, given that statement, I guess our text should read...

  - the levels of resiliency, reliability and robustness of the path
resources

... which should satisfy Payam as well.

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 4 Jan 2006 13:35:29 -0000

Hi,

> want to have a document on PCE architecture.

Well, I must confess that I find this discussions of semantics
frustrating. However, if the title confused you that is reason enough to
change it.

But we must change it to something that is accurate.

How about...
   "A PCE-Based Network Architecture"

>>> 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
> need to mention that.

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.

So you may be saying that the computed path must be presented to the PCC
using identifiers that can be understood by the PCC. But that is only
superficially true - the PCC only needs to understand the identifiers that
it must process. It is quite conceivable that a multidomain path will be
signaled by a control plane for the first domain, but will cross an E-NNI
into a domain where the LSP is established using a management plane.

I still don't get your point.

> Note this is the first time a common database TED is
> allowed to be supplemented by the two planes.

Well, it is not the first time a routing database has been built from
management and control plane information. I think this has been happening
for a while.

> For example, a switched

This is not a PCE question.

>>> 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.
>>
> 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
> more requests in the queue, and PCE processes them together. So, it is

Sure, PCE could operate in this way.
And PCC could chhose not to issue the second request until it has received
a response to the first request. So, you see, PCC *can* exercise control
over this function.

Yes.

>>> 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.
>>

This sounds like we're going round in circles.
Recall, we are in section 5.4 (Multiple PCE Path Computation with
Inter-PCE Communication).

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".

But maybe you will still class this as aggregate TE information and say
that this is model-based cooperation. That's OK, but let's look at where
ad hoc routing fits in. There are two cases:
1. The routing progresses in step with the signaling. That is, each
segment
    is computed and signaled, then the next segment is computed and
    signaled, and so on. In this case the each PCE is invoked
independently
    and there is no cooperation or communication between PCEs. This is
    the model shown in section 5.3.
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.

>>> - 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).
requests
> requests are sent and how they are processed.

With respect, this is tosh.
If I send request number one and do not send request number two until I
see the response to request number one then I have complete control over
the requests being processed separately and the PCE (unless psychic)
cannot do anything about it.

I think you have this on its head and should re-read 6.3.
Here you will find that the PCC does not have the power to force the PCE
to process requests separately except by withholding the subsequent
requests.
OTOH the PCC does have the power to require that the PCE process requests
simultaneously.
The middle option is that the PCC can say that the PCE is free to process
the requests separately if it chooses.

> Therefore, the starting

OK. I can change "will" to "may" to read...
   In this case of non-synchronized path computation, the PCE may make
   multiple individual path computations to generate the paths and the

>> computation of very many paths at the same time. It would then be
necessary
> 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.

> It may never get called because its

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?

> is found by processing n requests at the same time).

Hmmm.
Suppose I set up an unprotected service.
Now I change the service to desire protection.
This can only be achieved by non-synchronized computation (unless I always
assume that all services might one day need all features!)

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."

> because it cannot satisfy a more high-level requirement.

And how will you describe the PCC capabilities? Presumably you will
indicate that the PCE can or cannot perform synchronized computation.

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?

> metric in path computation- Suggest you do a search for "computing the
most

You are welcome to be picky about the use of English; I am all the time.

Will you settle for the text suggested to Dimitri...

Cheers,
Adrian

---

From: JP Vasseur <[email-masked]>
Date: Wed, 4 Jan 2006 11:25:58 -0500

Hi,

[snip]

>>   [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

Agree, Adrian, this should be clarified since this is apparently not  
clear.

Payam, in the case of inter-Provider it is more than likely that no  
TE information will be shared at all but rather computed (loose) path  
along with their respective cost.

>     If the answer to these and other questions is "no" then you  

Payam, does this explanation close the point ?

>>>   2. Compute be a path from A to B that is disjoint from the  
>>> previous
> path

Fully agree, as pointed out in my previous email.

>    multiple individual path computations to generate the paths and the

ok

>>> for these PCEs to reject the request (so that the PCC could  
>>> redirect it
> to a

See previous email.

>> they are in fact interested in one or more high-level requirements  
>> that
> are
>> 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
>> So, is synchronized vs. non-synchronized an algorithmic  
>> requirement, or
> a
>> outside the scope (e.g., total cost should be within x% of the  
>> solution
> that

In sync with Adrian as per my previous email.

>> the PCE capabilities at the time of discovery and decide not to  
>> choose a
> PCE

Note that this belongs to the requirements IDs ... To be discussed in  
this context.

>> metric in path computation- Suggest you do a search for "computing  
>> the
> most
>> reliable path".
>

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 4 Jan 2006 11:15:49 -0500

Hi,

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

> [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.
> [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.
> 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.
>
> 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 ...
> 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...
> 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 ...
> ad hoc. In
> share any
> 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?
> 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.
>
> the PCE
> [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
> 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.
>
> 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.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 4 Jan 2006 10:57:18 -0500

Hi,

Thanks Payam for the comments.

> This is such a small point. Do we really need to make a change?

Since this point has already been raised, we may want to change the  
title for something like "A PCE-based architecture model" ?

On the other comment I agree with Adrian, there is no assumption on  
whether the computed path must be end to end. For the sake of  
illustration, there could be a end-to-end TE LSP spanning multiple  
domains where path segments are computed using various techniques.

> Hmmm. I guess that by "correlation" we meant that there may be a  
> need to bring together in mutual realtionship the topology, routing  
> and policy information that exists in the separate domains. I  
> suppose an example would be that in order to perform inter-domain  
> path computation we might need to pull together routing information  
> from both domains.
>
> I'm sturggling to find a way to say this different from what I  
> typed. Maybe someone else can suggest some text.
>

Looks clear enough to me ...

> A PCC in domain A may request a pair of diverse paths from an  
> ingress in domain A to an egress in domain B.
>
> Let us assume that there are multiple domain border nodes between  
> domains B and D, but between no other domains.
>
> The PCE for domain A may request paths from the domains B and C.  
> The PCE for domain B may return several candidate paths. The PCE  
> for domain A will now request paths through domain D to the egress  
> and considering the entry points into domain D from domains B and C.
>
> HOWEVER, this example of how one might decompose a request is  
> entirely implementation-specific. There are other applicabilities  
> of PCE cooperation that might achieve this differently.
>
>
> > user should have a more descriptive requirement

Clearly, it is since the PCC would stipulate the requirement for  
simultaneous computations in its request. See for example the set of  
mechanisms specified in PCEP.

> (e.g., two full disjoint
> This sent me scampering to the CCAMP P&R drafts to find the  
> definitions of reliable and robust. Unfortunately not there :-(
>
> and Robust are adequate synonyms. The reason that I don't like to  
> use "reliable" is an old networking joke...
>

Thanks.

JP.

---

From: "Payam Torab" <[email-masked]>
Date: Wed, 4 Jan 2006 18:04:19 -0500

Hi Adrian- The list is down to one point (algorithm
specification by PCC) thanks to your patience.

How about...

[PT] Thanks. Any title other than "PCE Architecture" would satisfy
the purpose, and sorry for stress on wording.

[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.

[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.

necessary

What if you do?

[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.

[PT] Thanks. Being late for my comments, I respect any decision,
but would be disappointed if we target algorithm specification.

[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)

[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.

[PT] Yes- thanks.

Thanks,
Payam

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 5 Jan 2006 10:07:30 -0500

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-masked]>
To: "'Adrian Farrel'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 04, 2006 6:04 PM
Subject: RE: [Pce] Re: Working Group Last
callondraft-ietf-pce-architecture-03.txt

---

From: "Payam Torab" <[email-masked]>
Date: Thu, 5 Jan 2006 11:44:08 -0500

Hi JP - Your question got lost in the middle of text.

>     If the answer to these and other questions is "no" then you  
>     have ad hoc routing.
>

[PT] Yes- Adrian's update to clarify that the shared information
can be TE information or path information closed this discussion.

Thanks,
Payam

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 Jan 2006 16:49:54 -0000

Hi,

> I agree with Payam on the path computation algorithm issue.

OK. Not that we're counting votes, but that's two votes.

> but it should not control nor care which algorithm PCE selects to
satisfy

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.

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.]

> algorithm, how it can then verify that the specified algorithm indeed
was or

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?

Cheers,
Adrian

> > >> Now, many people have told us that they *do* want to be able to
specify
redirect it
> > > [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

---

From: JP Vasseur <[email-masked]>
Date: Thu, 5 Jan 2006 12:28:11 -0500

Hi Adrian et al,

On Jan 5, 2006, at 11:49 AM, Adrian Farrel wrote:

>> requires a particular set of constraints, their relaxation  
>> strategy in
> case
>> they could not fully be met, optimization criterias, timing  
>> parameters,
> etc.

Right. Another example ... Why wouldn't these two scenario be valid ?

(1) SLAs (qualitative or quantitative) are specified as objective  
within the path computation request without mentioning any algorithm
(2) The PCEs advertise within their capability the ability to support  
a set of Algorithms along with their respective characteristics (e.g.  
in term of computational resource requirement (and consequently  
computation speed), path quality (and thus optimality) and so on
A PCC may decide for some LSP to request the use of Algo_1 versus  
Algo_2 as a policy constraint. Furthermore, for a single LSP the PCC  
may decide to request a specific algorithm depending on the  
circumstances (e.g. less optimal but fast if the LSP is down and more  
optimal but slower for a reoptimization).

It looks to me that both scenario may be required.

At this point, in order to close on this last remaining open item,  
I'd like to pool the WG - especially Service Providers, please voice up.

Thanks.

>>> You imply that the model described assumes that "PCEs have  
>>> information
> on
>>> this is more work for you, and I know it will chew up your CPU,  
>>> and I
> know

---

From: JP Vasseur <[email-masked]>
Date: Thu, 5 Jan 2006 12:41:40 -0500

Hi,

> specification by PCC) thanks to your patience.

Glad that we're approaching a closure, thanks.

See below,

> the purpose, and sorry for stress on wording.

I'll send an email summary on the list with three proposals, should  
people desire to make express their opinion. Anyway, there was a need  
for a title change indeed, thanks.

> information on

ok, point closed then.

> have ad
>> my PCE

See my other emails. Your opinion is well taken, let's see what  
others think. But yes indeed, we heard several people requiring  
algorithm selection ...

> (removing "conversely" at the beginning)

Here I fundamentally disagree and please see the discussion that took  
place on this on the list and requirements ID. There are many cases  
where synchronization is required. A simple case: computation of N  
diverse paths ... Other cases are so as to minimize call set failure  
due to double bw allocation and so on.

Unless the WG desires to change this of course.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 5 Jan 2006 13:19:47 -0500

Thanks.

JP.

---

From: "Payam Torab" <[email-masked]>
Date: Thu, 5 Jan 2006 13:51:35 -0500

Hi JP,

> 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)
>

[PT] Fully understand that there are nice algorithms to handle
multiple path computations, with diverse paths perhaps the most
important. The point is the ill definition of "synchronized": What
does it really mean to PCC? to PCE? To illustrate, assume PCC asks
for diverse paths and "synchronized" processing. PCE from vendor A
has implemented a sophisticated algorithm that it calls synchronized
(may be close to popular diverse computation algorithms).
PCE from vendor B computes 1000000 alternate paths and finds
disjoint paths between them, but claims it is synchronized.
PCE from vendor C just cheats and processes the requests
sequentially and succeeds in this example. As a PCC,
you will not know the difference- and what is the point of
asking for something that PCC cannot verify?

What are the requirements that you as a PCC can detect,
measure and verify? You can ask for a computation time
of one second or less. It is up to PCE to make the best decision
based on its current load (requests from other PCCs), etc. to
pick the best among algorithms it supports, which may be
proprietary and unnamed. You may even ask multiple PCEs
and give them different requirements and pick between
the paths returned.

The reality is PCEs will provide better algorithms everyday,
and providers will test these PCEs with known topologies, etc.
to make sure they work ok with respect to algorithms. So,
that was the point, but I am ok with the document at this
stage, as the interface to PCE is flexible enough to support any
requirements, and over time correct requirements will emerge,
as we understand more.

Thanks,
Payam

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 5 Jan 2006 13:53:15 -0500

Adrian,

Please, see in-line.

Igor
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>; "Payam Torab" <[email-masked]>;
<[email-masked]>
Sent: Thursday, January 05, 2006 11:49 AM
Subject: Re: [Pce] Re: Working Group Last
callondraft-ietf-pce-architecture-03.txt

> 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.

> 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

> assumption

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 Jan 2006 23:25:50 -0000

Hi,

I'm not sure this is worth pursuing, but I will because I never can leave
tings alone...

> > > algorithm, how it can then verify that the specified algorithm
indeed
> > > was or was not used?
> choose the second path. The point is that PCC only can evaluate
quantative
> characteristics visible from outside of the PCE.

Actually, you can only test whether another PCE can compute a shorter path
at a different time using potentially different information. You simply
cannot catch the PCE out in a lie unless you also ask it to dump its TED
and do the computation yourself.

Hey, and what if the PCEs were cooperating in fibbing to you. My God! It's
a global conspiracy!

And why would a PCE say it had used one algorithm when it had actually
used another?

A

---

From: [email-masked]
Date: Fri, 6 Jan 2006 02:06:52 +0100

adrian - this is what is called reliability a system does what it claims 
to do; more specifically the question is not there, the question is 
whether one can trust the delegation of a given computation such that the 
PCC receives an answer inline with its request

the other side issue is whether the PCE architecture model does also 
include 1) PCE performance objectives and 2) if those have to be taken 
into account during PCE selection by the PCC(s)
 
if this is the case the latter shall be translated in the same way as you 
translate other objectives on the computation task result (such as 
"maximize residual bandwidth on most loaded links" or "shortest bounded 
delay path") in terms of resource consumption vs computation result speed; 
but there is no need tell how this objective is achieved 

thanks,
- dimitri.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
06/01/2006 00:25
Please respond to Adrian Farrel
 
        To:     "Igor Bryskin" <[email-masked]>, "Payam Torab" 
<[email-masked]>, <[email-masked]>
        cc: 
        Subject:        Re: [Pce] Re: Working Group Last 
callondraft-ietf-pce-architecture-03.txt

Hi,

indeed
quantative

A

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 6 Jan 2006 11:23:31 -0500

Adrian,

Please see in-line.

Igor

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>; "Payam Torab" <[email-masked]>;
<[email-masked]>
Sent: Thursday, January 05, 2006 6:25 PM
Subject: Re: [Pce] Re: Working Group Last
callondraft-ietf-pce-architecture-03.txt

> And why would a PCE say it had used one algorithm when it had actually

Hey,

a) Because it can
b) Because it is a good marketing point - I can sell more PCEs if I claim
that I support Dijkstra_Improved_By_Igor

We agreed long time ago that we do not standardize path computation
algorithms.
So what does it mean that my PCE supports Dijkstra_Improved_By_Igor? It
means pretty much nothing because even if this is a published algorithm
anybody can add any tweaks he wants and still claim that this is
Dijkstra_Improved_By_Igor.

So in IMO it does not make any sense to neither advertise nor request path
computation algorithms.

Igor