[rbridge] Ingress Rbridge and FTAG again

[Sanjay Sane (sanjays)]

I can see FTAG being useful to reduce hardware-cost in the scenario of
shared multicast trees.

Multi-pathing for multicast packets can be easily done only when there
are multiple shared trees to choose from. Each source-rbridge could have
a list of trees to choose from, and some hash (such as based on DA) can
be used to pick the tree. Once the tree is chosen, rest of rbridges must
forward the packet on the same tree, otherwise there'll be loops &
duplicates. 

Such shared multicast trees can be easily built by every rbridge
computing multiple trees/Djikstras with different (& well-placed) roots.
One may want to configure the roots of these trees in the core of the
network (assuming an access-aggregation-core topology).

We may want some m number of trees per VLAN to support multicast
multi-pathing. Typically, unicast supports 16 path multi-pathing. So,
(maybe) we should be able to support 16 trees per VLAN for multicast
multi-pathing. 

One way to distinguish different multicast trees is by carring some
additional tag & looking up forwarding-tables/port-logic with index
{vlan, tag-value}. Even if this additional tag is 3 bits (max 8 trees),
hardware needs to support 4k * 8 = 32k values (or a tcam which is also
expensive).   

I don't expect we need so many multicast trees, but I do want the
flexibility to at least support 8-way multipathing for each VLAN, but
don't want to build such costly hardware. 

Thus, it would be easier if everyone agrees on a single number space
(Ftag!), and associate a given multicast-tree of a given VLAN to a
particular Ftag. Proposed Ftag is 10 bits, so maximum number of trees in
my port-logic/forwarding-table is 1k. 

Sanjay
 

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Alia Atlas
Sent: Monday, October 23, 2006 1:47 PM
To: Dinesh G Dutt (ddutt)
Cc: rbridge at postel.org
Subject: Re: [rbridge] Ingress Rbridge and FTAG again

Hi Dinesh,

On 10/20/06, Dinesh G Dutt <ddutt at cisco.com> wrote:
> Alia Atlas wrote:
> > I certainly haven't heard a strong enough argument for including the

> > ingress rbridge.  For instance, if you really want traceroute equiv,

> > well, the encapsulated Ethernet frame contains  the source MAC from 
> > right before the entrance to the rbridge area.  Why can't that be 
> > used to get replies back?
> The reason is that this requires the core Rbridges to also populate 
> the tables with the mapping from MAC address to Rbridge. Not requiring

> the core Rbridges to maintain a large MAC table is one of the 
> advantages of Rbridges.

Not maintaining a large MAC table in hardware could be an advantage of a
core Rbridge.  However, given that the MAC to rbridge association is
provided through the routing protocol, even a core Rbridge will
certainly have the information available in software.   Could you
explain why you don't think this is sufficient?  Traceroute in IP is
frequently on the slowpath going through software; why would it need to
be different for this case?

> > As to the Ftag, I've not heard why the 3 bits that are equiv to the 
> > EXP bits in an MPLS header coudn't be used to indicate a CoS related

> > mechanism.
> Again, if you read my rather lengthy email, you'll see why three bits 
> are insufficient. The main reasons stem from having to do shared 
> multicast trees. Eric points out a way to do it using an additional 
> .1Q header and redefining (I think) the meaning of the VLAN field. 
> That has the disadvantages that I pointed out in my emails to him.

I had been scanning the emails & may have missed your argument about
three bits being insufficient.  How many shared multicast trees do you
think is sufficient and why?
Does the ingress Rbridge select which shared multicast tree to use for
a frame?   How are the shared multicast trees created and agreed upon?

If a frame is destined for a shared multicast tree, does the ingress
rbridge id in the shim have any relevance to the forwarding?

> >
> > I am particularly against the idea, that hasn't gotten much 
> > discussion, of trying to include info about how the final rbridge 
> > should direct a packet out.  I think this impacts the scalability & 
> > requires additional knowledge be distributed to all the rbridges.  A

> > similiar thing can be done with the MPLS Layer-3 VPN, where a 
> > different label is used to indicate the outgoing interface, etc.
> If you're thinking about the LID, I don't think it is analogous to 
> requiring an additional label. It is adding additional bits to the 
> switchID that are of consequence to the final Rbridge only. Also, I 
> understand that the arguments for including a LID may not be 
> technically strong enough to merit the overhead they add.

My concern  for the LID isn't just the bits that it adds to the header.
It is the additional table space required by the hardware of all the
Rbridges to produce frames with different encapsulations based upon the
final outgoing interface.  Additionally, how many ports or interfaces
would be sufficient?  Why?

If you're not seriously trying to move that idea forward, there's
probably little point discussing it here, given the debate on the other
two.

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