Re: [mdnsext] mdnsext & SLP

[Garret Peirce <[e-mail]>]

> And you still have the issue of resolving hostnames and/or routing
addresses for the services
> for example, a printer might advertise its printer service with any of
the following:
    >service:printer:ipp://192.168.0.100/ipp/print
    >service:printer:ipp://10.0.1.100/ipp/print
    >service:printer:ipp://[fe80::0100]/ipp/print
    >service:printer:ipp://hostname.local./ipp/print
    >service:printer:ipp://17.1.2.100/ipp/print
    >service:printer:ipp://hostname.apple.com/ipp/print
>The only ones that are likely to be directly usable are the last two..

I see your point about the variety of advertised service types, but I might
look at that as built-in filtering.  In my environment, I'd say if a device
doesn't have an FQDN or a globalAddr, I'd not want the service known
(outside the subnet).  If the other types were desired, I'd think namespace
collisions would have to be dealt with.
It seems SLP is caches collected service advertisements whereas the mdsnext
method demand polls for them.
At the expense of somewhat less realtime data, caching advertised services
would seem easier and more manageable than having proxies present on each
subnet to manage the polling.  I'd not desire to operate the hybridProxy
service on the subnet's router as a potential option it mentions; it'd seem
unduly intensive for a router to assume that role (managing and caching
queries, suppressing/rewriting others) - some other host would be required
to assume this role on each subnet.

If I read it correctly, each client query results in an mcast poll by the
subdelegated proxy. This could setup the overall system to be chattier than
desired. If 5 clients are looking for the a service on the same remote
link, the target subnet will be subject to 5 different mDNS requests by the
proxy.

With that, and I believe sharing David's thought, what about a model where
clients use DNS-SD, but instead of DNS using the hybridProxy model, the SLP
DA model of learning services is used.
ex. Using a snooping 'helper' to unicast forward link-local (ACLd) mDNS
service advertisements (~UAs) to populate centralized DA(s).
If snooping is done at L2, perhaps other data could be inserted (location
info) in the advertisement ('local', becomes 'Building1') here.
DAs accept/deny advertisements via policy.
DAs meshed and may share data via policy (~mSLP).
DHCP option(s) could supply a host with a specific DA to use and/or a
DNS-SD browse domain if desired.
Similar to the draft, a client DNS-SD request would be sent to it's DNS
server which ,if necessary, would be delegated to the appropriate DAs which
would then service the dynamic service request and respond to the client.

-- 
Garry Peirce
Networkmaine, University of Maine SystemSystem