Re: [Lsr] Flooding across a network

Robert Raszuk <robert@raszuk.net> Thu, 07 May 2020 09:20 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 396793A0ACB for <lsr@ietfa.amsl.com>; Thu, 7 May 2020 02:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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=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 nA6ZKDyx-o0I for <lsr@ietfa.amsl.com>; Thu, 7 May 2020 02:20:43 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 4B5953A0AD0 for <lsr@ietf.org>; Thu, 7 May 2020 02:20:43 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id e2so3940738eje.13 for <lsr@ietf.org>; Thu, 07 May 2020 02:20:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=krbhlxehCk4pljIGrb/7bosQOIzPoYhhw5kSbBBQV7k=; b=TkShdC8HsU/JiTMiFHl7vgZqvesoSJLJnWgDN/u/hCyN/+jqWYqn4rmMl8hnO0skh5 q+WBhpFapbRdC4D/KYZBqcexKcRtclgSwJ3JhSEfqrOTnKHAoD/8scGvV+doG0DqmcDv ajLX77i8QkAmic8oWItQagkoK8tgihrrPwh8g7VJh6NdaEpemMQslMDj7EcgxZZu0L0b cf1PCsSoeSIRh8JUZwimgtn2LYDWp7danxnrbYhznMV+XpHDeKYDZ5GOadROuSL/45cc zlp7nYBge8fQ4+KKy13pgQjTk81LAdDjyL6qKEoFSI8pa4fQ/r9IDw3osQkPYTUTonMA BXog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=krbhlxehCk4pljIGrb/7bosQOIzPoYhhw5kSbBBQV7k=; b=A/QOaheeby6PM+dry9+Yh2xkdFfLWv80iod6hAIoPgy4ueyAfRd1g+mvJSd3baEgk3 NOGkEdKhiOXsjN8X7SHd0OaNpVRWJrp6pytsopzdMQOHWN4AJdkusrbeV334Cg9gdcIh V6ET3FyuEp1UTKq8fxTyC6oBe3eH9k8/6yXtC48d8NwM2lBpbHauMfrGCQiJc21FAbJj vtCVfgSWbnWT7l99sy1hdFc49cleub6TuD1Xc5jrMq6ISmkfkzWJ6ntEQCZiD8zKOa2W toUoXRU2hs1F82Co4oawrPoYfm6iygqw/xld4Y2KsJxukGmrMoqDieuYu1Ef/8nCZp/q bGPw==
X-Gm-Message-State: AGi0PubkUZK55BROo6GjV1SgoARH5wqnA3fNz6etfqjGUuSO2yrbxNEp +F57qaXJcK0VFpCCfbNo0GUpe7gJfXahOYZ8yxoZhw==
X-Google-Smtp-Source: APiQypI4VPc3y0SRxDaaFnW3j5AfwIz2+BQwRtHEV/uMZJC17BXeYOnFDIB+V8Ls50RALobQD6VCsK+N62PIn8Qsmfk=
X-Received: by 2002:a17:906:7750:: with SMTP id o16mr11183526ejn.12.1588843241450; Thu, 07 May 2020 02:20:41 -0700 (PDT)
MIME-Version: 1.0
References: <24209_1588692477_5EB185FD_24209_35_1_53C29892C857584299CBF5D05346208A48E3D455@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MW3PR11MB46198A668B9F2532BCCC38FEC1A70@MW3PR11MB4619.namprd11.prod.outlook.com> <CAOj+MMGkbQGot4Yr6ji5BBn+_6N4c6ARTdnXvRL0wR7e7x1VnQ@mail.gmail.com> <c2f11fa3-1843-4fd4-9d05-47ea5748e214@Spark>
In-Reply-To: <c2f11fa3-1843-4fd4-9d05-47ea5748e214@Spark>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 7 May 2020 11:20:31 +0200
Message-ID: <CAOj+MMENcCK46A63FA_NPsh84Sv11FOgPe4JKAH3o+=hJgjXOQ@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000002d8cc05a50b6519"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/-uPWIRoBUacsY7YxoKbkCb4LNGk>
Subject: Re: [Lsr] Flooding across a network
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: Thu, 07 May 2020 09:20:45 -0000

Hey Jeff,

What if in your analysis A-D link metric is 1500 ? Still A will send to B !

See in all of this discussion from my pov it is not really about danger of
making LSDB inconsistent for much longer.

It is however about operator upgrading to new release a router, maybe even
reading release notes stating that flooding speed optimizations defined in
RFC ZZZ are implemented and final effect he sees are microloops lasting 10s
of seconds for his traffic.

Yes some vendors have good tools to protect from microloops, but those must
be enabled. Moreover those still require manual timer configuration how
long to keep loop free protection in place. And I am not aware any vendor
has a cli command showing how long it took in all routers in my area/level
to install in FIB result of various levels/cases of topology changes.

So I am not saying faster is not good. I am saying if you make car faster
do not forget to equip it with seat belts and make enough of warnings that
driver will actually fasten them.

Best,
R.

On Thu, May 7, 2020 at 6:41 AM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> Robert,
>
> Assuming C and E provide access to the same set of destinations, that are
> closer of further away from C and E.
> B (which is fast), after it notifies A that it can’t reach C directly will
> cause A to send traffic to D. D - dependent on total cost would start
> happily sending some traffic towards destinations behind C to B so LFA on B
> wouldn’t really help.
>
> Cheers,
> Jeff
>