Re: [Lsr] Dynamic flow control for flooding

David Lamparter <equinox@diac24.net> Tue, 23 July 2019 21:13 UTC

Return-Path: <equinox@diac24.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 5EA961202CC for <lsr@ietfa.amsl.com>; Tue, 23 Jul 2019 14:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tZYXgT3w7aXd for <lsr@ietfa.amsl.com>; Tue, 23 Jul 2019 14:13:52 -0700 (PDT)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 48EEA1202C3 for <lsr@ietf.org>; Tue, 23 Jul 2019 14:13:52 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from <equinox@diac24.net>) id 1hq26T-000kT7-5f; Tue, 23 Jul 2019 23:13:45 +0200
Date: Tue, 23 Jul 2019 23:13:45 +0200
From: David Lamparter <equinox@diac24.net>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Tony Li <tony.li@tony.li>, "lsr@ietf.org" <lsr@ietf.org>
Message-ID: <20190723211345.GH258193@eidolon.nox.tf>
References: <CAMj-N0LdaNBapVNisWs6cbH6RsHiXd-EMg6vRvO_U+UQsYVvXw@mail.gmail.com> <BYAPR11MB36382C89363202D1B5659614C1C70@BYAPR11MB3638.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BYAPR11MB36382C89363202D1B5659614C1C70@BYAPR11MB3638.namprd11.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/QY9y0TpEexK-ZvdTG_tj2orzKQE>
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: Tue, 23 Jul 2019 21:13:54 -0000

Hi Les,


On Tue, Jul 23, 2019 at 08:29:30PM +0000, Les Ginsberg (ginsberg) wrote:
> [...] As network-wide convergence depends upon fast propagation of LSP
> changes -

you're losing me between that previous part and the next:

> - which in turn requires consistent flooding rates on all interfaces
> enabled for flooding [...]

I understand and follow your reasoning if we have a classical timer that
limits flooding rates per LSP.  If we get multiple updates to the same
LSP, dissimilar flooding rates imply we might just have sent out the
previous now-outdated state, and we block for some potentially lengthy
time before sending out the most recent version of that LSP.

I don't understand how we get delayed propagation of LSP changes if we
employ some mechanism to raise the flooding rate to something based
around the target system's capabilities.

Could you elaborate on how we get delayed LSP propagation in this
scenario?

Thanks,


-David