IETF Logo Mail Archive

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

"Zafar Ali (zali)" <zali@cisco.com> Fri, 15 November 2013 03:12 UTC

Return-Path: <zali@cisco.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 E384B11E817D for <ccamp@ietfa.amsl.com>; Thu, 14 Nov 2013 19:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8]
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 vzYHmSb7JRhM for <ccamp@ietfa.amsl.com>; Thu, 14 Nov 2013 19:12:35 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3728E11E817F for <ccamp@ietf.org>; Thu, 14 Nov 2013 19:12:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1288; q=dns/txt; s=iport; t=1384485155; x=1385694755; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=X4Xn54iQPalgfjunKwolydHpcxcNp4I00QXTQp0yySM=; b=JQ9cuudBLnsqb5oiIIN16rcgs3ltcEHA0/5kDvwW8PLpBcQ6YQWdrNrs j0zRyL3HrGNM/hhgTUQoIx0envH6z5yJtB78IZn5eHoZmpDgperWYCYFT KD0Ej4nDH2vfh+Uminmt8FUp7JD4FBSwUZV3ZgSv/B5p20zlhOTNPZP3a k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAFOQhVKtJXHA/2dsb2JhbABZgweBC78igSEWdIIlAQEBBDo4BwwGAQgRAwECH0IdCAIEAQ0FGQKHZsEBj18HBoQrA5gQkgyDKIIq
X-IronPort-AV: E=Sophos;i="4.93,704,1378857600"; d="scan'208";a="285087624"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 15 Nov 2013 03:12:34 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAF3CYqg013715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 03:12:34 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 21:12:34 -0600
From: "Zafar Ali (zali)" <zali@cisco.com>
To: Fatai Zhang <zhangfatai@huawei.com>, "Zhangxian (Xian)" <zhang.xian@huawei.com>
Thread-Topic: The description of Path Key retaining time in RFC5553
Thread-Index: AQHO2+75nyh5MwjjqEemfNXW9E7a+JobcMqAgAVubRCABNrUAA==
Date: Fri, 15 Nov 2013 03:12:33 +0000
Message-ID: <CEA81ADA.8319C%zali@cisco.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF85CA8BDE1@SZXEMA504-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.82.237.186]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DE5F8180E875DA4A89BDC73C23AEB895@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:12:41 -0000

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

>

v2.23.0 | Report a Bug | By Email