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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 27 Oct 2006 12:07:16 -0400

Radia,

	What you say relative to the use of a "single Ingress Tree" is
correct, but we have not (and MUST NOT) preclude the use of VLANs in
interconnecting RBridges.

	Since the imposition of VLANs over an RBridge network creates
overlay VLANs that are not congruent, the creation of "ingress trees"
applies to each logically separate VLAN in use to connect RBridges.
Note that this requires no special behavior in RBridges, and thus is
a complicating factor in implementations, not in protocol design.

	What I mean is that 802.1Q encapsulation of RBridge "tunneled"
traffic is (and MUST be) as valid an encapsulation as other forms of
Ethernet encapsulation of RBridge "tunneled" traffic.  Consequently
(and without complicating RBridge protocols), it is certainly within
the range of possibility to configure VLAN information in RBridges 
such that there is a VLAN containing all RBridges with a common need
to deliver multicast traffic.

	I am unclear as to how this is semantically distinct from the
use of FTAGs - which would describe the same connectivity set and 
also require configuration - for support of "shared trees."

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of 
--> Radia.Perlman at sun.com
--> Sent: Thursday, October 26, 2006 7:52 PM
--> To: Sanjay Sane (sanjays)
--> Cc: rbridge at postel.org
--> Subject: [rbridge] How many trees, and per what
--> 
--> There is considerable confusion (certainly by me, and I'm 
--> sure others) at this point. Let me start a new thread to
--> specificallly discuss which trees should be computed.
--> 
--> The WG consensus seemed to be to compute per-ingress trees 
--> rather than
--> shared trees. For several reasons, e.g.,
--> 
--> a) the number of packet hops to deliver a packet to just a 
--> subset of links (as would be the case with
--> a packet only going to links for a particular VLAN, or for 
--> an IP multicast that is only going to links with
--> registered receivers plus IP multicast routers) can be a 
--> lot more than necessary if we are not using
--> a per-ingress tree, and instead using a shared tree
--> 
--> b) a few packets in a conversation from S to D are more 
--> likely to get out of order if at first D is unknown, and
--> the packet is sent on a shared tree, and then when D is 
--> found, going directly, since the path from S to D might
--> be much longer in the shared tree than the tree rooted at 
--> S's Designated Rbridge
--> 
--> It is true that it would take less memory and computation 
--> to use a shared tree, even multiple per-F-tag shared
--> trees, but they would not have the properties a) and b) above.
--> 
--> So I believe if we do per-F-tag trees, we will be 
--> multiplying the number of trees by F-tag, and computing
--> (# of Designated Rbridges) * (# of F-tag values).
--> 
--> I don't believe we should revisit the per-ingress trees. 
--> Especially if the reason is to make better use of
--> bandwidth by using F-tags, since using per-ingress trees 
--> certainly will cut down on bandwidth use for
--> IP multicast packets and unknown/multicast VLAN-tagged packets.
--> 
--> 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 *think* the only purpose of using multiple F-tag values 
--> and trees is to spread traffic around, and engineer traffic
--> for certain classes of traffic. 
--> 
--> Radia
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->