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

From: Oscar González de Dios <[email-masked]>
Date: Fri, 04 Jun 2010 12:57:31 +0200

Hi Adrian,

Lots of thanks for the very complete response. Further comments inline. At the end, I continue with more sections of the document.

>-----Mensaje original-----
>De: Adrian Farrel [mailto:[email-masked]]
>Enviado el: jueves, 27 de mayo de 2010 13:42
>Para: Oscar González de Dios
>CC: [email-masked]
>Asunto: Re: [Pce] question about draft-king-pce-hierarchy-fwk-03
>
>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.
OK! 
Then note that the same cases apply to the hierarchical PCE approach in section 4, so they should be added there equally.  
"When a multi-domain path is needed, the ingress PCE sends a request to the parent PCE (using the path computation element protocol)"
Comment#1: If the child PCE cannot find a path to the egress and returns and error (or it does not respond and the timeout pops)... then, the parent PCE should try again with a different sequence of domains? Or should it just leave it open, and let the implementation of the parent PCE decide what to do, if either return a error to the PCC that initiated the request or try again.
Comment#2 The child PCE of some domain could not respond (maybe it's down, or overflowed, or whatever). This leads to a question... RFC4655 in section 6.5.  refers to Detecting PCE Liveness. Must it be stated that PCE child to PCE parent communications should implement mechanisms to detect the PCE liveleness as stated in RFC 4655?

>
>> - "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.
>
OK!
>> 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?
>
Good question....

>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.
>
True... Comment#3 The Hierarchical PCE is a better approach (although you need another PCE to rule them all). In case of multiple domains belonging to the same operator (I am thinking in a GMPLS network subdivided in several administrative domains with different vendors, or the different domains of its MPLS network), the Hierarchical PCE approach makes sense. However, for bigger number of domains... But as you say in the draft, the aim is at solving the problem in reasonable sized number of domains.

>> - "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".
YES
>
>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.
>
OK!
>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

Finally a few comments about the relation with ASON. In chapter 6.2, you talk about the ASON Architecture. You mention that the Routing Controller is synonymous with a PCE. In 6.2.1 you mention that PCE can be seen as a realization of a RC. So.... just to clarify, you mean the second, that if you want to implement a RC, use the Hierarchical PCE and its associated protocols (PCEP)? 
Regarding this relation with ASON, the OIF standardized in 2007 the OIF-ENNI-OSPF-01.0 interface. So, in analogy to the RC-PCE, can it be mentioned that some sort of OSPF extension will be a realization of the E-NNI 1.0 and can be used to fill in the TEDs that the Hierarchical PCE would use? 
You mention something in the draft about how to fill in the TEDs (in section 5.4 there is something),but I guess this is far from the scope of the document... 

Best Regards,

	Óscar

---

From: "Daniel King" <[email-masked]>
Date: Mon, 7 Jun 2010 13:48:01 +0100

Hi Oscar, 

Thanks for review and comments. I have provided some additional thoughts
in-line. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Oscar
González de Dios
Sent: 04 June 2010 11:58
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [Pce] question about draft-king-pce-hierarchy-fwk-03

Hi Adrian,

Lots of thanks for the very complete response. Further comments inline. At
the end, I continue with more sections of the document.

>We should add a sentnce to cover this.

DK>> Indeed. I have prepared two new scenarios and text to cover these cases
in the next version of our draft. 

OK! 
Then note that the same cases apply to the hierarchical PCE approach in
section 4, so they should be added there equally.  
"When a multi-domain path is needed, the ingress PCE sends a request to the
parent PCE (using the path computation element protocol)"
Comment#1: If the child PCE cannot find a path to the egress and returns and
error (or it does not respond and the timeout pops)... then, the parent PCE
should try again with a different sequence of domains? Or should it just
leave it open, and let the implementation of the parent PCE decide what to
do, if either return a error to the PCC that initiated the request or try
again.

DK>> It's possible that multiple child PCE's exist within a domain so the
parent PCE could:

