Hi Dimitri, Please find inlined answers,
> -----Message d'origine----- > De : dimitri papadimitriou [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 17 novembre 2005 19:47 > À : LE ROUX Jean-Louis RD-CORE-LAN > Cc : [EMAIL PROTECTED]; [EMAIL PROTECTED] > Objet : Re: [Pce] multiple PCE path computation > > hi jean-louis, > > LE ROUX Jean-Louis RD-CORE-LAN wrote: > > 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?? > > 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 These are interesting points but related to PCE selection, and actually out of the scope of the PCECP... Here I was asking for PCECP requirements... >- 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 ? More generally some PCE applications will require RSVP-TE extensions. Here you give a potential example. Another example, could be the support of path confidentiality in an inter-provider context. In this case the computed path may, for instance, comprise of cookies identifying the computed intra-provider path segments along with the IDs of the corresponding PCEs. This would require RSVP-TE extensions to carry these PCE ids and path cookies within the ERO, and this would also address your point by the way. Where should these extensions be worked out in an other issue, and I will let the chairs answer. Actually the answser seems to be in the PCE charter: "- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models." Thanks for this discussion. Best Regards, JL > > > 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 protected] https://www1.ietf.org/mailman/listinfo/pce > >> > > > > > > . > > > _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
