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

[Dinesh G Dutt]

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. 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,

Dinesh
Joe Touch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> 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
>
> iEUEARECAAYFAkowLnYACgkQE5f5cImnZru4jACXRpWDmbsqx36tYQ71mAgNAPQF
> mQCfWccsjsmdv6jylLSIteO+s3M0Hto=
> =VPUF
> -----END PGP SIGNATURE-----
>
>   

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