Subject: [rbridge] ARP proxying

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 19 Dec 2005 10:58:00 -0500

Joe,

	Are you sure that you're not deliberately trying to make
things more difficult to understand?

	Caching - in general - is well understood.  The form of
storing ARP entries in passing - in order to reduce ARP traffic
across the RBridge campus - that I have seen described on this
list so far, is directly analogous to any number of different
"Caching" uses.

	The fact that RFC 925 describes using a cache or ARP 
entries as a basis for what RFC 1009 subsequently defines as
ARP caching (or "the ARP hack"), in no way implies that this 
is what anyone would generally refer to as ARP caching.  In
fact, one use for the cache defined in RFC 925 is the MAC DA
"translation" that occurs in traversing an Internet Gateway
(router).

	While it is clearly too late to change the prior usage,
the function described in RFC 1009 would be better termed an
"ARP Translation" than an "ARP Proxy".

	I think many of us are convinced that "ARP Proxy" can't
be used because of earlier (historical) reasons (whether we
regard those as in error or not).  I do not think the term
"ARP Replay" is sufficiently descriptive and I believe that
the suggestion is made pejoratively - in what certainly looks
like an attempt to prejudice the working group against any
such discussion.

	Therefore, I again suggest using the term ARP Caching.

	I don't really care that hosts do it.  I don't care that
Disk Drive controllers do it.  I don't care that Web sites do
it.  I just want us to settle on a term that is consistent with
what is described and is not chosen to add unwanted freight.

--
Eric

--- [SNIP] ---

--> Gray, Eric wrote:
--> > Radia/Joe,
--> > 
--> > 	We can call it ARP caching (which would make some sense
--> > - possibly more than ARP replay), 
--> 
--> ARP caching is what hosts and proxy ARP-ing routers already do (ala
--> RFC1122). See TCP/IP Illustrated, Vol 1, section 4.3.
--> 

--- [SNIP] ---

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 19 Dec 2005 08:22:10 -0800

> things more difficult to understand?

As Harald said, we need to use existing terms in existing ways. Both
proxy ARP and ARP caching are existing, well-defined terms, and neither
applies to what we have been describing for rbridges.

> list so far, is directly analogous to any number of different

Analogous perhaps, and certainly proxy ARP and ARP reply, as well as end
nodes internally, all use caches.

> ARP caching (or "the ARP hack"), in no way implies that this 

proxy ARP in 1009.

> "translation" that occurs in traversing an Internet Gateway

Except that the rules for ARP caching are the same for all ARP caches -
regarding cache refresh, timeout, etc. That's why it's useful and
important to consider them equivalent.

> "ARP Translation" than an "ARP Proxy".

That would require our redefining that term, as well as corresponding
proxy terms in other widespread use - notably web proxy. Proxying in
these cases, as well as in general English, refers to one party
_representing_ another, not trying to fake being another.

> like an attempt to prejudice the working group against any

This _is_ a replay, with all the good AND bad associations. It's useful
to consider those issues, e.g., that replay won't work if proper
anti-replay measures are implemented.

> what is described and is not chosen to add unwanted freight.

It's not consistent with the well-established use of the term in IETF
Standards documents, which means (IMO) that's not a viable option.

Joe

> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051219/2e86a438/signature.bin