RE: [Pce] comments on draft-ietf-pce-pcecp-interarea-reqs-00.txt

Hi Dimitri, 

> -----Message d'origine-----
> De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] 
> Envoyé : lundi 13 février 2006 19:41
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : dimitri.papadimitriou@alcatel.be; pce@ietf.org
> Objet : Re: [Pce] comments on 
> draft-ietf-pce-pcecp-interarea-reqs-00.txt
> 
> hi jean-louis
> 
> LE ROUX Jean-Louis RD-CORE-LAN wrote:
> 
> > Hi Dimitri
> > 
> > Please see inline,
> > 
> > 
> >> -----Message d'origine----- De : pce-bounces@lists.ietf.org 
> >> [mailto:pce-bounces@lists.ietf.org] De la part de dimitri 
> >> papadimitriou Envoyé : lundi 13 février 2006 17:11 À : 
> pce@ietf.org  
> >> Objet : [Pce] comments on 
> draft-ietf-pce-pcecp-interarea-reqs-00.txt
> >> 
> >> folks,
> >> 
> >> the document mentions
> >> 
> >> "A solution for computing inter-area TE-LSP path relies on a per 
> >> domain path computation ([PD-COMP]). It is based on loose 
> hop routing 
> >> with an ERO expansion on each ABR. This can allow setting up a 
> >> constrained path, but faces two major limitations: -This does not 
> >> allow computing an optimal constrained path -This may lead 
> to several 
> >> signalling crankback messages and hence delay the LSP setup, and 
> >> invoke routing activities. "
> >> 
> >> optimal computation does not imply resource reservation, 
> hence a PCE 
> >> functionality does not prevent from crankback
> > 
> > Sure, but it drastically reduces crankback probability. 
> Btw, the above 
> > text never say that a PCE prevents from crankback...
> 
> just wanted to avoid confusion in one way or the other, i 
> guess slight rephrasing may help here

OK, this will be done.

> 
> >> section 5 present two models, would it be possible to 
> consider that 
> >> homogeneity is not necessarily verified, e.g. an area 
> having a single 
> >> ABR does not a PCE to reach the local exit point
> > 
> > Could you clarify please?
> 
> the proposed models assume that there are always multiple 
> exit points per area (two) ... hence the question even if 
> there is only ABR hence not much to do in terms of selection 
> the exit point, is the path comp.
> sequence identical ?

I would say yes. Even if there is a single ABR, one may prefer to rely on PCEs to compute the path, rather than ERO expansion. This avoids invoking the signaling when there is no path to the destination (from the single ABR to the destination).
If there is no path from the ABR to the destination, the PCE replies "NO-PATH", and the signaling is not invoked.

> 
> >> section 7.13 should discuss scaling wrt to the TEDB wrt to 
> single PCE 
> >> model it is stated that such consideration is beyond the 
> scope of the 
> >> document i would more than certainly re-consider this since this a 
> >> necessary condition for supporting the "all area" PCE 
> model (is this 
> >> not a single point of failure ? or are specifics in terms of 
> >> resilience outside the scope of this document)
> > 
> > Note that this draft discusses PCECP requirements and hence this 
> > section is dedicated to PCECP scalability. This is why TEDB size is 
> > out of the scope.  By the way, please note that we are 
> going to move 
> > models description (section 5) to an applicability 
> statement draft to 
> > be posted soon.
> 
> does it mean you are going to discuss the scalability issues 
> in the latter document ?

Yes,

Regards

JL

> 
> thanks,
> - dimitri.
> 
> > Thanks
> > 
> > JL
> > 
> > 
> >> thanks, - dimitri.
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________ Pce mailing list 
> >> Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce
> >> 
> > 
> > 
> > .
> > 
> 

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce