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 - 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 protected] https://www1.ietf.org/mailman/listinfo/pce
.
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
