From owner-idmr@cs.ucl.ac.uk Thu Mar 1 11:53:47 2001 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 LAA10397 for ; Thu, 1 Mar 2001 11:53:46 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 1 Mar 2001 15:04:50 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Mar 2001 15:04:42 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 1 Mar 2001 15:04:50 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id QAA10055 for ; Thu, 1 Mar 2001 16:04:49 +0100 (MET) Message-ID: <3A9E6511.BE603C65@irisa.fr> Date: Thu, 01 Mar 2001 16:04:49 +0100 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: IGMP 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, just a simple question IGMP messages are encapsulated in IPv4 with an IP protocol number of 2. what is the number 2 ; is it that mean the sending and recieving mode or what? thanx From owner-idmr@cs.ucl.ac.uk Thu Mar 1 11:53:51 2001 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 LAA10408 for ; Thu, 1 Mar 2001 11:53:51 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 1 Mar 2001 16:43:35 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Mar 2001 16:43:28 +0000 Received: from mailhub.fokus.gmd.de by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 1 Mar 2001 16:43:35 +0000 Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA23416; Thu, 1 Mar 2001 17:43:33 +0100 (MET) Received: (from chr@localhost) by benetnash.fokus.gmd.de (8.8.8/8.8.8) id RAA13147; Thu, 1 Mar 2001 17:43:33 +0100 (MET) Date: Thu, 1 Mar 2001 17:43:33 +0100 From: Christoph Reichert To: idmr@cs.ucl.ac.uk Cc: fenner@research.att.com Subject: IGMP Proxying and CBT/Simple Multicast Message-ID: <20010301174333.A13106@fokus.gmd.de> 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 Hi, I am new to this list and have a few questions: a) IGMP-Proxying (draft-fenner-igmp-proxy-03.txt) claims to be useful only in "certain topologies" (networks with a single border router, right ?). But when the term "root" is replaced with "core", and "upstream interface" is replaced with "RPF checked" (towards the core), then, in principal, IGMP-Proxying will create a shared tree centered around the core. Why is IGMP-Proxying not used to setup shared trees ? b) Why is simple multicast scheme (draft-perlman-simple-multicast-03.txt) not a great success ? :-) To me, it seems to solve all multicast problems at once (address allocation, core discovery etc.) chris From owner-idmr@cs.ucl.ac.uk Thu Mar 1 16:35:51 2001 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 QAA24545 for ; Thu, 1 Mar 2001 16:35:50 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 1 Mar 2001 21:03:29 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Mar 2001 21:03:22 +0000 Received: from mailhub.fokus.gmd.de by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 1 Mar 2001 21:03:29 +0000 Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id WAA18009; Thu, 1 Mar 2001 22:03:27 +0100 (MET) Received: (from chr@localhost) by benetnash.fokus.gmd.de (8.8.8/8.8.8) id WAA13701; Thu, 1 Mar 2001 22:03:27 +0100 (MET) Date: Thu, 1 Mar 2001 22:03:27 +0100 From: Christoph Reichert To: Radia Perlman - Boston Center for Networking Cc: idmr@cs.ucl.ac.uk, fenner@research.att.com Subject: Re: IGMP Proxying and CBT/Simple Multicast Message-ID: <20010301220327.A13633@fokus.gmd.de> References: <200103011955.OAA02401@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103011955.OAA02401@bcn.East.Sun.COM>; from Radia.Perlman@Sun.COM on Thu, Mar 01, 2001 at 02:55:38PM -0500 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk On Thu, Mar 01, 2001 at 02:55:38PM -0500, Radia Perlman - Boston Center for Networking wrote: [...] > or not. Bidirectional trees (which Simple Multicast > advocated) would make multi-sender applications > more efficient, and perhaps can be explored at some point in the future, > but the notion of "explicit Root" multicast is the most > critical portion of both proposals, and is becoming a success, I believe. I understand that the "explicit root" identification of a tree is the important thing. This requires IGMP to be extended to carry (R, G) pairs, right ? [...] > I don't think Root centered trees solve ALL possible multicast, by the way. > I still think there's a place for very localized "dense mode" multicast, > to solve things similarly to what's solved in layer 2 multicast...e.g., > finding something. That would not be Root-hosted, but would involve > a small number of more-or-less statically allocated groups, as opposed I understand that (R, G)-trees are for wide-area multicasting, and that "dense-mode" is good for finding local time servers etc. How will hosts differentiate between rooted trees and "dense" trees ? (0.0.0.0, G) versus (R, G) ? > An interesting alternative to this "dense" > form of multicast, though, is "anycast", > which will only find one of the thing you search for, which might be > all you need (unless the one the routing structure finds for you is > broken or something). I understand anycast, and that it is provided natively in IPv6. IPv6 uses a separate portion of IPv6's address space for anycast. How will this be done in IPv4 ? > Radia chris From owner-idmr@cs.ucl.ac.uk Thu Mar 1 16:36:08 2001 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 QAA24562 for ; Thu, 1 Mar 2001 16:36:07 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 1 Mar 2001 19:58:21 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Mar 2001 19:55:37 +0000 Received: from mercury.Sun.COM by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 1 Mar 2001 19:55:45 +0000 Received: from bcn.East.Sun.COM ([129.148.75.4]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24030; Thu, 1 Mar 2001 11:55:40 -0800 (PST) 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 OAA02401; Thu, 1 Mar 2001 14:55:38 -0500 (EST) Message-Id: <200103011955.OAA02401@bcn.East.Sun.COM> Date: Thu, 1 Mar 2001 14:55:38 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: IGMP Proxying and CBT/Simple Multicast To: idmr@cs.ucl.ac.uk, reichert@fokus.gmd.de Cc: fenner@research.att.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IRKM5WBOHh16lT7VwR0MQQ== 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 Re: Christoph Reichert's email: b) Why is simple multicast scheme (draft-perlman-simple-multicast-03.txt) not a great success ? :-) To me, it seems to solve all multicast problems at once (address allocation, core discovery etc.) The main point of Simple Multicast was Root-centered trees, and you're right that it makes address allocation and core discovery simple. It's really quite similar to what's being called "Single Source", in that a group is (R,G) with R (the Root's address) being known as an attribute of the group, and G being assigned by that R, with no need for it to be globally unique. The only real difference between what's called "single source" (which used to be called Express), and what was called "Simple Multicast" is whether the trees are bidirectional or not. Bidirectional trees (which Simple Multicast advocated) would make multi-sender applications more efficient, and perhaps can be explored at some point in the future, but the notion of "explicit Root" multicast is the most critical portion of both proposals, and is becoming a success, I believe. Anything that can be done with bidirectional trees can be done with unidirectional trees by tunneling to the Root and having the Root multicast, or by forming a different tree per sender. Bidirectional trees are only an optimization, and not nearly as important to making the idea of easily, efficiently, and dynamically creating millions of multicast groups with far-flung membership, as the basic idea of getting rid of the need to do global coordination of addresses or needing algorithms to find the Root of the tree to be formed. I don't think Root centered trees solve ALL possible multicast, by the way. I still think there's a place for very localized "dense mode" multicast, to solve things similarly to what's solved in layer 2 multicast...e.g., finding something. That would not be Root-hosted, but would involve a small number of more-or-less statically allocated groups, as opposed to conference calls, or data-pushing web-sites, or in the most touching example someone gave to me...multicasting all church services from all over the world to anyplace in the Internet, which are perfectly suited to Root-hosted multicast. Since "dense-mode" multicast can't be efficient in huge areas, I sympathize with those that say that form of multicast is dangerous to deploy, but I believe such multicast will always be useful if confined to very low bandwidth applications (finding something with probing with very low-frequency), and in a limited region. (I suspect it would be very rare for anyone to configure a firewall to let such traffic pass through, for instance), or even to accept it from a foreign domain. My favorite use of this form of multicast would be finding a nearby directory server, or time server. An interesting alternative to this "dense" form of multicast, though, is "anycast", which will only find one of the thing you search for, which might be all you need (unless the one the routing structure finds for you is broken or something). Radia From owner-idmr@cs.ucl.ac.uk Thu Mar 1 21:12:27 2001 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 VAA01565 for ; Thu, 1 Mar 2001 21:12:26 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 2 Mar 2001 00:54:57 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Mar 2001 21:38:41 +0000 Received: from mercury.Sun.COM by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 1 Mar 2001 21:38:49 +0000 Received: from bcn.East.Sun.COM ([129.148.75.4]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06830; Thu, 1 Mar 2001 13:38:46 -0800 (PST) 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 QAA03133; Thu, 1 Mar 2001 16:38:43 -0500 (EST) Message-Id: <200103012138.QAA03133@bcn.East.Sun.COM> Date: Thu, 1 Mar 2001 16:38:43 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: finding things To: Radia.Perlman@Sun.COM, reichert@fokus.gmd.de Cc: idmr@cs.ucl.ac.uk, fenner@research.att.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zoH5OcikdmxBjj9YYgrzHg== 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 Oh, and another alternative for finding things is using something like Service Location Protocol, which instead of requiring n different multicast or anycast addresses, can get by with a single address, which is the address of a service in which other things can register and get looked up, which is probably a better way of attempting to bootstrap and find things. Radia From owner-idmr@cs.ucl.ac.uk Thu Mar 1 21:14:09 2001 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 VAA01606 for ; Thu, 1 Mar 2001 21:14:08 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 2 Mar 2001 00:54:03 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Mar 2001 21:26:53 +0000 Received: from patan.Sun.COM by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 1 Mar 2001 21:27:01 +0000 Received: from bcn.East.Sun.COM ([129.148.75.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24346; Thu, 1 Mar 2001 13:26:59 -0800 (PST) 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 QAA03084; Thu, 1 Mar 2001 16:26:57 -0500 (EST) Message-Id: <200103012126.QAA03084@bcn.East.Sun.COM> Date: Thu, 1 Mar 2001 16:26:57 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: IGMP Proxying and CBT/Simple Multicast To: Radia.Perlman@Sun.COM, reichert@fokus.gmd.de Cc: idmr@cs.ucl.ac.uk, fenner@research.att.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: oOBuVHbOWsxpeYzo5x22sQ== 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 Re: Christoph's question "how will anycast be provided in IPv4" Anycast in v4 conceptually is simple. It can look like ordinary unicast with a mask of /32, otherwise known as a "host route". The slightly tricky part is allowing endnodes to announce such destinations. And possibly security issues with having someone that isn't providing the service claim to provide the service. Or filling up router tables with bogus destinations (which could be done today if routers aren't using cryptographic integrity checks on their routing messages). Or some routers that might refuse to store /32's. As for how you tell whether you're joining a global G or an (R,G), there are many ways. For instance, the applications that are setting up personalize chat groups, or conference calls, or pushing data bits would call an explicit tree, Root-hosted group, and something that would be advertising a local service would call a service that uses globally allocated Root-less multicast (or anycast). If you really want a single API, then you could signal the dense-mode service by, like you said, using "0" for the Root IP address. As for how to join an 8-byte group...it can be done with extending IGMP, or (my preference for various reasons) having the application send some sort of explicit join message directed to the root R. The reasons it's nice to do it that way rather than a new version of IGMP: a) it's easier to deploy, because it can be done at the application layer rather than needing a new version of the OS (and for instance, SSL was really easy to deploy because it didn't require changes to the OS, whereas IPSec is harder to deploy) b) you can automatically create tunnels, so that an endnode can join or host a group without needing to have the routers nearby be multicast-capable c) if the Root/source is participating in the tree creation, it knows if there are any listeners. WIth an IGMP-based scheme, if there is a high-volume source with no receivers, it will transmit unnecessarily on the first hop. Ross Finlayson recently posted an internet draft discussing automatic tunneling with a particular format known as UMTP. I think there might be other proposals as well floating around. It's hard to keep up with everything. Radia From owner-idmr@cs.ucl.ac.uk Fri Mar 2 03:56:39 2001 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 DAA23801 for ; Fri, 2 Mar 2001 03:56:38 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 2 Mar 2001 07:58:48 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Mar 2001 07:58:40 +0000 Received: from hermes.research.kpn.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 2 Mar 2001 07:58:48 +0000 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01K0PRU71K3C000HCG@research.kpn.com> for idmr@cs.ucl.ac.uk; Fri, 2 Mar 2001 08:58:47 +0100 Received: from david.research.kpn.com (david.research.kpn.com [139.63.194.14]) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) with SMTP id IAA11533; Fri, 02 Mar 2001 08:58:46 +0100 (MET) Received: from L4529 by david.research.kpn.com (SMI-8.6/SMI-SVR4) id IAA00664; Fri, 02 Mar 2001 08:58:45 +0100 Date: Fri, 02 Mar 2001 08:58:45 +0100 From: Wilbert de Graaf Subject: Re: IGMP To: Ali Boudani Cc: idmr@cs.ucl.ac.uk Message-id: <005b01c0a2ee$9b415480$01c63f8b@L4529.research.kpn.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailer: Microsoft Outlook Express 4.72.2106.4 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit >hello, >just a simple question >IGMP messages are encapsulated in IPv4 with an IP protocol number of 2. >what is the number 2 ; >is it that mean the sending and recieving mode or what? The protocol number 2 is assigned to IGMP (rfc1112), and the IP module of the TCP/IP stack uses this number to hand the message to the IGMP module. (That is, to discriminate igmp packets from icmp, tcp, udp, and so on.) Wilbert From owner-idmr@cs.ucl.ac.uk Fri Mar 2 03:59:52 2001 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 DAA23898 for ; Fri, 2 Mar 2001 03:59:52 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 2 Mar 2001 07:29:42 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Mar 2001 07:29:36 +0000 Received: from shuttle.wide.toshiba.co.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 2 Mar 2001 07:29:43 +0000 Received: from localhost ([3ffe:501:100f:10c1:441b:78ed:c813:6d6a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id QAA15690; Fri, 2 Mar 2001 16:29:26 +0900 (JST) Date: Fri, 02 Mar 2001 16:28:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Christoph Reichert Cc: Radia Perlman - Boston Center for Networking , idmr@cs.ucl.ac.uk, fenner@research.att.com Subject: Re: IGMP Proxying and CBT/Simple Multicast In-Reply-To: In your message of "Thu, 1 Mar 2001 22:03:27 +0100" <20010301220327.A13633@fokus.gmd.de> References: <200103011955.OAA02401@bcn.East.Sun.COM> <20010301220327.A13633@fokus.gmd.de> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 26 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >>>>> On Thu, 1 Mar 2001 22:03:27 +0100, >>>>> Christoph Reichert said: >> An interesting alternative to this "dense" >> form of multicast, though, is "anycast", >> which will only find one of the thing you search for, which might be >> all you need (unless the one the routing structure finds for you is >> broken or something). > I understand anycast, and that it is provided natively in IPv6. IPv6 > uses a separate portion of IPv6's address space for anycast. No, that's not true. Section 2.6 of RFC2373 says Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats. Thus, anycast addresses are syntactically indistinguishable from unicast addresses. When a unicast address is assigned to more than one interface, thus turning it into an anycast address, the nodes to which the address is assigned must be explicitly configured to know that it is an anycast address. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-idmr@cs.ucl.ac.uk Fri Mar 2 13:33:12 2001 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 NAA11358 for ; Fri, 2 Mar 2001 13:33:11 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 2 Mar 2001 16:40:05 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Mar 2001 16:39:59 +0000 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 2 Mar 2001 16:40:06 +0000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 49A984CE29; Fri, 2 Mar 2001 11:40:06 -0500 (EST) 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 LAA11591; Fri, 2 Mar 2001 11:40:05 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA24357; Fri, 2 Mar 2001 08:40:05 -0800 (PST) Message-Id: <200103021640.IAA24357@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: reichert@fokus.gmd.de Subject: Re: IGMP Proxying and CBT/Simple Multicast Cc: idmr@cs.ucl.ac.uk Date: Fri, 2 Mar 2001 08:40:05 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >a) IGMP-Proxying (draft-fenner-igmp-proxy-03.txt) claims to be useful > only in "certain topologies" (networks with a single border > router, right ?). > > But when the term "root" is replaced with "core", and "upstream > interface" is replaced with "RPF checked" (towards the core), > then, in principal, IGMP-Proxying will create a shared tree centered > around the core. > > Why is IGMP-Proxying not used to setup shared trees ? IGMP Proxying doesn't use routing to determine where to forward the membership information; it uses static configuration. Static configuration doesn't scale very well, and doesn't allow for redundancy. Also, with IGMP Proxying, all traffic always flows towards the root, which leads to e.g. traffic concentration. Bill From owner-idmr@cs.ucl.ac.uk Mon Mar 5 12:16:14 2001 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 MAA22013 for ; Mon, 5 Mar 2001 12:16:13 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 5 Mar 2001 13:54:01 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 5 Mar 2001 11:44:45 +0000 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 5 Mar 2001 11:44:52 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11002; Mon, 5 Mar 2001 06:44:51 -0500 (EST) Message-Id: <200103051144.GAA11002@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-07.txt,.ps Date: Mon, 05 Mar 2001 06:44:51 -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 : Internet Group Management Protocol, Version 3 Author(s) : B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan Filename : draft-ietf-idmr-igmp-v3-07.txt,.ps Pages : 50 Date : 02-Mar-01 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 is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-07.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-v3-07.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-07.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: <20010302132013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-igmp-v3-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-igmp-v3-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302132013.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Tue Mar 6 04:27:16 2001 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 EAA05752 for ; Tue, 6 Mar 2001 04:27:16 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 6 Mar 2001 07:27:43 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Mar 2001 07:27:36 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 6 Mar 2001 07:27:45 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id IAA05331 for ; Tue, 6 Mar 2001 08:27:44 +0100 (MET) Message-ID: <3AA49170.367611B8@irisa.fr> Date: Tue, 06 Mar 2001 08:27:44 +0100 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: express and simple multicast 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 didnt found any rfc or draft describing simple multicast?? is there any??and what is the problem in it if not?? and is express is the same as xcast or it is n older proposition ?? Thanx From owner-idmr@cs.ucl.ac.uk Tue Mar 6 06:23:38 2001 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 GAA06911 for ; Tue, 6 Mar 2001 06:23:37 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 6 Mar 2001 09:55:56 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Mar 2001 09:55:49 +0000 Received: from 212.150.220.34 by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 6 Mar 2001 09:55:54 +0000 Received: by davis.bandwiz.com with Internet Mail Service (5.5.2653.19) id <167M4YBN>; Tue, 6 Mar 2001 11:56:41 +0200 Message-ID: <288F58308EFBD411B896006008F5DCAA049501@davis.bandwiz.com> From: Doron Rajwan To: "'Ali Boudani'" Cc: idmr@cs.ucl.ac.uk Subject: RE: express and simple multicast Date: Tue, 6 Mar 2001 11:56:40 +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 Simple Multicast was only a draft, not an RFC. Drafts are discarded after 6 months. You can find it here: http://www.dante.net/mbone/refs/draft-perlman-simple-multicast-03.txt Doron. > I didnt found any rfc or draft describing simple multicast?? > is there any??and what is the problem in it if not?? From owner-idmr@cs.ucl.ac.uk Tue Mar 6 08:30:13 2001 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 IAA11062 for ; Tue, 6 Mar 2001 08:30:12 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 6 Mar 2001 12:27:20 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Mar 2001 12:27:14 +0000 Received: from ids2.idsonline.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 6 Mar 2001 12:27:22 +0000 Received: from 21rst-century.com (reston-gnap-ip-216012-58.dynamic.ziplink.net [216.8.12.58]) by ids2.idsonline.com (8.11.1/8.11.1) with ESMTP id f26DuGe00045; Tue, 6 Mar 2001 08:56:17 -0500 Message-ID: <3AA4D7F9.B784155E@21rst-century.com> Date: Tue, 06 Mar 2001 07:28:41 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Ali Boudani CC: idmr@cs.ucl.ac.uk Subject: Re: express and simple multicast References: <3AA49170.367611B8@irisa.fr> 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; Simple and express were subsumed in SSM (not XCast). I believe all of the old drafts are dead now. SSM has a number of active drafts and is in the new PIM-SM-v2 spec. I believe that both predate XCast. Of related interest are the auto-tunneling multicast drafts : http://www.ietf.org/internet-drafts/draft-finlayson-umtp-05.txt http://www.ietf.org/internet-drafts/draft-finlayson-mboned-autotunneling-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-00.txt Ali Boudani wrote: > > Hello, > I didnt found any rfc or draft describing simple multicast?? > is there any??and what is the problem in it if not?? > > and is express is the same as xcast or it is n older proposition ?? > > Thanx -- Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From owner-idmr@cs.ucl.ac.uk Tue Mar 6 08:30:52 2001 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 IAA11089 for ; Tue, 6 Mar 2001 08:30:51 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 6 Mar 2001 11:56:24 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 6 Mar 2001 11:56:17 +0000 Received: from mailhub.fokus.gmd.de by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 6 Mar 2001 11:56:25 +0000 Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id MAA10570; Tue, 6 Mar 2001 12:56:22 +0100 (MET) Received: (from chr@localhost) by benetnash.fokus.gmd.de (8.8.8/8.8.8) id MAA05245; Tue, 6 Mar 2001 12:56:21 +0100 (MET) Date: Tue, 6 Mar 2001 12:56:21 +0100 From: Christoph Reichert To: "'Ali Boudani'" Cc: idmr@cs.ucl.ac.uk Subject: Re: express and simple multicast Message-ID: <20010306125621.A5233@fokus.gmd.de> References: <288F58308EFBD411B896006008F5DCAA049501@davis.bandwiz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <288F58308EFBD411B896006008F5DCAA049501@davis.bandwiz.com>; from Doron@bandwiz.com on Tue, Mar 06, 2001 at 11:56:40AM +0200 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk EXPRESS is described in a SIGCOMM paper. Holbrook, Cheriton, "IP Multicast Channels: EXPRESS Support for Large-scale Single-source Applications" chris On Tue, Mar 06, 2001 at 11:56:40AM +0200, Doron Rajwan wrote: > > Simple Multicast was only a draft, not an RFC. Drafts are discarded after 6 > months. > > You can find it here: > http://www.dante.net/mbone/refs/draft-perlman-simple-multicast-03.txt > > Doron. > > > > I didnt found any rfc or draft describing simple multicast?? > > is there any??and what is the problem in it if not?? From owner-idmr@cs.ucl.ac.uk Wed Mar 7 07:12:59 2001 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 HAA00287 for ; Wed, 7 Mar 2001 07:12:58 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 11:10:44 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 11:10:40 +0000 Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 11:10:48 +0000 To: Ali Boudani cc: idmr@cs.ucl.ac.uk, ietf@ietf.org Subject: Re: Multicast In-reply-to: Your message of "Wed, 07 Mar 2001 11:35:46 +0100." <3AA60F02.2FE41239@irisa.fr> Date: Wed, 07 Mar 2001 11:10:46 +0000 Message-ID: <8118.983963446@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk In message <3AA60F02.2FE41239@irisa.fr>, Ali Boudani typed: >>Isnt SSM just a particular case of PIM?? the right place for this discussion is SSM , SSM is a subset of PIM SM, roughly, and relies (sort of) on IGMPv3 (at least on a subset of equiv. functionality). >>It is the specifications for just specific sources but they arent adressing >>the multicast in general. >>am I right ? not quite - i dont think the whole IETF list is the right place for this one - see http://www.ietf.org/html.charters/ssm-charter.html i think since the ssm work is close to done, we'll see work resume on bidir (s/cbt/pim-bidir:-) soon , and similalrly in the RMT work see http://www.ietf.org/html.charters/rmt-charter.html a lot of building blocks are close to done (prob. about a year) then we'll see some work on multiple source (the latent demand for multiple source applications is imho underestimated, but until we can fix the more immediate problems with supporting 1-many, we can't really expect people to deploy many-to-many extensively- other problems being addressed are concerned with having good solutions for multicast security (see http://www.ietf.org/html.charters/msec-charter.html and for many-to-many, for congestion control (to meet transport area requirements).... i think (but of course i am usually wrong) that we may see progress on this in 2002... >>Jon Crowcroft wrote: >> >>> In message <3AA60C4B.58AA4CFC@irisa.fr>, Ali Boudani typed: >>> >>> >>First the CBT protocol was created to use shared tree solutions because >>> >>DVMRP and the other dense mode protocols werent scalable. there were >>> >>many problems with CBT (which is bidirectional) so PIM-SM was cretaed >>> >>which provide some switching (between shared tree and source tree). and >>> >>after that there is some discussions about the bidirectional PIM, which >>> >>is like CBT. >>> >>Are we in circle here or what ?? >>> >>> not really. the mainstream current multicast action is concentrating on >>> single source (and on single source reliable multicast transport) >>> since we didn't feel we understood all the complications of ANY of the >>> multiple source schemes for IP or reliable....(e.g. interdomain >>> routing, and multiple source semantics for reliable) - >>> >>> there were'nt really "problems" with CBT apart from we never managed >>> to get a router vendor to committ to an implmenetation which we could >>> deploy and learn from - tony ballardie got a lot of the details out, >>> but the two implementaions i know of never saw light of day.....bidir >>> pim is cool, bgmp is cool, but action in implementation/details/spec >>> is waiting on getting the PIM SSM stuff completely shaken down.... >>> >>> its all part of a good learning experience and (as any good s/w >>> engineer might say) its the norm:-) >>> >> >>> >>> cheers >>> >>> jon >> cheers jon From owner-idmr@cs.ucl.ac.uk Wed Mar 7 07:13:08 2001 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 HAA00298 for ; Wed, 7 Mar 2001 07:13:07 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 10:24:10 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 10:24:03 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 10:24:11 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id LAA11633; Wed, 7 Mar 2001 11:24:11 +0100 (MET) Message-ID: <3AA60C4B.58AA4CFC@irisa.fr> Date: Wed, 07 Mar 2001 11:24:11 +0100 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, ietf@ietf.org Subject: Multicast 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, First the CBT protocol was created to use shared tree solutions because DVMRP and the other dense mode protocols werent scalable. there were many problems with CBT (which is bidirectional) so PIM-SM was cretaed which provide some switching (between shared tree and source tree). and after that there is some discussions about the bidirectional PIM, which is like CBT. Are we in circle here or what ?? From owner-idmr@cs.ucl.ac.uk Wed Mar 7 07:13:55 2001 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 HAA00313 for ; Wed, 7 Mar 2001 07:13:54 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 10:35:45 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 10:35:38 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 10:35:46 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id LAA12946; Wed, 7 Mar 2001 11:35:46 +0100 (MET) Message-ID: <3AA60F02.2FE41239@irisa.fr> Date: Wed, 07 Mar 2001 11:35:46 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: Jon Crowcroft CC: idmr@cs.ucl.ac.uk, ietf@ietf.org Subject: Re: Multicast References: <7882.983961040@cs.ucl.ac.uk> 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 again, Isnt SSM just a particular case of PIM?? It is the specifications for just specific sources but they arent adressing the multicast in general. am I right ? Jon Crowcroft wrote: > In message <3AA60C4B.58AA4CFC@irisa.fr>, Ali Boudani typed: > > >>First the CBT protocol was created to use shared tree solutions because > >>DVMRP and the other dense mode protocols werent scalable. there were > >>many problems with CBT (which is bidirectional) so PIM-SM was cretaed > >>which provide some switching (between shared tree and source tree). and > >>after that there is some discussions about the bidirectional PIM, which > >>is like CBT. > >>Are we in circle here or what ?? > > not really. the mainstream current multicast action is concentrating on > single source (and on single source reliable multicast transport) > since we didn't feel we understood all the complications of ANY of the > multiple source schemes for IP or reliable....(e.g. interdomain > routing, and multiple source semantics for reliable) - > > there were'nt really "problems" with CBT apart from we never managed > to get a router vendor to committ to an implmenetation which we could > deploy and learn from - tony ballardie got a lot of the details out, > but the two implementaions i know of never saw light of day.....bidir > pim is cool, bgmp is cool, but action in implementation/details/spec > is waiting on getting the PIM SSM stuff completely shaken down.... > > its all part of a good learning experience and (as any good s/w > engineer might say) its the norm:-) > >> > > cheers > > jon From owner-idmr@cs.ucl.ac.uk Wed Mar 7 07:14:03 2001 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 HAA00325 for ; Wed, 7 Mar 2001 07:14:03 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 10:30:39 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 10:30:35 +0000 Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 10:30:42 +0000 To: Ali Boudani cc: idmr@cs.ucl.ac.uk, ietf@ietf.org Subject: Re: Multicast In-reply-to: Your message of "Wed, 07 Mar 2001 11:24:11 +0100." <3AA60C4B.58AA4CFC@irisa.fr> Date: Wed, 07 Mar 2001 10:30:40 +0000 Message-ID: <7882.983961040@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk In message <3AA60C4B.58AA4CFC@irisa.fr>, Ali Boudani typed: >>First the CBT protocol was created to use shared tree solutions because >>DVMRP and the other dense mode protocols werent scalable. there were >>many problems with CBT (which is bidirectional) so PIM-SM was cretaed >>which provide some switching (between shared tree and source tree). and >>after that there is some discussions about the bidirectional PIM, which >>is like CBT. >>Are we in circle here or what ?? not really. the mainstream current multicast action is concentrating on single source (and on single source reliable multicast transport) since we didn't feel we understood all the complications of ANY of the multiple source schemes for IP or reliable....(e.g. interdomain routing, and multiple source semantics for reliable) - there were'nt really "problems" with CBT apart from we never managed to get a router vendor to committ to an implmenetation which we could deploy and learn from - tony ballardie got a lot of the details out, but the two implementaions i know of never saw light of day.....bidir pim is cool, bgmp is cool, but action in implementation/details/spec is waiting on getting the PIM SSM stuff completely shaken down.... its all part of a good learning experience and (as any good s/w engineer might say) its the norm:-) >> cheers jon From owner-idmr@cs.ucl.ac.uk Wed Mar 7 09:46:00 2001 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 JAA06047 for ; Wed, 7 Mar 2001 09:45:59 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 12:37:39 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 12:37:32 +0000 Received: from necom830.hpcl.titech.ac.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 12:37:30 +0000 From: Masataka Ohta Message-Id: <200103071226.VAA05030@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA05030; Wed, 7 Mar 2001 21:25:45 +0859 Subject: Re: Multicast In-Reply-To: <3AA60C4B.58AA4CFC@irisa.fr> from Ali Boudani at "Mar 7, 2001 11:24:11 am" To: Ali Boudani Date: Wed, 7 Mar 2001 21:25:44 +0859 () CC: idmr@cs.ucl.ac.uk, ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Ali; > Hello, > First the CBT protocol was created to use shared tree solutions because > DVMRP and the other dense mode protocols werent scalable. there were > many problems with CBT (which is bidirectional) so PIM-SM was cretaed > which provide some switching (between shared tree and source tree). and > after that there is some discussions about the bidirectional PIM, which > is like CBT. > Are we in circle here or what ?? If there were some progress somewhere, you might be able say "circle". But, in IETF, no proposal makes any sense that there is absolutely no movement. Here, you are on a point behind a start line. SSM is no different. The real difficulty of multicast is in the various relationships to resource reservation. I've heard that ISPs, which were expecting to receive special charge for multicast service, are now bitterly recognizing one aspect of the relationship that, even if multicast is free, customers do not bother to use multicast if they pay flat rate to receive any amount of unicast traffic Those serving the customers simply increase the number of capacity of servers, of course. Masataka Ohta From owner-idmr@cs.ucl.ac.uk Wed Mar 7 09:46:10 2001 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 JAA06066 for ; Wed, 7 Mar 2001 09:46:06 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 14:34:17 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 14:34:12 +0000 Received: from necom830.hpcl.titech.ac.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 14:34:15 +0000 From: Masataka Ohta Message-Id: <200103071429.XAA05573@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA05573; Wed, 7 Mar 2001 23:29:32 +0900 Subject: Re: Multicast In-Reply-To: <3AA64095.1B8997E7@irisa.fr> from Ali Boudani at "Mar 7, 2001 03:07:17 pm" To: Ali Boudani Date: Wed, 7 Mar 2001 23:29:31 +0859 () CC: idmr@cs.ucl.ac.uk, ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Ali; > are you suggesting that there is no multicast problem :-) There is none remaining. > and that is the ordinary unicast problems related to ressource reservation > and by expanding the capacity of servers and also of the link bandwidth that > problem will be solved. :-) I'm saying it was simple and easy to solve the resource reservation and multicast problems at once (www.real-internet.org). You can see that RSVP has a fatal flaw trying to accomodate all the possible and impossible multicast protocols. Another interesting aspect of the relationship is that each multicast group consumes a precious resource of routing table entry that multicast is a resource reserving communication. Masataka Ohta From owner-idmr@cs.ucl.ac.uk Wed Mar 7 09:46:16 2001 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 JAA06084 for ; Wed, 7 Mar 2001 09:46:15 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 14:11:15 +0000 Received: from haig.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 14:11:07 +0000 Received: from sky.irisa.fr by haig.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 14:11:07 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id PAA04884; Wed, 7 Mar 2001 15:07:17 +0100 (MET) Message-ID: <3AA64095.1B8997E7@irisa.fr> Date: Wed, 07 Mar 2001 15:07:17 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: Masataka Ohta CC: idmr@cs.ucl.ac.uk, ietf@ietf.org Subject: Re: Multicast References: <200103071226.VAA05030@necom830.hpcl.titech.ac.jp> 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, are you suggesting that there is no multicast problem :-) and that is the ordinary unicast problems related to ressource reservation and by expanding the capacity of servers and also of the link bandwidth that problem will be solved. :-) thanx Masataka Ohta wrote: > Ali; > > > Hello, > > First the CBT protocol was created to use shared tree solutions because > > DVMRP and the other dense mode protocols werent scalable. there were > > many problems with CBT (which is bidirectional) so PIM-SM was cretaed > > which provide some switching (between shared tree and source tree). and > > after that there is some discussions about the bidirectional PIM, which > > is like CBT. > > Are we in circle here or what ?? > > If there were some progress somewhere, you might be able say "circle". > > But, in IETF, no proposal makes any sense that there is absolutely > no movement. > > Here, you are on a point behind a start line. > > SSM is no different. > > The real difficulty of multicast is in the various relationships > to resource reservation. > > I've heard that ISPs, which were expecting to receive special charge > for multicast service, are now bitterly recognizing one aspect of the > relationship that, even if multicast is free, customers do not bother > to use multicast if they pay flat rate to receive any amount of unicast > traffic > > Those serving the customers simply increase the number of capacity > of servers, of course. > > Masataka Ohta From owner-idmr@cs.ucl.ac.uk Wed Mar 7 12:25:43 2001 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 MAA13035 for ; Wed, 7 Mar 2001 12:25:42 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 16:24:00 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 16:23:52 +0000 Received: from necom830.hpcl.titech.ac.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 16:23:46 +0000 From: Masataka Ohta Message-Id: <200103071619.BAA06002@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA06002; Thu, 8 Mar 2001 01:19:17 +0900 Subject: Re: Multicast In-Reply-To: <3AA65C7D.A63C2CD1@koganei.wide.ad.jp> from Katsushi Kobayashi at "Mar 8, 2001 01:06:21 am" To: Katsushi Kobayashi Date: Thu, 8 Mar 2001 01:19:16 +0859 () CC: Ali Boudani , idmr@cs.ucl.ac.uk, ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Kobayashi san; > ISP talking with you intend to charge whether sender, reciever > or both ?　I guess some ISP would not like to start multicast > service, even if subscriber request it. They might sometimes > say as an excuse what you heard. > > I think there are a lot of way to make a special charge for special > service without resource reservation protocol as you think, even > if you say "It is not scalable way" :) You completely miss the point. Because best effort service is flat rated, receivers are not motivated to use multicast. Senders learned to have more servers. See my column article on the most recent IPSJ magazine for details. That's all. Masataka Ohta From owner-idmr@cs.ucl.ac.uk Wed Mar 7 12:29:45 2001 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 MAA13150 for ; Wed, 7 Mar 2001 12:29:44 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 15:45:44 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 15:45:25 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 15:45:32 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id QAA15145; Wed, 7 Mar 2001 16:45:28 +0100 (MET) Message-ID: <3AA65799.894BBA17@irisa.fr> Date: Wed, 07 Mar 2001 16:45:29 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: Masataka Ohta CC: idmr@cs.ucl.ac.uk, ietf@ietf.org Subject: Re: Multicast References: <200103071429.XAA05573@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > > are you suggesting that there is no multicast problem :-) > There is none remaining. Well, what about scalability, and the interoperability with the underlying unicast protocols. and what about the interdomain multicast??? > I'm saying it was simple and easy to solve the resource reservation > and multicast problems at once (www.real-internet.org). Is that the draft :Simple Resource ReSerVation Protocol (SRSVP) (in English) or there is another one?? I didnt found it in the internet-drafts at the IETF !!! thanx From owner-idmr@cs.ucl.ac.uk Wed Mar 7 15:13:48 2001 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 PAA21014 for ; Wed, 7 Mar 2001 15:13:47 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 19:04:13 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 17:28:36 +0000 Received: from sean.ebone.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 17:28:36 +0000 Received: by sean.ebone.net (Postfix, from userid 1113) id 488E08A3; Wed, 7 Mar 2001 18:28:34 +0100 (CET) To: aboudani@irisa.fr, huntting@hunkular.glarp.com Subject: Re: Multicast Cc: idmr@cs.ucl.ac.uk, ietf@ietf.org, mohta@necom830.hpcl.titech.ac.jp Message-Id: <20010307172834.488E08A3@sean.ebone.net> Date: Wed, 7 Mar 2001 18:28:34 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Brad Hunting writes: | It even uses fewer resources for network providers. | | "The real difficulty of multicast" is that it's much more difficult | for ISP's (and presumably router venders) to support than unicast. These two statements are, unfortunately, mutually exclusive. IP multicast does not scale well for S,G state; it may scale OK for *,G for reasonable numbers of groups; it is not known whether it will scale at all for little things like customer support. Several backbones (including Ebone) offer native multicast "for free"; all a customer has to do is configure things up: for source-active/rendezvous: use our (anycast) RP, talk MSDP to us for RPF: use mBGP for joins/prunes: use PIM in sparse mode It's not so difficult to set up, but not many people actually do it. A sister network which has a pretty similar overall architecture to ours offers multicast "for free" with a transmissions cap of a few hundred kbps or so from a customer to the rest of the world through that network. I don't think that this threshold has ever been in the way of anyone so far... Why? Poor client support springs to mind. I've always wanted to have someone throw together a web page that downloads a Java applet equivalent to vic/vat/rat/etc., joins the right group, and puts content into the face of the clicker, perhaps for a fee. However, in the absence of compelling content (sadly we don't have Vint to strip for us :) ), I haven't suggested that this be a priority. Also, not all routers at/near the edge can even do native multicast... Sean. P.S.: A long time ago there was a very interesting discussion (probably on NANOG) involving Vadim Antonov and many others; the argument advanced by Vadim's side (include me here) is, roughly, that if you consider multicast to be a degenerate form of caching, where the cache is purged immediately after servicing the implicit cache requests made by the listeners who have joined below the current router, then native multicast, particularly reliable native multicast, is being approached in fundamentally the wrong fashion. In other words, rolling (maybe short term) content caching into (some) routers is likely to be a more useful generalized service than deploying actual native multicast, all while being able to reuse some join/prune, SA and RPF state handling to optimize the "network-based Content Distribution Network" (to use a set of buzzwords). From owner-idmr@cs.ucl.ac.uk Wed Mar 7 15:13:57 2001 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 PAA21026 for ; Wed, 7 Mar 2001 15:13:56 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 18:59:15 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 16:13:00 +0000 Received: from koganei.wide.ad.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 16:13:07 +0000 Received: from koganei.wide.ad.jp (koganei.wide.ad.jp [202.249.37.254]) by ns.koganei.wide.ad.jp (8.11.1/8.11.1) with ESMTP id f27GCgQ42047; Thu, 8 Mar 2001 01:12:42 +0900 (JST) (envelope-from ikob@koganei.wide.ad.jp) Message-ID: <3AA65C7D.A63C2CD1@koganei.wide.ad.jp> Date: Thu, 08 Mar 2001 01:06:21 +0900 From: Katsushi Kobayashi X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Masataka Ohta CC: Ali Boudani , idmr@cs.ucl.ac.uk, ietf@ietf.org Subject: Re: Multicast References: <200103071226.VAA05030@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Ohta san, ISP talking with you intend to charge whether sender, reciever or both ?　I guess some ISP would not like to start multicast service, even if subscriber request it. They might sometimes say as an excuse what you heard. I think there are a lot of way to make a special charge for special service without resource reservation protocol as you think, even if you say "It is not scalable way" :) Masataka Ohta wrote: > > I've heard that ISPs, which were expecting to receive special charge > for multicast service, are now bitterly recognizing one aspect of the > relationship that, even if multicast is free, customers do not bother > to use multicast if they pay flat rate to receive any amount of unicast > traffic > From owner-idmr@cs.ucl.ac.uk Wed Mar 7 15:14:04 2001 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 PAA21048 for ; Wed, 7 Mar 2001 15:14:02 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 19:04:42 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 17:42:19 +0000 Received: from sean.ebone.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 17:42:24 +0000 Received: by sean.ebone.net (Postfix, from userid 1113) id 41B4F8A3; Wed, 7 Mar 2001 18:42:23 +0100 (CET) To: aboudani@irisa.fr, mohta@necom830.hpcl.titech.ac.jp Subject: Re: Multicast Cc: idmr@cs.ucl.ac.uk, ietf@ietf.org Message-Id: <20010307174223.41B4F8A3@sean.ebone.net> Date: Wed, 7 Mar 2001 18:42:23 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk | Well, what about scalability, and the interoperability with the underlying unicast | protocols. and what about the interdomain multicast??? IDR for multicast is pretty straightforward: 1. discovering sources: SA handling done by MSDP works OK, there are maybe better ways of doing it simple policies are sufficient: i don't want to know about sources going active from your network for some reason, so i'll filter them out. i don't want you to know about my source going active (perhaps because the source isn't paying me) so i won't announce it to you 2. handling joins/prunes: PIM in sparse mode works OK, there are maybe better ways of doing it possibly complicated policies, particularly on joins: i don't want to hear your join to groups whose sources are across the ocean, unless some customer of mine has already joined and is causing the traffic to flow anyway i will happily dump traffic "for free" onto an IX if a paying customer on a router "right beside" the IX (or at the IX) joins a group i will pick up traffic dumped "for free" onto an IX and forestall a join towards the distant source while the traffic is there i do want your customer's joins, but not your peers' joins; those i will drop on the floor 3. handling RPF: mBGP okay, this is the "worst part", since the policy opportunities here are endless. however, what should be done here is mainly forwarding loop avoidance; policy one would want to express here (do not propagate out interface X) should be expressed in some other way -- probably join control, however that ignores some brutal realities about rebuilding trees when lines/routers fail. | Is that the draft :Simple Resource ReSerVation Protocol (SRSVP) (in English) | or there is another one?? | I didnt found it in the internet-drafts at the IETF !!! Good, RSVP for multicast is an insane idea. There is a finite but nearly zero chance that an ISP will ever squeeze more money out of someone by promising them via RSVP that their multicast packets will make it through from source to destination, whether the someone is a source or a listener. However, if you demonstrate compliance with an SLA that works like many unicast ones (x% packet loss, y ms delay, from network edge to network edge), you may be able to charge more for "best efforts" multicast, and pick up customers who are frustrated with RSVP stuff. "Simple" RSVP: say yes always, or say no always. Choose one. Sean. From owner-idmr@cs.ucl.ac.uk Wed Mar 7 15:14:13 2001 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 PAA21059 for ; Wed, 7 Mar 2001 15:14:12 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 19:05:51 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 15:45:05 +0000 Received: from hunkular.glarp.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 15:45:13 +0000 Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.11.1/8.11.1) with ESMTP id f27Fj1O34014; Wed, 7 Mar 2001 08:45:02 -0700 (MST) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200103071545.f27Fj1O34014@hunkular.glarp.com> To: Ali Boudani cc: Masataka Ohta , idmr@cs.ucl.ac.uk, ietf@ietf.org Subject: Re: Multicast In-Reply-To: Your message of "Wed, 07 Mar 2001 15:07:17 +0100." <3AA64095.1B8997E7@irisa.fr> Date: Wed, 07 Mar 2001 08:45:00 -0700 From: Brad Huntting Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk > The real difficulty of multicast is in the various relationships > to resource reservation. This is so completely wrong... Multicast is cheaper than unicast from every resource perspective. It uses fewer network resources for both content providers and consumers. It even uses fewer resources for network providers. "The real difficulty of multicast" is that it's much more difficult for ISP's (and presumably router venders) to support than unicast. brad From owner-idmr@cs.ucl.ac.uk Wed Mar 7 15:51:30 2001 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 PAA22222 for ; Wed, 7 Mar 2001 15:51:29 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 19:05:18 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 17:57:44 +0000 Received: from sean.ebone.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 17:57:52 +0000 Received: by sean.ebone.net (Postfix, from userid 1113) id A813E8A3; Wed, 7 Mar 2001 18:57:50 +0100 (CET) To: ikob@koganei.wide.ad.jp, mohta@necom830.hpcl.titech.ac.jp Subject: Re: Multicast Cc: aboudani@irisa.fr, idmr@cs.ucl.ac.uk, ietf@ietf.org Message-Id: <20010307175750.A813E8A3@sean.ebone.net> Date: Wed, 7 Mar 2001 18:57:50 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Ohta-san: | Because best effort service is flat rated, receivers are not motivated | to use multicast. Senders learned to have more servers. Yes, but some senders would like to send a bit less :-) For instance, some are actually paying based on volume (Mbytes/month), some are paying on peak usage (95th percentile of measured traffic load), and some are paying flat rate available bandwidth. All would like to have more happy eyeballs watching while paying less to send the traffic towards them, and some of these people would not be opposed to using IP multicast. Unfortunately, while it's fun to think about a sender flooding out on a group and paying for the volume only when the group is joined towards, actually implementing this is stuck in the realm of "fun idea" Don't hold your breath. So, I think you're essentially right: if one wants to send a bit less, one pays a unicast-CDN to do very-short-term caching at various points in the network instead. "A bit less" can be significant in the case of streaming content when one considers the number of outbound copies one can save when doing packet-replication or short-term-content-caching here and there in the network. Or at least so many CDN companies argue with varying degrees of success. Sean. CDN: buzzword, "content distribution network". From owner-idmr@cs.ucl.ac.uk Wed Mar 7 15:51:41 2001 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 PAA22234 for ; Wed, 7 Mar 2001 15:51:39 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 19:03:37 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 16:15:37 +0000 Received: from necom830.hpcl.titech.ac.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 16:15:46 +0000 From: Masataka Ohta Message-Id: <200103071603.BAA05974@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA05974; Thu, 8 Mar 2001 01:03:29 +0900 Subject: Re: Multicast In-Reply-To: <3AA65799.894BBA17@irisa.fr> from Ali Boudani at "Mar 7, 2001 04:45:29 pm" To: Ali Boudani Date: Thu, 8 Mar 2001 01:03:28 +0859 () CC: idmr@cs.ucl.ac.uk, ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Ali; > > > are you suggesting that there is no multicast problem :-) > > There is none remaining. > > Well, what about scalability, Which scalability? In a sense, multicast is proven not to scale that aggregation of multicast routing table entries is impossible, which is why it is a resource reserved communication. Income scales proportional to the number of groups that you can afford larger routing table. > and the interoperability with the underlying unicast > protocols. The current underlying unicast protocols are best effort and irrelevant. > and what about the interdomain multicast??? Huh? It is crazy to first design a intra domain protocol with a lot of scalability problems and expect an interdomain protocol magically fix the problems. Protocols should just work. Please don't say interdomain policy control by BGP. BGP is for best effort policy. > > I'm saying it was simple and easy to solve the resource reservation > > and multicast problems at once (www.real-internet.org). > > Is that the draft :Simple Resource ReSerVation Protocol (SRSVP) (in English) > or there is another one?? There are several. Some of them are available in Japanese only, I think. > I didnt found it in the internet-drafts at the IETF !!! I think it was not posted at all. Masataka Ohta From owner-idmr@cs.ucl.ac.uk Wed Mar 7 15:52:02 2001 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 PAA22250 for ; Wed, 7 Mar 2001 15:51:59 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 20:27:40 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 20:27:27 +0000 Received: from necom830.hpcl.titech.ac.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 20:27:35 +0000 From: Masataka Ohta Message-Id: <200103072017.FAA06692@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id FAA06692; Thu, 8 Mar 2001 05:16:50 +0859 Subject: Re: Multicast In-Reply-To: <20010307175750.A813E8A3@sean.ebone.net> from Sean Doran at "Mar 7, 2001 06:57:50 pm" To: Sean Doran Date: Thu, 8 Mar 2001 05:16:49 +0859 () CC: ikob@koganei.wide.ad.jp, aboudani@irisa.fr, idmr@cs.ucl.ac.uk, ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Sean; > | Because best effort service is flat rated, receivers are not motivated > | to use multicast. Senders learned to have more servers. > > Yes, but some senders would like to send a bit less :-) By definition, majority is taken by the receivers. ;-) Masataka Ohta From owner-idmr@cs.ucl.ac.uk Wed Mar 7 17:20:37 2001 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 RAA24824 for ; Wed, 7 Mar 2001 17:20:37 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 21:01:06 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 21:01:00 +0000 Received: from envoy.onecall.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 21:01:09 +0000 Received: by envoy.onecall.net; id QAA24790; Wed, 7 Mar 2001 16:04:44 -0500 Received: from atlas.onecall.net(172.19.64.14) by envoy.onecall.net via smap (V5.0) id xma024776; Wed, 7 Mar 01 16:04:04 -0500 Received: from onecall.net (dhcp64228.onecall.net [172.19.64.228]) by atlas.corp.onecall.net (8.9.3/8.9.1) with ESMTP id QAA23778; Wed, 7 Mar 2001 16:00:21 -0500 (EST) Message-ID: <3AA6A167.6CE5B4EF@onecall.net> Date: Wed, 07 Mar 2001 16:00:23 -0500 From: Rick Irving X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brad Huntting CC: Ali Boudani , Masataka Ohta , idmr@cs.ucl.ac.uk, ietf@ietf.org Subject: Re: Multicast References: <200103071545.f27Fj1O34014@hunkular.glarp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Brad Huntting wrote: > > > The real difficulty of multicast is in the various relationships > > to resource reservation. > > This is so completely wrong... > > Multicast is cheaper than unicast from every resource perspective. > It uses fewer network resources for both content providers and > consumers. It even uses fewer resources for network providers. Flaw: You are defining network resources as being circuit bandwidth. > > "The real difficulty of multicast" is that it's much more difficult > for ISP's (and presumably router venders) to support than unicast. No, the real difficulty is it consumes massive amounts of "network resources"... the rare ones. ;) > > brad From owner-idmr@cs.ucl.ac.uk Wed Mar 7 17:20:49 2001 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 RAA24837 for ; Wed, 7 Mar 2001 17:20:48 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 21:31:32 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 21:31:24 +0000 Received: from network-services.uoregon.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 21:31:33 +0000 Received: from localhost (shep@localhost) by network-services.uoregon.edu (8.10.1/8.10.1) with ESMTP id f27LVL303813; Wed, 7 Mar 2001 13:31:21 -0800 (PST) Date: Wed, 7 Mar 2001 13:31:21 -0800 (PST) From: Greg Shepherd X-Sender: shep@network-services.uoregon.edu To: Sean Doran cc: aboudani@irisa.fr, huntting@hunkular.glarp.com, idmr@cs.ucl.ac.uk, ietf@ietf.org, mohta@necom830.hpcl.titech.ac.jp Subject: Re: Multicast In-Reply-To: <20010307172834.488E08A3@sean.ebone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk > Why? Poor client support springs to mind. I've always wanted to > have someone throw together a web page that downloads a Java applet > equivalent to vic/vat/rat/etc., joins the right group, and puts content > into the face of the clicker, perhaps for a fee. However, in the absence > of compelling content (sadly we don't have Vint to strip for us :) ), I > haven't suggested that this be a priority. I often thought of the same, but the current Java Applet security model prevents applets from joining mcast groups; or at least did last I looked. Greg > Also, not all routers at/near the edge can even do native multicast... > > Sean. > > P.S.: A long time ago there was a very interesting discussion (probably > on NANOG) involving Vadim Antonov and many others; the argument > advanced by Vadim's side (include me here) is, roughly, that if you consider > multicast to be a degenerate form of caching, where the cache is purged > immediately after servicing the implicit cache requests made by the > listeners who have joined below the current router, then native multicast, > particularly reliable native multicast, is being approached in fundamentally > the wrong fashion. In other words, rolling (maybe short term) content > caching into (some) routers is likely to be a more useful generalized > service than deploying actual native multicast, all while being able > to reuse some join/prune, SA and RPF state handling to optimize the > "network-based Content Distribution Network" (to use a set of buzzwords). > From owner-idmr@cs.ucl.ac.uk Wed Mar 7 19:12:55 2001 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 TAA28208 for ; Wed, 7 Mar 2001 19:12:53 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 23:04:32 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 23:04:25 +0000 Received: from garcia.multicasttech.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 23:04:20 +0000 Received: from [63.105.122.212] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 830978; Wed, 07 Mar 2001 18:06:03 -0500 Message-ID: <3AA6BECC.AD39247A@21rst-century.com> Date: Wed, 07 Mar 2001 18:05:48 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Greg Shepherd CC: Sean Doran , aboudani@irisa.fr, huntting@hunkular.glarp.com, idmr@cs.ucl.ac.uk, ietf@ietf.org, mohta@necom830.hpcl.titech.ac.jp Subject: Re: Multicast References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Greg; The multicast test button we wrote : http://www.multicasttech.com/mt/ http://www.on-the-i.com/mt/test_ns.html is a Java applet, and it joins a group. The secret was in getting the right certificates and authorizations. This seems to still be the problem with the Mac. Marshall Greg Shepherd wrote: > > > Why? Poor client support springs to mind. I've always wanted to > > have someone throw together a web page that downloads a Java applet > > equivalent to vic/vat/rat/etc., joins the right group, and puts content > > into the face of the clicker, perhaps for a fee. However, in the absence > > of compelling content (sadly we don't have Vint to strip for us :) ), I > > haven't suggested that this be a priority. > > I often thought of the same, but the current Java Applet security model > prevents applets from joining mcast groups; or at least did last I looked. > > Greg > > > Also, not all routers at/near the edge can even do native multicast... > > > > Sean. > > > > P.S.: A long time ago there was a very interesting discussion (probably > > on NANOG) involving Vadim Antonov and many others; the argument > > advanced by Vadim's side (include me here) is, roughly, that if you consider > > multicast to be a degenerate form of caching, where the cache is purged > > immediately after servicing the implicit cache requests made by the > > listeners who have joined below the current router, then native multicast, > > particularly reliable native multicast, is being approached in fundamentally > > the wrong fashion. In other words, rolling (maybe short term) content > > caching into (some) routers is likely to be a more useful generalized > > service than deploying actual native multicast, all while being able > > to reuse some join/prune, SA and RPF state handling to optimize the > > "network-based Content Distribution Network" (to use a set of buzzwords). > > -- Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From owner-idmr@cs.ucl.ac.uk Wed Mar 7 19:12:59 2001 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 TAA28231 for ; Wed, 7 Mar 2001 19:12:58 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 7 Mar 2001 23:17:11 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Mar 2001 23:17:05 +0000 Received: from sigma.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 7 Mar 2001 23:17:11 +0000 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.18]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA25882; Wed, 7 Mar 2001 15:16:12 -0800 (PST) Date: Wed, 7 Mar 2001 15:16:12 -0800 (PST) From: Greg Shepherd To: Marshall Eubanks cc: Greg Shepherd , Sean Doran , aboudani@irisa.fr, huntting@hunkular.glarp.com, idmr@cs.ucl.ac.uk, ietf@ietf.org, mohta@necom830.hpcl.titech.ac.jp Subject: Re: Multicast In-Reply-To: <3AA6BECC.AD39247A@21rst-century.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Okay, so signed applets work? Good. Thanks, Greg On Wed, 7 Mar 2001, Marshall Eubanks wrote: > Greg; > > The multicast test button we wrote : > > http://www.multicasttech.com/mt/ > http://www.on-the-i.com/mt/test_ns.html > > is a Java applet, and it joins a group. > > The secret was in getting the right certificates and authorizations. This > seems to still be the problem with the Mac. > > Marshall > > Greg Shepherd wrote: > > > > > Why? Poor client support springs to mind. I've always wanted to > > > have someone throw together a web page that downloads a Java applet > > > equivalent to vic/vat/rat/etc., joins the right group, and puts content > > > into the face of the clicker, perhaps for a fee. However, in the absence > > > of compelling content (sadly we don't have Vint to strip for us :) ), I > > > haven't suggested that this be a priority. > > > > I often thought of the same, but the current Java Applet security model > > prevents applets from joining mcast groups; or at least did last I looked. > > > > Greg > > > > > Also, not all routers at/near the edge can even do native multicast... > > > > > > Sean. > > > > > > P.S.: A long time ago there was a very interesting discussion (probably > > > on NANOG) involving Vadim Antonov and many others; the argument > > > advanced by Vadim's side (include me here) is, roughly, that if you consider > > > multicast to be a degenerate form of caching, where the cache is purged > > > immediately after servicing the implicit cache requests made by the > > > listeners who have joined below the current router, then native multicast, > > > particularly reliable native multicast, is being approached in fundamentally > > > the wrong fashion. In other words, rolling (maybe short term) content > > > caching into (some) routers is likely to be a more useful generalized > > > service than deploying actual native multicast, all while being able > > > to reuse some join/prune, SA and RPF state handling to optimize the > > > "network-based Content Distribution Network" (to use a set of buzzwords). > > > > > -- > > Multicast Technologies, Inc. > 10301 Democracy Lane, Suite 410 > Fairfax, Virginia 22030 > Phone : 703-293-9624 Fax : 703-293-9609 > e-mail : tme@on-the-i.com http://www.on-the-i.com > From owner-idmr@cs.ucl.ac.uk Wed Mar 7 22:19:39 2001 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 WAA01550 for ; Wed, 7 Mar 2001 22:19:38 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 8 Mar 2001 02:11:16 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Mar 2001 02:11:10 +0000 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 8 Mar 2001 02:11:19 +0000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 536DF1E010; Wed, 7 Mar 2001 21:11:18 -0500 (EST) 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 VAA15348; Wed, 7 Mar 2001 21:11:13 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id SAA18539; Wed, 7 Mar 2001 18:11:12 -0800 (PST) Message-Id: <200103080211.SAA18539@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: shep@cisco.com Subject: Re: Multicast Cc: tme@21rst-century.com, idmr@cs.ucl.ac.uk Date: Wed, 7 Mar 2001 18:11:12 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk [I removed ietf@ietf.org, as well as most of the other entries, from the cc: line.] Signed applets work if you grant the rights (at least in Netscape). I tried Marshall's applet and I got: JavaScript or a Java applet from 'Multicast Technologies, Inc ' is requesting additional privileges. Granting the following is HIGH RISK: Broadcasting information to multiple computers over a network. I granted that one, and got another one, saying Granting the following is HIGH RISK: Accepting connections from other computers on a network Then a third, saying: Granting the following is HIGH RISK: Contacting and connecting with other computers over a network And finally, my system joined the group: 18:06:55.843130 mango.attlabs.att.com > 233.64.133.12: igmp v2 report 233.64.133.12 [ttl 1] but netscape's warnings are plenty threatening (and prolific) to make some/many/most consumers not click all those buttons. (Netscape will remember these decisions, and I *think* the decision is based on the signer, so if you get someone to click all these buttons once they will trust all of the applets signed by the same key, but still...) Bill From owner-idmr@cs.ucl.ac.uk Thu Mar 8 00:04:30 2001 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 AAA03965 for ; Thu, 8 Mar 2001 00:04:29 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 8 Mar 2001 03:51:15 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Mar 2001 03:51:09 +0000 Received: from garcia.multicasttech.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 8 Mar 2001 03:51:18 +0000 Received: from [216.8.7.10] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 831076; Wed, 07 Mar 2001 22:52:59 -0500 Message-ID: <3AA7020D.9A2FA683@21rst-century.com> Date: Wed, 07 Mar 2001 22:52:45 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner , Marty Schoch CC: shep@cisco.com, idmr@cs.ucl.ac.uk Subject: Re: Multicast References: <200103080211.SAA18539@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bill; Bill Fenner wrote: > > [I removed ietf@ietf.org, as well as most of the other entries, from > the cc: line.] Thanks - I should have done that. I don't think the whole IETF is interested... > > Signed applets work if you grant the rights (at least in Netscape). > I tried Marshall's applet and I got: Marty Schoch wrote it. > > JavaScript or a Java applet from 'Multicast Technologies, Inc ' is > requesting additional privileges. > > Granting the following is HIGH RISK: > Broadcasting information to multiple computers over a network. > > I granted that one, and got another one, saying > > Granting the following is HIGH RISK: > Accepting connections from other computers on a network > > Then a third, saying: > > Granting the following is HIGH RISK: > Contacting and connecting with other computers over a network > > And finally, my system joined the group: > > 18:06:55.843130 mango.attlabs.att.com > 233.64.133.12: igmp v2 report 233.64.133.12 [ttl 1] > > but netscape's warnings are plenty threatening (and prolific) to make > some/many/most consumers not click all those buttons. (Netscape will > remember these decisions, and I *think* the decision is based on the > signer, so if you get someone to click all these buttons once they will > trust all of the applets signed by the same key, but still...) > > Bill Hey, at least we didn't make you sign a waiver. Our button web page warns you about these messages (Microsoft IE requires just one such grant, BTW). We couldn't figure out how to shut them off. If anyone knows a way to get the applet to work without this, please let me know. What we were trying to do here was to get something that the uninitiated could use without downloading anything, so this seemed acceptable. It is problematic for most applet applications, of course. It seems to me that joining a mulitcast group from a applet running inside a virtual machine is fairly safe. Maybe the browser makers could make an exception for a join with transmission disabled. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From owner-idmr@cs.ucl.ac.uk Thu Mar 8 01:49:14 2001 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 BAA08588 for ; Thu, 8 Mar 2001 01:49:14 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 8 Mar 2001 05:27:34 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Mar 2001 05:27:29 +0000 Received: from necom830.hpcl.titech.ac.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 8 Mar 2001 05:27:38 +0000 From: Masataka Ohta Message-Id: <200103080523.OAA08273@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA08273; Thu, 8 Mar 2001 14:22:59 +0859 Subject: Re: Multicast In-Reply-To: <20010307174223.41B4F8A3@sean.ebone.net> from Sean Doran at "Mar 7, 2001 06:42:23 pm" To: Sean Doran Date: Thu, 8 Mar 2001 14:22:59 +0859 () CC: aboudani@irisa.fr, idmr@cs.ucl.ac.uk, ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Sean; > | Is that the draft :Simple Resource ReSerVation Protocol (SRSVP) (in English) > | or there is another one?? > | I didnt found it in the internet-drafts at the IETF !!! > > Good, RSVP for multicast is an insane idea. There is a finite but nearly > zero chance that an ISP will ever squeeze more money out of someone by > promising them via RSVP that their multicast packets will make it through > from source to destination, whether the someone is a source or a listener. ISPs can squeeze more money with resource reserved unicast. ISPs can squeeze less money with resource reserved multicast, which is why, with resource reserved communication, source or listener are motivated to use multicast. Then, with free competition between ISPs, some ISP is motivated to offer multicast. > However, if you demonstrate compliance with an SLA that works like many > unicast ones (x% packet loss, y ms delay, from network edge to network edge), > you may be able to charge more for "best efforts" multicast, and pick > up customers who are frustrated with RSVP stuff. To make it operationally scale without spending infinite amount of money on network operators (:-), we need a fully automated signaling protocol. > "Simple" RSVP: say yes always, or say no always. Choose one. RSVP is complex partly because of filter spec, which is unnecessary with shared-tree unidirectional PIM, and half hearted support of half-reliable link local multicast, which is unnecessary as, following the CATENET model, internet should not include large link layer, which ATM network dreamed to be. Masataka Ohta From owner-idmr@cs.ucl.ac.uk Thu Mar 8 04:28:55 2001 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 EAA20830 for ; Thu, 8 Mar 2001 04:28:54 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 8 Mar 2001 08:13:12 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Mar 2001 08:13:07 +0000 Received: from dynamic-195-91.dialup.chalmers.se by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 8 Mar 2001 08:13:05 +0000 Received: (from lindberg@localhost) by amati.cdg.chalmers.se (8.9.3/8.9.3) id JAA07713; Thu, 8 Mar 2001 09:12:57 +0100 Date: Thu, 8 Mar 2001 09:12:57 +0100 Message-Id: <200103080812.JAA07713@amati.cdg.chalmers.se> X-Authentication-Warning: amati.cdg.chalmers.se: lindberg set sender to lindberg@cdg.chalmers.se using -f From: Gunnar Lindberg To: idmr@cs.ucl.ac.uk, ietf@ietf.org Subject: Re: Multicast X-Mailer: UCB Mail 5.3.21 2000-12-15 (MIME) Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Please explain what's wrong with my take on multicast scalability: Every time a new sender shows up, the entire multicast core (RPs, right now those running MSDP in the default free zone) has to be informed. To "show up", the host just starts sending data. Every time a new receiver shows up, its nearest RP has to initiate a data distribution path (tree) torwards the sender(s). This is likely to involve at least some of the core routers. Scalability problems: 1) An indivivual sender - host, my Linux PC - affects routing information in the entire router core. Just send data. There are a few hosts on the Internet. 2) As if his wasn't enough, consider the potential for DoS- attacks. The recent Ramen worm was the first(?) example; who can claim it was the last? Assume technology evolves fast enough to solve 1). We still have 2). My claim is that it doesn't scale to allow individual hosts to affect the Interet core routing system. What do I miss? Gunnar Lindberg From owner-idmr@cs.ucl.ac.uk Thu Mar 8 06:06:54 2001 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 GAA21565 for ; Thu, 8 Mar 2001 06:06:54 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 8 Mar 2001 09:51:46 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Mar 2001 09:51:39 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 8 Mar 2001 09:51:48 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id KAA06741 for ; Thu, 8 Mar 2001 10:51:47 +0100 (MET) Message-ID: <3AA75633.36575261@irisa.fr> Date: Thu, 08 Mar 2001 10:51:47 +0100 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: MASC 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, What is the difference between the claim-collide and query response in MASC?? I read the MASC protocl and I didnt understand it?? will any one please explain it to me. thanx you From owner-idmr@cs.ucl.ac.uk Thu Mar 8 07:56:15 2001 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 HAA24504 for ; Thu, 8 Mar 2001 07:56:15 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 8 Mar 2001 11:17:10 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Mar 2001 11:17:06 +0000 Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Mar 2001 11:17:14 +0000 To: #PATHIK GUPTA# cc: "'Gunnar Lindberg'" , idmr@cs.ucl.ac.uk, ietf@ietf.org Subject: Re: Multicast In-reply-to: Your message of "Thu, 08 Mar 2001 18:11:11 +0800." <3BC5217C8E6D9E498F4F682CD7FF75460F9E44@mail10.main.ntu.edu.sg> Date: Thu, 08 Mar 2001 11:17:13 +0000 Message-ID: <10679.984050233@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk again, i don't know if the WHOLE IETF list wants to see this discussion, nor if IDMR (which now looks at a fairly small piece of the multicast picture) wants to be cc:d - the right place for this discussion is probably pim, and possibly ssm, - idmr is about ready to close down the right solution (imho) is a two protocol world 1/ PIM SSM for 1-many apps with IGMPv3 for join/leave 2/ PIM bidir/BGMP (basically equiv. to hierarchical PIM) for many sender with some smart inter-domain RP assignment done as part of the brokering/peering arrangements between providers - this latter needs lots of work i) PIM bidir needs finishing ii) the interdomain part needs implementing (not hard) and detailed specification as ISPs get use to intradomain SSM, they may start to comtemplate some PIM SM, then PIM bidir customers/applications (a while off, but slowly) - then,when they understand traffic engineering internally for these applications, they may start to consider how to do inter-domain peering and traffic engineering on any plausible timeframe for this, routers maybe able to handle the state for the many-sender protocols (certainyl they wont be today or tomorrows routers), so as long as state scales linear or sublinear in #many-sender flows, it is not out of the question (not great, but not out of the question) - hierchical approaches based on bidir trees can do some aggregation to get it better than s,g (if we believe we will have a lot of apps anyhow with genuine inter-domain, globally visible state required. ... it aint obvious - a lot of apps we are thinking about can be global, but stay mainly within a single tier 1 provider, until they say auto-tunnel thru the access provider. some apps can just use small numbers of SSM flows from the server site. lots of alternatives .... anyhow, as i say, this discussion is already ongoing in the relevant groups (including mboned) and direcrorates...not on idmr and ietf:-) In message <3BC5217C8E6D9E498F4F682CD7FF75460F9E44@mail10.main.ntu.edu.sg>, #PA THIK GUPTA# typed: >>Hi, >> >>It is true that there are certain scalability issues with Multicast. However >>the solution of this is to have a very good InterDomain multicast routing as >>well as Intra Domain multiast routing protocols. With that the problem of >>host affecting the entire routing core is greatly reduced. >>The protocols like CBT and PIM-SM were developed because it was found that >>protocols like DVMRP and PIM-DM cannot scale. It is also neceesary to note >>the fact that PIM-SM is only efficient for the sparesely disributed hosts >>and it is a Receiver initiated protocol. This has significant advantage over >>flood and prune protocols like DVMRP. >> >>If you think of the scenario where there are very less hosts receving the >>session and why dont we just send data directly, then this solution cannot >>scale. The whole purpose of multicast is lost. The server will be burdened >>and each unicast stream will contribute more to a single multicast stream. >> >>Cheers, >>Pathik Gupta >> >>-----Original Message----- >>From: Gunnar Lindberg [mailto:lindberg@CDG.CHALMERS.SE] >>Sent: Thursday, March 08, 2001 4:13 PM >>To: idmr@CS.UCL.AC.UK; ietf@ietf.org >>Subject: Re: Multicast >> >> >>Please explain what's wrong with my take on multicast scalability: >> >>Every time a new sender shows up, the entire multicast core (RPs, >>right now those running MSDP in the default free zone) has to be >>informed. To "show up", the host just starts sending data. >> >>Every time a new receiver shows up, its nearest RP has to initiate >>a data distribution path (tree) torwards the sender(s). This is >>likely to involve at least some of the core routers. >> >>Scalability problems: >> >> 1) An indivivual sender - host, my Linux PC - affects routing >> information in the entire router core. Just send data. >> There are a few hosts on the Internet. >> >> 2) As if his wasn't enough, consider the potential for DoS- >> attacks. The recent Ramen worm was the first(?) example; >> who can claim it was the last? >> >>Assume technology evolves fast enough to solve 1). We still have 2). >> >>My claim is that it doesn't scale to allow individual hosts to affect >>the Interet core routing system. What do I miss? >> >> Gunnar Lindberg >> cheers jon ), in memory of lowell george From owner-idmr@cs.ucl.ac.uk Thu Mar 8 07:56:21 2001 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 HAA24517 for ; Thu, 8 Mar 2001 07:56:20 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 8 Mar 2001 12:32:55 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Mar 2001 12:32:49 +0000 Received: from garcia.multicasttech.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 8 Mar 2001 12:32:57 +0000 Received: from [216.8.6.128] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 831169; Thu, 08 Mar 2001 07:34:33 -0500 Message-ID: <3AA77C51.655D0512@21rst-century.com> Date: Thu, 08 Mar 2001 07:34:24 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Gunnar Lindberg CC: idmr@cs.ucl.ac.uk Subject: Re: Multicast References: <200103080812.JAA07713@amati.cdg.chalmers.se> 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 removed the IETF list cc. Gunnar Lindberg wrote: > > Please explain what's wrong with my take on multicast scalability: > > Every time a new sender shows up, the entire multicast core (RPs, > right now those running MSDP in the default free zone) has to be > informed. To "show up", the host just starts sending data. > > Every time a new receiver shows up, its nearest RP has to initiate > a data distribution path (tree) torwards the sender(s). This is > likely to involve at least some of the core routers. > > Scalability problems: > > 1) An indivivual sender - host, my Linux PC - affects routing > information in the entire router core. Just send data. > There are a few hosts on the Internet. > Under ISM, a individual sender only affects routing AT THE RP (in the absence of any receivers). Under SSM, sending without receivers only affects the first hop router. For either, the FIRST receiver does change state along the path. The Nth is not likely to (if N is sufficiently large). > 2) As if his wasn't enough, consider the potential for DoS- > attacks. The recent Ramen worm was the first(?) example; > who can claim it was the last? > I will present on this at the IETF. Basically, ISM is sensitive to DOS at the RP, and can amplify certain ones (if nothing is done). SSM is much less sensitive, and does not amplify DOS attacks. In any case, something can be done - rate and state limit filters. I have no doubt that SSM can be made robust against d-DOS attacks. ISM is less clear, but if broadcasting moves over to SSM, multiparty conferences are not likely to last long enough to be the subject of a DOS attack. > Assume technology evolves fast enough to solve 1). We still have 2). > > My claim is that it doesn't scale to allow individual hosts to affect > the Interet core routing system. What do I miss? > ISM RP's and MSDP don't scale very well for IDMR. SSM does scale much better, as only the routers involved between sender and receiver are affected. I would submit that SSM scales better than BGP, and that, for a long time to come, router upgrades will be be driven by the need to keep up with BGP advertisements, not the need to store SSM state. It would take a lot more than 100,000 SSM broadcasters to make this a worry. > Gunnar Lindberg -- Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From owner-idmr@cs.ucl.ac.uk Thu Mar 8 09:44:42 2001 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 JAA27925 for ; Thu, 8 Mar 2001 09:44:41 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 8 Mar 2001 13:15:11 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Mar 2001 03:20:08 +0000 Received: from sj-msg-core-1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 8 Mar 2001 03:20:17 +0000 Received: from holbrook-laptop.cisco.com (dhcp-10-34-3-132.cisco.com [10.34.3.132]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id TAA08950; Wed, 7 Mar 2001 19:19:11 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id B1103C3A73; Wed, 7 Mar 2001 19:19:16 -0800 (PST) From: Hugh Holbrook To: ssm-interest@external.cisco.com, idmr@cs.ucl.ac.uk Cc: bcain@cereva.com Subject: draft-holbrook-idmr-igmpv3-ssm-01.txt Reply-To: holbrook@cisco.com Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Message-Id: <20010308031916.B1103C3A73@holbrook-laptop.cisco.com> Date: Wed, 7 Mar 2001 19:19:16 -0800 (PST) Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Brad and I revised the igmpv3-and-ssm draft and submitted an -01 version (draft-holbrook-idmr-igmpv3-ssm-01.txt). It should show up in the internet drafts directory any time now. For now, you can get it from http://sith.maoz.com/SSM/draft-holbrook-idmr-igmpv3-ssm-01.txt The biggest change relative to the -00 version is to specify that hosts should have a configuration option for the SSM address range and that protocol mechanisms for setting this option may be defined in the future. We also added a note about the new igmpv3 behavior of not reverting to EXCLUDE mode when running out of resources. We think we're pretty close to last call on this, so we'd appreciate any comments. Thanks, -Hugh From owner-idmr@cs.ucl.ac.uk Thu Mar 8 09:45:09 2001 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 JAA27956 for ; Thu, 8 Mar 2001 09:45:08 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 8 Mar 2001 13:16:04 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Mar 2001 10:11:25 +0000 Received: from mail3.ntu.edu.sg by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 8 Mar 2001 10:11:20 +0000 Received: by mail3.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Mar 2001 18:10:49 +0800 Message-ID: <3BC5217C8E6D9E498F4F682CD7FF75460F9E44@mail10.main.ntu.edu.sg> From: #PATHIK GUPTA# To: "'Gunnar Lindberg'" , idmr@cs.ucl.ac.uk, ietf@ietf.org Subject: RE: Multicast Date: Thu, 8 Mar 2001 18:11:11 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi, It is true that there are certain scalability issues with Multicast. However the solution of this is to have a very good InterDomain multicast routing as well as Intra Domain multiast routing protocols. With that the problem of host affecting the entire routing core is greatly reduced. The protocols like CBT and PIM-SM were developed because it was found that protocols like DVMRP and PIM-DM cannot scale. It is also neceesary to note the fact that PIM-SM is only efficient for the sparesely disributed hosts and it is a Receiver initiated protocol. This has significant advantage over flood and prune protocols like DVMRP. If you think of the scenario where there are very less hosts receving the session and why dont we just send data directly, then this solution cannot scale. The whole purpose of multicast is lost. The server will be burdened and each unicast stream will contribute more to a single multicast stream. Cheers, Pathik Gupta -----Original Message----- From: Gunnar Lindberg [mailto:lindberg@CDG.CHALMERS.SE] Sent: Thursday, March 08, 2001 4:13 PM To: idmr@CS.UCL.AC.UK; ietf@ietf.org Subject: Re: Multicast Please explain what's wrong with my take on multicast scalability: Every time a new sender shows up, the entire multicast core (RPs, right now those running MSDP in the default free zone) has to be informed. To "show up", the host just starts sending data. Every time a new receiver shows up, its nearest RP has to initiate a data distribution path (tree) torwards the sender(s). This is likely to involve at least some of the core routers. Scalability problems: 1) An indivivual sender - host, my Linux PC - affects routing information in the entire router core. Just send data. There are a few hosts on the Internet. 2) As if his wasn't enough, consider the potential for DoS- attacks. The recent Ramen worm was the first(?) example; who can claim it was the last? Assume technology evolves fast enough to solve 1). We still have 2). My claim is that it doesn't scale to allow individual hosts to affect the Interet core routing system. What do I miss? Gunnar Lindberg From owner-idmr@cs.ucl.ac.uk Thu Mar 8 16:40:18 2001 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 QAA14216 for ; Thu, 8 Mar 2001 16:40:16 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 8 Mar 2001 19:46:03 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Mar 2001 19:45:58 +0000 Received: from catarina.usc.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 8 Mar 2001 19:46:01 +0000 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA60527; Thu, 8 Mar 2001 11:46:00 -0800 (PST) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id LAA83057; Thu, 8 Mar 2001 11:45:59 -0800 (PST) Message-Id: <200103081945.LAA83057@rumi.usc.edu> To: Ali Boudani cc: idmr@cs.ucl.ac.uk, malloc@catarina.usc.edu Subject: Re: MASC In-reply-to: Your message of "Thu, 08 Mar 2001 10:51:47 +0100." <3AA75633.36575261@irisa.fr> Date: Thu, 08 Mar 2001 11:45:59 -0800 From: Pavlin Ivanov Radoslavov Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk [A better place to ask MASC-related questions is malloc@catarina.usc.edu (CC-ed above). If someone replies to this email, please remove IDMR from the CC list] > Hello, > What is the difference between the claim-collide and query response in > MASC?? Just to clarify, MASC uses only the claim-collide mechanism. > I read the MASC protocl and I didnt understand it?? > will any one please explain it to me. > thanx you The spec purpose is more or less to describe the protocol the way it is, hence it doesn't go into details about alternative solutions. The main difference between claim-collide and query-response (also occasionally called request-response) is: With query-response, if you want to get/use some resource (e.g., name or block of addresses), you must request it from a resource manager. Only after you get a positive acknowledgment from the manager, then you can go ahead and use the resource. If the manager is down or not reachable, then the allocation system needs to consider how to deal with robustness issues instead of keeping you waiting. With claim-collide, there is no explicit manager responsible for the resource allocation. If you want to use some resource, you shout loudly to everyone "I WANT THAT!". Then you politely wait for long enough interval of time to make sure that everyone heard you and that nobody else wanted the same resource. If you hear somebody else asking for the same resource, then the collision is resolved unambiguously (e.g. based on timestamp or whatever). If you are the loser then you must repeat the process by claiming something else. After you have waited long enough time without a collision (or if you are the winner of all collisions), then you pretty confidently assume that you can use that resource. Hope that helps, Pavlin From owner-idmr@cs.ucl.ac.uk Fri Mar 9 12:51:40 2001 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 MAA26001 for ; Fri, 9 Mar 2001 12:51:40 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 9 Mar 2001 16:07:58 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Mar 2001 16:07:53 +0000 Received: from necom830.hpcl.titech.ac.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 9 Mar 2001 16:07:48 +0000 From: Masataka Ohta Message-Id: <200103091554.AAA12606@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA12606; Sat, 10 Mar 2001 00:54:29 +0900 Subject: Re: Multicast In-Reply-To: <200103080812.JAA07713@amati.cdg.chalmers.se> from Gunnar Lindberg at "Mar 8, 2001 09:12:57 am" To: Gunnar Lindberg Date: Sat, 10 Mar 2001 00:54:29 +0859 () CC: idmr@cs.ucl.ac.uk, ietf@ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Gunnar; > Please explain what's wrong with my take on multicast scalability: > > Every time a new sender shows up, the entire multicast core (RPs, > right now those running MSDP in the default free zone) has to be > informed. To "show up", the host just starts sending data. You are wrong to say "multicast scalability" instead of "MSDP scalability". > 1) An indivivual sender - host, my Linux PC - affects routing > information in the entire router core. Just send data. > There are a few hosts on the Internet. > Assume technology evolves fast enough to solve 1). No, it does not. > My claim is that it doesn't scale to allow individual hosts to affect > the Interet core routing system. What do I miss? Then entire multicast (actually MSDP) core has nothing to do with the Internet core routing system. Masataka Ohta From owner-idmr@cs.ucl.ac.uk Fri Mar 16 05:50:09 2001 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 FAA01623 for ; Fri, 16 Mar 2001 05:50:09 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 16 Mar 2001 09:01:00 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 16 Mar 2001 09:00:54 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 16 Mar 2001 09:01:05 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id JAA22239; Fri, 16 Mar 2001 09:42:13 +0100 (MET) Message-ID: <3AB1D1E5.A00CABCF@irisa.fr> Date: Fri, 16 Mar 2001 09:42:13 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: ssm-interest@external.cisco.com, malloc@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: hello Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit I was wondering that SSM (before was the SImple Muticast or EXPRESS) use a channel like (S, G) and the drafts are saying that this is the solution to the address allocation problem because each group is represented with the souce address also. but why?? figure this : 2 groups (having the same address) want to recieve from the same source. the (simple multicast or EXPRESS or SSM) will consider them as the same group So in this case any (S, G) = (S, G1) .... (S, Gn) and there is no sense in the adress group of the recievers. at the same time if G2 (the recievers in the G2 but having the G multicast address group) for example want to recieve from S2 , in that case all the G1.... Gn will recieve the data. am I right ?? thanx From owner-idmr@cs.ucl.ac.uk Fri Mar 16 05:50:45 2001 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 FAA01634 for ; Fri, 16 Mar 2001 05:50:45 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 16 Mar 2001 09:28:15 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 16 Mar 2001 09:28:11 +0000 Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 16 Mar 2001 09:28:11 +0000 To: Ali Boudani cc: ssm-interest@external.cisco.com, malloc@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: Re: hello In-reply-to: Your message of "Fri, 16 Mar 2001 09:42:13 +0100." <3AB1D1E5.A00CABCF@irisa.fr> Date: Fri, 16 Mar 2001 09:28:09 +0000 Message-ID: <24631.984734889@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk the problem it solves is the address _collision_ Problem - since all SSM G,s are specific to their S's, you don';t have to run a distributed algorithm or directory to do the allocation since there are no clash type problems. i.e. the malloc architecture is sidestepped. In message <3AB1D1E5.A00CABCF@irisa.fr>, Ali Boudani typed: >>I was wondering that SSM (before was the SImple Muticast or EXPRESS) use >>a channel like (S, G) and the drafts are saying that this is the >>solution to the address allocation problem because each group is >>represented with the souce address also. but why?? >>figure this : 2 groups (having the same address) want to recieve from >>the same source. the (simple multicast or EXPRESS or SSM) will consider >>them as the same group >>So in this case any (S, G) = (S, G1) .... (S, Gn) and there is no sense >>in the adress group of the recievers. >>at the same time if G2 (the recievers in the G2 but having the G >>multicast address group) for example want to recieve from S2 , in that >>case all the G1.... Gn will recieve the data. >> >>am I right ?? >>thanx >> cheers jon From owner-idmr@cs.ucl.ac.uk Fri Mar 16 11:48:25 2001 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 LAA06857 for ; Fri, 16 Mar 2001 11:48:24 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 16 Mar 2001 14:52:05 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 16 Mar 2001 09:56:14 +0000 Received: from alc119.alcatel.be by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 16 Mar 2001 09:56:20 +0000 Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f2G9aMv01866; Fri, 16 Mar 2001 10:36:22 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A11.0034BD5E; Fri, 16 Mar 2001 10:36:03 +0100 Message-ID: <3AB1DE82.D6ADD1AB@alcatel.be> Date: Fri, 16 Mar 2001 10:36:02 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ali Boudani CC: ssm-interest@external.cisco.com, malloc@catarina.usc.edu, idmr@cs.ucl.ac.uk Subject: Re: hello References: <3AB1D1E5.A00CABCF@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Ali Boudani wrote: > > I was wondering that SSM (before was the SImple Muticast or EXPRESS) use > a channel like (S, G) and the drafts are saying that this is the > solution to the address allocation problem because each group is > represented with the souce address also. but why?? > figure this : 2 groups (having the same address) want to recieve from > the same source. I have difficulty in understanding what you are writing, but I think that the main point that you are missing is that a sender will never use the same group address for two different streams. The sender determines wich G to use for a certain stream. dirk the (simple multicast or EXPRESS or SSM) will consider > them as the same group > So in this case any (S, G) = (S, G1) .... (S, Gn) and there is no sense > in the adress group of the recievers. > at the same time if G2 (the recievers in the G2 but having the G > multicast address group) for example want to recieve from S2 , in that > case all the G1.... Gn will recieve the data. > > am I right ?? > thanx From owner-idmr@cs.ucl.ac.uk Sat Mar 17 15:28:51 2001 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 PAA09016 for ; Sat, 17 Mar 2001 15:28:50 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sat, 17 Mar 2001 19:02:09 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 17 Mar 2001 19:02:03 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 17 Mar 2001 19:02:15 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id UAA03275; Sat, 17 Mar 2001 20:02:13 +0100 (MET) Message-ID: <3AB3B4B6.99A6AA4A@irisa.fr> Date: Sat, 17 Mar 2001 20:02:14 +0100 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, Dirk.Ooms@alcatel.be Subject: xcast Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit I DONT KNOW IF THIS IS THE RIGHT LIST to send this question : in section 9 . encoding (draft-ooms-xcast-basic-spec-00.txt) why in XCAST we are using the all-xcasts-routers in the destination?? we just need to put the routers where there are recievers and not all the xcasts routers ?? and I didnt understand the issue of the fixed value ?? what do you mean about it? From owner-idmr@cs.ucl.ac.uk Sun Mar 18 19:07:53 2001 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 TAA12571 for ; Sun, 18 Mar 2001 19:07:52 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sun, 18 Mar 2001 22:50:32 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sun, 18 Mar 2001 20:46:24 +0000 Received: from alc119.alcatel.be by bells.cs.ucl.ac.uk with Internet SMTP id ; Sun, 18 Mar 2001 20:46:36 +0000 Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f2IKjrf21278; Sun, 18 Mar 2001 21:46:00 +0100 (MET) Received: from alcatel.be ([128.251.84.166]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A13.007207E8; Sun, 18 Mar 2001 21:45:32 +0100 Message-ID: <3AB4F650.3CFD4CC3@alcatel.be> Date: Sun, 18 Mar 2001 18:54:24 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ali Boudani CC: idmr@cs.ucl.ac.uk Subject: Re: xcast References: <3AB3B4B6.99A6AA4A@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Ali, There is an xcast mailing list, see http://www.alcatel.com/xcast on how to subscribe. dirk Ali Boudani wrote: > > I DONT KNOW IF THIS IS THE RIGHT LIST to send this question : > > in section 9 . encoding > (draft-ooms-xcast-basic-spec-00.txt) > why in XCAST we are using the all-xcasts-routers in the destination?? > we just need to put the routers where there are recievers and not all > the xcasts routers ?? > and I didnt understand the issue of the fixed value ?? what do you mean > about it? From owner-idmr@cs.ucl.ac.uk Mon Mar 26 10:41:56 2001 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 KAA09751 for ; Mon, 26 Mar 2001 10:41:55 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 26 Mar 2001 14:38:48 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 26 Mar 2001 14:38:42 +0100 Received: from firewall.exbit.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 26 Mar 2001 14:38:55 +0100 Received: from amrod.exbit-technology.com (amrod) [192.168.1.114] by anor.exbit-technology.com with smtp (Exim 2.05 #1 (Debian)) id 14hXCw-0005DZ-00; Mon, 26 Mar 2001 15:38:54 +0200 Reply-To: "morten.jagd.christensen" From: Morten Jagd Christensen To: idmr Subject: IGMP snooping draft: Solicitation for Comments Date: Mon, 26 Mar 2001 15:38:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009A_01C0B60B.3E9F59E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_009A_01C0B60B.3E9F59E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Some of you may have seen that we have posted a draft on this list on aspects of IGMP snooping switches. The draft is available as: draft-ietf-idmr-igmp-snoop-00.txt A presentation of this draft was made at the IETF meeting last week. Generally I would say that the draft was well received with only positive comments or encouragements although it will probably move out of the idmr WG soon. Since the IETF idmr WG meeting had a limited number of attendees compared to the number of subscribers of this list (I suppose) I would like to solicit for comments on the draft. So, please send us comments if: 1) You have read the draft and have any comments whatsoever. No comment is to simple. 2) You are working for a company producing IGMP snooping switches and have experiences that you want to share. For example regarding interoperability issues or solutions that you have found to be practical. 3) You know some people who might be interested in this work. Either send me their email addresses or forward this mail to them. 4) You're IGMP agnostic but still want to share your view on this. You can either post your reply to the discussion list or you can email me directly (CC to Frank Solensky) is you don't want your name out in the public. Your contribution will be appreciated. Cheers /Morten -------------------------------------------------- Morten Jagd Christensen | Exbit Technology M.Sc., Ph.D. | www.exbit.com Network- and System Architect | mjc@exbit.dk ------=_NextPart_000_009A_01C0B60B.3E9F59E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IGMP snooping draft: Solicitation for Comments

Hi,

Some of you may have seen that we have = posted a draft on this list
on aspects of IGMP snooping = switches.

The draft is available as: = draft-ietf-idmr-igmp-snoop-00.txt

A presentation of this draft was made = at the IETF meeting last
week. Generally I would say that the = draft was well received with only
positive comments or encouragements = although it will probably move
out of the idmr WG soon.

Since the IETF idmr WG meeting had a = limited number of attendees
compared to the number of subscribers = of this list (I suppose)  I would
like to solicit for comments on the = draft.

So, please send us comments if:

1) You have read the draft and have any = comments whatsoever. No comment
is to simple.

2) You are working for a company = producing IGMP snooping switches and
have experiences that you want to = share. For example regarding interoperability
issues or solutions that you have = found to be practical.

