[Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes)

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 14 February 2017 18:13 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9D0AB1296DC for <anima-bootstrap@ietfa.amsl.com>; Tue, 14 Feb 2017 10:13:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hIG0CxvPIGFq for <anima-bootstrap@ietfa.amsl.com>; Tue, 14 Feb 2017 10:13:11 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F601296DE for <anima-bootstrap@ietf.org>; Tue, 14 Feb 2017 10:13:11 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F3E07200A3; Tue, 14 Feb 2017 13:34:33 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5855C6381A; Tue, 14 Feb 2017 13:13:07 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima-bootstrap <anima-bootstrap@ietf.org>
In-Reply-To: <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl>
References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 14 Feb 2017 13:13:07 -0500
Message-ID: <18113.1487095987@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/yoL7Lnk5cwO0sDTui_U3NJ_abTA>
Cc: Toerless Eckert <tte@cs.fau.de>, consultancy@vanderstok.org
Subject: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes)
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: anima-bootstrap@ietf.org
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2017 18:13:13 -0000

peter van der Stok <stokcons@xs4all.nl> wrote:
    > We just did our own mDNS (students did years ago) and have no
    > experience with
    > existing code.
    > What was the precise question?

It's a good question. What *IS* the question :-)

We have had the discussion about use of GRASP M_FLOOD vs mDNS for discovery
of the Join Proxy by the pledge.   We have had some indirect feedback
("heresay") from implementers to the effect thta the M_FLOOD stuff
"is IETF ivory tower nonsense, and we should stop inventing new vanity

(paraphrased, and unattributed.  Sorry Brian: not my words, and I'm relaying
them third or fourth-hand, and I sure wish that said people would communicate
directly, but I think corporate reporting structures get in the way of some
of that)

There are some esthetic reasons to prefer use of M_FLOOD. This has to do with
ANIMA being a self-contained system.

There is also a claim that mDNS is already present in many small
devices. RFC6763 even says that some ethernet chips can autonomously answer
mDNS queries when the device in question is in low-power mode!

But there are some real technical claims about why mDNS does not suit:

The specific claim is that we can't do unsolicited announcements using
mDNS.  https://tools.ietf.org/html/rfc6762#section-8, section 8.2 says:

   A Multicast DNS responder MUST NOT send announcements in the absence
   of information that its network connectivity may have changed in some
   relevant way.  In particular, a Multicast DNS responder MUST NOT send
   regular periodic announcements as a matter of course.

The rfc6763 DNS-SD process makes it pretty clear that discovery involves a
query and a reply, and that responses may be multicast such that they are
easily cached.  6762 says a lot about TTL and how often things are cached.

I myself do not quite understand the entire interaction.  I observe that
on networks I am part of that, my mDNS daemon (avahi), always has a list of
seldom (even never!) used services in it's cache.

For instance:
knothole-[~](2.1.5) mcr 10002 %avahi-browse -vat | wc -l

knothole-[~](2.1.5) mcr 10003 %avahi-browse -vat | grep -i Mumble
+ credil IPv6 lapeche                      Mumble Server local
+ credil IPv4 lapeche                      Mumble Server local

I'm sure that NOBODY has ever asked the network if there was a Mumble
server around.  Clearly, when it first started, it had a reason to announce
itself, but that value should have a TTL that after the several hundred days
of uptime for the "lapeche" machine must have expired.  So I'm unclear how
reconcile what I read in the specifications ("MUST NOT send regular priodic
announcements") with what I see in practice.

It might be that in the end we don't care about the anonimity of the pledge.
If the pledge can ask the network about Join Proxy, then there is nothing
to stop us from using mDNS here.

On the other hand, M_FLOOD is as certainly useable, and is rather simple.
I had very little problem implementing it myself.  I also think that every
Join Proxy is also an ACP node, and so it will want to M_FLOOD about it's
ACPness, and so I see little downside here.

I do not have horse in this race:  I just don't want to be ignored by
developers... who granted, have not come to this conversation.

(I hear lots of anti-IETF rhetoric from Linux kernel developers, most of whom
have never posted any question to an IETF list, ever!)

Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-