Subject: Re: [Pce] question on draft-king-hierarchy-fwk-03.txt

From: "Daniel King" <[email-masked]>
Date: Fri, 8 Jan 2010 12:02:16 -0000

Hi Yongli,

Thanks for reviewing the draft. In response to your questions:

1. The Parent PCE will determine the likely domain paths from the source to the destination. The Parent PCE will then send an edge-to-edge request to a Child PCE in the ingress domain (ingress-to-edge), and requests to a Child PCE in each candidate transmit domain (edge-to-edge) and finally a Child PCE in the egress domain (edge-to-egress). Once the responses are collated a suitable path can be identified and selected by Parent PCE. The Parent PCE will then send a response back to the Child PCE in the ingress domain. The Child PCE will then send an ERO response to the PCC that requested the inter-domain path. 

2. H-PCE has been designed so the Parent PCE will not have the same detailed internal domain topology information of the Child PCE's it services. However the Parent PCE does know capabilities of the links that connect the domains together. The inter-domain link information would be reported by the Child PCE during the initial Child and Parent PCE information exchange. The Child PCE can learn about its inter-domain links via its domain IGP. During "step 9" of the example procedure the Parent PCE has the opportunity to apply network or policy constraints based on its knowledge of the inter-domain links selected for the candidate path.

So in summary, one aim of H-PCE is to avoid the need for anyone one entity to have a detailed topology view of each transit domain. A Child PCE per domain, is used to compute a segment of the end-to-end path. The Child PCE can also replace its path segment information with a path-key [RFC5520] to further maintain confidentiality. 

On review of the step 9 procedure, we will update the text so the process and actual network topology view is clearer.  

Br, Dan.

From: 赵永利 [mailto:[email-masked]] 
Sent: 03 January 2010 09:45
To: [email-masked]
Cc: [email-masked]
Subject: question on draft-king-hierarchy-fwk-03.txt

Hi Dan,
     I have two questions on the document "draft-king-hierarchy-fwk-03.txt". 
(1) In the procedure of section 5.6.2, three domain paths have been gained, and PCEs 1 to 4 have received the path compuation requests from the parent PCE. Does it mean that the parent PCE will send edge-to-edge path computation requests to all the PCEs along all the domain paths?
 
(2) In step 9 of the same section, it seems not very clear about the compuation responses in the sentence of  "PCE 5 correlates all the computation responses from each child PCE". Does it mean the detailed constraint-based path segments in the local domain? 
    Thank you very much.
 
Best regards.

Yongli Zhao

Beijing University of Posts and Telecommunications
Beijing, China

---

From: 赵永利 <[email-masked]>
Date: Sun, 10 Jan 2010 20:28:39 +0800

Hi Dan
    Thank you very much for your answers.
     Ok. The Parent PCE can determine a likely domain path based on its
knowledge of the inter-domain links. However, the domain path may not be
optimal because it does not know the detailed information in each domain.
Maybe there is a balance between the optimization and the complexity. Do you
think so?
I am always wondering about the optimal end-to-end path in the current
framework.
     Another question. Can we abstract the detailed information in each
domain into some simple forms and provide them to the parent PCE? For
example, if we compute the shortest path according to the hop numbers. We
can gain the hop numbers between each border nodes pair in each domain by
the child PCE, and provide them to the parent PCE. Then the parent PCE can
gain the optimal the end-to-end path across multi-domains.

Best regards.

Yongli Zhao

2010/1/8 Daniel King <[email-masked]>

> 1. The Parent PCE will determine the likely domain paths from the source to
> the destination. The Parent PCE will then send an edge-to-edge request to a
> Child PCE in the ingress domain (ingress-to-edge), and requests to a Child
> PCE in each candidate transmit domain (edge-to-edge) and finally a Child PCE
> in the egress domain (edge-to-egress). Once the responses are collated a
> suitable path can be identified and selected by Parent PCE. The Parent PCE
> will then send a response back to the Child PCE in the ingress domain. The
> Child PCE will then send an ERO response to the PCC that requested the
> inter-domain path.
>
> 2. H-PCE has been designed so the Parent PCE will not have the same
> detailed internal domain topology information of the Child PCE's it
> services. However the Parent PCE does know capabilities of the links that
> connect the domains together. The inter-domain link information would be
> reported by the Child PCE during the initial Child and Parent PCE
> information exchange. The Child PCE can learn about its inter-domain links
> via its domain IGP. During "step 9" of the example procedure the Parent PCE
> has the opportunity to apply network or policy constraints based on its
> knowledge of the inter-domain links selected for the candidate path.
>
> So in summary, one aim of H-PCE is to avoid the need for anyone one entity
> to have a detailed topology view of each transit domain. A Child PCE per
> domain, is used to compute a segment of the end-to-end path. The Child PCE
> can also replace its path segment information with a path-key [RFC5520] to
> further maintain confidentiality.
>
> On review of the step 9 procedure, we will update the text so the process
> and actual network topology view is clearer.
>
> Br, Dan.
>
> (1) In the procedure of section 5.6.2, three domain paths have been gained,
> and PCEs 1 to 4 have received the path compuation requests from the parent
> PCE. Does it mean that the parent PCE will send edge-to-edge path
> computation requests to all the PCEs along all the domain paths?
>
> (2) In step 9 of the same section, it seems not very clear about the
> compuation responses in the sentence of  "PCE 5 correlates all the
> computation responses from each child PCE". Does it mean the detailed
> constraint-based path segments in the local domain?
>    Thank you very much.
>
> Best regards.
>
>
> Yongli Zhao
>

---

