Is TI-LFA compatible with the default SR algorithm?

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Wed, 13 June 2018 14:59 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 37199130E37; Wed, 13 Jun 2018 07:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 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] 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 ykTfYOuoDODI; Wed, 13 Jun 2018 07:59:52 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.1]) (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 33AC8130E36; Wed, 13 Jun 2018 07:59:45 -0700 (PDT)
Received: from [85.158.142.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-a.eu-central-1.aws.symcld.net id 3C/16-16147-F51312B5; Wed, 13 Jun 2018 14:59:43 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJsWRWlGSWpSXmKPExsViovlDRTfOUDH a4PY1E4uuly/YLD71vGCxuPDmN7PF8Qu/GS1OPUh0YPXYOesuu8eSJT+ZApiiWDPzkvIrElgz Dq6xLtgUVvH9/nO2Bsb7vl2MXBwsAouYJZZPeM8E4ggJTGaSeHf6GlsXIyeQ85hR4sqFEBCbT cBWYtPqu2wgRSICTYwSF1puM4IkmAVmM0n8XS4GYgsL2Eh0fLgK1iwi4CgxvfcC0FQOIFtPYn NnLEiYRUBV4trkLewgNq9AgkT7ySlMIDajgJjE91NrmCBGikvcejIfzJYQEJBYsuc8M4QtKvH y8T9WCFtRYsa9OewQtqzEpfndjBD2FiaJy1vlIGxDieMr9zODnCAhoCyx5UUshOkr8W1BOcgn EgKnGSXOTG6EatWSWD7xNDvEOUkS958uhIpnSzQu3wd1TrTE/gP3odbKSazqfcgCMWg3s0TPi 19QCRmJTxduQCVms0m09W9jggRossSJOZ+hEsDA/XTkHNsERu1ZSJ6GsPMkLuz6xzwLHEiCEi dnPmGBiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxgtkooy0zNKchMzc3QNDQx0DQ2NdQ1 1zYz1Eqt0E/VSS3WTU/NKihKBknqJ5cV6xZW5yTkpenmpJZsYgSmNAQh2MP78mXKIUZKDSUmU 12+CQrQQX1J+SmVGYnFGfFFpTmrxIUYZDg4lCd5H+orRQoJFqempFWmZOcDkCpOW4OBREuFlB 0nzFhck5hZnpkOkTjEacxx6P6WHmeMciBRiycvPS5US590EUioAUppRmgc3CJb0LzHKSgnzMg KdJsRTkFqUm1mCKv+KUZyDUUmY9wTIFJ7MvBK4fa+ATmECOuXoUQWQU0oSEVJSDYw7rvWcsE5 S/MoXvcr+8dna7yHnmD7pnXjl8cQ17tYVxz1LklumTVXOOLT333WXhH8+jSqpMpdqGS4uMNjp 7C3l/SH0W+/1D2JGtnN11QwmRqmePlV/WWOyCOP2O+8yqzd4VJd5Gxm4Bb7/q6j0+bjgipkTp K9s7Plcs+KL4uGl/Artol99nMyUWIozEg21mIuKEwEq96+J9QMAAA==
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-26.tower-228.messagelabs.com!1528901979!2169611!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 10771 invoked from network); 13 Jun 2018 14:59:41 -0000
Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-26.tower-228.messagelabs.com with AES256-SHA256 encrypted SMTP; 13 Jun 2018 14:59:41 -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=9sVdgZH4JMlHPo192IuHpPk+otmyNeKpdEp3XHKK+uk=; b=jONp+x8kEIMesaBH8y3gZEzh4XUKeoFMP/EZSaerNnmFOA5t1VSpUOX328c5n85sKz+wGxECSPEqSUx+6ChFb501ahpETDMu9pB2Qj1S6m8RnfZ0Dx/nFapkK4RU7gtfgV41J54Ed2EM6KpqFn5ialW/n8oKglC28Z+nSpRDMQY=
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5SPR8PMB091.eurprd03.prod.outlook.com (10.166.170.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.14; Wed, 13 Jun 2018 14:59:37 +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; Wed, 13 Jun 2018 14:59:36 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "draft-bashandy-rtgwg-segment-routing-ti-lfa.authors@ietf.org" <draft-bashandy-rtgwg-segment-routing-ti-lfa.authors@ietf.org>
CC: "rtgwg@ietf.org" <rtgwg@ietf.org>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, Stewart Bryant <stewart.bryant@gmail.com>, "draft-ietf-spring-segment-routing.authors@ietf.org" <draft-ietf-spring-segment-routing.authors@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Subject: Is TI-LFA compatible with the default SR algorithm?
Thread-Topic: Is TI-LFA compatible with the default SR algorithm?
Thread-Index: AdQDJQBEzlZGSBhRThelBw/PgQXs7A==
Date: Wed, 13 Jun 2018 14:59:36 +0000
Message-ID: <DB5PR0301MB1909F44C6E7D9311B0FDA0C99D7E0@DB5PR0301MB1909.eurprd03.prod.outlook.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; DB5SPR8PMB091; 7:1e9dVkU4FsE4d05JpaR8Phw6uIUgTfjNCr636IeW4I80lwI22+7i5iBYzMYplh4WnZfcFXZE1AQCp6PNmF/DlsANmYQk3ovt1MSPv2HRuCh+j8yW18BE2eI1WS6VF9tgl2o8S7PlES0H4I2A8lb8qX1/q6Q+NRlLh5DEV/Ac6kQVQb5wXUG0Dj7BcR9R41cEZVQjPcUU0LA87jmOxlXq+pu1aj3tVgO8inACgG5x6od43HviSDujt18/pDBzclad
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-ms-office365-filtering-ht: Tenant
X-MS-Office365-Filtering-Correlation-Id: d9601453-a15a-451f-f028-08d5d13e47be
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB5SPR8PMB091;
x-ms-traffictypediagnostic: DB5SPR8PMB091:
x-microsoft-antispam-prvs: <DB5SPR8PMB091B85C09AC7CDF439E5BFD9D7E0@DB5SPR8PMB091.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155)(279101305709854);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DB5SPR8PMB091; BCL:0; PCL:0; RULEID:; SRVR:DB5SPR8PMB091;
x-forefront-prvs: 07025866F6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(346002)(376002)(39380400002)(51874003)(252514010)(189003)(53754006)(199004)(486006)(33656002)(102836004)(14454004)(6916009)(2906002)(606006)(2351001)(86362001)(5630700001)(25786009)(186003)(7696005)(105586002)(39060400002)(476003)(106356001)(4326008)(6506007)(26005)(3660700001)(68736007)(236005)(3846002)(97736004)(6116002)(3280700002)(790700001)(54906003)(316002)(54896002)(6436002)(9686003)(6306002)(7736002)(55016002)(66066001)(2501003)(5250100002)(99286004)(5660300001)(5640700003)(8936002)(74316002)(81166006)(81156014)(8676002)(2900100001)(72206003)(53936002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5SPR8PMB091; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: HZM3yCc4/t0M4/U9z3YvH6t+hlqQqwyxpch3opb2F7ij7N41anHl/mOGm/oeP0tTtipnIypl0q8q/fwuF/8bIhDAzRe8dKuCFlzvNksDJkdWgzjTi7eKbu7recHVL16GMoxHN4eDIxg1e4FrSJsk5D+c87MBPi8hPmCJDeJ1MVZfrl/WoP7yrdHNb+3NMVQh
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB1909F44C6E7D9311B0FDA0C99D7E0DB5PR0301MB1909_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d9601453-a15a-451f-f028-08d5d13e47be
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2018 14:59:36.3695 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5SPR8PMB091
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/jVgucGYICNhP6pblI0g4VcsdDmA>
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: Wed, 13 Jun 2018 14:59:56 -0000

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


___________________________________________________________________________

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