Subject: [rbridge] MAC aggregation in rbridge?

From: saku+rbridge at ytti.fi (Saku Ytti)
Date: Wed, 7 Dec 2005 12:32:35 +0200

Hey,

 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
TCAM sizes?

-- 
  ++ytti

---

From: steven.bakker at ams-ix.net (Steven Bakker)
Date: Wed, 07 Dec 2005 13:29:50 +0100

> you'd have aggregated MAC TLV with mask to propagate the information.

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...

>  Is this feasible? Is this needed or is it more sane to just grow

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.

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.

Regards,
Steven

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 07 Dec 2005 17:03:06 +0100

Sakku, Steven,

Just for  information on MAC aggregation, you can find here a link to a 
proposal  originated by Jose  Morales, based on private MAC  addresses 
assignment by ISPs (and the like), that allows aggregation.  I have no 
defined position on this proposal, but there are interesting aspects on 
it to analyze. Regarding upper layers the proposal is quite radical.
Guillermo

 http://www.lmdata.es/uets/uets-cm1.pdf

Steven Bakker wrote:

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Wed, 07 Dec 2005 20:44:53 +0100

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).

                        Harald

(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:

> Hey,
>
>  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.
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 07 Dec 2005 12:05:43 -0800

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
more.

Given the current assumption of encapsulation, what is the gain of a
translation-based system?

Joe

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 09 Dec 2005 11:26:10 +0100

This additional document from IEEE Global Communications Newsletter 
October 2005, may help to better understand the UETS proposal, mentioned 
in my previous mail,   that includes MAC aggregation.
http://www.lmdata.es/uets/uets-gcn.pdf
Guillermo

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794