Subject: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 8 May 2006 15:28:13 -0400

Dino,

	I agree that - for a specific subset of RBridge deployment
scenarios (possibly most significant deployment scenarios, maybe
all important ones) - it is more than just desirable that all of
the RBridges implement both VLAN and Multicast optimizations.

	I am not trying to say anything contrary to this.  Nor am
I trying to argue that other deployment scenarios are somehow of
greater number or importance.

	What I am saying is that there is a difference between what
might make sense in a variety of different RBridge implementations, 
and what we have to specify in order to define interoperable RBridge 
implementations.

	The difference is that an RBridge - as a functional abstract
concept - does not need to implement these optimizations in order
to function interoperably with other RBridges.  This remains true
even if some RBridges fully implement these optimizations and some
implement only the message forwarding and information exchanges to
make that possible (without implementing the optimizations).

	Argument that a device that does not implement optimizations 
will be effectively disfunctional in a deployment scenario that 
requires full support for these optimizations is both correct and 
obvious.  We envision a scenario in which XYZ is required and then 
say that not having XYZ in that scenario is a problem.  That is very 
clearly going to be the case, because this represents a tautology.

	However, the fact that implementations need to have a feature
(a set of optimization in this case) in order to satisfy requirements
of a particular deployment has nothing to do with whether or not the
term "MAY", "SHOULD" or "MUST" applies in a protocol specification.
What determines which of these words applies is 1) the way they are
defined in RFC 2119 and 2) the degree to which interoperability is 
dependent on implementing that feature.

	We cannot, and should not, stretch the meaning of the terms
defined in RFC 2119 for the sake of convenience.  If something is
required for interoperability in implementing a specification, it is 
a MUST.  If something is expected in an interoperable implementation 
of a specification, but might not be required in every case, it is a 
SHOULD.  If something is allowed, but neither expected, nor required,
it is a MAY.

	As a result of all of the things we've discussed over the past
several months, it is clear that - with very little stretching - we
can make the word SHOULD apply to VLAN and Multicast optimization.
With similar stretching, we could make the word MAY apply as well.

	But - particularly since it has been abundantly demonstrated 
that it is not necessary for every implementation to implement every 
one of these optimizations in order to achieve interoperability - it 
is not possible to stretch this to the point that MUST would apply 
to the implementation of the optimizations.  The implementation of 
message forwarding and information exchanges is required to support 
the optimizations and is therefore a MUST.

--
Eric 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Dino Farinacci
--> Sent: Thursday, May 04, 2006 8:11 PM
--> To: riw at cisco.com
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Should layer 2 or layer 3 IP 
--> Multicast addresses be advertised?
--> 
--> >> I don't know if I understand this, actually.... Today, 
--> what happens is
--> >> we get layer 2 multicast, and forward it everywhere. We use IGMP
--> >> snooping to optimized that flooding, on the assumption 
--> that anything
--> >> being sent to a layer 2 multicast address that maps to a layer 3
--> >> multicast address must be an IP originated multicast (as 
--> it should be,
--> >> based on the mapping rules), and thus, we can optimize 
--> these multicasts
--> >> based on the layer 3 information.
--> 
-->     The optimization is not based on a L3 multicast address 
--> mapping to a L2
-->     multicast address but the fact there is receiver 
--> membership signalling.
-->  
-->     If L2 apps implemented GMRP/GARP, we could optimize for 
--> non-IP multicast
-->     as well.
--> 
--> >> So, in light of this, shouldn't an rbridge just act the 
--> same way? In the
--> >> absence of other information, we should flood multicast 
--> through the
--> >> vlan. IGMP snooping and "other mechanisms" MAY be used 
--> to optimize the
--> >> tree, but we can't count on these. They are good 
--> optimizations, and we
--> 
-->     SHOULD or even MUST.
--> 
-->     I wish some enterprise multicast deployers on this list 
--> would speak up and
-->     indicate not doing this optimization is a non-starter. 
--> That is what
-->     they have told me anyways. 
--> 
--> >> - -- Put it on the agenda to talk about using other, 
--> rbridge specific,
--> >> mechanisms to find this sort of information. For 
--> instance, we could
--> >> postulate a mechanism where we do conflate l2 and l3 addresses in
--> >> rbridge advertisements, and build an l3 tree for 
--> multicast in parallel
--> >> with the l2 tree, restricting the l2 tree based on the l3 tree.
--> 
-->     If someone doesn't think this assumption is too 
--> restrictive and assumed
-->     that senders must also be receivers, then the rBridges 
--> directly connected
-->     to the hosts could do the signalling inside of the 
--> rBridge network.
-->    
-->     This way we don't have to do flooding for non-signaled 
--> protocols.
--> 
--> Dino
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->