Return-Path: 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 A9A6421E8093 for ; Thu, 21 Feb 2013 13:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dworiK2mAEX for ; Thu, 21 Feb 2013 13:46:25 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFDD21E808C for ; Thu, 21 Feb 2013 13:46:25 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id ni5so158obc.26 for ; Thu, 21 Feb 2013 13:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=9FlOm2WsEkKD3kK3+elHSVRDgPGmRyTVLzl0Ymti++8=; b=psuPqH0gtzum9ZdWGh1UOJXWbhtnkganrixTd6W7s4lRM/fDV3KbXqLidZsNeqAa2d FIYNjDpPycxzdhihwCV2a2zNxTAH3S3igIrZFZfZoba1YXmQjwCIbJS5iJjjRv9JjpTI OiQ6UfhIEw5nf4n+FJMeVD8W6JixEUZnX1EGsAxWDJMR4vLgL8x695s5fioASboqnPoh 1aMUY9OqyVK84ipavs0e6SwCFQ472yI5RFEZLAhSXIJTG43MHNuZP1XqA72+XFv/uv72 pXi+U+uczc7x9aEBWRcthUbfMhNhhJZAnGD9rJcGi0zHN/tXIhyz5wVev/FbmoIMpd3l Mc3g== MIME-Version: 1.0 X-Received: by 10.60.12.137 with SMTP id y9mr11186056oeb.88.1361483184652; Thu, 21 Feb 2013 13:46:24 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.60.3.129 with HTTP; Thu, 21 Feb 2013 13:46:24 -0800 (PST) Date: Thu, 21 Feb 2013 16:46:24 -0500 X-Google-Sender-Auth: FWi6-s_Gh9kumlh6hQjYVNPt1U8 Message-ID: From: Kerry Lynn To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb2024496c19c04d6430135 Subject: [mdnsext] FYI: Just in case you missed it... 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 21:46:25 -0000 --e89a8fb2024496c19c04d6430135 Content-Type: text/plain; charset=ISO-8859-1 DNS-SD and mDNS are now published Standards Track RFCs as part of the series: http://tools.ietf.org/html/rfc6760 http://tools.ietf.org/html/rfc6761 http://tools.ietf.org/html/rfc6762 http://tools.ietf.org/html/rfc6763 Regards, -K- --e89a8fb2024496c19c04d6430135 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable DNS-SD and mDNS are now published Standards Track RFCs as part of the serie= s:

http://tools.ietf.= org/html/rfc6760
http= ://tools.ietf.org/html/rfc6761
http://tools.ietf.org/html/r= fc6762
http://tools.i= etf.org/html/rfc6763

Regards, -K-

