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
Beijing University of Posts and Telecommunications
Beijing, China
2010/1/8 Daniel King <[email protected]>
> 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 protected]]
> Sent: 03 January 2010 09:45
> To: [email protected]
> Cc: [email protected]
> 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
>
>
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
