Re: [mdnsext] mdnsext & SLP

Garret Peirce <> Sat, 22 June 2013 03:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 459C311E80F5 for <>; Fri, 21 Jun 2013 20:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a1NKCPKGLPwr for <>; Fri, 21 Jun 2013 20:27:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c02::22a]) by (Postfix) with ESMTP id 6F39721F9951 for <>; Fri, 21 Jun 2013 20:27:37 -0700 (PDT)
Received: by with SMTP id i3so6568428vbh.15 for <>; Fri, 21 Jun 2013 20:27:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=PcOo11ewi/Fn2DWU98WMf5zvrUJD0GeOCI/w4IwugbY=; b=CTG7g+TsQd2slbIWQz9xRAbESELh5+u4FhbQIxCYqCbu5m4+XNtyS+zLZGb1vE69ec qb9oDHGpGh2fgoMibRtfFedYYu7hNkwMw9udIxU14Q9i2rfDdNEXSHCwVWld/haYEu3z osjz5wWNSeoM4dE00kDrW0rcoJBTdoT5KhxSRLIA2osVfR7skorJflfWB1XdzkHLwGwf h9iB71lqBYl/cUbLZTUl4VZJzBF9efJo0XiBNfmfoQla2sRExSkv+DnvaggryYOp4vpt /0m/IPytINQusFgAfwxj1ghcdAj0Qa0/dPIhU3D3/A+C3IpR7Yy/F2jaXNfQvujOVouB WKug==
MIME-Version: 1.0
X-Received: by with SMTP id fv3mr6062607vdb.11.1371871657146; Fri, 21 Jun 2013 20:27:37 -0700 (PDT)
Received: by with HTTP; Fri, 21 Jun 2013 20:27:37 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 21 Jun 2013 23:27:37 -0400
Message-ID: <>
From: Garret Peirce <>
To: Michael Sweet <>
Content-Type: multipart/alternative; boundary=047d7bacb840cd495104dfb5c2db
X-Gm-Message-State: ALoCoQkeezoIO4EUkD7bCPs5cD+Iu9QaITM0WJjiB00Il+/bdS20Kjpn7JAaKkzM66UfSSQxdOBq
Cc: IETF mdnsext <>
Subject: Re: [mdnsext] mdnsext & SLP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 22 Jun 2013 03:27:39 -0000

> 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

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