Closing of the MAGMA mailing list

All,
      The IESG has recently re-chartered the PIM working group.  In 
doing so, they have added responsibility for handling work related to 
IGMP and MLD.  To avoid any confusion, I have suggested that the magma 
mailing list be closed and all discussion of IGMP/MLD issues carried out 
on the PIM mailing list.  My plan is to close this mailing list in the 
next week or so.

      Information on subscribing to the PIM mailing list is available at 
https://www.ietf.org/mailman/listinfo/pim.

Regards,
Brian

Regarding IGMPProxy stream receiving time gap after join

Regarding IGMPProxy :---

                                           Upstream
            Downstream
H1 -------------------------------------  eth0 IGMPProxy eth2
-------------------------------------- H2
multicastsend
                                                    multicastrecv

UDP -->
                                                      <---- JOIN

With the above setup.

Started pumping UDP stream  from H1 to group 239.0.0.0/5000.

After sending the IGMP JOIN on H2 side (to Grp 239.0.0.0), UDP stream
started receiving properly to the port 5000.

But it is observed that, udp stream is not recieved immediately to H2,
it is taking 2 to 3 seconds some times, it is taking 4 to 6 seconds
also.

I hope that IGMPProxy implementation will add the Route in MFC,
whenver it receives CACHE_MISS event and matches the JOIN database.

In IGMP General queries sent, "Max Response Time" field is set to 1 second.

Any better approach to avoid  delayed stream

Fw: [multimob] draft-ietf-multimob-igmp-mld-tuning-03

Hello folks,

Multimob WG started WGLC for the following draft discussing IGMP/MLD
timer or value tuning for wireless network or mobile communication.

We'd appreciate hearing your comments on "multimob ML", not magma ML.
(Just teling "support" on multimob ML is also fine. :)

Regards,
--
Hitoshi Asaeda

From: Behcet Sarikaya <sarikaya2012 <at> gmail.com>
Subject: [multimob] draft-ietf-multimob-igmp-mld-tuning-03
Date: 2012-02-13 12:27:14 GMT

Folks,
     This message starts a one week Multimob Working Group last call
on advancing:

     Title     :Tuning the Behavior of IGMP and MLD for Routers in
Mobile and Wireless Networks
     Author(s) :H. Asaeda
                 H. Liu

Learning dynamic mrouter when both IGMP and snooping are enabled

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

Sending query on a new member of VE

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

Forwarding of query to mrouter ports of other vlans.

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

Querier transition based on Group Specific Query?

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

Destination address in v2 leave message

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

Cross-Vlan IGMP query-forwarding.

Hello, all,

IGMP is not responsible for routing across VLANs. It is actually designed to keep things local to its own
VLAN-- to reduce flooding, rather than create it.

Indranil's diagram is shown below:

>                           VLANA(10.x.x.x)         VLANB(20.x.x.x)
>
> RTR--------------------------sw-------------------------HOST.

If you want to route IGMP Queries from one VLAN to IGMP hosts on another, then you use a multicast routing
protocol such as PIM.

IGMP alone is not expected to perform this function.

Thank you and best regards,
  Karen Kimball

Message: 1
Date: Wed, 12 Oct 2011 19:54:26 +0530
From: Indranil Bhattacharya <myselfindranil <at> gmail.com>
To: "Beeram, Suresh KumarReddy" <sbeeram <at> hp.com>
Cc: "magma <at> ietf.org" <magma <at> ietf.org>
Subject: Re: [magma] Question about IGMP host implementation
Message-ID:
	<CAAaur94fK2C+HnnbnOjdrOTfDatJ9g1gATxvkzQ-LcdrW7ogVw <at> mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Suresh,
                           VLANA(10.x.x.x)         VLANB(20.x.x.x)

RTR-------------------------------sw------------------------------HOST.

All the queries received on VLANA will be forwared to VLANB. When mcast data
is received on vlanA those will also be forwarded on vlanB after some header
rewrite. Please let me know if this answers your question.
Thanks,
Indranil
On Wed, Oct 12, 2011 at 4:16 PM, Beeram, Suresh KumarReddy
<sbeeram <at> hp.com>wrote:

