Re: [homenet] biggest L2 domain

[Ted Lemon <[e-mail]>]

On Dec 13, 2019, at 12:26 PM, Gert Doering <[e-mail]> wrote:
>> On Fri, Dec 13, 2019 at 09:54:08AM -0500, Michael Richardson wrote:
>> In testing, we have found a device that does not put it's 5-"LAN" ports into
>> a bridge.  That's probably a missing configuration, but in the meantime, we
>> have an interesting HNCP and naming setup!
> 
> My understanding of "homenet" and "HNCP" devices has always been "every 
> single hole in the box is a routed port".  Now that's my understanding and
> not necessarily written down somewhere.
> 
> Magically grouping ports into a common L2 network and then un-grouping
> them in case one of them turns out to have another HNCP device connected
> sounds like an interesting challenge, to say the least :-)

Homenet in general is an interesting challenge—that was kind of a given when we started.   It’s definitely true that at least some substantial part of the Homenet effort, specifically the CeroWRT work, assumed one link per port.

Unfortunately, what we’ve seen is that multi-router vendors are _all_ assuming a flat link layer: bridging rather than routing.   This isn’t ideal in some ways, but it does give much better UX than having e.g. every WiFi AP on a different link, because the latter case results in routine connection dropping.

If we want to do better than the current state of the art in the market, we need to not adopt solutions that provide worse UX.   So one-link-per-port and one-link-per-AP is probably not a good direction to go.   If we want to accomplish whatever that accomplishes, we should figure out how to do it in a way that doesn’t reduce usability.

As for the HNCP case, there’s actually no reason why we need to assume that because two routers are plugged into the same link, it’s a point-to-point link.   If there’s more than three stations plugged into the “link” and two of them are routers, then the two routers can use the link for transit, and the other stations can use it for connectivity.

If it turns out that there is some performance benefit to making a port-to-port, point-to-point link for the router pair, then we can do that adaptively.   That’s an optimization: it need not be where we start, and indeed back when we were initially working on this, I don’t think there was any assumption that we would try to constrain links to being either point-to-point or multi-station.