Subject: [rbridge] Must/Should flooding optimization

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 27 Mar 2006 11:45:43 -0500

Dino,

	I'm not sure that there are any remaining points of dis-
agreement below, but please see in-line comments/questions... 

--> >> 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.
--> 
-->     And I'm telling you that it should when looking at a 
-->     network the size of 100 switches.

Possibly this is my bad for using "... never ... not ..."

I assume we would be in agreement if I rephrased this 

    "o   The implied intention has always been to do this."

I make this assertion because this is how Radia has presented 
this in earlier discussions on this topic (specifically in a
"How many trees" presentation given at IETF-63).

--> 
--> >> 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.
--> 
-->     I don't see how it is related. Wanted to do [optimized] 
-->     forwarding doesn't require more configuration.

If RBridges are only REQUIRED to be VLAN aware at RBridge egress
interfaces, VLAN configuration is only REQUIRED at those interfaces.

Each RBridge advertises, via the RBridge Routing Protocol, the VLANs
to which it is connected.

Therefore only requiring VLAN awareness at RBridge egress interfaces
is highly consistent with the TRILL minimal-configuration goal - and
has no impact on the ability of RBridges to provide VLAN pruning.

--> 
--> >> 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? 
--> 
-->     You confused me. I don't see how your bullets follow to 
--> your question.

Given that it seems that you reversed the sense of the second
bullet above (the one with the offensive double-negative), it
may be that the flow to the question is clearer now.  However,
I will re-state as follows:

Background:
o  VLAN-based pruning/filtering MUST occur on RBridge egress.
o  VLAN-based pruning/filtering at RBridges that do not support
   directly VLAN-connected interfaces may require some non-zero 
   amount of "extra" configuration.

Additional factor:
o  Minimal configuration may be a more important consideration  
   in some deployment scenarios than VLAN pruning/filtering at
   interfaces that are not RBridge egresses

Questions:
1) Given that VLAN filtering MUST occur at least at all RBridge 
   egress interfaces, how can VLAN-scoped Multicast be delivered
   on a VLAN-specific interface that does not support that VLAN?

	(my answer: VLAN-scoped Multicast will not be delivered on
	 VLAN-specific interfaces that do not support that VLAN)

2) Assuming that you agree with my answer, then what justification 
   is there for saying VLAN filtering MUST occur on all RBridge 
   interfaces in order to prevent this form of mis-delivery?

	(my answer: this requirement is not justified)

A) Alternatively, are you arguing that VLAN filtering MUST occur
   on all RBridge interfaces in order to prevent mis-delivering
   VLAN-scoped multicast, or did I misunderstand your comments?

--> 
--> >> 	These are clearly isomorphic representations of a common
--> >> sub-setting operation.  This same observation applies to an 
--> >> RBridge campus as a whole.
--> 
-->     Whatever.
--> 
--> >> ->	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.
--> 
-->     Right.

I assume that these two responses mean either that you agree,
or that you don't care...

--> 
--> Dino
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: dino at cisco.com (Dino Farinacci)
Date: Mon, 27 Mar 2006 09:26:56 -0800

>>    VLAN-scoped multicast, or did I misunderstand your comments?

    First off, I never brought up VLAN pruning, you did. I was focusing the
    discussion on multicast forwarding. So if there is in IGMP report received
    for a group on an egress rBridge interface, forwarding to that group does 
    not happen on that interface, period.

    So associating "VLAN pruning" with "multicast pruning" brings no value to
    the discussion IMO. 

    If an IGMP report for group G is received on an interface and the interface
    is in VLAN x, then there is a receiver for the group in VLAN x. Therefore,
    the MAC forwarding table for VLAN x has a MAC group entry to forward out
    this interface. And this would be the case for all switches where the
    "forwarding tree" is rooted by the switch directly connected to the 
    source(s).

Dino