Hi Payam,
Thanks for your interest in this
document.
Responses in line.
Cheers,
Adrian
> 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.
> 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.
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?
> - 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.
> 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.
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.
> - 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.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?
> - 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.
Yes.
> 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.
> 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".
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.
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.
> - 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."
> - 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.
Yes.
> 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.
> 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?
> - 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).
> for synchronization (the TED synchronization arrow does not suggest a
> possible link to NMS).
Yeah, probably. The text covers this pretty well,
however.
Actually, we debated removing the TED
synchronization arrows as beyond the scope of PCE.
> - 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"
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
> optimal".
Agreed.
> - 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?
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.
> - 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).
> 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.
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
_______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