1. Send a request to the child PCE 1 in (Domain 1) and then if no route is
found by that PCE or no response is received for a path1, then the Parent
PCE can send the same path request to another PCE say child PCE2 (Domain 1).
Bear in mind that the second request would be based on the error type
received back from PCE1, if PCE1 says there is no path available (versus I
cannot find a path) then the parent PCE should not send a second request,
but should send a request to a child PCE in a different transit domain. 

2. Send two requests to simultaneously to PCE1 and PCE2 in (Domain 1). 
 
Actually these type of scenarios and specific procedures could be covered in
our draft. 

Comment#2 The child PCE of some domain could not respond (maybe it's down,
or overflowed, or whatever). This leads to a question... RFC4655 in section
6.5.  refers to Detecting PCE Liveness. Must it be stated that PCE child to
PCE parent communications should implement mechanisms to detect the PCE
liveleness as stated in RFC 4655?

DK>> Again, we could use a mechanism that polls another child pce or chooses
a new transit domain. I do think we need to expand on Liveness Detection and
Monitoring, as well as Verifying Correct Operation in more detail on our
draft.

OK!
Good question....

>why it may be very inappropriate.
True... Comment#3 The Hierarchical PCE is a better approach (although you
need another PCE to rule them all). In case of multiple domains belonging to
the same operator (I am thinking in a GMPLS network subdivided in several
administrative domains with different vendors, or the different domains of
its MPLS network), the Hierarchical PCE approach makes sense. However, for
bigger number of domains... But as you say in the draft, the aim is at
solving the problem in reasonable sized number of domains.

DK>> Indeed. The current charter specifically prohibits expending effort on
"large" groups of domains. The definition of "large" is open to
interpretation, and various discussions on this list have occurred over the
years on this specific topic. Applicability of H-PCE and the number of
domains it services may also depend on the size of the domains. In the
optical world, a single ring of a specific technology type or vendor, may be
a domain in itself. 

YES
>   simple and would still leave scaling concerns.

DK>> Indeed. We have tried to avoid mechanisms that use flooding techniques.

OK!

DK>> Ah FRPC, indeed other techniques may also be applied including Dual
Recursive Path Computation. With DRPC the H-PCE could send out multiple
requests in either direction across the multi-domain topology and stitch
together responses and prune where necessary. Although you need to consider
where the middle is, rather hard in a cloud :-) 

>domains are arranged in a mesh.

Finally a few comments about the relation with ASON. In chapter 6.2, you
talk about the ASON Architecture. You mention that the Routing Controller is
synonymous with a PCE. In 6.2.1 you mention that PCE can be seen as a
realization of a RC. So.... just to clarify, you mean the second, that if
you want to implement a RC, use the Hierarchical PCE and its associated
protocols (PCEP)? 

DK>> Yes. [G-8080] describes that the Routing Controller Component is an
abstract entity (in our case a PCE), which is responsible for responding to
requests for path (route) information and topology information. [G-7715-2]
describes the Route Query Requester as an RC that sends a route query
message to one or more RCs to compute paths that satisfies a set of routing
constraints. In this context the Parent PCE (Parent RC) and Child PCEs
(Child RCs) could communicate using PCEP and this would translate to route
query (RI_QUERY / PCEP Request) and route query response (RI_UPDATE / PCEP
Response) messages as per [G-7715-2]. 

Regarding this relation with ASON, the OIF standardized in 2007 the
OIF-ENNI-OSPF-01.0 interface. So, in analogy to the RC-PCE, can it be
mentioned that some sort of OSPF extension will be a realization of the
E-NNI 1.0 and can be used to fill in the TEDs that the Hierarchical PCE
would use?

You mention something in the draft about how to fill in the TEDs (in section
5.4 there is something),but I guess this is far from the scope of the
document... 

DK>> Very true, the TED could be comprised of information retrieved from an
NMS system or as you mentioned OSPF-TE, or indeed something else entirely
and various work has already been started in this area (see
draft-lee-pce-ted-alternatives). Also bear in mind that to maintain
confidentiality and scaling we may not want to provide the Parent RC the
full Child RC database.  

Best Regards,

	Óscar

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce