> In dnssd we have the “stitching” topic on our plate, around operation of > dns-sd > in unmanaged multi-link networks. So this is timely discussion.
Aha, excellent. > We’re beginning work on a BCP for the use of the discovery/advertising proxy > in > enterprise/campus networks, where there is administrative configuration, and > scalability is a concern. The stitching topic would likely form part of a > corresponding BCP for unmanaged operation, as per a multi-link homenet. I could be wrong, but I believe that stitching could be just as useful in managed networks. I'm not especially enthused by the solution suggested in Section 5.1 of dnssd-hybrid-05 (making a single hybrid proxy ubiquitous through link-layer magic). > The proxies ask about (discover) services on the link(s) they serve on behalf > of the (remote) querier. For general info on how dns-sd works, see > https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-05, Section 5 in > particular. The draft suggests that the hybrid proxy does not speak mDNS, but that it gets the information from an existing mDNS cache (last paragraph of 5.1). It appears that Markus' OpenWRT implementation follows this model. As a general rule, I'm not overly keen on solutions that require dependencies between daemons, but Markus and Steven have a good track record of beating such constructs into compliance. > For more info on that, see > https://www.ietf.org/proceedings/97/slides/slides-97-dnssd-hybrid-proxy-00.pdf Will do, thanks. > The other thing to be aware of is that there is “long lived query” support for > the proxies being defined via the DNS Push Notifications and DNS Session > Signalling drafts (https://tools.ietf.org/html/draft-ietf-dnssd-push-09 and > https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-01). Oh my. Is that meant to be optional? Thanks for all the info, -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
