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

Robert Raszuk <robert@raszuk.net> Mon, 11 March 2019 21:28 UTC

Return-Path: <robert@raszuk.net>
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 2672F1200D7 for <lsr@ietfa.amsl.com>; Mon, 11 Mar 2019 14:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 pd-1Q7bMtIIV for <lsr@ietfa.amsl.com>; Mon, 11 Mar 2019 14:28:15 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A28B1224E8 for <lsr@ietf.org>; Mon, 11 Mar 2019 14:28:15 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id v10so267967qtp.8 for <lsr@ietf.org>; Mon, 11 Mar 2019 14:28:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=2XiXg1VaDeKsJv6nHIX1Rd4a6koJzfMDFM+Drg+eAAA=; b=RRZtmse9FIXmf8jhHrPVbB9qxI+biez1GpAfZnkH80FOTqixqdTuyOHCnC0e1i9eTY S+ZHtZz3BgZ4rtle5ALWByu3/O+6EQXLMfFPdjqMd8E6M1BEhgSSwPg644BOCv8GRX4b KN9HE86cA0my0mw1OCh3bT+U4Wp3k7Bsjiauc9nHWF9L0AC/v1fBV+9lF0A57oJPc3bX AJLY8ATPoRPnGwt8WuAuypjs/g8+r/1ufLvRjCOgCZh57zigj+gzCehpmVm+mDLxz7LF fLDIQcXvDB80ysRPW3burWBjXLF1NJ4n7zdrXgt+qFmlzG9xEM7ZLKp9zozuzOvBBu4W dN2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2XiXg1VaDeKsJv6nHIX1Rd4a6koJzfMDFM+Drg+eAAA=; b=FtaDu0Qoycu0zIgbbm6fUTnRk6t859TAhndoTiqLGF9fSlZcTAC+86a9fzuTlJ8ZMK fbg9bf6IDw6L18g8H3IAfRrrauRrp1Q4/6+9EHeDlfI25qV4+mzazp9OxbtYjLtgynSk Clq879u9uFs+3MLUgvucy63KnjAmyWbRd9mYyfif0YCji9WYN0Y/lb5R+Cuv2/ESZcPn MxkQgoG8mYkEuf4USaDo5lFdQdwg9teRZqzR3yG3qXZpXNxlRqHuxKUSgFKEvV1DLPog 4ZtZsBI2PNmUpI1h8j+IwcjeLx0mwo3dMwtjCxiJvyJOSrMMgPVnxL8Y5vt6iC3BlSY0 BPVw==
X-Gm-Message-State: APjAAAVcfvOniNZ+JxFzZmAb1GuZSe5e3RMhvr/LKWfdGsJeaIbx7rjD 253GEseKx+OWas6lAhyV5nArJENLiVPQ+U/gCUMBy/xMMD0=
X-Google-Smtp-Source: APXvYqxIJHKYne1wV44rhNTM2peCn3/gsLxqUmqNDcT2/gqSJ/qbzakBy+kJG8iExKJ15ePo8lpdWNdSdJo2LaQxKTg=
X-Received: by 2002:ac8:6894:: with SMTP id m20mr26775960qtq.277.1552339693953; Mon, 11 Mar 2019 14:28:13 -0700 (PDT)
MIME-Version: 1.0
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 11 Mar 2019 22:28:04 +0100
Message-ID: <CAOj+MMHwJW6=SQ+_VSTUqwOWDv=+vkg-TTncA5PEczkAn-bdUg@mail.gmail.com>
To: lsr@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000779150583d84095"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/gTATS4ny867wNqgf6jBl_U0u2gI>
Subject: [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: Mon, 11 Mar 2019 21:28:17 -0000

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.

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.