Subject: [rbridge] Must/Should flooding optimization

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 24 Mar 2006 12:42:49 -0500

Dino,

	Thanks for the reply.

	So the issue you are concerned about is scoping multicast
by VLAN.  I see 3 remaining clarifications required in reponse
to the portion of your message that I've included below.

========================= 1 ====================================

	To clarify the question I asked specifically about your
concerns in this case, I was trying to ask the following:

o	In every case (with or without VLAN optimization within
	the RBridge campus), an egress RBridge MUST filter VLAN
	traffic on egress (i.e. - when decapsulating RBridge to
	RBridge traffic for forwarding on a Ethernet link).
o	There has never been any intention not to do this.
o	This is highly consistent with the minimal-configuration
	goal of the TRILL WG because egress RBridges - at least
	- will need to know (most likely from configuration) what
	VLANs are associated with what RBridge interfaces.

o	So, given the above context, how do you expect that any
	VLAN-scoped Multicast could end up being delivered on an
	innappropriate VLAN interface? 

========================== 2 ===================================

	On your further point, "pruning for a multicast group is 
always a subset of the pruning for a VLAN toplogy" - I agree
completely.  

	However I must add - strictly for "correctness" - that 
there is no ordering requirement in the sub-setting operation
by VLAN and Multicast group.  

	An implementation may do this using per-VLAN tables where 
multicast group is part of the look-up, a per-Multicast-Group 
table where VLAN is part of the look-up or a single table where 
VLAN and multicast group are both part of the lookup.

	These are clearly isomorphic representations of a common
sub-setting operation.  This same observation applies to an 
RBridge campus as a whole.

=========================== 3 ==================================

	On your last point, the fact that routers and hosts are
not included as part of an RBridge campus is relevant because:

o	Routers and hosts will only receive frames after they've
	been delivered by an egress RBrdge to the LAN segment on
	which the host or router is present.
o	The egress RBridge will necessarily have applied a VLAN
	specific filter prior to delivering any traffic to the
	LAN segment on which the RBridge is present.

->	Therefore, routers and hosts will not receive multicast 
	frames that were not intended to be delivered to a VLAN
	on which a router (or host) resides.

--
Eric

.. [SNIP] ..

--> 
--> >> As a clarification question, I am not sure whether this relates
--> >> to VLAN support or multicast support.  Can you please clarify 
--> >> the following points?
--> 
-->     Multicast support which is scoped within a VLAN.

.. [SNIP] ..

--> >> If your concern relates to VLANs in combination with multicast,
--> >> how is this a problem if VLAN pruning necessarily occurs when
--> >> frames egress from the RBridge campus?
--> 
-->     I really don't understand the question but let me respond by 
-->     saying the pruning for a multicast group is always a subset 
-->     of the pruning for a VLAN toplogy.
--> 
-->     The concern is that data packets and IGMP reports are send to 
-->     the same MAC address. So packets need to go to different 
-->     places then the IGMP reports go.
--> 
--> >> 
--> >> It has been a question from the very beginning of this effort 
--> >> as to whether or not there would be discrete Ingress RBridge
--> >> Trees per-VLAN (which corresponds to pruning VLAN traffic at
--> >> each RBridge), but there has never been a question about doing
--> >> this "VLAN pruning" at egress from the RBridge campus.
--> 
-->     Well the set of routers on one VLAN can be different (and 
-->     therefore at different topological locations) than another 
-->     one, so you have to have separate state to deal with each 
-->     VLAN.
--> 
--> >> Also, we do not include routers and hosts as part of a RBridge
--> >> campus.  Frames forwarded to routers and hosts MUST egress the
--> >> RBridge campus first.
--> 
-->     Right, how is this relevant?
--> 
--> Dino
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: dino at cisco.com (Dino Farinacci)
Date: Sun, 26 Mar 2006 14:44:33 -0800

>> o	There has never been any intention not to do this.

    And I'm telling you that it should when looking at a network the size
    of 100 switches.

>> 	VLANs are associated with what RBridge interfaces.

    I don't see how it is related. Wanted to do optmized forwarding doesn't
    require more configuration.

>> 	innappropriate VLAN interface? 

    You confused me. I don't see how your bullets follow to your question.

>> RBridge campus as a whole.

    Whatever.

>> 	on which a router (or host) resides.

    Right.

Dino