Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt

zhangrenhai 18605 <zhangrenhai@huawei.com> Fri, 13 January 2006 03:40 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExFnf-0004oK-I7; Thu, 12 Jan 2006 22:40:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExFnc-0004jf-9l for pce@megatron.ietf.org; Thu, 12 Jan 2006 22:40:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25593 for <pce@ietf.org>; Thu, 12 Jan 2006 22:39:02 -0500 (EST)
Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExFuq-0000o8-6i for pce@ietf.org; Thu, 12 Jan 2006 22:47:53 -0500
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IT000IQZI1EM5@usaga01-in.huawei.com> for pce@ietf.org; Thu, 12 Jan 2006 19:36:50 -0800 (PST)
Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IT000M4FI1CBW@usaga01-in.huawei.com> for pce@ietf.org; Thu, 12 Jan 2006 19:36:50 -0800 (PST)
Received: from [172.24.1.3] (Forwarded-For: [10.161.114.61]) by szxmc01-in.huawei.com (mshttpd); Fri, 13 Jan 2006 11:40:01 +0800
Date: Fri, 13 Jan 2006 11:40:01 +0800
From: zhangrenhai 18605 <zhangrenhai@huawei.com>
Subject: Re: [Pce] Comment on draft-ietf-pce-pcecp-interarea-reqs-00.txt
To: JP Vasseur <jvasseur@cisco.com>
Message-id: <11aac111b1bc.11b1bc11aac1@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004)
Content-type: text/plain; charset="us-ascii"
Content-language: en
Content-transfer-encoding: 7bit
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: 7bit
Cc: pce@ietf.org
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=subscribe>
Sender: pce-bounces@lists.ietf.org
Errors-To: pce-bounces@lists.ietf.org

Hi, JP

Sorry for seeing your reply so late.
Thanks, see inline.

----- Original Message -----
From: JP Vasseur <jvasseur@cisco.com>
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?
> 
> >
> >  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.
> 
> >  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?


Thanks,
Zhang

> 
> JP.
> 
> > Regards,
> > Zhang
> > _______________________________________________
> > 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