Re: [homenet] Support for RFC 7084 on shipping devices...

Ole Troan <otroan@employees.org> Fri, 04 October 2019 13:28 UTC

Return-Path: <otroan@employees.org>
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 82B4212001A; Fri, 4 Oct 2019 06:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 XZbGi4xerosi; Fri, 4 Oct 2019 06:28:32 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BB612085F; Fri, 4 Oct 2019 06:28:32 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [IPv6:2a02:20c8:5921:100:d9f1:37ec:73bd:aecf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id A97AA4E11A4D; Fri, 4 Oct 2019 13:28:31 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 8B30D1E7088A; Fri, 4 Oct 2019 15:28:27 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <5F0D2E3D-BE20-4421-8A37-E81E6B93B3A5@fugue.com>
Date: Fri, 04 Oct 2019 15:28:27 +0200
Cc: Markus Stenberg <homenet@ietf.org>, 6MAN <6man@ietf.org>, Mikael Abrahamsson <swmike@swm.pp.se>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E50D25C7-8EF1-4685-9442-021F019F7F62@employees.org>
References: <56255ECF-9002-4440-BA0D-665EFC4BA9C6@fugue.com> <F638F635-9A1C-409E-BDB8-C00DF00A64C8@employees.org> <alpine.DEB.2.20.1910040752050.968@uplift.swm.pp.se> <A52F076F-817D-4807-8CD6-280C2040AEBF@employees.org> <5F0D2E3D-BE20-4421-8A37-E81E6B93B3A5@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/LOLD7HkK4q3E9yuZgHs1Kt-G7HM>
Subject: Re: [homenet] Support for RFC 7084 on shipping devices...
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, 04 Oct 2019 13:28:34 -0000

Ted,

>> Homenet has solved the problem of self-configuring networks in arbitrary topologies.
> 
> If that were true, I wouldn’t be asking this question.  We’re still chugging along, but we don’t have something that nay router vender could even consider shipping right now.  There isn’t enough participation in homenet anymore for us to really iron out the kinks.  Certainly if I could count o homenet being present in routers in the home, we wouldn’t be having this conversation! :)

Since this was sent to an IETF list I assumed you were focused on standards. (And presumably also running code). :-)

>> Unless someone goes to lengths describing exactly how this is supposed to work, the idea of "simplifying" the homenet solution sounds like a recipe for failure.
> 
> I tend to agree, but wasn’t proposing that.   I was really just trying to solve the very specific problem of how I do IPv6 routing in the case I described, given the hardware that is likely to be present in the home.
> 
>> How are you going to tell the customers that you can only plug in devices in particular topologies and in particular ways.
> 
> The customer already has a router.   Suppose I want to add a router with a bunch of devices behind it, and  I know the router I’m adding will never have a second layer behind it.   Can I get it to work?   That’s the problem.
> 
>> - single router and bridging (7084)
> 
> If it doesn’t filter RA, and I control the second router, I’m okay, right?

Well, yes it isn't a router at that point, it's a bridge.

> 
>> - arbitrary topology plug and play (homenet)
> 
> Yes, that’s homenet.   It would really help if folks who think homenet is done would try to deploy it in their home using OpenWRT and see how it goes.   Seriously.   This is not a solved problem.   We’re maybe 50-60% of the way there at this point.   I’ve been trying to make progress on this ever since HNCP was declared done, and occasionally get collaboration, and indeed we may be begining to make progress agan, but we could definitely use more participation if there are folks in 6man who want this to work and imagine that it already does.

The notion of "permissionless extensions of the network" is still somewhat unresolved. HNCP allows for that, but as we know it's not well supported/deployed. I had some hopes for multi-link subnet routing (implemented how it was originally intended, not as spanning tree in ND). But I have never gotten around to flesh that out in detail. Pascal has done various stuff in this space for lowpan, which may be something to build on.

The MLSR idea is basically a /64 shared across all links. Hosts register with routers using ARO (or DHCP). Routers advertise host routes in a routing protocol between themselves. The tricky parts are of course detecting when hosts go away, detecting movement and so on.

A side meeting in Singapore perhaps?

>> - manually configured (meaning ansible, scripts or whatever automation solution external to the routers themselves).
> 
> Yech.   That’s not an option.  :]

Cheers,
Ole