[rbridge] [saku@ytti.fi: Re: MAC aggregation in rbridge?]

[Saku Ytti]

 Apparently I haven't setup folder-hook, thus source address was wrong,
and email is sitting somewhere in queue waiting manual approval.

 And yeah, if course rbridge prefix + ifindex, isn't enough, either
prefix+ifindex+increment, or just prefix+increment.  But seems
that it was understood what I ment from the replies.

----- Forwarded message from Saku Ytti <saku at ytti.fi> -----

From: Saku Ytti <saku at ytti.fi>
To: "Developing a hybrid router/bridge." <rbridge at postel.org>
Subject: Re: [rbridge] MAC aggregation in rbridge?
Date: Wed, 7 Dec 2005 14:46:21 +0200

On (2005-12-07 13:29 +0100), Steven Bakker wrote:
 
> Mmmh, sounds like a L2 NAT? Just as in L3 (IPv4) NAT, L2 NAT has the
> potential to break many things. Right off the bat, I can tell you it
> will break ARP since ARP packets carry MAC address information in their
> payload. This means that for L2 NAT to work, your rbridges need to know
> about possible protocol and rewrite payloads, recalculate checksums,
> etc. This is not going to work. And even if it could, would that scale
> to 10GE and higher speeds? That's an awful lot of rewriting...

 Rewriting is already done in some IP-DSLAM (well just really bridges
with ethernet trunk, no routing) applications, but you typically want
to butt in to ARP's there anyhow. But still, your observation
is valid and it might be more pain than gain.

> IMO, it is unfeasible, unnecessary, and very undesired. Wearing the hat
> of my current employer (large scale Internet exchange), I like the idea
> of rbridge for its potential to better utilise the available links and
> efficiently route traffic. I pretty much have all the TCAM I need.

 Wearing the hat of any metro service provider today, amount of 
MAC addresses you can populate is quite small (think of lot L2 islands
connected via VPLS etc, think of providing ethernet-dslam bitstream)

> MAC aggregation might make sense if there were some kind of structure on
> the allocation of addresses (as in IPv4/v6), but there is not.

 Hence hierarchy needs to be forced, which is, undoubtfully most 
questionable part of it.

-- 
  ++ytti

----- End forwarded message -----

-- 
  ++ytti