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

Ted Lemon <mellon@fugue.com> Mon, 07 October 2019 13:18 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 DA68E1200CC for <homenet@ietfa.amsl.com>; Mon, 7 Oct 2019 06:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 DUZhKQdg0iLV for <homenet@ietfa.amsl.com>; Mon, 7 Oct 2019 06:18:25 -0700 (PDT)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 BBD49120096 for <homenet@ietf.org>; Mon, 7 Oct 2019 06:18:25 -0700 (PDT)
Received: by mail-ot1-x32e.google.com with SMTP id m19so10938815otp.1 for <homenet@ietf.org>; Mon, 07 Oct 2019 06:18:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8iI7zrI7LnsTNPY2QDtBOiucWPcVavayg3s543G/Nz0=; b=K2VPkZYu27bGD1KZ0jltT5GDfNw4Hwq6VhR2lKblW8MYjzSz8Qf53KuvtsrSc/LsGq +v60tsyr7PV2fwDaUi7ukNOPx9nInvDzDik7sBkDv16rTsaGVHH1k67fg7EQqdVv6kkk W4XbSY7S+N+ot2pAwyKGIBFtG8RXwlyvXhPw70/Ak/j61nX+pzhzoaipsUhxgNuRVC9u EqZcApWTnenn63vfJPu/uTNGTihkRcI0IBBHktiTpGIK3xcOGu34PF6vbYGcoj2EwdEE wjgasyqPaaKPmxUmOdS5A6NuIw5GG5wWyfVpv1j/PnWVI3509y1rBCX2dLcIVJmeh67M 2+vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8iI7zrI7LnsTNPY2QDtBOiucWPcVavayg3s543G/Nz0=; b=VYUx4Vnkk9MABmp4RecToDM3rGeDVYIHuTt2YJlQERDNL4tR/u+dipnRXy3J+TcY3Z eSGpU3tA437LClGM/g/JiSm4LVlfKvqEjpE29DnDfI+jkrYpSYokkr9MFTAhgxd0jtSo RH7aHj/oo6dAhkkoI9tms21BmUOQ4VKvmZsohq8aawViqZVgCwiqV/g///NuNNyn+ABt jUU87+miKXO0+tPa5T941tIvz5UkEEA7vIQ+e5L0nHBC5dg3Gr9o4wtor213qxVBmQIQ cgcWpwiayPfEQPUSSNsEy+2n/MaRSAfTKoPJkicQyyfOSr9bBb2TD8hSo+Fjva+NJJgW Oe1A==
X-Gm-Message-State: APjAAAWSMTCb9FYMpwe7W42nxU89G2pxdnSNs5ywxNG7Z021NCU+IUUv w+uD1kgr+kfuV1iDTVu6WO1MNg==
X-Google-Smtp-Source: APXvYqwq/SqHFaw+wxsLKPOul8qinkRBZASNyaUSnMW//3V4ihZMFB+ixQBiVEMf3X5Gq2ftRwz22w==
X-Received: by 2002:a9d:68cd:: with SMTP id i13mr21889231oto.25.1570454304835; Mon, 07 Oct 2019 06:18:24 -0700 (PDT)
Received: from [10.254.144.120] (072-182-058-035.res.spectrum.com. [72.182.58.35]) by smtp.gmail.com with ESMTPSA id n9sm4661459otn.4.2019.10.07.06.18.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Oct 2019 06:18:23 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <B7D14C5A-437D-4AB4-8BF2-7208986F5235@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_724F6DE4-2CE6-44C7-A0D6-30989B25BC39"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\))
Date: Mon, 7 Oct 2019 06:18:22 -0700
In-Reply-To: <FF34E138-469F-40F6-BA8F-7AE02F878B29@employees.org>
Cc: Markus Stenberg <homenet@ietf.org>, 6MAN <6man@ietf.org>, Mikael Abrahamsson <swmike@swm.pp.se>
To: Ole Troan <otroan@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> <E50D25C7-8EF1-4685-9442-021F019F7F62@employees.org> <60B2C15B-E126-4F86-AA9A-9EB9A6C0EB2D@fugue.com> <FBCD2C32-9CBE-4499-A3E9-0FF4991E34DF@employees.org> <A5D12082-3D6A-4540-9AFB-2530D4FA6A32@fugue.com> <FF34E138-469F-40F6-BA8F-7AE02F878B29@employees.org>
X-Mailer: Apple Mail (2.3600)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/zQXVnCFaCLh42sHXiJSj6lPe7aU>
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: Mon, 07 Oct 2019 13:18:28 -0000

