[rbridge] Updated charter

Eric Gray eric.gray at ericsson.com
Sat Jul 17 18:02:55 PDT 2010


James,

	See "EG> " below...

--
Eric 

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson
Sent: Saturday, July 17, 2010 10:19 AM
To: Linda Dunbar
Cc: 'Developing a hybrid router/bridge.'; 'Jari Arkko'
Subject: Re: [rbridge] Updated charter

On 7/16/10 4:42 PM, Linda Dunbar wrote:
> Section 3 of the draft (ARP Optimization Details) listed 5 steps. The first
> step is "observing native ARP request and reply frame" to learn the frame's
> IP, VLAN. 
> 
> This snooping at line rate is not trivial, requiring the switch port to
> filtering all the ARP messages at line rate and store the learned IP
> addresses and VLANs.

It already has to snoop at all frames on the wire to learn source MAC
addresses and to do normal forwarding.  In some implementations (such as
the one I worked on at Sun), that's 99%+ of the cost.  

EG> So, the fact is that source MAC learning is already done in bridges
EG> (and has been done in bridges for a very long time).  Finding H/W
EG> that does this _is_ trivial.
EG> 
EG> For sure, if you want to start over - possibly because you want to
EG> do additional stuff, while you're about it - it can be a bit hard.
EG> 
EG> And that makes me want to understand whether your implementation
EG> elected to do things the hard way simply because the implementors 
EG> in your case were already predisposed to doing this extra stuff.

--- [SNIP] ---


More information about the rbridge mailing list