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

Pushpasis Sarkar <psarkar@juniper.net> Tue, 18 March 2014 17:12 UTC

Return-Path: <psarkar@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 E5C3A1A0451 for <rtgwg@ietfa.amsl.com>; Tue, 18 Mar 2014 10:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.253
X-Spam-Level:
X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 c0dYaRs_jKOX for <rtgwg@ietfa.amsl.com>; Tue, 18 Mar 2014 10:12:11 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id B31011A0425 for <rtgwg@ietf.org>; Tue, 18 Mar 2014 10:11:57 -0700 (PDT)
Received: from mail228-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Mar 2014 17:11:49 +0000
Received: from mail228-va3 (localhost [127.0.0.1]) by mail228-va3-R.bigfish.com (Postfix) with ESMTP id 0C8BFAA01B7; Tue, 18 Mar 2014 17:11:49 +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: -26
X-BigFish: VPS-26(zz9371Ic85fh103dKe0eah1a09J4015I1447Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h2668h9a9j1155h)
Received-SPF: pass (mail228-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=psarkar@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(377454003)(199002)(189002)(51914003)(164054003)(66654002)(97186001)(87266001)(93136001)(81342001)(81542001)(33646001)(76482001)(87936001)(20776003)(31966008)(93516002)(59766001)(97336001)(85306002)(19580395003)(19580405001)(94316002)(79102001)(19300405004)(95416001)(95666003)(92566001)(15202345003)(90146001)(54356001)(74662001)(74316001)(81686001)(74502001)(2656002)(74876001)(53806001)(85852003)(74366001)(47736001)(19609705001)(51856001)(47446002)(50986001)(15975445006)(16236675002)(49866001)(65816001)(80022001)(47976001)(46102001)(94946001)(77982001)(83072002)(4396001)(56776001)(54316002)(66066001)(76796001)(86362001)(80976001)(77096001)(81816001)(83322001)(63696002)(74706001)(69226001)(76786001)(76576001)(56816005)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB517; H:BN1PR05MB520.namprd05.prod.outlook.com; FPR:ECAEF2E7.AFF2D3E2.38D27C7F.CED5FB6C.2060E; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail228-va3 (localhost.localdomain [127.0.0.1]) by mail228-va3 (MessageSwitch) id 139516270542537_14633; Tue, 18 Mar 2014 17:11:45 +0000 (UTC)
Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.241]) by mail228-va3.bigfish.com (Postfix) with ESMTP id ED3A69A0063; Tue, 18 Mar 2014 17:11:44 +0000 (UTC)
Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Mar 2014 17:11:43 +0000
Received: from BN1PR05MB517.namprd05.prod.outlook.com (10.141.65.142) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 18 Mar 2014 17:11:42 +0000
Received: from BN1PR05MB520.namprd05.prod.outlook.com (10.141.65.151) by BN1PR05MB517.namprd05.prod.outlook.com (10.141.65.142) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 18 Mar 2014 17:11:41 +0000
Received: from BN1PR05MB520.namprd05.prod.outlook.com ([169.254.14.240]) by BN1PR05MB520.namprd05.prod.outlook.com ([169.254.14.187]) with mapi id 15.00.0898.005; Tue, 18 Mar 2014 17:11:41 +0000
From: Pushpasis Sarkar <psarkar@juniper.net>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org" <draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org>
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+1fYrM2rA6Ui8swo42YsDw5rm7aHQgAAlqyA=
Date: Tue, 18 Mar 2014 17:11:41 +0000
Message-ID: <758bbd568a014f879ae0db848902ee43@BN1PR05MB520.namprd05.prod.outlook.com>
References: <CF480575.5095C%aretana@cisco.com> <20825_1395160636_5328763C_20825_2806_1_53C29892C857584299CBF5D05346208A07119F80@PEXCVZYM11.corporate.adroot.infra.ftgroup>
In-Reply-To: <20825_1395160636_5328763C_20825_2806_1_53C29892C857584299CBF5D05346208A07119F80@PEXCVZYM11.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.184.15]
x-forefront-prvs: 0154C61618
Content-Type: multipart/alternative; boundary="_000_758bbd568a014f879ae0db848902ee43BN1PR05MB520namprd05pro_"
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/_veCQT-lqE5eZjt_YWqYGF-sKB8
Cc: "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: Tue, 18 Mar 2014 17:12:22 -0000