3) You know some people who might be = interested in this work. Either send me
their email addresses or forward this = mail to them.

4) You're IGMP agnostic but still want = to share your view on this.

You can either post your reply to the = discussion list or you can email me
directly (CC to Frank Solensky) is you = don't want your name out in the
public.

Your contribution will be = appreciated.

Cheers

/Morten

--------------------------------------------------
Morten Jagd = Christensen        | Exbit = Technology
M.Sc., = Ph.D.           &n= bsp;       | www.exbit.com
Network- and = System Architect  | mjc@exbit.dk

------=_NextPart_000_009A_01C0B60B.3E9F59E0-- From owner-idmr@cs.ucl.ac.uk Mon Mar 26 13:46:15 2001 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 NAA14021 for ; Mon, 26 Mar 2001 13:46:13 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 26 Mar 2001 17:39:29 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 26 Mar 2001 16:30:39 +0100 Received: from prue.eim.surrey.ac.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Mon, 26 Mar 2001 16:30:52 +0100 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14hYxD-0003Xk-00; Mon, 26 Mar 2001 16:30:47 +0100 Date: Mon, 26 Mar 2001 16:30:48 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Morten Jagd Christensen cc: idmr Subject: Re: IGMP snooping draft: Solicitation for Comments In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *14hYxD-0003Xk-00*v9ylYg6oDh2* Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk On Mon, 26 Mar 2001, Morten Jagd Christensen wrote: > Some of you may have seen that we have posted a draft on this list > on aspects of IGMP snooping switches. > > The draft is available as: draft-ietf-idmr-igmp-snoop-00.txt No it's not. Try: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idmr-snoop-00.txt L. > > A presentation of this draft was made at the IETF meeting last > week. Generally I would say that the draft was well received with only > positive comments or encouragements although it will probably move > out of the idmr WG soon. > > Since the IETF idmr WG meeting had a limited number of attendees > compared to the number of subscribers of this list (I suppose) I would > like to solicit for comments on the draft. > > So, please send us comments if: > > 1) You have read the draft and have any comments whatsoever. No comment > is to simple. > > 2) You are working for a company producing IGMP snooping switches and > have experiences that you want to share. For example regarding > interoperability > issues or solutions that you have found to be practical. > > 3) You know some people who might be interested in this work. Either send me > their email addresses or forward this mail to them. > > 4) You're IGMP agnostic but still want to share your view on this. > > You can either post your reply to the discussion list or you can email me > directly (CC to Frank Solensky) is you don't want your name out in the > public. > > Your contribution will be appreciated. > > Cheers > > /Morten > > -------------------------------------------------- > Morten Jagd Christensen | Exbit Technology > M.Sc., Ph.D. | www.exbit.com > Network- and System Architect | mjc@exbit.dk > > PGP From owner-idmr@cs.ucl.ac.uk Mon Mar 26 13:47:41 2001 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 NAA14032 for ; Mon, 26 Mar 2001 13:47:39 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 26 Mar 2001 19:21:02 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 26 Mar 2001 19:20:56 +0100 Received: from smtprch1.nortelnetworks.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 26 Mar 2001 19:21:10 +0100 Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Mon, 26 Mar 2001 12:15:50 -0600 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Mar 2001 10:15:36 -0800 Message-ID: <5D630265EF50D311ABB60008C7917DB604593F64@zsc4c004.us.nortel.com> From: Sundeep Singatwaria To: "'morten.jagd.christensen'" , idmr Subject: RE: IGMP snooping draft: Solicitation for Comments Date: Mon, 26 Mar 2001 10:15:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B620.BDB35870" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0B620.BDB35870 Content-Type: text/plain; charset="iso-8859-1" We have been supporting IGMP snopping on our Accelar switches for many years now. Cisco, has it own propiteary way of doing snopping. Are we standardizing it now. How come there is a renewed interest for this in IETF when it was considered outside its charter a couple of years back. Sundeep. -----Original Message----- From: Morten Jagd Christensen [mailto:morten.jagd.christensen@exbit.dk] Sent: Monday, March 26, 2001 5:39 AM To: idmr Subject: IGMP snooping draft: Solicitation for Comments Hi, Some of you may have seen that we have posted a draft on this list on aspects of IGMP snooping switches. The draft is available as: draft-ietf-idmr-igmp-snoop-00.txt A presentation of this draft was made at the IETF meeting last week. Generally I would say that the draft was well received with only positive comments or encouragements although it will probably move out of the idmr WG soon. Since the IETF idmr WG meeting had a limited number of attendees compared to the number of subscribers of this list (I suppose) I would like to solicit for comments on the draft. So, please send us comments if: 1) You have read the draft and have any comments whatsoever. No comment is to simple. 2) You are working for a company producing IGMP snooping switches and have experiences that you want to share. For example regarding interoperability issues or solutions that you have found to be practical. 3) You know some people who might be interested in this work. Either send me their email addresses or forward this mail to them. 4) You're IGMP agnostic but still want to share your view on this. You can either post your reply to the discussion list or you can email me directly (CC to Frank Solensky) is you don't want your name out in the public. Your contribution will be appreciated. Cheers /Morten -------------------------------------------------- Morten Jagd Christensen | Exbit Technology M.Sc., Ph.D. | www.exbit.com Network- and System Architect | mjc@exbit.dk ------_=_NextPart_001_01C0B620.BDB35870 Content-Type: text/html; charset="iso-8859-1" IGMP snooping draft: Solicitation for Comments
 
