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

[Thomas Narten <[e-mail]>]

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