Subject: [rbridge] Ingress Rbridge and FTAG again

From: sanjays at cisco.com (Sanjay Sane (sanjays))
Date: Wed, 25 Oct 2006 19:30:26 -0700

see inline with <sanjay>

-----Original Message-----
From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
Sent: Wednesday, October 25, 2006 4:47 PM
To: Sanjay Sane (sanjays)
Cc: Alia Atlas; Dinesh G Dutt (ddutt); rbridge at postel.org
Subject: Re: [rbridge] Ingress Rbridge and FTAG again

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.

<sanjay>
ftag # represents the shared tree. For a given tree, all rbridges
compute the same tree, with the same rbridge as the root, and associate
their forwarding tables with the same ftag #. Once a rbridge gets a
packet with the ftag #, they select the forwarding table relevant to
that ftag #. 

             B
             |
           |----|
          /| R2 |\
   |----|/ |----| \|----|
A--| R1 |          | R3 |-C
   |----|          |----|
        \        / 
         \|----|/
          | R4 |
          |----|
            |
            D

Lets say all hosts (A,B,C,D) are interested in groups G1, G2, 
All rbridges (R1, R2, R3, R4) build 2 trees, one rooted at R2 (loop
broken at R2-R3), (tree has ftag = Ftag-R2), another rooted at R4 (loop
broken at say R1-R2), (tree has ftag = Ftag-R4

Then, a multicast for G1 sourced at A, may be choosen to be sent on
Ftag-R2. 
Then, a multicast for G2 sourced at A, may be choosen to be sent on
Ftag-R4. 
[ It may be possible all packets sourced at R4 use only 1 tree --
Ftag-R4 ]

At any intermediate rbridge, say R2, I would consult the forwarding
table [Ftag-R2,G1] OR [Ftag-R4,G] based on the FTAG carried by the
packet (NOT what the source rbridge is). Similarly loops would be broken
based on Ftag in the packet. 

If we needed multipathing from each source-rbridge, say 2 trees per each
source-rbridge, we would need to be able to store 4 * 2 combinations. In
reality, we don't need so many trees, but at any given time, we may need
the flexibility to be able to provide multicast multi-pathing from any
given source rbridge.  

-Sanjay

The trees are shared by multiple source/ingress rbriges. We wont be
computing 1000 trees from each source rbridge. 

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