From owner-idmr@cs.ucl.ac.uk Thu Apr 5 11:09:48 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04584 for ; Thu, 5 Apr 2001 11:09:47 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 5 Apr 2001 13:48:43 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 5 Apr 2001 12:06:36 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 5 Apr 2001 12:06:45 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27372; Thu, 5 Apr 2001 07:06:42 -0400 (EDT) Message-Id: <200104051106.HAA27372@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: idmr@cs.ucl.ac.uk From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-igmp-proxy-00.txt,.ps Date: Thu, 05 Apr 2001 07:06:42 -0400 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : IGMP-based Multicast Forwarding ('IGMP Proxying') Author(s) : W. Fenner Filename : draft-ietf-idmr-igmp-proxy-00.txt,.ps Pages : 5 Date : 04-Apr-01 In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient to learn group membership information and simply forward based upon that information. This draft describes a mechanism for forwarding based solely upon IGMP membership information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-proxy-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idmr-igmp-proxy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idmr-igmp-proxy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010404074839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-igmp-proxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-igmp-proxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010404074839.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Thu Apr 5 13:11:41 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08454 for ; Thu, 5 Apr 2001 13:11:40 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 5 Apr 2001 16:18:28 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 5 Apr 2001 16:18:20 +0100 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 5 Apr 2001 16:18:20 +0100 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id RAA15470; Thu, 5 Apr 2001 17:18:16 +0200 (MET DST) Message-ID: <3ACC8CBD.D19F1DCF@irisa.fr> Date: Thu, 05 Apr 2001 17:18:21 +0200 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: ietf@ietf.org, idmr@cs.ucl.ac.uk Subject: BGP and MBGP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello, 1- Is the 2 attributs in MBGP are additional attributes in the update message of a BGP update message or it is just another type of update messages. If it is not a new message, and those are just two additionnal attributes then what should be the meaning of the unfeasible routes field and also the NLRI field in the update message? There is nothing in the standards and specifications clarifying this point. 2- in the case where MBGP used for Multicast, is it the role of this protocol that just providing a new multicast topology or there is anything else?? because if a new topology isnt created with the MBGP then there is no meaning of this protocol. 3- in the multicast topology , how can the paths can be aggregated??? in the same manner of unicast ??? suppressing the unfeasible routes or how? thanx From owner-idmr@cs.ucl.ac.uk Sat Apr 7 21:04:15 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18912 for ; Sat, 7 Apr 2001 21:04:14 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sun, 8 Apr 2001 00:54:44 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 7 Apr 2001 23:43:07 +0100 Received: from cypher.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 7 Apr 2001 23:43:23 +0100 Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA10501 for idmr@cs.ucl.ac.uk; Sat, 7 Apr 2001 15:43:22 -0700 (PDT) Date: Sat, 7 Apr 2001 15:43:22 -0700 From: Toerless Eckert To: idmr@cs.ucl.ac.uk Subject: If packet counters in MROUTE MIB ? (RFC2932) Message-ID: <20010407154322.A8580@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Can someone explain to me, why there are no per interface IP multicast packet input/output counters in RFC2932's IpMRouteInterfaceEntry ? There are Octet input/output counters in it, but no packet counters. When i tried to get an answer to this question from the authors, i was referred to the byte counters available in the interface MIB (RFC1573, RFC2233, RFC2863), but i do not understand how i should put IP multicast packet input/output counters into ifXTable's ifIn/OutMulticastPkts variables, because by default, the whole interface MIB is supposed to be layer2, or is it not ? Eg: On an ethernet interface, these counters should count ethernet level Multicast packets, and on a serial interface, they should probably not count any packets at all unless there is some L2 multicast mechanism on the p2p link. Right ? Wrong ? What if i don't only have IP ? "There's no multicast beside IP multicast" ? Fine with me, but does SNMP agree ? Or let me phrase the question differently: If i have a router that already utilizes the interface MIB counters for layer2 unicast/non-unicast/broadcast/multicast packet counters, where the heck should IP Multicast packet counters go into if those are known within the router explicitly ? Just wondering... Thanks Toerless From owner-idmr@cs.ucl.ac.uk Tue Apr 10 14:47:04 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23430 for ; Tue, 10 Apr 2001 14:47:03 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 10 Apr 2001 18:06:28 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 10 Apr 2001 18:06:22 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 10 Apr 2001 18:06:40 +0100 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 6603F1E0A1; Tue, 10 Apr 2001 13:06:34 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA11653; Tue, 10 Apr 2001 13:06:30 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA25108; Tue, 10 Apr 2001 10:06:29 -0700 (PDT) Message-Id: <200104101706.KAA25108@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: If packet counters in MROUTE MIB ? (RFC2932) Cc: idmr@cs.ucl.ac.uk Date: Tue, 10 Apr 2001 10:06:29 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Toerless, I talked to Dave Thaler (one of the authors of RFC2932) about this issue a couple of months ago, and basically there was some confusion when the MIB was designed about existing and new counters. In the context of IPv6, we're revising the IP (and TCP and UDP) MIB (see http://www.aciri.org/fenner/mibs/v6/). One of my proposals was to add all of these IP multicast packet and octet counters to this revision. Bill From owner-idmr@cs.ucl.ac.uk Fri Apr 13 18:25:26 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19595 for ; Fri, 13 Apr 2001 18:25:26 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 13 Apr 2001 22:09:53 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 13 Apr 2001 22:09:48 +0100 Received: from mpfg.attlabs.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 13 Apr 2001 22:10:05 +0100 Received: (from fenner@localhost) by mango.attlabs.att.com (8.9.3/8.9.3) id OAA15824 for idmr@cs.ucl.ac.uk; Fri, 13 Apr 2001 14:10:04 -0700 (PDT) (envelope-from fenner) Date: Fri, 13 Apr 2001 14:10:04 -0700 (PDT) From: Bill Fenner Message-Id: <200104132110.OAA15824@mango.attlabs.att.com> To: idmr@cs.ucl.ac.uk Subject: IDMR 50 minutes Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk IDMR met in one meeting at the 50th IETF. These minutes are reported by Bill Fenner. After the usual agenda bashing and document status session, there were four presentations of new work. Isidor Kouvelas presented MSNIP, the Multicast Source Notification of Interest Protocol, draft-ietf-idmr-msnip-00.{txt,ps}. This protocol allows routers to notify an end system when there is interest in reception of a given SSM stream (see the presentation slides for more details). There was interest expressed in a more general protocol that would allow handle non-SSM groups and also work with no router present. No course of action was decided upon at the meeting. Brian Haberman presented a document on the interactions between IGMPv3 and routing protocols, draft-ietf-idmr-igmpv3-and-routing-00.txt . Haixang He presented draft-he-mixed-igmp-proxy-00.txt, an extension to the ideas in draft-fenner-igmp-proxy-04.txt, to allow different IGMP versions on different interfaces. The authors of the two specs decided to work together on a single proxying spec. Morten Christensen presented a document on IGMP snooping, draft-ietf-idmr-snoop-00.txt . This document includes the problems that it introduces and some education for switch vendors. Bill Fenner and Brian Haberman then presented a proposal to terminate the IDMR working group and spin up a new working group, called MAGMA -- Multicast/Anycast Group Membership. Since IDMR's work items are almost completely IGMP, it doesn't make sense to have a routing-area group, and IDMR's history still includes some overhead. There was wide support in the meeting for this change. From owner-idmr@cs.ucl.ac.uk Mon Apr 16 09:48:22 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03620 for ; Mon, 16 Apr 2001 09:48:21 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 16 Apr 2001 13:24:36 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 16 Apr 2001 13:24:30 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 16 Apr 2001 13:24:48 +0100 Received: from chatel.loria.fr (chatel.loria.fr [152.81.12.37]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with SMTP id OAA21444 for ; Mon, 16 Apr 2001 14:24:45 +0200 (MET DST) From: Abdelkader Lahmadi To: idmr@cs.ucl.ac.uk Subject: igmpv3 router side Date: Mon, 16 Apr 2001 14:21:53 +0200 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01041614244500.05009@chatel.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit hi, in the router side of the protocol igmpv3. if the router receive a igmpv1 or igmpv2 query. what the router do? it's not mentionned in the draft of IGMPv3. regards, --------------------------------------------- Lahmadi Abdelkader LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : lahmadi@loria.fr --------------------------------------------- From owner-idmr@cs.ucl.ac.uk Mon Apr 16 13:22:47 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09015 for ; Mon, 16 Apr 2001 13:22:46 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 16 Apr 2001 16:50:08 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 16 Apr 2001 16:50:02 +0100 Received: from zcars04e.nortelnetworks.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 16 Apr 2001 16:50:21 +0100 Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Mon, 16 Apr 2001 11:48:29 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JASKJAL3; Mon, 16 Apr 2001 11:48:28 -0400 Received: from nortelnetworks.com (deathvalley.us.nortel.com [47.141.233.58]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G6TWSANR; Mon, 16 Apr 2001 11:48:28 -0400 Message-ID: <3ADB1424.529D6519@nortelnetworks.com> Date: Mon, 16 Apr 2001 11:47:49 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Brian Haberman X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Abdelkader Lahmadi CC: idmr@cs.ucl.ac.uk Subject: Re: igmpv3 router side References: <01041614244500.05009@chatel.loria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit It is mentioned, in section 7.3.1 discusses the interaction with older version queriers. Regards, Brian Abdelkader Lahmadi wrote: > > hi, > in the router side of the protocol igmpv3. if the router receive a igmpv1 > or igmpv2 query. what the router do? > it's not mentionned in the draft of IGMPv3. > regards, > --------------------------------------------- > Lahmadi Abdelkader > LORIA - UHP NANCY I > CAMPUS SCIENTIFIQUE B.P.239 > 54506 VANDOEUVRE-LES-NANCY CEDEX > E-mail : lahmadi@loria.fr > --------------------------------------------- From owner-idmr@cs.ucl.ac.uk Thu Apr 19 06:13:49 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09624 for ; Thu, 19 Apr 2001 06:13:48 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 19 Apr 2001 09:57:15 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 19 Apr 2001 09:57:09 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 19 Apr 2001 09:57:28 +0100 Received: from vernille.loria.fr (IDENT:lahmadi@vernille.loria.fr [152.81.11.123]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with SMTP id KAA29487 for ; Thu, 19 Apr 2001 10:57:25 +0200 (MET DST) From: Abdelkader Lahmadi To: idmr@cs.ucl.ac.uk Subject: querier election Date: Thu, 19 Apr 2001 10:54:28 +0200 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01041910572500.02159@vernille.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit hi, on a network, on router side of IGMPv3, what is the mecanism of the querier election ? is the router with the lowest version of IGMP is the querier? thanks, --------------------------------------------- Lahmadi Abdelkader LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : lahmadi@loria.fr --------------------------------------------- From owner-idmr@cs.ucl.ac.uk Thu Apr 19 06:15:39 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09635 for ; Thu, 19 Apr 2001 06:15:38 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 19 Apr 2001 10:54:06 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 19 Apr 2001 10:48:29 +0100 Received: from phoebe.eim.surrey.ac.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Thu, 19 Apr 2001 10:48:40 +0100 Received: from regan.ee.surrey.ac.uk ([131.227.89.11] helo=eim.surrey.ac.uk) by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14qB3F-0006NK-00 for idmr@CS.UCL.AC.UK; Thu, 19 Apr 2001 10:48:37 +0100 Message-ID: <3ADEB475.48B3AF2C@eim.surrey.ac.uk> Date: Thu, 19 Apr 2001 10:48:37 +0100 From: Ning Wang Organization: University of Surrey X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk Subject: A few questions Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit X-Scanner: exiscan *14qB3F-0006NK-00*K3a5nClL0yE* Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have a few questions on current multicast routing implementation: (1) IETF is now putting great efforts on SSM for one-to-many applications. On the other hand, Simple Multicast also belongs to RAMA style multicast, but why isn't it attractive recently? I just noticed that the last internet draft for SM is in Oct. 1999. IETF is developing bidir-PIM, does this mean that SM comes to its end? In fact SM successfully solves the problem of class D address allocation. BTW, can igmpv3 support SM? Note that the root of the tree in SM is a router instead of the information source itself. (2) For multicast applications with multi-senders we can still use SSM model, and additional senders can be authorized and authenticated by the single source (root) at the APPLICATION level. How about bi-directional trees? Is it possible to implement the sender access control at the same level, or should it be developed at the routing level? Thanks. Ning Wang From owner-idmr@cs.ucl.ac.uk Thu Apr 19 13:30:29 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14949 for ; Thu, 19 Apr 2001 13:30:28 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 19 Apr 2001 14:35:16 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 19 Apr 2001 14:32:03 +0100 Received: from drawbridge.ascend.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 19 Apr 2001 14:32:22 +0100 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id GAA27607; Thu, 19 Apr 2001 06:32:02 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 19 Apr 2001 13:32:20 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id GAA27423; Thu, 19 Apr 2001 06:32:20 -0700 (PDT) Received: from tinman.eng.ascend.com (tinman.eng.ascend.com [135.140.53.78]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id GAA09613; Thu, 19 Apr 2001 06:32:20 -0700 (PDT) Received: from siddhart by tinman.eng.ascend.com (8.8.8+Sun/SMI-SVR4) id GAA20987; Thu, 19 Apr 2001 06:33:05 -0700 (PDT) Message-ID: <039601c0c8d5$9c018b30$aa1ea8c0@boh.lucent.com> From: Siddhartha Karan Singh To: Abdelkader Lahmadi Cc: idmr References: <01041910572500.02159@vernille.loria.fr> Subject: Re: querier election Date: Thu, 19 Apr 2001 09:35:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Is'nt that the one with the lowest IP address. ----- Original Message ----- From: "Abdelkader Lahmadi" To: Sent: Thursday, April 19, 2001 4:54 AM Subject: querier election > > hi, > on a network, on router side of IGMPv3, what is the mecanism of the querier > election ? is the router with the lowest version of IGMP is the querier? > thanks, > --------------------------------------------- > Lahmadi Abdelkader > LORIA - UHP NANCY I > CAMPUS SCIENTIFIQUE B.P.239 > 54506 VANDOEUVRE-LES-NANCY CEDEX > E-mail : lahmadi@loria.fr > --------------------------------------------- From owner-idmr@cs.ucl.ac.uk Fri Apr 20 06:00:50 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09687 for ; Fri, 20 Apr 2001 06:00:49 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 20 Apr 2001 09:50:10 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 20 Apr 2001 09:50:03 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 20 Apr 2001 09:50:22 +0100 Received: from vernille.loria.fr (IDENT:lahmadi@vernille.loria.fr [152.81.11.123]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with SMTP id KAA29660 for ; Fri, 20 Apr 2001 10:50:19 +0200 (MET DST) From: Abdelkader Lahmadi To: idmr Subject: forwarding rules on IGMPv3 Date: Fri, 20 Apr 2001 10:42:04 +0200 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain References: <039601c0c8d5$9c018b30$aa1ea8c0@boh.lucent.com> MIME-Version: 1.0 Message-Id: <01042010501901.04351@vernille.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit hi, what is the interaction between the multicast routing protocol and IGMPv3 router side ? --------------------------------------------- Lahmadi Abdelkader LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : lahmadi@loria.fr --------------------------------------------- From owner-idmr@cs.ucl.ac.uk Fri Apr 20 06:03:14 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09720 for ; Fri, 20 Apr 2001 06:03:13 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 20 Apr 2001 10:49:43 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 20 Apr 2001 02:14:16 +0100 Received: from patan.Sun.COM by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 20 Apr 2001 02:14:36 +0100 Received: from bcn.East.Sun.COM ([129.148.75.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27501; Thu, 19 Apr 2001 18:14:33 -0700 (PDT) Received: from bcn (bcn [129.148.75.4]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id VAA19710; Thu, 19 Apr 2001 21:14:32 -0400 (EDT) Message-Id: <200104200114.VAA19710@bcn.East.Sun.COM> Date: Thu, 19 Apr 2001 21:14:32 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: A few questions To: idmr@cs.ucl.ac.uk, N.Wang@eim.surrey.ac.uk MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iVhrKbD/+L58VeAtWL4LHg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk From: Ning Wang Hello, I have a few questions on current multicast routing implementation: (1) IETF is now putting great efforts on SSM for one-to-many applications. On the other hand, Simple Multicast also belongs to RAMA style multicast, but why isn't it attractive recently? I just noticed that the last internet draft for SM is in Oct. 1999. IETF is developing bidir-PIM, does this mean that SM comes to its end? In fact SM successfully solves the problem of class D address allocation. BTW, can igmpv3 support SM? Note that the root of the tree in SM is a router instead of the information source itself. The term "RAMA", for those for which it's not familiar, means "Root- Administered-Multicast-Addressing", and as you observed, "Single source multicast" and "Simple Multicast" both were RAMA-style. As for whether igmpv3 can support it...anything can support anything if there's enough bits. Igmpv3 has enough bits to specify "I want to join (R,G). But I'd think an even better way to do joins would be using something like UMTP, because it doesn't require support in the operating system...it can be deployed as a user-level process. And then you can also automatically tunnel across regions of the net that don't support multicast. you don't even need a local router on your LAN supporting multicast. The draft draft-finlayson-mboned-autotunneling-00.txt explains this. As you stated, bidirectional tree support with RAMA addressing would be a good thing to do. Bidirectional PIM cannot use RAMA addressing (at least as specified...anything can support anything if modified). BIdirectional PIM (currently) requires globally unique 4-byte addressing. As for whether it's a good time now to think about extending "single source" for bidirectional trees, I suspect it is. Now that people are getting used to the idea of 8-byte groups and seeing how it makes things much more manageable, it's a natural time to get together a proposal for reviving something like Simple Multicast. I'm not sure what mailing list would be appropriate. Maybe idmr, though this isn't strictly in their charter I think. Maybe SSM, though their charter seems to be specific to unidirectional trees. You said one slightly incorrect thing. You said that the root of the tree in bidir-RAMA was a "router rather than the source". The root need not be a router. It can be an endnode. The root does not need to forward traffic. In a bidir tree, even packet appears on every link once, so if the root is an endnode with only a single link, then it would never forward multicast traffic. It will either source it or receive it on its link. (2) For multicast applications with multi-senders we can still use SSM model, and additional senders can be authorized and authenticated by the single source (root) at the APPLICATION level. How about bi-directional trees? Is it possible to implement the sender access control at the same level, or should it be developed at the routing level? Thanks. Ning Wang If you want routers to enforce access control, then the access control policy would have to be distributed by the root to the routers along the tree. This was specified in the SImple Multicast proposal. It allows configuration of the policy at a single point (the tree root, the host of the multicast group), but you do want routers to filter unauthorized traffic. Radia From owner-idmr@cs.ucl.ac.uk Fri Apr 20 06:11:38 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09764 for ; Fri, 20 Apr 2001 06:11:37 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 20 Apr 2001 10:21:41 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 20 Apr 2001 10:21:35 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 20 Apr 2001 10:21:55 +0100 Received: from vernille.loria.fr (IDENT:lahmadi@vernille.loria.fr [152.81.11.123]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with SMTP id LAA02581 for ; Fri, 20 Apr 2001 11:21:54 +0200 (MET DST) From: Abdelkader Lahmadi To: idmr@cs.ucl.ac.uk Subject: forwarding rules Date: Fri, 20 Apr 2001 11:12:13 +0200 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01042011215402.04351@vernille.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit hi, on the IGMPv3 source-specific forwarding rules, if the multicast routing protocol haven't any infortmation about the (S,G) ,for example the last hope router wich have an (*,G) state, so there are on the subnet a traffic from an excluded source ? --------------------------------------------- Lahmadi Abdelkader LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : lahmadi@loria.fr --------------------------------------------- From owner-idmr@cs.ucl.ac.uk Fri Apr 20 13:54:20 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15420 for ; Fri, 20 Apr 2001 13:54:19 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 20 Apr 2001 17:44:25 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 20 Apr 2001 17:44:19 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 20 Apr 2001 17:44:25 +0100 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 77F0F4CF16; Fri, 20 Apr 2001 12:44:23 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA12483; Fri, 20 Apr 2001 12:44:22 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA26866; Fri, 20 Apr 2001 09:44:21 -0700 (PDT) Message-Id: <200104201644.JAA26866@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: abdelkader.lahmadi@loria.fr Subject: Re: querier election Cc: idmr@cs.ucl.ac.uk Date: Fri, 20 Apr 2001 09:44:20 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk The router with the lowest version of IGMP must be the querier, but since IGMPv1 did not specify a querier election mechanism, it wasn't possible to ensure that the IGMPv1 router was elected querier. Therefore, all routers speaking IGMP on a given network have to be configured to speak the same version, and then querier election occurs as specified in the IGMPv2 or v3 spec (or, if configured for v1, querier election occurs however it happens and you might end up with multiple or [hopefully not] zero queriers). Bill From owner-idmr@cs.ucl.ac.uk Fri Apr 20 13:54:25 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15431 for ; Fri, 20 Apr 2001 13:54:24 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 20 Apr 2001 17:48:08 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 20 Apr 2001 17:48:01 +0100 Received: from isis.lip6.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 20 Apr 2001 17:48:11 +0100 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.11.0/jtpda-5.3.2) with ESMTP id f3KGlug31636 ; Fri, 20 Apr 2001 18:47:56 +0200 Received: from lip6.fr (otos.lip6.fr [132.227.61.47]) by tibre.lip6.fr (8.11.3/8.11.3) with ESMTP id f3KGlkD22603; Fri, 20 Apr 2001 18:47:46 +0200 (CEST) Message-ID: <3AE0683B.75C90CB6@lip6.fr> Date: Fri, 20 Apr 2001 18:47:55 +0200 From: Rolland Vida Organization: Laboratoire Lip6 X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk, ipng@sunroof.eng.sun.com CC: iana@iana.org, icann@icann.org, Luis Costa Subject: address allocation for MLDv2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have a question about the procedure to follow in order to request the allocation of a special multicast address and a protocol message type number. We've already contacted IANA (at iana@iana.org) and ICANN (at icann@icann.org), but we haven't received any answer yet. We are working on the specification of the MLDv2 protocol draft, the IPv6 version of IGMPv3. (http://www.ietf.org/internet-drafts/draft-vida-mld-v2-00.txt) In the specification of the protocol we need the followings: 1. the allocation of a special IPv6 multicast address called "all mldv2-capable routers". For IGMPv3 IANA already allocated the IPv4 multicast address 224.0.0.22 for "all igmpv3-capable routers". As normally there is a correspondence between specially assigned IPv4 and IPv6 addresses, we think FF02::16 is the suitable address for all-mldv2-routers. But the only document that we found listing already assigned IPv6 multicast addresses is RFC2375, dated July 1998. So we are not sure that this proposed address is not already allocated. For IPv4 there's a much more recent document available at (http://www.isi.edu/in-notes/iana/assignments/multicast-addresses - March 2001) 2. the allocation of an ICMPv6 message type for MLDv2 Report messages. In the first version of the draft we mistakenly considered the value of 136 for this message type, but this value is already allocated to Neighbor Advertisment messages. As far as we know, the first available message type value is 143 (141 and 142 are experimental assignments for mtrace messages). But before releasing a new, corrected version of the draft, we would like to officially request the assignment of this value (143) for MLDv2 reports. We would appreciate if you could give us a hint on how to proceed in order to do these allocations. Maybe you've already faced a similar situation. Or can we just release the new version of the draft, with the considered values, and hope that IANA will confirm our assignments? Thanks in advance, Best regards, Rolland Vida Luis Costa -- ______________________________________________________ Make everything as simple as possible, but not simpler - Albert Einstein Rolland VIDA - Ph.D. student Universite Pierre et Marie Curie Laboratoire LIP6-CNRS, 8, rue du Capitaine Scott Tel: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: Rolland.Vida@lip6.fr Web: http://www-rp.lip6.fr/~vida ______________________________________________________ From owner-idmr@cs.ucl.ac.uk Fri Apr 20 13:58:48 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15452 for ; Fri, 20 Apr 2001 13:58:47 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 20 Apr 2001 17:49:03 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 20 Apr 2001 17:48:54 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 20 Apr 2001 17:49:02 +0100 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 345044CE99; Fri, 20 Apr 2001 12:49:00 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA12605; Fri, 20 Apr 2001 12:48:59 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA26930; Fri, 20 Apr 2001 09:48:58 -0700 (PDT) Message-Id: <200104201648.JAA26930@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: abdelkader.lahmadi@loria.fr Subject: Re: forwarding rules on IGMPv3 Cc: idmr@cs.ucl.ac.uk References: <039601c0c8d5$9c018b30$aa1ea8c0@boh.lucent.com> <01042010501901.04351@vernille.loria.fr> Date: Fri, 20 Apr 2001 09:48:58 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >what is the interaction between the multicast routing protocol and IGMPv3 >router side ? The IGMPv3 router side notifies the routing protocol of receiver interest on the network. The routing protocol takes that into account (along with other information) when deciding how to forward packets. See, for example, the pim_include() and pim_exclude() macros in the PIM spec, draft-ietf-pim-v2-new-02.{txt,ps}. Also see draft-ietf-idmr-igmpv3-and-routing-00.txt . The router may end up forwarding more than requested onto the LAN, e.g. because another router might want the traffic, when the LAN is being used for transit. Also, host A might include (S1,G) and host B might include (S2,G) and the router would have to forward both S1 and S2 onto the LAN, so systems already have to be able to handle seeing traffic on the LAN that they don't want. Bill From owner-idmr@cs.ucl.ac.uk Fri Apr 20 20:24:09 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20315 for ; Fri, 20 Apr 2001 20:24:08 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 20 Apr 2001 23:55:15 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 20 Apr 2001 23:55:08 +0100 Received: from newgate.mitel.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 20 Apr 2001 23:55:28 +0100 Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id SAA28744; Fri, 20 Apr 2001 18:53:17 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A34.007DB80C ; Fri, 20 Apr 2001 18:53:11 -0400 X-Lotus-FromDomain: MITEL From: James_Huang@Mitel.COM To: idmr@cs.ucl.ac.uk cc: kouvelas@cisco.com, fenner@research.att.com, deering@cisco.com, brad.cain@mirror-image.com, ajit@torrentnet.com Message-ID: <85256A34.007DB649.00@kanmta01.software.mitel.com> Date: Fri, 20 Apr 2001 15:53:07 -0700 Subject: X in igmpv3 EXCLUDE(X,Y) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi all, In IGMPV3, when a router receives an exclude mode response for a group G, it will keep state for that group in the format of EXCLUDE(X,Y). According to the draft, X is the set of sources that some host would like to receive their group G traffic but some other host is not interested in receiving their group G traffic. Why X is defined this way? Why not simply keep in X the set of sources that at least one host would like to receive their group G traffic? With this modified definition, transition from EXCLUDE mode to INCLUDE mode would be a lot more smooth than the current scheme. For example, after the following set of responses, host 1 sends IS_IN({a}). host 2 sends IS_IN({b}) host 3 sends IS_EX({b,c}), the router will keep a record of EXCLUDE({b},{c}) with the current scheme. With the modified scheme, the router will keep a record of EXCLUDE({a,b},{c}). When the group timer expires (e.g. host 3 crashes), the router will immediately switch the state to INCLUDE({a,b}) and possibly send some group-specific query. Am I missing something?? Regards, -- James Huang From owner-idmr@cs.ucl.ac.uk Mon Apr 23 14:59:47 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10440 for ; Mon, 23 Apr 2001 14:59:46 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 23 Apr 2001 18:32:03 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 23 Apr 2001 18:31:57 +0100 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 23 Apr 2001 18:32:17 +0100 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id TAA03385 for ; Mon, 23 Apr 2001 19:32:14 +0200 (MET DST) Message-ID: <3AE4671F.12FC537D@irisa.fr> Date: Mon, 23 Apr 2001 19:32:15 +0200 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit hello, Is the querier in IGMP is the same designated router in a network ?? thanx From owner-idmr@cs.ucl.ac.uk Mon Apr 23 17:57:12 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13597 for ; Mon, 23 Apr 2001 17:57:11 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 23 Apr 2001 21:47:36 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 23 Apr 2001 21:47:29 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 23 Apr 2001 21:47:51 +0100 Received: from dargneuilles.loria.fr (IDENT:lahmadi@dargneuilles.loria.fr [152.81.11.183]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with SMTP id WAA03378; Mon, 23 Apr 2001 22:47:48 +0200 (MET DST) From: Abdelkader Lahmadi To: Ali Boudani Subject: Re: (no subject) Date: Mon, 23 Apr 2001 22:46:56 +0200 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain References: <3AE4671F.12FC537D@irisa.fr> Cc: idmr@cs.ucl.ac.uk MIME-Version: 1.0 Message-Id: <01042322474801.13484@dargneuilles.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, 23 Apr 2001, you wrote: > hello, > Is the querier in IGMP is the same designated router in a network ?? > thanx -- Bill finner wrote: The router with the lowest version of IGMP must be the querier, but since IGMPv1 did not specify a querier election mechanism, it wasn't possible to ensure that the IGMPv1 router was elected querier. Therefore, all routers speaking IGMP on a given network have to be configured to speak the same version, and then querier election occurs as specified in the IGMPv2 or v3 spec (or, if configured for v1, querier election occurs however it happens and you might end up with multiple or [hopefully not] zero queriers). Bill --------------------------------------------- Lahmadi Abdelkader LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : lahmadi@loria.fr --------------------------------------------- From owner-idmr@cs.ucl.ac.uk Tue Apr 24 10:57:45 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08818 for ; Tue, 24 Apr 2001 10:57:44 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 24 Apr 2001 14:40:37 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 24 Apr 2001 14:40:31 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 24 Apr 2001 14:40:51 +0100 Received: from vignot.loria.fr (IDENT:lahmadi@vignot.loria.fr [152.81.2.146]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with SMTP id PAA06089; Tue, 24 Apr 2001 15:40:47 +0200 (MET DST) From: Abdelkader Lahmadi To: Bill Fenner Subject: IGMP proxy Date: Tue, 24 Apr 2001 15:29:56 +0200 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain References: <039601c0c8d5$9c018b30$aa1ea8c0@boh.lucent.com> <01042010501901.04351@vernille.loria.fr> <200104201648.JAA26930@windsor.research.att.com> In-Reply-To: <200104201648.JAA26930@windsor.research.att.com> Cc: idmr@cs.ucl.ac.uk MIME-Version: 1.0 Message-Id: <01042415404700.12762@vignot.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit hello, i'm working on an implementation fo an IGMP proxy according to your draft "IGMP proxing" and the draft of IGMPv3. i have implement a prototype of this proxy, without the forwarding rules, i will use the API given with the implementation of PIM-SM (by Ahmed Helmy), to updat th Multicast forwarding Cach in the Kernel to do the forwarding rules. then i think to integrate this proxy in the hole implementation of pim-sm to have a mulicast router using PIM-SM and IGMPv3 router side. but in your draft of igmp proxy, you mentionned the spanning tree multicast protocol, i haven't a big idea on this protocol so where can i find more information about i? and an IGMP proxy is designed to be used with this protocol, or any multicast protocol? regards, --------------------------------------------- Lahmadi Abdelkader LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : lahmadi@loria.fr -------------------------------------------- From owner-idmr@cs.ucl.ac.uk Tue Apr 24 15:25:40 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13486 for ; Tue, 24 Apr 2001 15:25:39 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 24 Apr 2001 18:49:49 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 24 Apr 2001 18:49:43 +0100 Received: from newgate.mitel.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 24 Apr 2001 18:49:58 +0100 Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id NAA04837; Tue, 24 Apr 2001 13:49:50 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A38.0061EF21 ; Tue, 24 Apr 2001 13:49:42 -0400 X-Lotus-FromDomain: MITEL From: James_Huang@Mitel.COM To: idmr@cs.ucl.ac.uk cc: kouvelas@cisco.com, fenner@research.att.com, deering@cisco.com, brad.cain@mirror-image.com, ajit@torrentnet.com Message-ID: <85256A38.0061EE35.00@kanmta01.software.mitel.com> Date: Tue, 24 Apr 2001 10:49:38 -0700 Subject: igmpv3 question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi all, In IGMPV3, when a router receives an exclude mode response for a group G, it will keep state for that group in the format of EXCLUDE(A,B). According to the draft, A is the set which represents "conflicts in the desired reception state" (section 6.2.1). When a IS_EX(B) is received with the router in a state of INCLUDE(A), the new router state will become EXCLUDE(A*B,B-A) (section 6.4.1). THis definition of A is not consistent with the following description from Appendix A.3: "One of the ways to accomplish this is for routers to keep track of all sources desired by hosts that are in INCLUDE mode even though the router itself is in EXCLUDE mode." If we follows the description in Appendix A.3, then when a IS_EX(B) is received with the router in a state of INCLUDE(A), the new router state should become EXCLUDE(A,B-A). For example, after the following set of reports, IS_IN({a}) from host1 IS_IN({b}) from host2 IS_EX({b,c}) from host3, the router will have a state of EXCLUDE({b},{c}) using the rules in section 6.4.1. But if we follows the description in Appendix A.3, then the router will have a state of EXCLUDE({a,b},{c}). Also the rules in section 6.4.1 seem to have the following property: the final state in the router depends on the order of the reports it receives. For example, if the order of the reports in the above example is changed to IS_IN({b}), IS_EX({b,c}), IS_IN({a}), then the state in the router will become EXCLUDE({a,b},{c}). Am I missing something?? Regards, -- James Huang From owner-idmr@cs.ucl.ac.uk Wed Apr 25 11:22:25 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19515 for ; Wed, 25 Apr 2001 11:22:24 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 25 Apr 2001 13:44:08 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 25 Apr 2001 09:05:17 +0100 Received: from 199.203.76.13 by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 25 Apr 2001 09:05:37 +0100 Received: by optmail.optibase.co.il with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 11:05:45 +0200 Message-ID: From: Arthur Rabinowitz To: idmr@cs.ucl.ac.uk Subject: RFC 1112/2236 Date: Wed, 25 Apr 2001 11:05:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk W. Fenner, I hope this mail finds you and finds you well. My name is Arthur Rabinovitz and I work for Optibase a company heavily invested in streaming and MPEG. My question to you is as follows. Under RFC 1112 which among other things obseletes RFC 988 does the Mulitcast Transmitter need to send a message, "build the group," or is this message not needed under RFC 1112 as it is under 988. I thank you in advance for your consideration. Arthur Rabinovitz Sincerely yours, Arthur Rabinovitz Customer Support Engineer Optibase LTD. Phone : +972-9-9709294 Fax : +972-9-9586099 For All Technical Support, our Web site: http://helpdesk.optibase.com/ See Optibase at these upcoming events: NAB 2001 (National Association Of Broadcasters) Sands Expo center, Booth # I6331 Las Vegas, Nevada USA, April 23th-26rd, 2001 http://www.nab.org/conventions/nab2001/attendees/exhibitors.asp IBC Streaming Media Conference The Marriott Hotel, London, May 14-15, 2001 http://www.ibctelecoms.com/streamingmedia From owner-idmr@cs.ucl.ac.uk Wed Apr 25 16:54:48 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00867 for ; Wed, 25 Apr 2001 16:54:48 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 25 Apr 2001 20:42:08 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 25 Apr 2001 20:42:02 +0100 Received: from newgate.mitel.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 25 Apr 2001 20:42:23 +0100 Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id PAA09023; Wed, 25 Apr 2001 15:42:21 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A39.006C3AB1 ; Wed, 25 Apr 2001 15:42:09 -0400 X-Lotus-FromDomain: MITEL From: James_Huang@Mitel.COM To: idmr@cs.ucl.ac.uk cc: brad.cain@mirror-image.com, fenner@research.att.com, deering@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com Message-ID: <85256A39.006C396A.00@kanmta01.software.mitel.com> Date: Wed, 25 Apr 2001 12:42:05 -0700 Subject: Another IGMPv3 question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi all, I believe the folowing rule in the latest IGMPv3 draft is wrong. Router state Report rec'd New router state Actions -------------------------------------------------------------------- EXCLUDE(X,Y) IS_EX(A) EXCLUDE(A-Y,Y*A) (A-X-Y)=GMI Delete (X-A) Delete (Y-A) Group Timer=GMI According to the Actions, the new router state should be EXCLUDE(X*A+(A-Y),Y*A). This result was also shown in draft-ietf-idmr-igmp-v3-05.txt and was somehow changed to EXCLUDE(A-Y,Y*A) in draft-ietf-idmr-igmp-v3-06.txt. Still I do not understand why we keep X*A+(A-Y) in the first set of source list. If the router receives the following sequence of reports, IS_EX(A) followd by IS_EX(B), with an initial state of INCLUDE({}), the resulting state will be EXCLUDE(B-A,A*B). Router state Report rec'd New router state ------------------------------------------------------ INCLUDE({}) IS_EX(A) EXCLUDE({},A) EXCLUDE({},A) IS_EX(B) EXCLUDE(B-A,A*B) But if the order of the two reports is reversed, the result will be EXCLUDE(A-B,A*B). Why is the final state depends on the order of reports received? What is the exact definition of X in EXCLUDE(X,Y)?? - James C. Huang From owner-idmr@cs.ucl.ac.uk Wed Apr 25 18:31:12 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02991 for ; Wed, 25 Apr 2001 18:31:11 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 25 Apr 2001 22:13:48 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 25 Apr 2001 22:13:42 +0100 Received: from sj-msg-core-1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 25 Apr 2001 22:14:03 +0100 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3PLDWL27141; Wed, 25 Apr 2001 14:13:36 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA10819; Wed, 25 Apr 2001 14:12:32 -0700 (PDT) Message-Id: <200104252112.OAA10819@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: James_Huang@Mitel.COM cc: idmr@cs.ucl.ac.uk, brad.cain@mirror-image.com, fenner@research.att.com, deering@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com Subject: Re: Another IGMPv3 question In-reply-to: Your message of "Wed, 25 Apr 2001 12:42:05 PDT." <85256A39.006C396A.00@kanmta01.software.mitel.com> Date: Wed, 25 Apr 2001 14:12:32 -0700 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk James_Huang@Mitel.COM writes: >Hi all, > > I believe the folowing rule in the latest IGMPv3 draft is wrong. > > Router state Report rec'd New router state Actions > -------------------------------------------------------------------- > EXCLUDE(X,Y) IS_EX(A) EXCLUDE(A-Y,Y*A) (A-X-Y)=GMI > Delete (X-A) > Delete (Y-A) > Group Timer=GMI > > >According to the Actions, the new router state should be EXCLUDE(X*A+(A-Y),Y*A). >This result was also shown in draft-ietf-idmr-igmp-v3-05.txt and was somehow >changed to EXCLUDE(A-Y,Y*A) in draft-ietf-idmr-igmp-v3-06.txt. The modification is correct as X*A is included in A-Y. >Still I do not understand why we keep X*A+(A-Y) in the first set of source list. >If the router receives the following sequence of reports, IS_EX(A) followd by >IS_EX(B), with an initial state of INCLUDE({}), the resulting >state will be EXCLUDE(B-A,A*B). > > > Router state Report rec'd New router state > ------------------------------------------------------ > INCLUDE({}) IS_EX(A) EXCLUDE({},A) > > EXCLUDE({},A) IS_EX(B) EXCLUDE(B-A,A*B) > > >But if the order of the two reports is reversed, the result will be >EXCLUDE(A-B,A*B). Why is the final state depends on the order of reports >received? What is the exact definition of X in EXCLUDE(X,Y)?? Set X is a temporary working set of sources that may become blocked if no messages are received to update the source timers. In both sequence of events above, only A*B will remain blocked. thanks I From owner-idmr@cs.ucl.ac.uk Wed Apr 25 20:42:19 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04925 for ; Wed, 25 Apr 2001 20:42:18 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 26 Apr 2001 01:09:29 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 26 Apr 2001 01:09:23 +0100 Received: from sj-msg-core-1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 26 Apr 2001 01:09:44 +0100 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3Q09QL01189; Wed, 25 Apr 2001 17:09:28 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA10977; Wed, 25 Apr 2001 17:09:12 -0700 (PDT) Message-Id: <200104260009.RAA10977@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: James_Huang@Mitel.COM cc: idmr@cs.ucl.ac.uk, Isidor Kouvelas , brad.cain@mirror-image.com, fenner@research.att.com, deering@cisco.com, ajit@torrentnet.com Subject: Re: Another IGMPv3 question In-reply-to: Your message of "Wed, 25 Apr 2001 16:45:15 PDT." <85256A39.00827CCB.00@kanmta01.software.mitel.com> Date: Wed, 25 Apr 2001 17:09:12 -0700 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk So the idea behind set X is that if no more messages are received from any other host, the view of the last reporting host will eventually be reflected by the router state. In your example below, if after this event: EXCLUDE({},A) IS_EX(B) EXCLUDE(B-A,A*B) the router keeps receiving IS_EX(B), (this means that the host that was sending IS_EX(A) either died or changed its mind) then the sources in X (i.e B-A) will time out and be added to set Y. Hence the state will become EXCLUDE({},B) which is what the host asked for. thanks I James_Huang@Mitel.COM writes: > > >From: James Huang@MITEL on 04/25/2001 04:45 PM PDT > > > > > >Isidor Kouvelas on 04/25/2001 02:12:32 PM > >To: James Huang/USA/Mitel@Mitel >cc: idmr@cs.ucl.ac.uk, brad.cain@mirror-image.com, fenner@research.att.com, > deering@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com > >Subject: Re: Another IGMPv3 question > > > > >James_Huang@Mitel.COM writes: >>>Hi all, >>> >>> I believe the folowing rule in the latest IGMPv3 draft is wrong. >>> >>> Router state Report rec'd New router state Actions >>> -------------------------------------------------------------------- >>> EXCLUDE(X,Y) IS_EX(A) EXCLUDE(A-Y,Y*A) (A-X-Y)=GMI >>> Delete (X-A) >>> Delete (Y-A) >>> Group Timer=GMI >>> >>> >>>According to the Actions, the new router state should be >EXCLUDE(X*A+(A-Y),Y*A). >>>This result was also shown in draft-ietf-idmr-igmp-v3-05.txt and was somehow >>>changed to EXCLUDE(A-Y,Y*A) in draft-ietf-idmr-igmp-v3-06.txt. >> >>The modification is correct as X*A is included in A-Y. >> > > >O.K.I got it. X*A is included in A-Y becuase X and Y are disjoint. > > >>>Still I do not understand why we keep X*A+(A-Y) in the first set of source >list. >>>If the router receives the following sequence of reports, IS_EX(A) followd b >y >>>IS_EX(B), with an initial state of INCLUDE({}), the resulting >>>state will be EXCLUDE(B-A,A*B). >>> >>> >>> Router state Report rec'd New router state >>> ------------------------------------------------------ >>> INCLUDE({}) IS_EX(A) EXCLUDE({},A) >>> >>> EXCLUDE({},A) IS_EX(B) EXCLUDE(B-A,A*B) >>> >>> >>>But if the order of the two reports is reversed, the result will be >>>EXCLUDE(A-B,A*B). Why is the final state depends on the order of reports >>>received? What is the exact definition of X in EXCLUDE(X,Y)?? >> >>Set X is a temporary working set of sources that may become blocked >>if no messages are received to update the source timers. In both >>sequence of events above, only A*B will remain blocked. >> >>thanks >>I >> > >The rule to computing the second set of the EXCLUDE mode state is very >straight-forward. Basically we have to make sure that any source with >interested receivers should not be included in the second set. > >But I simply can not find any rationale or pattern for the way the first set >(the temporary working set) is computed. For example, why INCLUDE(A) + IS_EX( >B) >--> EXCLUDE(A*B,B-A) instead of INCLUDE(A) + IS_EX(B) --> EXCLUDE(A,B-A)? Als >o >why EXCLUDE(X,Y) + IS_EX(A) --> EXCLUDE(A-Y,Y*A) instead of EXCLUDE(X,Y) + >IS_EX(A) --> EXCLUDE(X+Y+A-Y*A,Y*A)? Can someone explain it to me? > > >Thanks, >-- James C. Huang > > > > From owner-idmr@cs.ucl.ac.uk Wed Apr 25 20:56:59 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05072 for ; Wed, 25 Apr 2001 20:56:58 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 26 Apr 2001 00:45:25 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 26 Apr 2001 00:45:19 +0100 Received: from newgate.mitel.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 26 Apr 2001 00:45:40 +0100 Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id TAA01013; Wed, 25 Apr 2001 19:45:24 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A39.00827D30 ; Wed, 25 Apr 2001 19:45:17 -0400 X-Lotus-FromDomain: MITEL From: James_Huang@Mitel.COM To: idmr@cs.ucl.ac.uk, Isidor Kouvelas cc: brad.cain@mirror-image.com, fenner@research.att.com, deering@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com Message-ID: <85256A39.00827CCB.00@kanmta01.software.mitel.com> Date: Wed, 25 Apr 2001 16:45:15 -0700 Subject: Re: Another IGMPv3 question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk From: James Huang@MITEL on 04/25/2001 04:45 PM PDT Isidor Kouvelas on 04/25/2001 02:12:32 PM To: James Huang/USA/Mitel@Mitel cc: idmr@cs.ucl.ac.uk, brad.cain@mirror-image.com, fenner@research.att.com, deering@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com Subject: Re: Another IGMPv3 question James_Huang@Mitel.COM writes: >>Hi all, >> >> I believe the folowing rule in the latest IGMPv3 draft is wrong. >> >> Router state Report rec'd New router state Actions >> -------------------------------------------------------------------- >> EXCLUDE(X,Y) IS_EX(A) EXCLUDE(A-Y,Y*A) (A-X-Y)=GMI >> Delete (X-A) >> Delete (Y-A) >> Group Timer=GMI >> >> >>According to the Actions, the new router state should be EXCLUDE(X*A+(A-Y),Y*A). >>This result was also shown in draft-ietf-idmr-igmp-v3-05.txt and was somehow >>changed to EXCLUDE(A-Y,Y*A) in draft-ietf-idmr-igmp-v3-06.txt. > >The modification is correct as X*A is included in A-Y. > O.K.I got it. X*A is included in A-Y becuase X and Y are disjoint. >>Still I do not understand why we keep X*A+(A-Y) in the first set of source list. >>If the router receives the following sequence of reports, IS_EX(A) followd by >>IS_EX(B), with an initial state of INCLUDE({}), the resulting >>state will be EXCLUDE(B-A,A*B). >> >> >> Router state Report rec'd New router state >> ------------------------------------------------------ >> INCLUDE({}) IS_EX(A) EXCLUDE({},A) >> >> EXCLUDE({},A) IS_EX(B) EXCLUDE(B-A,A*B) >> >> >>But if the order of the two reports is reversed, the result will be >>EXCLUDE(A-B,A*B). Why is the final state depends on the order of reports >>received? What is the exact definition of X in EXCLUDE(X,Y)?? > >Set X is a temporary working set of sources that may become blocked >if no messages are received to update the source timers. In both >sequence of events above, only A*B will remain blocked. > >thanks >I > The rule to computing the second set of the EXCLUDE mode state is very straight-forward. Basically we have to make sure that any source with interested receivers should not be included in the second set. But I simply can not find any rationale or pattern for the way the first set (the temporary working set) is computed. For example, why INCLUDE(A) + IS_EX(B) --> EXCLUDE(A*B,B-A) instead of INCLUDE(A) + IS_EX(B) --> EXCLUDE(A,B-A)? Also why EXCLUDE(X,Y) + IS_EX(A) --> EXCLUDE(A-Y,Y*A) instead of EXCLUDE(X,Y) + IS_EX(A) --> EXCLUDE(X+Y+A-Y*A,Y*A)? Can someone explain it to me? Thanks, -- James C. Huang