Subject: [Pce] Providing optimization metrics in addition to a computed path in PCE responses

From: "Andrew Dolganow" <[email-masked]>
Date: Thu, 4 Aug 2005 05:16:49 -0400

Hi,
 
It would be highly desirable if a response to a PCE Request contained not
only a computed path but also metrics that can be used in a selection of the
most optimal path by either a PCE or PCC issuing the original request. For
example a PCC (directly or through a PCE) issuing a request for a multi-hop
PW may need to go to two independent PCEs to find a path from two border
S-PEs towards destination. The PCC (PCE) would then take both responses and
compare them with paths to reach each of the S-PEs it can compute. To find
the optimal path, the PCC (PCE) needs info to allow such "optimal" path
selection (like for example costs for the computed paths).
 
I would like to propose that the protocol requirements draft includes a
requirement (section 6 and 6.1.5 of the
draft-ietf-pce-comm-protocol-gen-reqs-01.txt draft) that a Path Computation
Response SHOULD allow return of metrics that can be used by a requesting
entity to optimize a path.
 
Andrew 
_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Thu, 4 Aug 2005 11:43:04 +0200

Hi Andrew,

On Aug 4, 2005, at 11:16 AM, Andrew Dolganow wrote:

> Hi,
>
> It would be highly desirable if a response to a PCE Request  
> contained not only a computed path but also metrics that can be  
> used in a selection of the most optimal path by either a PCE or PCC  
> issuing the original request.

The ability for the PCC to provide objective function which could be  
used by the PCE for path selection is indeed listed as a requirement  
in the generic PCE communication requirement ID.

> For example a PCC (directly or through a PCE) issuing a request for  
> a multi-hop PW may need to go to two independent PCEs to find a  
> path from two border S-PEs towards destination. The PCC (PCE) would  
> then take both responses and compare them with paths to reach each  
> of the S-PEs it can compute. To find the optimal path, the PCC  
> (PCE) needs info to allow such "optimal" path selection (like for  
> example costs for the computed paths).
>

Two comments:
1) Indeed, the PCC may in some cases send the same requests to  
multiple PCEs (this is one of the reasons why in PCEP for example we  
introduced the ability for the PCC to cancel pending requests)
2) Since the objective function will be provided by the PCC, it  
should get comparable path costs. That said, note that this may  
require synchronization between PCEs lying in different domains to  
ensure metric consistency.

> I would like to propose that the protocol requirements draft  
> includes a requirement (section 6 and 6.1.5 of the draft-ietf-pce- 
> comm-protocol-gen-reqs-01.txt draft) that a Path Computation  
> Response SHOULD allow return of metrics that can be used by a  
> requesting entity to optimize a path.

Clearly the PCC request will include the ability to specify the  
objective function. Thus the computed path cost provided by the PCE  
will be well-understood by the PCC. Are you referring to the  
requirement for the PCE to provide the computed path cost ?

Thanks.

JP.

---

From: "Andrew Dolganow" <[email-masked]>
Date: Thu, 4 Aug 2005 06:09:31 -0400

JP,
 
Please see below in bold font:

  _____  

From: JP Vasseur [mailto:[email-masked]] 
Sent: Thursday, August 04, 2005 5:43 AM
To: Andrew Dolganow
Cc: [email-masked]
Subject: Re: [Pce] Providing optimization metrics in addition to a computed
path in PCE responses

Hi Andrew, 

Hi,

It would be highly desirable if a response to a PCE Request contained not
only a computed path but also metrics that can be used in a selection of the
most optimal path by either a PCE or PCC issuing the original request.

The ability for the PCC to provide objective function which could be used by
the PCE for path selection is indeed listed as a requirement in the generic
PCE communication requirement ID.

For example a PCC (directly or through a PCE) issuing a request for a
multi-hop PW may need to go to two independent PCEs to find a path from two
border S-PEs towards destination. The PCC (PCE) would then take both
responses and compare them with paths to reach each of the S-PEs it can
compute. To find the optimal path, the PCC (PCE) needs info to allow such
"optimal" path selection (like for example costs for the computed paths).

Two comments: 
1) Indeed, the PCC may in some cases send the same requests to multiple PCEs
(this is one of the reasons why in PCEP for example we introduced the
ability for the PCC to cancel pending requests)
2) Since the objective function will be provided by the PCC, it should get
comparable path costs. That said, note that this may require synchronization
between PCEs lying in different domains to ensure metric consistency.
 
