Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft

Peter Psenak <> Fri, 01 May 2020 09:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0039F3A0D9C; Fri, 1 May 2020 02:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fwOflWup98Uv; Fri, 1 May 2020 02:57:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D2A63A0D99; Fri, 1 May 2020 02:57:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4966; q=dns/txt; s=iport; t=1588327044; x=1589536644; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=rQajhTCLYp4vMNd5L68a9oThtXY7WcuEq7cUpcwjzQk=; b=bFo95USqzEPtTGjNnUhkHKVxjEBpb2bLhRYhiOX27GZy8j8idV+KbPWH /CTXpB8JavUqqMxSF1uPMNl8rMMgoQY4hKPx3dzASVu1zo1DsAf+ZjWpS MIqSt5A5IcuUyJ65ipyOU7j/RbK0zKpO4FBGFewf8WZUkroF23HMTgszV 8=;
X-IronPort-AV: E=Sophos;i="5.73,339,1583193600"; d="scan'208";a="25823126"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 May 2020 09:57:22 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id 0419vL5F030028; Fri, 1 May 2020 09:57:21 GMT
To: Alexander Vainshtein <>, "" <>, "" <>, "" <>, "" <>
Cc: "" <>, "" <>, "" <>, Michael Gorokhovsky <>, Ron Sdayoor <>
References: <>
From: Peter Psenak <>
Message-ID: <>
Date: Fri, 1 May 2020 11:57:21 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 May 2020 09:57:29 -0000


On 30/04/2020 17:21, Alexander Vainshtein wrote:
> Hi all,
> I have a question about the proposed usage of SRLG in the IGP Flexible 
> Algorithm <> draft.
> This usage is defined Section 12 of the draft with the reference to the 
> SRLG exclude rule as following:
>        2.  Check if any exclude SRLG rule is part of the Flex-Algorithm
>        definition.  If such exclude rule exists, check if the link is
>        part of any SRLG that is also part of the SRLG exclude rule.  If
>        the link is part of such SRLG, the link MUST be pruned from the
>        computation.
> This looks effectively undistinguishable from the usage of the exclude 
> Admin groups rule as described in the same Section 12 of the draft:
>        1.  Check if any exclude rule is part of the Flex-Algorithm
>        definition.  If such exclude rule exists, check if any color that
>        is part of the exclude rule is also set on the link.  If such a
>        color is set, the link MUST be pruned from the computation.
>  From my POV, with such a definition, there is no need in the dedicated 
> “Exclude SRLG” rule as part of the specification of the Flexible 
> Algorithm, since such the SRLG Exclude rule can be replaced with a 
> matching Exclude All rule  using Admin groups.

there is one very important point. Maintaining the affinities is 
operationally complex. Some networks have already deployed SRLGs. If 
SRLG exclude with flex-algo gives people what they want, asking them to 
deploy affinities would be redundant. That's the main point.

Simple use case:

I have two SRLGs in the network. For some specific traffic I want to 
send the data via two independent streams. I want to avoid single SRLG 
failure to affect both streams. I define two flex-algos, each one 
excluding one SRLG. No need to define extra affinities. This is btw not 
an academical example, this has been requested by real users.

> I also think that such a usage of SRLG does not fit the needs of the 
> <> 
> draft that considers an SRLG as a resource that fails when any of the 
> links/nodes comprising it fails. E.g., it says in Section 2:
>     The Point of Local Repair (PLR), S, needs to find a node Q (a repair
>     node) that is capable of safely forwarding the traffic to a
>     destination D affected by the failure of the protected link L, a set
>     of links including L (SRLG), or the node F itself.  The PLR also
>     needs to find a way to reach Q without being affected by the
>     convergence state of the nodes over the paths it wants to use to
>     reach Q: the PLR needs a loop-free path to reach Q.

I see no conflict between the LFA draft and flex-algo one. If you do, 
please be precise where the conflict is.

> To me this suggests that SRLGs are only relevant when computing backup 
> paths for specific failures, e.g., an LFA for failure of a link hat 
> belongs to a specific SRLG must be computed in the topology from which 
> all the links belonging to the same SRLG are pruned. This understanding 
> matches RFC 4090 that states in Section 6.2 “Procedures for Backup Path 
> Computation”:

SRLG is a mechanism to express fate share. I see no reason why SRLG 
could not be used for other than LFA purposes.


>        - The backup LSP cannot traverse the downstream node and/or link
>          whose failure is being protected against.  Note that if the PLR
>          is the penultimate hop, node protection is not possible, and
>          only the downstream link can be avoided. The backup path may be
>          computed to be SRLG disjoint from the downstream node and/or
>          link being avoided.
> If SRLGs are only relevant for computation of backup paths, it is not 
> clear to me if they should be part of the definition of a specific 
> Flexible Algorithm.
> What, if anything, did I miss?
> 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.
> ___________________________________________________________________________