Re: [dnssd] Provisional agenda for IETF98

Markus Stenberg <markus.stenberg@iki.fi> Mon, 20 March 2017 08:08 UTC

Return-Path: <markus.stenberg@iki.fi>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6C41296C8 for <dnssd@ietfa.amsl.com>; Mon, 20 Mar 2017 01:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level:
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 lMsHyEM6Syl7 for <dnssd@ietfa.amsl.com>; Mon, 20 Mar 2017 01:07:59 -0700 (PDT)
Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.229]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5D31296CE for <dnssd@ietf.org>; Mon, 20 Mar 2017 01:07:59 -0700 (PDT)
Received: from poro.lan (80.220.131.63) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 58A591F800B027BC; Mon, 20 Mar 2017 10:07:52 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <2C65F0EC-180C-49FD-9871-15B58C49AE68@apple.com>
Date: Mon, 20 Mar 2017 10:07:50 +0200
Cc: Tim Chown <Tim.Chown@jisc.ac.uk>, Ralph Droms <rdroms.ietf@gmail.com>, "dnssd@ietf.org" <dnssd@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <11497C4D-07FF-498B-B53E-2A97DA808446@iki.fi>
References: <DCC07B2D-2F03-4B9B-B1C4-82BD442AD4BE@jisc.ac.uk> <2C65F0EC-180C-49FD-9871-15B58C49AE68@apple.com>
To: Stuart Cheshire <cheshire@apple.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/36rNyE5PsRLeJnhnnDAo1rnE_Vc>
Subject: Re: [dnssd] Provisional agenda for IETF98
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 08:08:02 -0000

On 19 Mar 2017, at 22.26, Stuart Cheshire <cheshire@apple.com> wrote:
> 8. Zone Stitching — when clients can interrogate multiple links (e.g., via a Discovery Broker) it would be convenient if we did not have names duplicated on the different underlying links. I confess that I still don’t have a single blindingly-obvious answer to this, so I welcome discussion and suggestions. I suspect the solution might build on the Discovery Proxy. When two links are configured to not allow duplicated names, the two Discovery Proxies in question would establish a bidirectional TCP connection. When one Discovery Proxy sees a device ask (using Multicast DNS) “Is this name in use?” the Discovery Proxy would ask its peer (over the TCP connection) “Is this name already in use on your link?” and if the answer is “Yes”, then the Discovery Proxy tells the local device (using Multicast DNS) “Name already in use; pick another.”

I have thought quite a bit about this over the years (less recently, as I am mostly working on non-IETF stuff).

I am not very fond of discovery proxies talking with each other; you wind up with O(N^2) connections given N links. 

Instead, I would probably do this as function of discovery broker; either

a) it provides rewritten information to its clients (somewhat fishy, as if mdns info contains computer-42, and there is another computer-42, you would wind up with e.g. computer-42-2 for one of them)

b) discovery broker <> discovery proxy action is actually bidirectional, and DB can tell DP to force client to rename.

Either design is relatively simple given devices that do not move. 

However, in presence of moving devices, I am somewhat uncertain on what is the correct way; as device moves, it gets new IP address, so how to correlate that X.link1.example.com is actually X.link2.example.com? I can think of few obvious heuristics but given recent work in IPv6 address pseudorandomization per link, they seem error prone and therefore not advisable. Therefore I am currently leaning towards design

c) DB just shows (DNS-SD) services, even if they are duplicate (omitting extra ones?), and they point to host names on various links that may not be unique. In other words, just omit conflict resolution across links.

or even

d) DB just shows (DNS-SD services) for each link; based on cursory reading of RFC 6763, nothing prevents PTR _http.tcp.example.com => site on X._http._tcp.link1.example.com

I am not quite sure if d) is valid, but at any rate, I am really leery of options a and b currently due to how they interact (or actually do not interact _well_) with moving hosts.

Cheers,

-Markus