We have been supporting IGMP snopping on our Accelar switches for many years now. Cisco, has it own propiteary way of doing snopping. Are we standardizing it now. How come there is a renewed interest for this in IETF when it was considered outside its charter a couple of years back.
 
Sundeep.
-----Original Message-----
From: Morten Jagd Christensen [mailto:morten.jagd.christensen@exbit.dk]
Sent: Monday, March 26, 2001 5:39 AM
To: idmr
Subject: IGMP snooping draft: Solicitation for Comments

Hi,

Some of you may have seen that we have posted a draft on this list
on aspects of IGMP snooping switches.

The draft is available as: draft-ietf-idmr-igmp-snoop-00.txt

A presentation of this draft was made at the IETF meeting last
week. Generally I would say that the draft was well received with only
positive comments or encouragements although it will probably move
out of the idmr WG soon.

Since the IETF idmr WG meeting had a limited number of attendees
compared to the number of subscribers of this list (I suppose)  I would
like to solicit for comments on the draft.

So, please send us comments if:

1) You have read the draft and have any comments whatsoever. No comment
is to simple.

2) You are working for a company producing IGMP snooping switches and
have experiences that you want to share. For example regarding interoperability
issues or solutions that you have found to be practical.

3) You know some people who might be interested in this work. Either send me
their email addresses or forward this mail to them.

