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 >
- [Lsr] Flooding across a network bruno.decraene
- Re: [Lsr] Flooding across a network Les Ginsberg (ginsberg)
- Re: [Lsr] Flooding across a network Robert Raszuk
- Re: [Lsr] Flooding across a network Christian Hopps
- Re: [Lsr] Flooding across a network Robert Raszuk
- Re: [Lsr] Flooding across a network bruno.decraene
- Re: [Lsr] Flooding across a network Les Ginsberg (ginsberg)
- Re: [Lsr] Flooding across a network bruno.decraene
- Re: [Lsr] Flooding across a network Christian Hopps
- Re: [Lsr] Flooding across a network Les Ginsberg (ginsberg)
- Re: [Lsr] Flooding across a network Les Ginsberg (ginsberg)
- Re: [Lsr] Flooding across a network Christian Hopps
- Re: [Lsr] Flooding across a network bruno.decraene
- Re: [Lsr] Flooding across a network Les Ginsberg (ginsberg)
- Re: [Lsr] Flooding across a network Joel M. Halpern
- Re: [Lsr] Flooding across a network Les Ginsberg (ginsberg)
- Re: [Lsr] Flooding across a network Tony Przygienda
- Re: [Lsr] Flooding across a network Mitchell Erblich
- Re: [Lsr] Flooding across a network Jeff Tantsura
- Re: [Lsr] Flooding across a network bruno.decraene
- Re: [Lsr] Flooding across a network Robert Raszuk
- Re: [Lsr] Flooding across a network Les Ginsberg (ginsberg)
- Re: [Lsr] Flooding across a network tony.li
- Re: [Lsr] Flooding across a network bruno.decraene
- Re: [Lsr] Flooding across a network Gyan Mishra
- Re: [Lsr] Flooding across a network bruno.decraene
- Re: [Lsr] Flooding across a network Gyan Mishra