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

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 11 Aug 2020 17:20:11 +0000

Hi Ted,

Indeed, I was not expressing this as a criticism. I wonder if there’s a way to get that kind of reduction for regular NS/NA pairs. I think for the “I want to send a packet to foo” case, this is easy; the question is, what about during SLAAC?

I have more or less punted on the subject of SLAAC and consider the NBMA links I am
dealing with as link-local-only. SLAAC brings the problem of what to do about DAD
and MLD. I think on-link prefixes on large NBMA links are an unnecessary burden
and should be avoided – do you see it differently?

Address resolution is a different question, though; if a node on the NBMA link wants
to resolve the address of a subnet router for a target destination it can send NS(AR)
to the solicited-node multicast address corresponding to the target. The “multicast”
will then go to exactly one node, which is the target subnet router, and the resultant
NA(AR) is unicast back to the (single) node that sent the NS. Very efficient, and
again without disturbing the massive numbers of other nodes on the link.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Aug 2020 13:35:49 -0400

> and should be avoided – do you see it differently?

No, I think you’re making the right choice for your use case. But for a typical WiFi network, the scale is smaller both in terms of time and number of nodes.
 
> again without disturbing the massive numbers of other nodes on the link.

Do WiFi base stations implement this correctly, or do they broadcast?

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 11 Aug 2020 18:18:40 +0000

Hi Ted – see below for response to your question:

In the NBMA case, we leverage unicast routing in an overlay BGP routing topology
based on the NS target address. For a WiFi base station, it could use broadcast
but that might not scale well if the number of nodes in the broadcast domain is
large. Alternatively, it could do the unicast/multicast emulation the same as
for the NBMA case if an overlay BGP routing topology is established.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Aug 2020 14:22:51 -0400

> for the NBMA case if an overlay BGP routing topology is established.

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.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 11 Aug 2020 19:33:17 +0000

Hi Ted,

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?

Fred

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 11 Aug 2020 20:15:03 +0000

From: ipv6 <[email-masked]> On Behalf Of Templin (US), Fred L

Hi Ted,

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Aug 2020 13:47:28 -0700

> Do WiFi base stations implement this correctly, or do they broadcast?

I would expect that WiFi Base Stations multicast. However, understand what that means. 

On the air interface, they are either transmitting or not. In the receiving NIC, the question is whether or not they store the message; if they are not configured to receive a certain multicast group, regardless of transmission type, they receive and store the message and then forget that they have done so, re-using the buffer for the next message. If they forward the message on, it uses the bandwidth on the other side, whatever it is, with the same destination address. 

The place where one might distinguish “broadcast” from “multicast” is on a data center switch, where “multicast” might mean keeping a list of relevant ports and only sending to them. They want to send a message once. If they are sending the same message several times, “to whom” is an important question.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Aug 2020 16:57:07 -0400

> The place where one might distinguish “broadcast” from “multicast” is on a data center switch, where “multicast” might mean keeping a list of relevant ports and only sending to them. They want to s…

Hm. What I do know about WiFi is that actual multicast messages are not acknowledged (because they can’t be) and are therefore sent at lower data rates, so that multicasts occupy much larger time slices per packet. A multicast is notionally only intended for a subset of all connected nodes. If the WiFi base station knows which nodes are interested in a particular multicast address, and that number is small, then it would nearly always be faster to transmit the message to each node as a unicast.

The question is, for a particular WiFi AP, can it know which of its connected WiFi nodes are interested in a particular NS, or do we have to multicast it to every node?

If this is known in the data center, then it must be known on the AP, right?

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 11 Aug 2020 21:03:39 +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 <[email-masked]>; Ted Lemon <[email-masked]>
Cc: IPv6 List <[email-masked]>; [email-masked]; Bob Hinden <[email-masked]>
Subject: RE: [EXTERNAL] [v6ops] draft-ietf-6man-grand : saving lookups

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Templin (US), Fred L
Hi Ted,

Bert

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Aug 2020 22:02:39 +0000

Hello Ted

Some APs and controllers snoop the protocols and turn broadcasts to unicast day or drop them. The problem is that snooping gives us only an imperfect view of who is connected with IPv6.

I know for having written such code and tons of tricks, some of which we published either as drafts or patents.

We found the result to be non-satisfactory largely because of the limitations of snooping. So we brought RFC 8605 yo the IETF with no IPR attached.

I guess others will have to go through the same hassles ad we did and still do before they realize why we ended up with a stateful ND, not for all situations but for many modern use cases that involve a solid state in the network. Including APs. And fabrics.

I’m happy that Fred uses BGP, we do that too in eVPN. But how do you feed BGP? If the host does not speak BGP then we need a host to router interface that has similar properties but is abstract to the routing protocol.

There’s already 2 protocols, RPL and RIFT, that benefit from RFB 8505 advertisements to inject (redistribute) host addresses.

Take care,

Pascal

Le 11 août 2020 à 22:58, Ted Lemon <[email-masked]> a écrit :

 On Aug 11, 2020, at 4:47 PM, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:
On the air interface, they are either transmitting or not. In the receiving NIC, the question is whether or not they store the message; if they are not configured to receive a certain multicast group, regardless of transmission type, they receive and store the message and then forget that they have done so, re-using the buffer for the next message. If they forward the message on, it uses the bandwidth on the other side, whatever it is, with the same destination address.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Aug 2020 18:08:44 -0400

> We found the result to be non-satisfactory largely because of the limitations of snooping. So we brought RFC 8605 yo the IETF with no IPR attached. 

vCard Format Extensions?

But yes, what you say makes sense, assuming you meant RFC 8505. :)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Aug 2020 22:15:29 +0000

Fat fingers little screen 🤣

Regards,

Pascal

Le 12 août 2020 à 00:09, Ted Lemon <[email-masked]> a écrit :

 On Aug 11, 2020, at 6:02 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
We found the result to be non-satisfactory largely because of the limitations of snooping. So we brought RFC 8605 yo the IETF with no IPR attached.

vCard Format Extensions?

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 11 Aug 2020 23:00:57 +0000

Hi Pascal,

It is called the “OMNI Interface”, but I wouldn’t call it a “host” to router interface.
The “host” could be a multi-addressed behemoth that connects a multitude of IoT
devices, networks or virtual machines – it might even be as big as my cellphone,
or even bigger still.

Thanks - Fred