[Lsr] A new proposal on how to do Sparse Link-State Flooding in Dense Topologies

Henk Smit <hhwsmit@xs4all.nl> Mon, 22 October 2018 19:53 UTC

Return-Path: <hhwsmit@xs4all.nl>
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 C1B45130E6A for <lsr@ietfa.amsl.com>; Mon, 22 Oct 2018 12:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kV9pKCMUzMSp for <lsr@ietfa.amsl.com>; Mon, 22 Oct 2018 12:53:33 -0700 (PDT)
Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F73130E4B for <lsr@ietf.org>; Mon, 22 Oct 2018 12:53:30 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud7.xs4all.net with ESMTPA id EgGVggfiMw2L8EgGVgBSwc; Mon, 22 Oct 2018 21:53:28 +0200
Received: from knint.xs4all.nl ([83.163.74.169]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 22 Oct 2018 21:53:27 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 22 Oct 2018 21:53:27 +0200
From: Henk Smit <hhwsmit@xs4all.nl>
To: lsr@ietf.org
Cc: Gunter Van De Velde <gunter.van_de_velde@nokia.com>
Message-ID: <b74d3ca68bf7782e97060dabeb0362da@xs4all.nl>
X-Sender: hhwsmit@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfFyDGu8AQY+MoHWrJLs3Ofu+H+bQE90WfrIphr2jX/gNT9QC958OMkoVFT9XpPnsfX29mlDN4TVTolfMWURrQ4WUTx87paL8y7Mw1U/6TZ2xvgLhee4J IdUYTD97gruly9dNWyRAASraJprHva8KjZPmCVue0umCKNu3FBJSz8zzBFlavr7tdHkWZFRi283y/5uGSLzAbF8aoF0c6X/MgbiZmTGIJpuBBvWwaIJxq2DZ kk62ktB9IRiHCWG4jbaCbw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/5arxjJ6-cai1bNgCe2IRJeuJb3I>
Subject: [Lsr] A new proposal on how to do Sparse Link-State Flooding in Dense Topologies
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, 22 Oct 2018 19:53:42 -0000

Hello all,

Gunter Van De Velde and myself have submitted a first version of
our new draft regarding sparse Link-State flooding in dense topologies.

You can find the new draft here:
https://datatracker.ietf.org/doc/draft-hsmit-lsr-isis-dnfm/


Abstract

    This document describes a technology extension to reduce link-state
    flooding in highly resilient dense networks.  It does this by using
    simple and backwards-compatible extensions to reduce the number of
    adjacencies over which link-state flooding takes place.

    "IS-IS Sparse Link-State Flooding" is an extension to the IS-IS
    routing protocol.

    It is relatively easy to understand and implement.
    It is backwards compatible.
    It requires no per-node configuration.
    It uses a distributed algorithm, therefor no centralized computations 
are required.
    No complex computations are required on each node in the network.
    The algorithm has no requirements for the network topology.
    It can be deployed in a redundant way to improve robustness and 
convergence-times.


The element that distinguishes this algorithm from other proposals is
the fact that it uses a new TLV in IIHs to signal suppression of 
flooding
between two adjacent routers. A network has an "anchor", which will 
function
as the root of the tree that forms the flooding topology. Each router
will request, via its IIHs, to flood only over an adjacency to another
router that is closer to the anchor. More details are in the draft.

Although the algorithm isn't overly complex, we might not have been
100% succesful yet in writing down the perfect description and 
explanation.
All suggestions, comments and questions are welcome.

Thanks in advance,

Gunter & henk.