Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Robert Raszuk <> Mon, 27 April 2020 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6A5F3A1A22 for <>; Mon, 27 Apr 2020 12:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qQXhCu4vkr0D for <>; Mon, 27 Apr 2020 12:11:45 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15DD73A1A23 for <>; Mon, 27 Apr 2020 12:11:45 -0700 (PDT)
Received: by with SMTP id p16so14362778edm.10 for <>; Mon, 27 Apr 2020 12:11:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gwTKX9HfghELn9kexZRekrUd4TySI0IpKijKdq4Z91U=; b=cGNdbzTFNLbP+tZW0VibGtyEsGR3Nm/pwplLWF/3kz9wsdTkiwjKYbaMru0FXKurcE vLnA0lGYBDWWlj+0uODDqlloQ2Y9OopxAV/IIb7JzaE7FzkTcNoTntV1+zhUs46zHvM+ ormDC1P8NZ5sbM/1ZW5hlK+UZctmyj4q1WG8L2IBSvEoXbXSBY+j2mWkywCIZ2Ah8sFz obPixK/WUWxwFfpaMuC8jr6NyHyJeLZEjdPLxFqIwV4TqgEXd0ibmTIAN1oaAwGigkMW G43g3B1sRgw8+Uj+wGxRf+woZeguSbQ989x3AiiPhJ+yaZM5n1/0dLErpk5T4YbDjsSW alQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gwTKX9HfghELn9kexZRekrUd4TySI0IpKijKdq4Z91U=; b=uczY4bY31ggmLaWdIIgFfLMQ8nPI1BAN8oENmVoKnnSaP/LBBY4zGxr8Kk8kh2ak8Q dy6uabsQyqDqhVCYzpF75eahpqW8zwXVJ46ZzVoimE0LOAISs4T2GCVProVzQsCCqqlr W4ZAVj/X/yVojoBTWOaXGL+LT9izKzJk4bjMPRCRtcx6GD3z5CJb3Uo4ZZXCyof90vbh zHYz2MUPlwW8jmU9FwNFUg60ISiPAC14YVadlsgv1hYMs791FuNKwvUHYoX2tYw6j2GP K5NaduPQl9XXP+c3v+Ix3AEGrnzKRQ3T9hFsQjefVCL530gRdhQ7jSWR6UBldeSJsStS urPw==
X-Gm-Message-State: AGi0PuYeYtdeQRQuBZULXqbBqv8JWlWq7ENQ3cyrqTTndNJlLqrJJLsw Yi60WAcOTbl8W7QqjHzNmH3Im/KSDNFDeIgDP+ISDg==
X-Google-Smtp-Source: APiQypKgOGewGutUltS3bRzMUpvqQif+NNuqtkWNKLG9mdXcPs2NQQM+E4WEB4NGaKtxBtWnpQ2Wzm8SPtfMZX7RNTs=
X-Received: by 2002:aa7:d5d4:: with SMTP id d20mr20168376eds.369.1588014703391; Mon, 27 Apr 2020 12:11:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <13222_1587383221_5E9D8BB5_13222_339_1_53C29892C857584299CBF5D05346208A48E22AF0@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <> <6448_1587578604_5EA086EC_6448_75_1_53C29892C857584299CBF5D05346208A48E26E6F@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <19631_1587662111_5EA1CD1F_19631_99_1_53C29892C857584299CBF5D05346208A48E28EDE@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <4008_1587720323_5EA2B083_4008_332_1_53C29892C857584299CBF5D05346208A48E29FE5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <12067_1587976445_5EA698FD_12067_293_6_53C29892C857584299CBF5D05346208A48E2E14C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <24062_1587989690_5EA6CCBA_24062_69_1_53C29892C857584299CBF5D05346208A48E2E517@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <27097_1587992566_5EA6D7F6_27097_166_1_53C29892C857584299CBF5D05346208A48E2E687@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 27 Apr 2020 21:11:32 +0200
Message-ID: <>
To: Tony Li <>
Cc: Bruno Decraene <>, "Les Ginsberg (ginsberg)" <>, "" <>, "Acee Lindem (acee)" <>, Tony Przygienda <>
Content-Type: multipart/alternative; boundary="0000000000004b60c005a44a7c6e"
Archived-At: <>
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Apr 2020 19:11:47 -0000

Ahh ok.

I was under the assumption that flooding reduction is something we will
have sooner then LSP flow control. But maybe this was too optimistic.

- - -

For per peer flow control I do not get how receiver's ISIS process is to
come up with per peer timer if it may never see under congestion given
peer's LSPs (being dropped on the single RE cp queue or at the interface).

Perhaps such flag to "slow down guys" could be send by receiver uniformly
to all peers when under LSP flooding congestion ? And instead of
specifying an absolute number just mean: slow N times (ex: slow 2 times or
slow 4 times). Such timer could be either temporary with fixed duration or
in effect until relaxed explicitly.

LSP senders would still require to handle it on a per peer basis but as
indicated this is not an issue.


On Mon, Apr 27, 2020 at 8:57 PM <> wrote:

> If we have 1000 of interfaces and all peers *all in the same time* will
> send us an LSP of max size of 1492 octets that our control plane buffer RAM
> size required to store them would be as huge as 1.5 MB. And that assumes we
> did not process any from arrival of the first to the arrival of the last
> one.
> And that’s only one LSP.  If they don’t stop there and each sends 1000
> LSPs, then you can have 10^6 incoming packets, requiring 1.6GB.
> Further, since the bottleneck is likely the queue of packet on the
> forwarding chip(s) to the CPU, this 1.6GB needs to exist on the forwarding
> silicon.  Needless to say, it doesn’t.
> Yes, the CPU can probably keep up with one of the peers. This implies that
> the forwarding plane queue grows at the rate that 999 peers are sending at.
> Thus, congestion.
> Tony