On Oct 6, 2019, at 11:36 PM, Ole Troan <otroan@employees.org> wrote:
> I believe HNCP has solved the technical problem it set out to do. Allow for an automatically configured, arbitrary topology network with multiple exits.
> The deployment challenge of that is that every router must support HNCP and must support SADR.

The question I have about this is: if nobody is shipping this, how do we know that the problem is solved?   We have zero operational experience for the intended use case.   HNCP experts setting it up for themselves or people they know is not the target use case.  At present everybody who’se tried seriously to use this stuff has looked at the source code.

>>> I know why I haven't implemented HNCP on software I work on... and I also know that there aren't any very realistic alternatives either.
>> 
>> Can you say why that is?
> 
> Quite a few reasons, some which might be not relevant to your case of course.
> - the pendulum between distributed algorithms and centralized controllers is for the problems I'm working on largely towards the centralized side

This makes sense.

> - it's quite a lot of work. it requires a new routing protocol, it requires a changed forwarding paradigm, and it requires integration with a lot of features

Yes.   This is a big problem.

> - it does not support the case "permissionless extensions of the network".

That seems to contradict your first point—if you want permissionless extension, isn’t that by definition not centralized?

>>> RA guard isn't applicable in a RFC7084 context. RFC7078 talks about routing and routers. I.e. what happens at the network layer.
>> 
>> You mean at the “internet layer,” I assume?
> 
> No, I mean the network layer. RA guard operates as a layer violating feature at the data-link layer.

Hm, okay, fair point.   But I think that we need to say how RA guard works on home networks if we don’t want to have to guess.   Possibly this is not 6man work, but it feels relevant to me.

>>> If you are talking about what happens at the often integrated bridge CE devices have, then sure, they could implement RA Guard.
>>> But having your additional router sending RAs across the homenet might not be a particularly good idea anyway.
>> 
>> Why not?   What would be a better idea?   I don’t mean to say that using RAs in this way is ideal, but what’s the alternative that doesn’t involve the vast complexity of per-host routing?
> 
> I don't understand how it would work. Add another router with it's own link. How would you get addresses for that link? Make them up from ULA? And then advertise that in an RA upstream with the MSR option?
> That would put a lot of responsibility on the hosts of getting things "right".
> And what if you added two of your routers, or connected them differently?
> 
> Per-host routing is in itself trivial and likely scales orders of magnitude further than you need. But there are problems with MLSR that are unsolved / not solved to my liking yet there.

If you’re adding this to an RFC 7084 network, there are things that you can do that can work as long as RA guard isn’t present, and that achieve the limited goal of being able to have devices on one network communicate with devices on the other.   Indeed, a ULA would work well for this use case.   Allocate a single ULA, and then allocate prefixes out of it for the various networks.

I think that if you want to add more than one router, HNCP+Babel is a sensible way to do it.   But this is only required for leaf-to-leaf communication.   A device on the home network will have an RA advertising transit to each leaf prefix, and will either have IPv6 connectivity from RFC 7084, or from another prefix advertised on the link.

The problem with per-host routing is that it means I have to implement and deploy per-host routing, which I never want.   And as you add leaf networks, the number of routes being propagated starts to snowball.   I believe that this can be made to work for use cases I care about, but it’s in no way a “good” solution.  The main problem with it is that it means I have to write code to do it.   I’d rather not write that code if I don’t have to.

> for "permissionless extensions of the network" there isn't much else than NAT.
> Your other likely option is an ND proxy. If you are very sure that nothing else can be added to the network (we don't want to build a spanning tree protocol out of ND).

Yeah.  That is the exact situation I would most like to avoid, so I don’t want to be walking in that direction.

> Because you don't like the mechanisms for automated subnet assignment? ;-)

On the contrary, if HNCP were widespread, that’s what I’d be using.   HNCP would be my first choice for this.   I’d still like that to be the long-term solution.   But what can I build into a leaf router _today_ to make this work when the edge router doesn’t run HNCP?  :)

> And no, I'm not suggesting we should do MLSRv2 as a competitor for HNCP. MLSRv2 would also require an update to every router, and a network operator allowing extensions to the network.

BGP?   ;)

>> This is why I’m asking people if they have knowledge of what is actually deployed.   I think this is the right place to ask, but if you disagree, I’m open to suggestions.
> 
> I do not disagree. I think having that feedback loop from implementation/deployment/operational experience is important.

Okay.   Thanks for the deep engagement on this.   I’m not sure we agree on what to do, but it’s very useful to hear what you are thinking about this.