From: Peng He <[email-masked]>
Date: Sun, 10 Jan 2010 11:40:05 -0500

kind of distributed-computing system; if considering abstract say (TE)
info from domain internal to parent PCE, the fundamental question
might be what almost-exact information that are gonna be abstracted
and also need to make sure by abstracting the global end-to-end
optimal pach can still be achieved with no scalability concerns ...

Regards,
Peng

2010/1/10 赵永利 <[email-masked]>:
>> 1. The Parent PCE will determine the likely domain paths from the source
>> to the destination. The Parent PCE will then send an edge-to-edge request to
>> a Child PCE in the ingress domain (ingress-to-edge), and requests to a Child
>> (1) In the procedure of section 5.6.2, three domain paths have been
>> gained, and PCEs 1 to 4 have received the path compuation requests from the
>> parent PCE. Does it mean that the parent PCE will send edge-to-edge path
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 10 Jan 2010 20:20:32 -0000

Hi Yongli,

[speaking as an individual and co-author]

> The Parent PCE can determine a likely domain path based on
> its knowledge of the inter-domain links. However, the
> domain path may not be optimal because it does not know
> the detailed information in each domain.

I think there is something missing here. There would be zero value in this 
hierarchical PCE approach if it could not generate optimal paths!

The parent PCE is able to determine all potential end-to-end domain paths. 
It can then ask the child PCEs responsible for each domain to compute 
optimal paths across the domains and return those paths together with their 
costs.

The parent PCE can combining these paths to construct a set of potential 
end-to-end paths and can easily determine which is optimal by summing the 
costs of the segments.

Of course, the parent PCE does not need to perform this work for *all* 
potential domain paths if it can apply policy to guess that some domain 
paths are likely to result in suboptimal solutions.

Furthermore, the parent PCE can make a trade-off. By issuing computation 
requests to the children one at a time and using the returned information to 
prune domains from the set of potential domain paths. This (obviously) 
reduces the number of child PCEs involved and simplifies the computations 
they have to perform, but may take longer to reach a solution.

> Maybe there is a balance between the optimization and
> the complexity. Do you think so?

This is always the case. But we aim to produce a simple (non-complex) 
architecture that can be used in complex or simple environments, and that 
can provide optimal solutions.

> I am always wondering about the optimal end-to-end path in
> the current framework.
>
> Another question. Can we abstract the detailed information
> in each domain into some simple forms and provide them to
> the parent PCE? For example, if we compute the shortest
> path according to the hop numbers. We can gain the hop
> numbers between each border nodes pair in each domain by
> the child PCE, and provide them to the parent PCE. Then
> the parent PCE can gain the optimal the end-to-end path
> across multi-domains.

I am strongly opposed to this idea. Operating on a single metric like hop 
count, it appears that this approach might be practicable. It might suffer 
some instability during link failures, but this could be damped leading to 
sub-optimal paths in those windows.

But what value is this information is a sophisticated TE environment? If 
your definition of an "optimal" end-to-end path is limited to just least 
number of end-to-end hops, this mechanism can work. But the constraints on 
TE paths include *at*least* bandwidth availability as well. It becomes 
radically more complex to abstract the available bandwidth and tie it to the 
hop counts for all edge-to-edge connectivity across a domain. It is also 
likely that this information will change every time some unrelated LSP is 
set up within the domain. The result is a very large data set with a high 
rate of change and non-trivial abstraction processing.

Of course, an option is to aggregate the information by introducing 
approximations. This can reduce the size of the data set considerably, and 
will also reduce the flapping, but might not reduce the processing 
requirements. BUT, the main concern with such aggregation is that it loses 
information; and any loss of information risks the optimality of the final 
solution.

Moreover, when we extend the PCE model beyond "simple" packet TE 
environments to use cases with multiple constraints (consider the WSON work 
currently in hand) this abstraction becomes hopelessly complex.

So, the solution we have developed uses just a topological abstraction 
(i.e., what inter-domain links exist). It leaves every other item of the 
determination of cross-domain paths as the responsibility of the child PCEs.

Hope this helps.
Cheers,
Adrian

---

From: 赵永利 <[email-masked]>
Date: Mon, 11 Jan 2010 10:05:46 +0800

Hello Adrian and peng,
     Thank you for your valueable answers. I support the hierarchical PCE
approach.
     I understand the parent PCE can gain the optimal paths across diverse
domains if it asks all child PCEs along all potential end-to-end domain
paths. However, it is at the cost of comlexity. So the parent PCE can make a
trafe-off and apply some policy to gain the suboptimal solutions which is
practical in most environments. Is it right?
     If we want to compute the optimal paths at lower complexity, some
optimal approaches are necessary, such as the pruning approach Adrian said.
Actually, there are some problems with the abstracting method, such as the
instability and the complexity. However, all the information is also
necessary when the parent PCE asks the child PCEs. So can the child PCEs
compute and maintain the link information between each border nodes pair in
each domain in advance? Then the parent PCE can gain the end-to-end path
quickly. Furthermore, the child PCEs can compute and maintain the
information easily because they keep all the detailed information in the
local domain.
    What information and constraints are to compute and maintain is same to
that we consider in other documents.

Thanks.
Br.
Yongli

2010/1/11 Adrian Farrel <[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 12 Jan 2010 17:53:54 -0000

Hi,

Sure, a child PCE implementation could pre-compute paths across the domain, 
and supply those responses to the parent PCE when requested. In fact, any 
PCE is free to pre-compute any path.

In some circumstances this might be very sensible. In others, it might be a 
very poor solution.

I don't believe there is any change to the PCE architecture, protocols, or 
procedures to build such implementations.

Regards,
Adrian