Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding

Peter Psenak <ppsenak@cisco.com> Tue, 12 March 2019 11:09 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3079B127968 for <lsr@ietfa.amsl.com>; Tue, 12 Mar 2019 04:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 frBNwasgSZd5 for <lsr@ietfa.amsl.com>; Tue, 12 Mar 2019 04:09:48 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB883126E5C for <lsr@ietf.org>; Tue, 12 Mar 2019 04:09:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4765; q=dns/txt; s=iport; t=1552388988; x=1553598588; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=f1PP6lOL7QmJ5wn5msivAIFh52oq4WZ/Yn6DdHaGZNg=; b=Ie3+RiW5CJFhDB3PpMWlKV1k/IIyz5ZEO6kaSeODd3ebJimjm5ca361C /NUqMtNzwLR/EgxLB1Y5AX5OMLiuMsqAARCiIUSznzs2XcoF1PMfXmADY pyWxrSNY1YOaftNrhW6dt1LREw5Ck1ej06nD2smcqmJPHMjtJJbTadRNz 8=;
X-IronPort-AV: E=Sophos;i="5.58,471,1544486400"; d="scan'208";a="10691281"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2019 11:09:46 +0000
Received: from [10.147.24.38] ([10.147.24.38]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x2CB9jO9003284; Tue, 12 Mar 2019 11:09:45 GMT
To: Robert Raszuk <robert@raszuk.net>, Jeff Tantsura <jefftant.ietf@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
References: <CAOj+MMHwJW6=SQ+_VSTUqwOWDv=+vkg-TTncA5PEczkAn-bdUg@mail.gmail.com> <e0901e21-fdfa-b14f-7abe-f80bfd4c5016@cisco.com> <CAOj+MMEP_08FxkcOXBAyuH_Ho0Tsh9KwTkct6S47hs29_Y=raw@mail.gmail.com>
Cc: lsr@ietf.org
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <0e8b3753-7263-900d-7d6c-e103c25b5689@cisco.com>
Date: Tue, 12 Mar 2019 12:09:45 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAOj+MMEP_08FxkcOXBAyuH_Ho0Tsh9KwTkct6S47hs29_Y=raw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.147.24.38, [10.147.24.38]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/20x40U0XTYgYWf5SwYphORzyqKQ>
Subject: Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 11:09:50 -0000

Robert,

On 12/03/2019 10:42 , Robert Raszuk wrote:
> Jeff & Les,
>
> The suggested use of "LFA" was completely unrelated to ECMP or to data
> plane. I realize that some people may just think of LFA in its original
> meaning :).
>
> It was just a hint how an edge node can determine which links are
> "towards" the disconnected nodes and which of his local links would be
> going in the opposite direction just by running SPF virtually putting as
> initial node your adjacent FT nodes. No more no less.
>
> Per section 6.7.9 it seems that implementation is already mandated ot
> find such links towards the disconnected part of the network, but it
> does not seems to indicate how. Maybe it is just a matter of local smart
> implementation.
>
> Peter,
>
> If I am reading your reply and section 6.7.5 it seems to indicate that
> you would not start adding any link to FT as long as you have at least
> one there still being alive. You just advertise new LSA/LSP over still
> active flooding link indicating change in topology and sit and wait till
> you get a new FT ?
>
> Well perhaps wrong, but my understanding was that if you have two active
> FT links you start adding new ones (and request your peer over that link
> to do so too) just after you loose one as a temporary patch till you get
> a new graph.
>
> So what happens when you loose one link and you do not get a new FT for
> time t. How long do you wait ?

when the local link that is on FT is lost, the FT is recalculated, 
either locally, or centrally and flooded. That should provide 
bi-connectivity again, if available.

Temporary flooding is only triggered when node itself or its neighbor 
becomes isolated.

thanks,
Peter

>
> Many thx,
> R.
>
>
>
> On Tue, Mar 12, 2019 at 7:45 AM Peter Psenak <ppsenak@cisco.com
> <mailto:ppsenak@cisco.com>> wrote:
>
>     Hi Robert,
>
>     On 11/03/2019 22:28 , Robert Raszuk wrote:
>     > Hi,
>     >
>     > As of now at the event of failure of any of the FT enabled link
>     > additional links are being added in more or less random fashion by
>     nodes
>     > directly connected to the failed links.
>
>     above statement is incorrect. It is absolutely NOT TRUE that "at the
>     event of failure of any of the FT enabled link additional links are
>     being added".
>
>     Temporary additions of the links to the FT has its strict rules:
>
>     6.7.5. Failures of Link On the Flooding Topology
>
>        "If the failed local link represented the only connection to the
>         flooding topology on the node where the link failed, the node MUST
>         enable temporary flooding on a subset of its local links."
>
>     6.7.9.  Treatment of Disconnected Adjacent Nodes
>
>         Every time there is a change in the flooding topology a node MUST
>         check if there are any adjacent nodes that are disconnected from the
>         current flooding topology.  Temporary flooding MUST be enabled
>         towards a subset of the disconnected nodes.
>
>
>     So we are only performing temporary flooding if either we or one of our
>     neighbors got isolated from the FT, which given the bi-connectivity of
>     the FT itself is an unlikely event.
>
>     thanks,
>     Peter
>
>     >
>     > In the event of 100s of links on such nodes and advisable rate
>     limiting
>     > addition of those links it seems that repair of FT may take some time.
>     >
>     > In order to reduce such time interval better then random addition of
>     > remaining links seems recommended. How about we hint participating
>     nodes
>     > to execute purely in control plane of FT an LFA algorithm for possible
>     > future event of active link failure and use results of the LFA
>     > computation to prioritize links which will be first temporary
>     additions
>     > upon active flooding links failures ?
>     >
>     > Such optimization is local and optional and does not require any
>     changes
>     > to proposed protocol signalling.
>     >
>     > _Therefor how about just one sentence addition to section 6.7.1
>     > of draft-ietf-lsr-dynamic-flooding:_
>     >
>     > /Temporary additions of links to flooding topology could be more
>     > educated if given node runs a pure control plane LFA ahead of any FT
>     > failure on active FT links completely detached from potential LFA runs
>     > for data plane topology. /
>     >
>     > Kind regards,
>     > R.
>     > /
>     > /
>     >
>     >
>     > _______________________________________________
>     > Lsr mailing list
>     > Lsr@ietf.org <mailto:Lsr@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/lsr
>     >
>