--e89a8fb2024496c19c04d6430135-- Return-Path: 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 07C5221F8600 for ; Fri, 15 Feb 2013 13:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.84 X-Spam-Level: X-Spam-Status: No, score=-104.84 tagged_above=-999 required=5 tests=[AWL=1.759, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wPrTIRCaXiJ for ; Fri, 15 Feb 2013 13:46:50 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5D321F85FE for ; Fri, 15 Feb 2013 13:46:50 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1FLjrxH000098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Feb 2013 13:45:53 -0800 (PST) Message-ID: <511EAC90.8000609@isi.edu> Date: Fri, 15 Feb 2013 13:45:52 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: RJ Atkinson References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> <511DC47A.9050907@umn.edu> <511E75A8.2030601@isi.edu> <94957246-5E23-4516-8DCC-51DCA6356323@gmail.com> <511E8250.7050009@isi.edu> <9A9CB8FC-FA07-4898-B1D8-5342BFDE97B7@gmail.com> In-Reply-To: <9A9CB8FC-FA07-4898-B1D8-5342BFDE97B7@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 21:46:51 -0000 On 2/15/2013 11:14 AM, RJ Atkinson wrote: > > On 15 Feb 2013, at 13:45 , Joe Touch wrote: >> It depends on what you consider an API. >> If it's at the level of Unix Sockets, I agree. > > Great. We're on the same page then. > > Describing the TCP functions/operations/state-machine > details necessary for interoperability are one thing, > while the BSD API to TCP/IP is quite another. Just to be clear, I do look forward to the level of OPEN, CLOSE, ABORT, etc., though. That's critical, and is part of what's needed for interoperability. Which aren't Unix sockets, but Unix sockets are *one* implementation of. Joe Return-Path: 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 68EB321F84C2 for ; Fri, 15 Feb 2013 13:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiDkKhHHsjfJ for ; Fri, 15 Feb 2013 13:34:58 -0800 (PST) Received: from itsnt427.iowa.uiowa.edu (itsnt427.iowa.uiowa.edu [128.255.6.109]) by ietfa.amsl.com (Postfix) with ESMTP id 5800821F84C0 for ; Fri, 15 Feb 2013 13:34:58 -0800 (PST) Received: from ITSNT441.iowa.uiowa.edu ([169.254.3.85]) by itsnt427.iowa.uiowa.edu ([128.255.6.109]) with mapi id 14.02.0318.001; Fri, 15 Feb 2013 15:34:56 -0600 From: "Johnson, Neil M" To: RJ Atkinson , "mdnsext@ietf.org" Thread-Topic: [mdnsext] mDNSext features/requirements rollup Thread-Index: AQHOBTtDxRDhid+bt0yje7Q7hcDAFph64pAAgACZKYD///poog== Date: Fri, 15 Feb 2013 21:34:56 +0000 Message-ID: References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> <511DD320.7080003@umn.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 21:34:59 -0000 My former employer (a large multi-national electronics device manufacturer)= at one time had ~13,000 AppleTalk Zones and 10's of thousands of devices. = We had all sorts of issues: - Name collisions when far spread admins choose the same name for their zon= es. - Router performance issues handling that many zones and devices. - Issues with software trying to display that many zones and devices. We were more than glad to get rid of Apple Talk when IP became the defacto = standard. My point is to becareful what you mean by large scale :-) -Neil ________________________________________ From: mdnsext-bounces@ietf.org [mdnsext-bounces@ietf.org] on behalf of RJ A= tkinson [rja.lists@gmail.com] Sent: Friday, February 15, 2013 9:26 AM To: mdnsext@ietf.org Subject: Re: [mdnsext] mDNSext features/requirements rollup On 15 Feb 2013, at 01:18 , David Farmer wrote: > So the routers are in the idea location to do this, but I'm > really concerned about the instability adding more network state > into the routers. I have operational experience with large-scale (e.g. campus wide) deployments of AppleTalk over Ethernet that used low-cost (and by today's standards) very very low performance CPUs (e.g. 68K) with tiny amounts of RAM. The AppleTalk service advertisement proxying and zone advertisement proxying did NOT create any sort of instability. Back in those days, the deployed world was multi-protocol with some DECnet, some IP, a lot of IPX, and some other stuff besides, so there was a lot more state that needed to be kept inside the routers. With today's IP-centric world, the state needed in routers is much less, generally just a bridge table, an IPv4 RIB/FIB and an IPv6 RIB/FIB. Further, unlike back then, the actual packet forwarding generally does not involve the switch/router CPU or the RAM associated with the CPU. Instead, commodity or custom packet processing ASICs handle the heavy lifting today, and most of the other state (e.g. bridge table, IPv4 & IPv6 FIBs) is stored separately in commodity TCAM. So modern enterprise switches have tons of spare RAM and A LOT more CPU to spare than those devices did back in the 1990s. > While in large scale enterprise routers we try to make > things as stateless as possible, ideally the routing table only, > and we are supporting 2500 to 7500 devices with a single > large scale router. Back in the day, tiny (68K + smallish RAM) AppleTalk (EtherTalk) routers were supporting 2000+ devices successfully -- without instability. Today's enterprise routers and L3 switches are MUCH more capable, with more spare capacity. So my operational experience says that this is not a real problem, provided we are ordinarily sensible. For one thing, mDNS information ought to be "soft state", that regularly expires in some sensible way, and gets tossed and relearned when someone chooses to reboot (or significantly reconfigure without rebooting) some router or L3 switch. Yours, Ran _______________________________________________ mdnsext mailing list mdnsext@ietf.org https://www.ietf.org/mailman/listinfo/mdnsext= Return-Path: 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 1CBE621F88A1 for ; Fri, 15 Feb 2013 11:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRdT5H+dqg38 for ; Fri, 15 Feb 2013 11:14:22 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7B77821F8734 for ; Fri, 15 Feb 2013 11:14:22 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id p1so2368344vcq.16 for ; Fri, 15 Feb 2013 11:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=+6eN1rWhYt+XRzdoVmBrCOOXHTbEkL2x/KaQbJlqDtA=; b=RGvh/qHwgQhi22kAV9JrC3YHUooFp8rnFS9vQKizFbQj+z3JIAp12TLXfFFItTdN/m 11xnqd0zk/g3TCd+rxFrwlGDsMqRHxsaAg2PNusxcAtND+oMlOW09Db1uy14eOYArted hiW3boSxwFAtxUKF6+V+WqR6hOHo65Muaa0fa0nUTPX2WgIAmzJxqXs4qGbL+81jrGgQ 8Tx9Eft27IrxiKlJdukSUN/Ati9DFe3WuN/Tg0klQ/KDQGgoayUzOAYB+C5U6+tsXap8 O9vzNWhHwwkjIcVeHGh+KsOQgi654EvCe+bGlXWbTkFK1tU9qGvT3mNZ3UqrD+gmllb2 Ic/w== X-Received: by 10.220.220.134 with SMTP id hy6mr4793501vcb.2.1360955661822; Fri, 15 Feb 2013 11:14:21 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id o6sm82716528vdd.11.2013.02.15.11.14.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 11:14:21 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <511E8250.7050009@isi.edu> Date: Fri, 15 Feb 2013 14:14:20 -0500 Content-Transfer-Encoding: 7bit Message-Id: <9A9CB8FC-FA07-4898-B1D8-5342BFDE97B7@gmail.com> References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> <511DC47A.9050907@umn.edu> <511E75A8.2030601@isi.edu> <94957246-5E23-4516-8DCC-51DCA6356323@gmail.com> <511E8250.7050009@isi.edu> To: mdnsext@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 19:14:23 -0000 On 15 Feb 2013, at 13:45 , Joe Touch wrote: > It depends on what you consider an API. > If it's at the level of Unix Sockets, I agree. Great. We're on the same page then. Describing the TCP functions/operations/state-machine details necessary for interoperability are one thing, while the BSD API to TCP/IP is quite another. Cheers, Ran Return-Path: 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 1A5C521F8808 for ; Fri, 15 Feb 2013 10:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.806 X-Spam-Level: X-Spam-Status: No, score=-102.806 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PHFedebJOtw for ; Fri, 15 Feb 2013 10:46:14 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1E421F87FA for ; Fri, 15 Feb 2013 10:46:14 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r1FIjbTb019281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Feb 2013 10:45:37 -0800 (PST) Message-ID: <511E8250.7050009@isi.edu> Date: Fri, 15 Feb 2013 10:45:36 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: RJ Atkinson References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> <511DC47A.9050907@umn.edu> <511E75A8.2030601@isi.edu> <94957246-5E23-4516-8DCC-51DCA6356323@gmail.com> In-Reply-To: <94957246-5E23-4516-8DCC-51DCA6356323@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 18:46:15 -0000 On 2/15/2013 10:00 AM, RJ Atkinson wrote: > > On 15 Feb 2013, at 12:51 , Joe Touch wrote: >> UI considerations are out of scope, ... > > Well, I'm glad we all agree on that. :-) > >> The IETF has as much obligation to describe the upper layer >> events ("API") as it has describing the format "on the wire". > > I agree with the obligation to describe "upper layer events" > that are inherently part of some IETF standards-track > protocol (i.e. elements required for interoperability). > > However, the IETF routinely chooses not to define > Application Programming Interfaces (APIs). > > I don't think this WG is *obliged* to produce an > Application Programming Interface specification. > That seems optional to me. It depends on what you consider an API. If it's at the level of Unix Sockets, I agree. However, a good example of a "upper layer spec" is in TCP, describing OPEN, CLOSE, ABORT, etc., separately from how an OS implements them. IMO, too many protocols ignore those upper layer indicators, leaving them to the implementers to figure out. That breeds incompatibility, and should be avoided. Joe Return-Path: 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 B83D221F8808 for ; Fri, 15 Feb 2013 10:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEFE9oLcrylx for ; Fri, 15 Feb 2013 10:00:28 -0800 (PST) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2683F21F85C0 for ; Fri, 15 Feb 2013 10:00:27 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oz10so3328619veb.32 for ; Fri, 15 Feb 2013 10:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=65NwUwBuHpwDkWVZIxS7lixQcezg8AOmMRSpEW+vx6U=; b=mrumBBc8MLggWNVYcnY4nnP8hNZErv+w6cYoxa1PhNFdOR9Llx4LbShTL/mPwl4UNo 0Hgmc3Gje7yoa1WsDmcaxkVAekIVXKFYpe3HNgu6QZKFCHTAHuoNmXI6eoYReTOjDMie k8eoJnQJOVeTzhCjKMSdhH7+Wvy0tFhkBh7sqJa7PJfWSCnze4+2pjJvc21Szy8TnGRM B1UtCPTsc2mZBnD3q3lTYtb83r3Tx+hLjI6VAzWGDrkNwQpMYzWxgv7FcykoqgB34TKG 2mboyZtCaPH1UC/70VgQCls1eNa6oERLz2w8OWhMFba/OriFKk9yNus8Stt/htyGUo/G IYXg== X-Received: by 10.220.239.143 with SMTP id kw15mr4254262vcb.62.1360951226974; Fri, 15 Feb 2013 10:00:26 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id p20sm82396903vdj.6.2013.02.15.10.00.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 10:00:26 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <511E75A8.2030601@isi.edu> Date: Fri, 15 Feb 2013 13:00:25 -0500 Content-Transfer-Encoding: 7bit Message-Id: <94957246-5E23-4516-8DCC-51DCA6356323@gmail.com> References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> <511DC47A.9050907@umn.edu> <511E75A8.2030601@isi.edu> To: mdnsext@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 18:00:28 -0000 On 15 Feb 2013, at 12:51 , Joe Touch wrote: > UI considerations are out of scope, ... Well, I'm glad we all agree on that. :-) > The IETF has as much obligation to describe the upper layer > events ("API") as it has describing the format "on the wire". I agree with the obligation to describe "upper layer events" that are inherently part of some IETF standards-track protocol (i.e. elements required for interoperability). However, the IETF routinely chooses not to define Application Programming Interfaces (APIs). I don't think this WG is *obliged* to produce an Application Programming Interface specification. That seems optional to me. Cheers, Ran Return-Path: 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 3BADF21F87D2 for ; Fri, 15 Feb 2013 09:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.813 X-Spam-Level: X-Spam-Status: No, score=-102.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUr4481PPUFn for ; Fri, 15 Feb 2013 09:52:00 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3222221F85A1 for ; Fri, 15 Feb 2013 09:52:00 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1FHpbdm006741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Feb 2013 09:51:37 -0800 (PST) Message-ID: <511E75A8.2030601@isi.edu> Date: Fri, 15 Feb 2013 09:51:36 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Farmer References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> <511DC47A.9050907@umn.edu> In-Reply-To: <511DC47A.9050907@umn.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: mdnsext@ietf.org, RJ Atkinson Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 17:52:01 -0000 Hi, all, On 2/14/2013 9:15 PM, David Farmer wrote: > On 2/7/13 07:58 , RJ Atkinson wrote: > >> Later on 29th Jan 2013, David Farmer wrote, in part: >>> 4. Doesn't really solve any multicast traffic issues or scaling >>> of the name space. Yes, it's not the network's problem to display >>> 100s of services, but it will be a problem with most of the GUI's >>> I've seen. >> >> We ought to keep potential UI concerns separate from the >> potential protocol concerns. Getting the protocol design >> reasonably correct is a central issue for the IETF, whereas >> UI design generally is beyond the IETF's scope. IETF might >> well offer document UI concerns and/or offer advice about >> UI considerations, but UIs are normally outside the IETF scope. UI considerations are out of scope, but IMO a protocol consists of: data exchanged on the layer below state maintained at the endpoints timer events events on the layer above rules describing how these relate (i.e., a Mealy machine) The IETF has as much obligation to describe the upper layer events ("API") as it has describing the format "on the wire". I agree, e.g., that the details of the argument format and order for creating sockets is out of scope for TCP, but TCP *does* specify what kind of upper layer actions drive the protocol. The same ought to be true here. Joe Return-Path: 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 B97B521F8569 for ; Fri, 15 Feb 2013 07:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtY8Kfnv+fgb for ; Fri, 15 Feb 2013 07:28:42 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 26C6321F850F for ; Fri, 15 Feb 2013 07:28:42 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id m8so2235994vcd.9 for ; Fri, 15 Feb 2013 07:28:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=MC2RyYdTkfxShwovEJ+5mQU59+7n/KaSoIKwitTK5gc=; b=pZC3NMK00owQFPYetiymblfRx/tgtCs/nwffb59afhlGf8sTLxI7PdpX2DxMBeW7Tk 1iLBTcxzVYEyo7X+9XRlnUBwQlvtYZJsk72R5OMjcB03a0w4VjOwGxIBOfHkMn1RrKE2 0bunh2iHirfknrSbBenDD/sufwhV/0xrXPajLQUn6fT0TDxdwinBJTxDit/Endg0/2Zb w6Nq0T9z8QtDl6i+Qy6gwUESAJ1QARy9st4bKGRp6IrAW108G1KIxBWobnEhsFldq+Jk AO0/BMFnp+OaJ29CzksoJTjLApOqzkMkIYSN4UT2eXh5J6VQP2l97jYyL6dTiYzggeRN E6xg== X-Received: by 10.221.2.71 with SMTP id nt7mr2357839vcb.71.1360942121652; Fri, 15 Feb 2013 07:28:41 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id p7sm70772003vdt.2.2013.02.15.07.28.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 07:28:40 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <511DC47A.9050907@umn.edu> Date: Fri, 15 Feb 2013 10:28:40 -0500 Content-Transfer-Encoding: 7bit Message-Id: <8089B366-CDB4-4FF8-9BA5-233A00EEB98B@gmail.com> References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> <511DC47A.9050907@umn.edu> To: mdnsext@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 15:28:42 -0000 On 15 Feb 2013, at 00:15 , David Farmer wrote: > ... AppleTalk Ver2 included Zones that allowed users to self organise > their services in the UI, and helped scale the name space to extend > to the multi-segment environment of AppleTalk Ver2. Agreed. I still think that is a useful operational capability. I simply want to separate the protocol functions from the UI issues. Protocol functions seem within the scope for this WG, but UI issues seem outside the scope for this WG. Cheers, Ran Return-Path: 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 B94C921F8569 for ; Fri, 15 Feb 2013 07:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-hsUEPifGsP for ; Fri, 15 Feb 2013 07:26:21 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id B929821F850F for ; Fri, 15 Feb 2013 07:26:21 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id ft2so2177784vbb.37 for ; Fri, 15 Feb 2013 07:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=3f4lsOEXS/ntJLwOazEoEAPfYjfg2WA+HADIIji2tc8=; b=vWGraKNsvGyEfEllTEWiE2TGrUX+GWdwCu4dcsNAd/F6BsZcfyCNRjuCy8g2hDXajR BqLjTEOuFp0Twj28zqBABJHW6xFw0Y1OOA3nLur6Uh6nKmwF86TDIUxJh1Z0g6WC9k/m gsVE953AjcQ8BYy2VVLxLGV99XllTF9VUMfCDhrdxA3UiFB/hl94buXY6H1YDk6DHli8 xavgJ+3Ft+uxFHTitnzBoNLeFza6rjbn4OX/CVTtg5C+6mSSEpgGtokJOMXLZmoyZLMw M9ykyrdnpil+gQXOIxHPq4U3Rd6IWq86QNaGBExulVSNxx3DyBQqUqWSTSPy3Q+1ZdNZ mIXQ== X-Received: by 10.52.27.138 with SMTP id t10mr3188485vdg.59.1360941981040; Fri, 15 Feb 2013 07:26:21 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id pa4sm67941893veb.1.2013.02.15.07.26.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 07:26:20 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <511DD320.7080003@umn.edu> Date: Fri, 15 Feb 2013 10:26:19 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> <511DD320.7080003@umn.edu> To: mdnsext@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 15:26:22 -0000 On 15 Feb 2013, at 01:18 , David Farmer wrote: > So the routers are in the idea location to do this, but I'm > really concerned about the instability adding more network state > into the routers. I have operational experience with large-scale (e.g. campus wide) deployments of AppleTalk over Ethernet that used low-cost (and by today's standards) very very low performance CPUs (e.g. 68K) with tiny amounts of RAM. The AppleTalk service advertisement proxying and zone advertisement proxying did NOT create any sort of instability. Back in those days, the deployed world was multi-protocol with some DECnet, some IP, a lot of IPX, and some other stuff besides, so there was a lot more state that needed to be kept inside the routers. With today's IP-centric world, the state needed in routers is much less, generally just a bridge table, an IPv4 RIB/FIB and an IPv6 RIB/FIB. Further, unlike back then, the actual packet forwarding generally does not involve the switch/router CPU or the RAM associated with the CPU. Instead, commodity or custom packet processing ASICs handle the heavy lifting today, and most of the other state (e.g. bridge table, IPv4 & IPv6 FIBs) is stored separately in commodity TCAM. So modern enterprise switches have tons of spare RAM and A LOT more CPU to spare than those devices did back in the 1990s. > While in large scale enterprise routers we try to make > things as stateless as possible, ideally the routing table only, > and we are supporting 2500 to 7500 devices with a single > large scale router. Back in the day, tiny (68K + smallish RAM) AppleTalk (EtherTalk) routers were supporting 2000+ devices successfully -- without instability. Today's enterprise routers and L3 switches are MUCH more capable, with more spare capacity. So my operational experience says that this is not a real problem, provided we are ordinarily sensible. For one thing, mDNS information ought to be "soft state", that regularly expires in some sensible way, and gets tossed and relearned when someone chooses to reboot (or significantly reconfigure without rebooting) some router or L3 switch. Yours, Ran Return-Path: 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 3092F21F8871 for ; Fri, 15 Feb 2013 07:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSWY7XgLPdXB for ; Fri, 15 Feb 2013 07:11:31 -0800 (PST) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8B03721F8887 for ; Fri, 15 Feb 2013 07:11:31 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id 14so3097675vea.1 for ; Fri, 15 Feb 2013 07:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=vsyj5gENV8bNqvgizyl7jSZejtkRViMZe8zTcr2I2nE=; b=WuWSXIwAgEjKZvbTCsdlhAse32YvKTkT+uRjmrSvOg/xTn97709JdH28Nsp4yM1REz A13+tnsxzhevfVpWSpCWuudzFhInxHgASoSdNW4gTPck726zo5pE4/Kr47kQBciTBvEu FIhfo3cnRRQFPVZEvqBznKDwRqv715ymKREU2lMecsdI8Q1rqvcvRizRECZC38mmLC+0 pvAAbWjsFuLexDEGbkGHqfIpmsBYEc6A2i/y+ZZ+yz370XxghOjHRQ1HcVps66VjdP+O L11JnQJ7BI2/PPgfcxOPQQnQf/61Px+0PW5OAbZyZtazh/Nh459jqpwev2iJKsFxAPIw FX/Q== X-Received: by 10.220.151.144 with SMTP id c16mr3660597vcw.18.1360941091029; Fri, 15 Feb 2013 07:11:31 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id u5sm80887668vef.0.2013.02.15.07.11.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 07:11:30 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <511DF61E.9010005@umn.edu> Date: Fri, 15 Feb 2013 10:11:29 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> <511DF61E.9010005@umn.edu> To: mdnsext@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 15:11:32 -0000 On 15 Feb 2013, at 03:47 , David Farmer wrote: > However, I will say that care needs to be taking to not proxy > link-local (IPv4 or IPv6) addressing associated with services > and only proxy GUA or ULA addressing for services off of a > network segment with multicast or hybrid proxy of mDNS services. Off hand, I'm not sure exactly what set of rules/guidelines ought to be promulgated, but I agree that this is a question that this WG ought to examine -- and that some set of rules or guidelines ought to be documented as part of any standards-track specifications. > Furthermore, we need to define if a proxy should defend the > name of a link-local only service on other segments to preserve > naming coherency for any devices that may see the link-local > only service and the potentially conflicting GUA addressed > service of the same name on a different segment I agree this deserves thought. I don't have a firm view myself just yet. > Should an mDNS proxy also proxy the data path in the case of a > link-local only addressed service as well? Also a good question that the WG ought to discuss and address. > In the case of an mDNS proxy across a NAT Router then you > would have to use the proxies outside address and NAT > the Data path of the service, there are a whole bunch > of corner cases here, BLECH!! My intuition is that a NAT boundary (like an router interface running E-BGP) is a natural indication of a natural administrative boundary. For a wide range of reasons, one normally ought not ("by default") proxy or forward mDNS packet across any natural administrative boundary. Yours, Ran Return-Path: 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 732B821F88B0 for ; Fri, 15 Feb 2013 00:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRdzhrMmcF-X for ; Fri, 15 Feb 2013 00:47:40 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id ABF7221F866F for ; Fri, 15 Feb 2013 00:47:40 -0800 (PST) Received: from mail-ob0-f198.google.com (mail-ob0-f198.google.com [209.85.214.198]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 15 Feb 2013 02:47:30 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f198.google.com [209.85.214.198] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f198.google.com with SMTP id dn14so16990289obc.1 for ; Fri, 15 Feb 2013 00:47:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=DuyIwKR97fdZ4I5MJuIeLmx7lW8Hrodi0tc/cMM1wlI=; b=hDZ8RhAbNBfVS8N0h0XG+q4WEkc/cyCddanU+2BOhKpsxXfxEf8uKf78Ql8+yBkRet 0TWG7A7wW4jr4Z4MKf4LaDWvwDZaoiopGqWpgkWYoZmqatR0b3VMawSNY89mIlhUYAAX XQaynEb+pdW3hmlD6SNwPgSo2P31tARxLCxZYHUdkVtXOZqAFDuPakhM19IniFCBhpDJ PkUv+AXkAu43/K+TUHxulVQLfzCoqU+5eHvC3pR9L0xy4/VmV06oEhAPLDyWbom699Yn um9PyB/uJ9RfS9iWnW6CHF0PZaW8FeCv/ifW90C8vW/uCVKRNl6BKtRNmJfDWR4rQdZV /kdg== X-Received: by 10.43.124.130 with SMTP id go2mr1110765icc.8.1360918049676; Fri, 15 Feb 2013 00:47:29 -0800 (PST) X-Received: by 10.43.124.130 with SMTP id go2mr1110763icc.8.1360918049572; Fri, 15 Feb 2013 00:47:29 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id nh1sm3352309igc.4.2013.02.15.00.47.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 00:47:28 -0800 (PST) Message-ID: <511DF61E.9010005@umn.edu> Date: Fri, 15 Feb 2013 02:47:26 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: RJ Atkinson References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> In-Reply-To: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQltN27ra612sBlrTpmJyJxUt01FAHiHWwugzgk31hEHk8SijPvhaPppQjuA/yYwWJAw2iWyA24C21RfwzcMtR2upJT5mnyLo0+ad9bnzmt1tgV8GjRbLGct2fJVRYBFkYUCATrr Cc: mdnsext@ietf.org, David Farmer Subject: Re: [mdnsext] mDNSext features/requirements rollup X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer 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: Fri, 15 Feb 2013 08:47:41 -0000 On 2/7/13 07:58 , RJ Atkinson wrote: > Later on 29th Jan 2013, David Farmer wrote, in part: >> 5. What about IPv6, mDNS is using link-local IPv6, how do you >> route between multiple IPv6 link-local, by definition you can't. >> So multi network mDNS is really IPv4 only right now. > > I'm not too sure about the claim in that last sentence. > > I have heard of at least one multi-subnet "proxy-oriented" > implementation of mDNS that exists today, and that approach > should work equally well for IPv4 and IPv6. Of course, that > existing prototype/implementation is necessarily proprietary, > simply because this WG doesn't have a specification one > could comply with. OK, my comments were based on testing I did more than a year ago, and I'd swear that I saw only link-local IPv6 addressing for services on a dual-stack network with a IPv6 GUA prefix available. However, I just looked at this again and now I'm seeing IPv4 GUA, IPv6 link-local, and IPv6 GUA addressing associated with the same mDNS service name. So, I don't know if I just was remembering things wrong, if implementations have changed, or I just screwed up in my previous testing. Whatever the case, this isn't the problem I thought it was, sorry. However, I will say that care needs to be taking to not proxy link-local (IPv4 or IPv6) addressing associated with services and only proxy GUA or ULA addressing for services off of a network segment with multicast or hybrid proxy of mDNS services. Furthermore, we need to define if a proxy should defend the name of a link-local only service on other segments to preserve naming coherency for any devices that may see the link-local only service and the potentially conflicting GUA addressed service of the same name on a different segment? I think link-local only name needs to be defended. But then, what address should the link-local only service be advertized with on the other segments? Should the proxy use its own link-local address on the other segment? Should an mDNS proxy also proxy the data path in the case of a link-local only addressed service as well? In the case of an mDNS proxy across a NAT Router then you would have to use the proxies outside address and NAT the Data path of the service, there are a whole bunch of corner cases here, BLECH!! There is a similar question between IPv4 and IPv6, the ships-in-the-night solution for IPv4 and IPv6 used in mDNS may or may not be workable across multicast and hybrid proxies. Which every way we go with it we need to give serious attention to the dual-stack naming behavior across proxies, multicast or hybrid. If this is implemented differently between solutions you could see some really weird behavior. -- ================================================ David Farmer Email: farmer@umn.edu 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 ================================================ Return-Path: 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 965AB21F8780 for ; Thu, 14 Feb 2013 22:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, GB_AFFORDABLE=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E5WFMAmCrV9 for ; Thu, 14 Feb 2013 22:18:21 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id C14BE21F8746 for ; Thu, 14 Feb 2013 22:18:21 -0800 (PST) Received: from mail-ob0-f197.google.com (mail-ob0-f197.google.com [209.85.214.197]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 15 Feb 2013 00:18:11 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f197.google.com [209.85.214.197] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f197.google.com with SMTP id ta14so16529510obb.4 for ; Thu, 14 Feb 2013 22:18:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=2u/2VzLdQcstFg6pCPSUPATCpFopfS2vvVv0wc/VFVs=; b=MsKelkKM7j0IMRN/zDIRmbl1+K+eNocGrOzgqugen5L/ZcT9c8zVmVRT0j5mYugmdj MCji13Pfn5k/IDJPIb0aBZ9YF7wAhpFUD1NJdue/XpAZLt0TIqD1Z5yGhRCRV8nPDvKG dgV/xHdhsTsijyEQcQysAzA10bMeQZ+szNCZcPQp/4KJSJ4Ckxc3uBgwHLM2V6/pJvcn GL7Ktpz152PKy/Cxy5cqOar00RD3EQEy7QbM4vZc/bZNVa6mCCgNKJDEwr3DwnGxaX7y Dkz6Tev+za50vEid2QfCVizl9UVKbjYhSgKYLEFljHV1ZkmWSxiMg7q6zc5gXq4/sh9O +47Q== X-Received: by 10.50.88.129 with SMTP id bg1mr1035291igb.33.1360909090821; Thu, 14 Feb 2013 22:18:10 -0800 (PST) X-Received: by 10.50.88.129 with SMTP id bg1mr1035283igb.33.1360909090661; Thu, 14 Feb 2013 22:18:10 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id wv1sm3166485igb.0.2013.02.14.22.18.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 22:18:09 -0800 (PST) Message-ID: <511DD320.7080003@umn.edu> Date: Fri, 15 Feb 2013 00:18:08 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: RJ Atkinson References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> In-Reply-To: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnTWS9nP8xpjqmfW1xu/D5QR9Aeg5qmdBLGPhMLX23gsLhmLOsrF/hTdJBs6BBIu50ZPG5UUX24pbhrGB6xkpThOIjS4aUoaQyNzzo/7u3c4u46NOr/LqJfs6Sie1ZpKsn7UYdX Cc: mdnsext@ietf.org, David Farmer Subject: Re: [mdnsext] mDNSext features/requirements rollup X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer 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: Fri, 15 Feb 2013 06:18:22 -0000 On 2/7/13 07:58 , RJ Atkinson wrote: > Earlier, on Jan 29th 2013, Stephen Orr wrote, in part: >> I agree with Dan on this - making sure that the network >> infrastructure has the ability to operate as good "mdns clients" >> while providing filtering/proxying of DNS-SD advertisements >> between L3 segments would be a fundamental use case. > > Agreed. For interconnection of different IP subnets, > past experience has shown that putting this kind of > function inside routers makes sense. Routers are well > positioned to handle the proxy function, and already > are commonly used to provide various kinds of packet > filtering. > > Of course, we ought not REQUIRE that it be implemented > in routers -- both in the sense of not requiring router > implementers to include it and also in the sense of not > requiring network operators to put the function in routers. > > Later on 29th Jan 2013, David Farmer wrote, in part: >> 3. Creates the same problem AppleTalk had, routers involved >> in the name binding protocol. This is especially a problem >> for most enterprise network gear with powerful fast-path ASIC >> switching and relatively low powered slow-path processors. > > I really disagree with (3) above, on multiple grounds. > > A. My own operational experience with AppleTalk (EtherTalk) > on a very large campus network was that even low-cost > routers with small CPUs could handle NBP/AppleTalk traffic > -- and this was ~15 years ago when a "low cost CPU" was > MUCH less capable than today. > > B. Again, my own operational experience with AppleTalk > on a very large campus network was that having this > function inside the router meant that (1) the network > operator could apply policy, (2) prevented loops, and > (3) helped scalability by managing the inter-subnet > AppleTalk traffic. > > C. Back then, "powerful fast-path ASIC switching" was NOT yet > widely available and the same "low-powered slow-path > processors" (from ~15 years ago) were able to handle > BOTH bridging/forwarding and also AppleTalk/NBP traffic. > Also, back then the world was much more multi-protocol > (e.g. IPX, Banyan, IPv4, and AppleTalk were commonly > deployed concurrently on a single campus network using > the same interconnection devices; my site also had some > experimental IPv6 traffic). > > D. The widespread availability of commodity ASIC packet > processors and the huge increase in the power of what > we call a "low-powered" CPU means that a well-designed > "mDNS agent/relay/proxy" really ought not be an issue > inside an affordable enterprise-grade switch from any > major vendor. My concern is much less about processor than other resources like memory. But my more fundamental concern is we would be tracking another kind of state in the routers, the naming state of the network. So the routers are in the idea location to do this, but I'm really concerned about the instability adding more network state into the routers. If you think of a home broadband router they pile all sorts of state into them, DNS anmeing state, DHCP addressing state, TCP and UDP connection state, in addition to the packet forwarding state (the routing table), but they are doing this for 1 to 20 devices in the typical home. While in large scale enterprise routers we try to make thins as stateless as possible, ideally the routing table only, and we are supporting 2500 to 7500 devices with a single large scale router. So that doesn't mean the enterprise routers don't support the other services that the broadband routers do, but they do them in different ways. DHCP is usually support with a relay agent, host are directed to DNS other services through DHCP or Router Advertisements in IPV6. So yes, sometimes the router can and probably should the proxy or other naming services entity. But I'd like us to consider a relay agent model or redirector model too, like you talk about in D above. Where the router forwards the requests to another naming services entity or redirects requests to another naming services entity, that actually contains the naming state. In this way the routers could participate without building naming state in the routers themselves, and allowing naming to effect the stability of the routers. This comes from my experience of runing an extremely large multi-protocol network that supported AppleTalk (300+ zones, 3000+ services), IPX (2000+ SAPs), IP, DECNET Phases 3,4,&5 all on about 500+ segments, where AppleTalk and IPX naming state in the routers created much instability and drove several rounds of upgrades. Currently on just our 32 wireless network segments there are 3000 to 5000 or more mDNS services advertised at peak times of the day, and that doesn't include any the wired segments yet. So for scaling I do want the routers to participate in the naming service, but not contain any of the naming state itself, that's what I'm worried about. -- ================================================ David Farmer Email: farmer@umn.edu 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 ================================================ Return-Path: 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 422DC21F86B3 for ; Thu, 14 Feb 2013 21:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI+YiBUwrx7W for ; Thu, 14 Feb 2013 21:15:55 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDBD21F8432 for ; Thu, 14 Feb 2013 21:15:51 -0800 (PST) Received: from mail-ie0-f200.google.com (mail-ie0-f200.google.com [209.85.223.200]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 14 Feb 2013 23:15:41 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f200.google.com [209.85.223.200] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f200.google.com with SMTP id c11so15698723ieb.11 for ; Thu, 14 Feb 2013 21:15:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=bOjLpN2gTD95nAoUHAZtVWncvFBcqvONU3RtgvXEmoI=; b=imr0fz5aXGMCJ/R9Yplc8Gbh2e3DESOplI+JM0h8g67W8MqgRvh80GKLcA7duz8Rsh UKrLQdk2JJkINFgg3wiPO25QROluZ+9xR2FuuOw318PLe2GehPmqAciN5ijMZDA4DYUk AWMsWdMUlm0CHXXCXMweOW9/BeaP9lph8R59jSXKTmHmy3AmWPzDXHHLwf/izAwXrwyZ tQEK+t+5j9TiT6lDUQwBdB3jtYgfK6TfEWRz7M/1OQMnjrRKHQdWPqAhQceNMvJxOJTI 2zHD7omeDk1+DtRxzHQGGCJTFD9uM5eXRymw2W+hQP9c4V7ZGOcWgyDbWNRJ8PQsgGBI S5ew== X-Received: by 10.50.37.239 with SMTP id b15mr894772igk.69.1360905340738; Thu, 14 Feb 2013 21:15:40 -0800 (PST) X-Received: by 10.50.37.239 with SMTP id b15mr894765igk.69.1360905340644; Thu, 14 Feb 2013 21:15:40 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id kf2sm2896372igc.0.2013.02.14.21.15.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 21:15:39 -0800 (PST) Message-ID: <511DC47A.9050907@umn.edu> Date: Thu, 14 Feb 2013 23:15:38 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: RJ Atkinson References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> In-Reply-To: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl0H15V+cWEYGVho/6QsB8TGymq0zt00oO9GXwWO0OVqC5Gu6vriM4QKMPqs9AS6LOdYKOogAv9L2lS6zab3xz7emEntsZj42khHkvIPLXtXmbWNeiTOoQlBjpUPXuUh3stVf4N Cc: mdnsext@ietf.org, David Farmer Subject: Re: [mdnsext] mDNSext features/requirements rollup X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer 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: Fri, 15 Feb 2013 05:15:56 -0000 On 2/7/13 07:58 , RJ Atkinson wrote: > Later on 29th Jan 2013, David Farmer wrote, in part: >> 4. Doesn't really solve any multicast traffic issues or scaling >> of the name space. Yes, it's not the network's problem to display >> 100s of services, but it will be a problem with most of the GUI's >> I've seen. > > We ought to keep potential UI concerns separate from the > potential protocol concerns. Getting the protocol design > reasonably correct is a central issue for the IETF, whereas > UI design generally is beyond the IETF's scope. IETF might > well offer document UI concerns and/or offer advice about > UI considerations, but UIs are normally outside the IETF scope. For the most part I agree, but AppleTalk Ver2 included Zones that allowed users to self organize their services in the UI, and helped scale the name space to extend to the multi-segment environment of AppleTalk Ver2. So while I don't want to specifically get into UI issues, a single flat name space doesn't scale, especially for the UI, but for many other reasons too. This is a protocol issue we need to deal with in my opinion. Stuart's hybrid proxy proposal has one possible solution for this, I'm not sure its the right solution. However, we need something that helps scale and organize the namespace and it needs to be designed into the protocol, especially as we expand from link local to a multi-segment environment. -- ================================================ David Farmer Email: farmer@umn.edu 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 ================================================ Return-Path: 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 AB7B821F89AE for ; Thu, 7 Feb 2013 15:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClA-hT353VQg for ; Thu, 7 Feb 2013 15:40:09 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1669021F89AA for ; Thu, 7 Feb 2013 15:40:08 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B10E58A031 for ; Thu, 7 Feb 2013 23:40:06 +0000 (UTC) Date: Thu, 7 Feb 2013 18:40:04 -0500 From: Andrew Sullivan To: mdnsext@ietf.org Message-ID: <20130207234004.GH484@mx1.yitter.info> References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 23:40:09 -0000 On Thu, Feb 07, 2013 at 08:58:53AM -0500, RJ Atkinson wrote: > Much later, on 6th February 2013, Andrew Sullivan wrote, in part: > > > > It seems to me that, in Internet terms, we really have three > > scopes: > > > > 1. my network; > > 2. my network_s_; > > 3. the Internet. > > I'm not entirely clear on Andrew's terminology, but my guess > is that by (1) he means this subnet/link and (2) the set of > inter-connected subnets/links at my site/building/home/campus. I was being deliberately vague partly because of the whole do-what-I-mean flavour of this set of problems, but I think the distinctions you're making are probably good enough operationalizations for our purposes. > The claim above is not obviously true for several reasons: > > A) Split-horizon DNS deployments have been around since > the 1990s at least. THese are widely deployed. Few > problems have arisen in practice, as a percentage of > split-horizon deployments. Yes, problems could arise, > for example if a human misconfigures something, but > it isn't inherent in a split-horizon DNS deployment. Problems have in fact arisen. The root DNS servers receive a large amount of traffic for names that don't exist and that are clearly leakage of split horizon queries and of local-scope queries (*.local) that have escaped. One of the reasons the SiteFinder idea caused so much anguish was that, while wilcards in some other TLDs had worked for some time, .com turned out to be special in that failed queries were implicitly assumed to be inside .com (so local-use-only DNS names worked just fine before SiteFinderDay, but suddenly all got resolved inside .com on SiteFinderDay). From the point of view of end users, there are no problems; from the point of view of the Internet infrasrtucture, there are plenty of problems. > B) The current work here on (2) is extending mDNS rather than > putting a bunch of *.LOCAL data into the unicast DNS system > (which in many ways is a different system entirely, although > they have compatible namespaces). Except that all the clients need to work as though the mDNS (".local") names and the Internet DNS names are part of a single naming continuum. This fact is why .local names leak out to the Internet. In the case of the current mDNS, at the very least it's possible to identify (just from network topology) the border one shouldn't traverse. The same is not true in case (2): there's just no way to infer the scope of the site of inter-connected links at "my site", because we don't have a way to identify that. (In some ways, we are walking in sideways to the same problem people have experienced in the DNS -- attempting to infer organizational boundaries from delegation boundaries, or trying to infer "my domain" from the search path or other such tricks used by standard resolver libraries.) I've been musing over one possible strategy: to use the DNS to assert some network boundaries. But I haven't worked out the details of how this might help. Maybe a clue for mDNS responders? That seems to foil the whole zeroconf point of all this, though. > I don't agree with the idea of eliminating .LOCAL or > similar scoped domains or information advertised in those > domains. Its unrealistic to believe that a typical home > deployment will use global-scope DNS naming for devices > not intended to be accessible from outside the home. Well, obviously we can't ditch this: it's widely deployed. Also IMO it's not realistic to expect local-scope names to work across network boundaries. So we're now arguing about whose scope gets to be called "local" :) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com Return-Path: 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 EC0B521F86A2 for ; Thu, 7 Feb 2013 08:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmRu-uuPXKxN for ; Thu, 7 Feb 2013 08:53:24 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id D63D921F8BA6 for ; Thu, 7 Feb 2013 08:53:15 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9477B2016D; Thu, 7 Feb 2013 11:59:16 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A4E0914852; Thu, 7 Feb 2013 11:52:14 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9172124691; Thu, 7 Feb 2013 11:52:14 -0500 (EST) From: Michael Richardson To: RJ Atkinson In-Reply-To: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 16:53:27 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "RJ" =3D=3D RJ Atkinson writes: >> The problem I see is that, because of historical practice, >> attempting to treat (2) as a special case of (1) will mean that >> names designed to be local to (1) will leak into (3). RJ> The claim above is not obviously true for several reasons: RJ> A) Split-horizon DNS deployments have been around since the RJ> 1990s at least. THese are widely deployed. Few problems have RJ> arisen in practice, as a percentage of split-horizon RJ> deployments. Yes, problems could arise, for example if a human RJ> misconfigures something, but it isn't inherent in a RJ> split-horizon DNS deployment. There are significant problems with split-horizon. They didn't show up until we had nomadic devices like laptops and now smartphones. Consider that the MIF WG has an entire draft to attempting to solve this problem (I think it's a total fail though) Big organizations have fewer problems because they know how to deploy the right infrastructure and do the right configuration and training for end(remote) notes, but smaller (dis)organizations basically devolve to using IP address literals for all internal hosts ("intranet"s) because of road warriors and VPNs and the like.=20 That's why mDNS has been such a success, and why in homenet and here there has been such a big discussion about what is .site, because nobody wants to type IPv6 literals, and yet v6 global end addressability is making people realize that they will want (some) connectivity. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAURPbvoqHRg3pndX9AQLGjwQArOUr7gGxu2CDUVBkRYZbjHfU01QKeEAx 6kQ/st7tveL+MSiwpKecQruGZtUbSTGvHX2AG5nJOYSOyuMdJche2wwu6/l85q4o 19o9KHsyYX/4WFGX0KWMb51SUaUIRClw+DC1z0wsIG96Udvib8Q7BQHKiQNkBw3u HgEAbup2fBQ= =1Mtj -----END PGP SIGNATURE----- --=-=-=-- Return-Path: 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 BACF521F8501 for ; Thu, 7 Feb 2013 08:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXJZgUsNYfd6 for ; Thu, 7 Feb 2013 08:48:42 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 6D85621F8460 for ; Thu, 7 Feb 2013 08:48:42 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 950042016D; Thu, 7 Feb 2013 11:54:38 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 6A88314852; Thu, 7 Feb 2013 11:47:34 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5174424691; Thu, 7 Feb 2013 11:47:34 -0500 (EST) From: Michael Richardson To: RJ Atkinson In-Reply-To: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Thu, 07 Feb 2013 12:24:40 -0800 Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 16:48:43 -0000 >>>>> "RJ" == RJ Atkinson writes: RJ> Of course, we ought not REQUIRE that it be implemented in RJ> routers -- both in the sense of not requiring router RJ> implementers to include it and also in the sense of not RJ> requiring network operators to put the function in routers. +1 Perhaps we should write that this function must be easily co-located inside a router, but that it should not depend upon any (default) routing infrastructure to actually bring packets there. I can imagine one implementation where we would define some anycast address to which DNS UPDATEs and queries should be sent to, and we would assume that the routing infrastructure would respond, with the result being blackholed by ISPs. Such a system would *require* the proxy function to be co-located in routers, which I think is what you are getting at: we don't want to require it. A system of proxying link-local multicast would not require co-location the way an anycast would. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ Return-Path: 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 882C521F8654 for ; Thu, 7 Feb 2013 05:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, GB_AFFORDABLE=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbgL-J5sXZpB for ; Thu, 7 Feb 2013 05:58:55 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 662C321F8645 for ; Thu, 7 Feb 2013 05:58:55 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id l6so1630825vcl.17 for ; Thu, 07 Feb 2013 05:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=idTCUAL2eG+K4WxVcwd1Re/NMBCz//JdxQJx+g/mO0k=; b=V1Msq+F4axzAdO9Rx/FUTXiSdMOJtFHq5Cq5ICtn/MIE4wHUPUZgRX/rGbtYuobb/P gxUpBIg+603617kssJR9b8qb2Tjy7oEXwHLrtHsd3cbK60Xpl8jXeNxcQ4AtdIIlvvjJ r8WC9GfRQs3rN3+/YtmrcksxfJWny569/7sSZIJh9FELocbeIVDD83eaxdzWRvIi/Wlt IHNPd4umYu/+xSRkT3L9LdVJo7Lv3CS+x82aGl0z+DvsOwIFz2eufQdd+OWPHVwJ/7xT rprLMS4MZzUYwpLbQBsLIBWuYEZrI2Fn7t8/2DTmaqbyyD3wQO7YTGrxzwmJIM8N6BJp 5XhQ== X-Received: by 10.52.97.7 with SMTP id dw7mr1487824vdb.38.1360245534820; Thu, 07 Feb 2013 05:58:54 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id p7sm27362399vdt.2.2013.02.07.05.58.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 05:58:54 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Feb 2013 08:58:53 -0500 Message-Id: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com> To: mdnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 13:58:56 -0000 This note replies to several different notes in this thread. I've tried to do this by working from oldest note at the top of this note to most recent note at the bottom of this note. If one replies, trimming my original while editing the reply is definitely encouraged, as this is longish. Thanks ! Earlier, on Jan 29th 2013, Stephen Orr wrote, in part: > I agree with Dan on this - making sure that the network=20 > infrastructure has the ability to operate as good "mdns clients"=20 > while providing filtering/proxying of DNS-SD advertisements=20 > between L3 segments would be a fundamental use case. Agreed. For interconnection of different IP subnets, past experience has shown that putting this kind of function inside routers makes sense. Routers are well positioned to handle the proxy function, and already are commonly used to provide various kinds of packet filtering. Of course, we ought not REQUIRE that it be implemented in routers -- both in the sense of not requiring router implementers to include it and also in the sense of not requiring network operators to put the function in routers. Later on 29th Jan 2013, David Farmer wrote, in part: > 1. What happens if you get a proxy loop? =20 > This seems really bad!=20 > Right now I have nothing to prevent this. >=20 > 2. Maybe loop detection can be defined as part of a proxies behaviour. I agree that loop detection/prevention is an operational concern that ought to be addressed. > 3. Creates the same problem AppleTalk had, routers involved > in the name binding protocol. This is especially a problem > for most enterprise network gear with powerful fast-path ASIC > switching and relatively low powered slow-path processors. I really disagree with (3) above, on multiple grounds. A. My own operational experience with AppleTalk (EtherTalk) on a very large campus network was that even low-cost routers with small CPUs could handle NBP/AppleTalk traffic -- and this was ~15 years ago when a "low cost CPU" was MUCH less capable than today. B. Again, my own operational experience with AppleTalk on a very large campus network was that having this function inside the router meant that (1) the network operator could apply policy, (2) prevented loops, and (3) helped scalability by managing the inter-subnet AppleTalk traffic. C. Back then, "powerful fast-path ASIC switching" was NOT yet widely available and the same "low-powered slow-path=20 processors" (from ~15 years ago) were able to handle=20 BOTH bridging/forwarding and also AppleTalk/NBP traffic. =20 Also, back then the world was much more multi-protocol=20 (e.g. IPX, Banyan, IPv4, and AppleTalk were commonly=20 deployed concurrently on a single campus network using=20 the same interconnection devices; my site also had some experimental IPv6 traffic). D. The widespread availability of commodity ASIC packet processors and the huge increase in the power of what we call a "low-powered" CPU means that a well-designed "mDNS agent/relay/proxy" really ought not be an issue inside an affordable enterprise-grade switch from any major vendor. > 4. Doesn't really solve any multicast traffic issues or scaling > of the name space. Yes, it's not the network's problem to display > 100s of services, but it will be a problem with most of the GUI's > I've seen. We ought to keep potential UI concerns separate from the potential protocol concerns. Getting the protocol design reasonably correct is a central issue for the IETF, whereas UI design generally is beyond the IETF's scope. IETF might well offer document UI concerns and/or offer advice about UI considerations, but UIs are normally outside the IETF scope. > 5. What about IPv6, mDNS is using link-local IPv6, how do you > route between multiple IPv6 link-local, by definition you can't. > So multi network mDNS is really IPv4 only right now. I'm not too sure about the claim in that last sentence. =20 I have heard of at least one multi-subnet "proxy-oriented"=20 implementation of mDNS that exists today, and that approach=20 should work equally well for IPv4 and IPv6. Of course, that existing prototype/implementation is necessarily proprietary, simply because this WG doesn't have a specification one=20 could comply with. > So a proxy that safely interconnects multiple link-local nets > is only one small part of the solution space we need. That is > only a start, but an important start. I mostly agree with this. Much later, on 6th February 2013, Andrew Sullivan wrote, in part: >=20 > It seems to me that, in Internet terms, we really have three > scopes: >=20 > 1. my network; > 2. my network_s_; > 3. the Internet. I'm not entirely clear on Andrew's terminology, but my guess is that by (1) he means this subnet/link and (2) the set of inter-connected subnets/links at my site/building/home/campus. If I'm understanding his meaning, existing mDNS + DNS-SD is a sufficient solution for (1) -- evidence very broad deployment and use today (and for the past 5 years or so). > In naming, historically we've treated case (2) as a special case > of (3), and sometimes added split-horizon or something to it. =20 > What people are really asking for now is to treat case (2) > as a special case of (1), and figure out how to make that work. =46rom a DNS perspective, I mostly agree with this. In recent history, the DNS deployments mostly seem to be: (1) is something.LOCAL (2) is something.FOO.BAR.TLD (3) also is something.BAZ.TLD We are now looking to extend a single instance of .LOCAL beyond a single link/subnet, but contain it within a=20 single site/campus/home. > The problem I see is that, because of historical practice, > attempting to treat (2) as a special case of (1) will mean > that names designed to be local to (1) will leak into (3). =20 The claim above is not obviously true for several reasons: A) Split-horizon DNS deployments have been around since the 1990s at least. THese are widely deployed. Few problems have arisen in practice, as a percentage of split-horizon deployments. Yes, problems could arise, for example if a human misconfigures something, but it isn't inherent in a split-horizon DNS deployment. B) The current work here on (2) is extending mDNS rather than putting a bunch of *.LOCAL data into the unicast DNS system (which in many ways is a different system entirely, although they have compatible namespaces). I think we all agree that a functional requirement is (edit to taste): Any multi-link/multi-subnet mDNS solution needs to provide mechanisms to ensure that locally-scoped DNS information conveyed via mDNS (including whatever multi-hop mDNS solution emerges) does not leak across an administrative boundary (e.g. home, building, campus, site). > I think that leaking locally-scoped names onto the public > Internet is going to be a bad thing, and that's why I'm > arguing that what is really needed is a way to bring an > actual global namespace to this. I'm not entirely sure what the above quote is trying to say. I agree with supporting the conveyance of global-scope DNS information via mDNS (and via whatever extensions=20 this WG devises). =20 I have clients where this (using mDNS as extended by this WG=20 to convey DNS records using global-scope naming) is an=20 important use-case. I don't agree with the idea of eliminating .LOCAL or similar scoped domains or information advertised in those domains. Its unrealistic to believe that a typical home deployment will use global-scope DNS naming for devices not intended to be accessible from outside the home. Yours, Ran Atkinson Return-Path: 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 0322421F8499 for ; Wed, 6 Feb 2013 16:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of2X1x40UGzN for ; Wed, 6 Feb 2013 16:53:22 -0800 (PST) Received: from mail.ccgs.wa.edu.au (io.ccgs.wa.edu.au [203.135.184.6]) by ietfa.amsl.com (Postfix) with ESMTP id 03DB421F8488 for ; Wed, 6 Feb 2013 16:53:21 -0800 (PST) Received: by mail.ccgs.wa.edu.au (Postfix, from userid 108) id 2155BCA5A3; Thu, 7 Feb 2013 08:53:19 +0800 (WST) X-CCGS-ID: 20130207085314-16495 X-CCGS-ARGS: jandrewartha@ccgs.wa.edu.au mdnsext@ietf.org Received: from atlas.ad.ccgs.wa.edu.au (atlas.ad.ccgs.wa.edu.au [10.20.10.4]) by mail.ccgs.wa.edu.au (Postfix) with ESMTP id 72431CA554 for ; Thu, 7 Feb 2013 08:53:14 +0800 (WST) Received: from [10.10.20.21] (10.10.20.21) by atlas.ad.ccgs.wa.edu.au (10.20.10.4) with Microsoft SMTP Server id 8.1.436.0; Thu, 7 Feb 2013 08:53:14 +0800 Message-ID: <5112FAFA.4070109@ccgs.wa.edu.au> Date: Thu, 7 Feb 2013 08:53:14 +0800 From: James Andrewartha Organization: Christ Church Grammar School User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <5111BA39.10408@ccgs.wa.edu.au> <20130206143152.GF27306@mx1.yitter.info> In-Reply-To: <20130206143152.GF27306@mx1.yitter.info> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 00:53:23 -0000 On 06/02/13 22:31, Andrew Sullivan wrote: > On Wed, Feb 06, 2013 at 10:04:41AM +0800, James Andrewartha wrote: > >> useful client UI etc? Imagine having to reconfigure your DNS search >> domains when you change location - sure this can be handled by DHCP, but >> then you have to have lots of different scopes, which is another >> management tool problem. > > But you have this problem _by definition_ with mDNS. It's always > localy scoped. Indeed, that's what people are complaining about. > > It seems to me that, in Internet terms, we really have three scopes: > > 1. my network; > 2. my network_s_; > 3. the Internet. > > In naming, historically we've treated case (2) as a special case of > (3), and sometimes added split-horizon or something to it. What > people are really asking for now is to treat case (2) as a special > case of (1), and figure out how to make that work. > > The problem I see is that, because of historical practice, attempting > to treat (2) as a special case of (1) will mean that names designed to > be local to (1) will leak into (3). The evidence for this is the > effectiveness of split-views at keeping "private" names off the > Internet. This is only going to get worse as ICANN expands the root > zone (note there's an application for .mail, just for instance). > Similarly, RFC1918 addresses have often turned out to be globally > problematic because of their local scope. > > I think that leaking locally-scoped names onto the public Internet is > going to be a bad thing, and that's why I'm arguing that what is > really needed is a way to bring an actual global namespace to this. Those are all very good points. Does the experience of Site Local Addresses (RFC 3879) have any lessons here? >> As for the server side of things, apparently some devices don't support >> registration in DNS [1]. > > Since we're attempting to make a new protocol, no matter what we do > some already deployed stuff isn't going to work with it perfectly. If > what people want is a perfectly backward-compatible, do-what-I-mean > protocol that gives us all the new features we want for all the > existing stuff that works according to the previous protocol > specification, then I think we're going to be disappointed. The primary reason this is being working on is Apple TVs. Read the archives of EDUCAUSE that prompted the petition and forming of this working group, it's all about streaming video from iPads to Apple TVs in classrooms. And as has been established, Apple TV streaming doesn't work with WA DNS-SD. If whatever new protocol extension or feature or management tool we come up with isn't supported by Apple TVs, the whole exercise has been pointless. >> My use case is Apple TVs in each classroom, which I'd like to limit >> geographically, both for ease of use (finding an entry is a list of 100 >> is not fun) and to prevent accidents (streaming to the wrong device). > > "And no administration." We _had_ a solution for your use case as you > describe it: put things in the DNS, put a big label on the TV that has > the name of the device, and now you don't need to navigate drop-down > lists of 100s of devices. But it means you need to manage the DNS, > and it probably means slightly different interface design both on the > iPad and the Apple TV. I think I get why that's not desirable; I just > want us to be clear about what the challenge really is. I'm happy to put a label on things and tell teachers to put that in, but apparently Apple is not. I'm happy to do some administration and management, people have been doing it with printers for years. Anyway, I don't really care what the solution is, so long as it works for Apple TVs. It's Apple you need to convince about the suitability of using DNS, not me. -- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877 Return-Path: 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 978CA21F870E for ; Wed, 6 Feb 2013 06:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBBvbDxU2YUe for ; Wed, 6 Feb 2013 06:31:57 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F26C121F8645 for ; Wed, 6 Feb 2013 06:31:56 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E99288A031 for ; Wed, 6 Feb 2013 14:31:54 +0000 (UTC) Date: Wed, 6 Feb 2013 09:31:52 -0500 From: Andrew Sullivan To: mdnsext@ietf.org Message-ID: <20130206143152.GF27306@mx1.yitter.info> References: <5111BA39.10408@ccgs.wa.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5111BA39.10408@ccgs.wa.edu.au> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 14:31:57 -0000 On Wed, Feb 06, 2013 at 10:04:41AM +0800, James Andrewartha wrote: > useful client UI etc? Imagine having to reconfigure your DNS search > domains when you change location - sure this can be handled by DHCP, but > then you have to have lots of different scopes, which is another > management tool problem. But you have this problem _by definition_ with mDNS. It's always localy scoped. Indeed, that's what people are complaining about. It seems to me that, in Internet terms, we really have three scopes: 1. my network; 2. my network_s_; 3. the Internet. In naming, historically we've treated case (2) as a special case of (3), and sometimes added split-horizon or something to it. What people are really asking for now is to treat case (2) as a special case of (1), and figure out how to make that work. The problem I see is that, because of historical practice, attempting to treat (2) as a special case of (1) will mean that names designed to be local to (1) will leak into (3). The evidence for this is the effectiveness of split-views at keeping "private" names off the Internet. This is only going to get worse as ICANN expands the root zone (note there's an application for .mail, just for instance). Similarly, RFC1918 addresses have often turned out to be globally problematic because of their local scope. I think that leaking locally-scoped names onto the public Internet is going to be a bad thing, and that's why I'm arguing that what is really needed is a way to bring an actual global namespace to this. > As for the server side of things, apparently some devices don't support > registration in DNS [1]. Since we're attempting to make a new protocol, no matter what we do some already deployed stuff isn't going to work with it perfectly. If what people want is a perfectly backward-compatible, do-what-I-mean protocol that gives us all the new features we want for all the existing stuff that works according to the previous protocol specification, then I think we're going to be disappointed. > My use case is Apple TVs in each classroom, which I'd like to limit > geographically, both for ease of use (finding an entry is a list of 100 > is not fun) and to prevent accidents (streaming to the wrong device). "And no administration." We _had_ a solution for your use case as you describe it: put things in the DNS, put a big label on the TV that has the name of the device, and now you don't need to navigate drop-down lists of 100s of devices. But it means you need to manage the DNS, and it probably means slightly different interface design both on the iPad and the Apple TV. I think I get why that's not desirable; I just want us to be clear about what the challenge really is. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com Return-Path: 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 7AEA121F8A42 for ; Tue, 5 Feb 2013 18:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeTbR9GXD7R7 for ; Tue, 5 Feb 2013 18:05:08 -0800 (PST) Received: from mail.ccgs.wa.edu.au (io.ccgs.wa.edu.au [203.135.184.6]) by ietfa.amsl.com (Postfix) with ESMTP id A171521F8A2F for ; Tue, 5 Feb 2013 18:04:50 -0800 (PST) Received: by mail.ccgs.wa.edu.au (Postfix, from userid 108) id B72F1CA58A; Wed, 6 Feb 2013 10:04:48 +0800 (WST) X-CCGS-ID: 20130206100442-20160 X-CCGS-ARGS: jandrewartha@ccgs.wa.edu.au mdnsext@ietf.org Received: from atlas.ad.ccgs.wa.edu.au (atlas.ad.ccgs.wa.edu.au [10.20.10.4]) by mail.ccgs.wa.edu.au (Postfix) with ESMTP id 42B72CA59C for ; Wed, 6 Feb 2013 10:04:42 +0800 (WST) Received: from [10.10.20.21] (10.10.20.21) by atlas.ad.ccgs.wa.edu.au (10.20.10.4) with Microsoft SMTP Server id 8.1.436.0; Wed, 6 Feb 2013 10:04:41 +0800 Message-ID: <5111BA39.10408@ccgs.wa.edu.au> Date: Wed, 6 Feb 2013 10:04:41 +0800 From: James Andrewartha Organization: Christ Church Grammar School User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [mdnsext] mDNSext features/requirements rollup 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 02:06:31 -0000 On Mon, 28 Jan 2013 12:34:00 -0500, Andrew Sullivan wrote: > I still do not understand why this sort of thing isn't better handled > by vastly improved tools for real DNS management. It seems to me that > people are asking for a single, unifed namespace outside the > link-local context, and we invented a mechanism for that many years > ago. The problem is that the support tools for that mechanism sort of > suck. Instead of inventing a new protocol which, by definition, is > going to run into conflicts with the existing protocols in this space, > why wouldn't it be better to take that energy and expend it on the > missing tools? I too would like better real DNS management, however there are several problems with it. Others have pointed out that existing implementations are focused on mDNS and LL DNS-SD - is WA DNS-SD well tested, has a useful client UI etc? Imagine having to reconfigure your DNS search domains when you change location - sure this can be handled by DHCP, but then you have to have lots of different scopes, which is another management tool problem. As for the server side of things, apparently some devices don't support registration in DNS [1]. A suggestion was made to have a tool that translates mDNS to updates to a WA DNS-SD domain, which could work, and does allow administrator approval of what is visible, but there's still the question of domain scope management. Never mind that some features of Apple TVs just don't work over WA DNS-SD, only mDNS [2]. Even for applications/devices that do support registration, I don't know if they support setting a scope for each record. As such, doing it once at the network level is far easier than updating every DNS-SD publishing application. For example, I recently discovered [3] that our printers are published to Mac clients via mDNS from Papercut - how do I control the visibility of printers in certain areas? Going back to the broader topic, I also need different scopes for different folk^Wservices - the area/networks a printer should be advertised on are different to an Apple TV in a classroom. But a client iPad needs to see both. My use case is Apple TVs in each classroom, which I'd like to limit geographically, both for ease of use (finding an entry is a list of 100 is not fun) and to prevent accidents (streaming to the wrong device). [1] http://listserv.educause.edu/cgi-bin/wa.exe?A2=ind1112&L=WIRELESS-LAN&T=0&F=&S=&P=52503 [2] http://listserv.educause.edu/cgi-bin/wa.exe?A2=WIRELESS-LAN;0pol1g;20111220182540-0600 [3] After installing a new wireless network that appears to be having trouble with multicast. I've since discovered printers can be pushed out by profiles, but a) profiles suck compared to MCX, b) profiles have no location awareness. [late subscriber to the list, apologies for thread-breaking] -- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877 Return-Path: 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 2CB4821F8AE7 for ; Mon, 4 Feb 2013 10:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3atWq7aZ4fn3 for ; Mon, 4 Feb 2013 10:17:08 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 6710921F8AD8 for ; Mon, 4 Feb 2013 10:17:08 -0800 (PST) Received: from mail-ob0-f198.google.com (mail-ob0-f198.google.com [209.85.214.198]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 4 Feb 2013 12:16:57 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f198.google.com [209.85.214.198] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f198.google.com with SMTP id dn14so34569967obc.1 for ; Mon, 04 Feb 2013 10:16:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to:x-gm-message-state; bh=dfbX9raQ2ulUZ0LBjTEDWrFwbFmdEpl2yVCP4liXu+o=; b=LcU0vDG6Ua2SkjPCoTi9D4Rn1krXe001AcTDkxKBHtoWuQ/0BVu/EWm6uDVT9hk8GD gJf2NxjH70cEa7W/ontSrGD90ayKML2I3vhCvowp6vbx8DwHmZAjrX7XGF5mMyN/mamI 2wrjABH8+6j0cmiUGeul8qbEx6X5BaCbniP4lUDt5Jf9pUaxZ/GaW16SGCQlVeY16XIt pbXHRshcLkS4wd7xJkHRgwiF/GnNqFWIV24vqoIu17Uu+ZdH6C3XQ9qlfV+LGFd6hm9N XHuHgEHfg+eao2RLpBk7EBuvWXrypnb2y2+OVjXeXfaPX6LIhdklhrElyBOVUjnA1HTA OVLQ== X-Received: by 10.50.108.161 with SMTP id hl1mr7959850igb.101.1360001817217; Mon, 04 Feb 2013 10:16:57 -0800 (PST) X-Received: by 10.50.108.161 with SMTP id hl1mr7959532igb.101.1360001814395; Mon, 04 Feb 2013 10:16:54 -0800 (PST) Received: from [172.19.131.122] ([199.106.166.66]) by mx.google.com with ESMTPS id fa6sm17512981igb.2.2013.02.04.10.16.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Feb 2013 10:16:52 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-8D502D28-A57D-407C-9653-EB21EA21C39A Message-Id: X-Mailer: iPad Mail (10B141) From: David Farmer Date: Mon, 4 Feb 2013 12:16:37 -0600 To: Alf Watt X-Gm-Message-State: ALoCoQmkBvQ8ON4il0EiKl0HxKQZPBgkZsplHYeqRnznka+CNMDIJvkwn10e6tmp3anynzYM/hgacavX07+tjMf7+KEUGyqYWQKkKpNjrTw4psIIjPFef+LWm7YQkJnH3ayzUGKKa1QC Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] mdnsproxy and hybrid proxy loop detection 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 18:17:09 -0000 --Apple-Mail-8D502D28-A57D-407C-9653-EB21EA21C39A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Feb 1, 2013, at 11:34, Alf Watt wrote: >=20 > My initial though is that loop detection is most important for multicast t= o multicast proxy scenarios, which is the current state of the art in bonjou= r bridges. Can anyone think of a case where the proposed hybrid proxy can ge= t into a loop? Not a forwarding loop, but maybe a registration loop, or a registration race= condition. If two hybrid proxies were registering to the same DNS zone and= connected to the same link network they would need some kind of coordinatio= n to prevent them both registering the same services. Or to detect that the s= econd place gateway is attempting to reregister the same service and not ret= urn a registration conflict back to the device on the link. So, while they are probably different kinds of loops and they may need diffe= rent solutions, maybe we can find a common solution or at least parts in com= mon to separate solutions. > One solution I've been considering is to have the proxy advertise itself a= s a service, _mdnsproxy._udp. for e.g., if they include some basic configura= tion information in the txt record then a second proxy can detect the presen= ce of another proxy with similar configuration and disable any conflicting p= roxy directives until such time as the first proxy removes itself from the s= ubnet. This seems like a logical approach. They could advertise the link networks t= hey connect to and for a hybrid proxy the DNS zone they connect to as part o= f the txt records. We would need a link network identifier that the proxies= can agree on, this may be difficult in the presence of dual stack, partitio= ning and joining of link networks. > Best, > Alf >=20 > On Jan 29, 2013, at 12:00 PM, mdnsext-request@ietf.org wrote: >=20 >> From: David Farmer >> Subject: Re: [mdnsext] mDNSext features/requirements rollup >> Date: January 29, 2013 10:59:51 AM PST >> To: "Stephen Orr (sorr)" >> Cc: "mdnsext@ietf.org" , Dan Harkins >>=20 >>=20 >> As a first step I'm ok with this, in fact I'm already doing it, but I vie= w this as mostly a work around or hack. >>=20 >> 1. What happens if you get a proxy loop? This seems really bad! Right no= w I have nothing to prevent this. >>=20 >> 2. Maybe loop detection can be defined as part o a proxies behavior. >=20 --Apple-Mail-8D502D28-A57D-407C-9653-EB21EA21C39A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On Feb 1, 2013, at 11:34, Alf Watt <alf.watt@ruckuswireless.com> wrote:

