From owner-idmr@cs.ucl.ac.uk Wed Oct 2 13:11:08 2002 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28879 for ; Wed, 2 Oct 2002 13:11:08 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 2 Oct 2002 17:48:56 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Oct 2002 17:48:48 +0100 Received: from mailgw2.technion.ac.il by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 2 Oct 2002 17:47:51 +0100 Received: by mailgw2.technion.ac.il (Postfix, from userid 60999) id 5EB9A36D66; Wed, 2 Oct 2002 19:46:41 +0300 (IDT) Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by mailgw2.technion.ac.il (Postfix) with SMTP id 9025336CED for ; Wed, 2 Oct 2002 19:46:39 +0300 (IDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 2 Oct 2002 17:26:42 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Oct 2002 17:26:35 +0100 Received: from mail.timetra.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 2 Oct 2002 17:25:32 +0100 Received: from SURESHPC ([192.168.1.253]) by mail.timetranetworks.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 2 Oct 2002 09:24:32 -0700 Reply-To: suresh From: Suresh Boddapati To: idmr Subject: IGMPV3: Source timer expiration in Exclude Mode Date: Wed, 2 Oct 2002 09:25:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 02 Oct 2002 16:24:32.0963 (UTC) FILETIME=[30CED130:01C26A30] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In the table specified in Section 6.3, when a source timer expires in EXCLUDE mode, it says "DO NOT Remove Record". I am assuming this means the source record. If so, what is the use of keeping the record and not removing it as is done when the mode is INCLUDE? When the group timer expires and the transition happens to INCLUDE mode, all the source records that have expired timers are removed anyway. Why keep them till the group timer expires? Thanks. Suresh From owner-idmr@cs.ucl.ac.uk Wed Oct 2 13:14:04 2002 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29022 for ; Wed, 2 Oct 2002 13:14:04 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 2 Oct 2002 17:26:42 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Oct 2002 17:26:35 +0100 Received: from mail.timetra.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 2 Oct 2002 17:25:32 +0100 Received: from SURESHPC ([192.168.1.253]) by mail.timetranetworks.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 2 Oct 2002 09:24:32 -0700 Reply-To: suresh From: Suresh Boddapati To: idmr Subject: IGMPV3: Source timer expiration in Exclude Mode Date: Wed, 2 Oct 2002 09:25:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 02 Oct 2002 16:24:32.0963 (UTC) FILETIME=[30CED130:01C26A30] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In the table specified in Section 6.3, when a source timer expires in EXCLUDE mode, it says "DO NOT Remove Record". I am assuming this means the source record. If so, what is the use of keeping the record and not removing it as is done when the mode is INCLUDE? When the group timer expires and the transition happens to INCLUDE mode, all the source records that have expired timers are removed anyway. Why keep them till the group timer expires? Thanks. Suresh From owner-idmr@cs.ucl.ac.uk Thu Oct 3 01:06:52 2002 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17312 for ; Thu, 3 Oct 2002 01:06:51 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 3 Oct 2002 04:36:09 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Oct 2002 04:36:03 +0100 Received: from 202.56.254.10 by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 3 Oct 2002 04:34:55 +0100 Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by mtv01owa01.mindtree.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 3 Oct 2002 09:05:13 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IGMPV3: Source timer expiration in Exclude Mode Date: Thu, 3 Oct 2002 09:05:12 +0530 Message-ID: <8FE7FF0CFEFE3243998E86D27FE334665585C3@mtv01ex01.mindtree.com> Thread-Topic: IGMPV3: Source timer expiration in Exclude Mode Thread-Index: AcJqOu5u7+Xgvj5cRAi33sqnmmq5GAAUM4PQ From: Srivatsan S To: suresh , idmr X-OriginalArrivalTime: 03 Oct 2002 03:35:13.0228 (UTC) FILETIME=[E1DFF8C0:01C26A8D] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA17312 Suresh, Following table gives u a more clear picture. Mode Source Timer EXCLUDE If source timer is running, then there is a conflict for the source, i.e., one client wants mcast packets from the source, while another doesn't. Hence the result is if source timer is running in EXCLUDE mode, the mcast packets from the source are forwarded to the n/w. It is the responsibility of the client to filter out unwanted packets. EXCLUDE No source timers are running. The clients in this n/w are in total agreement that they don't need packets from this source. INCLUDE Source timer should be running. Because if the source timers are not running, there is no point in keeping the entry as it is obvious that none of the clients are interested. Also, note that in EXCLUDE mode if any igmp packets are received which contains sources to be blocked, these are not blocked immediately. A Group and source specific query is sent to make sure that none of the clients on the n/w wants packets from the source. At this point of time, the mode is EXCLUDE with source timer running. If no response is received, the timer expires blocking the source. If a client responds, the source timer continues to run with all mcast packets from the source being forwarded to the interface. Hope this helps. Thanks, Srivatsan ---------------------------------------------------------- Srivatsan S MindTree Consulting, Bangalore. Ph: 91-80-6711777 Extn:1428 ---------------------------------------------------------- -----Original Message----- From: Suresh Boddapati [mailto:suresh@timetranetworks.com] Sent: Wednesday, October 02, 2002 9:55 PM To: idmr Subject: IGMPV3: Source timer expiration in Exclude Mode Hi, In the table specified in Section 6.3, when a source timer expires in EXCLUDE mode, it says "DO NOT Remove Record". I am assuming this means the source record. If so, what is the use of keeping the record and not removing it as is done when the mode is INCLUDE? When the group timer expires and the transition happens to INCLUDE mode, all the source records that have expired timers are removed anyway. Why keep them till the group timer expires? Thanks. Suresh From owner-idmr@cs.ucl.ac.uk Thu Oct 3 01:07:43 2002 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17333 for ; Thu, 3 Oct 2002 01:07:42 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 3 Oct 2002 05:46:22 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Oct 2002 05:46:11 +0100 Received: from mailgw2.technion.ac.il by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 3 Oct 2002 05:45:16 +0100 Received: by mailgw2.technion.ac.il (Postfix, from userid 60999) id 98CB636D84; Thu, 3 Oct 2002 07:45:14 +0300 (IDT) Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by mailgw2.technion.ac.il (Postfix) with SMTP id 92A1E36D1B for ; Thu, 3 Oct 2002 07:45:13 +0300 (IDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 3 Oct 2002 04:36:09 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Oct 2002 04:36:03 +0100 Received: from 202.56.254.10 by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 3 Oct 2002 04:34:55 +0100 Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by mtv01owa01.mindtree.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 3 Oct 2002 09:05:13 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IGMPV3: Source timer expiration in Exclude Mode Date: Thu, 3 Oct 2002 09:05:12 +0530 Message-ID: <8FE7FF0CFEFE3243998E86D27FE334665585C3@mtv01ex01.mindtree.com> Thread-Topic: IGMPV3: Source timer expiration in Exclude Mode Thread-Index: AcJqOu5u7+Xgvj5cRAi33sqnmmq5GAAUM4PQ From: Srivatsan S To: suresh , idmr X-OriginalArrivalTime: 03 Oct 2002 03:35:13.0228 (UTC) FILETIME=[E1DFF8C0:01C26A8D] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA17333 Suresh, Following table gives u a more clear picture. Mode Source Timer EXCLUDE If source timer is running, then there is a conflict for the source, i.e., one client wants mcast packets from the source, while another doesn't. Hence the result is if source timer is running in EXCLUDE mode, the mcast packets from the source are forwarded to the n/w. It is the responsibility of the client to filter out unwanted packets. EXCLUDE No source timers are running. The clients in this n/w are in total agreement that they don't need packets from this source. INCLUDE Source timer should be running. Because if the source timers are not running, there is no point in keeping the entry as it is obvious that none of the clients are interested. Also, note that in EXCLUDE mode if any igmp packets are received which contains sources to be blocked, these are not blocked immediately. A Group and source specific query is sent to make sure that none of the clients on the n/w wants packets from the source. At this point of time, the mode is EXCLUDE with source timer running. If no response is received, the timer expires blocking the source. If a client responds, the source timer continues to run with all mcast packets from the source being forwarded to the interface. Hope this helps. Thanks, Srivatsan ---------------------------------------------------------- Srivatsan S MindTree Consulting, Bangalore. Ph: 91-80-6711777 Extn:1428 ---------------------------------------------------------- -----Original Message----- From: Suresh Boddapati [mailto:suresh@timetranetworks.com] Sent: Wednesday, October 02, 2002 9:55 PM To: idmr Subject: IGMPV3: Source timer expiration in Exclude Mode Hi, In the table specified in Section 6.3, when a source timer expires in EXCLUDE mode, it says "DO NOT Remove Record". I am assuming this means the source record. If so, what is the use of keeping the record and not removing it as is done when the mode is INCLUDE? When the group timer expires and the transition happens to INCLUDE mode, all the source records that have expired timers are removed anyway. Why keep them till the group timer expires? Thanks. Suresh From owner-idmr@cs.ucl.ac.uk Thu Oct 3 12:51:17 2002 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24156 for ; Thu, 3 Oct 2002 12:51:17 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 3 Oct 2002 16:39:45 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Oct 2002 16:39:38 +0100 Received: from mail.timetra.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 3 Oct 2002 16:38:42 +0100 Received: from SURESHPC ([192.168.1.253]) by mail.timetranetworks.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 3 Oct 2002 08:37:34 -0700 Reply-To: suresh From: Suresh Boddapati To: Srivatsan S , idmr Subject: RE: IGMPV3: Source timer expiration in Exclude Mode Date: Thu, 3 Oct 2002 08:38:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <8FE7FF0CFEFE3243998E86D27FE334665585C3@mtv01ex01.mindtree.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 03 Oct 2002 15:37:34.0958 (UTC) FILETIME=[CB8F20E0:01C26AF2] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Not sure this helps. Maybe you can elaborate. My question relates to the second entry in your table. I have a source timer that has become zero (or expired) in EXCLUDE mode. The draft says that I should not remove the source record (even though I should block forwarding of packets from this source). My question is what is the use of keeping this record around? Why not just delete it? We delete the record with source timer zero in INCLUDE mode because we dont need it anymore. Same thing applies to EXCLUDE mode also (even from your explanation, since everybody on the network is in agreement that no one needs packets from this source). -----Original Message----- From: owner-idmr@cs.ucl.ac.uk [mailto:owner-idmr@cs.ucl.ac.uk]On Behalf Of Srivatsan S Sent: Wednesday, October 02, 2002 8:35 PM To: suresh; idmr Subject: RE: IGMPV3: Source timer expiration in Exclude Mode Suresh, Following table gives u a more clear picture. Mode Source Timer EXCLUDE If source timer is running, then there is a conflict for the source, i.e., one client wants mcast packets from the source, while another doesn't. Hence the result is if source timer is running in EXCLUDE mode, the mcast packets from the source are forwarded to the n/w. It is the responsibility of the client to filter out unwanted packets. EXCLUDE No source timers are running. The clients in this n/w are in total agreement that they don't need packets from this source. INCLUDE Source timer should be running. Because if the source timers are not running, there is no point in keeping the entry as it is obvious that none of the clients are interested. Also, note that in EXCLUDE mode if any igmp packets are received which contains sources to be blocked, these are not blocked immediately. A Group and source specific query is sent to make sure that none of the clients on the n/w wants packets from the source. At this point of time, the mode is EXCLUDE with source timer running. If no response is received, the timer expires blocking the source. If a client responds, the source timer continues to run with all mcast packets from the source being forwarded to the interface. Hope this helps. Thanks, Srivatsan ---------------------------------------------------------- Srivatsan S MindTree Consulting, Bangalore. Ph: 91-80-6711777 Extn:1428 ---------------------------------------------------------- -----Original Message----- From: Suresh Boddapati [mailto:suresh@timetranetworks.com] Sent: Wednesday, October 02, 2002 9:55 PM To: idmr Subject: IGMPV3: Source timer expiration in Exclude Mode Hi, In the table specified in Section 6.3, when a source timer expires in EXCLUDE mode, it says "DO NOT Remove Record". I am assuming this means the source record. If so, what is the use of keeping the record and not removing it as is done when the mode is INCLUDE? When the group timer expires and the transition happens to INCLUDE mode, all the source records that have expired timers are removed anyway. Why keep them till the group timer expires? Thanks. Suresh From owner-idmr@cs.ucl.ac.uk Fri Oct 4 01:17:13 2002 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14183 for ; Fri, 4 Oct 2002 01:17:12 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 4 Oct 2002 05:31:44 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 4 Oct 2002 05:31:37 +0100 Received: from 202.56.254.10 by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 4 Oct 2002 05:30:39 +0100 Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by mtv01owa01.mindtree.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 4 Oct 2002 10:00:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IGMPV3: Source timer expiration in Exclude Mode Date: Fri, 4 Oct 2002 10:00:54 +0530 Message-ID: <8FE7FF0CFEFE3243998E86D27FE334665585C4@mtv01ex01.mindtree.com> Thread-Topic: IGMPV3: Source timer expiration in Exclude Mode Thread-Index: AcJrAVdo4jtWGf9+QSq376Pkd1NRCwAXIZbg From: Srivatsan S To: suresh , idmr X-OriginalArrivalTime: 04 Oct 2002 04:30:57.0704 (UTC) FILETIME=[D5C04280:01C26B5E] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA14183 EXCLUDE mode is "forwarding packets from *all but* specific source addresses". When you remove the source (with timer expired) from the list, multicast data packets from that source are forwarded to that i/f (whereas it should be blocked). Only the sources with "source-timers expired and in the block list" are blocked in EXCLUDE mode. Packets from all other sources are forwarded. Refer Appendix A.3 in the draft for more explanation. - Srivatsan ---------------------------------------------------------- Srivatsan S MindTree Consulting, Bangalore. Ph: 91-80-6711777 Extn:1428 ---------------------------------------------------------- -----Original Message----- From: Suresh Boddapati [mailto:suresh@timetranetworks.com] Sent: Thursday, October 03, 2002 9:08 PM To: Srivatsan S; idmr Subject: RE: IGMPV3: Source timer expiration in Exclude Mode Not sure this helps. Maybe you can elaborate. My question relates to the second entry in your table. I have a source timer that has become zero (or expired) in EXCLUDE mode. The draft says that I should not remove the source record (even though I should block forwarding of packets from this source). My question is what is the use of keeping this record around? Why not just delete it? We delete the record with source timer zero in INCLUDE mode because we dont need it anymore. Same thing applies to EXCLUDE mode also (even from your explanation, since everybody on the network is in agreement that no one needs packets from this source). -----Original Message----- From: owner-idmr@cs.ucl.ac.uk [mailto:owner-idmr@cs.ucl.ac.uk]On Behalf Of Srivatsan S Sent: Wednesday, October 02, 2002 8:35 PM To: suresh; idmr Subject: RE: IGMPV3: Source timer expiration in Exclude Mode Suresh, Following table gives u a more clear picture. Mode Source Timer EXCLUDE If source timer is running, then there is a conflict for the source, i.e., one client wants mcast packets from the source, while another doesn't. Hence the result is if source timer is running in EXCLUDE mode, the mcast packets from the source are forwarded to the n/w. It is the responsibility of the client to filter out unwanted packets. EXCLUDE No source timers are running. The clients in this n/w are in total agreement that they don't need packets from this source. INCLUDE Source timer should be running. Because if the source timers are not running, there is no point in keeping the entry as it is obvious that none of the clients are interested. Also, note that in EXCLUDE mode if any igmp packets are received which contains sources to be blocked, these are not blocked immediately. A Group and source specific query is sent to make sure that none of the clients on the n/w wants packets from the source. At this point of time, the mode is EXCLUDE with source timer running. If no response is received, the timer expires blocking the source. If a client responds, the source timer continues to run with all mcast packets from the source being forwarded to the interface. Hope this helps. Thanks, Srivatsan ---------------------------------------------------------- Srivatsan S MindTree Consulting, Bangalore. Ph: 91-80-6711777 Extn:1428 ---------------------------------------------------------- -----Original Message----- From: Suresh Boddapati [mailto:suresh@timetranetworks.com] Sent: Wednesday, October 02, 2002 9:55 PM To: idmr Subject: IGMPV3: Source timer expiration in Exclude Mode Hi, In the table specified in Section 6.3, when a source timer expires in EXCLUDE mode, it says "DO NOT Remove Record". I am assuming this means the source record. If so, what is the use of keeping the record and not removing it as is done when the mode is INCLUDE? When the group timer expires and the transition happens to INCLUDE mode, all the source records that have expired timers are removed anyway. Why keep them till the group timer expires? Thanks. Suresh From owner-idmr@cs.ucl.ac.uk Fri Oct 4 10:28:12 2002 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05398 for ; Fri, 4 Oct 2002 10:28:11 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 4 Oct 2002 14:46:33 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 4 Oct 2002 14:46:26 +0100 Received: from 202.56.254.10 by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 4 Oct 2002 14:45:22 +0100 Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by mtv01owa01.mindtree.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 4 Oct 2002 19:14:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Host suppression Date: Fri, 4 Oct 2002 19:14:51 +0530 Message-ID: <8FE7FF0CFEFE3243998E86D27FE334665585C6@mtv01ex01.mindtree.com> Thread-Topic: Host suppression Thread-Index: AcJrrDatKx4dwRhbQ5+rtLezyx5XXQ== From: Srivatsan S To: idmr X-OriginalArrivalTime: 04 Oct 2002 13:44:51.0844 (UTC) FILETIME=[36D79440:01C26BAC] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA05398 Hi, This is regarding the information furnished in "Appendix A.2 Host Suppression" Host suppression doesn't have any meaning for IGMPv3. This is because IGMPv3 report message includes different records, which in turn includes mode and source list information for a group. The chances of mode type and source list being same for two hosts on the same network being remote, host suppression doesn't have any logic in IGMPv3. Whereas in IGMPv2, the report packet consisted of only the group address and a single report would suffice per group per network. This point has to be mentioned clearly in the appendix section. Thanks, Srivatsan ---------------------------------------------------------- Srivatsan S MindTree Consulting, Bangalore. Ph: 91-80-6711777 Extn:1428 ---------------------------------------------------------- From owner-idmr@cs.ucl.ac.uk Fri Oct 4 12:41:46 2002 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12583 for ; Fri, 4 Oct 2002 12:41:46 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 4 Oct 2002 17:05:03 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 4 Oct 2002 17:04:57 +0100 Received: from mail.timetra.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 4 Oct 2002 17:03:56 +0100 Received: from SURESHPC ([192.168.1.253]) by mail.timetranetworks.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 4 Oct 2002 09:02:39 -0700 Reply-To: suresh From: Suresh Boddapati To: Srivatsan S , idmr Subject: RE: IGMPV3: Source timer expiration in Exclude Mode Date: Fri, 4 Oct 2002 09:03:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <8FE7FF0CFEFE3243998E86D27FE334665585C4@mtv01ex01.mindtree.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 04 Oct 2002 16:02:39.0809 (UTC) FILETIME=[76EEEB10:01C26BBF] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the explanation. I think I understand what you are saying, although IMO the spec could have been a little more explicit. I guess it is more easier conceptually and consistent with the draft's notation if it stated that "when a source timer expires in EXCLUDE mode, IGMP should suggest to not forward traffic from source and move source from the INCLUDE list to the EXCLUDE list" i.e. Original state Src Timer expired New state ============== =============== ============== EXCLUDE(X, Y) (A) EXCLUDE(X-A, Y+A) Does this sound right? Suresh -----Original Message----- From: owner-idmr@cs.ucl.ac.uk [mailto:owner-idmr@cs.ucl.ac.uk]On Behalf Of Srivatsan S Sent: Thursday, October 03, 2002 9:31 PM To: suresh; idmr Subject: RE: IGMPV3: Source timer expiration in Exclude Mode EXCLUDE mode is "forwarding packets from *all but* specific source addresses". When you remove the source (with timer expired) from the list, multicast data packets from that source are forwarded to that i/f (whereas it should be blocked). Only the sources with "source-timers expired and in the block list" are blocked in EXCLUDE mode. Packets from all other sources are forwarded. Refer Appendix A.3 in the draft for more explanation. - Srivatsan ---------------------------------------------------------- Srivatsan S MindTree Consulting, Bangalore. Ph: 91-80-6711777 Extn:1428 ---------------------------------------------------------- -----Original Message----- From: Suresh Boddapati [mailto:suresh@timetranetworks.com] Sent: Thursday, October 03, 2002 9:08 PM To: Srivatsan S; idmr Subject: RE: IGMPV3: Source timer expiration in Exclude Mode Not sure this helps. Maybe you can elaborate. My question relates to the second entry in your table. I have a source timer that has become zero (or expired) in EXCLUDE mode. The draft says that I should not remove the source record (even though I should block forwarding of packets from this source). My question is what is the use of keeping this record around? Why not just delete it? We delete the record with source timer zero in INCLUDE mode because we dont need it anymore. Same thing applies to EXCLUDE mode also (even from your explanation, since everybody on the network is in agreement that no one needs packets from this source). -----Original Message----- From: owner-idmr@cs.ucl.ac.uk [mailto:owner-idmr@cs.ucl.ac.uk]On Behalf Of Srivatsan S Sent: Wednesday, October 02, 2002 8:35 PM To: suresh; idmr Subject: RE: IGMPV3: Source timer expiration in Exclude Mode Suresh, Following table gives u a more clear picture. Mode Source Timer EXCLUDE If source timer is running, then there is a conflict for the source, i.e., one client wants mcast packets from the source, while another doesn't. Hence the result is if source timer is running in EXCLUDE mode, the mcast packets from the source are forwarded to the n/w. It is the responsibility of the client to filter out unwanted packets. EXCLUDE No source timers are running. The clients in this n/w are in total agreement that they don't need packets from this source. INCLUDE Source timer should be running. Because if the source timers are not running, there is no point in keeping the entry as it is obvious that none of the clients are interested. Also, note that in EXCLUDE mode if any igmp packets are received which contains sources to be blocked, these are not blocked immediately. A Group and source specific query is sent to make sure that none of the clients on the n/w wants packets from the source. At this point of time, the mode is EXCLUDE with source timer running. If no response is received, the timer expires blocking the source. If a client responds, the source timer continues to run with all mcast packets from the source being forwarded to the interface. Hope this helps. Thanks, Srivatsan ---------------------------------------------------------- Srivatsan S MindTree Consulting, Bangalore. Ph: 91-80-6711777 Extn:1428 ---------------------------------------------------------- -----Original Message----- From: Suresh Boddapati [mailto:suresh@timetranetworks.com] Sent: Wednesday, October 02, 2002 9:55 PM To: idmr Subject: IGMPV3: Source timer expiration in Exclude Mode Hi, In the table specified in Section 6.3, when a source timer expires in EXCLUDE mode, it says "DO NOT Remove Record". I am assuming this means the source record. If so, what is the use of keeping the record and not removing it as is done when the mode is INCLUDE? When the group timer expires and the transition happens to INCLUDE mode, all the source records that have expired timers are removed anyway. Why keep them till the group timer expires? Thanks. Suresh From owner-idmr@cs.ucl.ac.uk Thu Oct 17 21:34:32 2002 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02440 for ; Thu, 17 Oct 2002 21:34:31 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 18 Oct 2002 01:04:33 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Oct 2002 00:25:54 +0100 Received: from gamma.isi.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 18 Oct 2002 00:24:37 +0100 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g9HNOWD12387; Thu, 17 Oct 2002 16:24:32 -0700 (PDT) Message-Id: <200210172324.g9HNOWD12387@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3376 on Internet Group Management Protocol, Version 3 Cc: rfc-editor@rfc-editor.org, idmr@cs.ucl.ac.uk From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 17 Oct 2002 16:24:32 -0700 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3376 Title: Internet Group Management Protocol, Version 3 Author(s): B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan Status: Standards Track Date: October 2002 Mailbox: deering@cisco.com, fenner@research.att.com, kouvelas@cisco.com Pages: 53 Characters: 119726 Obsoletes: 2236 I-D Tag: draft-ietf-idmr-igmp-v3-11.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3376.txt This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document obsoletes RFC 2236. This document is a product of the Inter-Domain Multicast Routing Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <021017162240.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3376 --OtherAccess Content-Type: Message/External-body; name="rfc3376.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021017162240.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart--