Subject: [mdnsext] mdnsext & SLP

From: Garret Peirce <[email-masked]>
Date: Fri, 21 Jun 2013 11:05:41 -0400

I'm curious why SLP is not a potential solution to the hurdle of 'service
discovery beyond the local link'.

Ignoring client support for the moment, SLP seems like an existing, defined
mechanism for scalable SD.
It seems this draft aims to develop an alternate method to do so.

Finding some history in older IETF zeroconf archives(
http://osdir.com/ml/ietf.zeroconf/2002-07), I'm wondering if the thoughts
to the question from a decade ago would be different today?

>So it seems to me that either DNS-SD has to scale gracefully all
>the way up to huge, or that I will have to bite the bullet and
>build in something tougher like SLP anyway. And then why would I want to
do DNS-SD as well?

As anything else, both this DNS-SD hybrid extension and SLP have their
levels of complexity and choreography.
SLP has hosts advertise their services to a central depository, and the
client must use this depository (SA/DA) to locate known services.   Whereas
in the DNS-SD extension method, the clients use the hybridProxy to actively
search for services. I wonder if the latter might become chatty , the need
for suppression of certain responses and use of LLQ potentially tricky (are
LLQ responses  supported by all common clients?)

Perhaps a current discussion/comparison of DNS-SD/SLP would be a worthwhile
exploration for SD beyond the local link.  I could envision room for both
depending on one's environment, ex. DNS-SD (as it exists) used for manually
controlled entries and SLP for dynamic ones.

Seeing OpenSLP 2.0 was recently released, there is an interesting note
mentioning future mDNS integration - 'Version 2.1 is slated to include
features like mdns integration'.  http://openslp.org/

Appreciate any thoughts as I try to understand the differences of each
approach.

-- 
Garry Peirce
Networkmaine, University of Maine System

---

From: Michael Sweet <[email-masked]>
Date: Fri, 21 Jun 2013 11:26:22 -0400

Garret,

On Jun 21, 2013, at 11:05 AM, Garret Peirce <[email-masked]> wrote:
> I'm curious why SLP is not a potential solution to the hurdle of 'service discovery beyond the local link'.

Speaking from experience, SLP is painful without a DA, and you need an accessible DA on every network segment.

> Ignoring client support for the moment, SLP seems like an existing, defined mechanism for scalable SD.

AFAIK, SLP does not solve the multiple-network problem.

> It seems this draft aims to develop an alternate method to do so.

Well, I think the goal is to come up with a solution to the multiple-network problem that scales while retaining dynamic registration/advertising of services.  The focus may be on mDNS and DNS-SD (because that drove the petition to fix things...) but I suspect that solutions for DNS-SD and mDNS would also work for extending SLP.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Garret Peirce <[email-masked]>
Date: Fri, 21 Jun 2013 12:15:27 -0400

Michael,

I had thought the purpose of an SLP DA was to enable SD across subnet
boundaries.
The idea being there could be a number of them setup for different reasons
(ex. organizational/serviced scoped).
ref: RFC2608 section 12.

On Fri, Jun 21, 2013 at 11:26 AM, Michael Sweet <[email-masked]> wrote:

> Well, I think the goal is to come up with a solution to the
> multiple-network problem that scales while retaining dynamic
> registration/advertising of services.  The focus may be on mDNS and DNS-SD
> (because that drove the petition to fix things...) but I suspect that
> solutions for DNS-SD and mDNS would also work for extending SLP.
>

-- 
Garry Peirce
Network Architect
1-207-561-3539

---

From: Michael Sweet <[email-masked]>
Date: Fri, 21 Jun 2013 12:43:34 -0400

Garret,

On Jun 21, 2013, at 12:15 PM, Garret Peirce <[email-masked]> wrote:
> Michael,
> 
> I had thought the purpose of an SLP DA was to enable SD across subnet boundaries.
> The idea being there could be a number of them setup for different reasons (ex. organizational/serviced scoped).
> ref: RFC2608 section 12.

*If* the DA spans the subnets, a single DA could service all of them and still be auto-detected by the UA's.  But that really only works for simple topologies where you have a common gateway or router joining the subnets.

If you use DHCP to set the DA for the UA's on each subnet, then you have to configure each of the DHCP servers to do that...  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...

---

From: David Farmer <[email-masked]>
Date: Fri, 21 Jun 2013 12:12:52 -0500

On 6/21/13 11:43 , Michael Sweet wrote:
> Garret,
>
> On Jun 21, 2013, at 12:15 PM, Garret Peirce <[email-masked]
> <mailto:[email-masked]>> wrote:
>> Michael,
>>
>> The idea being there could be a number of them setup for different
>> reasons (ex. organizational/serviced scoped).
>> ref: RFC2608 section 12.
>
> *If* the DA spans the subnets, a single DA could service all of them and
> still be auto-detected by the UA's.  But that really only works for
> simple topologies where you have a common gateway or router joining the
> subnets.
>
> If you use DHCP to set the DA for the UA's on each subnet, then you have
> to configure each of the DHCP servers to do that...  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:
>
> <http://hostname.apple.com/ipp/print>

I have experience running SLP in a large scale Campus/Enterprise 
environment, many of the things you say are a disadvantage are actually 
an advantage in such environments.

I'm not sure compatibility or interpenetration with SLP is a good idea 
or not, but something similar to the DA architecture and the ability to 
tell unicast isolated client where the DA is with a DHCP option are 
concepts I think should be considered for the dnssdext solution space.

Thanks.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Michael Sweet <[email-masked]>
Date: Fri, 21 Jun 2013 13:40:08 -0400

David,

On 2013-06-21, at 1:12 PM, David Farmer <[email-masked]> wrote:
> ...
> I have experience running SLP in a large scale Campus/Enterprise environment, many of the things you say are a disadvantage are actually an advantage in such environments.

I don't recall saying any of this was a disadvantage, merely that it was an incomplete solution.

> I'm not sure compatibility or interpenetration with SLP is a good idea or not, but something similar to the DA architecture and the ability to tell unicast isolated client where the DA is with a DHCP option are concepts I think should be considered for the dnssdext solution space.

Absolutely.  My only points are these:

1. SLP needs a DA for scalability/performance
2. SLP needs DHCP to support arbitrary subnets
3. SLP doesn't solve the name/address resolution issues called out in the charter for home networks, although DNS can fill the gap for larger/managed networks.
4. The issues with deploying SLP look similar to those faced by mDNS + DNS-SD.

---

From: Garret Peirce <[email-masked]>
Date: Fri, 21 Jun 2013 23:27:37 -0400

> 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:
>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

---

From: Michael Sweet <[email-masked]>
Date: Fri, 21 Jun 2013 23:48:59 -0400

Garret,

On 2013-06-21, at 11:27 PM, Garret Peirce <[email-masked]> wrote:
> ...
> It seems SLP is caches collected service advertisements whereas the mdsnext method demand polls for them.  

SLP with a DA caches, otherwise you have a similar amount of network traffic as for mDNS+DNS-SD.

> 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.

I don't know about that; based on discussions on the ipv6 list, even consumer routers have sufficient capacity to do some pretty advanced routing and other functions, so I don't think acting as a proxy or caching service is out of the question, particularly if the cache is not persistent or of "infinite" depth.