My initial though is that loop detection is most important for multicast to multicast proxy scenarios, which is the current state of the art in bonjour bridges. Can anyone think of a case where the proposed hybrid proxy can get into a loop?

Not a forwarding loop, but maybe a registration loop, or a registration race condition. If two hybrid proxies were registering to the same DNS zone and connected to the same link network they would need some kind of coordination to prevent them both registering the same services. Or to detect that the second place gateway is attempting to reregister the same service and not return a registration conflict back to the device on the link.

So, while they are probably different kinds of loops and they may need different solutions, maybe we can find a common solution or at least parts in common to separate solutions.

One solution I've been considering is to have the proxy advertise itself as a service, _mdnsproxy._udp. for e.g., if they include some basic configuration information in the txt record then a second proxy can detect the presence of another proxy with similar configuration and disable any conflicting proxy directives until such time as the first proxy removes itself from the subnet.

This seems like a logical approach. They could advertise the link networks they connect to and for a hybrid proxy the DNS zone they connect to as part of the txt records. We would need a link network identifier that the proxies can agree on, this may be difficult in the presence of dual stack, partitioning and joining of link networks.

Best,

Alf

On Jan 29, 2013, at 12:00 PM, mdnsext-request@ietf.org wrote:

From: David Farmer <farmer@umn.edu>

