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

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Tue, 11 August 2020 20:15 UTC

Return-Path: <albert.e.manfredi@boeing.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0C73A0C5E; Tue, 11 Aug 2020 13:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 Wf6WDkmJCaJM; Tue, 11 Aug 2020 13:15:15 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 7F7FE3A0C4D; Tue, 11 Aug 2020 13:15:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 07BKFBuH029038; Tue, 11 Aug 2020 16:15:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1597176913; bh=Pxbk8pBDGbojc0tjJnGKFPHtp28WovPXdAjIobHRAwM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=nAyn7JQlyETQ5CSqd269MqfPccR20em6F3zbB6dtfH7ftS9R3j86SwpA4E4CAKP4k veW20VthJ6zV4JlvWOWs6Qse1X9vhK9k42UQivYPk2tQ2JbeNiLxH7103e1nt88BY1 TcTR/f6ajVCeJ+B7G82M4rCnqZypWhou9aFMsfZW9IB5F8DJd51NEgTjAMTZeP6YDb 0iCBemWzTuZ4vJpwSgwpKVEZ7L10zNcsXlYJRZNKcPnRWdU9gYCkNsePHSpQp0LJlz S+o/0RdgswqURkJWLAaV0OVIP+pcg4RsuOBEMRyUmm5opE4JadmlgKYPHNpFXa42C1 jmIVpUprnxDtg==
Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 07BKF40c028658 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 11 Aug 2020 16:15:04 -0400
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 11 Aug 2020 13:15:03 -0700
Received: from XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323]) by XCH16-01-11.nos.boeing.com ([fe80::a96c:5d85:1337:4323%4]) with mapi id 15.01.2044.004; Tue, 11 Aug 2020 13:15:03 -0700
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Ted Lemon <mellon@fugue.com>
CC: IPv6 List <ipv6@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Thread-Topic: [EXTERNAL] [v6ops] draft-ietf-6man-grand : saving lookups
Thread-Index: AQHWcAyIl4J+bnqVN0aqlKzDmxcKv6kzwcWA//+SpMA=
Date: Tue, 11 Aug 2020 20:15:03 +0000
Message-ID: <e634f7c3373e40148bdd66540bd4c76e@boeing.com>
References: <8b5d5420e55b435aa578c20bd99f3407@boeing.com> <F098390D-B8CF-4121-9D5D-F2610144DE9D@fugue.com> <ae4333439bc6431d91e3b0c0bd43286a@boeing.com> <500105DD-90B0-4870-AF97-6213798221DF@fugue.com> <d4dc68ad019f44f09f7e1d791845f0b2@boeing.com>
In-Reply-To: <d4dc68ad019f44f09f7e1d791845f0b2@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.115.204.6]
x-tm-snts-smtp: BAAE475CF5B91A643CAFD1B4CBDD1F31F0A53D94A3379DC75B79A8E24893A17E2000:8
Content-Type: multipart/alternative; boundary="_000_e634f7c3373e40148bdd66540bd4c76eboeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hWZqfjwmNK2xZnuVvdWo4ncKQhU>
Subject: Re: [v6ops] [EXTERNAL] draft-ietf-6man-grand : saving lookups
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2020 20:15:19 -0000

From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Templin (US), Fred L

Hi Ted,


But there’s no reason for an overlay topology. The question is, is there a way for it to know which stations to send the multicast too? If so, then it should just iterate across that set of stations using unicast, which is a lot faster. If not, then it probably has no choice but to broadcast. Sorry if these are naive questions—I haven’t really dug around in the details of how WiFi routers do multicast, so I have just enough knowledge to appear really ignorant.


With my NBMA case, there is a an overlay routing system which has proactive full
knowledge of all active nodes on the link and knows how to unicast-forward to any
of those nodes at any time. In the WiFi base station case, unless there is some way
for the base station to learn the list of active nodes on the link then broadcast is
the last resort. Or, the base station could start out life with a NULL topology table
and then add new nodes as it receives multicasts. Then, as its topology table grows,
it may be able to eventually start to do unicasts to those nodes it has previously
learned about from broadcasts – a learning bridge, in other words – useful?

What’s the expression? “What goes around comes around,” I think. This is all very reminiscent of IP over ATM, as described in RFC 2225 and RFC 2226. There are servers, MARS, to emulate broadcast, using sequential unicasts.

The problem is that with CLIP (classical IP over ATM), this sort of thing was compulsory even in small networks, so it is cumbersome. ATM didn’t survive, in large measure, because it was less than ideal for carrying IP packets. In a parallel universe, a universe in which this IP thing was not developed concurrently with Ethernet, it might do well.

Large broadcast or multicast domains are still a bad idea. Having to go NBMA for everything, to mitigate the large broadcast domain problem, is like having stuck with CLIP, to this day. It didn’t happen. For targeted, special purposes, that’s something different.

Bert