[rbridge] ARP proxying

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Joe Touch wrote:
> 
> 
> Gray, Eric wrote:
> ...
> 
>>>--> > 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).
>>>--> 
>>>--> 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.
>>>
>>>Earlier (Friday, 12/16), in a post on this same subject, Radia said
>>>(in part) 
>>>
>>>
>>>>>b) getting rid of stale ARP caches faster by sometimes (we'd have 
>>>>>to decide >>under what circumstances) sending the ARP query directly
>>>>>to the assumed target's link, and making the target respond.
>>>
>>>I am unclear how this behavior is a significant departure from a
>>>typical ARP cache implementation in a host or router.
> 
> 
> ARP caches don't typically remove non-stale entries of their own accord;
> when they do, they don't emit ARP requests except based on a trigger of
> need (e.g., a cache miss of an IP packet to be emitted).
> 
> ARP caches are typically updated by ARP activity as snooped on the wire,
> i.e., if a new ARP request or response would replace an entry, the entry
> is silently updated.
> 
> ...
> 
>>>--> > 	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.
>>>--> 
>>>--> 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.
>>>
>>>I disagree.  Apparently, your offer for someone else to suggest a
>>>term was not genuine as you appear unwilling to accept any such
>>>suggestion.
> 
> 
> Your suggestion was to use ARP caching. We agree not to try to redefine
> proxy ARP, but ARP caching has an equally old and established
> definition. While it is part of proxy ARP and ARP replay (or whatever
> the latter ends up being called), it's clear it isn't appropriate to
> describe it either.
           ^^

to describe what it is that rbridges should/could do for optimization...

> 
> It would also be useful to explain how you disagree with my assessment
> of how this IS replay (i.e., did you mean it is NOT replay, it is NOT
> useful to consider the issues, or that what we're asking an rbridge to
> do would continue to work in the presence of anti-replay?)
> 
> JOe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDpzmPE5f5cImnZrsRAo0bAKCE9yOomiMsIjYHugwjGe7t22//TQCgo/2V
a1xccwstrrvs8hH+faTq5tw=
=nc+I
-----END PGP SIGNATURE-----