[Anima] DNS-SD in GRASP - draft-eckert-anima-grasp-dnssd-04

[Esko Dijk <[e-mail]>]

Hi all,

From a DNS/DNS-SD background and interest I started looking into draft-eckert-anima-grasp-dnssd-04.  Also saw some earlier list discussion on this topic (GRASP + DNS-SD).

It looks like the draft mainly aims to provide a “multi-hop mDNS like functionality over an ACP by using GRASP” with unsolicited (flooded) service announcements, plus service queries. That looks quite useful to have (looking at draft-eckert-anima-services-dns-autoconfig-02 for the motivation for this.)

First question is, why do we want to define a separate GRASP i.e. CBOR format for the DNS(-SD) information? For example in CoRE WG for constrained nodes currently the draft draft-ietf-core-dns-over-coap-01 defines the re-use of the DNS format and no specific redefinition of this format as CBOR. And this intends to work for constrained nodes (like e.g. ACPna?)   So if we still want to use a CBOR based format we should have a clear motivation for this. (I understood there may be some concerns on code size of the DNS format parser?) And ideally in case CoRE WG or another WG does start to define a CBOR-based DNS format (there was talk about this at IETF 115, opportunity for even more compact representations) then such format would ideally be equal to the one carried in GRASP, I think. Otherwise we will have so many different formats!

Re-using the existing DNS formats will save a lot of redefining things, now and in the future. If there are worries that some DNS-SD features (like e.g. ‘_sub’)  are too complex for ACP-nodes then the draft could focus on a particular constrained ‘profile’ of DNS-SD that rules out such constructs. So, a generic IETF-wide new encoding of DNS-as-CBOR is maybe useful, but doing this for GRASP specifically? I have some doubts here.

Second question is, do we need to better motivate in the draft the 100% distributed nature of the service discovery mechanism? Since the dnssd WG is now moving towards more centralized approaches, avoiding mDNS and avoiding multicast/flooding: using Service Registration Protocol (SRP). In this solution  there are 1 or a few SRP Registrars to which nodes can register their service(s); and DNS clients may discover those services again using (unicast) DNS queries to one of the SRP Registrars. Perhaps one motivation is that in the bootstrap scenario, no SRP Registrars are defined yet so hence SRP cannot be used. And the case of multiple SRP Registrars requires automatic sync’ing between Registrars which is complex / not suitable for an ACP. And a single SRP Registrar could be possible but is then a single-point-of-failure and nothing works if this drops out.

Third question, what if every ACP-node starts flooding some service(s) – is that scalable to 100s or 1000s of nodes? Maybe we want to avoid this situation. It wasn’t clear to me yet if such use cases are intended. E.g. draft-eckert-anima-services-dns-autoconfig-02 mentions “SSH server” as a service which is what every ACP-node would have.

Regards
Esko