>  Hi Indranil,****
>
> Why the Query coming from VLAN-A has to be forwarded to VLAN-B?****
>
> In general switch should forward the Query packets to all the ports in same
> VLAN(VLAN-A). Hosts receiving the Query can reply to the query even the
> source address of the Query is in different subnet.****
>
> Is there anything I am missing in your reply???****
>
> Thanks****
>
> B S  Reddy****
>
> ** **
>
> *From:* magma-bounces <at> ietf.org [mailto:magma-bounces <at> ietf.org] *On Behalf
> Of *Indranil Bhattacharya
> *Sent:* Wednesday, October 12, 2011 2:06 PM
> *To:* Kunal Shah
> *Cc:* magma <at> ietf.org
> *Subject:* Re: [magma] Question about IGMP host implementation****
>
> ** **
>
> Hi Kunal,****
>
>  ****
>
>              Yes it should. The scenario that I have in mind is a switch
> whose mrouter interface is in vlanA and igmp joins are received on an
> interface in vlanB. In this case, query coming from vlanA(different subnet)
> has to be answered by hosts in vlanB.****
>
>  ****
>
> Thanks,****
>
> Indranil****
>
> On Wed, Oct 12, 2011 at 6:08 AM, Kunal Shah <kunal.shah <at> ericsson.com>
> wrote:****
>
> Hi all,****
>
>  ****
>
> Can an IGMPv2 host respond to a general query originated from a subnet
> other then its own?? RFC 2236 states: ****
>
>  ****
>
> ""query received" occurs when the host receives either a valid
>      General Membership Query message, or a valid Group-Specific
>      Membership Query message.  To be valid, the Query message must be
>      at least 8 octets long, and have a correct IGMP checksum.  The
>      group address in the IGMP header must either be zero (a General
>      Query) or a valid multicast group address (a Group-Specific Query)" *
> ***
>
>  ****
>
> There is no requirement for the source address to be on the same subnet as
> the host.****
>
>  ****
>
> Thanks,****
>
> Kunal****
>
>  ****
>
>
> _______________________________________________
> magma mailing list
> magma <at> ietf.org
> https://www.ietf.org/mailman/listinfo/magma****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/magma/attachments/20111012/33211bfd/attachment.htm>

------------------------------

Message: 2
Date: Wed, 12 Oct 2011 19:55:14 +0530
From: Indranil Bhattacharya <myselfindranil <at> gmail.com>
To: Bharat Joshi <bharat_joshi <at> infosys.com>
Cc: "magma <at> ietf.org" <magma <at> ietf.org>
Subject: Re: [magma] Question about IGMP host implementation
Message-ID:
	<CAAaur94VkhghN+VaL7ZUzyt_t9LDKG4JmqDG8fPPA5ba29dsbA <at> mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Bharat,

              I was thinking on the line of cat3k switches where we can
configure SVIs.

Thanks,
Indranil

On Wed, Oct 12, 2011 at 4:53 PM, Bharat Joshi <bharat_joshi <at> infosys.com>wrote:

> How is a switch has two different subnets on its two ports? Typically
> switch divides the broadcast domain. Right?
>
> Regards,
> Bharat
> ________________________________________
> From: magma-bounces <at> ietf.org [magma-bounces <at> ietf.org] On Behalf Of
> Indranil Bhattacharya [myselfindranil <at> gmail.com]
> Sent: Wednesday, October 12, 2011 2:05 PM
> To: Kunal Shah
> Cc: magma <at> ietf.org
> Subject: Re: [magma] Question about IGMP host implementation
>
> Hi Kunal,
>
>             Yes it should. The scenario that I have in mind is a switch
> whose mrouter interface is in vlanA and igmp joins are received on an
> interface in vlanB. In this case, query coming from vlanA(different subnet)
> has to be answered by hosts in vlanB.
>
> Thanks,
> Indranil
>
> On Wed, Oct 12, 2011 at 6:08 AM, Kunal Shah <kunal.shah <at> ericsson.com
> <mailto:kunal.shah <at> ericsson.com>> wrote:
> Hi all,
>
> Can an IGMPv2 host respond to a general query originated from a subnet
> other then its own?? RFC 2236 states:
>
> ""query received" occurs when the host receives either a valid
>     General Membership Query message, or a valid Group-Specific
>     Membership Query message.  To be valid, the Query message must be
>     at least 8 octets long, and have a correct IGMP checksum.  The
>     group address in the IGMP header must either be zero (a General
>     Query) or a valid multicast group address (a Group-Specific Query)"
>
> There is no requirement for the source address to be on the same subnet as
> the host.
>
> Thanks,
> Kunal
>
>
> _______________________________________________
> magma mailing list
> magma <at> ietf.org<mailto:magma <at> ietf.org>
> https://www.ietf.org/mailman/listinfo/magma
>
>
>
> **************** 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***
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/magma/attachments/20111012/29af8268/attachment.htm>

------------------------------

Message: 3
Date: Wed, 12 Oct 2011 11:47:59 -0400
From: Kunal Shah <kunal.shah <at> ericsson.com>
To: Bharat Joshi <bharat_joshi <at> infosys.com>, "magma <at> ietf.org"
	<magma <at> ietf.org>
Subject: Re: [magma] Question about IGMP host implementation
Message-ID:
	<4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A <at> EUSAACMS0703.eamcs.ericsson.se>
	
Content-Type: text/plain; charset="us-ascii"

