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

[peter van der Stok <[e-mail]>]

Hi Michael,

I saw Brian's response.
Just a four additional remarks by me, just to show my point of view.
See below.

Michael Richardson schreef op 2017-02-14 19:13:
> peter van der Stok <[e-mail]> 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
> protocols."
> 
> (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!

<pvds>
As said before, discovery is a "popular" subject with everybody coming 
up with its preferred solution.

I can imagine that within the anima context specific discovery functions 
are wanted or omitted;I have no opinion.
However, the bootstrapping process is an interesting one and deserves 
attention outside anima.
For those other operational environments, different discovery functions 
may be used.
I like to point out mDNS due to its long-standing existence.
If bootstrapping is taken over by other SDOs, I expect them to often 
choose something different from GRASP or mDNS. (fact of life).
</pvds>
> 
> 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.
<pvds>
The beginning of section 8 says:
"
    Whenever a Multicast DNS responder starts up, wakes up from sleep,
    receives an indication of a network interface "Link Change" event, or
    has any other reason to believe that its network connectivity may
    have changed in some relevant way, it MUST perform the two startup
    steps below: Probing (Section 8.1) and Announcing (Section 8.3).
"
Much of the text of rfc6762 is about suppressing superfluous traffic.
The method relies on repetitive querying and reactive responding, with a 
response at responder re-activation (see above).
There is a lot of operational experience here, and deserves attention.
</pvds>
> 
> 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
> 174
> 
> 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.
<pvds>
Did we? IMO, almost impossible in an unsecured bootstrapping network.
Once keys are distributed, pledge looses it identity and starts afresh 
(I reckoned)
</pvds>
> If the pledge can ask the network about Join Proxy, then there is 
> nothing
> to stop us from using mDNS here.
<pvds>
Or anything else dependent on the operational environment of the SDO 
using the bootstrapping protocol.
</pvds>
> 
> 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 <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap