Subject: [homenet] biggest L2 domain

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Dec 2019 09:54:08 -0500

I thought that we wrote somewhere in RFC7368 that the Homenet router should
collect as many ports as possible together into a single L2 zone.
I can't find that text right now. Did it go away?

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!

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Gert Doering <[email-masked]>
Date: Fri, 13 Dec 2019 18:26:46 +0100

Hi,

> 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 :-)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Fri, 13 Dec 2019 18:45:29 +0100

Gert Doering wrote on 13/12/2019 18:26:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
Hi,

I agree that learning L2 topology is not trivial and is not covered in 
the current Homenet daemon.

Learning at boot time or port status change would require stopping 
forwarding to avoid loops, which is undesirable in networks where 
devices are plugged and unplugged (think wired laptop moving around 
interrupting media streaming on another device)

I was thinking of something like bringing up all ports in L3 at boot 
time, on a dedicated VLAN, see what's there, and then "annealing" the 
network later.

So if two (or more) ports are detected as only having hosts, they could 
later be merged to be one L2 domain after some period of stable operations.

One name and prefix would be primary, whilst the others would be 
configured initially but gradually removed (as leases die), which would 
be the equivalent of a phased
renumbering event with a flag day.

But other alternative of treating all ports as L3 ports forever would 
seem to require hierarchy in the naming solutions (which doesn't exist 
today).

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Dec 2019 13:42:46 -0500

> 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.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Dec 2019 15:11:21 -0500

> not necessarily written down somewhere.

It wasn't intended to be automatic, but rather based upon provisioned
knowledge that a device had.

The intent was to avoid routing-at-layer-two (i.e. spanning tree, etc.), but
not to replace switches.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Dec 2019 15:13:05 -0500

Ted Lemon <[email-masked]> wrote:
    > 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.

I'm not arguing for doing this.
I'm asking what happened to the text that said that we weren't.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 17 Dec 2019 20:08:31 +0100

> collect as many ports as possible together into a single L2 zone.

Section 3.3.2?