Subject: [dnssd] draft-cheshire-dnssd-hybrid-01

From: peter van der Stok <[email-masked]>
Date: Wed, 05 Feb 2014 13:00:58 +0100

Hi Stuart,

Thanks for your draft. It may go a long way to solving service discovery 
in building control networks.
There is one aspect that my need additional text.
In the draft you delegate ownership of each defined link name to the 
hybrid proxy.
This works when discovery is wanted from a host not present on the local 
link but connected via the router to the local link.

In contras, we should like to do discovery with unicast messages to the 
hybrid proxy from hosts present on the local link when the local link 
may be stand alone, or connected to the Internet infrastructure (e.g. 
DNS) via the router.

Addition of text to discover the presence of the hybrid server on the 
local link by hosts present on the local link would be appreciated. Is 
that possible or do you prefer an additional document?

In addition, it is not clear to me that the hybrid server will support 
the insertion of PTR records to allow the addition of device discovery 
domains, such that the building1.example.com domain can be used instead 
of the .local domain from devices connected to the local link.

Peter

-- 
Peter van der Stok
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 24 Feb 2014 18:41:05 -0800

On 5 Feb, 2014, at 04:00, peter van der Stok <[email-masked]> wrote:

> Hi Stuart,
> 
> Thanks for your draft. It may go a long way to solving service discovery in building control networks.
> In the draft you delegate ownership of each defined link name to the hybrid proxy.
> This works when discovery is wanted from a host not present on the local link but connected via the router to the local link.
> 
> In contras, we should like to do discovery with unicast messages to the hybrid proxy from hosts present on the local link when the local link may be stand alone, or connected to the Internet infrastructure (e.g. DNS) via the router.
> 
> Addition of text to discover the presence of the hybrid server on the local link by hosts present on the local link would be appreciated. Is that possible or do you prefer an additional document?

The hybrid server is discovered like any other authoritative DNS server -- via NS records (i.e. DNS delegation).

> In addition, it is not clear to me that the hybrid server will support the insertion of PTR records to allow the addition of device discovery domains, such that the building1.example.com domain can be used instead of the .local domain from devices connected to the local link.

The hybrid server exists on the same link as the *services*.

The domain enumeration records need to exist in the environment of the *client*, which may be on the other side of the planet.

This client-side information can be configured manually by the network operator where the client is, or manually by the user of the client (for an example of such manual configuration, see my email of 2nd February).

Stuart Cheshire

---

From: peter van der Stok <[email-masked]>
Date: Tue, 25 Feb 2014 08:51:47 +0100

Hi Stuart,

Apparently, I was not clear.
A stand-alone network without DNS server but with a Hybrid server.
How to discover the Hybrid server?

> 
> The hybrid server is discovered like any other authoritative DNS
> server -- via NS records (i.e. DNS delegation).
> 

Peter
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 25 Feb 2014 10:39:47 +0200

> How to discover the Hybrid server?

To get hybrid proxy provided services visible to clients, you will need these elements in the equation:

[1] appropriate DNS server and DNS search path provided to clients (via DHCP, DHCPv6, or RA options)

[2] DNS-SD records within domain in the search path that have subdomain PTR records that point at individual links

[3] DNS based path that leads from DNS server address provided to the client to hybrid proxy owning the subdomain(s)

