[Pce] Comments on draft-ietf-pce-disco-proto-igp

Zhang Renhai <zhangrenhai@huawei.com> Tue, 13 June 2006 07:37 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq3ST-0002OO-Vg; Tue, 13 Jun 2006 03:37:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq3SS-0002OJ-Fj for pce@ietf.org; Tue, 13 Jun 2006 03:37:04 -0400
Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq3SP-0001jM-UX for pce@ietf.org; Tue, 13 Jun 2006 03:37:04 -0400
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0S00BH4FUQ6C@szxga01-in.huawei.com> for pce@ietf.org; Tue, 13 Jun 2006 15:37:38 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0S008T6FUPC3@szxga01-in.huawei.com> for pce@ietf.org; Tue, 13 Jun 2006 15:37:37 +0800 (CST)
Received: from z18605 ([10.110.115.154]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0S00IKAG9W9M@szxml04-in.huawei.com> for pce@ietf.org; Tue, 13 Jun 2006 15:46:44 +0800 (CST)
Date: Tue, 13 Jun 2006 15:06:36 +0800
From: Zhang Renhai <zhangrenhai@huawei.com>
To: pce@ietf.org
Message-id: <014c01c68eb7$e9805960$9a736e0a@huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc:
Subject: [Pce] Comments on draft-ietf-pce-disco-proto-igp
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>
Content-Type: multipart/mixed; boundary="===============1701811098=="
Errors-To: pce-bounces@lists.ietf.org

Hi, all

I recently read the draft draft-ietf-pce-disco-proto-igp again, here are some comments。

When IGP is used as a PCED protocol, the capabilities of pce will be advertised periodicly along with other lsa/lsp information. In my opinion, unless the PCE's capabilities change,  there is no need for the PCC to receive and handle the information again. Furthermore, if most of the routers in a domain will always have no request to a PCE, there is also no need for them to maintain the information. 

My concern to PCE-DEST-DOMAINS sub-TLV is that we can't anticipate how many destination domains a PCE can  computate path towards, as a result,the length of space taken by this capality in the message can't be controlled. So I think if the PCC send a request to a PCE which can't compute the path for the reason of the destination domain, the PCE can tell the PCC in the PCrep message the right PCE. One additional quesion: is it suitable for the PCE to have such ability to know exactly the destination domain it can compute towards?

Some functions specified in the PATH-CAMP-CAP sub-TLV are also defined in the PCEP,  a clear division should be made. 

Cheers,

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