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

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 12 July 2018 13:49 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 4E1CF130DDE; Thu, 12 Jul 2018 06:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.769
X-Spam-Level:
X-Spam-Status: No, score=-1.769 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, URIBL_BLOCKED=0.001] 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 RP1yIArXKYfW; Thu, 12 Jul 2018 06:49:33 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.68]) (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 6B36C12785F; Thu, 12 Jul 2018 06:49:32 -0700 (PDT)
Received: from [46.226.52.199] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-b.eu-west-1.aws.symcld.net id CD/E6-10044-A6C574B5; Thu, 12 Jul 2018 13:49:30 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALsWRWlGSWpSXmKPExsViougQq5sV4x5 t8OICq8XiNRIWP3bMYbb4sd7VYsM7EYtH6/sYLW6cn8xk0bSwidli/9rFzBYX3vxmtvi69yGr xakHiQ7cHmt+vmPy2DnrLrvHkiU/mTyuN11l92h5dpLNY/fGBUwBbFGsmXlJ+RUJrBlPZ35jL Xj2mLni+4QHjA2MW+4ydzFycbAILGKWeLN1FhuIIyQwlUniXsMxdgjnMaPE58+3WLsYOTnYBG wlNq2+C1YlIrCSUeLF0jlg/cwCk5glNry7wQxSJSyQJrF8VgMjiC0ikC4x+9ETJgjbT2JD63w WEJtFQFXi06lXYDavQKLEh+NtUOuusUtcPdQF1sAJtO7uzmZ2EJtRQEzi+6k1YHFmAXGJW0/m g9kSAgISS/acZ4awRSVePv7HClGfJHH/6UJGiLiixIx7c9ghbFmJS/O7GUGWSQhsZ5K4Mnc5K 0RCV+LD1KlQg3wl9jS2AsU5gGxliS0vYiHqPzJKTF92H6peR2LblRVQ9QUSLcfeQw1dzyjR2N 4ItVlOYlXvQxYI+wCzxMd5GhC2jMSLx7OYIRquskmsuDuVbQKj7iwk30HYeRJX3q1lngUOJkG JkzOfsMwCOopZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2K0SCrKTM8oyU3MzNE1NDDQ NTQ00jW0NNM1tDDWS6zSTdJLLdUtTy0u0TXUSywv1iuuzE3OSdHLSy3ZxAhMnwxAsINx84XkQ 4ySHExKorxSVq7RQnxJ+SmVGYnFGfFFpTmpxYcYZTg4lCR4paPdo4UEi1LTUyvSMnOAiRwmLc HBoyTCmwKS5i0uSMwtzkyHSJ1i9OY4cm/KJGaOC2By3tGpQPLPexC5r3sakLwDIoVY8vLzUqX EeZNBRgiAjMgozYNbAMtIlxhlpYR5GYFOFuIpSC3KzSxBlX/FKM7BqCTM6w0yhSczrwTujldA JzIBnRiX4gZyYkkiQkqqgbHuVO+Hh/mbHLPUQ3xUF0Uu/FqwQdl7xrurk+zc7R46ud/uOnTkt +TF/E43rmLhixMrK14leB0oqD/++M+a8+3eJ6O29X1+X/1WIMqBz1e2ysfmo6dGlc2UiGa5lO uuV76n2Ii+XxolPun557Onmm32nkre8vLipLWKxuuvrqu/tIXHKuv6mkolluKMREMt5qLiRAA 2cADAQwQAAA==
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-10.tower-287.messagelabs.com!1531403366!4642936!1
X-Originating-IP: [52.33.64.93]
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 9570 invoked from network); 12 Jul 2018 13:49:28 -0000
Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-10.tower-287.messagelabs.com with AES256-SHA256 encrypted SMTP; 12 Jul 2018 13:49:28 -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=qo3RmyR+Bf5eZDEx04P/rUVgQ/hvejdCMriS9wxJJf0=; b=OQmbZNmXfyNXulxqcv+EWUbwbfvE7oCH5FbvVSKHJMxny3Ohd7IX8XzHmolMZEbVyLhAHAbl820DK8rr6QD25QvRouLqrPCWZmJhXEOqXSiabnR0vAREPYCyqVL/Slk0mYiz5u2bXO7jmkzupW2XdsuDgohjKLMyr02xI+QCJXw=
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB2007.eurprd03.prod.outlook.com (10.167.227.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.17; Thu, 12 Jul 2018 13:49: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.017; Thu, 12 Jul 2018 13:49:20 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.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>, Ahmed Bashandy <abashandy.ietf@gmail.com>, 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
Thread-Topic: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa
Thread-Index: AQHT9sbRZr09Sx5RRE2SlwYEgLprKaSLVK0wgABYMmCAAA/D0IAAIQ8AgAACMqA=
Date: Thu, 12 Jul 2018 13:49:20 +0000
Message-ID: <DB5PR0301MB19092D462918918ADF1957A39D590@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> <98d610d9-1dd4-3025-3b5c-070b6120cda7@gmail.com> <30046_1531388953_5B472419_30046_355_1_53C29892C857584299CBF5D05346208A47AEA48D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <DB5PR0301MB19097AB7FA7181464B765B779D590@DB5PR0301MB1909.eurprd03.prod.outlook.com> <6030_1531397206_5B474456_6030_298_1_53C29892C857584299CBF5D05346208A47AEA7BE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <b023d2d8-0eae-752e-76f2-568947c0dee5@gmail.com>
In-Reply-To: <b023d2d8-0eae-752e-76f2-568947c0dee5@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; DB5PR0301MB2007; 7:+oB2Q7x3ZibZw69zE3Sxe+MwZYs3AJaQV8C7wW7tKsZif5CWKR5Xboz7yw5YrsRww8jPpL/SMaFKyYruWVXDZ/juzYmY/O+bMEbFFPfDmpbipUkAkIjeg5SYjL+0T7QXnDcVMqtF/LgWDG3AH+Is1TLhQy8GCjW4k5mlkAkgwYU1sZf4bM8nVSTQ/h2myhnSORZ6uNnTd6Ux6Nj+5r8q0QesgPO9svCBEwMRyKzZrmSPc2z3b12g/FhBMzspCaMh
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: fa7a6cb4-5fe8-4cae-096b-08d5e7fe44fe
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB2007;
x-ms-traffictypediagnostic: DB5PR0301MB2007:
x-microsoft-antispam-prvs: <DB5PR0301MB20079CA2D9C26195433E41F99D590@DB5PR0301MB2007.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(226690903318834)(138986009662008)(223705240517415)(85827821059158)(18271650672692)(21748063052155)(279101305709854);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DB5PR0301MB2007; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB2007;
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(136003)(376002)(366004)(199004)(189003)(252514010)(51444003)(53754006)(25786009)(476003)(53946003)(110136005)(53936002)(54906003)(256004)(99286004)(236005)(55016002)(54896002)(106356001)(4326008)(93886005)(9686003)(7736002)(33656002)(7416002)(6306002)(105586002)(66066001)(8936002)(14444005)(39060400002)(5660300001)(81166006)(316002)(6436002)(6246003)(2906002)(5024004)(8676002)(6506007)(97736004)(81156014)(2900100001)(53546011)(229853002)(102836004)(186003)(486006)(74316002)(11346002)(76176011)(446003)(14454004)(26005)(2201001)(2501003)(68736007)(3846002)(790700001)(86362001)(7696005)(6116002)(5250100002)(72206003)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB2007; 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: 8mrZ5fFnD1Mm4iv9Bc2S2FxhjzVHLggD1qiTSztp0uDOJrWgWqhbEZCoMkcI8PHvYQDd0eGs2/YYsj9F2nljtvDS7XgsEyYyFZBYJpCBczjWlksSBj8ocVBdj5Z6JDbczhxLfIXjmfIHJ/nQxpKDg5dFaVqoascNmH59IJo0MQw4cxXBrhNnWh1akQequAOqbc6tPVfvPp2KAE9pXY9LWIBcgnxZLBUhxEdimc3Sm5i3hUpL9mxQxrxmH2BTqQVDjdyQyd4/IYEeoa0IrEk+skltPcNe+X9iaQbYT9UsQMXn8CQXnGTwEGiO+lCaZpVS+heBzb8T9JE81TY4S9vcop5DSdRsLqWZcsjXEQoX7RA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB19092D462918918ADF1957A39D590DB5PR0301MB1909_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fa7a6cb4-5fe8-4cae-096b-08d5e7fe44fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2018 13:49:20.6060 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB2007
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/ysxSaCq0Pjs45L_tZVhkCFSlFs8>
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: Thu, 12 Jul 2018 13:49:37 -0000

Hi all,
I concur with Stewart regarding the way to move forward with the draft.

I defer to the RTGWG chairs regarding the decision to adopt the draft now or after the new version is posted.

Regards,
Sasha

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

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Thursday, July 12, 2018 4:39 PM
To: bruno.decraene@orange.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; Ahmed Bashandy <abashandy.ietf@gmail.com>om>; Robert Raszuk <robert@raszuk.net>et>; Chris Bowers <cbowers@juniper.net>
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa



So, it sounds like we need a new version of the draft clarifying the solution's characteristics and allowing the reader to evaluate its applicability to their specific network problem.

Publishing an updated text fully addressing the review comments and putting it back to the WG for review of the revised draft would seem to be the way forward.

Best Regards

Stewart

On 12/07/2018 13:06, bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> wrote:
Sasha,

Please see inline [Bruno]

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Thursday, July 12, 2018 1:26 PM
To: DECRAENE Bruno IMT/OLN
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>; Ahmed Bashandy; Robert Raszuk; Chris Bowers; Stewart Bryant
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Bruno,
It seems there is some misunderstanding, and I will try to clarify it.

To the best of my understanding, the following text in Section 1 of the draft presents the benefits of using post-convergence path for FRR:

   As the capacity of the post-convergence path is typically planned by
   the operator to support the post-convergence routing of the traffic
   for any expected failure, there is much less need for the operator
   to tune the decision among which protection path to choose.  The
   protection path will automatically follow the natural backup path
   that would be used after local convergence.  This also helps to
   reduce the amount of path changes and hence service transients: one
   transition (pre-convergence to post-convergence) instead of two
   (pre-convergence to FRR and then post-convergence).

I see two different claims of benefits from using post-convergence path in this test fragment

1.       One path change and therefore one service transient instead of two

2.       Post-convergence path is taken into account in the operator’s panning (e.g., by allocating sufficient resources for traffic flows on both pre-convergence and post-convergence paths).


Speaking just for myself, I think that neither of these claims is justified for traffic flows that do not originate at the PLR.

E.g., consider Stewart’s example and the traffic flow from A to E

1.       This flow will experience two path changes (pre-convergence--> FRR and FRR --> post-convergence

2.       The network operator will not take links C-F, F-G and G-D for consideration in its planning of pre-convergence and post-convergence paths for this flow.

Did I miss something substantial?
[Bruno] I think we should distinguish 2 aspects:
a) the technical behavior
b) the text/claims in the draft

