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. ___________________________________________________________________________
- RE: Is TI-LFA compatible with the default SR algo… Alexander Vainshtein
- Re: Is TI-LFA compatible with the default SR algo… Stewart Bryant
- RE: Is TI-LFA compatible with the default SR algo… Alexander Vainshtein
- RE: Is TI-LFA compatible with the default SR algo… Alexander Vainshtein
- Re: Is TI-LFA compatible with the default SR algo… Stewart Bryant
- RE: Is TI-LFA compatible with the default SR algo… stephane.litkowski
- Is TI-LFA compatible with the default SR algorith… Alexander Vainshtein