RE: Is TI-LFA compatible with the default SR algorithm?

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 14 June 2018 12:47 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 5F5D3130F53; Thu, 14 Jun 2018 05:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.564
X-Spam-Level:
X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.795, 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=ham 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 EJIVWbAFR86h; Thu, 14 Jun 2018 05:47:49 -0700 (PDT)
Received: from mail3.bemta25.messagelabs.com (mail3.bemta25.messagelabs.com [195.245.230.147]) (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 7DDD513113B; Thu, 14 Jun 2018 05:47:48 -0700 (PDT)
Received: from [46.226.53.53] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-c.eu-west-1.aws.symcld.net id 1E/39-12747-2F3622B5; Thu, 14 Jun 2018 12:47:46 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHJsWRWlGSWpSXmKPExsViougQq/spWSn aYPodKYuuly/YLD71vGCxuPDmN7PF8Qu/GS2+7n3IanHqQaIDm8fOWXfZPZYs+cnk0fLsJFsA cxRrZl5SfkUCa0bv17XMBXe3MlacPtnJ2MC4fxFjFyMXB4vAImaJGzMnsIE4QgJTmSRWPHrBA uE8ZpTYsLGZuYuRk4NNwFZi0+q7bCC2iICuxJpfr8E6mAU2MUusOX4ZLCEs4CDx62YvC0SRo8 T03gtMELaTxJXdKxlBbBYBVYkjF6+wg9i8AgkSc7dcZIfY1sskserAN7AEJ9C2Myuvgw1lFBC T+H5qDdggZgFxiVtP5oPZEgICEkv2nGeGsEUlXj7+xwpRnyRx/+lCRoi4osSMe3PYIWxZiUvz u8GelhDYxiRxov8yC0TCUOL4yv1AgziAbGWJLS9iIcK+EgvvguwFqT/LKLH24jpWiISOxIzGf qjF+RIbFj+CWlYtsePsA6iZchKreh+yQDTvZ5bY9mQnVJGMxJT9N5ghEsfYJA68X8I0gVF3Fp LvIOw8iZ3t91hngYNJUOLkzCcsEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjeVJRZnp GSW5iZo6uoYGBrqGhka6RgbGuhZFeYpVusl5qqW55anGJrqFeYnmxXnFlbnJOil5easkmRmDK YwCCHYxXviUfYpTkYFIS5VW4qhgtxJeUn1KZkVicEV9UmpNafIhRhoNDSYJ3QZJStJBgUWp6a kVaZg4w+cKkJTh4lER4t4KkeYsLEnOLM9MhUqcY7TkOvZ/Sw8xxDkwe+gAi/93c38ssxJKXn5 cqJc67CKRNAKQtozQPbigsW1xilJUS5mUEOlOIpyC1KDezBFX+FaM4B6OSMO9vkCk8mXklcLt fAZ3FBHTW0aMKIGeVJCKkpBoYlTf7x2lq3F3z4ImX9mNG5ZdGf/+JyRckBy35F3rr1KUNJXMs 5A8wrmLeMnmm+GIxpbwXD6x2ndBhZdjbHyNzILdsLfc3ka1nXnctMbD+qudesOjssznPWKfan DF2d3ngt5vRnld+Ck/VVS2dDqOI+kdPTh2KlZ1z50q4aoPyvblNwuXxr942K7EUZyQaajEXFS cCAD7GxJcRBAAA
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-22.tower-305.messagelabs.com!1528980462!2491518!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 17775 invoked from network); 14 Jun 2018 12:47:45 -0000
Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-22.tower-305.messagelabs.com with AES256-SHA256 encrypted SMTP; 14 Jun 2018 12:47:45 -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=5jrWnX0aekKewHsN1NOckBg/1BlRGyBHdH/cBww6PCk=; b=hQY/JOHXsOGtPV3Kr8UkmODfI/VXKzwJNvv1mP7mRcwoAv7D13W7O3bZN0j1dlmknMH704Z41VF6Iy2sKvOY6GiGV72sXtyGSByJcwNy+Or22cn0pyD5inTaXTIVyZWhpA2wWUPBJBZ7YxYbXc97sUj0DggqYdAYbUK4FiUNqWM=
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Thu, 14 Jun 2018 12:47:40 +0000
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::d461:c56e:7404:d5b1]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::d461:c56e:7404:d5b1%6]) with mapi id 15.20.0863.016; Thu, 14 Jun 2018 12:47:40 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
CC: Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, "draft-ietf-spring-segment-routing.authors@ietf.org" <draft-ietf-spring-segment-routing.authors@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "draft-bashandy-rtgwg-segment-routing-ti-lfa.authors@ietf.org" <draft-bashandy-rtgwg-segment-routing-ti-lfa.authors@ietf.org>
Subject: RE: Is TI-LFA compatible with the default SR algorithm?
Thread-Topic: Is TI-LFA compatible with the default SR algorithm?
Thread-Index: AdQDJQBEzlZGSBhRThelBw/PgQXs7AAqTYjAAANYgIAAAIsZMA==
Date: Thu, 14 Jun 2018 12:47:40 +0000
Message-ID: <DB5PR0301MB19095F3E3FF97B3717AF01B69D7D0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
References: <DB5PR0301MB1909F44C6E7D9311B0FDA0C99D7E0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <1113_1528973791_5B2249DF_1113_378_1_9E32478DFA9976438E7A22F69B08FF924B1C4116@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <02d22e1d-0f94-2c42-cb4d-62db0af9996f@gmail.com>
In-Reply-To: <02d22e1d-0f94-2c42-cb4d-62db0af9996f@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; DB5PR0301MB1909; 7:L1yQw7ahDfeklOTV2mxnr5PK2IKjbkSrRtmlGcdBbsqxhOjsQSKIPf7d3THeMbtR5/BfZvVSPfnCRVHWqLK25ZVA115I+rcxGuqGl6ZHDKzEDcZn5OMPby96IQPtZbKClAIJpmum6vquQQ9t+7YhmGVAg21BDeJTRb5PE4LtdHgohDxtASfg1zPyI16/rpRBYzC9SvyBQkiNUXaX8moyhMnds4l69sGTLTrAGY1Yt2P8ZcesOoZMzbNYzsqQ9qyU
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 202c8bb5-93ea-4f13-0d42-08d5d1f503de
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB1909;
x-ms-traffictypediagnostic: DB5PR0301MB1909:
x-microsoft-antispam-prvs: <DB5PR0301MB19093C5A54BE12127AB9DCAD9D7D0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(18271650672692)(21748063052155)(279101305709854);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DB5PR0301MB1909; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB1909;
x-forefront-prvs: 0703B549E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(39380400002)(346002)(366004)(396003)(199004)(51874003)(189003)(53754006)(252514010)(25786009)(26005)(53936002)(33656002)(236005)(55016002)(11346002)(6306002)(3660700001)(2906002)(68736007)(5250100002)(186003)(6436002)(74316002)(7696005)(54906003)(54896002)(99286004)(6916009)(9686003)(39060400002)(6246003)(6506007)(446003)(53546011)(2900100001)(3280700002)(14454004)(8936002)(86362001)(316002)(72206003)(3846002)(790700001)(5660300001)(606006)(81156014)(486006)(81166006)(4326008)(478600001)(476003)(6116002)(105586002)(7736002)(66066001)(106356001)(102836004)(5890100001)(97736004)(229853002)(76176011)(59450400001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB1909; 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: LctOE2FD4aJMoktMwigetUcN1dELlyhE45C9Jd1G/c+CxtzoKvQplnxHUhmshN+gemnyHCaDEnbPy3LphJRbEGFB05dGIrl4KKrVANjpoGG9bKILNeXslbQ5GvxuansSxVAGH0QybHnBWsOLrMwsBA1nNX5Ckgw9m+MCeA7eNYhtSIz8sNL2BlYU4b7Cak1g
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB19095F3E3FF97B3717AF01B69D7D0DB5PR0301MB1909_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 202c8bb5-93ea-4f13-0d42-08d5d1f503de
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2018 12:47:40.3729 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB1909
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/3BidVIOVoJz8s2Ra1v1xq28poWU>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.26
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, 14 Jun 2018 12:47:55 -0000

Stewart,
Lots of thanks for a prompt and highly meaningful response.

Regards,
Sasha

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

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Thursday, June 14, 2018 3:31 PM
To: stephane.litkowski@orange.com; Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>om>; draft-bashandy-rtgwg-segment-routing-ti-lfa.authors@ietf.org
Cc: Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>om>; draft-ietf-spring-segment-routing.authors@ietf.org; spring@ietf.org; rtgwg@ietf.org
Subject: Re: Is TI-LFA compatible with the default SR algorithm?


RFC5714 was written when we were focused on routing in base along normal Dijkstra shortest paths.

As policy and flexible algorithms become prevalent we need to specify that any RFC5714 action is compliant to the policies and intended algorithms along the entirety of its path.

We need to think this through carefully, but that may mean that in a network where any of these enhanced routing methods are deployed, ALL routers doing FRR need to validate the safety of the packet path. There may be more computationally efficient ways to do this, but worse case looks like needing to precompute the full path to all destinations reachable via the failure including applying the policy and algorithms installed on all of those routers. What I am unclear of is how we find that policy to do that.

Maybe I am being overly pessimistic here, but Sasha makes an interesting observation that we need to think through very carefully.

- Stewart

On 14/06/2018 11:56, stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> wrote:
Hi Sasha,

Could you elaborate on :" I strongly suspect that it is not so, and that these mechanisms are only compatible with the Strict-SPF. (Actually, I can provide an example that confirms this suspicion.)" ?

Thanks,


From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, June 13, 2018 17:00
To: draft-bashandy-rtgwg-segment-routing-ti-lfa.authors@ietf.org<mailto:draft-bashandy-rtgwg-segment-routing-ti-lfa.authors@ietf.org>
Cc: Stewart Bryant; Michael Gorokhovsky; draft-ietf-spring-segment-routing.authors@ietf.org<mailto:draft-ietf-spring-segment-routing.authors@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: [spring] Is TI-LFA compatible with the default SR algorithm?

Hi all,
I have looked up Section 3.1.1 "Prefix-SID Algorithm" of the Segment Routing Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> draft (already In the RFC Editor queue) and found there the following statement (the relevant part is highlighted):

This document defines two algorithms:

   o  "Shortest Path": this algorithm is the default behavior.  The
      packet is forwarded along the well-known ECMP-aware SPF algorithm
      employed by the IGPs.  However it is explicitly allowed for a
      midpoint to implement another forwarding based on local policy.
      The "Shortest Path" algorithm is in fact the default and current
      behavior of most of the networks where local policies may override
      the SPF decision.

   o  "Strict Shortest Path (Strict-SPF)": This algorithm mandates that
      the packet is forwarded according to ECMP-aware SPF algorithm and
      instructs any router in the path to ignore any possible local
      policy overriding the SPF decision.  The SID advertised with
      Strict-SPF algorithm ensures that the path the packet is going to
      take is the expected, and not altered, SPF path.  Note that Fast
      Reroute (FRR) [RFC5714<https://tools.ietf.org/html/rfc5714>] mechanisms are still compliant with the
      Strict Shortest Path.  In other words, a packet received with a
      Strict-SPF SID may be rerouted through a FRR mechanism.

At the same time, the TI-LFA draft<https://tools.ietf..org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-04> discusses protection of active Prefix-SIDs (e.g., in Section 3 that discusses P-Space and Q-space) but, to the best of my understanding, does not mention algorithms that form the context of these SIDs.

My question to the authors of the TI-LFA draft is:

Are the mechanisms defined in the draft (and examples discussed in Section 4) applicable to Prefix-SIDs associated with the default forwarding algorithm as defined in the Segment Routing Architecture draft?

I strongly suspect that it is not so, and that these mechanisms are only compatible with the Strict-SPF. (Actually, I can provide an example that confirms this suspicion.)

Do I miss something substantial here?

Regards, and lots of thanks in advance,
Sasha

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


___________________________________________________________________________

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