My answer was about “a”. I see that you are not challenging it.
Regarding “b”, speaking for myself, I’m primarily interesting in the technical specification, less about the text introduced to motivate the solution. That being said:
1) If it were up to me, I would personally be very open to completely rewrite the text you cited. e.g. using my text ;-) (below).
2) I mostly agree with you. Although possibly the text could be rephrased to say that it refers to the local behavior on the PLR rather than the end to end path in the network. Also, capacity planning is very topology dependent and SP dependent. Here, Stewart’s example is custom-built to highlight a case where capacity planning for TI-LFA is different than capacity planning for link failure. I personally don’t find the example very typical of real network, as typically it’s more efficient to try to share the backup capacity for both link and node failure, which is not the case in the example.
That being said, the example is good enough to say that the capacity planning claim is not guaranteed. Again, cf my point 1. i.e. I support changing this text.

Coming back to the technical behavior, if we agree that using the shortest path from the PLR to the destination is the best path (that we can choose from) that’s good enough for me.

Regards,
--Bruno

Regards,
Sasha

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

From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> [mailto:bruno.decraene@orange.com]
Sent: Thursday, July 12, 2018 12:49 PM
To: Stewart Bryant <stewart.bryant@gmail.com><mailto:stewart.bryant@gmail.com>
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>; Ahmed Bashandy <abashandy.ietf@gmail.com><mailto:abashandy.ietf@gmail.com>; 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>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Stewart,

