Subject: [Pce] multiple PCE path computation

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 11 Nov 2005 20:35:27 +0100

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

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)

hence, the questions are

o) do we need to address this case (imho: yes)

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) ?

opinions appreciated.

thanks,
- dimitri.

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

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Sun, 20 Nov 2005 21:57:30 +0100

Hi Dimitri,

Please find inlined answers, 

> -----Message d'origine-----
> De : dimitri papadimitriou [mailto:[email-masked]] 
> Envoyé : jeudi 17 novembre 2005 19:47
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [email-masked]; [email-masked]
> 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-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 -
> >> 
> > 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...
> > 
> > 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
> >> 
> > 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-masked] https://www1.ietf.org/mailman/listinfo/pce
> >> 
> > 
> > 
> > .
> > 
>