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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 11 August 2020 21:03 UTC

Return-Path: <Fred.L.Templin@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 068833A0C78; Tue, 11 Aug 2020 14:03:56 -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 GVzVLKCmIi8t; Tue, 11 Aug 2020 14:03:54 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 0CC6E3A0C62; Tue, 11 Aug 2020 14:03:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 07BL3nWB012566; Tue, 11 Aug 2020 17:03:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1597179831; bh=7K4a52e+DpuAdGLFB90Y6JiNp19z8XV5tWVVJRlE6C4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZhiyEIS3q4b7tLuXcuvCrPxwSeqtUprnufcyZa4nI/mPScpN7qxJZXbA0d9Q+PZUp AW0SpnfBVmCDCDyTZg1jfsc8essF8hM184HFTOGbPqyggjVPPcifUzEaBP6u1Sv82B 1cKGYQn2AnSkJcsxlxtcZY1qBX96PVK7xYXIEK9Zqziy/Ez11D4QjnItuFbM2FqIxT GMYIZPktM3mXC9ih/1YM45rzgS13ONtDILPNhmwvKkZ/+Mtc4gbzgn7vsl86GRILE8 /3YuCEGpBWFPM8hw0CRLbbL3IJgg9sMEhYdRSRObWrIkexpApyUxHb0+1xbuD/y2D+ flfJawgzdUsRQ==
Received: from XCH16-01-12.nos.boeing.com (xch16-01-12.nos.boeing.com [144.115.66.70]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 07BL3elj011464 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 11 Aug 2020 17:03:40 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-01-12.nos.boeing.com (144.115.66.70) 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 14:03:39 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 11 Aug 2020 14:03:39 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "Manfredi (US), Albert E" <albert.e.manfredi@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: AQHWcBZDozN/TbgM60KTlQsJYZVlgakzzV2A//+XgaA=
Date: Tue, 11 Aug 2020 21:03:39 +0000
Message-ID: <5e83c523ef934837816c37845ca19e26@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> <e634f7c3373e40148bdd66540bd4c76e@boeing.com>
In-Reply-To: <e634f7c3373e40148bdd66540bd4c76e@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 5DD679CABE7B80E4BF7980DF0B521BD2751A02664AADA9F40BC3CE14EA8D990A2000:8
Content-Type: multipart/alternative; boundary="_000_5e83c523ef934837816c37845ca19e26boeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/pOFvuRxtxWRJzOFQ68UlbOkCEqQ>
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 21:03:56 -0000

Bert, read draft-templin-* (several drafts); they all say Boeing on them. Please get a grip
and understand that whether you like them or not they are products of our company,
and they are going to move forward.

Thanks - Fred

From: Manfredi (US), Albert E
Sent: Tuesday, August 11, 2020 1:15 PM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; Ted Lemon <mellon@fugue.com>
Cc: IPv6 List <ipv6@ietf.org>rg>; v6ops@ietf.org; Bob Hinden <bob.hinden@gmail.com>
Subject: RE: [EXTERNAL] [v6ops] draft-ietf-6man-grand : saving lookups

From: ipv6 <ipv6-bounces@ietf.org<mailto: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