Please see 1 comment inline [Bruno]
Trimming the text to ease the focus on this point

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Tuesday, July 10, 2018 2:40 PM



On 09/07/2018 20:53, Ahmed Bashandy wrote:
[…]



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.”

SB> It is not as simple as that, and I think that the draft needs to provide greater clarity.

I think there will be better examples, but consider

              12
      +--------------+
      |              |
A-----B-----C---//---D----E
        10  |        |
            F--------G

Traffic injected at C will initially go C-D-E at cost 2, will be repaired C-F-G-D-E at cost 4 and will remain on that path post convergence. This congruence of path is what TI-LFA claims.

However, a long standing concern about traffic starting further back in the network needs to be more clearly addressed in the draft to clearly demonstrate the scope of applicability.

For traffic starting at A, before failure the path is A-B-C-D-E cost 13

TI-LFA will repair to make the path A-B-C-F-G-D-E cost 15 because TI-LFA optimises based on local repairs computed at C.

After repair the path will be A-B-D-E cost 14.

[Bruno] The draft is about IP Fast ReRoute (FRR).
FRR is a local reaction to failure, so by hypothesis, all nodes but the PLR are not aware about the failure. This includes all upstream nodes which do keep forwarding traffic through the same path, i.e. via the PLR.
The argument that the path would have been shorter if upstream node were aware of the failure to reroute before (or that the PLR should send the packet back in time) is not relevant.
The only question which matter is: from the PLR to the destination, which is the best path to use?
I, and the draft, argue that the best path in IP routing, is the IGP shortest path. Whichever type of metric you choose (e.g. bandwidth, latency, cost…). Do you disagree on this?


Now, eventually we can narrow down the discussion to the choice of terms. We can discuss about the term “post-convergence paths from the point of local repair », which you don’t think to like. Although, the term seems technically true to me, I would also be fine with changing from  “post-convergence path” to “optimal IGP shortest path”



So the draft needs to make it clear to the reader that TI-LFA only provides benefit to traffic which traverses the PLR before and after failure.

[Bruno] No, that is not true. cf above.
--Bruno



Traffic which does not pass through the PLR after the failure will need to be traffic engineered separately from traffic that passes though the PLR in both cases.






_________________________________________________________________________________________________________________________



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.

___________________________________________________________________________

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.
___________________________________________________________________________

_________________________________________________________________________________________________________________________



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.


___________________________________________________________________________

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.
___________________________________________________________________________