Re: [Lsr] Flooding across a network

tony.li@tony.li Thu, 07 May 2020 15:52 UTC

Return-Path: <tony1athome@gmail.com>
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 07B003A0A93 for <lsr@ietfa.amsl.com>; Thu, 7 May 2020 08:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 T-yVZ8kBL4dm for <lsr@ietfa.amsl.com>; Thu, 7 May 2020 08:52:50 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 73A653A0A51 for <lsr@ietf.org>; Thu, 7 May 2020 08:52:46 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id w65so3175327pfc.12 for <lsr@ietf.org>; Thu, 07 May 2020 08:52:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9gXvVor5MHf04Idah4TOJPtYPptXOomYuoUOUNnRoVM=; b=QkP5nPJmMgMpDHFp6MDuA1ZAJGz/dMuj8SXzMJDTxESaRI73yxDVm1Sc8atKWlJNXZ CRxHPgKEHOPNpq47zlVq2kNO2FK+WKCKkEsUp+N3Jxl6olirAshfhHeLuOHhp2rK0I1X ZUn7GwLpN3IxINp32UH+5ewHSYltl6YqGKFCcGOSN0zluv5YbwtGXB/R1wYqd8hpsa/b EZQBX50DlnfNihgwZoh2JAxIru+va0bjtukpIq3vSXsFEI9OrnaCTnGyezIWFk0oEvtA 5iXbHIDE+zmMWKtSoBA8sxNpIkUb70VU6LsumIA1SrvS/PzorKhHqC1CS5+FM/pgTFR5 BWgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9gXvVor5MHf04Idah4TOJPtYPptXOomYuoUOUNnRoVM=; b=rFKsP67uIHtqPo4aXJc5qHVdhIXoY6kRKWz13gzHVT9++BLRiWP/JadlAdcD1aBQCM 4UC9FJ0rKlYe+JYlSbZTPB5cGTmebJjiw+zPawew0YQXyXlanAMVMPtCri66viaIHy6f vSoXhXSGNUeeliNIJQ0RsWRUiAqHvIbwz0ZogLlLsVDAONbynPxb5cEaIJ4zwKhKxTt+ 5e0T8eQNNfQjbykAs8jX+ZCSFjgwCw8pM2goTqKyOJy5qEUXO1dqwsr3akhRq2B9DpM7 NNXyt0Ur3ZK983HTlJT0vHEfXsgN6mpgqDLdWOHrkFYJqgfb7P38T5VgMFsisAa3P2/C sgJQ==
X-Gm-Message-State: AGi0PuYTmFCfKOh2+Har6KHJa0JLrFXshj5QNOkBCiBGtCco6wNw+OxL c1rQpldgGWb+rK6QTWpbbAh4qBFK
X-Google-Smtp-Source: APiQypLQVpgY2qocORWJrQqPqNyICY2rb9NBK/2mmWenKNVjvOzeHMED8WOxGXoNucEeL57yWPJpFg==
X-Received: by 2002:aa7:8594:: with SMTP id w20mr14828881pfn.137.1588866765840; Thu, 07 May 2020 08:52:45 -0700 (PDT)
Received: from [10.95.84.23] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id i13sm220807pja.40.2020.05.07.08.52.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 08:52:45 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <73606233-D019-4ABC-B1AB-9ED4FECC782C@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3E0A45CE-BA85-485D-9B31-7EC383F2CCCA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 07 May 2020 08:52:43 -0700
In-Reply-To: <MW3PR11MB46193B31C35D5CA02F58AF81C1A50@MW3PR11MB4619.namprd11.prod.outlook.com>
Cc: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "lsr@ietf.org" <lsr@ietf.org>, Christian Hopps <chopps@chopps.org>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>
References: <24209_1588692477_5EB185FD_24209_35_1_53C29892C857584299CBF5D05346208A48E3D455@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MW3PR11MB46198A668B9F2532BCCC38FEC1A70@MW3PR11MB4619.namprd11.prod.outlook.com> <6287_1588771252_5EB2B9B4_6287_332_1_53C29892C857584299CBF5D05346208A48E3F698@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MW3PR11MB46199CC33B10BC9D3D622D2AC1A40@MW3PR11MB4619.namprd11.prod.outlook.com> <10562_1588775602_5EB2CAB2_10562_251_11_53C29892C857584299CBF5D05346208A48E3FB63@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <87CDE7F3-E08D-4C45-9AF1-9DAD635F8908@chopps.org> <9992_1588784982_5EB2EF56_9992_201_1_53C29892C857584299CBF5D05346208A48E40256@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MW3PR11MB4619015E4B356DFC225CD001C1A40@MW3PR11MB4619.namprd11.prod.outlook.com> <6544_1588843052_5EB3D22C_6544_99_1_53C29892C857584299CBF5D05346208A48E415A8@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MW3PR11MB46193B31C35D5CA02F58AF81C1A50@MW3PR11MB4619.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/T5WHTWGLuMy7NmpLe3xt7hpZ2Ys>
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 15:52:52 -0000

Les,

 
> I have specifically used an example where “microloop avoidance” is not applicable. So I did not want to use the term “microloop” but rather used “loop” so as not to suggest that “microloop avoidance” is a potential solution for the sub-optimal behavior.
> Hope you can appreciate that point.
>  
> It would be easy enough to include more nodes in the topology which only support slow flooding. The end result would be the same.
> I have kept the example simple in the hopes we could more easily agree that what I describe can happen when not all nodes support faster flooding – which is the only point I am trying to make. Whether the ratio of Fast/Slow nodes is large or small or about the same doesn’t eliminate the possibility that the same behavior could be seen – though it might alter the location of the topology change which would be problematic.
>  
> From an operator’s POV, I am pretty sure that what you really care about is whether packets get successfully forwarded or not. I am demonstrating that it isn’t safe to assume forwarding behavior will be optimal when not all nodes support fast flooding.


Your point is well-made. There are certainly going to be topologies where making flooding faster would result in worse behavior.

However, the point is that there are also topologies where flooding faster would improve convergence. To support those, we must have faster flooding. Please focus on that goal.

Regards,
Tony