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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0720611E80D7; Wed, 29 Aug 2012 13:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.348
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pq+ZQN77TwAS; Wed, 29 Aug 2012 13:59:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7518011E80EA; Wed, 29 Aug 2012 13:59:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2F74CA5FCD; Wed, 29 Aug 2012 13:59:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A6B41C9F23; Wed, 29 Aug 2012 13:59:12 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9F52E1C9E9D; Wed, 29 Aug 2012 13:59:11 -0700 (PDT)
Message-ID: <>
Date: Wed, 29 Aug 2012 16:59:07 -0400
From: "Joel M. Halpern" <>
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 <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc:, "A. Jean Mahoney" <>, "" <>
Subject: Re: [armd] Gen-art] review: draft-ietf-armd-problem-statement-03
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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,

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