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

"Templin (US), Fred L" <> Wed, 12 August 2020 12:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51BE63A1264; Wed, 12 Aug 2020 05:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FvxPZ05TpvYe; Wed, 12 Aug 2020 05:36:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66B203A1262; Wed, 12 Aug 2020 05:36:25 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 07CCaIjq012728; Wed, 12 Aug 2020 08:36:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1597235783; bh=rZ7I6prsNvaTDBKHVJj5SLsKUD145088OFgSMWMMr4w=; h=From:To:CC:Subject:Date:From; b=Fc9Ymr/mQxYpuDGfXFy4Z8gs7vgWgpfd2HtwMhmz6ALwYSqOfiuok5eYeCNLEtjDX DCLbdFNCupzf7UG9Vn2P2ghpr/aPyQ8lCGlp8C778mafb+o+sz2lGgJb6BFCLuLCp4 EY/jQH41G8h1JNabSZstDSDFGZJwHAqRn/EeJSiPFIBTie++u8fUQtNO99hh+9AvHd 7NX9RV7Vqx+bbtovUg5AhyNzy3KA+H280Gu5aGUS8J9KAX9ei8zI1g/d2N7LYKzGy8 wy5bhcxnMPUL0ow47cvykrHIe1/RMmECT+eGXq4sG1Eba6AeoUI/kgKAOHOvHnNUsd NFud9xBd9vzCg==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 07CCa21E011100 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 12 Aug 2020 08:36:04 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 12 Aug 2020 05:36:01 -0700
Received: from ([fe80::1522:f068:5766:53b5]) by ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Wed, 12 Aug 2020 05:36:01 -0700
From: "Templin (US), Fred L" <>
To: "Manfredi (US), Albert E" <>, Ted Lemon <>
CC: Bob Hinden <>, "" <>, "IPv6 List" <>
Thread-Topic: [v6ops] draft-ietf-6man-grand : saving lookups
Thread-Index: AdZwpRSiEe6oNB+AQlqLrpXmMcXdqQ==
Date: Wed, 12 Aug 2020 12:36:01 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 369CB51F666DFC148D1916B4DD85A4BAF27D35EFF85D3F40ECAE03B6880A7AF02000:8
Content-Type: multipart/alternative; boundary="_000_7f9b1337d1324bb1a6d4a952b245c2c7boeingcom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Aug 2020 12:36:27 -0000

Hi, it has come to my attention that the tone of this message may have been inappropriate.
I apologize to the lists in general and to Bert in particular for invoking a company name in a
non-technical way. Instead, I believe the documents can stand on their technical merit, and
will continue to work with the IETF to gain consensus.

Thanks - Fred

From: ipv6 [] On Behalf Of Templin (US), Fred L
Sent: Tuesday, August 11, 2020 2:04 PM
To: Manfredi (US), Albert E <>om>; Ted Lemon <>
Cc: Bob Hinden <>om>;; IPv6 List <>
Subject: RE: [EXTERNAL] [v6ops] draft-ietf-6man-grand : saving lookups

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 <<>>; Ted Lemon <<>>
Cc: IPv6 List <<>>;<>; Bob Hinden <<>>
Subject: RE: [EXTERNAL] [v6ops] draft-ietf-6man-grand : saving lookups

From: ipv6 <<>> 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.