Re: [Lsr] Flooding across a network

Robert Raszuk <robert@raszuk.net> Wed, 06 May 2020 07:52 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 CD1DB3A045B for <lsr@ietfa.amsl.com>; Wed, 6 May 2020 00:52:21 -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=unavailable 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 8A24vLhBrfyh for <lsr@ietfa.amsl.com>; Wed, 6 May 2020 00:52:19 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 6B8583A044D for <lsr@ietf.org>; Wed, 6 May 2020 00:52:19 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id pg17so526185ejb.9 for <lsr@ietf.org>; Wed, 06 May 2020 00:52:18 -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=MEjpUSGPj1E4MpsfTJbpnF4ZVqBlDCtDe1kXWLzXNFU=; b=cf+bsGWPwSHm5SMYjp+36Saosxzn84R9UxcOvivFbKVs5kOzphLGZoiYlLpRl84jSO fkww0dVGOQO+Btx03LEhSb6/6kF8Kjp4L8hlXNIHQGPAuolOoUkGGV/K+Aiq6oXL2Xqh EVs1U2IILR5FusPBjomymR5QKQluM1YukWC3LKn0Dyio83OxPLNH22FlOd/7JkLEAX11 9SZgZc61UjnQECONSFHcgIWl37Tzi2yA9AIA/4rmYgmjEfrg5q02adFbWsui8O1MktQc T61u9T2YztC6fIapFAdT2oy+IzXls/iaB1CPJSjgBDPjofHA44vt6Ft+a0mbfZ+sdUdP 6BBw==
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=MEjpUSGPj1E4MpsfTJbpnF4ZVqBlDCtDe1kXWLzXNFU=; b=BvFgWR0idLIKptSnVOmbJdIaZeG+QvZD9RsNY7f4IbJNGR5fAWwlSU3akfKqdh2GyB Idu/F0tCtSebAqdOOm+YGcNaAu1N+k2bqmbHxvcSKHHxQ9pZmNPTIX9TlZ61v1p9u+yO skoVJNZDdLRCSLg7AGID58ha22l/ji2indCexqqLE7qiTCFCPGuuDafVJACW4nwTOh9u JQit3gBYlnlibbo31RIty7XUxUG4fJQs7hj0RhnK031J6wVBLrSZ/a1IKoq3E+tSk7aI 2CXGYgF8cOwm6HLDxo8l6ugRRtaqq+BFUZarabnzHPmYJPZ9hR/SQ2kmYt8sEzTyhrif XuWA==
X-Gm-Message-State: AGi0Pubug0lHZ3Cpk/52jyejedrc84hXaYA/msJDPQfI4yuCIiQBCbVn 9x5+2dxwLSlMRKy0CLWJdFpDJ5scorS3hnzAhzJ7ww==
X-Google-Smtp-Source: APiQypKh9xKVNvO3dLmXHYPmp0kZnaKo6g+H5TTK3qqtNoJSvUa/FjXtRidoLNjUSOha7b/FvY05F8lbuIX3KtTig9w=
X-Received: by 2002:a17:906:7750:: with SMTP id o16mr6300059ejn.12.1588751537504; Wed, 06 May 2020 00:52:17 -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> <61EB462E-18EC-4F1D-8EF4-0EA126D5F7F6@chopps.org>
In-Reply-To: <61EB462E-18EC-4F1D-8EF4-0EA126D5F7F6@chopps.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 6 May 2020 09:52:08 +0200
Message-ID: <CAOj+MMEZB-GPKzopj=zDcHbVLdbLB56G0JyRoCkvyPQHbDrvfQ@mail.gmail.com>
To: Christian Hopps <chopps@chopps.org>
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="000000000000079c3705a4f60b4f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/JsunrGHln-yr2_NGQ4p1XK3xgcE>
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: Wed, 06 May 2020 07:52:22 -0000

Christian,

It is not about "hand-wringing and theorizing about being too-successful".

It is about impact to the overall network service when you make ISIS
convergence not consistent across nodes of the topology, I think our goal
is not to converge ISIS faster by improving flooding speed ... it is much
more about how to deliver user packets with minimal disruption upon
topology changes.

Best,
R.

On Wed, May 6, 2020 at 5:48 AM Christian Hopps <chopps@chopps.org> wrote:

> [as WG member]
>
> I think it would be more productive if we stay focused on trying to
> improve flooding speed/efficiency here. How about let's get some of the
> proposals being mulled over actually written, and provide some data, and
> leave all the hand-wringing and theorizing about being too-successful for
> after we've shown we could be? :)
>
> Thanks,
> Chris.
>
>
> > On May 5, 2020, at 8:03 PM, Robert Raszuk <robert@raszuk.net> wrote:
> >
> > But this proves that consistent convergence time in a domain is rather a
> good thing regardless if it takes 2 sec or 50 sec on all nodes.
> >
>
>