Re: [Lsr] Dynamic flow control for flooding

Henk Smit <henk.ietf@xs4all.nl> Wed, 24 July 2019 14:11 UTC

Return-Path: <henk.ietf@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 E4F091200E0 for <lsr@ietfa.amsl.com>; Wed, 24 Jul 2019 07:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 4iHNi7NPrKjT for <lsr@ietfa.amsl.com>; Wed, 24 Jul 2019 07:11:42 -0700 (PDT)
Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (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 7BFE0120019 for <lsr@ietf.org>; Wed, 24 Jul 2019 07:11:42 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216]) by smtp-cloud8.xs4all.net with ESMTPA id qHzXh3NxseD5bqHzXhed3N; Wed, 24 Jul 2019 16:11:39 +0200
Received: from knint.xs4all.nl ([83.163.74.169]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 24 Jul 2019 16:11:39 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 24 Jul 2019 16:11:39 +0200
From: Henk Smit <henk.ietf@xs4all.nl>
To: Robert Raszuk <rraszuk@gmail.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Tony Li <tony.li@tony.li>, lsr@ietf.org
In-Reply-To: <CA+b+ER=LOZxoyoonPtC7VKppSNcQohGQdx+n8D3+LndnHdsofQ@mail.gmail.com>
References: <CAMj-N0LdaNBapVNisWs6cbH6RsHiXd-EMg6vRvO_U+UQsYVvXw@mail.gmail.com> <BYAPR11MB36382C89363202D1B5659614C1C70@BYAPR11MB3638.namprd11.prod.outlook.com> <5841_1563943794_5D37E372_5841_105_1_9E32478DFA9976438E7A22F69B08FF924D9C373E@OPEXCAUBMA3.corporate.adroot.infra.ftgroup> <BYAPR11MB363856BB026992DFBB3BB224C1C60@BYAPR11MB3638.namprd11.prod.outlook.com> <8376a87831ffa6f5298c5122907c6e66@xs4all.nl> <CA+b+ER=LOZxoyoonPtC7VKppSNcQohGQdx+n8D3+LndnHdsofQ@mail.gmail.com>
Message-ID: <cc806e622ad77ab73263cd9dc7eecad8@xs4all.nl>
X-Sender: henk.ietf@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfDFZTyegzamJa2nJzmyC40BsizWUpqRWTOSLjklhcKHk+RfWePUDa/g+ANs9yEIdtQJoi9wEWO00G/7HQfYnMklz6dLSftm5JhSD9c2pV7aVdD687JR9 cCsSMCLipLkG70Iw5p4DjpTzrSf3EoHUnaLz6fDMkJWHD0B/TgYMUleKeB0ZwXHkKg1tOpvWf6rCuWUOPPsCl9gRczF+onMmMeLXrqbs4NYhbHlOgcv9WBY2 c6Dxj2FE6WLmmFJ//PS5qcAjz1qH/aEJt/qiKYgpXd4r1Iksyf1X4f0/zCxOSTJ+
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/glwTC2D2CF4wNl4RRfzCI8tUrGw>
Subject: Re: [Lsr] Dynamic flow control for 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: Wed, 24 Jul 2019 14:11:46 -0000

Hello Robert,

Tony brought up the example of a partioned network.
But there are more examples.

E.g. in a network there is a router with a 1000 neighbors.
(When discussing distributed vs centralized flooding-topology
  reduction algorithms, I've been told these network designs exist).
When such a router reboots/crashes/comes back up, all 1000 neighbors
will create a new version of their own LSP. This causes a 1000 different
LSPs to be flooded through the network at the same time. Impacting every
router in the network.

The case I was thinking of myself, was when a router in a large network
boots. When it brings up a number of adjacencies, each neighbor will
try to synchronize its LSPDB with the newly booted router. As the newly
booted router will send emtpy CSNPs to each of its neighbors, each
neighbor will start sending the full LSPDB. If such a network has 10k
LSPs, and such a router has 100 neighbors, that router will receive 100 
* 10k
is 1 million LSPs. Having a faster and more efficient flooding 
transport,
with flow-control, will make a reboot in such a topology less painful.

(In that last case, creative use of the overload-bit could prevent 
black-holing
or microloops while ISIS synchronizes its LSPDB after a reboot. Just 
like we
used the overload-bit to solve the problem of slow convergence of BGP 
after
a reboot, 22 years ago. I have no idea if there are any implementations 
that
use the overload-bit to alleviate slow convergence of IS-IS after a 
reboot).

henk.


Robert Raszuk schreef op 2019-07-24 15:33:
> Hey Henk & all,
> 
> If acks for 1000 LSPs take 16 PSNPs (max 66 per PSNP) or even as long
> as Tony mentioned the full flooding as Tony said may take 33 sec - is
> this really a problem ?
> 
> Remember we are not talking about protocol convergence after link flap
> or node going down. We are talking about serious network partitioning
> which itself may have lasted for minutes, hours or days. While just
> considering absolute numbers yelds desire to go faster and faster, if
> we put things in the overall perspective is there really a problem to
> be solved in the first place ?
> 
> Would there still be a problem if LSR WG recommends faster acking
> maybe not for each LSP but for say 20 or 30 max ?
> 
> Thx,
> R.