Subject: [rbridge] How many trees, and per what

From: sanjays at cisco.com (Sanjay Sane (sanjays))
Date: Fri, 27 Oct 2006 17:41:13 -0700

Russ, Radia, et. al.

Having a per-ingress rbridge tree, and using it for multicast delivery
has many issues
-- no scope for multicast multi-pathing/load-balancing
-- for an IP multicast that is only going to links with registered
receivers, we now need to build a state with 
# of ingress rbridges * # of groups. This is heavy on computation &
memory. 

Using shared multicast trees for multicast delivery avoids both above,
and the forwarding state is # of shared trees * # of groups. 

Also, instead of adding F-tag "values" to the context of the Rbridge-id,
why not treat "F-tag" as the Forwarding topology identifier. (quote from
http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-encap-00.txt
--> "The Forwarding Tag (FTag) identifies the forwarding topology
assigned to a given frame"). 

In the tree usage case (unknowns/multicast/broadcast), it's the tree
identifier. If flood/unknown packets are best sent using ingress-rbridge
tree, use the F-tag of the tree rooted at that ingress rbridge. If
multicast packets are best sent using shared-multicast trees, use the
F-tag of the (load-balanced) shared tree. 

Again, which tree/topology the packet is to be put onto, is the decision
made at the source/ingress rbridge. But once the tree is chosen, and the
F-tag is put on the packet, other rbridges honor the F-tag and forward
accordingly.  

-Sanjay

-----Original Message-----
From: Russ White [mailto:riw at cisco.com] 
Sent: Friday, October 27, 2006 3:02 PM
To: Radia.Perlman at sun.com
Cc: Sanjay Sane (sanjays); rbridge at postel.org
Subject: Re: [rbridge] How many trees, and per what

> So the question is whether we should multiply the number of trees by 
> the number of F-tag values. And if so, how many F-tag values are
really needed.

I seem to be lost in the F-tag discussion, someplace.... Time warp,
anyone? :-)

My original impression was one tree per device per vlan throughout the
entire cloud, with some consideration for multicast still be taken in. I
don't really understand why we'd want one pre f-tag, maybe someone
should explain what we'd hope to gain through this?

:-)

Russ

- --
riw at cisco.com CCIE <>< Grace Alone

---

From: akatlas at gmail.com (Alia Atlas)
Date: Fri, 27 Oct 2006 19:42:57 -0700

Sanjay,

> F-tag is put on the packet, other rbridges honor the F-tag and forward

Why have a separate additional field for this purpose?  The only
meaning of the ingress rbridge nickname in the shim header is, I
believe, to indicate the intended multicast tree.   Could the shared
multicast trees be given a nickname from the same space?  This would
avoid the need for the additional overhead and change in the header.
Are there scalability considerations that would make this a problem?

Alia