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

["Joel M. Halpern" <[e-mail]>]

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
>