From owner-idmr@cs.ucl.ac.uk Tue Apr 2 18:46:14 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 SAA08531 for ; Tue, 2 Apr 2002 18:46:13 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 3 Apr 2002 00:14:26 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 2 Apr 2002 23:54:40 +0100 Received: from mpfg.attlabs.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 2 Apr 2002 23:50:32 +0100 Received: from stash.attlabs.att.com (localhost [127.0.0.1]) by stash.attlabs.att.com (8.12.2/8.12.2) with ESMTP id g32Mo9I2044819; Tue, 2 Apr 2002 14:50:09 -0800 (PST) (envelope-from fenner@stash.attlabs.att.com) Received: (from fenner@localhost) by stash.attlabs.att.com (8.12.2/8.12.2/Submit) id g32Mo757044817; Tue, 2 Apr 2002 14:50:07 -0800 (PST) Date: Tue, 2 Apr 2002 14:50:07 -0800 (PST) Message-Id: <200204022250.g32Mo757044817@stash.attlabs.att.com> To: routing-discussion@ietf.org From: Bill Fenner Subject: routing-discussion mailing list resurrected Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Dear Routing Area participants, Alex and I have resurrected the routing-discussion mailing list, routing-discussion@ietf.org (routing-discussion-request@ietf.org to subscribe, or https://www1.ietf.org/mailman/listinfo/routing-discussion). This list is intended for use for general routing area issues, especially routing-related items that cross multiple working groups or do not fall specifically within a given group's charter. It will also be used for cross-area coordination of routing issues. Please sign up for the list if you are interested. Thanks, Bill and Alex. From owner-idmr@cs.ucl.ac.uk Thu Apr 11 21:36:42 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 VAA26203 for ; Thu, 11 Apr 2002 21:36:41 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 12 Apr 2002 02:07:10 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 12 Apr 2002 02:07:03 +0100 Received: from system149.nexsi.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 12 Apr 2002 01:53:54 +0100 Received: from khonsu.Winnet.NEXSI.NET (khonsu.winnet.nexsi.net [192.168.104.132]) by chrome.nexsi.com (Postfix) with ESMTP id 0809FF02E; Thu, 11 Apr 2002 17:53:44 -0700 (PDT) Date: Thu, 11 Apr 2002 17:49:54 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.60c) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <190198984754.20020411174954@nexsi.com> To: idmr@cs.ucl.ac.uk Cc: Bill Fenner , Toerless Eckert , iwu@cisco.com Subject: Request for review of draft-wu-rgmp-01.txt MIME-Version: 1.0 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, The IESG received a request to publish draft-wu-rgmp-01.txt as an Informational RFC. While considering this request, it was identified that the subject of the draft may overlap with some work done by the IDMR WG. The ADs would like to ask the WG to review this I-D and provide comments on it by April 26th. Following are the types of feedback we're looking for: 1. Technical quality and usefulness of this work. 2. Whether the WG considers this I-D an end-run around the WG's efforts. 3. Whether this document should be published as an Informational RFC. Please note that the draft describes a proprietary protocol, which has been implemented and deployed, and the authors are interested in keeping the protocol operation as described. Also, be advised that we have been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. The authors have been asked to follow the procedure and file an official IPR disclosure with the IETF executive director. Thank you Alex & Bill IETF Routing Area Directors From owner-idmr@cs.ucl.ac.uk Thu Apr 18 05:26:23 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 FAA29784 for ; Thu, 18 Apr 2002 05:26:23 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 18 Apr 2002 09:52:21 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 18 Apr 2002 09:52:14 +0100 Received: from 202.108.35.232 by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 18 Apr 2002 09:47:43 +0100 Received: (qmail 9389 invoked by uid 99); 18 Apr 2002 08:37:59 -0000 Message-ID: <20020418083759.9387.qmail@sina.com> From: yftu To: idmr@cs.ucl.ac.uk Subject: dvmrp in switch MIME-Version: 1.0 Date: Thu, 18 Apr 2002 16:37:44 +0800 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi,all I have two questions about dmvrp when developing dvmrp in switch. <1>、when a multicast trffic packet received from upstream interface, if another port which is in the same VLAN of receiving port and it has a host wanting to recieve that multicast traffic packet, then how can switch forward the multicast traffic packet from the receiving port to the port which has a receiving host? <2>、If one port in the non-designated forwarding interface has a group receiving host, then how can switch forward the multicast traffic packet from designated forwarder to the the port in the non-designated forwarding interface? ______________________________________ =================================================================== 新浪免费电子邮箱 (http://mail.sina.com.cn) 新浪分类信息：二手市场走一走，该出手时就出手！ (http://classad.sina.com.cn/2shou/) From owner-idmr@cs.ucl.ac.uk Mon Apr 22 16:40:31 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 QAA12147 for ; Mon, 22 Apr 2002 16:40:30 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 22 Apr 2002 21:03:58 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Apr 2002 21:03:52 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 22 Apr 2002 20:59:16 +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 5F24B1E0B1; Mon, 22 Apr 2002 15:58:59 -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 PAA18335; Mon, 22 Apr 2002 15:58:58 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA19093; Mon, 22 Apr 2002 12:58:57 -0700 (PDT) Message-Id: <200204221958.MAA19093@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idmr@cs.ucl.ac.uk Subject: Re: Request for review of draft-wu-rgmp-01.txt Cc: zinin@nexsi.com, eckert@cisco.com, iwu@cisco.com Date: Mon, 22 Apr 2002 12:58:57 -0700 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk [WG participant hat firmly planted on head] When I first heard of RGMP, I wondered why IEEE 802.1p's GMRP did not suffice. RGMP does use IP multicast addresses, instead of ethernet multicast addresses, but there may be little benefit from that because routers aren't allowed to send LEAVE messages for groups that overlap with other groups that the router does want traffic from. GMRP also handles multiple switches gracefully, etc, something that's not completely handled in RGMP. I'd like to see the spec discuss why GMRP is not sufficient and why RGMP is better. On the topic of the spec itself, I think that it should admit that it's PIM-specific, instead of saying that it is general and then saying that you could maybe use non-PIM mechanisms if you felt like it. It doesn't even suggest using multicast router discovery for discovering multicast routers, instead saying to use PIM protocol messages. I think it's a shame that RGMP continues the 224.0.0/24 problem, but since we're not allowed to suggest protocol changes, such is life. Hardwiring 224.0.1.39 and .40 is also unfortunate; that's a Cisco protocol that a given network might not be running. RGMP happened to pick IGMP type numbers out of the space that's reserved for experimental usage. I guess that's OK, except that collisions might occur and presumably fairly unpredictable behavior will result. However, again, since we're not allowed to do protocol changes, there's nothing for us to do here except live with it. Bill From owner-idmr@cs.ucl.ac.uk Sat Apr 27 11:36:07 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 LAA16978 for ; Sat, 27 Apr 2002 11:36:06 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sat, 27 Apr 2002 15:02:17 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 27 Apr 2002 02:04:17 +0100 Received: from possum.icir.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 27 Apr 2002 01:59:36 +0100 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.11.6/8.11.3) with ESMTP id g3R0xX323412; Fri, 26 Apr 2002 17:59:34 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200204270059.g3R0xX323412@possum.icir.org> To: Alex Zinin cc: idmr@cs.ucl.ac.uk, Bill Fenner , Toerless Eckert , iwu@cisco.com, magma@ietf.org Subject: Re: Request for review of draft-wu-rgmp-01.txt In-Reply-To: Message from Alex Zinin of "Thu, 11 Apr 2002 17:49:54 PDT." <190198984754.20020411174954@nexsi.com> Date: Fri, 26 Apr 2002 17:59:33 -0700 From: Pavlin Radoslavov Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk (CC to magma@ietf.org as well because some comments have been sent to that list instead) > The IESG received a request to publish draft-wu-rgmp-01.txt > as an Informational RFC. While considering this request, > it was identified that the subject of the draft may overlap > with some work done by the IDMR WG. > > The ADs would like to ask the WG to review this I-D and > provide comments on it by April 26th. Following are the types > of feedback we're looking for: > > 1. Technical quality and usefulness of this work. > > 2. Whether the WG considers this I-D an end-run > around the WG's efforts. > > 3. Whether this document should be published as an > Informational RFC. > > Please note that the draft describes a proprietary protocol, > which has been implemented and deployed, and the authors are > interested in keeping the protocol operation as described. > > Also, be advised that we have been notified of intellectual > property rights claimed in regard to some or all of > the specification contained in this document. The authors > have been asked to follow the procedure and file an official > IPR disclosure with the IETF executive director. Two technical comments from me: * Why IPv4-specific? (Though I may be missing some IPv6 solution that does that already :) E.g., make the Group Address 32 bits for IPv4, and 128 bits for IPv6. Then add a sentence that the address family of Group Address (and therefore its size resp.) must match the address family of the IP message that carries it. In addition, use "MLD/IGMP" instead of "IGMP", and specify the corresponding IPv6 mcast group addresses mentioned in the draft. * What about SSM? There was no Source Address in the message format, so is RGMP "approximating" (S,G) with (*,G) by considering the Group Address only? E.g., you can add an optional "Source Address" right after "Group Address". Because the message length is fixed, if there are 32 bits/128 of data (for IPv4/IPv6 resp.) after "Group Address", that extra data would be "Source Address". Note that this solution should be compatable with implementation that use the current format. Alternatively, you can specify different message types that carry a Source Address as well. Thanks, Pavlin From owner-idmr@cs.ucl.ac.uk Mon Apr 29 09:34:57 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 JAA05966 for ; Mon, 29 Apr 2002 09:34:57 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 29 Apr 2002 13:27:39 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 29 Apr 2002 12:58:06 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 29 Apr 2002 12:53:06 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24944; Mon, 29 Apr 2002 07:53:01 -0400 (EDT) Message-Id: <200204291153.HAA24944@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-v3-10.txt,.ps Date: Mon, 29 Apr 2002 07:53:01 -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 : Internet Group Management Protocol, Version 3 Author(s) : B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan Filename : draft-ietf-idmr-igmp-v3-10.txt,.ps Pages : 52 Date : 26-Apr-02 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-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-v3-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-v3-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: <20020426140948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-igmp-v3-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-igmp-v3-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020426140948.I-D@ietf.org> --OtherAccess-- --NextPart--