IETF Logo Mail Archive

Re: [Lsr] Flooding across a network

Mitchell Erblich <erblichs@earthlink.net> Wed, 06 May 2020 18:57 UTC

Return-Path: <erblichs@earthlink.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 71E783A0A9A for <lsr@ietfa.amsl.com>; Wed, 6 May 2020 11:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-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=earthlink.net; domainkeys=pass (2048-bit key) header.from=erblichs@earthlink.net header.d=earthlink.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 OMgAuZ3A_5E5 for <lsr@ietfa.amsl.com>; Wed, 6 May 2020 11:57:57 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (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 2F3863A0A9D for <lsr@ietf.org>; Wed, 6 May 2020 11:57:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1588791477; bh=n/fXpOBNUxAji9syjshdYEq7PnxA6+2ei3KD aNprFzI=; h=Received:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; b=naw2VRjAOX sI1kkXYEEP/+4xsIdbeiTCg6Z8X/rbH8c2WrEVacA9f/bNb2VwhFEN8cWpUx+knG1u6 oPyZ0zUdQDU8uQY1IIRURRzHyEI+vuMf+VDfcSdRqcyFiZyuIOVpBl5a+BW2JTy22SS G0nFgvNT5NHH7CdK2HFxgpTHQccr/0Iukx6HpwEZ8RfiCrTaPuDSYE8Jv/JZrmZswkT qFy5iVT8FI7BK2giekvi+YQ13OoVQ7MHk4sQj1+VE2YNet0G3CTmL9nBbW20aNrU3mn QlhqsLG+BorwsjHMKaSSgmHppaNEpoayAwliPTqPj6w690ydXUfKBA6AdI0BRObw==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=q4BvK+2WpTsCtI1+QGVgvW341pT2mTz1Gp2epTNYleU4AgNXnwJe08Jam5HyqCl2pCQ7xL0MSmNinrNBGmFkPaGce1BtdYiIzdhBOENF4NswX8xugq8beHFUV/sxY69YW0aoNmAsIB40r2aP4vjIjNdDnV1u6Zbp5Ao805wEdv8rm4CsNCvjS5iSJ9e74OaDDErU5j/dTMdpZfkmqgXDytvYP9nKp7S43y1bKFpds8TEor+PE9ZDIWyR+lhTcbJ1U4x835eBTXkb71cupLhhSK+8B92k82jkIEYDgWrW8GAyxHmcU5GE0hyeGGTtMYbZb6FJH6US5e35DwGPP1BEgg==; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [98.234.227.202] (helo=[10.0.0.53]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4) (envelope-from <erblichs@earthlink.net>) id 1jWPEw-0008Gx-FZ; Wed, 06 May 2020 14:57:54 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mitchell Erblich <erblichs@earthlink.net>
In-Reply-To: <CAOj+MMEZB-GPKzopj=zDcHbVLdbLB56G0JyRoCkvyPQHbDrvfQ@mail.gmail.com>
Date: Wed, 06 May 2020 11:57:52 -0700
Cc: Christian Hopps <chopps@chopps.org>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AF8D9440-E5B7-4557-A26B-C29DDD5279F8@earthlink.net>
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> <CAOj+MMEZB-GPKzopj=zDcHbVLdbLB56G0JyRoCkvyPQHbDrvfQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: Apple Mail (2.3124)
X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7971351d3d0339b4794dcfd6597512b3f5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 98.234.227.202
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/5NstFCkijD23AJrIFY7pE9H9cxs>
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 18:57:59 -0000

Robert,

		I agree with you…

		Disruptions based on protocol changes with non-current/legacy type products and/or intenal black-hole , loss of packets/rexmits, aka reliability should be primary.  Even good/great ideas of IPv4 / IPv6 intermediate systems/routers find small incompatibilities either with the protocol and/or CLI errors.

		With that said, I definitely like the OSPF DR/BDR functionality in Eth/multi-access/non-p2p environments for single router failures IMO adds reliability and mitigates certain types of disruptions.

		However, with wireless devices, one must still respect that bottlenecks need to be resolved when dealing with these slower/down ward scaling environments. This is just not just a packet-per-sec / bytes-per-second issue but frequently are smaller packet/segment sizes , a scaling of the number of simultaneous connections, and loss of packets/segments in these newer environments

		And, sorry, Eth is there with 100Gb and LACP exists, that will eventually push upward scaling proposals.

		
Mitchell Erblich
erblichs@earthlink.net



> On May 6, 2020, at 12:52 AM, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 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. 
> > 
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

v2.23.0 | Report a Bug | By Email