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

Peter Psenak <ppsenak@cisco.com> Tue, 12 March 2019 06:45 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 C88E8130EFC for <lsr@ietfa.amsl.com>; Mon, 11 Mar 2019 23:45:25 -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 qz5OfquRrDsO for <lsr@ietfa.amsl.com>; Mon, 11 Mar 2019 23:45:23 -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 A69D6130EE7 for <lsr@ietf.org>; Mon, 11 Mar 2019 23:45:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2471; q=dns/txt; s=iport; t=1552373122; x=1553582722; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=DIEh9vKgbgmDKFnGMoDtxKq/Q7GZZH7z9embNKGvQWU=; b=QyVQeiww4eXU6RJJgMOalK8duZx3EZmZkpFb5Cumoiz6CnJ0YHyP36md PD1hC/F5cwmjCBJsLbZwHs/zy0KW9RtuSj3v6pJ2h2pg1BLt7tojbmkmb 0pG/fyEWI6A8wsG0bRulPUBpPKPVknVOg9g05QA9G3tWCfEm9sPT0UWoq M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAACfVIdc/xbLJq1kGgEBAQEBAgEBAQEHAgEBAQGBUQUBAQEBCwGBZYESUCESJ4wkX4xlmCqBew0YC4RJAoRcNAkNAQEDAQEJAQMCbRwMhUoBAQEDAQEBNjYbCxguJzAGAQwGAgEBglNLAYFtCA+xOoVFhHsFgS8Bi0OBQD+BESeCPS6DHgEBh0IDihSHLIEXkVIJi1CHOwYZiwGIOop5knaBRziBVjMaCBsVO4JsiwyFQD4DMI12KoIjAQE
X-IronPort-AV: E=Sophos;i="5.58,470,1544486400"; d="scan'208";a="10685391"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2019 06:45:20 +0000
Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x2C6jKE4008107; Tue, 12 Mar 2019 06:45:20 GMT
To: Robert Raszuk <robert@raszuk.net>, lsr@ietf.org
References: <CAOj+MMHwJW6=SQ+_VSTUqwOWDv=+vkg-TTncA5PEczkAn-bdUg@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <e0901e21-fdfa-b14f-7abe-f80bfd4c5016@cisco.com>
Date: Tue, 12 Mar 2019 07:45:18 +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+MMHwJW6=SQ+_VSTUqwOWDv=+vkg-TTncA5PEczkAn-bdUg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.60.140.53, ams-ppsenak-nitro4.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/TxItDNzn2XMItAV2SbpDNh_WehY>
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 06:45:26 -0000

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
> https://www.ietf.org/mailman/listinfo/lsr
>