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

Toke Høiland-Jørgensen <toke@toke.dk> Thu, 10 August 2017 22:07 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 ACECC131D19 for <homenet@ietfa.amsl.com>; Thu, 10 Aug 2017 15:07:56 -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 4iGjyF2uWVA0 for <homenet@ietfa.amsl.com>; Thu, 10 Aug 2017 15:07:54 -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 98FC3132464 for <homenet@ietf.org>; Thu, 10 Aug 2017 15:07:54 -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=1502402871; bh=8lWHqUDAOYW2q0rLjaAWse0A+7r1NujQLCuYIKHoi48=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nzO0W2ugEFJ+UPyuIFDL80efP07rswLkXk4rdKk9dXeI2t3Fvxb7DcsVIHgp84g1m 6zfRZTnpKn8HJkFWYITkU+UY1GhmIs99wgiLCy/xCc1YRzqSaeH0BKxbwguI6NanPU qM86BbAfhd4LOwN+xdEEMY9HmQcej22i1BLZL85YZY3T0zaAqtqvGxbw2XrV6JOScG 4tAZDRNDLjrwPqY3J86NwSNhfCspPVHaDFhk68tMcIikz8xmC1hFpFg2VAXonHPx/C EIXc4cC/3wAsE5rPlZ5mn+BI99SFPGmy4eeFBzkRk5CMCBq04MQlGe3mGrBecaZx23 dEs5WPxo5gQsw==
To: Ted Lemon <mellon@fugue.com>
Cc: Andrew Sullivan <ajs@anvilwalrusden.com>, homenet@ietf.org
In-Reply-To: <A9C8CA05-54A0-4160-B2F0-645744BD259E@fugue.com>
References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <20170810203843.xq7wxdxp27vqt4pz@mx4.yitter.info> <87wp6byvw5.fsf@toke.dk> <A9C8CA05-54A0-4160-B2F0-645744BD259E@fugue.com>
Date: Fri, 11 Aug 2017 00:07:50 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87poc3yt3d.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/OyFC4-gw96T0G0GpMm49YLp8sFw>
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: Thu, 10 Aug 2017 22:07:57 -0000

Ted Lemon <mellon@fugue.com> writes:

> On Aug 10, 2017, at 5:07 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> with the possible exception of the
>> requirement for supporting multiple provisioning domains
>
> How would you solve the problem of dual-homing without the multiple
> provisioning domain support described in the document?

We're talking about the "oh no, my netflix streams is coming from the
wrong ISP" kind of problem here, right? I.e., same DNS request gives
different answer depending on which ISP I send it to?

For one thing, I'm not convinced this is that big of a problem. I happen
to live in a country that likes to apply censorship by messing with DNS;
so I generally don't use my ISP's name servers, and have never had any
issues arising from this. So in this case a solution could just be to
ignore the issue... :)

Now, assuming that I am wrong and this is actually a serious issue that
we need to solve (of which I am not opposed to being convinced), I think
it would be feasible to come up with a solution where we could at least
allow less capable routers that do not implement the full MPvD support.
I can think of at least two ways off the top of my head:

1. Allow the router in question to offload queries to a more capable
   router elsewhere in the homenet.

2. Allow the router in question to just query all upstreams and combine
   the results (and so offload the problem to the client).


-Toke