4) You're IGMP agnostic but still want to share your view on this.

You can either post your reply to the discussion list or you can email me
directly (CC to Frank Solensky) is you don't want your name out in the
public.

Your contribution will be appreciated.

Cheers

/Morten

--------------------------------------------------
Morten Jagd Christensen        | Exbit Technology
M.Sc., Ph.D.                   | www.exbit.com
Network- and System Architect  | mjc@exbit.dk

------_=_NextPart_001_01C0B620.BDB35870-- From owner-idmr@cs.ucl.ac.uk Mon Mar 26 21:36:21 2001 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 VAA26559 for ; Mon, 26 Mar 2001 21:36:19 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 27 Mar 2001 02:03:46 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 27 Mar 2001 02:03:41 +0100 Received: from mail1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 27 Mar 2001 02:03:55 +0100 Received: from bwilliam-t20.cisco.com (syd-equant-client-7.cisco.com [64.104.210.7]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA19011; Mon, 26 Mar 2001 16:59:42 -0800 (PST) Message-Id: <4.3.2.7.2.20010326182407.051f1e50@mail1.cisco.com> X-Sender: bwilliam@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Mar 2001 18:24:57 -0600 To: Sundeep Singatwaria , "'morten.jagd.christensen'" , idmr From: Beau Williamson Subject: RE: IGMP snooping draft: Solicitation for Comments In-Reply-To: <5D630265EF50D311ABB60008C7917DB604593F64@zsc4c004.us.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_7028696==_.ALT" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk --=====================_7028696==_.ALT Content-Type: text/plain; charset="us-ascii" Sundeep, Please be careful about stating what your competition does and does not support to this mailing list which is read by many of our collective customers. Your comment below is misleading and implies that Cisco does not support IGMP Snooping. Cisco *does* support IGMP Snooping as well as having support for CGMP which is another protocol that *is* Cisco proprietary. Having said that, I too think that an attempt to standardize IGMP Snooping is outside of the scope of the IETF. Beau Williamson At 12:15 PM 3/26/2001, Sundeep Singatwaria wrote: > >We have been supporting IGMP snopping on our Accelar switches for many years now. Cisco, has it own propiteary way of doing snopping. Are we standardizing it now. How come there is a renewed interest for this in IETF when it was considered outside its charter a couple of years back. > >Sundeep. >-----Original Message----- >From: Morten Jagd Christensen [mailto:morten.jagd.christensen@exbit.dk] >Sent: Monday, March 26, 2001 5:39 AM >To: idmr >Subject: IGMP snooping draft: Solicitation for Comments > >Hi, > >Some of you may have seen that we have posted a draft on this list >on aspects of IGMP snooping switches. > >The draft is available as: draft-ietf-idmr-igmp-snoop-00.txt > >A presentation of this draft was made at the IETF meeting last >week. Generally I would say that the draft was well received with only >positive comments or encouragements although it will probably move >out of the idmr WG soon. > >Since the IETF idmr WG meeting had a limited number of attendees >compared to the number of subscribers of this list (I suppose) I would >like to solicit for comments on the draft. >So, please send us comments if: > >1) You have read the draft and have any comments whatsoever. No comment >is to simple. > >2) You are working for a company producing IGMP snooping switches and >have experiences that you want to share. For example regarding interoperability >issues or solutions that you have found to be practical. > >3) You know some people who might be interested in this work. Either send me >their email addresses or forward this mail to them. > >4) You're IGMP agnostic but still want to share your view on this. > >You can either post your reply to the discussion list or you can email me >directly (CC to Frank Solensky) is you don't want your name out in the >public. > >Your contribution will be appreciated. > >Cheers > >/Morten > >-------------------------------------------------- >Morten Jagd Christensen | Exbit Technology >M.Sc., Ph.D. | www.exbit.com >Network- and System Architect | mjc@exbit.dk --=====================_7028696==_.ALT Content-Type: text/html; charset="us-ascii" Sundeep,

Please be careful about stating what your competition does and does not support to this mailing list which is read by many of our collective customers. Your comment below is misleading and implies that Cisco does not support IGMP Snooping.  Cisco *does* support IGMP Snooping as well as having support for CGMP which is another protocol that *is* Cisco proprietary.

Having said that, I too think that an attempt to standardize IGMP Snooping is outside of the scope of the IETF.

Beau Williamson

At 12:15 PM 3/26/2001, Sundeep Singatwaria wrote:
 
We have been supporting IGMP snopping on our Accelar switches for many years now. Cisco, has it own propiteary way of doing snopping. Are we standardizing it now. How come there is a renewed interest for this in IETF when it was considered outside its charter a couple of years back.
 
Sundeep.
-----Original Message-----
From: Morten Jagd Christensen [mailto:morten.jagd.christensen@exbit.dk]
Sent: Monday, March 26, 2001 5:39 AM
To: idmr
Subject: IGMP snooping draft: Solicitation for Comments
Hi,

Some of you may have seen that we have posted a draft on this list
on aspects of IGMP snooping switches.

The draft is available as: draft-ietf-idmr-igmp-snoop-00.txt

A presentation of this draft was made at the IETF meeting last
week. Generally I would say that the draft was well received with only
positive comments or encouragements although it will probably move
out of the idmr WG soon.

Since the IETF idmr WG meeting had a limited number of attendees
compared to the number of subscribers of this list (I suppose)  I would
like to solicit for comments on the draft.
So, please send us comments if:

1) You have read the draft and have any comments whatsoever. No comment
is to simple.