Subject: Re: [mdnsext] mDNSext features/requirements rollup

Date: January 29, 2013 10:59:51 AM PST

To: "Stephen Orr (sorr)" <sorr@cisco.com>

Cc: "mdnsext@ietf.org" <mdnsext@ietf.org>, Dan Harkins <dharkins@lounge.org>

As a first step I'm ok with this, in fact I'm already doing it, but I view this as mostly a work around or hack.

1. What happens if you get a proxy loop? This seems really bad! Right now I have nothing to prevent this.

2. Maybe loop detection can be defined as part o a proxies behavior.

--Apple-Mail-8D502D28-A57D-407C-9653-EB21EA21C39A-- Return-Path: 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 C34DB21E8049 for ; Fri, 1 Feb 2013 09:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hit+LkS0PAci for ; Fri, 1 Feb 2013 09:34:32 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id A0F7021F8D6A for ; Fri, 1 Feb 2013 09:34:32 -0800 (PST) Received: from mail93-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Feb 2013 17:34:32 +0000 Received: from mail93-va3 (localhost [127.0.0.1]) by mail93-va3-R.bigfish.com (Postfix) with ESMTP id CA8343402DA; Fri, 1 Feb 2013 17:34:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT004.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz98dI9371Ic85fhzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dh18c673hz32i2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail93-va3 (localhost.localdomain [127.0.0.1]) by mail93-va3 (MessageSwitch) id 1359740069257288_3056; Fri, 1 Feb 2013 17:34:29 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.240]) by mail93-va3.bigfish.com (Postfix) with ESMTP id 3A49A4E0049; Fri, 1 Feb 2013 17:34:29 +0000 (UTC) Received: from CH1PRD0811HT004.namprd08.prod.outlook.com (157.56.245.85) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Feb 2013 17:34:28 +0000 Received: from CH1PRD0811MB407.namprd08.prod.outlook.com ([169.254.8.195]) by CH1PRD0811HT004.namprd08.prod.outlook.com ([10.255.155.39]) with mapi id 14.16.0263.000; Fri, 1 Feb 2013 17:34:27 +0000 From: Alf Watt To: "mdnsext@ietf.org" , "farmer@umn.edu" Thread-Topic: mdnsproxy and hybrid proxy loop detection Thread-Index: AQHOAKJh1GgxTglkkkCRNOHg7DN7XA== Date: Fri, 1 Feb 2013 17:34:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.155.4] Content-Type: multipart/alternative; boundary="_000_D99048ACAF96354EBFD6A811E3C65ACD1097BE5ACH1PRD0811MB407_" MIME-Version: 1.0 X-OriginatorOrg: ruckuswireless.com Subject: [mdnsext] mdnsproxy and hybrid proxy loop detection 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 17:34:33 -0000 --_000_D99048ACAF96354EBFD6A811E3C65ACD1097BE5ACH1PRD0811MB407_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My initial though is that loop detection is most important for multicast to= multicast proxy scenarios, which is the current state of the art in bonjou= r bridges. Can anyone think of a case where the proposed hybrid proxy can g= et into a loop? One solution I've been considering is to have the proxy advertise itself as= a service, _mdnsproxy._udp. for e.g., if they include some basic configura= tion information in the txt record then a second proxy can detect the prese= nce of another proxy with similar configuration and disable any conflicting= proxy directives until such time as the first proxy removes itself from th= e subnet. Best, Alf On Jan 29, 2013, at 12:00 PM, mdnsext-request@ietf.org wrote: From: David Farmer > Subject: Re: [mdnsext] mDNSext features/requirements rollup Date: January 29, 2013 10:59:51 AM PST To: "Stephen Orr (sorr)" > Cc: "mdnsext@ietf.org" >, Dan Harkins > As a first step I'm ok with this, in fact I'm already doing it, but I view = this as mostly a work around or hack. 1. What happens if you get a proxy loop? This seems really bad! Right now = I have nothing to prevent this. 2. Maybe loop detection can be defined as part o a proxies behavior. --_000_D99048ACAF96354EBFD6A811E3C65ACD1097BE5ACH1PRD0811MB407_ Content-Type: text/html; charset="us-ascii" Content-ID: <3714AA57C878734F95F5239C7CE32CC4@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

