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
================================================