Re: Seeking clarification of "unregistered packet"

Hi,

      Please see my response in line.

Thanks,
Bharat

> > La Monte H.P. Yarroll wrote:
> > > I have a couple questions about the following material from RFC 4541,
> > > 2.1.2:
> > > 
> > > > 3) An unregistered packet is defined as an IPv4 multicast packet with
> > > >    a destination address which does not match any of the groups
> > > >    announced in earlier IGMP Membership Reports.
> > > >
> > > >    If a switch receives an unregistered packet, it must forward that
> > > >    packet on all ports to which an IGMP router is attached.  A switch
> > > >    may default to forwarding unregistered packets on all ports.
> > > >    Switches that do not forward unregistered packets to all ports
> > > >    must include a configuration option to force the flooding of
> > > >    unregistered packets on specified ports.
> > > 
> > > Is the ability to "force the flooding of unregistered packets on
> > > specified ports" only important on switches which are only processing
> > > v1 and v2 packets (or v3 packets ignoring "include source" and "exclude
> > > source")?
> > 
> > No. I think it is required even for V3 capable switch. Though I think
> >  while defining unregistered packet,  it would have been  better if RFC
> >  should have used 'destination address or a combination of source and
> >  destination address which does not....' instead of just 'destination
> >  address which does not..'.
> 
> Thanks, this is the revised definition of "unregistered packet" which I
> was expecting.
> 
> > > If it is relevant for a switch which processes fully general v3 Joins,
> > > the definition of "unregistered packet" seems a little ambiguous.
> > > 
> > > Consider traffic from source S1 to group G which no Joins seen. This
> > > traffic (S1,G) is unregistered packets. If we then see a Join for
> > > (S2,G), we have now seen the group G mentioned in a Join. How am I
> > > supposed to treat the (S1,G) traffic? Is it still unregistered packets?
> > > Or am I supposed to stop forwarding that traffic to "specified ports"?
> > 
> > If this switch understand IGMPv3 and there is no IGMP join for this
> >  group [none of the versions], as per the rule, it looks like that
> >  (S1,G) should still be treated as unregistered packets.
> 
> Good. That's what I thought, but it's not exactly what the RFC says.

Yes. I agree. If you think it is something which should be clarified, please submit a RFC-Errata to rfc-editor.

> > > My problem may be that I simply do not understand what kinds of devices
> > > I might have on "specified ports" that I may need to flood unregistered
> > > packets to them.
> > 
> > If you would have noticed, the second paragraph says that the
> >  unregistered packet needs to be forwarded to the ports where an IGMP
> >  router is available. Alternatively it can be forwarded to all ports
> >  except from which it came in as well.
> 
> 2.1.2 1) tells us:
> 
> > 1) Packets with a destination IP address outside 224.0.0.X which are
> >       not IGMP should be forwarded according to group-based port
> >       membership tables and must also be forwarded on router ports.
> 
> So we are already told to forward all multicast traffic on router
> ports. We've been treating "specified ports" as something other than
> routers, perhaps other snooping switches?

I think your confusion might be from the words 'specified ports' used in that paragraph. I think what 'specified ports' mean here in that context is the 'list of ports on which flooding of unregistered packets are enabled'. There is neither anything 'specific' nor importance for these ports.

So now it depends upon the device you have. If it really has a configurable option to turn on the 'flooding of unregistered packets' per port basis then 'specified ports' will be all those ports in which this option is enabled.

If your device does not have an option, it can simply flood it to all the ports or flood it only to router ports.

All the above functioning will be compliant with this RFC.
 
> The difference between "specified ports" and "router ports" is that we
> stop forwarding multicast traffic to "specified ports" as soon as we
> have identified a valid receiver for that traffic, but "router ports"
> always get all multicast traffic. I should clarify that we're
> implementing "must include a configuration option to force the flooding
> of unregistered packets on specified ports" and not "may default to
> forwarding unregistered packets on all ports".

Now what will you do if it is a router port and someone configures this option as disabled for that port? Will you forward unregistered packet traffic or you won't. One way or the other you will be breaking the rule.

> > Do you see any specific issues in doing this?
> 
> With your revised definition of "unregistered packet" it makes a lot
> more sense, but I'm still trying to understand why the handling of
> "specified ports" should differ from "router ports".

Please look at the definition of 'specified ports' I mentioned above. It is the rewording of what is mentioned in the RFC. Now with that definition, as a service provider I may want to disable flooding of unregistered packets to some specific ports which I am sure does not lead to a router. With this configuration option, I can achieve that..

**************** 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***