Alternatively, the requesting PCC (PCE) would now the "mapping" it needs to
apply to both costs, but I agree that metric consistency between PCEs would
be a better solution. 

Clearly the PCC request will include the ability to specify the objective
function. Thus the computed path cost provided by the PCE will be
well-understood by the PCC. Are you referring to the requirement for the PCE
to provide the computed path cost ?

That's exactly what I am looking for. In my example two PCEs building
partial paths need to provide back an optimization metric in their Path
Computation responses to allow the "original" PCC (or a PCE acting for that
PCC to build a complete path) to select the optimal path using one of the
partial paths computed by the two PCEs. Unless Path Computation Response
messages carry back such metrics we won't be able to build an optimal path.
 
Andrew

Thanks.

JP.

Andrew

---

From: JP Vasseur <[email-masked]>
Date: Fri, 5 Aug 2005 11:26:45 +0200

Hi Andrew,

On Aug 4, 2005, at 12:09 PM, Andrew Dolganow wrote:

> Subject: Re: [Pce] Providing optimization metrics in addition to a  
> computed path in PCE responses
>
> Hi Andrew,
>
>> used in a selection of the most optimal path by either a PCE or  
>> PCC issuing the original request.
>
> The ability for the PCC to provide objective function which could  
> be used by the PCE for path selection is indeed listed as a  
> requirement in the generic PCE communication requirement ID.
>
>> For example a PCC (directly or through a PCE) issuing a request  
>> for a multi-hop PW may need to go to two independent PCEs to find  
>> a path from two border S-PEs towards destination. The PCC (PCE)  
>> would then take both responses and compare them with paths to  
>> reach each of the S-PEs it can compute. To find the optimal path,  
>> the PCC (PCE) needs info to allow such "optimal" path selection  
>> (like for example costs for the computed paths).
>
> Two comments:
> multiple PCEs (this is one of the reasons why in PCEP for example  
> we introduced the ability for the PCC to cancel pending requests)
> Alternatively, the requesting PCC (PCE) would now the "mapping" it  
> needs to apply to both costs, but I agree that metric consistency  
> between PCEs would be a better solution.
> That's exactly what I am looking for. In my example two PCEs  
> building partial paths need to provide back an optimization metric  
> in their Path Computation responses to allow the "original" PCC (or  
> a PCE acting for that PCC to build a complete path) to select the  
> optimal path using one of the partial paths computed by the two  
> PCEs. Unless Path Computation Response messages carry back such  
> metrics we won't be able to build an optimal path.
>

Absolutely. This is actually detailed in draft-vasseur-ccamp-inter- 
domain-path-comp-00.txt (expired), the plan being the resurrect  
scenario-2 at some point (scenario 1 is now draft-ietf-ccamp-inter- 
domain-pd-path-comp). That said, the required object in this case is  
slightly different since the cost from a set of entry boundary LSRs  
to the destination is needed.

What I would suggest you is to produce a short ID specifying such  
object. It is worth having a separate object here (rather than  
defining the object in the PCE communication protocol) since it could  
be used to record cost of inter-domain TE LSP in a non PCE-context.  
Feel free to discuss it in the PCE WG *with* a review from CCAMP.

Thanks.

JP.

---

From: "Andrew Dolganow" <[email-masked]>
Date: Mon, 8 Aug 2005 09:07:25 -0400

JP,
 
Thanks for your explanation. Based on it and the some history you mention, I
agree with you that this may call for a separate ID.
 
Andrew

  _____  

From: JP Vasseur [mailto:[email-masked]] 
Sent: Friday, August 05, 2005 5:27 AM
To: Andrew Dolganow
Cc: [email-masked]
Subject: Re: [Pce] Providing optimization metrics in addition to a computed
path in PCE responses

Hi Andrew, 

JP,

  _____  

Hi Andrew, 

Hi,

Two comments: 

Absolutely. This is actually detailed in
draft-vasseur-ccamp-inter-domain-path-comp-00.txt (expired), the plan being
the resurrect scenario-2 at some point (scenario 1 is now
draft-ietf-ccamp-inter-domain-pd-path-comp). That said, the required object
in this case is slightly different since the cost from a set of entry
boundary LSRs to the destination is needed.

What I would suggest you is to produce a short ID specifying such object. It
is worth having a separate object here (rather than defining the object in
the PCE communication protocol) since it could be used to record cost of
inter-domain TE LSP in a non PCE-context. Feel free to discuss it in the PCE
WG *with* a review from CCAMP.

Thanks.

JP.

Andrew

Thanks.

JP.

Andrew