IETF Logo Mail Archive

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

<stephane.litkowski@orange.com> Fri, 13 July 2018 12:37 UTC

Return-Path: <stephane.litkowski@orange.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 D732B130F90; Fri, 13 Jul 2018 05:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 oswqblmk-UGm; Fri, 13 Jul 2018 05:37:54 -0700 (PDT)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90AF2130E14; Fri, 13 Jul 2018 05:37:54 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 41Rslh5K9mz8tPS; Fri, 13 Jul 2018 14:37:52 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 41Rslh3KfszCqkX; Fri, 13 Jul 2018 14:37:52 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0399.000; Fri, 13 Jul 2018 14:37:49 +0200
From: stephane.litkowski@orange.com
To: Stewart Bryant <stewart.bryant@gmail.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, DECRAENE Bruno IMT/OLN <bruno.decraene@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>
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: AQHT3HY1G0oYD7/8O0i22VwNlm4qXqQpIMMAgA5RxICADkCEAIAAB9uAgAAiTgCAAKAXgIAAGdaAgEELiACAARkbgIAC9POAgAAbGwCAADVzwP//8fMAgAGeuzA=
Date: Fri, 13 Jul 2018 12:37:48 +0000
Message-ID: <29234_1531485472_5B489D20_29234_5_1_7d70ca00-8630-456a-b620-03da4acbf685@OPEXCLILM43.corporate.adroot.infra.ftgroup>
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> <85030364-d6c6-36d0-0aa5-11dc96f6b638@gmail.com>
In-Reply-To: <85030364-d6c6-36d0-0aa5-11dc96f6b638@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.2]
Content-Type: multipart/alternative; boundary="_000_7d70ca008630456ab62003da4acbf685OPEXCLILM43corporateadr_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/EdUAVa3LQHoGjEZWQHHtPyWd4xM>
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: Fri, 13 Jul 2018 12:37:57 -0000

Hi Stewart,

TILFA is not intended to provide a loop free path at all phases of the convergence process. As any FRR technique (or most), it may suffer from micro-looping when the PLR has converged and rewrites the path out of the computed FRR path.
TILFA just encodes the postconvergence path seen from the PLR point of view in a loop free manner and the resulting label stack is used only during the FRR.

Global microloop avoidance is also doable using similar mechanism as TILFA, but that’s another story.
RFC8333 (local delay) can also be used in conjunction with TILFA to protect against local microloops that are caused by a link down.

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Thursday, July 12, 2018 15:47
To: LITKOWSKI Stephane OBS/OINIS; Alexander Vainshtein; DECRAENE Bruno IMT/OLN
Cc: Robert Raszuk; rtgwg-chairs@ietf.org; pfrpfr@gmail.com; draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org; rtgwg@ietf.org; daniel.voyer@bell.ca
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa




On 12/07/2018 13:47, stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> wrote:
TILFA helps here as it can use a loopfree IGP metric optimized path

All IPFRR paths are loop free against the number of failures that they set out to guard against.

However not all techniques are loop-free at all phases of convergence, and you now recognize that to be the case with this method.

Some methods are unconditionally stable against any degree of failure (down stream repair), although this is achieved at a cost of reduced coverage. All other methods are potentially looping and need a method of retrieving the situation which I did not see documented in this draft.

- Stewart

_________________________________________________________________________________________________________________________

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.

v2.23.0 | Report a Bug | By Email