Re: [v6ops] draft-ietf-6man-grand : saving lookups

Michael Richardson <mcr@sandelman.ca> Mon, 10 August 2020 16:45 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F673A0A4E; Mon, 10 Aug 2020 09:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 D8rNkAgckKab; Mon, 10 Aug 2020 09:45:02 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60D03A0A4A; Mon, 10 Aug 2020 09:45:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F3F7389DB; Mon, 10 Aug 2020 12:24:15 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id b4aLr0RuRIhV; Mon, 10 Aug 2020 12:24:14 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C6EF1389B1; Mon, 10 Aug 2020 12:24:13 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 60508724; Mon, 10 Aug 2020 12:44:57 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ca>
To: Nick Hilliard <nick@foobar.org>
cc: Bob Hinden <bob.hinden@gmail.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, IPv6 List <ipv6@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups
In-Reply-To: <89a4f4fc-7f4a-52c5-83b9-bd112f7a831a@foobar.org>
References: <m1k4nX7-0000ICC@stereo.hq.phicoh.net> <1D1A68AE-4C75-4DF0-8C7C-3500DB67C8FB@fugue.com> <4B1A43D0-45B1-4C73-8B09-089D4EC1FFF7@cisco.com> <17A8FA06-3776-450A-B549-958157AD5784@gmail.com> <B50732C5-4BBA-49E4-A169-74677C91B88B@cisco.com> <0A2FD466-6DB0-4378-88B7-AB99D32C2180@gmail.com> <89a4f4fc-7f4a-52c5-83b9-bd112f7a831a@foobar.org>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 10 Aug 2020 12:44:57 -0400
Message-ID: <553.1597077897@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SrspkX5UVnY9Puy9e09b5F5q0Ic>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2020 16:45:04 -0000

Nick Hilliard <nick@foobar.org> wrote:
    > Bob Hinden wrote on 10/08/2020 00:42:
    >> I thought we learned long ago to not create large distributed broadcast/multicast domains.

    > We did, but what's disheartening is that people persistently use this model
    > as rationale to justify a protocol change of one form or another.

And, we continue to pretend that we have these large domains in our analysis
of performance and security. And additionally, we are expending large amounts
of L2 logic to continue to simulate them with very little increase is
performance or security.

    > Maybe we need an ID which states this explicitly: "Large broadcast domains
    > considered harmful"?  As long as we have broadcast domains, people will be
    > tempted to make them too large and will express surprise that they don't
    > scale well.

Just remove the word "large" :-)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [