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:01 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 E5C45130F70; Sun, 15 Jul 2018 01:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.78
X-Spam-Level:
X-Spam-Status: No, score=-1.78 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_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 GTuecJ7mNujO; Sun, 15 Jul 2018 01:01:30 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.65]) (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 E8347130E9E; Sun, 15 Jul 2018 01:01:28 -0700 (PDT)
Received: from [46.226.52.199] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.eu-west-1.aws.symcld.net id 17/1E-26453-65FFA4B5; Sun, 15 Jul 2018 08:01:26 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1VTf0wTZxj2u2t7h6Hmo1R5YaKh6jIWr6PGuMM MM+evqlkiydQIbnqVkzZpC+mVgPvDFQPiAEURRGsF3EAXVLBkEZi/EGFRo4I/EvyFiMUqqCDZ FktkurteUff98eZ53+fJ+zx3+T6a1FRSMTSf4+Qdds6qU01UzI0PzGTWvFuRmuAvJthAs4dkT w5p2ccNuxB7p3MvwW47vI1kz5/4lWS7Xrwh2X/O9im/po3HR4cIY4u7hzLW1IwSxjz/ZZXxtL eaWKVMUVrspoycjUrzwOm/FJm99cqcG95HKhd6UKssRBNpBf6FhHdjRcFGg8sI6Hhyn5AbH4L nd+pRIQqjVTgJGo/1qCSsxYtg+5/XKUlE4tcE5A0dIiUiEm+Go24XkkXpcPBxv7iJFvFa+Lcz XBor8CwYcXcHJWrMwUjjS0o2G6Yh9+pTUmrCcD6ChqqCoArhKfD6ynFCwiSOgnv9VUEMGEPNm U5SxpNhwPdWKetN0PvkMJLncbD/oYeScSzcrCpCkgHgJgK66wMqmWDgVXl5aNG38HNtdTA14B nw+7PvZf0IgqZb+ZQ8nw3NLatkeSZsLxwO7WxAkFuQGzKeBnU7+xQy0UqCq7Q2lGIq5B5sCRG DKvjt2g5yN2LcH32djO1w6tkF5A7+pwi4fKBf4RbNSRwPDX98IUvioKyoj5LxZ5DvOUR9PK9G VB1iTQ5Lutlp4yxWxpCQwBgMcxhDYiJjYOfpuR8Zk57PYrJ5wckY9Fy2oBe22DZZ0/R23tmIx Ns4QTzNyNu1qQ1F04RusnpP3opUzSRTRtoWMyeYNziyrLzQhqbStA7UsW9FLsLBp/M5my1W8U qP00CH67Tq22MirRYyOZtgSZepK2gl3f6wrJSku4K1sqNcrGPDUj1XtE+sD6SqUdgz7HxMlLp ScsDSCnOW/b3B+LO5iWJjItVIjKwJz+QdNovz//wgiqKRLlK9UdoSbrE73+cYFCMSYkT9juVS RCf3gYpxoQpt8tEFC3htRWtS1NNlSZqwZE+Tj2hXZXOld6kDa8r+9pxsmRkYGC0Z2XWhuPLe0 u/45hepc529ny6O3vrmy/ZLn0y3rL/YnfK85xuvBv3Uv25+jbWupPur8pKOgtWThFcLrW29jb TtYmu0q8Af4Yr3v0w5kkgtCXgv/RCX5kte7dMpBDNn+Jx0CNx/mXlyZTEEAAA=
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-2.tower-287.messagelabs.com!1531641681!4803156!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 440 invoked from network); 15 Jul 2018 08:01:24 -0000
Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-2.tower-287.messagelabs.com with AES256-SHA256 encrypted SMTP; 15 Jul 2018 08:01:24 -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=zeK2OJjoN7i5p56e0MyJCqxP0MOGpzdekzZuM0dXBJQ=; b=fL70BPJ8LKcCUO+44RgNoaXwIgixtGrtmp56nwlFnx8db5Gs9kzOe7nSYRJS5nt6xFIpfN/eC6/KCQSgvan+Hma3vJaWUSIiNKXa1j9xxK2vtzaDDUKfgtwp95sE9pnM+kv6dE5QREdR5mGztSKDv+jPYUoNcHcoBaoX8lGu+l0=
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB1976.eurprd03.prod.outlook.com (10.167.227.24) 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:01:19 +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:01:19 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>
CC: Robert Raszuk <robert@raszuk.net>, "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>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "daniel.voyer@bell.ca" <daniel.voyer@bell.ca>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.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: AQHT9sbRZr09Sx5RRE2SlwYEgLprKaSLVK0wgABYMmCAACKdgIAAAg1ggAGSBoCAAs/ogA==
Date: Sun, 15 Jul 2018 08:01:18 +0000
Message-ID: <DB5PR0301MB1909BB6FDB84AFFA40E241B99D5E0@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> <9235_1531399667_5B474DF3_9235_106_2_ec03f05d-ff9c-4680-9c6b-8a975430ea9e@OPEXCLILM24.corporate.adroot.infra.ftgroup> <DB5PR0301MB190919B60E5E5F453B69C2859D590@DB5PR0301MB1909.eurprd03.prod.outlook.com> <14656_1531486438_5B48A0E6_14656_375_1_e941fea2-8400-43d9-bdf0-7783f6be17db@OPEXCLILM32.corporate.adroot.infra.ftgroup>
In-Reply-To: <14656_1531486438_5B48A0E6_14656_375_1_e941fea2-8400-43d9-bdf0-7783f6be17db@OPEXCLILM32.corporate.adroot.infra.ftgroup>
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; DB5PR0301MB1976; 7:EYkFiP028rJLiRKVyshuq/smrpMqxxhsqItSBgfoAncJcGN3KxmTu54JMrK72iSh5ZtOt9auVeWaSqqGJOVAlTF86RTmyb6LiSEh8MrBM3VD8xQ/q+gtnIhFjBliVsFnZKES30bH3/jSQquOuqTbqhdmYgCAYlbLCYiT0UvjG8P/pHW224TtumU5Ejvh/lrb7j/g0LxmEaZWKvdRM1/DOWvl+FpV55TG3AdNg/zUsWY2fXEcsK6k4YqBuvW/2r8u
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: eb7ee43c-c370-4950-4956-08d5ea2925d0
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:DB5PR0301MB1976;
x-ms-traffictypediagnostic: DB5PR0301MB1976:
x-microsoft-antispam-prvs: <DB5PR0301MB19767A81FDE37C82DDA195BA9D5E0@DB5PR0301MB1976.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)(10201501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DB5PR0301MB1976; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB1976;
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(376002)(396003)(39850400004)(252514010)(51444003)(52314003)(199004)(189003)(53936002)(2900100001)(7736002)(99286004)(9686003)(2906002)(53946003)(26005)(102836004)(6436002)(186003)(76176011)(54896002)(6306002)(6506007)(5640700003)(55016002)(236005)(6246003)(7696005)(53546011)(486006)(97736004)(790700001)(93886005)(3846002)(6116002)(6916009)(14444005)(5630700001)(5024004)(54906003)(316002)(256004)(476003)(2351001)(74316002)(68736007)(11346002)(66066001)(25786009)(446003)(14454004)(106356001)(5250100002)(39060400002)(81166006)(81156014)(2501003)(478600001)(8936002)(8676002)(229853002)(5660300001)(72206003)(86362001)(105586002)(33656002)(4326008)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB1976; 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: homDQHrb0nRrs2hBIxPn4IRxBvWN6UWAoeAn7dWEbHvK1BtdgaqI/msKgk9yyIIxLNXqHsxnEJ1onD7ptastbNqvccjtYU+bspTEPJ5H0OX0uzWj+ONRAHI9wMLmln9Jtnm168MVwx5lQXwS1u+G9pedaA9Akq0oez+B7TDaBQNm0rXR2AMwKTdF5WRu4gmwKtEgkHEWWQB2HiqR+MW4xgz+/g7ItZSq07oubh6i44ldmEzhAnlqDel1kBaZlZ6YYOLTsRWMabdTZ1/qemAZ3vY0AhSmi4NGvTPt/0MowBHBdgfSx/FVnuP4iF0Uk8WDrnVoS11xfxL/QeqaSdO7uYlBtouUEWxTfCLbv4RwPE8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB1909BB6FDB84AFFA40E241B99D5E0DB5PR0301MB1909_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eb7ee43c-c370-4950-4956-08d5ea2925d0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2018 08:01:18.9437 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB1976
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/qd2D6xbxt6ca5XxbGNZf6p2EItM>
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:01:35 -0000

Stephane,
Lots of thanks for a highly informative response.

Leaving aside the potential to use repair paths theoretically provided by SR but not available for IP FRR, would it be correct to assume that using the post-convergence path in TI-LFA resolves some of operational issues with LFA selection that are mentioned in Section 3 of RFC 7916 because these issues presumably have been taken by the network operator as part of its original network engineering? E.g., using PE routers to protect against core failures, or selecting links with low BW while links with high BW are available?

Such a claim looks reasonable to me – especially since, as you have written, “TILFA perfectly fits the criteria: lowest IGP metric”  that is one of the mandatory criteria in 7916.

I admit that I did not understand that from just reading TI-LFA draft, not in the least because RFC 7916 is neither mentioned nor referenced there.

Regards,
Sasha

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

From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Friday, July 13, 2018 3:54 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>;
Cc: Robert Raszuk <robert@raszuk.net>;; rtgwg-chairs@ietf.org; pfrpfr@gmail.com; draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org; rtgwg@ietf.org; daniel.voyer@bell.ca; DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>;
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

RFC7916 was written at a time when TILFA did not exist. LFA and RLFA provide a set of candidate paths where we need to pick one or more to be installed.

With segment routing, we bring the ability to use any alternate path compared to LFA and RLFA which have a limited amount of candidate paths. As a consequence, we are not exactly in the same backup path selection logic as for LFA and RLFA. If we try to mimic RFC7916 logic with SR, we need to consider the list of candidate paths to be all alternate paths available through the network (so many many !) which may provide some scaling concern especially if we try to involve path attribute collection for the candidate paths. That’s why the logic of TILFA is to focus on the postconvergence path.

To answer your question, IMO, TILFA perfectly fits the criteria: lowest IGP metric.

We could think (as a theoretical exercice) of TILFA using other criterias than the lowest IGP metric. Note that if we think of TILFA in the context of flexalgo, the backup path may require to fit the constraint defined by the flexalgo.



From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Thursday, July 12, 2018 15:16
To: LITKOWSKI Stephane OBS/OINIS
Cc: Robert Raszuk; 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>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; daniel.voyer@bell.ca<mailto:daniel.voyer@bell.ca>; DECRAENE Bruno IMT/OLN
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Stephane,
Lots of thanks for a prompt response.

We seem to agree on at least one of my objections and the need to remove the associated text from the draft.

Regarding the other one:

1.       Lots of thanks for pointing to RFC 7916 that describes problems with LFA/RLFA selection. BTW, this RFC is not referenced by the TI-LFA draft

2.       One of the mandatory criteria in RFC 7916 is lowest IGP metric used to reach the destination:

a.       Is this equivalent to giving precedence to post-convergence paths?

b.       This is just one of mandatory criteria in RFC 7916 with some recommended criteria as well. These criteria should be evaluated based on their preferences.

3.       One modification of the draft that I can think about could be:

a.       Provide a Normative reference to 7916. In particular, clarify that all mandatory criteria listed in this RFC MUST  be supported

b.       RECOMMEND giving highest preference to the criteria of lowest IGP metric to the destination.

Regards,
Sasha

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

From: stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> [mailto:stephane.litkowski@orange.com]
Sent: Thursday, July 12, 2018 3:48 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>; DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
Cc: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; 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>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; daniel.voyer@bell.ca<mailto:daniel.voyer@bell.ca>
Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Hi Sasha,

> This flow will experience two path changes (pre-convergence--> FRR and FRR --> post-convergence
+1, I think that the current  statement in the draft is more a “marketing” one rather than a reality and IMO it may be worth removing it.
As Stewart and you pointed, from an end-to-end point of view the path may change (so the statement is wrong), a node upstream from the failure may reroute the traffic out of the FRR path. And in anyway, the label stack used will change (except in one case) even if the hop by hop logical path does not.

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

This argument is worth to mention. First of all, the draft does not say that TILFA is magic and prevents the requirement of additional tuning. It says : “there is much less need for the operator
   to tune the decision among which protection path to choose.”.
This statement is perfectly true. With LFA and rLFA, you have high chance to pick a P-PE to protect a core link and depending on your topology, a lot of tuning and policies is required (see RFC7916) to ensure you get a good backup (or sometimes we prefer not having a backup).
TILFA helps here as it can use a loopfree IGP metric optimized path which requires less tuning. I do not say that there will never be a requirement for tuning but it is unlikely.

Brgds,

Stephane



From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Thursday, July 12, 2018 13:26
To: DECRAENE Bruno IMT/OLN
Cc: Robert Raszuk; 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>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; daniel.voyer@bell.ca<mailto:daniel.voyer@bell.ca>
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?

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

_________________________________________________________________________________________________________________________



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