[rbridge] MAC aggregation in rbridge?
touch at ISI.EDU
Wed Dec 7 12:05:43 PST 2005
-----BEGIN PGP SIGNED MESSAGE-----
The edge devices seem to be just as complex in either case (translate
vs. encapsulate); with encapsulation, there are only as many internal
addresses as edge devices, whereas with translation there could be many
Given the current assumption of encapsulation, what is the gain of a
Harald Tveit Alvestrand wrote:
> My thought would be that transporting the source and destination MAC
> end-to-end is part of the Ethernet model, and we therefore have to respect
> it in any viable Rbridge design.
> Of course, if you use encapsulation, the rbridges are free to do whatever
> they want to do with the MAC of the "envelope" (if there is one).
> (note: encapsulating in IPv4 gives you hierarchy for free, and makes the
> envelope have 32 bits less space used on address than Mac-in-Mac.... tongue
> only slightly in cheek....)
> --On onsdag, desember 07, 2005 12:32:35 +0200 Saku Ytti
> <saku+rbridge at ytti.fi> wrote:
>> I was thinking about the feasibility of supporting MAC address
>>aggregation in rbridges. How I think it could work in most simple way is
>>that each rbridge has it's own MAC 'prefix' and it then performs MAC
>>rewrite on it's 'edge' port, effectively changing the original MAC to
>>rbridge prefix+ifindex. Then you'd have aggregated MAC TLV with mask to
>>propagate the information.
>> In more complex scenario, there could be more hierarchy and aggregation
>>depending on topology got from SPF.
>> Is this feasible? Is this needed or is it more sane to just grow
>>rbridge mailing list
>>rbridge at postel.org
> rbridge mailing list
> rbridge at postel.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the rbridge