Subject: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Apr 2019 14:02:25 -0400

prplMesh solves the wifi broadcast domain issue.
   https://prplfoundation.org/working-groups/prplmesh/

I don't think we can fight this.  I'm upset that this is a gated
organization, and I hate it more than you.  Perhaps we can ask for a formal
liason, perhaps via Broadband Forum.

My question is how can we use HNCP to help manage this.
I don't know, as I haven't read their specification, but I'd like to figure
it out.   I think it's further layer-2 hacks inspired from 30 years of living
in IPv4.

A reason we need to delve into prplMesh is that it permits us to hairpin
traffic between two wifi devices to go through the (security) gateway so that
they can't attack each other.

I, like Juliusz, think we can do this better in layer-3 with much less complex
machinery, but I'm not sure that Homenet should solve this problem itself.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 02 Apr 2019 21:06:28 +0200

>From their website: « prplMesh is an open-source, carrier-grade and
certifiable implementation of the WiFi Alliance’s Multi-AP specification. »

That's a purely layer 2 solution that relies on a central controller.
It depends on IEEE 1905:

  https://en.wikipedia.org/wiki/IEEE_1905

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 3 Apr 2019 00:12:59 +0000

> >    <url mauled by corporate policy>
> 
>   <url mauled by corporate policy>

You can get the Wi-Fi Alliance MAP (branded EasyMesh) spec that prpl is implementing from the WFA website (after providing your name and contact info if you aren't a member):
https://www.wi-fi.org/file/multi-ap-specification-v10 

You can also see the prplMesh code in its current (incomplete -- the project is still underway) state at:
https://github.com/prplfoundation/prplMesh 

I am involved in the joint BBF effort that they mentioned. If someone wanted to join that project (it's free to join -- just requires agreeing to IPR policy and BSD+Patent open source license) and suggest and provide code for HNCP, they could. But since this is a purely Layer 2 network (routers will break it), the HNCP would really only be for other routers (e.g., IoT gateways attaching a Thread network) that aren't part of the Multi AP L2 network. If you'd like more info for joining the joint BBF/prpl project, let me know.
Barbara

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Apr 2019 21:42:28 -0400

STARK, BARBARA H <[email-masked]> wrote:
    > I am involved in the joint BBF effort that they mentioned. If someone
    > wanted to join that project (it's free to join -- just requires
    > agreeing to IPR policy and BSD+Patent open source license) and suggest
    > and provide code for HNCP, they could.

I will followup with you, unicast.

    > But since this is a purely Layer
    > 2 network (routers will break it), the HNCP would really only be for
    > other routers (e.g., IoT gateways attaching a Thread network) that
    > aren't part of the Multi AP L2 network. If you'd like more info for
    > joining the joint BBF/prpl project, let me know.

If the border routers are on the same L2 as the extensions, then it shouldn't
be a problem.  If there is a more complex HNCP network, then we could
probably simulate the L2 scenario with VXLAN, configured by HNCP.

There are probably some advantages to doing that as well.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 03 Apr 2019 17:44:59 +0200

> If there is a more complex HNCP network, then we could probably simulate
> the L2 scenario with VXLAN, configured by HNCP.

If memory serves, VXLAN requires support for multicast, which HNCP+Babel
doesn't provide.  There's a set of IBM (?) extensions to VXLAN that avoid
the use of multicast, I'm not a fan.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 03 Apr 2019 17:58:59 +0200

> the use of multicast, I'm not a fan.

Another issue is that since VXLAN emulates a layer 2 network, it doesn't
have any means to regulate MTU; hence, it requires either network-layer
fragmentation or the use of jumbograms.

Not a fan, sorry.

-- Juliusz

---

From: Tore Anderson <[email-masked]>
Date: Sun, 7 Apr 2019 19:28:27 +0200

* Juliusz Chroboczek

> the use of multicast, I'm not a fan.

I think you'll find very few deployed production VXLAN networks using
multicast in the underlay for BUM flooding. It is far more common to have
some kind of control plane (could be distributed or centralised) that takes
care of that. EVPN (RFC 7432), for example.

To get rid of multicast in the underlay, you'd at minimum need to
distribute information in HNCP about which routers are interested in
receiving BUM traffic for a given VXLAN ID, so that all routers can install
forwarding table entries for BUM traffic pointing to all the remote tunnel
endpoints (VTEPs). BUM frames will then be copied and sent unicast to all
the remote VTEPs (this process is called «Head End Replication»).

More advanced control planes (like EVPN) will also distribute information
about where individual MAC addresses are located, so that there is no need
to flood and learn unknown unicast. Works like a charm.

Tore