Re: [armd] Gen-art] review: draft-ietf-armd-problem-statement-03

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 29 August 2012 20:59 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: armd@ietfa.amsl.com
Delivered-To: armd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0720611E80D7; Wed, 29 Aug 2012 13:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.348
X-Spam-Level:
X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 pq+ZQN77TwAS; Wed, 29 Aug 2012 13:59:14 -0700 (PDT)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7518011E80EA; Wed, 29 Aug 2012 13:59:14 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 2F74CA5FCD; Wed, 29 Aug 2012 13:59:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9A6B41C9F23; Wed, 29 Aug 2012 13:59:12 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [10.10.10.104] (pool-71-161-50-84.clppva.btas.verizon.net [71.161.50.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9F52E1C9E9D; Wed, 29 Aug 2012 13:59:11 -0700 (PDT)
Message-ID: <503E829B.1000404@joelhalpern.com>
Date: Wed, 29 Aug 2012 16:59:07 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
References: <50243C05.3080006@nostrum.com> <502471DB.80303@joelhalpern.com> <201208291559.q7TFxgmJ012331@cichlid.raleigh.ibm.com> <503E3E54.70506@joelhalpern.com> <201208291954.q7TJsGqx015175@cichlid.raleigh.ibm.com>
In-Reply-To: <201208291954.q7TJsGqx015175@cichlid.raleigh.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: gen-art@ietf.org, "A. Jean Mahoney" <mahoney@nostrum.com>, "armd@ietf.org" <armd@ietf.org>
Subject: Re: [armd] Gen-art] review: draft-ietf-armd-problem-statement-03
X-BeenThere: armd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." <armd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/armd>, <mailto:armd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/armd>
List-Post: <mailto:armd@ietf.org>
List-Help: <mailto:armd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/armd>, <mailto:armd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Aug 2012 20:59:15 -0000

Yes, that is better.
(While I disagree with the WG on some of the drivers here, I think the 
text is sufficiently accurate and clear at this point that I should be 
considered to be in the rough.)

Thank you for the time and attention,
Joel

On 8/29/2012 3:54 PM, Thomas Narten wrote:
> Hi Joel.
>
>> All of the proposed resolutions look very good.  Thank you.
>
> Great!
>
>> With regard to routers and ARP caches, my concern is that from what I
>> saw of the years, common practice did not seem to match the SHOULD from
>> the RFCs.  I am a little remote from most implementations at the moment
>> (the ones I can check easily are a tiny fraction of the market), so I
>> was suggesting that be double-checked.
>
> I hear you, and I suspect that there is a wide variability in what
> routers implement. And the easy implementation (especially for the
> fast path) is not to queue anything at all, which would still be
> compliant since queuing is only a SHOULD...
>
> I've tweaked the text a bit more after looking at the actual
> requirements (e.g., the spec doesn't say you have to send an ICMP
> unreachable on an ARP miss, it only says that if you do, you shouldn't
> do it just because there is no ARP entry).
>
> In any case, the point of this paragraph is really just to explain the
> steps, to show they can be "cpu intensive". I think the WG asserted
> pretty strongly that for some implementations/deployments, the
> implementation cost is a problem (i.e., CPU intensive to the point of
> being problematical).
>
>     Finally, another area concerns the overhead of processing IP packets
>     for which no ARP entry exists.  Existing standards specify that one
>     (or more) IP packets for which no ARP entry exists should be queued
>     pending succesful completion of the address resolution process
>     [RFC1122] [RFC1812].  Once an ARP query has been resolved, any queued
>     packets can be forwarded on.  Again, the processing of such packets
>     is handled in the "slow path", effectively limiting the rate at which
>     a router can process ARP "cache misses" and is viewed as a problem in
>     some deployments today.  Additionally, if no response is received,
>     the router may send the ARP/ND query multiple times.  If no response
>     is received after a number of ARP/ND requests, the router needs to
>     drop any queued data packets, and may send an ICMP destination
>     unreachable message as well [RFC0792].  This entire process can be
>     CPU intensive.
>
> Is that any better?
>
> Thomas
>