Re: Seeking clarification of "unregistered packet"

Hi Todd,

     Please see my response in line.

Thanks,
Bharat

On Thu, 2009-05-21 at 08:57 +0530, Bharat joshi wrote:
Can someone comment on exactly what the purpose of flooding unregistered
> packets is?
>

Let me put forward my understanding. Please correct me if I am wrong.
 
> I think most of my confusion comes from the third paragraph of 2.1.2
> (3), where it discusses v3 hosts and switches that do not process v3
> REPORTs.  That gives me the impression that flooding unregistered
> packets was meant to solve that issue and ensure the v3 hosts receive
> traffic.  However, in the last paragraph of that section it is conceded
> that when both v2 and v3 hosts are present, this does not work because
> v2 joins cause the v3 hosts to stop receiving traffic.  If there are
> only v3 hosts present, the point is moot - if the switch doesn't
> understand the v3 REPORTs there is no "snooping" happening at all, and
> it has to flood all multicast to all ports.  So, if v3 hosts are to
> function in such an environment, it appears we need to flood ALL traffic
> to ports with v3 hosts attached rather than just unregistered traffic.

I completely agree with your reasoning. But flooding all traffic to v3 hosts will surely be an overkill. I think in such a case, a service provider should upgrade the switch.

> Is there another purpose for flooding unregistered traffic in a "normal"
> network?  I was considering a bootstrapping scenario - i.e. when the
> switch comes up, we don't know what groups the hosts had previously
> joined, so flooding unregistered traffic allows hosts to start receiving
> sooner.  However, this seems to be of marginal benefit because as soon
> as we receive a join for a group on any port, the other ports will be
> "cut off".  Using some sort of restart timer (where we flood all traffic
> to all ports for some amount of time after boot) seems like a better
> solution to that problem.

I do not think there is any other purpose to forward unregistered packet except to try to support some IGMPv3 hosts attached to a non-IGMPv3 switch. But this looks to be a half hearted attempt and things won't work as discussed in the RFC.

As recommended in paragraph 4, I think things will work properly if at least a cut-down version of IGMPv3 is supported in a switch.
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***