Re: Seeking clarification of "unregistered packet"

Thanks, if that is the case I don't see any benefit to treating "unregistered" traffic specially.  I am inclined to treat it the same as any other multicast traffic - i.e. send it to all ports requesting it (obviously, this is an empty set in the unregistered case) plus router ports.  This is technically not compliant with the RFC but I think it is better than the alternative of flooding it to all ports which has the somewhat counter-intuitive behaviour of sending traffic that no one is interested in to all ports.
 
I believe the only way to handle the v3-host/non-v3-switch case (assuming the switch doesn't even do "partial" v3 as suggested) is to provide an option to flood all traffic to flood all traffic to specified ports.  As you say, that is certainly overkill - but if the switch does not process the reports at all it is impossible to do anything better.
 
thanks,
 
todd.
 
________________________________

From: [email protected] on behalf of Bharat Joshi
Sent: Wed 5/20/2009 11:59 PM
To: Todd Derr; [email protected]
Cc: La Monte Yarroll; Manish Vora
Subject: Re: [magma] 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***
_______________________________________________
magma mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/magma

_______________________________________________
magma mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/magma