Re: [homenet] biggest L2 domain

Ted Lemon <mellon@fugue.com> Fri, 13 December 2019 18:42 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E29012011C for <homenet@ietfa.amsl.com>; Fri, 13 Dec 2019 10:42:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SybjV4VnnDv4 for <homenet@ietfa.amsl.com>; Fri, 13 Dec 2019 10:42:49 -0800 (PST)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343431208B4 for <homenet@ietf.org>; Fri, 13 Dec 2019 10:42:49 -0800 (PST)
Received: by mail-qv1-xf35.google.com with SMTP id k10so147396qve.7 for <homenet@ietf.org>; Fri, 13 Dec 2019 10:42:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=/kluTYzPuYSIOVw75lL3plr18RQnxHqjK0UjqLF72Vc=; b=FZ2MVV62UPYJFzpA5RmX6Ea3DGKE7INMc29wGkwBbStFH8B9jwKeOHMg+0pbd0G9Ly wSPFqaFTC6XB1YTY5J2ZsxVOLecqc2eQKEU6EcfdfCFlrLNB5Ttq2xWpTQDxC8AlLxlL aaJbAYYs6F8R+tePiwIjHbUFrqfBpfrFj4KjHbLI2neNiUVWy7x6XYZuk+LqegnmNDSH F4AzO/DKtJ0yXmHIKCD3zZ+aoo35QJYSVuvKqh1VjK3p+WCE6VEgWTuKkdUK5nHswrsK f5eceCNjklWin29Xu6PRtMHYMT+3CLdlgehfWC4V9LP8BQYd+NQaHFRlxCPelD5WnS6B ESXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=/kluTYzPuYSIOVw75lL3plr18RQnxHqjK0UjqLF72Vc=; b=Tb1j5NjbfzjpA1qYEj9y4KA3KFA3dTrnFi0x0DBdxAl8wPOyY22S07WYF8FxnSIT7Q 5mfS5n2r1Awfa4nI8fXHjf+iP+y/oBl7PoJNZk3ARHyoN1c4/ahoOPKEalQ0Oc6BHJa9 dvoMp/0LIZTpy7HZv7FbM2ZAJK+99g1d8Udx/FykvaJAnlL2XIJy/NI3QMigtyDDrvVK jsb5BfyDlHSW8Ii5+6Dy0cmi8gmAQKdQxHQ4lOlwQQP9iWQ3CcY5DN5lrxym+XE1DEpt 58av7OCWwbPGvCEnIVpfCny//XU+ffn6lUV6jK2e6adr1yfojS3GCYMmm0b8GYqqdz8F DnRA==
X-Gm-Message-State: APjAAAWQIb1sEJ/JOXxuC7LpnxCWCWL7TlhqHuO4l4JsRbAgf346E/jh 7iVWMea5JT2Ouy7YoC8+sQ1+SQ==
X-Google-Smtp-Source: APXvYqxOM+aQ5RJjkGRClQ3KTvgLDByblPTTzR/hukitHnleh7tyqaiL1TXKZEYGop//38l6HG8ClQ==
X-Received: by 2002:a0c:cd0e:: with SMTP id b14mr4997613qvm.12.1576262568260; Fri, 13 Dec 2019 10:42:48 -0800 (PST)
Received: from ?IPv6:2601:18b:300:36ee:9e0:c32:ec97:8411? ([2601:18b:300:36ee:9e0:c32:ec97:8411]) by smtp.gmail.com with ESMTPSA id c66sm3100409qkf.7.2019.12.13.10.42.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Dec 2019 10:42:47 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-340C0DB4-77F6-4D84-AF57-782BE362A388
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 13 Dec 2019 13:42:46 -0500
Message-Id: <EC907D0A-AC1C-44F9-9025-AD6B3878AFB8@fugue.com>
References: <20191213172646.GI72330@Space.Net>
Cc: Michael Richardson <mcr@sandelman.ca>, homenet <homenet@ietf.org>
In-Reply-To: <20191213172646.GI72330@Space.Net>
To: Gert Doering <gert@space.net>
X-Mailer: iPad Mail (17E177)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/yTe9IBOSCD92dhuspFbQ0tKgjnw>
Subject: Re: [homenet] biggest L2 domain
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2019 18:42:51 -0000

On Dec 13, 2019, at 12:26 PM, Gert Doering <gert@space.net> 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.