Subject: RE: [Pce] multiple PCE path computation

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Tue, 15 Nov 2005 19:31:30 +0100

Hi Dimitri,

Please see inline

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de dimitri 
> papadimitriou
> Envoyé : vendredi 11 novembre 2005 20:35
> À : [email-masked]
> Objet : [Pce] multiple PCE path computation
> 
> all -
> 
> during the discussion on "PCECP Specific Requirements for 
> Inter-Area Path Computation" i raised the issue that this 
> document addresses the case where the path computation is 
> completely decoupled from its signaling

Yes, that is, the path is entirely computed and then signaled.
By the way, note that this does not necessarily mean that the returned path is a strict explicit path. This may be a loose path, and ABRs may still have to perfom ERO expansion (either directly or using the services of an external PCE), but this may be a useless mode in this inter-area context, where confidentiality is not a problem...

> 
> however, there is a case - also described in Section 5.3 of 
> the PCE architecture document - where multiple PCE path 
> computations may be performed along the path during LSP 
> establishment (we could refer to this case as path coupled 
> computation)

Yes, note that this is also discussed in section 5 of this draft:

"Note that the per-area path computation mode relying on route 
   expansion performed directly by ABRs on the path (which function has 
   composite PCEs) , or on external PCEs contacted by the ABRs on the 
   path, consists in fact of a simple concatenation of intra area paths. 
   It actually only implies intra-area path computations and does not 
   allow computing inter-area optimal paths. Hence this mode is not 
   discussed in this document. "

> 
> hence, the questions are
> 
> o) do we need to address this case (imho: yes)

Yes this should be address, but, as explained in the draft in this case PCEs perform intra-area path computation, so this is not strictly speaking an inter-area path computation application...

> 
> o) do we need a separate document to address this case (the 
> question is probably yes concerning the specific RSVP-TE 
> processing during path establishment but is there a need to 
> describe corresponding requirements in a dedicated document 
> or could we make use of the "generic" document suggested by 
> Jean-Louis) ?

To me this is an intra-area path computation issue, and this should not be covered in this ID.

By the way do you see, with this application, any specific requirement for the PCECP, not already covered in the generic ID??

Also note that RSVP-TE procedures for such coupled computation are described in draft-ietf-ccamp-inter-domain-pd-path-comp...

Regards,

JL

> 
> opinions appreciated.
> 
> thanks,
> - dimitri.
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
> 

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 17 Nov 2005 19:46:30 +0100

hi jean-louis,

LE ROUX Jean-Louis RD-CORE-LAN wrote:
> Hi Dimitri,
> 
> Please see inline
> 
> 
>> -----Message d'origine----- De : [email-masked] 
>> papadimitriou Envoyé : vendredi 11 novembre 2005 20:35 À :
>> [email-masked] Objet : [Pce] multiple PCE path computation
>> 
>> all -
>> 
>> Inter-Area Path Computation" i raised the issue that this document
>> addresses the case where the path computation is completely
>> decoupled from its signaling
>  
> Yes, that is, the path is entirely computed and then signaled. By the
> way, note that this does not necessarily mean that the returned path
> is a strict explicit path. This may be a loose path, and ABRs may
> still have to perfom ERO expansion (either directly or using the
> services of an external PCE), but this may be a useless mode in this
> inter-area context, where confidentiality is not a problem...
> 
>> however, there is a case - also described in Section 5.3 of the PCE
>> architecture document - where multiple PCE path computations may be
>> performed along the path during LSP establishment (we could refer
>> to this case as path coupled computation)
> 
> Yes this should be address, but, as explained in the draft in this
> case PCEs perform intra-area path computation, so this is not
> strictly speaking an inter-area path computation application...
> 
>> question is probably yes concerning the specific RSVP-TE processing
>> during path establishment but is there a need to describe
>> corresponding requirements in a dedicated document or could we make
>> use of the "generic" document suggested by Jean-Louis) ?
> 
> By the way do you see, with this application, any specific
> requirement for the PCECP, not already covered in the generic ID??

the specific requirement in this case would be the PCE selection along 
the signaled path, by default the PCE is driven by the local policy 
(that by default may perform selection of the local computation engine) 
and optionally the ERO may include a subobject indicating which PCE may 
be contacted for further expanding the path - the reason for this is 
that the ingress may be in a position to perform such selection from the 
initial request rather than leaving the intermediate LSR performing this 
selection

but as i read your e-mail it is "yes, but not in this document" hence 
the question remains shall we bring this back to CCAMP to complete the 
RSVP extensions ?

> Also note that RSVP-TE procedures for such coupled computation are
> described in draft-ietf-ccamp-inter-domain-pd-path-comp...

i sent an e-mail to the list concerning this document last october and i 
would like to see what the revision will look like before further 
stating this document is the right place for documenting the above

thanks,
- dimitri.

> Regards,
> 
> JL
> 
> 
>> opinions appreciated.
>> 
>> thanks, - dimitri.
>> 
>> _______________________________________________ Pce mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/pce
>> 
> 
> 
> .
>