Re: [mdnsext] mDNSext features/requirements rollup
David Farmer <farmer@umn.edu> Fri, 15 February 2013 06:18 UTC
Return-Path: <farmer@umn.edu>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965AB21F8780 for <mdnsext@ietfa.amsl.com>; 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 <mdnsext@ietfa.amsl.com>; 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 <mdnsext@ietf.org>; 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 <mdnsext@ietf.org>; 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 <mdnsext@ietf.org>; 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 <farmer@umn.edu>
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 <rja.lists@gmail.com>
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 <farmer@umn.edu>
Subject: Re: [mdnsext] mDNSext features/requirements rollup
X-BeenThere: mdnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: David Farmer <farmer@umn.edu>
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:mdnsext@ietf.org>
List-Help: <mailto:mdnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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 ================================================
- [mdnsext] mDNSext features/requirements rollup Alf Watt
- [mdnsext] mDNSext features/requirements rollup RJ Atkinson
- [mdnsext] mDNSext features/requirements rollup RJ Atkinson
- Re: [mdnsext] mDNSext features/requirements rollup Andrew Sullivan
- Re: [mdnsext] mDNSext features/requirements rollup nudge
- Re: [mdnsext] mDNSext features/requirements rollup Andrew Sullivan
- Re: [mdnsext] mDNSext features/requirements rollup Brian Dickson
- Re: [mdnsext] mDNSext features/requirements rollup Andrew Sullivan
- Re: [mdnsext] mDNSext features/requirements rollup Tim Chown
- Re: [mdnsext] mDNSext features/requirements rollup David Farmer
- Re: [mdnsext] mDNSext features/requirements rollup David Farmer
- Re: [mdnsext] mDNSext features/requirements rollup peter van der Stok
- Re: [mdnsext] mDNSext features/requirements rollup RJ Atkinson
- Re: [mdnsext] mDNSext features/requirements rollup Dan Harkins
- Re: [mdnsext] mDNSext features/requirements rollup Alf Watt
- Re: [mdnsext] mDNSext features/requirements rollup Stephen Orr (sorr)
- Re: [mdnsext] mDNSext features/requirements rollup nudge
- Re: [mdnsext] mDNSext features/requirements rollup David Farmer
- Re: [mdnsext] mDNSext features/requirements rollup vortex
- Re: [mdnsext] mDNSext features/requirements rollup Andrew Sullivan
- Re: [mdnsext] mDNSext features/requirements rollup vortex
- [mdnsext] mDNSext features/requirements rollup Olivier Levon
- Re: [mdnsext] mDNSext features/requirements rollup James Andrewartha
- Re: [mdnsext] mDNSext features/requirements rollup Andrew Sullivan
- Re: [mdnsext] mDNSext features/requirements rollup James Andrewartha
- Re: [mdnsext] mDNSext features/requirements rollup RJ Atkinson
- Re: [mdnsext] mDNSext features/requirements rollup Michael Richardson
- Re: [mdnsext] mDNSext features/requirements rollup Michael Richardson
- Re: [mdnsext] mDNSext features/requirements rollup Andrew Sullivan
- Re: [mdnsext] mDNSext features/requirements rollup David Farmer
- Re: [mdnsext] mDNSext features/requirements rollup David Farmer
- Re: [mdnsext] mDNSext features/requirements rollup David Farmer
- Re: [mdnsext] mDNSext features/requirements rollup RJ Atkinson
- Re: [mdnsext] mDNSext features/requirements rollup RJ Atkinson
- Re: [mdnsext] mDNSext features/requirements rollup RJ Atkinson
- Re: [mdnsext] mDNSext features/requirements rollup Joe Touch
- Re: [mdnsext] mDNSext features/requirements rollup RJ Atkinson
- Re: [mdnsext] mDNSext features/requirements rollup Joe Touch
- Re: [mdnsext] mDNSext features/requirements rollup RJ Atkinson
- Re: [mdnsext] mDNSext features/requirements rollup Johnson, Neil M
- Re: [mdnsext] mDNSext features/requirements rollup Joe Touch