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

dimitri papadimitriou <dpapadimitriou@psg.com> Mon, 13 February 2006 18:41 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 1F8idG-0005tP-O3; Mon, 13 Feb 2006 13:41:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8idD-0005p4-Kd for pce@megatron.ietf.org; Mon, 13 Feb 2006 13:41:03 -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 NAA14001 for <pce@ietf.org>; Mon, 13 Feb 2006 13:39:17 -0500 (EST)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8iqr-0001mO-NG for pce@ietf.org; Mon, 13 Feb 2006 13:55:11 -0500
Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <dpapadimitriou@psg.com>) id 1F8id8-000ONS-4c; Mon, 13 Feb 2006 18:40:58 +0000
Message-ID: <43F0D2BD.6080604@psg.com>
Date: Mon, 13 Feb 2006 19:41:01 +0100
From: dimitri papadimitriou <dpapadimitriou@psg.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@francetelecom.com>
Subject: Re: [Pce] comments on draft-ietf-pce-pcecp-interarea-reqs-00.txt
References: <D109C8C97C15294495117745780657AE043852EA@ftrdmel1.rd.francetelecom.fr>
In-Reply-To: <D109C8C97C15294495117745780657AE043852EA@ftrdmel1.rd.francetelecom.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA14001
Cc: pce@ietf.org
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be
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 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

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

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

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