Hi Bharat,

The security consideration addresses the processing of a report from a different subnet on the router. My
question pertains to the processing of a Query from a different subnet on the host.

Kunal 

-----Original Message-----
From: Bharat Joshi [mailto:bharat_joshi <at> infosys.com] 
Sent: Wednesday, October 12, 2011 4:20 AM
To: Kunal Shah; magma <at> ietf.org
Subject: RE: Question about IGMP host implementation

Hi Kunal,

        I think to keep the security tight, it is better to not respond to queries received from a source address
which does not fall on a subnet on that interface. Please note that this should be done only broadcast
interfaces. It may not work on point-to-point links.

        If you look at the security consideration in RFC 2236, it is mentioned that for reports, the above check
should be done.

Regards,
Bharat
________________________________________
From: magma-bounces <at> ietf.org [magma-bounces <at> ietf.org] On Behalf Of Kunal Shah [kunal.shah <at> ericsson.com]
Sent: Wednesday, October 12, 2011 6:08 AM
To: magma <at> ietf.org
Subject: [magma] Question about IGMP host implementation

Hi all,

Can an IGMPv2 host respond to a general query originated from a subnet other then its own?? RFC 2236 states:

""query received" occurs when the host receives either a valid
     General Membership Query message, or a valid Group-Specific
     Membership Query message.  To be valid, the Query message must be
     at least 8 octets long, and have a correct IGMP checksum.  The
     group address in the IGMP header must either be zero (a General
     Query) or a valid multicast group address (a Group-Specific Query)"

There is no requirement for the source address to be on the same subnet as the host.

Thanks,
Kunal

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

------------------------------

Message: 4
Date: Wed, 12 Oct 2011 21:20:11 +0530
From: Bharat Joshi <bharat_joshi <at> infosys.com>
To: Kunal Shah <kunal.shah <at> ericsson.com>, "magma <at> ietf.org"
	<magma <at> ietf.org>
Subject: Re: [magma] Question about IGMP host implementation
Message-ID:
	<31D55C4D55BEED48A4459EB64567589A1186EB24EB <at> BLRKECMBX02.ad.infosys.com>
	
Content-Type: text/plain; charset="us-ascii"

Kunal,

        What I am suggesting is that though RFC does not explicitly suggest it, it might be better to do this for
broadcast interfaces.

        But yes, RFC does not suggest anything on this so a host can process a query message with a source address from
any other subnet as well.

Regards,
Bharat
________________________________________
From: Kunal Shah [kunal.shah <at> ericsson.com]
Sent: Wednesday, October 12, 2011 9:17 PM
To: Bharat Joshi; magma <at> ietf.org
Subject: RE: Question about IGMP host implementation

Hi Bharat,

The security consideration addresses the processing of a report from a different subnet on the router. My
question pertains to the processing of a Query from a different subnet on the host.

Kunal

-----Original Message-----
From: Bharat Joshi [mailto:bharat_joshi <at> infosys.com]
Sent: Wednesday, October 12, 2011 4:20 AM
To: Kunal Shah; magma <at> ietf.org
Subject: RE: Question about IGMP host implementation

Hi Kunal,

        I think to keep the security tight, it is better to not respond to queries received from a source address
which does not fall on a subnet on that interface. Please note that this should be done only broadcast
interfaces. It may not work on point-to-point links.

        If you look at the security consideration in RFC 2236, it is mentioned that for reports, the above check
should be done.

Regards,
Bharat
________________________________________
From: magma-bounces <at> ietf.org [magma-bounces <at> ietf.org] On Behalf Of Kunal Shah [kunal.shah <at> ericsson.com]
Sent: Wednesday, October 12, 2011 6:08 AM
To: magma <at> ietf.org
Subject: [magma] Question about IGMP host implementation

Hi all,

Can an IGMPv2 host respond to a general query originated from a subnet other then its own?? RFC 2236 states:

""query received" occurs when the host receives either a valid
     General Membership Query message, or a valid Group-Specific
     Membership Query message.  To be valid, the Query message must be
     at least 8 octets long, and have a correct IGMP checksum.  The
     group address in the IGMP header must either be zero (a General
     Query) or a valid multicast group address (a Group-Specific Query)"

There is no requirement for the source address to be on the same subnet as the host.

Thanks,
Kunal

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

End of magma Digest, Vol 77, Issue 2
************************************

Question about IGMP host implementation

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

IGMP/MLD discussion on PIM working-group

Hi All,

     I am not sure if people are aware of this. The new charter of PIM working-group now includes work on IGMP/MLD
protocol as well. So if you are interested in these protocols, please subscribe to PIM working-group
mailing list as well.

     Apologies if you are already on PIM working-group list or are aware of this.

Regards,
Bharat
**************** 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***