Re: [mdnsext] mdnsext & SLP

Michael Sweet <msweet@apple.com> Sat, 22 June 2013 03:49 UTC

Return-Path: <msweet@apple.com>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2693821E80AE for <mdnsext@ietfa.amsl.com>; Fri, 21 Jun 2013 20:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.82
X-Spam-Level:
X-Spam-Status: No, score=-8.82 tagged_above=-999 required=5 tests=[AWL=1.778, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4pxdHH2oWec for <mdnsext@ietfa.amsl.com>; Fri, 21 Jun 2013 20:48:55 -0700 (PDT)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0EB21E804D for <mdnsext@ietf.org>; Fri, 21 Jun 2013 20:48:54 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_hI7gNtzrbqdlNWJT2CPeag)"
Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOR00LZGZXF22K0@mail-out.apple.com> for mdnsext@ietf.org; Fri, 21 Jun 2013 20:48:53 -0700 (PDT)
X-AuditID: 11807153-b7f3c6d000007b32-ea-51c51ea4cf1a
Received: from [17.153.17.120] (Unknown_Domain [17.153.17.120]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id B5.7B.31538.5AE15C15; Fri, 21 Jun 2013 20:48:53 -0700 (PDT)
From: Michael Sweet <msweet@apple.com>
In-reply-to: <CABbPf3groNZ59Uc45sS4soswvpwAbtHR4YeNe+9jH0rCttWGRQ@mail.gmail.com>
Date: Fri, 21 Jun 2013 23:48:59 -0400
Message-id: <B3ADADAF-EECB-4F21-B3BC-2CEFCE7F8D70@apple.com>
References: <CABbPf3gpc_BFK5aFHVQHRwKnYwXVGXnFQKrvHbj-=_b_KbAxQQ@mail.gmail.com> <BCBFAA10-634B-4479-A653-25655236801E@apple.com> <CABbPf3hCy0pZ4fatYjab9jCxbayXz0-fUNYbzju3T0mNm-LS+A@mail.gmail.com> <4A8CEE77-B266-45E7-9D46-1ABB07C82CF0@apple.com> <CABbPf3groNZ59Uc45sS4soswvpwAbtHR4YeNe+9jH0rCttWGRQ@mail.gmail.com>
To: Garret Peirce <peirce@maine.edu>
X-Mailer: Apple Mail (2.1508)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUiOFOwQnep3NFAg67dBhYnl5xisjjyLdZi 14EJjA7MHltP/mDzWLLkJ5PH6V+tzAHMUVw2Kak5mWWpRfp2CVwZfw6oFDSqVXQeX8vWwPhc oYuRk0NCwETiYesDZghbTOLCvfVsXYxcHEICvUwSLRumsoAkhAVUJPbN3cAOYvMK6Eks/TeH EcRmFkiQuNI7C6yZTUBN4vekPlYQm1MgUGLhxmdgcRYBVYnGI5NZIOqVJVZMu8HUxcgBNMdG 4uqyEohde5gkJm5awAgSFwHateNgIYgpISArsfN30gRGvllIFs9CshjC1pZYtvA1lK0n8bLp HTumuK7ExXWTGBcwsq1iFChKzUmsNNZLLCjISdVLzs/dxAgK2IbC4B2Mf5ZZHWIU4GBU4uE9 kHokUIg1say4MvcQowQHs5IIL3sQUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvhlcHA4UE0hNL UrNTUwtSi2CyTBycUg2MwjO5OTr778zbMuOp81ITL1/X52/sZ3IZLKpOuC2mJ9JZUM0b7Mwn v2iqWnuF+J2C3FtJx6U1nJdbZ735qviSTyv+w12nLSUcIScd3N+3WC84fyabl/X0cgbFb5PE VmhxnlOIrnbq366n/fB49fLWNPOQ8mxty/VC/dfkT4bevc841SVZkU+JpTgj0VCLuag4EQD3 G5WEVAIAAA==
Cc: IETF mdnsext <mdnsext@ietf.org>
Subject: Re: [mdnsext] mdnsext & SLP
X-BeenThere: mdnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:mdnsext@ietf.org>
List-Help: <mailto:mdnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Jun 2013 03:49:02 -0000

Garret,

On 2013-06-21, at 11:27 PM, Garret Peirce <peirce@maine.edu> 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.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair