Re: [dnssd] Provisional agenda for IETF98

[Tim Chown <[e-mail]>]

Hi Stuart,

> On 19 Mar 2017, at 20:26, Stuart Cheshire <[e-mail]> wrote:
> 
> On 14 Mar 2017, at 09:20, Tim Chown <[e-mail]> wrote:
> 
>> Hi,
>> 
>> The provisional agenda for IETF98 is included below. Please let Ralph or I know if you have suggestions for changes or additions.
> 
> Thanks Tim. This looks good.
> 
> Here is the status as I see it:
> 
> 1. draft-ietf-dnssd-hybrid (Discovery Proxy) — ready to progress to the IESG.
> 
> 2. draft-ietf-dnssd-push — ready for WGLC.

Ralph and I agree, and will be acting on this very soon. One of us will need to do the shepherd writeup. I recall there is the discovery proxy IPR disclosure we need to include.

> 3. draft-ietf-dnsop-session-signal — ready for DNSOP WGLC.
> 
> Other documents I did not get done by the draft deadline, but really hope to have ready to submit when submissions re-open on Monday 27th. It would not be reasonable to expect people to discuss the content in our Tuesday meeting, but it would be good if I could have a few minutes to draw people’s attention to them.

You have 20 minutes at present. We may be able to raise that a little.

> 4. draft-cheshire-dnssd-roadmap — there are many components that make up service discovery, at various levels, and few people really understand how they all fit together. This short overview document is intended to remedy that.
> 
> 5. Discovery Broker — this is a kind of meta Discovery Proxy. From the outside it looks like a basic Discovery Proxy. Except, it doesn’t get its answers by querying using Multicast; it gets its answers by querying other Discovery Proxies. It has two purposes. One is client efficiency. Instead of a client opening three Push connections to three Discovery Proxies on three different links, the client can open a single Push connection to a Discovery Broker, which has its own connections to the relevant Discovery Proxies, and aggregates the results for the client. The second purpose is infrastructure efficiency. Instead of a thousand clients all opening separate Push connections to a poor little overloaded router on the link, the thousand clients can open Push connections to a big-iron Discovery Broker in the data centre, which has a single connection to the actual Discovery Proxy embedded in the router on the link. That way, the router on the link only has to serve a single client — the Discovery Broker.

OK, this is interesting. It touches on both the efficiency issues that were raised previously in the WG, and also the work that Ralph and Tom are doing on enterprise best deployment practices. 

> 6. Sleep Proxy — Apple has shipped this for years; I need to document it. It’s basically DNS Update, plus garbage collection, plus Wake-on-LAN magic packet. Simple, but should be documented.
> 
> 7. Advertising Proxy — this allows a device, with appropriate security, to advertise services via multicast service discovery, on a physical link to which the device is not directly attached. It has applicability for mesh networks like 6LoWPAN, where the trusted devices are conceptually part of the network, but can’t themselves use multicast. There have been efforts to support multicast on mesh networks, but this may be an overly heavyweight solution if there’s a better way to advertise services without requiring the mesh to support multicast in its full generality. It’s basically Sleep Proxy without the Wake-on-LAN magic packet.

This is what Ralph and I reserved the 20 mins for.  But if we can get WG feedback on each topic you’ve raised, that would of course be great.
> 
> 8. Zone Stitching — when clients can interrogate multiple links (e.g., via a Discovery Broker) it would be convenient if we did not have names duplicated on the different underlying links. I confess that I still don’t have a single blindingly-obvious answer to this, so I welcome discussion and suggestions. I suspect the solution might build on the Discovery Proxy. When two links are configured to not allow duplicated names, the two Discovery Proxies in question would establish a bidirectional TCP connection. When one Discovery Proxy sees a device ask (using Multicast DNS) “Is this name in use?” the Discovery Proxy would ask its peer (over the TCP connection) “Is this name already in use on your link?” and if the answer is “Yes”, then the Discovery Proxy tells the local device (using Multicast DNS) “Name already in use; pick another.”

This overlaps with previous discussions of course, and what Ted has spoken on previously.  We don’t really have a good answer for this yet. 

Tim