Subject: [Pce] question about draft-king-pce-hierarchy-fwk-03

From: Oscar González de Dios <[email-masked]>
Date: Wed, 26 May 2010 17:28:56 +0200

Dear authors/all

                I have a few comments about draft-king-pce-hierarchy-fwk-03. It this draft, it is specified in section 3.1 the applicability of BRPC when the Domain Path is Not Known. Bellow are my comments with regards to the text in the draft:

-          "When the ingress PCE has received a VSPT from each of its neighboring domains it is able to select the optimum path": Comment #1: Some of the neighboring domains may not send a VSPT (they may not be connected to any other domain, or just cannot reach the domain of the destination LSP). Thus, the ingress PCE should not expect an answer from each of the neighboring domain, but only from some. In that case, should there be a timer set when the first answer (VSPT) arrives, and when either the timer is over or all the neighboring domains have answered, then select the path?

-          "Each PCE in turn constructs a VSPT and passes it on to all of its neighboring PCEs". Comment #2: Clearly, the set of domains that are already part of the VSPT should be excluded when passing the VSPT. Comment #3:  A intermediate PCE could receive VPSTs from different domains. What should it do then? Complete all the VPST it receives and send them? Send just the first? And in case the PCE send multiple VSPTS (each would be a different sequence of domains), then the ingress PCE should receive all of them before selecting the optimum path. In such case, the timer mechanism could fit....

-          "The ingress PCE sends the path computation request direct to the  PCE responsible for the domain containing the destination node (the egress PCE)". Comment #4: Do you assume that the PCEs knows how to reach all the other PCEs? I assume that, at least a PCE must know how to reach its neighboring PCEs. If the PCE only knows that information, the request should be flooded until it reaches the egress PCE.

Best Regards,

                Óscar

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 27 May 2010 12:41:57 +0100

Hello Oscar,

Thanks for reading.

> I have a few comments about draft-king-pce-hierarchy-fwk-03. It this 
> draft,
> it is specified in section 3.1 the applicability of BRPC when the Domain 
> Path
> is Not Known. Bellow are my comments with regards to the text in the 
> draft:
>
> - "When the ingress PCE has received a VSPT from each of its neighboring
>    domains it is able to select the optimum path": Comment #1: Some of the
>    neighboring domains may not send a VSPT (they may not be connected
>    to any other domain, or just cannot reach the domain of the destination
>    LSP). Thus, the ingress PCE should not expect an answer from each of
>    the neighboring domain, but only from some. In that case, should there
>    be a timer set when the first answer (VSPT) arrives, and when either 
> the
>    timer is over or all the neighboring domains have answered, then select
>    the path?

Good catch.
Yes, we only described the positive case. We should add two other cases:
1. The PCE in the neighboring domain cannot find a path to the egress
    (for whatever reason) and returns an error for the PCReq.
2. The PCE in the neighboring domain fails to respond (a timeout pops).

We should add a sentnce to cover this.

> - "Each PCE in turn constructs a VSPT and passes it on to all of its
>    neighboring PCEs".
>   Comment #2: Clearly, the set of domains that are already part of the
>    VSPT should be excluded when passing the VSPT.

Well, indeed.
There are two ways of excluding.
1. If a PCE knows the domain is already in the path, it does not send
   a VPST to a neighboring PCE for that domain.
2. If a PCE receives a VPST and finds its own domain already in the
   path it can exclude the received VPST.

Although the first of these looks cleaner, the second works better in cases 
where one (neighbor) PCE may act for multiple domains.

I think we need to explore this a little.

> Comment #3:  A intermediate PCE could receive VPSTs from
> different domains. What should it do then? Complete all the VPST
> it receives and send them? Send just the first? And in case the PCE
> send multiple VSPTS (each would be a different sequence of
> domains), then the ingress PCE should receive all of them before
> selecting the optimum path. In such case, the timer mechanism
> could fit....

Yes. I think you are exposing some of the big issues with using BRPC in this 
way. The more "meshy" the network of domains, the harder it is to run this 
process. Comments 2 and 3 show up problems of impracticallity.

A timer could certainly be used to address this issue. Each PCE, in turn, 
would run such a timer meaning that the PCEs that have more PCEs down stream 
need to run longer timers. This gets quite messy because a PCE might have 
two domain paths to the egress domain. If one path has a small number of 
domains, the PCE will receive the VPST a long time before it receives the 
second. How does it know how long to wait?

We should try to add some discussion of this, but I note that we are not (in 
section 3.1) trying to show that BRPC can be used in any arbitrary domain 
mesh when the domain path is not known. In fact, we are trying to explain 
why it may be very inappropriate.

> - "The ingress PCE sends the path computation request direct to the PCE
>    responsible for the domain containing the destination node (the egress
>    PCE)".
>   Comment #4: Do you assume that the PCEs knows how to reach all the
>   other PCEs? I assume that, at least a PCE must know how to reach its
>    neighboring PCEs. If the PCE only knows that information, the request
>    should be flooded until it reaches the egress PCE.

When you say "know how to reach" I presume you mean "know the identity and 
address of".

And, yes, this is exactly one of the problems. In small domain meshes, this 
is not unreasonable, but some mechnism (config or flooding) would be needed. 
In large domain meshes, this would be less reasonable.

You highlight yet another reason why BRPC would not be so appropriate.

It is clear to me that we need to expand on the final paragraph of 3.1 that 
currently says:

   Clearly this mechanism (which could be called path computation
   flooding) has significant scaling issues. It could be improved by
   the application of policy and filtering, but such mechanisms are not
   simple and would still leave scaling concerns.

It seems to me that we should also add a section on "Forward Recursive Path 
Computation" in this case. This form of "flooding" VPSTs helps "discover" 
the destination domain since each PCE only needs to know its neighbors, but 
pruning the VPST during the process is harder, so there is more overhead.

Anyway, as I say, the purpose of section 3 is to highlight that BRPC is not 
a viable solution in the case where the domain path is unknown and the 
domains are arranged in a mesh.

Cheers,
Adrian