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

["Templin (US), Fred L" <[e-mail]>]

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

From: ipv6 <[e-mail]<mailto:[e-mail]>> 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