[rbridge] ARP proxying

[Joe Touch]

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



Radia Perlman wrote:
> How about just "ARP/ND optimization". That means that we don't have to 
> give a name
> to the actual mechanism...I think that term would be clearly implying 
> that there are various
> mechanisms that could do this. I'd hate to have to change the word if we 
> decided that
> the Designated RBridge on the querier's link should respond with any of 
> the following:
> 
> a) the target's MAC

That corresponds to what I was calling "ARP replay"

> b) the DB's MAC

That corresponds to proxy ARP, and works only if the DB then translates
that to the MAC of the destination for every frame.

> c) the egress RBridge's MAC

That doesn't appear to work; the node sending the ARP request would then
send unencapsulated traffic to the egress, defeating the 'routing'
inside the rbridge campus.

> d) a logical MAC address meaning "my DB's MAC".

I'm not sure how this differs from (b), except to use a logical MAC
rather than the physical MAC. The effect would be the same.

Of the above, only (a) will continue to work if the rbridges are swapped
with bridges, e.g., for maintenance or due to device failure.

> There were other alternatives discussed, including not optimizing 
> ARP/ND...just forwarding them like any other L2 multicast, as well as
> sending directly to the assumed DB of the target, and forcing the
> actual target to respond. I think, as I said, that perhaps one of
> these alternatives should be done sometimes, in case the cache is
> stale. In DECnet we had a "tryhard" bit that was used primarily in
> the interface from layer 4 to layer 3 inside a node, which said "get
> rid of caches that might be stale", which was invoked if layer 4 was
> having a hard time making a connection to a target. It might be nice
> to add such signalling from endnode to RBridge at some point, but we
> don't need it now.

Stale caches are only one issue; how the caches are refreshed is
another. Typical ARP caches are refreshed when _either_ they are
referenced locally or when a new ARP reply is seen (source address of
the entry in question, see RFC1122 sec 2.3.2.1). It would be hard to
flush entries in a cache that are nonlocal - as per that section. I.e.,
if the cache is moved from the host, it needs to have the signalling
described above at a minimum.

The other issue is the 'silent relocation' - when a node's MAC address
changes, or when it silently moves from the segment of one DR to
another. In either case, traffic will be misdirected until the receiver
speaks up, but there would be no reason for the receiver to do so.

As a result, it would be useful to consider the advice of RFC1122 (same
section) on proxy ARP - to limit the rbridge caching of replies to 1
minute max, regardless of refresh.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDqHgrE5f5cImnZrsRAhAVAJ0Rd6WqA5m1kRvUcqxjrhZfjirLdACfRxEk
hE4Zdhs0Ij3mQQVUc+m71uE=
=yOXx
-----END PGP SIGNATURE-----