Subject: [rbridge] ARP proxying

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 5 Jan 2006 20:03:26 -0500

Radia,

	I think it is the case that whatever optimization might
be proposed should work well with implementations that don't
support it.

	This is likely to be the case in optimization versions
I understand have been proposed to date.

	The set of topologies of optimized and non-optimized 
RBridges that are possible is arbitrarily large.  But it can
be shown that the "replay" version (with periodic deliberate
cache miss behavior) works well with one optimized RBridge
among any number of non-optimized RBridges (that one RBridge
will reduce ARP request/reply traffic on ports facing any
specific destination for which it holds a cache, and this 
behavior will have no direct effect, and a neglible indirect 
effect, on non-optimized RBridges in the same LAN).  That 
will hold for any topology of RBridges.  It also is true 
that replacing one or more additional RBridges, or insering 
new RBridges, with the ARP/ND Optimization consistently 
improves the behavior of the ARP/ND Optimization over-all 
without introducing strange corner cases - again in any 
topology.

	One way to look at the interactions between optimized
and non-optimized RBridges in such a scheme is to treat the
non-optimized RBridges as if they were optimized versions
that consistently see cache misses.  Consequently, proper 
behavior will occur in a mixed deployment as long as the 
specified behavior for the ARP/ND Optimization does not 
include deliberate behavior that makes excessive cache-miss 
behavior pathological.  An example of a pathological mis-
behavior of this sort would be anything that optimized 
RBridges do that assumes that everybody has a similar ARP 
(replay) cache (for instance, assuming that neighboring
RBridges already have cache entries and not forwarding ARP
replies).

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Thursday, January 05, 2006 7:08 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] ARP proxying
--> 
--> You're right. What I meant is that whatever mechanism there is for 
--> distributed ARP/ND queries,
--> all the RBridges have to support it. But it can be the 
--> choice of the 
--> first RBridge when each
--> mechanism is performed.
--> 
--> Radia
--> 
--> 
--> 
--> Erik Nordmark wrote:
--> 
--> >Radia Perlman wrote:
--> >  
--> >
--> >>I believe the ARP/ND optimization does need to be in the 
--> draft, because the
--> >>solutions we've talked about need to be done by all RBridges.
--> >>    
--> >>
--> >
--> >I don't understand why all RBridges would need to do the 
--> optimizations.
--> >
--> >At least for ARP replays, and for "ARP unicasts" (RBridges unicast 
--> >request to the last known egress RBridge for the MAC 
--> address) I can see 
--> >that some RBridges can do this based on the ARP 
--> information they have 
--> >cached, while other RBridges just forward the ARP request 
--> packets as any 
--> >other broadcast packets.
--> >
--> >It certainly would be nice if we could have this as an 
--> optimization, but 
--> >not require it.
--> >
--> >    Erik
--> >_______________________________________________
--> >rbridge mailing list
--> >rbridge at postel.org
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->