My initial though is that loop detection is most important for multica= st to multicast proxy scenarios, which is the current state of the art in b= onjour bridges. Can anyone think of a case where the proposed hybrid proxy = can get into a loop?

One solution I've been considering is to have the proxy advertise itse= lf as a service, _mdnsproxy._udp. for e.g., if they include some basic conf= iguration information in the txt record then a second proxy can detect the = presence of another proxy with similar configuration and disable any conflicting proxy directives until such time= as the first proxy removes itself from the subnet.

Best,

Alf

On Jan 29, 2013, at 12:00 PM, mdnsext-request@ietf.org wrote:

From: = David Fa= rmer <farmer@umn.edu>

Subject: <= /b>Re= : [mdnsext] mDNSext features/requirements rollup

Date: = January = 29, 2013 10:59:51 AM PST

To: "Step= hen Orr (sorr)" <sorr@cisco.com>

Cc: "mdnsext@ietf.org" <mdnsext@ietf.org>, Dan Hark= ins <dharkins@lounge.org><= br>

As a first step I'm ok with this, in fact I'm already doing it, but I view th= is as mostly a work around or hack.

1. What happens if you get a proxy loop? This seems really bad! Right n= ow I have nothing to prevent this.

2. Maybe loop detection can be defined as part o a proxies behavior.

--_000_D99048ACAF96354EBFD6A811E3C65ACD1097BE5ACH1PRD0811MB407_--