Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Toke Høiland-Jørgensen <toke@toke.dk> Tue, 15 August 2017 19:38 UTC

Return-Path: <toke@toke.dk>
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 9AA6A126BF3 for <homenet@ietfa.amsl.com>; Tue, 15 Aug 2017 12:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=toke.dk
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 3sytbwfRdMNB for <homenet@ietfa.amsl.com>; Tue, 15 Aug 2017 12:38:46 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825271200F3 for <homenet@ietf.org>; Tue, 15 Aug 2017 12:38:46 -0700 (PDT)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1502825923; bh=dBCQjHFrDHnMbdrZxZQGOGHL8+GiEOjhaIN6+hrIuNw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=f273giSnHH94NuGVWIpPJ2Uigahsa0juuOvWh3DfrNIj+YbhUlsWfQ13uufd11kOJ G/wsU4SbEIpQcTHAVC97eK63Vo+d5eFx11NN0sClA7TSuhvyLzHm5e9ZieI1Xyn2h+ YSxgSoE265bhSWzNbGpyKok/K743lpmKLSPPDoGbBwjpmWLE2K6t+5XbGtA8yFpZx2 Hc2UYOVN+uwILB3A8lTYefjY6SVLWI4vYjz4e0G4GqtJKX/bCswzCjXwLpH26Wmq7y ZoKZmfn99RFcWYvHT1mVQ96GzS9Cml3tl+lVFf1HA0/YOTzEWKN9xZW+9gNIIupQDr 59FF8j6LRvF9w==
To: Ted Lemon <mellon@fugue.com>
Cc: Juliusz Chroboczek <jch@irif.fr>, HOMENET <homenet@ietf.org>
In-Reply-To: <FB44A942-9DE3-4CE6-88C5-402B20756462@fugue.com>
References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <CAPt1N1m+218+FX_G+2W-msDWmxP8XXMKF9S0faTeCBnEEzk1uw@mail.gmail.com> <877eyaz2jm.fsf@toke.dk> <CAPt1N1m5nVGD-y2VrbkoTEPTs4qF98oRxGuvd-Has1yzuS0fmg@mail.gmail.com> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <CAPt1N1=oiU+DbjD6izOBNJOnC25d=-S3ARqFxydRfWLEet5mEQ@mail.gmail.com> <87valry4o7.fsf@toke.dk> <FCAD81FA-BBA0-45B0-8F1F-D1D5FD010484@fugue.com> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <E3E75086-BF36-4F59-86BD-7FFDAFE772AB@fugue.com> <87fuctxdrc.fsf@toke.dk> <FB44A942-9DE3-4CE6-88C5-402B20756462@fugue.com>
Date: Tue, 15 Aug 2017 21:38:47 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <877ey4y62g.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/ds3wGiVp6NAC-qv-2RqO75QhbGw>
Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 15 Aug 2017 19:38:49 -0000

Ted Lemon <mellon@fugue.com> writes:

>> Depending on the type of performance problem. If the performance problem
>> is general, yes. If it is specific to DNS, there's no reason to not use
>> the connection for other things; and the "send queries to all upstreams"
>> solution will automatically converge to use the best-performing upstream.
>
> I think we are wandering off into nonsense territory here.   Have you
> observed this sort of problem in the field?   If so, can you describe
> what happened?   If not, why would we optimize for it?

If you consider flaky ISP DNS servers to be "nonsense" you are clearly
more fortunate with your ISPs than me. And that's before even going into
the DNS censorship issue; in my part of the world ISP DNS servers are
broken *by design*.

>> Right, so if this is the case, how about we specify that routers MAY (or
>> maybe even SHOULD) support MPvD-specific resolver addresses, and
>> advertise the fact over HNCP. And that if a router receives such an
>> announcement from another router it MUST announce the MPvD-specific
>> resolver addresses over DHCP/RA. This way we ensure that *if* a router
>> on the network implements MPvD it is going to work for the whole
>> network; but routers can still opt to not implement the functionality
>> itself if the implementer doesn't want to pay the implementation cost.
>
> Can you describe for us what this implementation cost is that you want
> to avoid?

Can you describe for us how multiplying the number of resolvers by N (or
MxN if we follow your suggestion of running a full set of resolvers on
every router) is *not* going to incur a significant implementation and
debugability cost?

-Toke