Subject: [magma] Seeking clarification of "unregistered packet"

From: La Monte Yarroll <[email-masked]>
Date: Tue, 19 May 2009 14:50:06 -0400

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")?

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"?

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.

---

From: "V, Magesh (Magesh)" <[email-masked]>
Date: Wed, 20 May 2009 08:40:08 +0530

I think the recommendation holds good for even V3 switches. That is, if its a fully v3 aware switch then (S1,G) traffic should still be considered as unregistered data. 

On the other hand, if we assume that the presence of (S2,G) join has forced the switch to no more consider (S1,G) data as unregistered then it will start forwarding traffic to the v3 receiver (who sent S2,G join). If such a thing happens then your v3 purpose is defeated.

Thanks,
Magesh.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of La Monte Yarroll
Sent: Wednesday, May 20, 2009 12:20 AM
To: [email-masked]
Cc: Manish Vora; Todd Derr
Subject: [magma] Seeking clarification of "unregistered packet"

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

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 20 May 2009 08:55:12 +0530

Hi,

     Please see my response in line.

Thanks,
Bharat

> v1 and v2 packets (or v3 packets ignoring "include source" and "exclude

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

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

> I might have on "specified ports" that I may need to flood unregistered

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.

Do you see any specific issues in doing this?
**************** 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***

---

From: La Monte Yarroll <[email-masked]>
Date: Wed, 20 May 2009 10:07:04 -0400

On Wed, 2009-05-20 at 08:55 +0530, Bharat Joshi wrote:
> La Monte H.P. Yarroll wrote:
> 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 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.

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

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

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

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 21 May 2009 08:54:32 +0530

Hi,

Thanks,
Bharat

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

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

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