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

"Zafar Ali (zali)" <zali@cisco.com> Mon, 18 November 2013 17:52 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 47BD111E8274 for <ccamp@ietfa.amsl.com>; Mon, 18 Nov 2013 09:52:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.134
X-Spam-Level:
X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cfvr4SrVe9dH for <ccamp@ietfa.amsl.com>; Mon, 18 Nov 2013 09:52:35 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 26C4C21F9A05 for <ccamp@ietf.org>; Mon, 18 Nov 2013 09:47:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12031; q=dns/txt; s=iport; t=1384796843; x=1386006443; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=uE84+kuc8YknIRDKZhYNDBvey8Hgw/7GPaD5tO/xIJg=; b=QcGOcE0gzD+aIY/qRigBJxJtmJDxoThyeFCFOrT0bz5zqhgAuSdYHutb PeyYG4vTjfwTMOfRw3uep6sqZZpzcG0FINibHXU6BuPrclsOuL9NEU/a6 FtD01DZKJ7VanuU0dYZgd9tvYnKaSwYqM0PH2lIbyUa0K7D3lOY79J7Z2 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwFADFSilKtJXG9/2dsb2JhbABZgkNEOFO/NYEdFnSCJQEBAQQBAQFrBAcMBgEIEQMBAigoBgsUCQgCBA4FGQKHVAMPDbh9DYk5EwSMc4EqEQGBKQ0EBwaEKwOWJYFrjFWFOIMogXE5
X-IronPort-AV: E=Sophos; i="4.93,725,1378857600"; d="scan'208,217"; a="285838261"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 18 Nov 2013 17:46:57 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAIHkuiB021175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 17:46:56 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 18 Nov 2013 11:46:56 -0600
From: "Zafar Ali (zali)" <zali@cisco.com>
To: Cyril Margaria <cyril.margaria@gmail.com>
Thread-Topic: [CCAMP] The description of Path Key retaining time in RFC5553
Thread-Index: AQHO2+75nyh5MwjjqEemfNXW9E7a+JobcMqAgAVubRCABNrUAIABb9qAgAQ7fwA=
Date: Mon, 18 Nov 2013 17:46:55 +0000
Message-ID: <CEABEE0B.8487B%zali@cisco.com>
In-Reply-To: <CADOd8-swb-0ZRzUEWZMXuVQ-HPuo9Qv0wrqe_dEQ_nHgh8md0A@mail.gmail.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.215.66]
Content-Type: multipart/alternative; boundary="_000_CEABEE0B8487Bzaliciscocom_"
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: Mon, 18 Nov 2013 17:52:40 -0000

Cyrill-

Please see in-line.

Thanks

Regards … Zafar

From: Cyril Margaria <cyril.margaria@gmail.com<mailto:cyril.margaria@gmail.com>>
Date: Friday, November 15, 2013 3:09 PM
To: zali <zali@cisco.com<mailto:zali@cisco.com>>
Cc: Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>, "Zhangxian (Xian)" <zhang.xian@huawei.com<mailto:zhang.xian@huawei.com>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: Re: [CCAMP] The description of Path Key retaining time in RFC5553

Hi,
please see inline for comments.


On 15 November 2013 04:12, Zafar Ali (zali) <zali@cisco.com<mailto:zali@cisco.com>> wrote:

-----Original Message-----
From: Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>
Date: Monday, November 11, 2013 9:09 PM
To: zali <zali@cisco.com<mailto:zali@cisco.com>>, "Zhangxian (Xian)" <zhang.xian@huawei.com<mailto:zhang.xian@huawei.com>>
Cc: "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto: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.

I do not recall that each LSP needs a path key, each path does, but not each LSP.
So the scalability is not related to amount of LSPs, but the amount of path use, which scale quite differently than the number of LSPs.

I just responded to the same confusion in the other email – sorry for the duplicate.

  *
How would PCC or PCE know ahead of time which LSP will be used for
diversity by another LSP in a future time? E.g., if you are signaling LSP1
at t1. How would PCC or PCE will know that some other LSP (LSP2) will be
requesting diversity from LSP1 at a future time t2.


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

That is correct, the PCE need to keep a state on the path used, but using the term statefull in that case is confusing and misleading, as its tied to a full LSP DB. TED itself is a state too.

Yes, we need a new term for such stateful PCEs. Let's call it "path-stateful" PCE.


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

as stated before, you would support a maximum of 64k Paths, given the diversity constraint you want to support.
In any case the scaling of the solution is to be considered, but is there other problem with that solution?
This solution is attractive as it provides a complete solution ( deploy a PCE colocated with the LSR, only resolving  PKS, the rest is already defined).

If we are using "path-stateful" PCE, why not use "stateful" PCE.



Regards,
Cyril.

Thanks

Regards...Zafar

>

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org<mailto:CCAMP@ietf.org>
https://www.ietf.org/mailman/listinfo/ccamp