Multicast & Anycast Group Membership (magma)

rfc-editor | 4 Apr 2009 01:47

RFC 5519 on Multicast Group Membership Discovery MIB


A new Request for Comments is now available in online RFC libraries.

        
        RFC 5519

        Title:      Multicast Group Membership Discovery MIB 
        Author:     J. Chesterfield, B. Haberman, Ed.
        Status:     Standards Track
        Date:       April 2009
        Mailbox:    julian.chesterfield <at> cl.cam.ac.uk, 
                    brian <at> innovationslab.net
        Pages:      41
        Characters: 76260
        Obsoletes:  RFC2933, RFC3019

        I-D Tag:    draft-ietf-magma-mgmd-mib-15.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5519.txt

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects used for managing the Internet
Group Management Protocol (IGMP) and the Multicast Listener Discovery
(MLD) protocol.  [STANDARDS TRACK]

This document is a product of the Multicast & Anycast Group Membership Working Group of the IETF.

This is now a Proposed Standard Protocol.

(Continue reading)

headers

V, Magesh (Magesh | 12 Apr 2009 18:31

IGMP Snooping proxy

Hi,

A v2 snooping switch that works in proxy-mode may aggregate and send the v2 igmp membership reports to upstream igmp router with source ip address 0.0.0.0. In such a case,

1. How can the upstream igmp router ensure that the membership report is coming from a host that is indeed in the same subnet that of the igmp interface?

2. Should the igmp router not discard the reports if the source-ip of such packets are not in its local network?

3. If such packets (as in 2) will indeed be dropped then is it not required of the snooping switch (proxy mode) to send at least one report for each LAN w/ valid source-ip address for that network?

Would appreciate if someone can educate me on this.

Thanks a lot,

Magesh.

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www.ietf.org/mailman/listinfo/magma

headers

Bharat Joshi | 13 Apr 2009 05:26

Re: IGMP Snooping proxy


Hi Magesh,

    Please see my response in line.

Thanks,
Bharat

>A v2 snooping switch that works in proxy-mode may aggregate and send the v2 igmp membership reports to
upstream igmp 
>router with source ip address 0.0.0.0. In such a case, 
>
>1. How can the upstream igmp router ensure that the membership report is coming from a host that is indeed in
the same 
>subnet that of the igmp interface?

It can not. Router needs to be told that there is a snooping switch which does aggregation as well.

>2. Should the igmp router not discard the reports if the source-ip of such packets are not in its local network?

No. It should not. A router needs to be configured appropriately to not discard such messages. IIRC, Proxy
RFC mention this somewhere.

>3. If such packets (as in 2) will indeed be dropped then is it not required of the snooping switch (proxy
mode) to 
>send at least one report for each LAN w/ valid source-ip address for that network?

As I mentioned above, router must be configured not to drop these packets. 

For your question, if snooping switch forwards at least one report upstream for each valid source ip, part
of aggregation is broken. Another question is how does this switch will know what all are the valid source addresses?

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

headers

V, Magesh (Magesh | 13 Apr 2009 07:24

Re: IGMP Snooping proxy

Hello Bharat,

Thanks for the answers.

· Can you please elaborate as to what the igmp router can be configured with; is it to explicitly specify to process reports with src-ip 0.0.0.0?

· I referred in 2236 (mine is a v2 router) where, I couldn’t find a reference for this?

· Lastly, regarding valid source-ip; I agree that a part of aggregation will be defeated but the switch may send just ONE report per mc group per vlan in addition to the aggregated report. The switch can use the source-ip of the report which it last heard to refresh its group membership expiry timer for than LAN.

· OR it must be made possible in the proxy-snooping implementation to configure an ip-address per mrouter port which, can be used as the source-ip for the aggregates.

Thanks,

Magesh.

-----Original Message-----
From: Bharat Joshi [mailto:bharat_joshi <at> infosys.com]
Sent: Monday, April 13, 2009 8:57 AM
To: V, Magesh (Magesh)
Cc: magma <at> ietf.org
Subject: RE: IGMP Snooping proxy

Hi Magesh,

Please see my response in line.

Thanks,

Bharat

>A v2 snooping switch that works in proxy-mode may aggregate and send the v2 igmp membership reports to upstream igmp

>router with source ip address 0.0.0.0. In such a case,

>1. How can the upstream igmp router ensure that the membership report is coming from a host that is indeed in the same

>subnet that of the igmp interface?

It can not. Router needs to be told that there is a snooping switch which does aggregation as well.

>2. Should the igmp router not discard the reports if the source-ip of such packets are not in its local network?

No. It should not. A router needs to be configured appropriately to not discard such messages. IIRC, Proxy RFC mention this somewhere.

>3. If such packets (as in 2) will indeed be dropped then is it not required of the snooping switch (proxy mode) to

>send at least one report for each LAN w/ valid source-ip address for that network?

As I mentioned above, router must be configured not to drop these packets.

For your question, if snooping switch forwards at least one report upstream for each valid source ip, part of aggregation is broken. Another question is how does this switch will know what all are the valid source addresses?

**************** 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
magma <at> ietf.org
https://www.ietf.org/mailman/listinfo/magma

headers

Bharat Joshi | 13 Apr 2009 07:38

Re: IGMP Snooping proxy

Hi Magesh,

      Please see my response in line.

Thanks,
Bharat

> 
> ·        Can you please elaborate as to what the igmp router can be configured with; is it to explicitly specify to
process reports with src-ip 0.0.0.0?
> 
> ·        I referred in 2236 (mine is a v2 router) where, I couldn’t find a reference for this?

Please look at point 2 of section 2.1.1 of RFC 4541. It mention this. Just read through this RFC,
consideration of source address as 0.0.0.0 is mentioned at couple of places.

> ·        Lastly, regarding valid source-ip; I agree that a part of aggregation will be defeated but the switch
may send just ONE report per mc group per vlan in addition to the aggregated report. The switch can use the
source-ip of the report which it last heard to refresh its group membership expiry timer for than LAN.

Yes. Switch can surely do that and with this you do not need to send multiple join/leave requests upstream.

> ·        OR it must be made possible in the proxy-snooping implementation to configure an ip-address per
mrouter port which, can be used as the source-ip for the aggregates.

You can do this as well. It is similar to the above one but more granular.
**************** 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***

headers

V, Magesh (Magesh | 13 Apr 2009 08:51

Re: IGMP Snooping proxy

Hi Bharat,
4541 talks about a switch receiving/sending reports with src-ip 0.0.0.0. My question was w.r.t the
upstream igmp router that receives this report. Hence, I was referring 2236. However, I got a reference in
3376 (IgmpV3 - section 4.2.13) that mandates to accept reports w/ source-ip 0.0.0.0

However, my igmp router is v2.

Thanks,
Magesh.

-----Original Message-----
From: Bharat Joshi [mailto:bharat_joshi <at> infosys.com] 
Sent: Monday, April 13, 2009 11:09 AM
To: V, Magesh (Magesh)
Cc: magma <at> ietf.org
Subject: RE: IGMP Snooping proxy

Hi Magesh,

      Please see my response in line.

Thanks,
Bharat

> 
> *        Can you please elaborate as to what the igmp router can be configured with; is it to explicitly specify to
process reports with src-ip 0.0.0.0?
> 
> *        I referred in 2236 (mine is a v2 router) where, I couldn't find a reference for this?

Please look at point 2 of section 2.1.1 of RFC 4541. It mention this. Just read through this RFC,
consideration of source address as 0.0.0.0 is mentioned at couple of places.

> *        Lastly, regarding valid source-ip; I agree that a part of aggregation will be defeated but the switch may
send just ONE report per mc group per vlan in addition to the aggregated report. The switch can use the
source-ip of the report which it last heard to refresh its group membership expiry timer for than LAN.

Yes. Switch can surely do that and with this you do not need to send multiple join/leave requests upstream.

> *        OR it must be made possible in the proxy-snooping implementation to configure an ip-address per mrouter
port which, can be used as the source-ip for the aggregates.

You can do this as well. It is similar to the above one but more granular.
**************** 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***

headers

Bharat Joshi | 13 Apr 2009 09:14

Re: IGMP Snooping proxy

Hi Magesh,

     You are right. I was thinking that I have read this somewhere.

     From RFC 4541, it is clear that a switch can generate a join message with 0.0.0.0 source address. Now if your
router is IGMPv2 and follow RFC to the word, it will discard this packet. But if your router can
interoperate with switches that supports RFC 4541, it must not discard this packet.

     Alternatively, you can check if switch provides some mean to configure an IP address that can be used as
source address for these messages but then the same IP address can not be used in the general queries
generated on downstream ports.

Thanks,
Bharat

________________________________________
From: V, Magesh (Magesh) [mageshv <at> alcatel-lucent.com]
Sent: Monday, April 13, 2009 12:21 PM
To: Bharat Joshi
Cc: magma <at> ietf.org
Subject: RE: IGMP Snooping proxy

Hi Bharat,
4541 talks about a switch receiving/sending reports with src-ip 0.0.0.0. My question was w.r.t the
upstream igmp router that receives this report. Hence, I was referring 2236. However, I got a reference in
3376 (IgmpV3 - section 4.2.13) that mandates to accept reports w/ source-ip 0.0.0.0

However, my igmp router is v2.

Thanks,
Magesh.

-----Original Message-----
From: Bharat Joshi [mailto:bharat_joshi <at> infosys.com]
Sent: Monday, April 13, 2009 11:09 AM
To: V, Magesh (Magesh)
Cc: magma <at> ietf.org
Subject: RE: IGMP Snooping proxy

Hi Magesh,

      Please see my response in line.

Thanks,
Bharat

>
> *        Can you please elaborate as to what the igmp router can be configured with; is it to explicitly specify to
process reports with src-ip 0.0.0.0?
>
> *        I referred in 2236 (mine is a v2 router) where, I couldn't find a reference for this?

Please look at point 2 of section 2.1.1 of RFC 4541. It mention this. Just read through this RFC,
consideration of source address as 0.0.0.0 is mentioned at couple of places.

> *        Lastly, regarding valid source-ip; I agree that a part of aggregation will be defeated but the switch may
send just ONE report per mc group per vlan in addition to the aggregated report. The switch can use the
source-ip of the report which it last heard to refresh its group membership expiry timer for than LAN.

Yes. Switch can surely do that and with this you do not need to send multiple join/leave requests upstream.

> *        OR it must be made possible in the proxy-snooping implementation to configure an ip-address per mrouter
port which, can be used as the source-ip for the aggregates.

You can do this as well. It is similar to the above one but more granular.
**************** 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***

2	March 2012
11	February 2012
8	January 2012
29	October 2011
2	May 2011
2	April 2011
7	March 2011
4	February 2011
9	November 2010
5	October 2010
13	September 2010
1	August 2010
6	July 2010
17	June 2010
5	March 2010
3	February 2010
6	January 2010
6	December 2009
14	November 2009
1	September 2009
8	August 2009
11	July 2009
5	June 2009
10	May 2009
7	April 2009
7	March 2009
15	February 2009
2	January 2009
14	December 2008
1	November 2008
7	October 2008
6	September 2008
5	July 2008
6	June 2008
8	May 2008
2	April 2008
25	March 2008
1	January 2008
1	December 2007
2	November 2007
1	October 2007
24	September 2007
10	August 2007
10	July 2007
51	June 2007
4	May 2007
7	April 2007
8	March 2007
18	February 2007
9	January 2007
18	December 2006
13	November 2006
9	October 2006
2	September 2006
9	August 2006
8	July 2006
52	June 2006
9	May 2006
8	March 2006
9	January 2006
13	December 2005
2	November 2005
12	October 2005
7	September 2005
5	August 2005
11	July 2005
13	June 2005
30	May 2005
5	April 2005
15	March 2005
16	February 2005
10	January 2005
21	December 2004
31	November 2004
25	October 2004
14	September 2004
7	August 2004
19	July 2004
2	June 2004
12	May 2004
16	April 2004
38	March 2004
18	February 2004
10	January 2004
7	December 2003
11	November 2003
17	October 2003
21	September 2003
11	August 2003
23	July 2003
29	June 2003
13	May 2003
13	April 2003
50	March 2003
74	February 2003
52	January 2003
3	December 2002
19	November 2002
27	October 2002
8	September 2002
5	August 2002
16	July 2002
20	June 2002
14	May 2002
9	April 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30