[rbridge] How many trees, and per what

[Sanjay Sane (sanjays)]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFQoHbER27sUhU9OQRAipMAJ4whaXVLKMKVOfXBujtgRfd3vgK5wCgvGGQ
r2IwhU5kgDBVfpL9FGJ16Yc=
=g8Wb
-----END PGP SIGNATURE-----