Hi, Jean-Philippe See inline.
----- Original Message ----- From: "JP Vasseur" <[EMAIL PROTECTED]> To: "zhangrenhai 18605" <[EMAIL PROTECTED]> Cc: "LE ROUX Jean-Louis RD-CORE-LAN" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, January 13, 2006 9:52 PM Subject: Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt > Hi, > > On Jan 12, 2006, at 10:40 PM, zhangrenhai 18605 wrote: > > > Hi, JP > > > > Sorry for seeing your reply so late. > > Thanks, see inline. > > > > ----- Original Message ----- > > From: JP Vasseur <[EMAIL PROTECTED]> > > Date: Thursday, January 5, 2006 3:07 am > > Subject: Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea- > > reqs-00.txt > > > >> Hi , > >> > >> On Dec 28, 2005, at 2:03 AM, Zhang Renhai wrote: > >> > >>> Hi, Jean-Louis > >>> > >>> I have some comment on the draft draft-ietf-pce-pcecp-interarea- > >> > >>> reqs-00.txt > >>> > >>> In section 7.11.1, In case of network failure, jittering will > >> be > >>> used to avoid > >>> simultaneous requests sent to one PCE. Could more consideration > >> be > >>> given here to > >>> the preemptment, becouse the jittering timeout is stochastic, > >> some > >>> lower request > >>> may be served before a higher request and the path may be > >>> calculated differently. > >>> which may increase the probability of a preemptment. > >>> > >> > >> The decision on the PCC request scheduling is out of the scope of > >> this ID. Note that the point that you mentioned also applies to > >> the > >> located-PCE case. > > I am not sure what scope this point belongs to. I just considered > > more about what > > has been mentioned in the draft. > > Is this consideration important anough to be added somewhere? > > You're very welcome to discuss the topic on the list [ZRH](Can I cut your words so?) Thanks ! but PCC request > request scheduling are not standardized. > > >> > >>> > >>> I have always been thinking a question: if a PCC will not > >> perform > >>> the CSPF > >>> computation, why does it still maintain the TEDB any longer? > >> which > >>> may consume > >>> a lot of memory and CPU of a LSR.This question dost not aid at > >> this > >>> draft. > >>> > >> > >> Because > >> (1) The PCE may decide to use a remote PCE for some LSPs and not > >> for > >> others (for instance, inter versus intra-domain) > >> (2) The PCE may decide to always use a PCE and fall back to local > >> path computation or loose hop routing under specific conditions > > Agree, I just want to be convinced if some routers acting as a pure > > PCC > > (no longer perform path computation)can save some CPU and memory so > > there could be a lower requirement on capability to these routers > > in PCE-based environment.Maybe this is a benefit to PCE Architecture. > > Sure, this is an option already described in the draft. > > >> > >>> In inter-area environment,sometimes, a PCC may wish to get as > >> many > >>> paths as possible, > >>> for all kinds of purpose,so could the PCC send the request to > >> more > >>> than one PCEs? > >>> > >> > >> Yes, although this would clearly be very sub-optimal .... > > I am not sure your point, could you please expand your explanation > > any more? > > In my opinion, a ABR acting as a PCE usually can not have a full AS- > > scope information of TED. > > so it may return a sub-optimal compuation result compared to some > > latent path which can be returned by other ABR linked to a different > > area. I know this can be solved by a ABR through sending the > > request to multiple > > ABR in a area, otherwise, how to solve this problem? > > Yes stay tuned ... I'll resurrect soon a draft that used to be > discussed in CCAMP detailing these aspects. [ZRH]If possible, I can join you. > > Thanks. > > JP. > > > > > > > Thanks, > > Zhang > > > >> > >> JP. > >> > >>> Regards, > >>> Zhang > >>> _______________________________________________ > >>> Pce mailing list > >>> [email protected] > >>> https://www1.ietf.org/mailman/listinfo/pce > >> > >> _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