Hi Bruno,

Many many thanks for your thoughts. Please find some comments inline with [Pushpasis]

Thanks
-Pushpasis

From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Tuesday, March 18, 2014 10:07 PM
To: draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org
Cc: rtgwg@ietf.org; Alvaro Retana (aretana)
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi authors,

This is an interesting work, thanks for the draft and the rtgwg presentation.


1)      Regarding node protection, have you considered/evaluated the use of the algorithm proposed in TI-LFA (draft-francois-segment-routing-ti-lfa)?
Namely: computing the backup path with a (C)SPF (without the protected node), and enforcing this explicit path using multiple segments/labels?
[Pushpasis] We have gone through the TI-LFA and draft, and to the best of my understanding this requires a CSPF for each destination node in the network with the primary link as well as primary-nexthop node as exclude constraints for finding a backup path(if feasible) all the way to the destination. This will need far more computation than 1 forward SPF per PQ-nodes. Obviously it has the advantage of finding 100% of all possible node-protecting backup paths. With 16 PQ-nodes selected on the basis of the default heuristic suggested in this draft it was seen to find ~96-97% of all possible node-protecting backup paths on some of the common SP topologies we have run a simulation on. Adding so much of extra computation to achieve rest 3% of feasible node-protecting backup paths seemed insignificant and not worth exploring.

Clearly, using TI-LFA in the absence of Segment Routing (more precisely the absence of adjacency segments/labels), 100% coverage is not possible.
[Pushpasis] My understanding is that since with TI-LFA we are going to run CSPF for each destination, we will find 100% of all the feasible node-protecting paths to each destination. There may be destinations for which there are no feasible/possible node-protecting backup paths at all. Those destinations cannot be covered because there is no possible node-protecting backup paths for them.

But this is also not possible with draft-psarkar.
[Pushpasis] True. Like Stephane mentioned already, it is a tradeoff :)

It's a priori not clear to me if the coverage would be increased or decreased.
[Pushpasis] Obviously with TI-LFA will provide more coverage, like I explained above. But that will come at the cost of lot of extra computational overhead of running a lot of CSPFs.
On the pro side, the use of multiple segments increases the coverage by allowing reaching more Q nodes. On the con side, the additional constraints added during the computation (namely enforcing the post convergence path (only)) decreases the coverage as this specific path may require an adjacency segment to cross a high metric link.
Evaluating this option would probably be interesting (in term of coverage, control plane computation, label stack depth, routing optimality, number of T-LDP sessions).
[Pushpasis]Looks like you are referring to protection of MPLS traffic. I hope you remember that this draft also applies to IP-FRR.


2)      On a related note, a possible heuristic for draft-psarkar to pick a node protecting PQ, would be to pick the PQ on the post convergence SPF (as per above/TI-LFA). That's simple, computationally not expensive (one SPF), and reduce the set of Candidate Node-Protecting PQ to a single element at most (not considering ECMP, to simply). If the set has one node, a node protecting PQ node has been found (on the optimal path, as a free property). If the set is empty, you may choose to fall back on draft-psarkar (picking a subset of PQ using heuristic and running SPF on those PQ).
[Pushpasis] Not sure if I got what you are trying to say here. But, I think it will be best to not bring in TI-LFA in this. This draft was intended to cover the lack of node-protection in the original RLFA draft and address the need of some of the network deployments which still need node-protection to be guaranteed. The intention of using a heuristic is to choose a subset of all PQ-nodes found in the network and restrict the number of FSPFs to a maximum number, and still achieve a hight percentage of coverage with the same subset of PQ-nodes.

Thanks,
Regards,
Bruno

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro Retana (aretana)
Sent: Friday, March 14, 2014 6:02 AM
To: rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Cc: draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org<mailto:draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org>
Subject: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi!

During the meeting in London the authors asked for the WG to adopt this draft.

This message officially starts the call for adoption for draft-psarkar-rtgwg-rlfa-node-protection.  Please indicate your position about adopting it by end-of-day on March 28, 2014.

http://tools.ietf.org/html/draft-psarkar-rtgwg-rlfa-node-protection

Thanks!

Alvaro.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.