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

John E Drake <jdrake@juniper.net> Mon, 18 November 2013 18:39 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 53B8F1A1F4B for <ccamp@ietfa.amsl.com>; Mon, 18 Nov 2013 10:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 6FFVUkduhwTv for <ccamp@ietfa.amsl.com>; Mon, 18 Nov 2013 10:39:32 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id D5CDE1A1F48 for <ccamp@ietf.org>; Mon, 18 Nov 2013 10:39:31 -0800 (PST)
Received: from mail169-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.22; Mon, 18 Nov 2013 18:24:24 +0000
Received: from mail169-ch1 (localhost [127.0.0.1]) by mail169-ch1-R.bigfish.com (Postfix) with ESMTP id 265FE160128; Mon, 18 Nov 2013 18:24:24 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 2
X-BigFish: VPS2(zzc85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h9a9j1155h)
Received-SPF: pass (mail169-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=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(76576001)(74706001)(83322001)(4396001)(49866001)(47976001)(46102001)(83072001)(19580395003)(33646001)(76786001)(76796001)(80022001)(56816003)(63696002)(50986001)(85306002)(47736001)(87936001)(56776001)(54316002)(51856001)(66066001)(74316001)(54356001)(87266001)(53806001)(79102001)(19300405004)(74876001)(74662001)(74502001)(47446002)(77982001)(59766001)(81542001)(31966008)(81342001)(2656002)(80976001)(19609705001)(65816001)(74366001)(69226001)(15975445006)(15202345003)(81686001)(16236675002)(81816001)(76482001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; CLIP:66.129.241.16; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail169-ch1 (localhost.localdomain [127.0.0.1]) by mail169-ch1 (MessageSwitch) id 1384799061651414_25340; Mon, 18 Nov 2013 18:24:21 +0000 (UTC)
Received: from CH1EHSMHS040.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail169-ch1.bigfish.com (Postfix) with ESMTP id 8FD4F2A004F; Mon, 18 Nov 2013 18:24:21 +0000 (UTC)
Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 18 Nov 2013 18:24:21 +0000
Received: from BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.383.1; Mon, 18 Nov 2013 18:24:20 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 18 Nov 2013 18:24: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 18:24:18 +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+JobcMqAgAVubRCABNrUAIABC0WAgASPKYCAAAd7gA==
Date: Mon, 18 Nov 2013 18:24:18 +0000
Message-ID: <e0bc4ce42e4143049e79715a956b5b8b@BLUPR05MB562.namprd05.prod.outlook.com>
References: <CADOd8-swb-0ZRzUEWZMXuVQ-HPuo9Qv0wrqe_dEQ_nHgh8md0A@mail.gmail.com> <CEABEE0B.8487B%zali@cisco.com>
In-Reply-To: <CEABEE0B.8487B%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_e0bc4ce42e4143049e79715a956b5b8bBLUPR05MB562namprd05pro_"
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 18:39:34 -0000

Snipped, comment inline

Yours Irrespectively,

John


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.
[JD]   A PCE would return a path key to the initiator of LSP 1.  When LSP2 is signaled, it would include that path key along w/ an indication of whether LSP2 is to be disjointly or congruently routed wrt that path key.  Btw, as has been noted, if one is truly interested in disjoint routing, one should request LSP1 and LSP2 together so that Suurballe can be used.
Perhaps the WG should be developing the signaling to support this.
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.

[JD]  Because it is an already defined term w/ a completely different meaning?