[rbridge] When would an RBridge say "I don't want layer 2 multicast"?

[Dinesh G Dutt]

I checked and we don't need this bit. It was something that was put in 
for use in a network where MMRP was widely deployed, kind of thing. But 
as you pointed out, we can prune multicast effectively using the normal 
multicast pruning and don't need this bit.

Dinesh
Joe Touch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Dinesh G Dutt wrote:
>   
>> Joe,
>>
>> I see your point. I don't know the basis for this requirement. If an
>> operator wanted to turn off all non-IP multicast, wouldn't turning on
>> this bit be a good idea ? I guess your question is in what situations
>> can an operator make this decision. 
>>     
>
> Exactly.
>
>   
>> Furthermore, I don't believe
>> existing 802.1Q bridges provide such a funtionality. So, maybe getting
>> rid of this bit is a good idea as you suggest.
>>
>> Let me check with Dino and see if he remembers the need for this bit,
>>     
>
> Thanks. That'd be useful.
>
> Joe
>
>   
>> Dinesh
>> Joe Touch wrote:
>>
>>
>> Dinesh G Dutt wrote:
>>  
>>     
>>>>> There is a L2 protocol called MMRP (used to be called GMRP) that allows
>>>>> me to do the equivalent of IGMP but for L2-only multicast (actually it
>>>>> can also be used for IP multicast). So, it should be possible for an
>>>>> Rbridge to say "don't send me any L2 multicast that isn't derived from
>>>>> IP multicast".
>>>>>     
>>>>>           
>> I don't see why these two statements are related. If MMRP can also be
>> used for IP multicast or not, then how would an operator ever know when
>> to set this bit to "off"?
>>
>> I'm suggesting that if we can't give clear advice to an operator on when
>> to set each value of a bit, we should not include it.
>>
>> Joe
>>
>>  
>>     
>>>>> James Carlson wrote:
>>>>>  
>>>>>    
>>>>>           
>>>>>>>> Joe Touch writes:
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> Donald Eastlake wrote:
>>>>>>>>>                 
>>>>>>>>>                   
>>>>>>>>>> This was put
>>>>>>>>>> through a consensus call on the working group mailing list
>>>>>>>>>> resulting
>>>>>>>>>> in the formal consensus determination here:
>>>>>>>>>> http://www.postel.org/pipermail/rbridge/2007-September/002470.html.
>>>>>>>>>>                       
>>>>>>>>>>                     
>>>>>>>>> Besides your mail, there was only one post from James Carlson
>>>>>>>>> endorsing
>>>>>>>>> the idea:
>>>>>>>>> http://www.postel.org/pipermail/rbridge/2007-July/002400.html
>>>>>>>>>                   
>>>>>>>>>                   
>>>>>>>> Just to make clear (which itself might be impossible at this point):
>>>>>>>> the reason I supported it was for symmetry with the other multicast-
>>>>>>>> optimizing bits already defined.  If the implementation has some
>>>>>>>> reason to know that it has useful local information about non-IP
>>>>>>>> multicasts in use (e.g., the subnet in question runs only IP or
>>>>>>>> perhaps is known to use GMRP for all multicast addresses), then it
>>>>>>>> can
>>>>>>>> set or reset the flag as needed.  If it doesn't (or can't) know about
>>>>>>>> non-IP multicast usage, then it should set it to 1 with the rest of
>>>>>>>> those who aren't snooping the multicast control protocols.
>>>>>>>>
>>>>>>>> I somewhat doubt it's going to see much use, but it's also fairly
>>>>>>>> cheap -- as long as we already have to support IPv4 and IPv6 control
>>>>>>>> bits.  (And since, if you're lazy, you can just ignore it and let the
>>>>>>>> downstream discard the unwanted packets.)
>>>>>>>>               
>>>>>>>>                 
>>>>> I'm seeing a "something operators can set as desired", but not a reason
>>>>> they would ever want to set it. I particularly dislike the idea of
>>>>> filtering multicasts based on upper layer info (i.e., whether it's IP or
>>>>> not). IGMP is an optimization, but it seems like this bit could break
>>>>> things when its use wasn't needed - and I still don't see a clear need.
>>>>>
>>>>> Joe
>>>>>     
>>>>>           
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>  
>>     
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkoxFr8ACgkQE5f5cImnZrutDwCbBuwVDzPZgxdE/AB0ZcS+m0SQ
> ALgAn39Af0EuNqlfya38OGbfuJowMqGE
> =s9As
> -----END PGP SIGNATURE-----
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan