[rbridge] ARP proxying

[Radia Perlman]

I wasn't arguing about changing the mechanism (that the first RBridge 
responds to an
ARP/ND query with the target's MAC address). I was just saying that I 
don't want the
name to change if we make slight changes to how it works. So the only 
thing I was
arguing was to use the term "ARP/ND optimization" rather than "replay" 
"proxy" or
whatever, which seem to have specific and different meanings to people.

I always think it's useful to consider all sorts of variants of a 
scheme, and to think about their
pluses and minuses. I wasn't advocating answering anything other than 
with the target's MAC address,
because after carefully considering the implications of the 
alternatives, we concluded answering
with the target's MAC address was the best choice.

So the only point of my note is that we come up with a generic name for 
the mechanism, or the
problem we are solving, and then in the spec we say exactly how it 
works, rather than choosing
a name that we think will define the mechanism just by its name.

So...we're all agreeing, right? We'll call it "ARP/ND optimization", the 
main mechanism will be
that an RBridge responds to an ARP/ND query with the target's MAC 
address (if known),
and we might also suggest states when something more drastic is done 
rather than depending on
the RBridge's cache being correct.

Radia



Joe Touch wrote:

>-----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-----
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>