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

[Silvano Gai]

Eric,

No Problem, in:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
.txt

section 2.1.2 states:
"   Some frames (e.g., to unknown destinations, or multicast 
   destinations) will need to be delivered to multiple links. To 
   optimize delivery in the case where not all links are to receive the 
   frame (e.g., an IP multicast or a VLAN-tagged frame), and to avoid 
   out-of-order delivery when location of the destination is discovered 
   after a flow starts up, RBridges calculate a tree per ingress 
   RBridge, and deliver a frame along that distribution tree. The 
   ingress RBridge trees will be calculated based on the link state 
   information distributed in the core IS-IS instance. "

It is therefore clear that all multicast traffic will be sent on trees
rooted on the ingress RBridge, independently of how many VLANs are
present.

The use of shared trees is therefore impossible. Do you agree?

Also
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-00
.txt
speaks about VLANs and it says:
" A VLAN is a broadcast domain. That means that a layer 2 broadcast 
   (multicast) frame sent to a VLAN must only be delivered to links that

   are in that VLAN. A encapsulated frame destined for a particular VLAN

   may transit any link on the campus, but an unencapsulated VLAN frame 
   must only be delivered to links that RBridges know (for example, 
   through configuration) support that VLAN."

>From this sentence I have a hard time understanding what you were saying
in a previous message, i.e.
"	Note that this use of VLAN tags in the tunnel encapsulation
- while not entirely orthogonal to VLAN tag usage in native encaps
- does not necessarily result in depletion of the native VLAN tag
space."

The draft states that "a particular VLAN may transit any link on the
campus". Pretty strong statement.

-- Silvano



> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Friday, October 20, 2006 7:45 AM
> To: Silvano Gai
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Range of appllicability (was Re: TTL only - was
RE:
> New fields in shim header?)
> 
> 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] --