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

Stewart Bryant <> Thu, 14 June 2018 12:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8086131062; Thu, 14 Jun 2018 05:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SVWvLql9S01o; Thu, 14 Jun 2018 05:31:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 078F8131144; Thu, 14 Jun 2018 05:31:23 -0700 (PDT)
Received: by with SMTP id n5-v6so11623207wmc.5; Thu, 14 Jun 2018 05:31:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=org+hUma2bw0anacy9/NcevNmDZMYBsQIvhUw1bpJqI=; b=QIEFq9bwKOlLqDvokuN7VhwnAODTsbKVT9Y0/PVnGE7XgZnP2tYk/JOtQoLy6I59N7 jGAAjY/OgyTXNlk+hUuHoMnHuYJsU1srv5MdtACVDg3Op7C5dNG6hP5dw2RGsauXcCPM 5M/1WaGBrhD/gVyfTbuHG/sVITnXHWf86TDbZOL2B0D+u0leSmspLI26qXIdDaRCZjtt OmGmbiYn0cXaR7rxmqbgwdXlAGMeKW2Tsn98evCQpxfCMAh1+zzA2CU/OwnFumznXqw9 64nq1RnQ4xBT/bD0I7XuAjWc9dK1DRL3mKnc+RMvj3pyJFxFdaU1TjMcFKODFdKD7Q4w ZUiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=org+hUma2bw0anacy9/NcevNmDZMYBsQIvhUw1bpJqI=; b=gNLm7tGWr8fzXWG1eVNrISoctEMjtCoQyH979iIn6NyalPdRx/xvNPBUhlwgCSNhER c9kDHqN0do6IHpEpcC3mjzhOhBEDuKKroZDRp62pd1g9TH1bUb7TyIPeZrGWxrXqO19p P+HebqH1Hle6zMNt10RQFdr+jOrc+ozKVi4pQbrvsbg0mbOIV2zOsFc3tBHreDeEP+wZ PXzgJQlOJMgE730clzOKh7LfjVZGRI76MrX89tkjsy5pN0xno08kFDv4S+AHpmBFP+a3 mlOBdy4gCBDHq62p8jGQt60w8D9oLFBeWIAbvML9ON+k7tpSwy0p0KliKH2uCzZz9LPY w96w==
X-Gm-Message-State: APt69E3xEz0nF6RDkrJ1wJqiL17j7Qq5ZBC49wbQtPPeABYG2WkhMfAs r5wpUspkUtvM6P6b4qT1MYfQOIaG
X-Google-Smtp-Source: ADUXVKL7iZVcfRjuczc8v1oAJujEJIxlpgeaWZoDBVcW3mMd1UEDqKXqQ21dw9Cx4UKLIsUJUqVgHg==
X-Received: by 2002:a1c:d9cb:: with SMTP id q194-v6mr1688887wmg.91.1528979481301; Thu, 14 Jun 2018 05:31:21 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id f133-v6sm5816595wme.42.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jun 2018 05:31:20 -0700 (PDT)
Subject: Re: Is TI-LFA compatible with the default SR algorithm?
To:, Alexander Vainshtein <>, "" <>
Cc: Michael Gorokhovsky <>, "" <>, "" <>, "" <>
References: <> <1113_1528973791_5B2249DF_1113_378_1_9E32478DFA9976438E7A22F69B08FF924B1C4116@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
From: Stewart Bryant <>
Message-ID: <>
Date: Thu, 14 Jun 2018 13:31:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <1113_1528973791_5B2249DF_1113_378_1_9E32478DFA9976438E7A22F69B08FF924B1C4116@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------80BABD0746FAEE466C5955B9"
Content-Language: en-GB
Archived-At: <>
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Jun 2018 12:31:27 -0000

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, 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 [] *On Behalf Of 
> *Alexander Vainshtein
> *Sent:* Wednesday, June 13, 2018 17:00
> *To:*
> *Cc:* Stewart Bryant; Michael Gorokhovsky; 
> *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 
> <> 
> 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 <>] 
> 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 
> <> 
> 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:
> ___________________________________________________________________________
> 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.