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

John E Drake <jdrake@juniper.net> Mon, 18 November 2013 21:16 UTC

Return-Path: <jdrake@juniper.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F071AD66B for <ccamp@ietfa.amsl.com>; Mon, 18 Nov 2013 13:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx8L1fHjjpad for <ccamp@ietfa.amsl.com>; Mon, 18 Nov 2013 13:16:32 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 38E9D1ACC87 for <ccamp@ietf.org>; Mon, 18 Nov 2013 13:16:32 -0800 (PST)
Received: from mail44-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.22; Mon, 18 Nov 2013 21:16:26 +0000
Received: from mail44-ch1 (localhost [127.0.0.1]) by mail44-ch1-R.bigfish.com (Postfix) with ESMTP id 1413AE0235; Mon, 18 Nov 2013 21:16:26 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 1
X-BigFish: VPS1(zzc85fhec9Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h9a9j1155h)
Received-SPF: pass (mail44-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(37854004)(199002)(189002)(81342001)(54316002)(66066001)(56776001)(81816001)(74876001)(69226001)(80022001)(74706001)(79102001)(77982001)(59766001)(15975445006)(81686001)(19609705001)(65816001)(85306002)(63696002)(54356001)(4396001)(51856001)(76482001)(31966008)(87266001)(74662001)(15202345003)(83072001)(74502001)(53806001)(74316001)(16236675002)(80976001)(83322001)(74366001)(19580395003)(2656002)(87936001)(50986001)(47976001)(49866001)(33646001)(19300405004)(47736001)(47446002)(81542001)(56816003)(46102001)(76786001)(76796001)(76576001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB564; H:BLUPR05MB562.namprd05.prod.outlook.com; CLIP:66.129.241.16; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail44-ch1 (localhost.localdomain [127.0.0.1]) by mail44-ch1 (MessageSwitch) id 1384809382850441_20346; Mon, 18 Nov 2013 21:16:22 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail44-ch1.bigfish.com (Postfix) with ESMTP id CAE8A2C0053; Mon, 18 Nov 2013 21:16:22 +0000 (UTC)
Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 18 Nov 2013 21:16:22 +0000
Received: from BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.383.1; Mon, 18 Nov 2013 21:16:20 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 18 Nov 2013 21:16:19 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0820.005; Mon, 18 Nov 2013 21:16:19 +0000
From: John E Drake <jdrake@juniper.net>
To: "Zafar Ali (zali)" <zali@cisco.com>, Cyril Margaria <cyril.margaria@gmail.com>
Thread-Topic: [CCAMP] The description of Path Key retaining time in RFC5553
Thread-Index: AQHO2+75nyh5MwjjqEemfNXW9E7a+JobcMqAgAVubRCABNrUAIABC0WAgASPKYCAAAd7gIAADwyAgAAGr+CAAAeTgIAAEBuA
Date: Mon, 18 Nov 2013 21:16:18 +0000
Message-ID: <3fbb2fa2570a4133844cc19611730980@BLUPR05MB562.namprd05.prod.outlook.com>
References: <2c3d43c4da944177b3663320f4fff305@BLUPR05MB562.namprd05.prod.outlook.com> <CEAFDA21.85B26%zali@cisco.com>
In-Reply-To: <CEAFDA21.85B26%zali@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.16]
x-forefront-prvs: 00342DD5BC
Content-Type: multipart/alternative; boundary="_000_3fbb2fa2570a4133844cc19611730980BLUPR05MB562namprd05pro_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
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.15
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 21:16:34 -0000

If LSP1 is signaled at t1 (using PK1). How would PCC or PCE will know that some other LSP (LSP2) will no longer be requesting diversity from LSP1 (using PK1) at a future time t2? I.e., when PCE can purge PK1? If PK1 is purged before t2, the solution did not address the requirement.

[JD]  Three points.  Operationally, diversely routed LSPs are established concurrently so operationally this is a non-issue.  Since path state can be used for multiple LSPs there is no reason to aggressively purge it.  Your solution requires that every node at the edge of an abstract node has complete knowledge of the RSVP-TE explicit route and identifier of every LSP transiting that abstract node and to this point you have not indicated how this information would be distributed or maintained.

On the other hand, PCE needs to purge Path states to scale.

[JD]  Sever blades currently have on the order of 768GB of system memory and a path is on the order of 1K.