Hi Dimitri, Please see inline
> -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de dimitri > papadimitriou > Envoyé : vendredi 11 novembre 2005 20:35 > À : [EMAIL PROTECTED] > 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 protected] > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
