RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Sun, 15 July 2018 08:34 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66C6130DC1; Sun, 15 Jul 2018 01:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.77
X-Spam-Level:
X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com
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 Jvf0bdTC7Jt2; Sun, 15 Jul 2018 01:34:30 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCFF130E15; Sun, 15 Jul 2018 01:34:29 -0700 (PDT)
Received: from [46.226.52.199] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-b.eu-west-1.aws.symcld.net id B0/29-19217-3170B4B5; Sun, 15 Jul 2018 08:34:27 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILsWRWlGSWpSXmKPExsViovlDRVeY3Tv a4PICTovFayQsfqx3tdjwTsTi0fo+Rosb5yczWTQtbGK22L92MbPFhTe/mS1OPUh04PRY8/Md k8fOWXfZPZYs+cnkcb3pKrvH7o0LmAJYo1gz85LyKxJYM35O38lcsGgKS8WPGfNYGxgX9LJ0M XJxsAgsYpY4+HcVmCMkMIVJYsHkdjYI5zGjxIyzi9m7GDk52ARsJTatvssGYosI6EpcenmKEa SIWWASs8S01adYQBLCAmkSy2c1MEIUpUvMfvSECcJOlnjzuhWomQNon6rErE92ICavQKLE6vc OELvusUocWvqeFaScE2jXhBd7wcYwCohJfD+1BmwMs4C4xK0n88FsCQEBiSV7zjND2KISLx// Y4WoT5K4/3QhI0RcUWLGvTnsELasxKX53WA3SwhsZ5J4OO0c1CBdiQ9Tp0IN8pWY3HWABeQ4C QFliS0vYiHqHzBKLHzQDVWvI7Hn9FIWCLtA4syGHawQRfMZJfZMmQmVkJNY1fuQBSJxgFli/v yLrBAJGYnG2TuhEqfZJP7sWsQ+gVF3FpL3IOw8ib6WOewgNq+AoMTJmU9YZgFdxSygKbF+lz5 EiaLElO6H7BC2hkTrnLnsyOILGNlXMZolFWWmZ5TkJmbm6BoaGOgaGhrpGlpa6proJVbpJuml luqWpxaX6BrqJZYX6xVX5ibnpOjlpZZsYgQmRgYg2MG490LyIUZJDiYlUd6JLV7RQnxJ+SmVG YnFGfFFpTmpxYcYZTg4lCR4S1i9o4UEi1LTUyvSMnOAKRomLcHBoyTCywuS5i0uSMwtzkyHSJ 1itOc4cm/KJGaOC2Dyz/upQPJO97RJzEIsefl5qVLivI9B2gRA2jJK8+CGwnLKJUZZKWFeRqA zhXgKUotyM0tQ5V8xinMwKgnzrgCZwpOZVwK3+xXQWUxAZ+l1eIKcVZKIkJJqYLxi16c54+bv hMOiG6e9++Vw6Je+wZr/3Z1p5sfDanRvhX419jNscb90mrXsoWa6bWOHj53lzyMu/wXDJk38o 6t2ntVbaFuM53yekmVFe7k3JR+zVfhpdzWCr3jPxPVahVKbLirefLZzSZKY5jGGOb+OS6/Yr7 uxv+r3HmXvuimdDL929GyTuaLEUpyRaKjFXFScCAAzeRbNJAQAAA==
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-18.tower-287.messagelabs.com!1531643663!4822329!1
X-Originating-IP: [52.41.248.36]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 5085 invoked from network); 15 Jul 2018 08:34:25 -0000
Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-18.tower-287.messagelabs.com with AES256-SHA256 encrypted SMTP; 15 Jul 2018 08:34:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=njMe2Ed951UdEHmfYJjXx3Vh2Q9eLFrnTrvTdBBOsQQ=; b=fmHhtL5ByLcEqWYv+TrvhDaZea8mpH/GlzJy5lRyPdLDboSV9A+UQN1faUjiepa/8GrWo5cBwDzlEnMnm7YfIzUTlFivu1Hc7xGMxoTRPmzV/tWVrYW2eNEUym812aul++4kH0IUoS3fJetFBMQcjZ+i2zCMrxb6G7RrXEz+IsU=
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB1928.eurprd03.prod.outlook.com (10.167.227.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.19; Sun, 15 Jul 2018 08:34:20 +0000
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::6c62:c2c0:1d05:4e77]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::6c62:c2c0:1d05:4e77%2]) with mapi id 15.20.0952.021; Sun, 15 Jul 2018 08:34:20 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Ahmed Bashandy <abashandy.ietf@gmail.com>
CC: "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "pfrpfr@gmail.com" <pfrpfr@gmail.com>, "draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org" <draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org>, "daniel.voyer@bell.ca" <daniel.voyer@bell.ca>, "rtgwg@ietf.org" <rtgwg@ietf.org>, Robert Raszuk <robert@raszuk.net>, Chris Bowers <cbowers@juniper.net>, Stewart Bryant <stewart.bryant@gmail.com>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa
Thread-Topic: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa
Thread-Index: AQHT9sbRZr09Sx5RRE2SlwYEgLprKaRFp8yAgAAiTgCAAKAXgIAAC8xwgEEZkgCAAO6TEIAFVAaCgAJlvTA=
Date: Sun, 15 Jul 2018 08:34:19 +0000
Message-ID: <DB5PR0301MB1909E1F342F81C3E29E7D4919D5E0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
References: <1e42030f-3d68-fca3-500c-95ab7303e7cd@gmail.com> <F0098308-4F1E-4596-B3F9-B6740BA88F9A@gmail.com> <bfbe9775-ee81-b1fe-bb1f-a02392bc6fb5@gmail.com> <43389eec-6d63-ee35-54ed-19562b24562b@gmail.com> <12E9EB99-2970-49B6-9407-FE6AEAB3A0BB@gmail.com> <SN6PR05MB44305802FF3330DC2AE27F9CA96E0@SN6PR05MB4430.namprd05.prod.outlook.com> <CA+b+ERm=Jczivo0sJGuHWyP7UJbJFY=+N-vyQK7H_Es2anLGmQ@mail.gmail.com> <DB5PR0301MB1909BF5C925473CB3BC97BE79D6D0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <27db8d16-6120-17e9-55fa-30d35be97b32@gmail.com> <DB5PR0301MB190910B15E3B74ED45B18CE19D5B0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <2ff33bf0-cb23-9be2-99ac-25209876a5cf@gmail.com> <932429c1-8b06-126e-7db4-c7fa642e6882@gmail.com>
In-Reply-To: <932429c1-8b06-126e-7db4-c7fa642e6882@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5PR0301MB1928; 7:7SC+0DrecjcDLIDlzqwRL4e/y2337UT3p5unzjXY86sDqbbwcZ27FLpL6hhRM1S8dc9+PTwGhYiXwLINcdDlL7OIoZILsKOB1Dh4axcTDyeHp0y7Obr4yhCUquMzK1g3MQe/E0M1IYSiAF7N+pgUiWO3OAYJAf6JVfeaiohAOAVNP5RrX8PcUeg2vk6dwTsevoXqEsg/lk4TRqW624hCRVZmOjHTZ5PbHblnLVYKa6aVYNh53EEoZv8G19MBZDCW
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 1be019ba-2f8b-4e3b-bcff-08d5ea2dc28f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB1928;
x-ms-traffictypediagnostic: DB5PR0301MB1928:
x-microsoft-antispam-prvs: <DB5PR0301MB1928F42A40CA60D7BC7B6DE89D5E0@DB5PR0301MB1928.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(226690903318834)(120809045254105)(138986009662008)(85827821059158)(21748063052155)(279101305709854);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DB5PR0301MB1928; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB1928;
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(396003)(39850400004)(376002)(366004)(199004)(189003)(45074003)(51914003)(252514010)(53546011)(476003)(54906003)(256004)(14444005)(5024004)(6506007)(102836004)(316002)(68736007)(606006)(74316002)(7736002)(6916009)(76176011)(8936002)(486006)(81166006)(5660300001)(8676002)(11346002)(81156014)(7696005)(93886005)(561944003)(66066001)(55016002)(33656002)(236005)(99286004)(6306002)(54896002)(9686003)(97736004)(446003)(105586002)(25786009)(2900100001)(229853002)(4326008)(2906002)(14454004)(26005)(39060400002)(53946003)(6246003)(86362001)(186003)(478600001)(106356001)(72206003)(3846002)(6116002)(790700001)(5250100002)(53936002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB1928; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Q9Bz3WGJguO2vOX60XjsCuBNeJ0ExCFV7mw1Ft7JHViuffQ8XQXnkOhDjjsrR0SZd4Iqi0b1QZkehGSRguB8fpyz7dpAdvyC+rvdQVqQ5ye5NRT27gE1t3HrxtYp8wIH13m72IgxDXkpTJYA8257h3N19G5FGveN7fdlZdacc+wW0XqdWi+CLSb6XdD/wgGTQI1s3jx5MCTn5talP9JVRGjjj+GsQ6CeH6fQlFJKESW21Ougx3BFCt2Q2PRECSKyUgya3/UCcrbd9Juucq11L1/M3Yn0MPTSEvnXyTnL4a4qFjzd3yeTUIM69gL595CmDcFXxtxlqKVDqreIHlK4K7QfkWUcjHtGn+IQQ1bA9ig=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB1909E1F342F81C3E29E7D4919D5E0DB5PR0301MB1909_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1be019ba-2f8b-4e3b-bcff-08d5ea2dc28f
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2018 08:34:20.0540 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB1928
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/DNc4DNE9w0qjugUqZVlH5TXupvA>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.27
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 15 Jul 2018 08:34:34 -0000

Ahmed and all,
I’d like to summarize my understanding of the current status of my objections to adoption of the TI-LFA draft by the RTGWG. The

Original Issue

Current Status

Desired Resolution

IPR Disclosures for the draft are Lacking

IPR Disclosure 3068<https://datatracker.ietf.org/ipr/3068/> has been filed by Cisco

From my POV the issue is resolved.

Claims of benefits (in Section 1) associated with using the post-convergence path as the repair path are not justified

The claim about reduction of the number of path changes and service transients is, generally speaking, incorrect.

Remove this claim from the draft.

The claim about substantial simplification of tuning has been misunderstood

Provide the context for this claim with an explicit reference to RFC 7916 and
clarify that usage of shortest IGP path for LFA selection is actually one of the mandatory criteria in this RFC.

Scalability issue with usage of post-convergence path when Q-space computation is required

This issue remains unresolved.
One of the authors suggested using proxy Q-space that is computed just once.

Explicitly recognize the issue.
Explain whether using proxy Q-space (as in RFC 7490) is acceptable.

Overlap between Section 5.3 of the TI-LFA draft and draft-hegde

Priority claimed by the authors of TI-LFA draft.

From my POV this issue should be resolved between the authors of the two drafts.
But it is up to the WG to decide how to handle this issue.


Hopefully these notes clarify my position.

I would like to thank Bruno and, especially, Stephane, for their timely and highly informative responses.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
Sent: Friday, July 13, 2018 10:30 PM
To: Stewart Bryant <stewart.bryant@gmail.com>;; Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>;
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org; daniel.voyer@bell.ca; rtgwg@ietf.org; Robert Raszuk <robert@raszuk.net>;; Chris Bowers <cbowers@juniper.net>;
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa


See inline #Ahmed

Ahmed



On 7/10/18 5:48 AM, Stewart Bryant wrote:



On 10/07/2018 12:42, Alexander Vainshtein wrote:
Ahmad and all,
Lots of thanks for your response to my comments.
Unfortunately I cannot say that it addresses all of them – please see inline belowfor the details.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
Sent: Monday, July 9, 2018 10:54 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com><mailto:Alexander.Vainshtein@ecitele.com>; Robert Raszuk <robert@raszuk.net><mailto:robert@raszuk.net>; Chris Bowers <cbowers@juniper.net><mailto:cbowers@juniper.net>
Cc: rtgwg-chairs@ietf.org<mailto:rtgwg-chairs@ietf.org>; pfrpfr@gmail.com<mailto:pfrpfr@gmail.com>; draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org<mailto:draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org>; daniel.voyer@bell.ca<mailto:daniel.voyer@bell.ca>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; Stewart Bryant <stewart.bryant@gmail.com><mailto:stewart.bryant@gmail.com>
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Thanks for the comments
See the reply inline at #Ahmed

Ahmed
On 5/29/18 3:35 AM, Alexander Vainshtein wrote:
Robert, Chris and all,
I agree with Robert that it is up to the authors of an individual submission what they consider in or out of scope of the draft.
However, I agree with Chris that the authors of an individual draft asking for its adoption by a specific WG should do their best to address the comments they have received from the WG members.
#Ahmed: Thanks a lot



From my POV this did not happen in the case of the draft in question – for the following reasons:

1.      In his early RTG-DIR review<https://datatracker.ietf.org/doc/review-bashandy-rtgwg-segment-routing-ti-lfa-00-rtgdir-early-bryant-2017-05-31/> of the draft Stewart  has pointed to the following issues with the -00 version of the draft (needless to say, I defer to Stewart regarding resolution of these issues):

a.       No IPR disclosures for draft-bashandy in spite of 3 IPR disclosures for its predecessor draft-francois.  I have not seen any attempts to address this issue – at least, search of IPR disclosures for draft-bashandy did not yield any results today
#Ahmed: Since draft-bashandy inherits draft-francois, then the IPR of the latter applies to the former. But if there is a spec that requires re-attaching the IPR of an inherited draft to the inheriting draft, it would be great to point it out or point out some other draft where that occurred so that I can follow the exact procedure.
[[Sasha]] Well, it looks like we have been both in error here: there is a Cisco IPR Disclosure<https://datatracker.ietf.org/ipr/3068/> for draft-bashandy dated 18-Sep17.This disclosure has been posted after Stewart’s early review, and I have been wrong not checking for it before sending this comment. But there is no “inheritance” from IPR Disclosures for draft-francois either. So I think this issue is now closed.




b.      Selecting the post-convergence path (inheritance from draft-francois) does not provide for any benefits for traffic that will not pass via the PLR after convergence.

                                                                                                                                      i.      The authors claim to have addressed this issue by stating that “Protection applies to traffic which traverses the Point of Local Repair (PLR). Traffic which does NOT traverse the PLR remains unaffected.”

                                                                                                                                    ii.      From my POV this is at best a misleading statement because it does not really address Stewart’s comment which was about traffic that traversed the PLR before convergence but would not traverse it after convergence.

                                                                                                                                  iii.      This is not a fine distinction: actually it indicates that selecting post-convergence path for repair is more or less  useless (unless the traffic originates at the PLR).
#Ahmed: Thanks for pointing out this *additional benefit* of providing a post-convergence back path. If a flow starts to use the PLR after a failure, then the presence of a post convergence backup path on the PLR extends the benefits of using the post-convergence path to flows that did not use the PLR prior the topology change. I will modify the statement in the introduction to indicate that :)
[[Sasha]] Sorry, but this looks quite off the target to me. The repair path provided by TI-LFA is only relevant for the period between the actual failure (that triggers usage of this path) and re-convergence of IGP. I.e. traffic that did cross the PLR before failure but crosses it after failure AND IGP re-convergence cannot benefit in any way from selection of the repair path. At the same time, it is pretty easy to give an example of a setup in which:

-          Traffic between two nodes crosses the PLR before failure

-          The destination of this traffic is protected (say by a local LFA) and so will use the repair path in the interval between failure detection and IGP re-convergence

-          After IGP re-convergence traffic does not pass thru the original PLR anymore and thus does not experience any benefits from any possible selection of the repair path by the PLR.
If you wish, I can send you a simple example topology.

So, from my POV, this issue remains as open as before.

SB> This concern has been a day one issue by pretty much everyone that has seen this work.

The draft really needs text to address it.
#Ahmed: I replied to Sasha







c.       Selecting the post-convergence path is detrimental to scalability of the solution. Please note that in  RFC 7490<https://tools.ietf.org/html/rfc7490> “the Q-space of E with respect to link S-E is used as a proxy for the Q-space of each destination”  in order to provide a scalable solution – but this clearly is not the case of draft-bashandy if post-convergence paths are used. To the best of my understanding, the authors did not, so far, do anything to address this comment.
#Ahmed: I fail to see why there is a scalability problem. draft-bashandy-rtgwg-segment-routing-ti-lfa just prefers particular node(s) in the Q space if that node(s) is (are) along the post convergence path.
But if I am missing something, it would be great to point out exactly what aspect of scalability you are concerned about so that we can address it
[[Sasha]] Please take a look at the text from Section 5.2.1 of RFC 7490<https://tools.ietf.org/html/rfc7490> (the relevant text is highlighted):
   Note that the Q-space calculation could be conducted for each
   individual destination and a per-destination repair tunnel end point
   determined.  However, this would, in the worst case, require an SPF
   computation per destination that is not currently considered to be
   scalable.  Therefore, the Q-space of E with respect to link S-E is
   used as a proxy for the Q-space of each destination.




[[Sasha]] The proxy approach described above works well enough with RLFA. But it is hardly compatible with the proposal to use prefer the repair paths that match post-convergence paths, because post-convergence paths are per affected destination. I do not see how this can be combined with selecting a single Q-space (and hence a single PQ node) for all destinations.

SB> That is a good point.

- Stewart


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________