Subject: Re: Relationship DNS-SD and SLP

From: Bernard Aboba <[email-masked]>
Date: Sun, 21 Jul 2002 22:24:05 -0700 (PDT)

> One thing that does bother me is the link-local nature dns-sd (via its
> mDNS heritage).  That seems to limit scalability and also makes life
> hard in small routed networks.

I think you've got it backwards. It is the m(ulticast) in mDNS that
creates a potential scalability problem. One response to that is to limit
the scope of the multicast. Hence, linklocal multicast name resolution
(LLMNR).

Other responses could also be imagined, such as the multicast supression
mechanisms found in SLPv2. However, the DNSEXT WG was concerned about the
potential issues in expanding the scope of mDNS beyond linklocal, and
unimpressed with the rationale for doing so, given the ubiquity of unicast DNS.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 21 Jul 2002 22:40:17 -0700 (PDT)

> It seems like just about any request response
> protocol can be pressed into use for service discovery.

If this is true, I'd suggest that it is only because the "problem" is not
sufficiently well defined. As Erik has pointed out many times, there is
an important distinction between finding *an* instance of a service (any
instance, the "closest" instance, the "least loaded" instance, etc.) and a
*particular* instance of a service with a given set of characteristics.
The latter problem is the one to which the term "service discovery" is
typically applied, at least within the IETF.

I'd also note that just because it may be possible to discover a service
in many different ways, that does not mean that all these ways should be
implemented. On the Internet, it is not always true that having N ways to
do something is better than having a single, interoperable way to do
something.

> The most useful property of a service location protocol is that it
> be reasonably ubiquitous.

If ubiquity were the most useful property of a service location protocol
then there would be no need for an IP service location protocol at all,
since Novell IPX, Microsoft NetBEUI, and AppleTalk have had this functionality
for many years.

Rather, the most important property of a service location protocol is that
it solves the stated problem, and does so with the desired scalability.

> Right at the moment we seem to be creating
> a new mechanism for each new service discovery scenario we encounter,
> and I'm not sure that heads us in the right direction.

I'm not sure who the "we" refers to in this sentence. It does not appear
that any IETF WG (or even the IETF as a whole) is guilty of this. Perhaps
you are thinking about "IPv6 configuration" rather than service discovery?
That shoe might fit better.

---

From: Aidan Williams <[email-masked]>
Date: Mon, 22 Jul 2002 18:46:39 +1000

> the scope of the multicast. Hence, linklocal multicast name resolution

Backwards might be a matter of which way you are facing.. ;)

I would like it to be able to "scale" above a single link.

In particular, I have a home gateway box that routes between networks
(private ipv4 and 6to4 ipv6), and I need something special to make
LLMNR work between links.  (I seem to recall pushback against
supporting this by bridging the requests through the router, and
pushback against mapping LLMNR names into the unicast dns namespace).

> However, the DNSEXT WG was concerned about the potential issues in
> expanding the scope of mDNS beyond linklocal, and unimpressed with
> the rationale for doing so, given the ubiquity of unicast DNS.

Maybe you could summarise that discussion.  I certainly don't have a
clear understanding of what the problems were said to be.

The ubiquity of unicast DNS doesn't help a whole lot if it has to be
configured.  In the case of my routed gateway a non-LL MNR is appealing.

- aidan

---

From: Aidan Williams <[email-masked]>
Date: Mon, 22 Jul 2002 19:35:09 +1000

> typically applied, at least within the IETF.

I certainly agree about the problem definition part, although I wonder
if we have a plethora of solutions because service discovery can be
looked at in so many ways (e.g. configuring the NTP information vs
discovering an available NTP server vs anycast routing to the closest
NTP server).  Maybe I'm being unfair, but the great thing appears to
be that the problem can be defined to match the solution already
thought of.

I might be missing something, but a protocol for locating "particular"
services seems to be a superset of a protocol that locates "any"
service.  ("closest" seems to require topology info, which is harder).

> do something is better than having a single, interoperable way to do

Do you think this is true for service discovery?

> If ubiquity were the most useful property of a service location
> protocol then there would be no need for an IP service location
> protocol at all, since Novell IPX, Microsoft NetBEUI, and AppleTalk
> have had this functionality for many years.
> 

I'm not following you.  It seems to me that an IP service location
protocol is required because the other ones you mentioned aren't IP
(unless you count running them on top of IP).  Or, if they all run on
top of IP, why did the IETF invent SLP?  NIH?

> it solves the stated problem, and does so with the desired scalability.

To me this statement doesn't say much more than "X should work".
If there are several protocols that do basically "work" do we just use
them all?

Maybe each protocol should be thought of as defining one standard
mechanism for how it should be discovered.

> That shoe might fit better.

I was referring (rather grandiosely) to the IETF in general.
Yes, the debate about DNS service discovery springs to mind
however it isn't the only one.

-- 

regards
	aidan
____
:wq!

Sydney Network Research Lab             [email-masked]
Motorola Australian Research Centre          phone: +61 2 9666 0649
Locked Bag 5028, Botany NSW 1455              phax: +61 2 9666 0501
Australia                            http://marc.labs.mot.com/snrl/

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Jul 2002 05:07:41 -0700 (PDT)

> clear understanding of what the problems were said to be.

Basically, home gateways often implement DHCP/DNS proxy, so that if a
router is present there is no apparent need for mDNS.

> configured.  In the case of my routed gateway a non-LL MNR is appealing.

Since the home gateway is itself the DNS proxy, there is no configuration
required.

---

From: Erik Guttman <[email-masked]>
Date: Mon, 22 Jul 2002 16:36:15 +0200 (CEST)

> service.  ("closest" seems to require topology info, which is harder).

These are different problems.  For many services 'any' is OK, nearest
is GREAT.  For some services (like file servers, databases, anything
with a physical location you care about, limited access or specific
data you can't get anywhere else) - you need to find a particular 
service.
 
> Do you think this is true for service discovery?

There are several issues surrounding service discovery which could be
much better handled in a single protocol.  Otherwise it is very difficult
to get uniform behavior for a user.

 1) security -      which services can advertise themselves?
                    what configuration do services, clients and
                      infrastructure need?
                    what is the policy - what does one do with
                      unauthenticated services one discovers?
 2) organization -  what administrative hierarchy is presented for browsing?
 3) performance -   what does the administrator have to improve performance?
 4) parameters -    what parameters can one obtain for services from the
                      service discovery mechanism to configure clients
                      (beyond merely the address of the server)?
                    what is the 'schema' for these parameters?
 5) naming -        what are service names?
 6) management -    what does an administrator have to do to 'set up' a
                      group of clients and servers so that all the clients
                      in the enterprise can discover all the same set of 
                      services?   How can this be controlled? 
 7) internet        what has to happen to the protocol to make it scale
    resource          to the internet - so services can be discovered in
    discovery -       other administrative domains?

This is only a partial list.  Its pretty hard to get these things right 
for even a single service discovery protocol.  I believe it would be 
impossible to do if every protocol had its own discovery mechanism.

Erik