RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Chris Bowers <cbowers@juniper.net> Fri, 21 March 2014 16:20 UTC

Return-Path: <cbowers@juniper.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2D81A08CD for <rtgwg@ietfa.amsl.com>; Fri, 21 Mar 2014 09:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 a3zuuVOHiEam for <rtgwg@ietfa.amsl.com>; Fri, 21 Mar 2014 09:20:48 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 928551A047B for <rtgwg@ietf.org>; Fri, 21 Mar 2014 09:20:46 -0700 (PDT)
Received: from mail105-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.22; Fri, 21 Mar 2014 16:20:13 +0000
Received: from mail105-tx2 (localhost [127.0.0.1]) by mail105-tx2-R.bigfish.com (Postfix) with ESMTP id 2F10CC00E7; Fri, 21 Mar 2014 16:20:13 +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: -23
X-BigFish: VPS-23(zz9371Ic85fhec9Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzc2hz8275ch1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068h5eeeKz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh9a9j1155h)
Received-SPF: pass (mail105-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=cbowers@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(377454003)(37854004)(243025003)(19609705001)(49866001)(80976001)(87266001)(47736001)(4396001)(81686001)(76482001)(93136001)(47976001)(15975445006)(81816001)(87936001)(54356001)(50986001)(53806001)(80022001)(19300405004)(2656002)(46102001)(92566001)(77982001)(54316002)(83072002)(20776003)(51856001)(65816001)(85306002)(63696002)(31966008)(76786001)(33646001)(85852003)(19580405001)(76796001)(83322001)(76576001)(56776001)(81342001)(93516002)(86362001)(74316001)(94946001)(69226001)(74662001)(74502001)(47446002)(74706001)(81542001)(74876001)(56816005)(59766001)(79102001)(90146001)(66066001)(94316002)(19580395003)(95416001)(74366001)(97186001)(15202345003)(16236675002)(95666003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB516; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:9EFCF185.ABEA91C2.3AD15F8B.4AF9917D.205EF; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail105-tx2 (localhost.localdomain [127.0.0.1]) by mail105-tx2 (MessageSwitch) id 1395418805848015_24071; Fri, 21 Mar 2014 16:20:05 +0000 (UTC)
Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.226]) by mail105-tx2.bigfish.com (Postfix) with ESMTP id C6A7338006B; Fri, 21 Mar 2014 16:20:05 +0000 (UTC)
Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 21 Mar 2014 16:19:47 +0000
Received: from BLUPR05MB516.namprd05.prod.outlook.com (10.141.29.153) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 21 Mar 2014 16:19:46 +0000
Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB516.namprd05.prod.outlook.com (10.141.29.153) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 21 Mar 2014 16:19:44 +0000
Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.00.0898.005; Fri, 21 Mar 2014 16:19:44 +0000
From: Chris Bowers <cbowers@juniper.net>
To: Uma Chunduri <uma.chunduri@ericsson.com>, Pushpasis Sarkar <psarkar@juniper.net>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, Alia Atlas <akatlas@gmail.com>
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection
Thread-Topic: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection
Thread-Index: AQHPP0J+1fYrM2rA6Ui8swo42YsDw5rg72dQgADlVKCAAEjHgIACvj+AgAARM4CAAA+PAIAAmMCAgAAFmgCAAMpngIACbicwgAGGYgCAAVPFwA==
Date: Fri, 21 Mar 2014 16:19:43 +0000
Message-ID: <222907badd1f4b4dac7681c245f89c6a@BLUPR05MB292.namprd05.prod.outlook.com>
References: <CF480575.5095C%aretana@cisco.com> <1B502206DFA0C544B7A60469152008633F1EFEB4@eusaamb105.ericsson.se> <22713_1394872767_532411BF_22713_19413_1_EEE55384044474429A926C625D0FCC810C386E488D@PUEXCB2F.nanterre.francetelecom.fr> <CAG4d1reOwRDDbDCWhr-jMEuAowwzdaUZV9XzLz70fcoNZH6r5w@mail.gmail.com> <1B502206DFA0C544B7A60469152008633F214218@eusaamb105.ericsson.se> <68e5745f7ec24de8ba8936e704336997@BN1PR05MB520.namprd05.prod.outlook.com> <4364_1395046058_5326B6AA_4364_14864_1_EEE55384044474429A926C625D0FCC810C386E497E@PUEXCB2F.nanterre.francetelecom.fr> <1B502206DFA0C544B7A60469152008633F21767B@eusaamb105.ericsson.se> <ae496aa68eb74e21bb1d6c0d4846ad09@BN1PR05MB520.namprd05.prod.outlook.com> <1B502206DFA0C544B7A60469152008633F21BC6A@eusaamb105.ericsson.se> <4c0d4013255642fd8b660216b4c3768c@BLUPR05MB292.namprd05.prod.outlook.com> <1B502206DFA0C544B7A60469152008633F225EEF@eusaamb105.ericsson.se>
In-Reply-To: <1B502206DFA0C544B7A60469152008633F225EEF@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.239.13]
x-forefront-prvs: 0157DEB61B
Content-Type: multipart/alternative; boundary="_000_222907badd1f4b4dac7681c245f89c6aBLUPR05MB292namprd05pro_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/Qg55KTTSJIK1pCs9eMIn9aDpLww
Cc: "draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org" <draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 16:20:53 -0000

