[mdnsext] mdnsext & SLP

Garret Peirce <peirce@maine.edu> Fri, 21 June 2013 15:05 UTC

Return-Path: <peirce@maine.edu>
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 75AFB21E8101 for <mdnsext@ietfa.amsl.com>; Fri, 21 Jun 2013 08:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 bCtNTr2j83oJ for <mdnsext@ietfa.amsl.com>; Fri, 21 Jun 2013 08:05:43 -0700 (PDT)
Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3137A21E8112 for <mdnsext@ietf.org>; Fri, 21 Jun 2013 08:05:42 -0700 (PDT)
Received: by mail-vb0-f50.google.com with SMTP id w16so6049261vbb.9 for <mdnsext@ietf.org>; Fri, 21 Jun 2013 08:05:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=buModr3zhJFf5RsTkEqshZb1ZTJctMiozOXQCONMtH4=; b=P4bY4fQ5m40FkjCNIbW0gr80FljyYWPZ5M8WtxQBiukV4kLQ6CwlaRYA5YOD9jzGt7 d99pgReAZ2UpyPbj7fq0zfgKZyJPZU5ZKohQZx86OXsXRQIXIubRvZ9Upt9SufOLcakk e3SSnwKZDB62DWiNzDhlaDp5z1m8PoMPgeXT/ghJxmkxTRiHwlUvxtulX7ipaMbi8XfW HRd5tzoNZAxfC3QxGO36C3DWega9AQow84K6FGOGU7dcFNqMnUglV87iDlq8bEiPtEfY RmXNwplvThOrb561GQLOiHVpVhpS/jF5xb59dOUpdq3spjXANYSruc7GXZI7VG/kKN// h/bw==
MIME-Version: 1.0
X-Received: by 10.58.207.195 with SMTP id ly3mr5889137vec.77.1371827141640; Fri, 21 Jun 2013 08:05:41 -0700 (PDT)
Received: by 10.220.50.131 with HTTP; Fri, 21 Jun 2013 08:05:41 -0700 (PDT)
Date: Fri, 21 Jun 2013 11:05:41 -0400
Message-ID: <CABbPf3gpc_BFK5aFHVQHRwKnYwXVGXnFQKrvHbj-=_b_KbAxQQ@mail.gmail.com>
From: Garret Peirce <peirce@maine.edu>
To: mdnsext@ietf.org
Content-Type: multipart/alternative; boundary=047d7b6d8d7c7890fb04dfab6518
X-Gm-Message-State: ALoCoQn4TI+h67WGu6RHwBmftWEE/x6Gx7Pdgvs+NoUi9KNr7+C4mvCytKDCIolC3gZVLmLF8VSo
Subject: [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: Fri, 21 Jun 2013 15:05:44 -0000

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