Re: [CCAMP] The description of Path Key retaining time in RFC5553

"Zhangxian (Xian)" <zhang.xian@huawei.com> Fri, 15 November 2013 03:44 UTC

Return-Path: <zhang.xian@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5820F11E8186 for <ccamp@ietfa.amsl.com>; Thu, 14 Nov 2013 19:44:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.204
X-Spam-Level:
X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[MIME_BASE64_TEXT=2.796, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcP88h1fw+T7 for <ccamp@ietfa.amsl.com>; Thu, 14 Nov 2013 19:44:03 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BE59211E8184 for <ccamp@ietf.org>; Thu, 14 Nov 2013 19:44:00 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXX39538; Fri, 15 Nov 2013 03:43:59 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 03:42:55 +0000
Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 03:43:57 +0000
Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.140]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 11:43:45 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: "Zafar Ali (zali)" <zali@cisco.com>, Fatai Zhang <zhangfatai@huawei.com>
Thread-Topic: The description of Path Key retaining time in RFC5553
Thread-Index: AQHO2+75nyh5MwjjqEemfNXW9E7a+JobcMqAgAVubRCABNrUAP//8xaw
Date: Fri, 15 Nov 2013 03:43:44 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B263E4E61@szxeml510-mbx.china.huawei.com>
References: <F82A4B6D50F9464B8EBA55651F541CF85CA8BDE1@SZXEMA504-MBS.china.huawei.com> <CEA81ADA.8319C%zali@cisco.com>
In-Reply-To: <CEA81ADA.8319C%zali@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.104.209]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] The description of Path Key retaining time in RFC5553
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Nov 2013 03:44:08 -0000

Hi, Zafar,
   
   Thank you for sharing your thought. But I disagree. Why having a 16-bit PK space will constrain the network to have only 64k LSPs? PK is needed only when the LSP is needed to use as a constraint for path diversity. 

   Furthermore, I do not see why storing PKS in PCE for a longer time, even if the lifetime of LSP, will cause any scalability issue. PKS can be used locally by the PCE (stateless) per node basis, i.e. combining PKS + source node address as a way for PCE to solve the issue you mentioned below, which is internal to the PCE. Do you agree? If needed, we can capture this in the manageability section.

Regards,
Xian

-----Original Message-----
From: Zafar Ali (zali) [mailto:zali@cisco.com] 
Sent: 2013年11月15日 11:13
To: Fatai Zhang; Zhangxian (Xian)
Cc: ccamp@ietf.org
Subject: Re: The description of Path Key retaining time in RFC5553


-----Original Message-----
From: Fatai Zhang <zhangfatai@huawei.com>
Date: Monday, November 11, 2013 9:09 PM
To: zali <zali@cisco.com>, "Zhangxian (Xian)" <zhang.xian@huawei.com>
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: The description of Path Key retaining time in RFC5553

>Please don't argue scaliblity issue because you can see even a GMPLS node
>can store lots of informaiton.
>

Fatai- 

I did not get what you are saying. What I was saying is:

* Tunnel-id is 16 bit. I.e., client name space is 16 bit. There can be
more than one LSP per tunnel.
* Path key is 16 bits. I.e., server name space is 16 bits. Each LSP needs
a Path Key. 
* There is 1:N relationship between PCC and PCE (server). PCE sever may
even be centralized.
* You are requiring (Path key, path info) "state" to be stored at the PCE
server for the life time of the connections.
* Path keys have hold-off timer of 30 minutes before they can be reused.

Hence, in your solution, PCE server would run out of Path Keys much before
clients runs out of tunnel name space. In your solution, if you have a
centralized PCE, you can only support 64K connection IN THE NETWORK! I am
not sure why you want to ignore these scaling restrictions.

Thanks

Regards...Zafar 

>