My concern is if/how we can specify MTI (Mandatory to implement) zero-touch interoperable requirements for discovery.
In our non-constrained ANIMA work (ANI), we have MUST requirements sufficient for zero-touch discovery/interoperability (via GRASP). If we can find an agreeable MTI, then we can put it into a section that says something like "these discovery requirements are REQUIRED, unless an installation-type specification (IETF or non-IETF) replaces/amends them" installation-type = mesh-type = (6TiSCH, Thread, ISA 100 Wireless, JupiterMesh, Wi-SUN FAN, etc) If i go with coap/core-link, i can simply use coap over ff05::fd to discover the registrar. That is just expecting L3 multicast in the LLN, which luckily does sem to exist in networks such as thread and hopefully to know the registrar all the time). And we have IETF protocols such as MPL to support L3 multicast in LLN. For DNS-SD i wouldn't know a standardized zero-touch method to discover a DNS-SD/SRP server for an l3 network because mDNS is not intended to work across L3 hops but just link-local (at least with IETF standards). RFC8766 seems also like a non-zero touch optiond and complexity mismatch given how we likely wouldn't want to use it for ongoing discovery (but just unicast-DNS with SRP). We could specify that installation-types supporting discovery of a server that is known to support unicast-DNS-SD/SRP would use that to discover the registrar, and the registrar would register itself. And in minimum deployments, the registrar itself would run DNS-SD/SRP server. Thoughts ? Toerless On Wed, May 18, 2022 at 08:18:48AM +0000, Esko Dijk wrote: > Thanks for the example. I also don’t have a number-of-bits / round-trips > comparison at hand. There are various alternatives now (GRASP, CoAP > discovery, CoRE RD, DNS-SD SRP, mDNS, and ‘proprietary’ including the > distribution of Registrar location in network-wide config data). > In the selection of protocol efficiency / traffic reduction plays a role, but > certainly also aspects like footprint, code re-use & maintainability, > security (e.g. the less protocols on a device, the lower the attack surface) > and familiarity with certain protocols. > > For these reasons one implementer or standard may want to choose GRASP, while > another chooses DNS-SD SRP or CoAP discovery. All these implementations will > then not be mutually interoperable. But is this a problem? > The key thing is that within a single interoperable (IPv6) mesh standard > (e.g. 6TiSCH, Thread, ISA 100 Wireless, JupiterMesh, Wi-SUN FAN, etc) that > would choose to support BRSKI, or Constrained BRSKI, one particular method is > chosen and then also tested/certified for interoperability. > So the right details would be defined in those standards bodies for sure. > > That said, it would be good if IETF can define the best discovery options for > Constrained BRSKI and how to use those – e.g. as we do for GRASP in BRSKI. > Similar details could be added for some of the other alternatives, perhaps. > > Esko > > > From: Ted Lemon <[email protected]> > Sent: Wednesday, May 18, 2022 02:01 > To: Toerless Eckert <[email protected]> > Cc: Esko Dijk <[email protected]>; [email protected] > Subject: Re: [dnssd] CoAP resource discovery and DNS-SD > > Bear in mind that with dns name compression, you don’t repeat any domain > name—you just store a pointer for each subsequent repetition of the same > terminal label sequence. So default.service.arpa is a little longer, but > doesn’t multiply. > > On Tue, May 17, 2022 at 17:28 Toerless Eckert > <[email protected]<mailto:[email protected]>> wrote: > Thanks, Esko > > Actually a client would discover a new service instance with quering the PTR > RR, > so rfc6763 12.1. is relevant, but yes, it does ask to include all dependent > RRs. > Here is what i think is the minimum generic case for a single service > instance with one locator address. > > _service-name._udp.local PTR > service-instance-name._service-name._udp.local > service-instance-name._service-name._udp.local SRV prio weight port > service-instance-locator.local > service-instance-name._service-name._udp.local TXT 'key=value;...' > service-instance-locator.local AAAA IPv6-addr > > I have not tried to figure out how many bits that would be, especially in > comparison > to coap/core-link encoding. > > Actually, when one uses only unicast DNS and SRP, i guess you wouldn't > use .local, but .default.service.arpa, which would make all the messages > somewhat bigger > (thinking about how the ANIMA REST URLs where explicitly shortened, but then > DNS > adds the overhead back ...). I wonder how much of those details are better > defined > in the ANIMA drafts so that we do ensure interoperability... > > Cheers > Toerless > > On Tue, May 17, 2022 at 04:08:48PM +0000, Esko Dijk wrote: > > Toerless, there was also the below point in your mail: > > > > > In coap, like in GRASP, we can map all necessary service elements into > > > a single message, so we know it is a single request/reply exchange > > > > As I understand, it can be the same for DNS-SD. A good implementation would > > return the SRV record for found services and also the associated AAAA > > records to have a single request/response. RFC 6763 12.2 defines this. > > I would add to such behaviour that if the number of answers is high then > > the implementation can shorten the response by leaving out the AAAA > > records. Something that a DNS-SD server / SRP server suitable for mesh > > networks use could do. > > > > (Of course it has the downside that in any case a client still MUST be > > prepared for the case that it doesn't receive the AAAA records in the first > > response. So in that sense client complexity is a bit higher than for e.g. > > CoAP / GRASP(?) ) > > > > Regards > > Esko > > > > -----Original Message----- > > From: Esko Dijk > > Sent: Monday, May 16, 2022 09:59 > > To: Toerless Eckert <[email protected]<mailto:[email protected]>>; Ted Lemon > > <[email protected]<mailto:[email protected]>> > > Cc: [email protected]<mailto:[email protected]> > > Subject: RE: [dnssd] CoAP resource discovery and DNS-SD > > > > Hello Toerless, > > > > Ted was referring to the Service Registration Protocol (SRP) for DNS-SD as > > defined by https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-13 . > > This enables registration and discovery over generic services over unicast, > > similar to what a CoRE Resource Directory can do for CoAP resources. A > > single request/reply exchange can be used to register a device's services. > > Querying is the same as in unicast DNS-SD. > > > > For SRP you need of course a way to get an IP address of the / a SRP server > > before you can use SRP registration/querying. In OpenThread, this is done > > by e.g. including such address in mesh-network-wide configuration data. So > > then all devices that may need this, have it. > > See GetNextDnsSrpUnicastInfo() > > https://github.com/openthread/openthread/blob/main/src/core/thread/network_data_service.cpp#L262 > > for details. > > > > There's also the possibility to include a more compact set of configuration > > data that enables a device (client) to reach an SRP server over an anycast > > address ; see e.g. FindPreferredDnsSrpAnycastInfo() > > https://github.com/openthread/openthread/blob/main/src/core/thread/network_data_service.cpp#L196. > > Anycast reachability is useful for redundancy if multiple SRP servers are > > available and are kept synchronized (using e.g. > > https://datatracker.ietf.org/doc/html/draft-lemon-srp-replication-01). > > > > Some of the functions you mention may already be supported by the above > > approach. E.g. Thread defines mesh-local IPv6 addresses (described in the > > 'Thread Network Fundamentals' white paper) which would enable a device to > > advertise a particular service only in mesh scope, while other services > > could be advertised with greater scope by using a global or ULA IPv6 > > address. And the proxy function you mention may not be needed if multiple > > synchronized SRP servers are used, or a single SRP server that serves all > > mesh networks plus all regular non-constrained networks in an installation > > site. > > Note that proxying between mDNS devices and SRP-using devices is provided > > for (by https://datatracker.ietf.org/doc/html/draft-sctl-advertising-proxy > > and rfc8766). Such that on-mesh constrained devices don't have to use > > multicast / mDNS. > > > > Regards > > Esko > > > > > > -----Original Message----- > > From: dnssd <[email protected]<mailto:[email protected]>> On > > Behalf Of Toerless Eckert > > Sent: Saturday, May 14, 2022 16:02 > > To: Ted Lemon <[email protected]<mailto:[email protected]>> > > Cc: [email protected]<mailto:[email protected]> > > Subject: Re: [dnssd] CoAP resource discovery and DNS-SD > > > > > > To discover a service via mDNS is not not necessarily quite LLN friendly. > > > > You need to query/reply for all the RR involved in a service, which is > > if i remember AAAA, SRV, PTR, TXT and maybe CNAME. Admittedly > > i have not tried to work out how many bits this is, but there is > > also the question of how many packets this will end up being in the > > widey deployed implementations and who takes care of minimizing/optimizing > > that. So there is a cost to this more comples layering. RRs, messages, > > packets. > > > > In coap, like in GRASP, we can map all necessary service elements into > > a single message, so we know it is a single request/reply exchange. > > > > Yes, i would definitely prefer to minimize the amount of multicast, > > especially given how those LLN can really only flood them across > > the whole network, but both DNS and COAP could be on par in that > > department. > > > > Due to the proprietary nature of Thread i have not been able to figure > > out how it proposes to instantiate and discover the server instances > > of DNS or COAP that should be used. But thatss also where another > > complexity can come in: > > > > coap/dns > > server > > coap/dns > > client .... 802.15.4-net .... border-rtr .... ent-networks ..... > > server > > ... > > service-server > > > > The server we may want to discover on the client may not necessarily be > > connected to the 802.15.4 network, but the enterprise network behind it, > > (most simple designs would hope/expect for the service we want to use to > > be running on the border-rtr). > > > > So, it seems to me i need some form of scoping of service/resource > > request/replies from clients between those that should be only > > resolved within the 802.15.4 network, and those that should resolve > > (also) across the ent-network behind it. I am not quite sure how > > to most easily do this, but off the top of my head it looks as > > if i wanted some simple proxy function on the border router which > > on a per-service/resource basis decides whether to forward the request > > upstream to the coap/dns server in the enterprise network or not. > > And with coap i can see how that proxy function is easily implemented, > > and the concept of such a proxy is discussed in coap. > > > > Replicating that functionality in DNS would be quite more complex i fear. > > > > Cheers > > Toerless > > > > On Fri, May 13, 2022 at 08:01:37PM -0400, Ted Lemon wrote: > > > The registry/mapping problem is where we fell down. Why are you trying to > > > use Core for this anyway? DNS-SD works fine—that’s what we’re using for > > > Thread, for example. You can just do a DNS UDP query or use DNS Push > > > rather > > > than using multicast if you use SRP to update the DNS server. > > > > > > On Fri, May 13, 2022 at 19:57 Toerless Eckert > > > <[email protected]<mailto:[email protected]>> wrote: > > > > > > > Thanks, Ted > > > > > > > > Any pointer to Kerry's work in this regard ? I was looking through her > > > > expired > > > > draft, but i didn't see anything getting to that exact point > > > > (draft-doi-core-parameter-option looks like related, but i can't really > > > > make heads or tails out of it). > > > > > > > > So lets say: > > > > > > > > REQ: GET /.well-known/core?rt=<resource> > > > > > > > > RES: 2.05 Content > > > > Content-Format: 40 > > > > Payload: > > > > </b>;rt=<resource>;p=<prio>;w=<weight>;proto=<string>, > > > > ... > > > > > > > > I am just defining in the spec for my resource that it has additional > > > > option > > > > link-target attributes. p= for a numeric priority value, w= for a > > > > numeric > > > > weight attribute and proto= for a string enumerating protocol details. > > > > And these are the same parameters as what i'd use for the same resource > > > > (oops: service) when using DNS-SD. > > > > > > > > It seems as if rfc6690 didn't actually create a registry for those > > > > link-targets > > > > but simply created rt= and if= link-targets and just created a registry > > > > for > > > > the values of rt= and if=. Which raises the question if i could simply > > > > specify p/w/proto to be normative in the context of the specific > > > > resource, > > > > and if not whether those addtiional link-targets would have to be > > > > specified as > > > > updated to rfc6690... > > > > > > > > Cheers > > > > Toerless > > > > > > > > On Fri, May 13, 2022 at 07:22:41PM -0400, Ted Lemon wrote: > > > > > We were never able to figure that out either. The mapping from Core > > > > > RD in > > > > > particular to DNS-SD is something that the DNS-SD working group > > > > > actually > > > > > pursued for a while (Kerry Lynn worked on this pretty heavily for > > > > > about a > > > > > year). > > > > > > > > > > On Fri, May 13, 2022 at 7:20 PM Toerless Eckert > > > > > <[email protected]<mailto:[email protected]>> wrote: > > > > > > > > > > > Dear CoAP WG > > > > > > > > > > > > I am trying to figure out how to use CoAP discovery as specified in > > > > RFC7252 > > > > > > (and expanded in rfc6690 and rfc7390), but i can not figure out how > > > > > > one would encode basic parameters of a resource, such as those > > > > supported > > > > > > in DNS-SD, rfc6763: > > > > > > > > > > > > When discovering more than one instance of a resource, such as > > > > possible, > > > > > > when using multicast discovery as on rfc7252, clients will have to > > > > figure > > > > > > out, > > > > > > which instance of a resource to select. DNS-SSD has priority and > > > > > > weight > > > > > > parameters associated with each instance. How would one > > > > > > describe/encode > > > > > > such instance and weight ? > > > > > > > > > > > > When discovering one or more instance via DNS-SD, the discoering > > > > > > client > > > > > > may further select the best instance in terms of interoperability, > > > > > > functionality > > > > > > and performance based on one or more key=value property pairs > > > > describing > > > > > > the instance. How is this done in CoAP ? > > > > > > > > > > > > Thanks a lot! > > > > > > > > > > > > Toerless > > > > > > > > > > > > _______________________________________________ > > > > > > dnssd mailing list > > > > > > [email protected]<mailto:[email protected]> > > > > > > https://www.ietf.org/mailman/listinfo/dnssd > > > > > > > > > > > > > > -- > > > > --- > > > > [email protected]<mailto:[email protected]> > > > > > > > > -- > > --- > > [email protected]<mailto:[email protected]> > > > > _______________________________________________ > > dnssd mailing list > > [email protected]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/dnssd > > -- > --- > [email protected]<mailto:[email protected]> -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
