[rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)

[Gray, Eric]

Silvano,

	I think the best use of our time - yours and mine - would be for
you to review the protocol specification and point out where it is not
clear what the text in that draft means to an implementer.

	The reason why I say this is that your question indicates to me
that - if you have read the existing specifications - we have not been
doing a good job of capturing WG decisions and progress in this area,
in those documents. 

	There is a logical construct we refer to as ingress rbridge tree
that exists for each ingress RBridge.  This is a logical construct only
as it is not exactly a tree - and certainly not a tree in the sense of
a spanning tree.  

	Essentially, it is an overlay of multiple trees, where the base
tree provides one-way, p2mp delivery to at least the subset of egress 
RBridges having a common set of VLANs (including the "default" VLAN
- corresponding to un-tagged Ethernet).  "Overlay" versions of this
tree consist of various "prunings" of the base tree based on egress 
membership in VLANs and multicast groups.  "Pruning" is accomplished 
at intermediate RBridges by creating, modifying and deleting entries 
in a forwarding table used for IRT forwarding across the CRED (in the 
architecture document, this forwarding table is called the CFT-IRT).

	Since it cannot be the case that a destination intended to be
included in forwarding a multicast frame, is not reachable via the
IRT, I cannot imagine why you say that VLANs cannot be used for this
purpose.  Hence, there is clearly some kind of misunderstanding...

--
Eric 

-- [SNIP] --
--> 
--> VLAN within a CRED can work for unicast, but not for multicast.
--> As multicast is currently defined in TRILL the root of the tree is
--> ALWAYS in the ingress RBridge, independently of how many 
--> VLANs you have.
--> 
-- [SNIP] --