From owner-idmr@cs.ucl.ac.uk Thu Jan 9 11:45:02 2003 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 LAA17242 for ; Thu, 9 Jan 2003 11:45:01 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 9 Jan 2003 14:41:13 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 9 Jan 2003 14:30:02 +0000 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 9 Jan 2003 14:26:44 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10783; Thu, 9 Jan 2003 09:23:23 -0500 (EST) Message-Id: <200301091423.JAA10783@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-mrdisc-10.txt Date: Thu, 09 Jan 2003 09:23:22 -0500 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 : Multicast Router Discovery Author(s) : S. Biswas, B. Cain, B. Haberman Filename : draft-ietf-idmr-igmp-mrdisc-10.txt Pages : 17 Date : 2003-1-8 The concept of IGMP snooping requires the ability to identify the location of multicast routers. Since IGMP (and MLD) snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this scenario can lead to interoperability issues between multicast routers and layer-2 switches from different vendors. This document introduces a general mechanism that allows for the discovery of multicast routers. By introducing these new messages, snooping devices have a uniform means of identifying multicast routers without dependency on particular routing protocols. These messages may also be used to convey configuration parameters to all systems on a network. In addition, other devices that may need to discover multicast routers can utilize these messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-mrdisc-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-mrdisc-10.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-mrdisc-10.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: <2003-1-9092312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-igmp-mrdisc-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-igmp-mrdisc-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9092312.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Tue Jan 21 16:08:54 2003 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 QAA12079 for ; Tue, 21 Jan 2003 16:08:53 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 21 Jan 2003 20:25:27 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 21 Jan 2003 20:25:21 +0000 Received: from vscan-a.ucl.ac.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Tue, 21 Jan 2003 20:21:45 +0000 Received: from dns.nexthop.com ([64.211.218.216] helo=presque.djinesys.com) by vscan-a.ucl.ac.uk with esmtp (Exim 3.36 #1) id 18b4tt-0000jF-00 for idmr@cs.ucl.ac.uk; Tue, 21 Jan 2003 20:21:38 +0000 Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0LKLVV92264 for idmr@cs.ucl.ac.uk; Tue, 21 Jan 2003 15:21:31 -0500 (EST) (envelope-from dchopra@dchopra.nexthop.com) Received: from dchopra.nexthop.com (dchopra.nexthop.com [64.211.218.117]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h0LKLRC92257 for ; Tue, 21 Jan 2003 15:21:27 -0500 (EST) (envelope-from dchopra@dchopra.nexthop.com) Received: from localhost (localhost [[UNIX: localhost]]) by dchopra.nexthop.com (8.11.3/8.11.3) with ESMTP id h0LKLRC23522 for ; Tue, 21 Jan 2003 15:21:27 -0500 (EST) Date: Tue, 21 Jan 2003 15:21:27 -0500 (EST) From: Disha Chopra To: idmr Subject: IGMPv3 querier to non-querier transition Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 X-UCL-MailScanner: Found to be clean Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk RFC 2236(Section 3) states that " When a Querier receives a Leave Group message for a group that has group members on the reception interface, it sends [Last Member Query Count] Group-Specific Queries every [Last Member Query Interval] to the group being left. These Group-Specific Queries have their Max Response time set to [Last Member Query Interval]. If no Reports are received after the response time of the last query expires, the routers assume that the group has no local members, as above. Any Querier to non-Querier transition is ignored during this time; the same router keeps sending the Group-Specific Queries. " What should be IGMPv3 behavior in a similar case where the querier is sending out Q(G) / Q(G,S) during [Last Member Query Time] and receives a query that would cause it to transition to the non-querier state. Should the transition be ignored in this case (as in IGMPv2)? TIA, -Disha