RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa
Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 12 July 2018 12:54 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 5861D130DDF; Thu, 12 Jul 2018 05:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.779
X-Spam-Level:
X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 5VWMRCvdPr4n; Thu, 12 Jul 2018 05:54:06 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.114]) (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 123C6130DDE; Thu, 12 Jul 2018 05:54:04 -0700 (PDT)
Received: from [85.158.142.193] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-b.eu-central-1.aws.symcld.net id 4A/DB-24101-A6F474B5; Thu, 12 Jul 2018 12:54:02 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLsWRWlGSWpSXmKPExsViIr2lQjfL3z3 a4Gg/j8XiNRIWP3bMYbb4sd7VYsM7EYtH6/sYLW6cn8xk0bSwidli/9rFzBYX3vxmtjj1INGB y2PNz3dMHjtn3WX3WLLkJ5PH9aar7B4tz06yeezeuIApgC2KNTMvKb8igTXj8b4jbAUrWlgrn m9wa2B885uli5GLg0VgEbNEy657jCCOkMAUJokrb25AOY8ZJW6tmcLUxcjJwSZgK7Fp9V02EF tEwFriwcT1bCBFzAL7mCXWrtgIViQskCaxfFYDI0RRusTsR0+YIGw/ia9vDzOD2CwCqhKv5t9 nBbF5BRIlWi5cZ4XYtoJdomvmHyYQh1Ogi1Hi8ZJusCpGATGJ76fWgE1iFhCXuPVkPpgtISAg sWTPeWYIW1Ti5eN/UPVJEvefLmSEiCtKzLg3hx3ClpW4NL8b7DcJge1MEv//NrJBJHQlPkydC jXIV2LL1WfAoOEAspUltryIhaj/yCgx794bqMU6Eku630LZBRJLt81ggyhazyjR2N4ItVlOYl XvQxaIxAFmib5Vk6ASMhIvHs9ihki8ZJNYdmwPywRG3VlI3oOw8yTefv0EZvMKCEqcnPmEZRb QVcwCmhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNFUlFmekZJbmJmjq6hgYGuoaGxrrmu ibleYpVukl5qqW5yal5JUSJQUi+xvFivuDI3OSdFLy+1ZBMjMGkyAMEOxv4/KYcYJTmYlER5p axco4X4kvJTKjMSizPii0pzUosPMcpwcChJ8C71c48WEixKTU+tSMvMAaZvmLQEB4+SCO8mkD RvcUFibnFmOkTqFKM3x5F7UyYxc1wAk/OOTgWSf96DyH3d04DkHRApxJKXn5cqJc67EGSEAMi IjNI8uAWwPHSJUVZKmJcR6GQhnoLUotzMElT5V4ziHIxKwrwzQKbwZOaVwN3xCuhEJqAT41Lc QE4sSURISTUwCkRwPy6TEf0jV/9QQir9vG/Tv3cVr9uq+/OFj3EKuCS/WPRb4/vxn6tuv3/vW MY8ZfGZ7NW5USvtq+3/V3B2NDQeaVx0SFW3wubW1zdHFKW/f96302btSnb7ORt+liXHvuU4ol Iu9NU2vn/7uZK1SwMn/FcIcXhY3cu6Ny7j7mt9+ycT2Bx/KbEUZyQaajEXFScCADqVNWg+BAA A
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-32.tower-238.messagelabs.com!1531400037!2763846!1
X-Originating-IP: [52.27.180.120]
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 23978 invoked from network); 12 Jul 2018 12:54:00 -0000
Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR02-HE1-obe.outbound.protection.outlook.com) (52.27.180.120) by server-32.tower-238.messagelabs.com with AES256-SHA256 encrypted SMTP; 12 Jul 2018 12:54:00 -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=GbXxD0/sQwcPXc94ODyx3MKuG/D7GakeIvPXI0AGNUU=; b=KzEblJVv4OwPauyNJmPOJMg+E+nDYyebObu6rTUXrIjSuLNDIzI6Phwsy+EUuTPAg0igdE+uzZBQaNSpUbQv3F334dRk5uJSqzJLmyDvd/2jJTa2aYicu/MFdsSzz36nwP5sAhHP6ptcuCPUMQMloByBE1bvcY/obu/M/mqkJDg=
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB1959.eurprd03.prod.outlook.com (10.167.227.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.17; Thu, 12 Jul 2018 12:53:54 +0000
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::6c62:c2c0:1d05:4e77]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::6c62:c2c0:1d05:4e77%2]) with mapi id 15.20.0952.017; Thu, 12 Jul 2018 12:53:54 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>
CC: "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>, "daniel.voyer@bell.ca" <daniel.voyer@bell.ca>, "rtgwg@ietf.org" <rtgwg@ietf.org>, Ahmed Bashandy <abashandy.ietf@gmail.com>, Robert Raszuk <robert@raszuk.net>, Chris Bowers <cbowers@juniper.net>, Stewart Bryant <stewart.bryant@gmail.com>
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: AQHT9sbRZr09Sx5RRE2SlwYEgLprKaSLVK0wgABYMmCAABKhgIAABexggAAJ0kA=
Date: Thu, 12 Jul 2018 12:53:54 +0000
Message-ID: <DB5PR0301MB190979EB351475C75165DBA49D590@DB5PR0301MB1909.eurprd03.prod.outlook.com>
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> <DB5PR0301MB1909F8E5DC28E25EBD506B4B9D590@DB5PR0301MB1909.eurprd03.prod.outlook.com> <17225_1531398886_5B474AE6_17225_383_13_53C29892C857584299CBF5D05346208A47AEA919@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <17225_1531398886_5B474AE6_17225_383_13_53C29892C857584299CBF5D05346208A47AEA919@OPEXCLILM21.corporate.adroot.infra.ftgroup>
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; DB5PR0301MB1959; 7:zSWGbAVXgPlel6WXVCHsQQbb/m4VQm81npfSAF9VfHm7tEz0MVBF9Zgh6Z4bUfmTKd1eSFc3n5gTf4Sx1nHVuEpnkpwRU1GWd0cYfRC48hKmxCI7xlhUrCcIUNRf3mT4FEeYS4kyF1z/Jgsynk5870b9dG0a0auonHAW1sOYnnoFuqQ9uqPbE4d9ZMw86gE7M8rr6PZq+1qXF4EdbRjjXrgXvXbUw3RzQxvKTdGAgJq+RalWXTP6josLZcPUIapT
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 6fc72d60-194d-4999-964f-08d5e7f68695
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB1959;
x-ms-traffictypediagnostic: DB5PR0301MB1959:
x-microsoft-antispam-prvs: <DB5PR0301MB19595F6FF8E7682EF49C41F79D590@DB5PR0301MB1959.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(226690903318834)(138986009662008)(223705240517415)(85827821059158)(18271650672692)(21748063052155)(279101305709854);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:DB5PR0301MB1959; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB1959;
x-forefront-prvs: 0731AA2DE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(366004)(346002)(376002)(136003)(199004)(189003)(51444003)(252514010)(256004)(236005)(105586002)(102836004)(81156014)(106356001)(6506007)(486006)(93886005)(2900100001)(53546011)(2906002)(11346002)(186003)(446003)(8676002)(26005)(790700001)(6116002)(476003)(3846002)(7416002)(72206003)(39060400002)(6246003)(478600001)(14454004)(316002)(81166006)(5660300001)(2351001)(53946003)(99286004)(76176011)(229853002)(8936002)(6306002)(54896002)(9686003)(55016002)(33656002)(6436002)(7696005)(5640700003)(54906003)(97736004)(25786009)(6916009)(7736002)(86362001)(5250100002)(68736007)(5630700001)(53936002)(5024004)(2501003)(14444005)(66066001)(4326008)(74316002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB1959; 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: hswtYvx2CZpx75tU8ZtKmwzVDoriHfjRwdrLp2y7FBIupqlis/gN3FlxmQPA6idRyFvrI7wG0SsdGZhPIoobudBgwES5Hp0Xek22A8TB8itbIzKxBodJxT2t2xRRs6nnGLsIqh139yq2FxaCXMkJgn7FPdPTLDLNUxW3eMUFVuMn2HvZDl2Tj2g2dWnf9vBAY4A5T2p1Z8QsMQ16pZHSFXrG8RAI183jvtTNbQeBIlWlHQ0pkaDjEFpziAPLPMBNuOfEoV2EHrwXazjU4R+hJpPZUCid9dAIzbwkWfV8WCA5e08Np/HLk+mgiZYcw+kHZEZQNJOr4tDwO9ItVRgRGSb+pOvm1DkgN/i0ckr8Z48=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB190979EB351475C75165DBA49D590DB5PR0301MB1909_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6fc72d60-194d-4999-964f-08d5e7f68695
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2018 12:53:54.6913 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB1959
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/KIwJLVoJufrmOidyD8xgF0Cd2S0>
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: Thu, 12 Jul 2018 12:54:10 -0000
Bruno, Again lots of thanks for a prompt response. I fully agree that the way to solve the scalability problem with RLFA is ‘to restrict yourself to the Q space of E with respect to the link S-E”. This is exactly what RFC 7490 says. But this is not what the TI-LFA says, IMHO, because it intersects the post-convergence path from the PLR to D with the Q-space of D for the failed link S-E. You can probably adjust that by saying that Q-space of E can be used as proxy for Q-space of D. However: - The draft does not say that - The chances of the post-convergence path to D intersecting Q-space of D look quite reasonable to me. But what are the chances of non-empty intersection between the post-convergence path to D and Q-space of another node? Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Thursday, July 12, 2018 3:35 PM To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org; daniel.voyer@bell.ca; rtgwg@ietf.org; Ahmed Bashandy <abashandy.ietf@gmail.com>; Robert Raszuk <robert@raszuk.net>; Chris Bowers <cbowers@juniper.net>; Stewart Bryant <stewart.bryant@gmail.com> Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa Sasha, Please see inline [Bruno] From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, July 12, 2018 1:59 PM To: DECRAENE Bruno IMT/OLN 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; Robert Raszuk; Chris Bowers; Stewart Bryant Subject: RE: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa Bruno, The other issue I’ve raised with regard to usage of post-convergence paths is scalability. The draft says (in section 3.2): We want to determine which nodes on the post-convergence path from the PLR to the destination D are in the Q-Space of destination D w.r.t. link S-F. This can be found by intersecting the post-convergence path to D, assuming the failure of S-F, with Q(D, S-F). My reading of this text says that Q(D, S-F) MUST be computed for each destination D that is affected by failure of link S-F (I am not aware of any other method – do I miss something?). And this is exactly what RFC 7490 warns against in Section 5.2.1: Note that the Q-space calculation could be conducted for each individual destination and a per-destination repair tunnel end point determined. However, this would, in the worst case, require an SPF computation per destination that is not currently considered to be scalable. “Currently” in 7490 presumably refers to 2015, but I am not aware of drastic improvements in the computational power of the CPUs of modern routers that allow computation of hundreds of reverse SPF computations following every topology change. Again, did I miss something? [Bruno] First, as you quoted, your comment applies to RLFA. And in general, the answer is to restrict yourself to the Q space of E with respect to the link S-E. Second, - if you limit yourself to link protection, especially in network with symmetric link cost, some shortcut may be found. One could say it’s an implementation issue. One could argue that the draft should at least describe one algo, while stating that this choice is non-normative. - if you want node/SRLG protection [RFC 8102] and/or LFA manageability [RFC7916] to pick an acceptable path, it’s not clear to me that the alternatives scale better. TI-LFA has the benefit of computing the alternate path in one easy step (1 SPF), leaving the computation cost to the minimization of the list of segments when needed (and this is rarely needed, especially for link protection). It’s not clear to me that computing 10s of RLFA and then trying to pick the “best” / an acceptable one (e.g. by computing a SPF rooted on the PQ of each candidate) is a better way. But we don’t even need to compare as this did not stop the publication of RFC 8102. Regards, --Bruno Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com> From: Alexander Vainshtein Sent: Thursday, July 12, 2018 2:26 PM To: 'bruno.decraene@orange.com' <bruno.decraene@orange.com<mailto:bruno.decraene@orange.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>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Chris Bowers <cbowers@juniper.net<mailto:cbowers@juniper.net>>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>> 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. ___________________________________________________________________________
- Re: Request for RTGWG Working Group adoption for … Stewart Bryant
- Re: Request for RTGWG Working Group adoption for … Stewart Bryant
- RE: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- Re: Request for RTGWG Working Group adoption for … Ahmed Bashandy
- Re: Request for RTGWG Working Group adoption for … Ahmed Bashandy
- Re: Request for RTGWG Working Group adoption for … Jeff Tantsura
- RE: Request for RTGWG Working Group adoption for … Chris Bowers
- Re: Request for RTGWG Working Group adoption for … Robert Raszuk
- RE: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- RE: Request for RTGWG Working Group adoption for … bruno.decraene
- RE: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- RE: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- RE: Request for RTGWG Working Group adoption for … bruno.decraene
- RE: Request for RTGWG Working Group adoption for … bruno.decraene
- RE: Request for RTGWG Working Group adoption for … stephane.litkowski
- RE: Request for RTGWG Working Group adoption for … stephane.litkowski
- RE: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- RE: Request for RTGWG Working Group adoption for … stephane.litkowski
- RE: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- Re: Request for RTGWG Working Group adoption for … Stewart Bryant
- RE: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- Re: Request for RTGWG Working Group adoption for … Stewart Bryant
- Re: Request for RTGWG Working Group adoption for … Stewart Bryant
- RE: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- RE: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- RE: Request for RTGWG Working Group adoption for … bruno.decraene
- RE: Request for RTGWG Working Group adoption for … stephane.litkowski
- RE: Request for RTGWG Working Group adoption for … stephane.litkowski
- Re: Request for RTGWG Working Group adoption for … Stewart Bryant
- Re: Request for RTGWG Working Group adoption for … Stewart Bryant
- Re: Request for RTGWG Working Group adoption for … Ahmed Bashandy
- Re: Request for RTGWG Working Group adoption for … Ahmed Bashandy
- RE: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- RE: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- RE: Request for RTGWG Working Group adoption for … stephane.litkowski
- Re: Request for RTGWG Working Group adoption for … Alexander Vainshtein
- RE: Request for RTGWG Working Group adoption for … stephane.litkowski
- Re: Request for RTGWG Working Group adoption for … Stewart Bryant
- Re: Request for RTGWG Working Group adoption for … Ahmed Bashandy