[rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
sgai at nuovasystems.com
Fri Oct 20 08:21:58 PDT 2006
No Problem, in:
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
The use of shared trees is therefore impossible. Do you agree?
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
The draft states that "a particular VLAN may transit any link on the
campus". Pretty strong statement.
> -----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
> New fields in shim header?)
> 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
> 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...
> -- [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] --
More information about the rbridge