[rbridge] Ingress Rbridge and FTAG again

Wed Oct 25 16:46:32 PDT 2006

Sanjay Sane (sanjays) wrote:

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

Again, apologies that I haven't had a chance to catch up on this whole 
discussion, but I'm confused.
If you use 10 bits of Ftag to have 1000 different metrics, for which 
1000 trees can be computed,
don't you have to multiply the number of trees by the number of ingress 
RBridges? So it wouldn't
be 1K trees, it would be 1K times the number of ingress RBridges.

You also said:

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

What hardware cost are you reducing? I'd assume that what you might save 
in using multiple trees
is bandwidth, since traffic would be spread more. But I'd think having 
multiple
per-F-tag trees would *increase* hardware cost
because of having to compute more trees and keep more forwarding tables.

Radia

Sanjay Sane (sanjays) wrote:

>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
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>