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

Ahmed Bashandy <abashandy.ietf@gmail.com> Wed, 18 July 2018 00:13 UTC

Return-Path: <abashandy.ietf@gmail.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 00BBD130E8C; Tue, 17 Jul 2018 17:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2ARqTkPcJVqc; Tue, 17 Jul 2018 17:13:25 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E327813104C; Tue, 17 Jul 2018 17:13:24 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id z8-v6so1137894pgu.8; Tue, 17 Jul 2018 17:13:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Nob7h68kGshh4P/nBU3wEXQ9/ERoRlorm02urb50vm0=; b=b8I2TYcvEaA0UGW16hQi5lAeg3ZZG1Fr3dUaTM2HNMjixCDPVWyVqllrE+2bKwO1Uu egex9b2O2C65BaJ6M84lfm5lerHnnME812sFaT2v7Fy/OGCXigIwognhOEDSrcATNSVi tqmx6Lwa8b/sxOCR0luMtqpaqBbkBmQ1dBFdVz13VMmpx40qyugAHa1mgFNBNNJQD9FS B+VkxokbybVlAHRfJPsutQfCv/ExdNlKDTYJN/dpQpxAgsSD9up2RqKuhwi1S4ZtfGJC BLbOeoO9dK9n6c1WGMn3mwDMIfiofHpVUEnYOT6DyBErmA2tIA3kLYRLnoUIcK/K+1LQ 5cog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Nob7h68kGshh4P/nBU3wEXQ9/ERoRlorm02urb50vm0=; b=neL87h6MpPGNQFOV1mRCCfv8QLdgs3LmzBtfxkSu1UOAcdyrJo3MYkGt2jjhJfWna0 KDoQU6Rn1I6aKTCt9AGTwsac1yrc977qkvJFBiXsOo8LjlLpHSH1SwwLpZ8WyWrZ1uTX GcQ3uU4E4HRAmnlHzdKpXIrTkCDWL2MJ3gWYymg/L3KXWk6FhYZQ/naIkbtn5zoRocM3 MafUMJdSCsEAQUfxRB756rHSKuW5SurlpUT4qpMtPUovQYZR6AXLsPyKRNPVySRrH6IC /FptFWq95NDBWDY6/79zn5CEVLON7PKSyped0Dk0UY/8caDJFeHeCYtoLcWKgopEk568 +W2A==
X-Gm-Message-State: AOUpUlGJ7QyfcGAm+upHgG17vXpII7K7X8KNkDUeP26ijD1XWbiAu9gY mvpIaWFKA2BsOYzz57JIl3GVkg7p
X-Google-Smtp-Source: AAOMgpfZTyMV+4lzjcQcM33JEpsdn+VqfZrdhT8gK3JmA/XBFUaBuj0VLbPxf9u2cquv5C1/u+c2YQ==
X-Received: by 2002:a62:640b:: with SMTP id y11-v6mr2832017pfb.204.1531872804215; Tue, 17 Jul 2018 17:13:24 -0700 (PDT)
Received: from Arrcus-Ahmeds-MacBook-Pro.local ([75.8.210.205]) by smtp.gmail.com with ESMTPSA id x2-v6sm7631455pfi.166.2018.07.17.17.13.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 17:13:23 -0700 (PDT)
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa
To: stephane.litkowski@orange.com, Alexander Vainshtein <Alexander.Vainshtein@ecitele.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>
References: <1e42030f-3d68-fca3-500c-95ab7303e7cd@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> <DB5PR0301MB1909BB6FDB84AFFA40E241B99D5E0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <6002_1531727222_5B4C4D76_6002_161_1_2d5d8d94-bd84-4972-9c65-7cbe9c744b32@OPEXCLILM7E.corporate.adroot.infra.ftgroup> <DB5PR0301MB1909C00E6F102C8100023C2F9D5D0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <2357_1531812544_5B4D9AC0_2357_492_1_003e367a-343d-4f15-95b2-6012851c1a31@OPEXCLILM6C.corporate.adroot.infra.ftgroup>
From: Ahmed Bashandy <abashandy.ietf@gmail.com>
Message-ID: <b0cb3699-c391-67fe-1e94-1e7d5b083528@gmail.com>
Date: Tue, 17 Jul 2018 17:13:22 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <2357_1531812544_5B4D9AC0_2357_492_1_003e367a-343d-4f15-95b2-6012851c1a31@OPEXCLILM6C.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------3DE1B31EE36B87E67AACCB64"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/S6uOuuSevcGgMrLhWHStSJDjdhQ>
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: Wed, 18 Jul 2018 00:13:32 -0000

I think the discussion is quite fruiteful and we are making very good 
progress
I will edit the draft to accommodate the suggested changes
Many thanks for the input :):):)

Ahmed



On 7/17/18 12:29 AM, stephane.litkowski@orange.com wrote:
>
> Agree
>
> *From:*Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
> *Sent:* Monday, July 16, 2018 10:58
> *To:* LITKOWSKI Stephane OBS/OINIS
> *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; 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 promot response.
>
> It wiuld be nice to see this in the draft.
>
> Thumb typed by Sasha Vainshtein
>
> ------------------------------------------------------------------------
>
> *From:*stephane.litkowski@orange.com <stephane.litkowski@orange.com>;
> *Sent:* Monday, July 16, 2018 10:46:56 AM
> *To:* Alexander Vainshtein
> *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; DECRAENE Bruno IMT/OLN
> *Subject:* RE: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> Hi,
>
> > 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?
>
> Exactly !
>
> Brgds,
>
> Stephane
>
> *From:*Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
> *Sent:* Sunday, July 15, 2018 10:01
> *To:* LITKOWSKI Stephane OBS/OINIS
> *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; 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 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.
> ___________________________________________________________________________
>
> _________________________________________________________________________________________________________________________
> 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.