Uma
,
Thanks for your responses.
See my responses inline [CB].

Chris

From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
Sent: Thursday, March 20, 2014 1:43 PM
To: Chris Bowers; Pushpasis Sarkar; stephane.litkowski@orange.com; Alia Atlas
Cc: draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org; rtgwg@ietf.org
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Chris,

In-line [Uma]:
--
Uma C.

From: Chris Bowers [mailto:cbowers@juniper.net]
Sent: Wednesday, March 19, 2014 8:07 PM
To: Uma Chunduri; Pushpasis Sarkar; stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>; Alia Atlas
Cc: draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org<mailto:draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Uma,

At the London meeting we presented a sample of results from modeling different PQ-selection heuristics in real network topologies.  They are in slides 7-14 of this link.

http://www.ietf.org/proceedings/89/slides/slides-89-rtgwg-4.pdf

[Uma]:What is Topology-A and Topology-B represent? Are these 2 from the 14 SP topologies?
Else we don't know what are the main characteristics of the topology.
X-axis is not marked in the graph to get an idea of the total number of nodes in each topology; however I see anywhere between 500 - 1100 PQ nodes for
most PLRs (I am sure this is also function of number of  no of links per PLR apart from other factors).

[CB]  You are correct that Topology-A and Topology-B are just 2 out of many topologies analyzed.  I decided to present only two to keep the presentation brief and also to be able to present the coverage seen by each PLR.  The two topologies presented were fairly typical.  The only exception being that they are both fairly large in terms of number of nodes.  Topology A has more 500 nodes and topology B has more than 1000 nodes.  I chose large networks to make the point that if one wants to quickly calculate forward SPFs from PQ-nodes in order to determine the path characteristics from PQ-node to destination, then some heuristic to select a smaller subset of PQ-nodes is needed, because the PQ-condition can still results in hundreds of PQ-nodes.  Other than that, the topologies were not consciously chosen to make any particular point.

The comparison of per-PLR coverage for different heuristics for selecting a subset of PQ-nodes is shown for two topologies on p.11-14.  Not shown in these slides are the results when one considers all possible PQ-nodes, but this was also computed.  The exhaustive PQ-node results show that for some topologies, there is potential to improve coverage with more PQ-nodes or a better choice of PQ-nodes, especially with respect to node-protecting coverage.  However, for these two topologies, even with a simple heuristic for selecting 16 PQ nodes, RLFA offers a significant improvement in coverage compared to local LFA (as shown on p.9-10 ), so some service providers may find it useful.

[Uma]: I also see the coverage varies on PLT to PLR.  Though this result is giving some idea, probably it's still difficult to  conceive default heuristic is indeed is the best bet for all/majority the topologies. On the other hand, if the results are varying for each type of heuristic viz., AVOID_THEN_DIST/ DIST_THEN_AVOID/ RR_ AVOID_THEN_DIST/ SOME _BEST_PROP _XX_HEURISTIC  and we strive for best coverage, then how can we assure you get the same pre-computed PQ node irrespective of the vendor ? And also this predictability seems to be the premise of the standardization of the solution...

[CB]  In my opinion, this draft shouldn't try to standardize a particular PQ-selection heuristic, because there is no way to agree on what "best" coverage or backup path quality means and certainly no way to agree on best heuristic.  The meaning of best heuristic will certainly vary from network to network, and as you point out, it can even vary from PLR to PLR in the same network.  In my opinion, the focus of the draft should be on the use of forward SPF rooted at a PQ-node as the means of determining if the path from PQ-to-dest is node protecting and to collect other path properties.

[CB] When this idea was originally presented to the WG in Berlin, concerns were raised that computing forward SPFs from all PQ-nodes was computationally problematic.  To address that concern, section 2.3.3  was added to the draft.  It requires choosing a subset of PQ-nodes from which to perform forward SPFs.  The modeling results presented in London were intended to illustrate that when one imposes a limit on the subset of PQ-nodes from which to perform forward SPFs and uses a fairly simple heuristic, one can still get quite useful improvements in coverage by augmenting local LFA with RLFA.  It wasn't intended to imply that any particular heuristic should be standardized.  I hope that clarifies our reasons for presenting some results from analyzing PQ-selection heuristics.

As has been pointed out by others, having to deal with the constraint imposed by limiting possible repair tunnels to those that can be created with a single LDP label (extended P-space) is generally going to be problematic.
[Uma]: Though it's problematic, probably this is operationally simple.
Using explicitly routed repair tunnels (created using RSVP or segment routing) or using an alternate topology (as with MRT) may be more productive approaches to improving coverage and backup path quality.
[Uma]: Agree.

Chris