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

_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to