To provide [2], you MUST either have DNS server/forwarder with appropriate records ( see http://tools.ietf.org/html/draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-00 for example of doing it one way zeroconf and without god DNS server ), or just point clients at ‘hybrid server’ and let it also provide [2] records and do forwarding. However, this works only if your network really _has_ only one link as hybrid proxy has to be directly connected to the links.

For [3], you need either own magic (again, my draft), or normal DNS server with NS records as Stuart explained.

Cheers,

-Markus

---

From: peter van der Stok <[email-masked]>
Date: Wed, 26 Feb 2014 10:30:34 +0100

Hi Markus,

Given the information I received up till now, I understand the folowing 
solution to the discovery of the Hybrid proxy from clients on a 
stand-alone link or mesh.

There is a link or a mesh network with one hybrid proxy.
The link or mesh is completely stand-alone (no border router, no prefix 
has been distributed)
There is no DNS- or dhcp server connected to the stand-alone mesh or 
link.
Clients on the link or mesh have no access to DHCP or DNS, but can reach 
the Hybrid proxy with mDNS.

The clients on the link or mesh can use mDNS for discovery.
Given the large amount of clients on the mesh, unicast to the hybrid 
proxy instead of multicasting is preferred.

  To discover the existence of the hybrid proxy on the mesh or link, I 
understood the following process.

- The Hybrid proxy enters PTR records with label b._dns-sd._udp and with 
value the domain name.
e.g. b._dns-sd._udp  PTR building1.example.com.
- The client sends a query with mDNS querying all PTR records with label 
b._dns-sd._udp.
- The Hybrid proxy is the only node answering by sending a unicast with 
the queried PTR records.
- The client can learn the port and IP address from the answer and use 
it for unicast queries to Hybrid.

Is this a correct interpretation of your answers?

The next step is what happens when the border router is connected in a 
later stage and prefixes are distributed.

Peter

Markus Stenberg schreef op 2014-02-25 09:39:
> [2] DNS-SD records within domain in the search path that have
> subdomain PTR records that point at individual links
> 
> [3] DNS based path that leads from DNS server address provided to the
> client to hybrid proxy owning the subdomain(s)
> 
> To provide [2], you MUST either have DNS server/forwarder with
> appropriate records ( see
> http://tools.ietf.org/html/draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-00
> for example of doing it one way zeroconf and without god DNS server ),
> or just point clients at ‘hybrid server’ and let it also provide [2]
> records and do forwarding. However, this works only if your network
> really _has_ only one link as hybrid proxy has to be directly
> connected to the links.
> 
> For [3], you need either own magic (again, my draft), or normal DNS
> server with NS records as Stuart explained.
> 
> Cheers,
> 
> -Markus
>

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 26 Feb 2014 12:56:24 +0200

On 26.2.2014, at 11.30, peter van der Stok <[email-masked]> wrote:
> Given the information I received up till now, I understand the folowing solution to the discovery of the Hybrid proxy from clients on a stand-alone link or mesh.
> 
> The link or mesh is completely stand-alone (no border router, no prefix has been distributed)
> There is no DNS- or dhcp server connected to the stand-alone mesh or link.
> Clients on the link or mesh have no access to DHCP or DNS, but can reach the Hybrid proxy with mDNS.
> 
> Given the large amount of clients on the mesh, unicast to the hybrid proxy instead of multicasting is preferred.
> 
> To discover the existence of the hybrid proxy on the mesh or link, I understood the following process.
> 
> - The Hybrid proxy enters PTR records with label b._dns-sd._udp and with value the domain name.
> - The client sends a query with mDNS querying all PTR records with label b._dns-sd._udp.
> - The Hybrid proxy is the only node answering by sending a unicast with the queried PTR records.
> - The client can learn the port and IP address from the answer and use it for unicast queries to Hybrid.
> 
> The next step is what happens when the border router is connected in a later stage and prefixes are distributed.

I’m not sure if your case in general works. 

Typically, most of the clients do mdns _and_ dns-sd, if available, but dns availability _won’t_ suppress mdns lookups. I would say that hybrid proxy is worth using only where there are _small_ single broadcast domain_s_ (more than one of them). I don’t know if your description fits either of those criteria (you have single large broadcast domain).

If you have (for example) fruity device, and you browse for printers, it would look at _ipp._tcp.building1.example.com (unicast) AND at _ipp._tcp.local (multicast) in your case, and you would just get double the traffic but no practical benefit.. or perhaps I’m missing something here, and if so, please let me know :)

Cheers,

-Markus

---

From: peter van der Stok <[email-masked]>
Date: Thu, 27 Feb 2014 09:21:30 +0100

Hi Markus,

Two answers to your doubts:
(1)
> Typically, most of the clients do mdns _and_ dns-sd, if available, but
> dns availability _won’t_ suppress mdns lookups.
I expect a layer between application and discovery in the clients, in 
which a selection can be made between mDNS, unicast to Hybrid, unicast 
to DNS based on selection criteria to be formulated (e.g domain name).
(2)
> I would say that
> hybrid proxy is worth using only where there are _small_ single
> broadcast domain_s_ (more than one of them).
I do quote draft-ietf-dnsssd-requirements-01, section 2.2:
" Enabling service discovery on IEEE 802.11 networks requires that the
    number of multicast frames be restricted to a suitably low value, or
    replaced with unicast frames to use the MAC's reliability features."
and section 2.3:
" First, Link-Local multicast scope [RFC4291] is defined as a
    single-hop neighborhood.  A single subnet prefix in a wireless mesh
    network may often span multiple links, therefore a larger multicast
    scope is required to span it [I-D.ietf-6man-multicast-scopes].  mDNS
    is not currently specified for greater than Link-Local scope."

I expect that a mDNS request with realm-local scope to all MPL 
forwarders will take more link resources than a RPL unicast to the 
Hybrid server possibly located at the root of the DODAG.

Peter

Markus Stenberg schreef op 2014-02-26 11:56:
>> Given the information I received up till now, I understand the 
>> folowing solution to the discovery of the Hybrid proxy from clients on 
>> a stand-alone link or mesh.
>> 
> Typically, most of the clients do mdns _and_ dns-sd, if available, but
> dns availability _won’t_ suppress mdns lookups. I would say that
> hybrid proxy is worth using only where there are _small_ single
> broadcast domain_s_ (more than one of them). I don’t know if your
> description fits either of those criteria (you have single large
> broadcast domain).
> 
> If you have (for example) fruity device, and you browse for printers,
> it would look at _ipp._tcp.building1.example.com (unicast) AND at
> _ipp._tcp.local (multicast) in your case, and you would just get
> double the traffic but no practical benefit.. or perhaps I’m missing
> something here, and if so, please let me know :)
> 
> Cheers,
> 
> -Markus