2) You are working for a company producing IGMP snooping switches and
have experiences that you want to share. For example regarding interoperability
issues or solutions that you have found to be practical.

3) You know some people who might be interested in this work. Either send me
their email addresses or forward this mail to them.

4) You're IGMP agnostic but still want to share your view on this.

You can either post your reply to the discussion list or you can email me
directly (CC to Frank Solensky) is you don't want your name out in the
public.

Your contribution will be appreciated.

Cheers

/Morten

--------------------------------------------------
Morten Jagd Christensen        | Exbit Technology
M.Sc., Ph.D.                   | www.exbit.com
Network- and System Architect  | mjc@exbit.dk
--=====================_7028696==_.ALT-- From owner-idmr@cs.ucl.ac.uk Tue Mar 27 00:22:39 2001 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 AAA29802 for ; Tue, 27 Mar 2001 00:22:37 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 27 Mar 2001 05:05:30 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 27 Mar 2001 05:05:21 +0100 Received: from mailsrv.psl.com.sg by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 27 Mar 2001 05:05:20 +0100 Received: from netpornote3 ([202.14.154.89]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with SMTP id f2R41oK19713 for ; Tue, 27 Mar 2001 12:01:50 +0800 (SGT) Reply-To: chenghong From: Cheng Hong To: idmr Subject: IGMPv3: draft-ietf-idmr-igmp-v3-07 Date: Tue, 27 Mar 2001 12:08:30 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C0B6B6.A34CDB00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <4.3.2.7.2.20010326182407.051f1e50@mail1.cisco.com> Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0B6B6.A34CDB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I got some questions about the IGMPv3 draft. [1] In section 6.4.1, page 32, the router action table column 2 suggests that upon the reception of IS_EX(B) report on a router of state INCLUDE(A), the router would switch state to EXCLUDE(A*B, B-A), and the actions to take including Delete(A-B). [2] In section 6.5 and appendix A.3, it is suggested that when the group timer expires, the router should switch back to INCLUDE mode, following the rules of EXCLUDE(X,Y) ---> INCLUDE(X). Is that means the router mentioned in [1] would switch back to INCLUDE(A*B) instead of INCLUDE(A) when no host with Exclude mode exists in the subnet? Would this block the traffic from (A-B) while some hosts MAY request? PS: Does the draft suggest that the router would modify it is states every time it receives a current-state report? And as mentioned earlier in the draft that IGMPv3 host would not perform report suppressing. Would this make the router busy at updating it states? Regards Cheng ------=_NextPart_000_0014_01C0B6B6.A34CDB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I got=20 some questions about the IGMPv3 draft.
 
[1]
In=20 section 6.4.1, page 32, the router action table column 2 suggests that = upon the=20 reception of IS_EX(B) report on a router of state INCLUDE(A), the = router=20 would switch state to EXCLUDE(A*B, B-A), and the actions to take = including=20 Delete(A-B).
 
[2]
In=20 section 6.5 and appendix A.3, it is suggested that when the group timer = expires,=20 the router should switch back to INCLUDE mode, following the rules of=20 EXCLUDE(X,Y) ---> INCLUDE(X).
 
Is=20 that means the router mentioned in [1] would switch back to INCLUDE(A*B) = instead=20 of INCLUDE(A) when no host with Exclude mode exists in the subnet? Would = this=20 block the traffic from (A-B) while some hosts MAY = request?
 
 
PS:=20 Does the draft suggest that the router would modify it is states every = time it=20 receives a current-state report? And as mentioned earlier in the draft = that=20 IGMPv3 host would not perform report suppressing. Would this make the = router=20 busy at updating it states?
 
Regards
 
Cheng=20
 
 
------=_NextPart_000_0014_01C0B6B6.A34CDB00-- From owner-idmr@cs.ucl.ac.uk Tue Mar 27 14:53:12 2001 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 OAA27665 for ; Tue, 27 Mar 2001 14:53:11 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 27 Mar 2001 20:12:51 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 27 Mar 2001 20:12:45 +0100 Received: from sj-msg-core-1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 27 Mar 2001 20:12:59 +0100 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA28300; Tue, 27 Mar 2001 11:13:01 -0800 (PST) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA23345; Tue, 27 Mar 2001 11:12:56 -0800 (PST) Message-Id: <200103271912.LAA23345@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Mladen Sablic cc: idmr Subject: Re: IGMP router behaviour when v1 router is present. In-reply-to: Your message of "Tue, 27 Mar 2001 19:09:03 +0100." <018e01c0b6e9$01fd8140$0897ac3e@ukip> Date: Tue, 27 Mar 2001 11:12:56 -0800 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk It is a missconfiguration to have a router configured to operate IGMPv1 and a router configured to operate IGMPv3 on the same link. The only action taken by v3 is to log the error. The administrator must then fix the problem. The protocol behaviour under this condition is not defined. thanks I Mladen Sablic writes: >Hi, > >I have a question about how a router should behave when it hears a V1 Query. > >(section 7.3.1 of draft-ietf-idmr-igmp-v3-07.txt) >Apart from logging a warning should it become a Non-Querier irrespective of >its IP address and just sit and listen to reports OR is this behaviour >deliberately left undefined as there are not that many IGMPv1 routers >out there and all V2 implementations should come up by default as V2? > >Thanks, > >Mladen > From owner-idmr@cs.ucl.ac.uk Tue Mar 27 14:53:25 2001 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 OAA27676 for ; Tue, 27 Mar 2001 14:53:24 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 27 Mar 2001 19:09:01 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 27 Mar 2001 19:08:55 +0100 Received: from alpo.casc.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 27 Mar 2001 19:09:09 +0100 Received: from msablic ([62.172.151.8]) by alpo.casc.com (8.9.1a/8.9.1) with SMTP id NAA25939 for ; Tue, 27 Mar 2001 13:09:05 -0500 (EST) Message-ID: <018e01c0b6e9$01fd8140$0897ac3e@ukip> From: Mladen Sablic To: idmr References: Subject: IGMP router behaviour when v1 router is present. Date: Tue, 27 Mar 2001 19:09:03 +0100 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a question about how a router should behave when it hears a V1 Query. (section 7.3.1 of draft-ietf-idmr-igmp-v3-07.txt) Apart from logging a warning should it become a Non-Querier irrespective of its IP address and just sit and listen to reports OR is this behaviour deliberately left undefined as there are not that many IGMPv1 routers out there and all V2 implementations should come up by default as V2? Thanks, Mladen From owner-idmr@cs.ucl.ac.uk Tue Mar 27 20:34:53 2001 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 UAA06875 for ; Tue, 27 Mar 2001 20:34:52 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 28 Mar 2001 01:10:59 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 28 Mar 2001 01:10:53 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 28 Mar 2001 01:11:08 +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 A321B4CE20; Tue, 27 Mar 2001 19:11:06 -0500 (EST) 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 TAA19873; Tue, 27 Mar 2001 19:11:06 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA01012; Tue, 27 Mar 2001 16:11:05 -0800 (PST) Message-Id: <200103280011.QAA01012@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: mladen.sablic@lucent.com Subject: Re: IGMP router behaviour when v1 router is present. Cc: idmr@cs.ucl.ac.uk References: <018e01c0b6e9$01fd8140$0897ac3e@ukip> Date: Tue, 27 Mar 2001 16:11:05 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Since IGMPv1 did not specify a querier election, many implementations elect the IGMP querier based upon routing protocol neighbors, e.g. the highest IP address PIM neighbor. So, if the highest IP address PIM neighbor is an IGMPv3 router who just shuts up when it hears a v1 Query, then there will be no Querier. Since there's no easy way to deal with it, we left it specified that it's simply an administrative problem to ensure that these are consistent. Bill From owner-idmr@cs.ucl.ac.uk Thu Mar 29 22:18:20 2001 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 WAA00998 for ; Thu, 29 Mar 2001 22:18:19 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 30 Mar 2001 02:37:19 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 30 Mar 2001 02:37:13 +0100 Received: from Exchange.GothamNetworks.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 30 Mar 2001 02:37:27 +0100 Received: FROM exchange.gothamnetworks.com BY exchange.gothamnetworks.com ; Thu Mar 29 20:37:19 2001 -0500 Received: by mail1.gothamnetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Mar 2001 20:37:19 -0500 Message-ID: From: Frank Solensky To: "'Sundeep Singatwaria'" , "'morten.jagd.christensen'" , idmr Subject: RE: IGMP snooping draft: Solicitation for Comments Date: Thu, 29 Mar 2001 20:37:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk > We have been supporting IGMP snopping on our Accelar switches > for many years now. Cisco, has it own propiteary way of doing > snopping. Are we standardizing it now. How come there is a > renewed interest for this in IETF when it was considered > outside its charter a couple of years back. The suggestion was made during the working group meeting last week that this document should go the BCP route instead of "standards track" and would also be handed off into the IGMP working group once it becomes official. I'll admit that the prior round of interest in IGMP snooping predates my activity in the working group and, I believe, Morton's as well. Our sense was that since multiple vendors either already or will soon support this functionality, it would be a good idea to at least identify some of the issues that if overlooked might result in interoperability problems. -- Frank From owner-idmr@cs.ucl.ac.uk Fri Mar 30 14:13:43 2001 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 OAA06423 for ; Fri, 30 Mar 2001 14:13:43 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 30 Mar 2001 18:35:51 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 30 Mar 2001 18:35:44 +0100 Received: from ctron-dnm.cabletron.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 30 Mar 2001 18:35:47 +0100 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id MAA23911; Fri, 30 Mar 2001 12:42:04 -0500 (EST) Received: from cnc-exc2.ctron.com(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma023884; Fri, 30 Mar 01 12:41:59 -0500 Received: by cnc-exc2.ctron.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Mar 2001 12:35:39 -0500 Message-ID: From: "Humphries, Kevin" To: "'morten.jagd.christensen'" Cc: "'idmr@cs.ucl.ac.uk'" Subject: RE: IGMP snooping draft: Solicitation for Comments Date: Fri, 30 Mar 2001 12:35:36 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi all, Having just joined the group I also am not familiar with the past history on this draft, however, when I was asked to fix a L2 snooping bug for my company a while back I spent an inordinate amount of time looking for a draft/standard that would bring my up to speed on how IGMP L2 Snooping should work. I sway on the side of making some sort of a document describing L2 snooping, just for educational purposes if nothing else. Although I would be interested in working on the document. Kevin *-----------------* Kevin Humphries Enterasys Networks