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

Thomas Narten <> Wed, 29 August 2012 19:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A64C11E80F1 for <>; Wed, 29 Aug 2012 12:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zr8xYxQm6kKU for <>; Wed, 29 Aug 2012 12:55:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9068E11E80EE for <>; Wed, 29 Aug 2012 12:55:04 -0700 (PDT)
Received: from /spool/local by with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <> from <>; Wed, 29 Aug 2012 13:55:03 -0600
Received: from ( by ( with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 29 Aug 2012 13:54:22 -0600
Received: from ( []) by (Postfix) with ESMTP id B43F319D8043; Wed, 29 Aug 2012 13:54:21 -0600 (MDT)
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7TJsKXr115518; Wed, 29 Aug 2012 13:54:20 -0600
Received: from (loopback []) by (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7TJsJmo007163; Wed, 29 Aug 2012 13:54:19 -0600
Received: from ([]) by (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q7TJsI1e006958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 13:54:18 -0600
Received: from (localhost.localdomain []) by (8.14.5/8.12.5) with ESMTP id q7TJsGqx015175; Wed, 29 Aug 2012 15:54:17 -0400
Message-Id: <>
To: "Joel M. Halpern" <>
In-reply-to: <>
References: <> <> <> <>
Comments: In-reply-to "Joel M. Halpern" <> message dated "Wed, 29 Aug 2012 12:07:48 -0400."
Date: Wed, 29 Aug 2012 15:54:16 -0400
From: Thomas Narten <>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12082919-6148-0000-0000-0000090DBF5F
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 19:55:05 -0000

Hi Joel.

> All of the proposed resolutions look very good.  Thank you.


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