From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 1 01:07:21 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12779 for ; Thu, 1 Mar 2001 01:07:20 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA09986 for ; Wed, 28 Feb 2001 21:07:48 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f2157VL19814 for ; Wed, 28 Feb 2001 21:07:31 -0800 (PST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2157Jb21198 for ; Wed, 28 Feb 2001 21:07:20 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 01 Mar 2001 10:40:47 +0530 Received: from sabaris (rosario.future.futsoft.com [10.0.2.1]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f21AcXc02709 for ; Thu, 1 Mar 2001 16:08:33 +0530 Received: by localhost with Microsoft MAPI; Thu, 1 Mar 2001 10:18:08 +1100 Message-Id: <01C0A238.E9B69820.sabaris@future.futsoft.com> From: Sabaris Reply-To: "sabaris@future.futsoft.com" To: "ssm-interest@external.cisco.com" Date: Thu, 1 Mar 2001 10:18:07 +1100 Organization: FSL X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 unsubscribe ssm-interest From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 1 05:04:13 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28958 for ; Thu, 1 Mar 2001 05:04:12 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA01427 for ; Thu, 1 Mar 2001 00:55:40 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f218tNi01422 for ; Thu, 1 Mar 2001 00:55:23 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy2.cisco.com (8.11.2/8.11.2) with SMTP id f218tDb21209 for ; Thu, 1 Mar 2001 00:55:13 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Mar 2001 08:34:49 +0000 To: Hugh LaMaster cc: MBoned , SSM Subject: Re: New Internet Draft on automatic (end-user) tunneling for SSM In-reply-to: Your message of "Wed, 28 Feb 2001 13:17:00 PST." Date: Thu, 01 Mar 2001 08:34:47 +0000 Message-ID: <16187.983435687@cs.ucl.ac.uk> From: Jon Crowcroft In message , H ugh LaMaster typed: >>UMTP seems like a lot of work to develop/debug/deploy. I think >>the same level of effort applied to deploying native multicast >>might bring more multicast users online. Has anybody attempted >>to survey the Tier-2/3 providers about what they think about >>UMTP multicast vs. native multicast? good question - they are the main sticking point given a lot of tier 1 are doign native multicast my personal intuition is that "akamizing" auto-tunneled multicast across them is the best way but its a zero sum game:if we succeed, they will either run native multicast soon after, or block the tunnels.....so whatever we do, it better be code first, and standards later (of ever) cheers jon From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 1 11:01:51 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08324 for ; Thu, 1 Mar 2001 11:01:51 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA25732 for ; Thu, 1 Mar 2001 06:57:29 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f21EvA511682 for ; Thu, 1 Mar 2001 06:57:10 -0800 (PST) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f21Ev4W29473 for ; Thu, 1 Mar 2001 06:57:05 -0800 (PST) Received: from [209.206.1.50] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 803156; Thu, 01 Mar 2001 09:17:36 -0500 Message-ID: <3A9E5A41.813E3D0E@21rst-century.com> Date: Thu, 01 Mar 2001 09:18:42 -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: Jon Crowcroft CC: Hugh LaMaster , MBoned , SSM , MSDP Mail List Subject: Re: New Internet Draft on automatic (end-user) tunneling for SSM References: <16187.983435687@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello; My personal feeling, based on talking with a lot of service providers, is that they will only provide tunnel relays if they are paid to do it. The unicast traffic that results from tunneling, of course, they will carry without complaint. Whether paying them to do tunnel relay's will be cheaper than just doing unicast failover (as Yahoo does now, and we plan to do soon) is a very open question. Inktomi sells software to "roll your own" automatic tunnels. I do not know what level of interest they have, but they must sell some, as they were promoting it here in SF yesterday. They call it application layer multicast. It seems to be aimed mostly at enterprise networks / intranets. I still do not see how auto tunnels will scale. If my tunnel relay's will only accept a fan-out of 2, then to serve 2048 people will require 10 generations of tunnels (and about 1000 tunnel servers). Even if I accept a fan-out of 5, 2048 people will require ~ 5 generations. This seems like an awful long chain (with accumulation of jitter, packet loss, etc.) and a lot of coordination for an actual, workable, product.(Yes, this is what the routers do for ISM or SSM, but they are designed to do it. They also tend to cost a lot more than I suspect people want to spend for tunnel relay's.) BTW, in conversations with Matt Schmitt (Yahoo/Broadcast.com multicast guy) I found out that, while interested in SSM, they do NOT want to break ISM to achieve it, and DO want ISM and MSDP to continue to work for the forseeable future. He was unaware of the MSDP "black hole" situation caused by the Ramen worm and by the adoption of SSM only domains, but he certainly did not view it as acceptable. Their (514, as of this morning) ISM multicasts save them a lot of money, and will continue at least until SSM is adopted everywhere ISM is. Marshall Jon Crowcroft wrote: > > In message , H > ugh LaMaster typed: > > >>UMTP seems like a lot of work to develop/debug/deploy. I think > >>the same level of effort applied to deploying native multicast > >>might bring more multicast users online. Has anybody attempted > >>to survey the Tier-2/3 providers about what they think about > >>UMTP multicast vs. native multicast? > > good question - they are the main sticking point given a lot of tier > 1 are doign native multicast > > my personal intuition is that "akamizing" auto-tunneled multicast > across them is the best way > > but its a zero sum game:if we succeed, they will either run native > multicast soon after, or block the tunnels.....so whatever we do, it > better be code first, and standards later (of ever) > > > cheers > > jon -- 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-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 1 11:51:35 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10211 for ; Thu, 1 Mar 2001 11:51:34 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA06720 for ; Thu, 1 Mar 2001 07:58:38 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f21FwVr28598 for ; Thu, 1 Mar 2001 07:58:31 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy2.cisco.com (8.11.2/8.11.2) with SMTP id f21Fw6H05386 for ; Thu, 1 Mar 2001 07:58:06 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Mar 2001 15:52:42 +0000 To: tme@21rst-century.com cc: Hugh LaMaster , MBoned , SSM , MSDP Mail List Subject: Re: New Internet Draft on automatic (end-user) tunneling for SSM In-reply-to: Your message of "Thu, 01 Mar 2001 09:18:42 EST." <3A9E5A41.813E3D0E@21rst-century.com> Date: Thu, 01 Mar 2001 15:52:41 +0000 Message-ID: <18856.983461961@cs.ucl.ac.uk> From: Jon Crowcroft In message <3A9E5A41.813E3D0E@21rst-century.com>, Marshall Eubanks typed: >>I still do not see how auto tunnels will scale. If my tunnel relay's will only accept a fan-out of 2, >>then to serve 2048 people will require 10 generations of tunnels (and about 1000 >>tunnel servers). assume that we have the same limit roughly as with the old mbone mrouted tunnel overlay - was fanout of 6 as far as i recall... its still, as yo usay, a problem - in fact, the exact place you want this (at an ACCESS ISPs dslams etc) is where you wont get it... cheers jon i am a big fan of quantium computing - quantum computing allows n bits to store up to 2^n values _simultaneously_ :- with quantum computing, IP multicast becomes much simpler, and ipv6 becomes obsolete... you can simply address all the end systems in a group using all their seperate IP unicast addresses, but it takes no more bits than a current IP header. of course, you need a $1M MRI/interferometer in all your routers to sort out the packet entanglement, but hey, thats today's prices; when quantum internet addressing and routing meets optical switching the world will be a safer place, probably. a neat side effect of quantum ip (quip, TM) is that we can employ schroedinger's approach to mesage payload encoding too, which means that the fbi's carnivore systems won't be able to decode what we've sent (well they will, but they will have _chosen_ what to observe by observing it, so it can't be used as evidence in court about what we did send) - feynman said it all of course. From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 1 13:03:11 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13598 for ; Thu, 1 Mar 2001 13:03:11 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA29173 for ; Thu, 1 Mar 2001 09:01:08 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f21H0o605821 for ; Thu, 1 Mar 2001 09:00:51 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f21H0jW17901 for ; Thu, 1 Mar 2001 09:00:46 -0800 (PST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f21Givs10011; Thu, 1 Mar 2001 17:45:01 +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 C1256A02.005BFA1F; Thu, 1 Mar 2001 17:44:38 +0100 Message-ID: <3A9E7C75.BDC8541C@alcatel.be> Date: Thu, 01 Mar 2001 17:44:37 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jon Crowcroft CC: tme@21rst-century.com, Hugh LaMaster , MBoned , SSM , MSDP Mail List Subject: Re: New Internet Draft on automatic (end-user) tunneling for SSM References: <18856.983461961@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit and we will have communication without delay by applying the EPR paradox :-) Jon Crowcroft wrote: > > In message <3A9E5A41.813E3D0E@21rst-century.com>, Marshall Eubanks typed: > > >>I still do not see how auto tunnels will scale. If my tunnel relay's will only accept a fan-out of 2, > >>then to serve 2048 people will require 10 generations of tunnels (and about 1000 > >>tunnel servers). > > assume that we have the same limit roughly as with the old mbone > mrouted tunnel overlay - was fanout of 6 as far as i recall... > its still, as yo usay, a problem - in fact, the exact place you want > this (at an ACCESS ISPs dslams etc) is where you wont get it... > > cheers > > jon > > i am a big fan of quantium computing - quantum computing allows n bits > to store up to 2^n values _simultaneously_ :- with quantum computing, > IP multicast becomes much simpler, and ipv6 becomes obsolete... > you can simply address all the end systems in a group using > all their seperate IP unicast addresses, but it takes no more bits > than a current IP header. > > of course, you need a $1M MRI/interferometer in all your routers to > sort out the packet entanglement, but hey, thats today's prices; > when quantum internet addressing and routing meets optical switching > the world will be a safer place, probably. a neat side effect of > quantum ip (quip, TM) is that we can employ schroedinger's approach to > mesage payload encoding too, which means that the fbi's carnivore > systems won't be able to decode what we've sent (well they will, but > they will have _chosen_ what to observe by observing it, so it can't > be used as evidence in court about what we did send) - feynman said it > all of course. From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 1 16:24:11 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23998 for ; Thu, 1 Mar 2001 16:24:10 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA16539 for ; Thu, 1 Mar 2001 12:19:49 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f21KJdi04068 for ; Thu, 1 Mar 2001 12:19:39 -0800 (PST) Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.132.150]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f21KJSG05595 for ; Thu, 1 Mar 2001 12:19:28 -0800 (PST) Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id MAA19755; Thu, 1 Mar 2001 12:05:44 -0800 (PST) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Thu, 1 Mar 2001 12:05:44 -0800 (PST) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: MBoned , SSM , MSDP Mail List Subject: Re: New Internet Draft on automatic (end-user) tunneling for SSM In-Reply-To: <3A9E5A41.813E3D0E@21rst-century.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 1 Mar 2001, Marshall Eubanks wrote: > My personal feeling, based on talking with a lot of service providers, is that ^^^^^^^^^^^^^^^^^ I'm not sure if you are talking about Tier-1 or Tier-2/3 service providers. I would guess that some Tier-1 providers will do this "for free" as long as they could be sure that it would have near-zero impact on their core/edge routers, as stated previously. To me, that means that that should be a way for the protocols to allow all control traffic to be forwarded directly to the helper router without CPU intervention-- as discussed previously, when you are forwarding at OC-12/OC-48/OC-192 speeds, you need to maintain pretty strict separation of routing processes and the switching functionality in the router. (MSDP bursty-source encapsulation is something that violates this, of course, so I would like to see alternatives proposed for that.) The Tier-2/3 providers are in a different economic situation. So, I'm assuming that you are implying Tier-2/3 here. > they will only provide tunnel relays if they are paid to do it. The unicast > traffic that results from tunneling, of course, they will carry without > complaint. I wonder if the Tier-2/3 providers will see it that way if they ken how much tunnel traffic is being shoved at them. Of course, the traffic from N streaming video streams is the same, but, I'm worried about the knowledge gap-- they may see it as different, even if it isn't really. > I still do not see how auto tunnels will scale. If my tunnel relay's will only accept a fan-out of 2, > then to serve 2048 people will require 10 generations of tunnels (and about 1000 > tunnel servers). Even > if I accept a fan-out of 5, 2048 people will require ~ 5 generations. I don't think it *will* scale. That is impossible, actually. But, it might scale up just well enough to provide an incentive for Tier-2/3 providers to turn on multicast. I'm agnostic on that particular point. I think the fanout you can get from a mid-size router can be much more that you state, though. I know that you can do replication for 10-20 tunnels on a midsize software-forwarded router -- the limiting factor is the total outbound traffic -- that is, how large are the streams? Once this is up and running, there would be an incentive for the downstream Tier-2/3 provider to turn on multicast and save 20-30 Mbits/s traffic incoming. The incentive for the Tier-1 provider would be that by intercepting the requests at the edge, they would save the same amount of traffic over their backbones, so they get that immediate benefit, plus, the long-term benefit of eventually having the Tier-2/3 provider turn on native multicast. > This seems like an awful long chain (with accumulation of jitter, packet loss, etc.) and a > lot of coordination for an actual, workable, product.(Yes, this is what the routers > do for ISM or SSM, but they are designed to do it. They also tend to cost a lot more than > I suspect people want to spend for tunnel relay's.) From the Tier-1 provider's perspective, I think this is the wrong cost model. The incentive for the Tier-1 provider would be to push the traffic out to the edge; if a mid-size router can provide the replication at the edge and save the same core bandwidth, that potentially can save a lot of money-- possibly even enough to justify a mid-sized router directly. In addition, the mid-sized tunnel router is an investment in providing strong encouragement for the downstream provider to support multicast. I'm still not convinced about it, mind you, but, I can see that it could give Tier-2/3 providers the encouragement they need to implement native multicast. > Jon Crowcroft wrote: > > > > In message , H > > ugh LaMaster typed: > > > > >>UMTP seems like a lot of work to develop/debug/deploy. I think > > >>the same level of effort applied to deploying native multicast > > >>might bring more multicast users online. Has anybody attempted > > >>to survey the Tier-2/3 providers about what they think about > > >>UMTP multicast vs. native multicast? > > > > good question - they are the main sticking point given a lot of tier > > 1 are doign native multicast > > > > my personal intuition is that "akamizing" auto-tunneled multicast > > across them is the best way > > > > but its a zero sum game:if we succeed, they will either run native > > multicast soon after, or block the tunnels..... Agreed. That makes me question the effort involved, of course. But, as stated above, it could be worth it *if* it motivates understaffed Tier-2/3 providers to take the time to learn a little about multicast and make the effort to turn it on. I guess I don't have a good feel at this point for how Tier-2/3 providers view multicast, and, would view this tunneling approach. On another point: I hadn't really thought about the launcher application also launching a tunneling process. That is a good idea; it obviously works similarly for VPN client software, so it could probably work here, too; that way, you don't necessarily need to modify the apps. Putting it all in the launcher, which is probably for its part a browser plugin, is a good way to simplify the problem for the end user. So, I'll concede that point. -- Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov NASA Ames Research Center Or: lamaster@nren.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Fri Mar 2 18:52:11 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24979 for ; Fri, 2 Mar 2001 18:52:10 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA04858 for ; Fri, 2 Mar 2001 14:42:36 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f22MgHL06986 for ; Fri, 2 Mar 2001 14:42:17 -0800 (PST) Received: from mail.sonicity.com ([209.213.209.46]) by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f22MgBC25323 for ; Fri, 2 Mar 2001 14:42:12 -0800 (PST) Message-Id: <200103022242.f22MgBC25323@proxy1.cisco.com> Received: (qmail 5269 invoked from network); 2 Mar 2001 22:39:14 -0000 Received: from dhcp-1-246.int.sonicity.com (172.16.2.246) by mail.sonicity.com with SMTP; 2 Mar 2001 22:39:14 -0000 From: Thomas "H." Ptacek To: ssm-interest@external.cisco.com Content-Type: text/plain X-Mailer: Evolution (0.8 - Preview Release) Date: 02 Mar 2001 14:39:14 -0800 Mime-Version: 1.0 subscribe ssm-interest tqbf@sonicity.com From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Sat Mar 3 01:40:19 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06360 for ; Sat, 3 Mar 2001 01:40:18 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA05824 for ; Fri, 2 Mar 2001 21:05:47 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f2355TO26657 for ; Fri, 2 Mar 2001 21:05:29 -0800 (PST) Received: from polar.brownbear.com (polar.brownbear.com [63.67.193.100]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2355OC29873 for ; Fri, 2 Mar 2001 21:05:25 -0800 (PST) Received: from CJ41225A [65.9.41.145] by polar.brownbear.com (SMTPD32-6.06) id AAC91A0116; Fri, 02 Mar 2001 22:02:01 -0700 Message-ID: <006801c0a3b9$0d1aa0a0$91290941@reston1.va.home.com> From: "Zaid" To: References: <01C0A238.E9B69820.sabaris@future.futsoft.com> Date: Sat, 3 Mar 2001 00:07:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit unsubscribe ssm-interest From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Sat Mar 3 07:37:20 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18473 for ; Sat, 3 Mar 2001 07:37:19 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id DAA25094 for ; Sat, 3 Mar 2001 03:40:03 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f23Bds929939 for ; Sat, 3 Mar 2001 03:39:54 -0800 (PST) Received: from NOD.RESTON.MCI.NET ([166.60.6.38]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f23BdVv08570 for ; Sat, 3 Mar 2001 03:39:31 -0800 (PST) Received: from htruong ([166.60.18.121]) by shoe.reston.mci.net (PMDF V6.0-24 #47392) with SMTP id <01K0R162XOQAA0UDBZ@shoe.reston.mci.net> for ssm-interest@external.cisco.com; Sat, 03 Mar 2001 06:36:28 -0500 (EST) Date: Sat, 03 Mar 2001 06:34:26 -0500 From: "Hieu C. Truong" To: ssm-interest@external.cisco.com Reply-to: htruong@MCI.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT subscribe ssm-interest From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Sat Mar 3 15:53:39 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25033 for ; Sat, 3 Mar 2001 15:53:38 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA17926 for ; Sat, 3 Mar 2001 11:09:51 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f23J9lw02800 for ; Sat, 3 Mar 2001 11:09:47 -0800 (PST) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f23J9hr00980 for ; Sat, 3 Mar 2001 11:09:43 -0800 (PST) Received: from [216.8.13.209] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 803837; Sat, 03 Mar 2001 13:43:02 -0500 Message-ID: <3AA13B99.71B09A9D@21rst-century.com> Date: Sat, 03 Mar 2001 13:44:42 -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: Zaid CC: ssm-interest@external.cisco.com Subject: Re: References: <01C0A238.E9B69820.sabaris@future.futsoft.com> <006801c0a3b9$0d1aa0a0$91290941@reston1.va.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Zaid; I'm not sure that this is how to unsubscribe... BUT - were you ever able to fix our 65 second frame relay problem ? What exactly was it, anyway... Zaid wrote: > > unsubscribe ssm-interest -- 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-extdom.ssm-interest@sj-msg-core-1.cisco.com Sat Mar 3 20:00:25 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28855 for ; Sat, 3 Mar 2001 20:00:25 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA19476 for ; Sat, 3 Mar 2001 15:47:26 -0800 (PST) From: did342@arabia.com Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f23Nl7c05806 for ; Sat, 3 Mar 2001 15:47:07 -0800 (PST) Received: from sudanmail.net ([212.0.148.19]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f23Nkxr18135 for ; Sat, 3 Mar 2001 15:47:00 -0800 (PST) Received: from ns.sbbsonline.com [206.216.141.97] by sudanmail.net (SMTPD32-6.00) id A494F170134; Sat, 03 Mar 2001 20:14:44 +0200 Message-ID: <000019f63781$0000332a$0000386c@mailer.ug.eds.com> To: Subject: Brand New Email Pager FR-EE 1203 Date: Sat, 03 Mar 2001 12:04:53 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: did342@arabia.com Content-Transfer-Encoding: quoted-printable Brand New Pager for FR-EE!

No long term contract
No big prepayment of airtime
No credit check

Put Free pagers on your kids - Give one to your loved ones - For FR-EE

Here at Paging America we are excited to be offering you this exclusive, t= op of the line, full featured pager in your choice
of color for FR-EE. This side viewable display pager is one of the smalles= t and lightest pagers on the market today.


Call 877-699-8545 to be Guaranteed Your FR-EE Pager Today


Your pager will hold up to 20 numeric messages. It has 9 musi alerts and s= ilent vibration. New FLEX technology provides three
times the battery life. Also, message time and date stamping and smart ala= rm so you can set a daily or weekly reminder.
This pager comes in black, teal and blue.

To receive your free pager all we ask is that you allow us to provide you = with the monthly airtime cancelable at any time.
There is no long term contract.
Just call the toll free number and we'll ship your Free pager to you imme= diately in your choice of color already programmed with
a local telephone number for your town.

Make this easy phone call and we will deliver your pager immediately.


Call 877-699-8545 to get in on this exciting offer today


Brand New Pager for FR-EE!=


No long term contract

From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Mon Mar 5 17:54:28 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08756 for ; Mon, 5 Mar 2001 17:54:28 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA23156 for ; Mon, 5 Mar 2001 13:39:14 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f25LdAi02862 for ; Mon, 5 Mar 2001 13:39:10 -0800 (PST) Received: from ns.live.com (ns.live.com [208.184.148.162]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f25Lcsn00095 for ; Mon, 5 Mar 2001 13:38:54 -0800 (PST) Received: (from rsf@localhost) by ns.live.com (8.9.3/8.9.3) id NAA47790; Mon, 5 Mar 2001 13:34:07 -0800 (PST) (envelope-from rsf) Message-Id: <4.3.1.1.20010305115331.00b45960@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 05 Mar 2001 13:33:59 -0800 To: MBoned , SSM From: Ross Finlayson Subject: Re: New Internet Draft on automatic (end-user) tunneling for SSM In-Reply-To: <3A9E5A41.813E3D0E@21rst-century.com> References: <16187.983435687@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed If automatic multicast tunneling is to succeed (and thus spur the deployment of multicast throughout the Internet), it's important not only that the actual tunneling *mechanism* be automatic, but also that the *deployment* of this mechanism happen automatically. What I mean by this is that if network providers (at whatever 'tier') are required to make an explicit decision to install new infrastructure specifically for multicast tunneling (e.g., tunneling relays, anycast routes, etc.), then it's unlikely that many of them will make the effort to do this. (As Marshall Eubanks noted, most of them wouldn't install this unless they got paid to do so - but if you're going to pay providers to do something, you might as well pay them to turn on native multicast; that's what broadcast.com did. In any case, we should never lose sight of the fact that one of the promises of multicast is the 'democratizing' effect that it has on content providers - even content providers with limited means should be able to reach arbitrary-sized audiences.) Instead, the best way to deploy multicast tunneling is to have this happen automatically as providers upgrade their routers to support multicast. I.e., when a provider makes a decision to upgrade his routers, he can know that he's also getting support multicast tunneling (so that remaining legacy, non-multicast-capable routers below him can also participate in multicast). Of course, the provider can always disable the tunneling functionality (or tweak parameters such as max fan-out) if he wishes. But they should not be required to install anything separate to make tunneling happen. This is one of the key facets of the "URI" proposal (aka. "UDP router intercept"; draft-finlayson-mboned-autotunneling-00.txt). Assuming that SSM becomes as popular as many people hope, many providers will be wanting to upgrader their routers to support SSM. It would be great if they could automatically get tunneling support at the same time. Focusing on SSM rather than ISM (at least at first) makes the 'tunnel endpoint location' problem easier. In the "URI" proposal, you don't need any separate tunnel location mechanism (or infrastructure). Instead, a tunnel endpoint ('slave') is found automatically by the JOIN_GROUP message sent from the end node towards the SSM source. (This is the 'router intercept' mechanism; the challenge, of course, will be to see if routers can implement this efficiently.) In contrast, I worry about how easy it would be to deploy schemes that require a separate 'tunnel endpoint location' mechanism. In particular, the "AMT" draft (Thaler at al) proposes using "anycast" to find tunnel endpoints. However, do we expect anycast to be widely available - even by users of J. Random Non-Multicast-Connected ISPs? Aren't some providers likely to filter out anycast routes (because of the length of their 'prefix')? Ross. From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Mon Mar 5 20:29:58 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13056 for ; Mon, 5 Mar 2001 20:29:57 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA09322 for ; Mon, 5 Mar 2001 16:32:36 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f260WIi28592 for ; Mon, 5 Mar 2001 16:32:18 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f260WIp12128 for ; Mon, 5 Mar 2001 16:32:19 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 5 Mar 2001 16:31:26 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Mar 2001 16:31:22 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 5 Mar 2001 16:31:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4658.0 content-class: urn:content-classes:message Subject: RE: New Internet Draft on automatic (end-user) tunneling for SSM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 5 Mar 2001 16:31:21 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657420FDA4@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: New Internet Draft on automatic (end-user) tunneling for SSM Thread-Index: AcClwLgn96wacmiVRjGRKHL4btVFegAEy+ug From: "Dave Thaler" To: "Ross Finlayson" Cc: "MBoned" , "SSM" X-OriginalArrivalTime: 06 Mar 2001 00:31:21.0770 (UTC) FILETIME=[C4AD10A0:01C0A5D4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA13056 Ross writes: > In contrast, I worry about how easy it would be to deploy > schemes that > require a separate 'tunnel endpoint location' mechanism. In > particular, > the "AMT" draft (Thaler at al) proposes using "anycast" to > find tunnel > endpoints. However, do we expect anycast to be widely > available - even by > users of J. Random Non-Multicast-Connected ISPs? Aren't some > providers > likely to filter out anycast routes (because of the length of > their 'prefix')? If you read the draft, you'll see that the answer to your last question is "yes which is why it uses an anycast prefix not just a /32 anycast address". As a result, the answer to your next-to-last question is "yes, this type of anycast is widely available now". This same discussion for IPv6 connectivity happened in the NGtrans WG regarding 6to4 a while ago, with the consensus being the same mechanism used in the AMT draft. Chewing up lots of address space to get around prefix filters is certainly not a general solution to anycast. However, for a few special-cases (such as relieving different address space problems, for example), it is seen as acceptable. -Dave From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Mon Mar 5 21:21:25 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14050 for ; Mon, 5 Mar 2001 21:21:24 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA17042 for ; Mon, 5 Mar 2001 17:30:55 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f261UaQ28249 for ; Mon, 5 Mar 2001 17:30:36 -0800 (PST) Received: from mailweb7.rediffmail.com (IDENT:qmailr@[202.54.124.152]) by proxy3.cisco.com (8.11.2/8.11.2) with SMTP id f261Uap03603 for ; Mon, 5 Mar 2001 17:30:37 -0800 (PST) Received: (qmail 8353 invoked by uid 510); 6 Mar 2001 00:27:42 -0000 Date: 6 Mar 2001 00:27:42 -0000 Message-ID: <20010306002742.8352.qmail@mailweb7.rediffmail.com> Received: from unknown (134.193.111.189) by rediffmail.com via HTTP; 06 Mar 2001 00:27:42 -0000 MIME-Version: 1.0 To: "tme@21rst-century.com" , "J.Crowcroft@cs.ucl.ac.uk" Subject: I2 meeting... CC: "lamaster@nren.nasa.gov" , "mboned@network-services.uoregon.edu" , "ssm-interest@external.cisco.com" , "msdp@antc.uoregon.edu" From: "hitesh ruparel" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all.. will the i2 meeting be multicast...if so let me know as i wont make it... rgds hitesh ------------- Original Message -------------- Marshall Eubanks wrote: To:Jon Crowcroft From:Marshall Eubanks Date:Thu, 01 Mar 2001 09:18:42 -0500 CC:Hugh LaMaster , MBoned , SSM , MSDP Mail List Subject:Re: New Internet Draft on automatic (end-user) tunneling for SSM Hello; My personal feeling, based on talking with a lot of service providers, is that they will only provide tunnel relays if they are paid to do it. The unicast traffic that results from tunneling, of course, they will carry without complaint. Whether paying them to do tunnel relay's will be cheaper than just doing unicast failover (as Yahoo does now, and we plan to do soon) is a very open question. Inktomi sells software to "roll your own" automatic tunnels. I do not know what level of interest they have, but they must sell some, as they were promoting it here in SF yesterday. They call it application layer multicast. It seems to be aimed mostly at enterprise networks / intranets. I still do not see how auto tunnels will scale. If my tunnel relay's will only accept a fan-out of 2, then to serve 2048 people will require 10 generations of tunnels (and about 1000 tunnel servers). Even if I accept a fan-out of 5, 2048 people will require ~ 5 generations. This seems like an awful long chain (with accumulation of jitter, packet loss, etc.) and a lot of coordination for an actual, workable, product.(Yes, this is what the routers do for ISM or SSM, but they are designed to do it. They also tend to cost a lot more than I suspect people want to spend for tunnel relay's.) BTW, in conversations with Matt Schmitt (Yahoo/Broadcast.com multicast guy) I found out that, while interested in SSM, they do NOT want to break ISM to achieve it, and DO want ISM and MSDP to continue to work for the forseeable future. He was unaware of the MSDP "black hole" situation caused by the Ramen worm and by the adoption of SSM only domains, but he certainly did not view it as acceptable. Their (514, as of this morning) ISM multicasts save them a lot of money, and will continue at least until SSM is adopted everywhere ISM is. Marshall Jon Crowcroft wrote: > > In message , H > ugh LaMaster typed: > > >>UMTP seems like a lot of work to develop/debug/deploy. I think > >>the same level of effort applied to deploying native multicast > >>might bring more multicast users online. Has anybody attempted > >>to survey the Tier-2/3 providers about what they think about > >>UMTP multicast vs. native multicast? > > good question - they are the main sticking point given a lot of tier > 1 are doign native multicast > > my personal intuition is that "akamizing" auto-tunneled multicast > across them is the best way > > but its a zero sum game:if we succeed, they will either run native > multicast soon after, or block the tunnels.....so whatever we do, it > better be code first, and standards later (of ever) > > > cheers > > jon -- 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 _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Mon Mar 5 22:40:07 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17321 for ; Mon, 5 Mar 2001 22:40:07 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA13753 for ; Mon, 5 Mar 2001 18:33:11 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f262X7N02744 for ; Mon, 5 Mar 2001 18:33:07 -0800 (PST) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f262X2v24602 for ; Mon, 5 Mar 2001 18:33:02 -0800 (PST) Received: from [216.8.12.247] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 810243; Mon, 05 Mar 2001 21:16:27 -0500 Message-ID: <3AA4485A.B3A2FCE6@21rst-century.com> Date: Mon, 05 Mar 2001 21:15:54 -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: hitesh ruparel CC: "J.Crowcroft@cs.ucl.ac.uk" , "lamaster@nren.nasa.gov" , "mboned@network-services.uoregon.edu" , "ssm-interest@external.cisco.com" , "msdp@antc.uoregon.edu" Subject: Re: I2 meeting... References: <20010306002742.8352.qmail@mailweb7.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes. Go to the multicast calendar ! That's why we set it up : http://darkwing.uoregon.edu/~llynch/calendar/calendar.cgi hitesh ruparel wrote: > > Hi all.. > > will the i2 meeting be multicast...if so let me know as i wont make it... > > rgds > hitesh Here is the announcement : Subject: multicast-events: Internet2 members Meeting Live Netcast Date: Wed, 28 Feb 2001 14:47:35 -0800 (PST) From: "Lucy E. Lynch" To: The Spring 2001 Internet2 Member Meeting will be held March 7-9, 2001 at the Marriott Wardman Park Hotel, in Washington, D.C.The program committee and Internet2 staff are working on both content and logistics to ensure a successful experience for the Internet2 member community.The goal is to have a working meeting, where members can discuss the future of high performance networking and formulate activities for the months ahead. The Spring Member Meeting has a focus on policy and strategic planning, to complement the more technical and applications focus of the Fall meeting. Breakout sessions are organized into four tracks: Advanced Applications Middleware Network Planning and Engineering Relationships and Partnerships The University of Oregon with the support of Cisco Systems will netcast the Internet2 members meeting in Washington D.C.The sessions will be encoded with H.261 and MPEG-1 codecs. Session announcements are currently live for testing - 1.H.261 Broadcast. The H.261 stream will be visible to users with the standard multicast tools from the UCL Mbone Conferencing applications archive, and most other free and commercial tools that can can handle H.261/PCM. For information about setting up MBone tools for Windows95/NT, Macintosh, and Unix, see: http://www.uoregon.edu/~joelja/project/mbone/mbone.html 2.MPEG-1 Broadcast. The MPEG-1 stream will be generated using IP/TV, a streaming video server from Cisco. The IP/TV MPEG-1 stream will be visible either with IP/TV, MacTV, or MIM. Windows users can download IP/TV 3.1 from: http://videolab.uoregon.edu/download.html Macintosh users can download MacTV from: http://www.iwitnesstv.com/ UNIX users can download MIM from: http://videolab.uoregon.edu/mim/ H.261 audio - 224.2.175.151/23042 video - 224.2.157.253/58940 MPEG1 audio - 224.2.128.175/20530 video - 224.2.235.37/63718 Note: news about up-coming events can be found at: http://darkwing.uoregon.edu/~llynch/calendar/ This site includes forms for creating event announcements, a calendar & the multicast-events list archives. Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch@darkwing.uoregon.edu (541) 346-1774 > > ------------- Original Message -------------- > Marshall Eubanks wrote: > To:Jon Crowcroft > From:Marshall Eubanks > Date:Thu, 01 Mar 2001 09:18:42 -0500 > CC:Hugh LaMaster , > MBoned , > SSM , > MSDP Mail List > Subject:Re: New Internet Draft on automatic (end-user) tunneling for SSM > > Hello; > > My personal feeling, based on talking with a lot of service providers, is that > they will only provide tunnel relays if they are paid to do it. The unicast > traffic that results from tunneling, of course, they will carry without > complaint. Whether paying them to do tunnel relay's > will be cheaper than just doing unicast failover (as Yahoo does now, and we > plan to do soon) is a very open question. > > Inktomi sells software to "roll your own" automatic tunnels. I do > not know what level of interest they have, but they must sell some, > as they were promoting it here in SF yesterday. They call it > application layer multicast. It seems to be aimed mostly at > enterprise networks / intranets. > > I still do not see how auto tunnels will scale. If my tunnel relay's will only accept a fan-out of 2, > then to serve 2048 people will require 10 generations of tunnels (and about 1000 > tunnel servers). Even > if I accept a fan-out of 5, 2048 people will require ~ 5 generations. > This seems like an awful long chain (with accumulation of jitter, packet loss, etc.) and a > lot of coordination for an actual, workable, product.(Yes, this is what the routers > do for ISM or SSM, but they are designed to do it. They also tend to cost a lot more than > I suspect people want to spend for tunnel relay's.) > > BTW, in conversations with Matt Schmitt (Yahoo/Broadcast.com multicast guy) > I found out that, while interested in SSM, they do NOT want to break ISM to > achieve it, and DO want ISM and MSDP to continue to work for the forseeable > future. He was unaware of the MSDP "black hole" situation caused by the Ramen > worm and by the adoption of SSM only domains, but he certainly did not > view it as acceptable. Their (514, as of this morning) ISM multicasts > save them a lot of money, and will > continue at least until SSM is adopted everywhere ISM is. > > Marshall > > Jon Crowcroft wrote: > > > > In message , H > > ugh LaMaster typed: > > > > >>UMTP seems like a lot of work to develop/debug/deploy. I think > > >>the same level of effort applied to deploying native multicast > > >>might bring more multicast users online. Has anybody attempted > > >>to survey the Tier-2/3 providers about what they think about > > >>UMTP multicast vs. native multicast? > > > > good question - they are the main sticking point given a lot of tier > > 1 are doign native multicast > > > > my personal intuition is that "akamizing" auto-tunneled multicast > > across them is the best way > > > > but its a zero sum game:if we succeed, they will either run native > > multicast soon after, or block the tunnels.....so whatever we do, it > > better be code first, and standards later (of ever) > > > > > > cheers > > > > jon > > -- > > 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 > > _____________________________________________________ > Chat with your friends as soon as they come online. Get Rediff Bol at > http://bol.rediff.com -- Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements 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-extdom.ssm-interest@sj-msg-core-4.cisco.com Tue Mar 6 08:22:16 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10850 for ; Tue, 6 Mar 2001 08:22:15 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id EAA16021 for ; Tue, 6 Mar 2001 04:04:28 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f26C4Oj11206 for ; Tue, 6 Mar 2001 04:04:24 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f26C4Pp13541 for ; Tue, 6 Mar 2001 04:04:26 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07809; Tue, 6 Mar 2001 06:50:34 -0500 (EST) Message-Id: <200103061150.GAA07809@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ssm-interest@external.cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-holbrook-ssm-arch-02.txt Date: Tue, 06 Mar 2001 06:50:33 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Source-Specific Multicast for IP Author(s) : H. Holbrook, B. Cain Filename : draft-holbrook-ssm-arch-02.txt Pages : 14 Date : 05-Mar-01 IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols [IANA-ALLOCATION]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-holbrook-ssm-arch-02.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-holbrook-ssm-arch-02.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-holbrook-ssm-arch-02.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: <20010305125151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-holbrook-ssm-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-holbrook-ssm-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010305125151.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Wed Mar 7 06:30:38 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29619 for ; Wed, 7 Mar 2001 06:30:38 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA06329 for ; Tue, 6 Mar 2001 14:55:06 -0800 (PST) From: mk.joseph@verizonmail.com Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f26Mskk17808 for ; Tue, 6 Mar 2001 14:54:46 -0800 (PST) Received: from ns.iball.com.cn ([210.77.58.162]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f26MorZ12693 for ; Tue, 6 Mar 2001 14:50:54 -0800 (PST) Received: by ns.iball.com.cn id GAA0000016609; Wed, 7 Mar 2001 06:47:31 +0800 (CST) Received: from nobody@localhost by (8.8.5/8.6.5) with SMTP id GAA08239 for ; Tue, 06 Mar 2001 17:30:45 -0600 (EST) To: ssm-interest@external.cisco.com Message-ID: <199912112040.MAA94626@addr6.addr.com> Date: Tue, 06 Mar 01 17:30:45 EST Subject: Simple Fail-Safe Homebased E-Biz !! Hi, I thought I would drop you a quick note and let you know that there is an exciting and very profitable SELF-RUN online business which has exploded in 2000 and continues to grow in 2001! How would you like to quit your job, become your own boss, and build up enough residual income to support yourself for the rest of your life? Forget the old-days of Network Marketing where you had to "show the plan" and meet at the local high school for a "ra-ra" meeting. Our company offers you an opportunity that can be operated from in-front of your computer screen. Imagine the feeling of being able to offer our opportunity and products to millions of people in over 42 Countries and Territories around the World. Not only do you have the ability to own a profitable home-based business which is operating in the United States but you also have the potential of having distributors all over the World. Make a well informed decision which will impact your future today ! Simply click below to request more Information About this great opportunity! via email promptly: mailto:time_iz_now@verizonmail.com?subject=Send-info It will ONLY take a minute to find out. You will be glad that you did! I received your e-mail as someone interested in Internet Business Opportunities. If I received your e-mail in error, or you are no longer interested, click here to be removed. Be sure REMOVE is in the Subject Title and you will not be contacted again: mail to: mark2001@verizonmail.com Thank You, Mark From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Wed Mar 7 14:01:45 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17777 for ; Wed, 7 Mar 2001 14:01:44 -0500 (EST) Received: from holbrook-laptop.cisco.com (holbrook-dsl4.cisco.com [10.19.148.189]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA10649 for ; Wed, 7 Mar 2001 09:26:23 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id EE1CCC3A73; Wed, 7 Mar 2001 09:26:14 -0800 (PST) From: Hugh Holbrook To: ssm-interest@external.cisco.com Subject: ssm wg drafts Reply-To: holbrook@cisco.com Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Message-Id: <20010307172614.EE1CCC3A73@holbrook-laptop.cisco.com> Date: Wed, 7 Mar 2001 09:26:14 -0800 (PST) I've had several questions about this, so I want to clarify the ssm wg status and the IETF policy on internet draft naming. It's a not-well-publicized fact of the IETF that working group documents need not be named draft-ietf--foo, although drafts that start out as working group drafts are generally named that way. The SSM working group currently has two working drafts: draft-holbrook-ssm-arch-02.txt draft-bhattach-pim-ssm-00.txt. Neither document was initially submitted as a working group draft and so neither is named draft-ietf-ssm-*. [ The latter document has now expired and when the authors update it, it could come back with a different name. ] We decided to adopt these documents after our first meeting in pittsburgh. The former is slated to become a standards track RFC, and the latter is headed to become an informational RFC. I've been remiss in getting the IETF web page updated to reflect this, but this has been an action item in the iesg secretary's queue for a while now and the web page should soon reflect it. -Hugh From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Wed Mar 7 23:20:24 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03279 for ; Wed, 7 Mar 2001 23:20:23 -0500 (EST) 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) 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-extdom.ssm-interest@sj-msg-core-3.cisco.com Mon Mar 12 21:10:05 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27329 for ; Mon, 12 Mar 2001 21:10:04 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id QAA22843 for ; Mon, 12 Mar 2001 16:59:04 -0800 (PST) From: did342@arabia.com Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2D10E113518 for ; Mon, 12 Mar 2001 17:00:15 -0800 (PST) Received: from venus.ecgedas.com.mx (na-228-51.na.avantel.net.mx [148.245.228.51] (may be forged)) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2D0uUL10781 for ; Mon, 12 Mar 2001 16:56:30 -0800 (PST) Received: from mailhost.telematics.com [63.62.253.194] by venus.ecgedas.com.mx (SMTPD32-5.05) id A45A700A0; Mon, 12 Mar 2001 16:57:30 -0600 Message-ID: <000006ed3c2a$0000478e$00005e71@kwantlen.bc.ca> To: Subject: Tired of Cable TV raising there rates!!!! Date: Mon, 12 Mar 2001 17:06:28 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: did342@arabia.com Content-Transfer-Encoding: quoted-printable Tired of Cable TV raising their rates!!!
Get Satellite TV
YES ---YOU CAN WATCH DIFFERENT CHANNELS ON MULTIPLE TV'S
YES ---YOU CAN GET LOCAL STATIONS
Order Dish Network System with a one year plan, get FREE two receivers and=
the 18" Dish with FREE basic professional installation.

Why Bother? For $40.99 Get both receivers and the Top 100 Stations!
With only one receiver and the Dish $35.99
Local Channels add $5.00

You will be charged a one time $49.99 fee when you order which includes yo= ur
first months service for FREE.
THAT S IT!
FLIP TO SATELLITE... ITS DIGITAL.. ITS GREAT...
YOU'LL LOVE IT.
Ready? Order by phone 1-888-235-5285
or e-mail us dishpeople@mail.com

REQUIREMENT- 1. One year service commitment.
2. Major credit Card
3. Southwest exposure to the sky.

to be remove from future mailings e-mail us with the word "remove" in the<= BR> subject line at ---- getmeoff@arabia.com

Headquarters:
470 State Highway 10 West
Ledgewood, New Jersey 07852-0338
(973)252-9000
www.1800technostores.com



Tired of Cable TV raising their rates!!!

Get Satellite TV

=

From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Wed Mar 14 13:44:44 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01027 for ; Wed, 14 Mar 2001 13:44:43 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA24598 for ; Wed, 14 Mar 2001 09:15:01 -0800 (PST) From: b4h443@arabia.com Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2EHEvk23655 for ; Wed, 14 Mar 2001 09:14:58 -0800 (PST) Received: from mail.money.net.cn ([211.99.30.102]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2EHEmr23867 for ; Wed, 14 Mar 2001 09:14:49 -0800 (PST) Received: from ns.pcis.net ([63.62.253.245]) by mail.money.net.cn (Netscape Messaging Server 4.15) with SMTP id GA71F600.I12; Wed, 14 Mar 2001 23:23:30 +0800 Message-ID: <0000779a0aa0$00001754$00001187@ns.pcis.net> To: Subject: Tires of Cable TV raising there rates!!! Date: Wed, 14 Mar 2001 09:14:34 -0600 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: b4h443@arabia.com Tired of Cable TV raising their rates!!! Get Satellite TV YES ---YOU CAN WATCH DIFFERENT CHANNELS ON MULTIPLE TV'S YES ---YOU CAN GET LOCAL STATIONS Order Dish Network System with a one year plan, get FREE two receivers and the 18" Dish with FREE basic professional installation. Why Bother? For $40.99 Get both receivers and the Top 100 Stations! With only one receiver and the Dish $35.99 Local Channels add $5.00 You will be charged a one time $49.99 fee when you order which includes your first months service for FREE. THAT S IT! FLIP TO SATELLITE... ITS DIGITAL.. ITS GREAT... YOU'LL LOVE IT. Ready? Order by phone 1-888-235-5285 or e-mail us dishpeople@mail.com REQUIREMENT- 1. One year service commitment. 2. Major credit Card 3. Southwest exposure to the sky. to be remove from future mailings e-mail us with the word "remove" in the subject lineat --- getmeoff@arabia.com Tired of Cable TV raising their rates!!! Get Satellite TV From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Wed Mar 14 15:26:21 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03576 for ; Wed, 14 Mar 2001 15:26:21 -0500 (EST) Received: from holbrook-laptop.cisco.com (holbrook-dsl1.cisco.com [10.19.148.186]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA16328 for ; Wed, 14 Mar 2001 11:14:21 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id D2B7EC3ABB; Wed, 14 Mar 2001 11:14:22 -0800 (PST) From: Hugh Holbrook To: ssm-interest@external.cisco.com Subject: ssm working group agenda for mpls Reply-To: holbrook@cisco.com Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Message-Id: <20010314191422.D2B7EC3ABB@holbrook-laptop.cisco.com> Date: Wed, 14 Mar 2001 11:14:22 -0800 (PST) We have a short agenda for the SSM working group this time. - Agenda bashing - Updates on existing ssm drafts (5 minutes) draft-holbrook-ssm-arch-02.txt draft-bhattach-pim-ssm-00.txt draft-holbrook-idmr-igmpv3-ssm-01.txt (not an official ssm draft) - draft-kim-ssm-hierarchical-scheme-00.txt (5-10 min) - draft-schoch-dns-ssm-00.txt (10 min) (DNS for SSM) Please send me any updates. SSM is close to fulfilling its charter, and I believe the work of the SSM working group is sort of winding down. This might be our last meeting. -Hugh From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Wed Mar 14 16:40:53 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04985 for ; Wed, 14 Mar 2001 16:40:53 -0500 (EST) Received: from holbrook-laptop.cisco.com (holbrook-dsl1.cisco.com [10.19.148.186]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id MAA19254 for ; Wed, 14 Mar 2001 12:52:31 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 8D7FAC3ABB; Wed, 14 Mar 2001 12:52:29 -0800 (PST) From: Hugh Holbrook To: ssm-interest@external.cisco.com In-reply-to: <20010314191422.D2B7EC3ABB@holbrook-laptop.cisco.com> Subject: [Revised agenda] for ssm working group in Mpls. Reply-To: holbrook@cisco.com Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Message-Id: <20010314205229.8D7FAC3ABB@holbrook-laptop.cisco.com> Date: Wed, 14 Mar 2001 12:52:29 -0800 (PST) Here's our revised agenda. -Hugh - Agenda bashing - Updates on existing ssm drafts (5 minutes) draft-holbrook-ssm-arch-02.txt draft-bhattach-pim-ssm-00.txt draft-holbrook-idmr-igmpv3-ssm-01.txt (not an official ssm draft) - draft-he-mixed-igmp-proxy-00.txt (5-10 min) - draft-kim-ssm-hierarchical-scheme-00.txt (5 min) - draft-schoch-dns-ssm-00.txt (10 min) (DNS for SSM) Please send me any updates. From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 15 17:05:45 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09189 for ; Thu, 15 Mar 2001 17:05:44 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA12236 for ; Thu, 15 Mar 2001 12:47:58 -0800 (PST) From: mk.joseph@verizonmail.com Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2FKlbp01782 for ; Thu, 15 Mar 2001 12:47:37 -0800 (PST) Received: from cncc.cn.net ([202.96.58.161]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2FKl8X16647 for ; Thu, 15 Mar 2001 12:47:09 -0800 (PST) Received: from 202.96.58.161 by cncc.cn.net (8.8.8+Sun/SMI-SVR4) id EAB15466; Fri, 16 Mar 2001 04:32:29 +0800 (CST) Received: from nobody@localhost by (8.8.5/8.6.5) with SMTP id GAA00470 for ; Thu, 15 Mar 2001 01:32:20 -0600 (EST) To: ssm-interest@external.cisco.com Message-ID: <199912112040.MAA94626@addr6.addr.com> Date: Thu, 15 Mar 01 01:32:20 EST Subject: Simple Fail Safe Homebased E-Biz ! Hi, I thought I would drop you a quick note and let you know that there is an exciting and very profitable SELF-RUN online business which has exploded in 2000 and continues to grow in 2001! How would you like to quit your job, become your own boss, and build up enough residual income to support yourself for the rest of your life? Forget the old-days of Network Marketing where you had to "show the plan" and meet at the local high school for a "ra-ra" meeting. Our company offers you an opportunity that can be operated from in-front of your computer screen. Imagine the feeling of being able to offer our opportunity and products to millions of people in over 42 Countries and Territories around the World. Not only do you have the ability to own a profitable home-based business which is operating in the United States but you also have the potential of having distributors all over the World. Make a well informed decision which will impact your future today ! Simply click below to request more Information About this great opportunity! via email promptly: mailto:retire_young@verizonmail.com?subject=Send-info It will ONLY take a minute to find out. You will be glad that you did! I received your e-mail as someone interested in Internet Business Opportunities. If I received your e-mail in error, or you are no longer interested, click here to be removed. Be sure REMOVE is in the Subject Title and you will not be contacted again: mail to: mark2001@verizonmail.com Thank You, Mark From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 15 23:30:39 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15271 for ; Thu, 15 Mar 2001 23:30:39 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id TAA20499 for ; Thu, 15 Mar 2001 19:37:26 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2G3bQT12893 for ; Thu, 15 Mar 2001 19:37:26 -0800 (PST) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2G3XEX24038 for ; Thu, 15 Mar 2001 19:33:15 -0800 (PST) Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2652.78) id ; Thu, 15 Mar 2001 19:30:38 -0800 Received: from sprintlabs.com (ip199-2-53-56.sprintlabs.com [199.2.53.56]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id G5FQB7WL; Thu, 15 Mar 2001 19:30:33 -0800 From: Supratik Bhattacharyya To: ssm-interest@external.cisco.com Message-ID: <3AB1865F.EACDEFB7@sprintlabs.com> Date: Thu, 15 Mar 2001 19:19:59 -0800 X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Subject: draft-bhattach-ssm-framework-01.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A new version of the SSM WG framework document entitled "A Framework for Source Specific Multicast Deployment" is now available from : http://sith.maoz.com/SSM/draft-bhattach-ssm-framework-01.txt The previous version of this document was the Internet Draft "draft-bhattach-pim-ssm-00.txt" which has expired. We plan to resubmit this version as an ID very soon. The major change in this version is the addition of discussion on SSM for IPv6. This document was accepted as an SSM working group document at the 48th IETF (Pittsburg), and is expected to become an informational RFC. We feel that it is nearly ready at this point for advancing to the IESG, and would appreciate feedback/comments from everyone. Thanks, --Supratik From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Mar 16 05:18:55 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01392 for ; Fri, 16 Mar 2001 05:18:55 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id BAA02712 for ; Fri, 16 Mar 2001 01:01:04 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2G910516280 for ; Fri, 16 Mar 2001 01:01:00 -0800 (PST) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2G8ulX06345 for ; Fri, 16 Mar 2001 00:56:48 -0800 (PST) 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 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-extdom.ssm-interest@sj-msg-core-3.cisco.com Fri Mar 16 05:34:29 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01573 for ; Fri, 16 Mar 2001 05:34:28 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id BAA06153 for ; Fri, 16 Mar 2001 01:32:21 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2G9XZ803919 for ; Fri, 16 Mar 2001 01:33:35 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f2G9XS200239 for ; Fri, 16 Mar 2001 01:33:28 -0800 (PST) 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 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-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Mar 16 05:48:32 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01605 for ; Fri, 16 Mar 2001 05:48:32 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id BAA22450 for ; Fri, 16 Mar 2001 01:55:53 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2G9tnE02969 for ; Fri, 16 Mar 2001 01:55:49 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2G9pv206782 for ; Fri, 16 Mar 2001 01:51:58 -0800 (PST) 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 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-extdom.ssm-interest@sj-msg-core-1.cisco.com Fri Mar 16 06:15:05 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01838 for ; Fri, 16 Mar 2001 06:15:05 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id CAA24218 for ; Fri, 16 Mar 2001 02:19:14 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GAJEu13200 for ; Fri, 16 Mar 2001 02:19:14 -0800 (PST) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2GAJFD16006 for ; Fri, 16 Mar 2001 02:19:15 -0800 (PST) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id LAA00962 for ; Fri, 16 Mar 2001 11:04:12 +0100 (MET) Message-ID: <3AB1E51C.C53269B5@irisa.fr> Date: Fri, 16 Mar 2001 11:04:12 +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 Subject: SSm, simple multicast and Express Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If I understood well (maybe), SSM has replaced Simple Multicast and EXPRESS But what was the problem in those 2 protocoles?? thanx From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Fri Mar 16 13:04:40 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07999 for ; Fri, 16 Mar 2001 13:04:39 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA00326 for ; Fri, 16 Mar 2001 08:44:24 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GGiOe12677 for ; Fri, 16 Mar 2001 08:44:24 -0800 (PST) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2GGeeI25465 for ; Fri, 16 Mar 2001 08:40:41 -0800 (PST) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 834722; Fri, 16 Mar 2001 11:17:58 -0500 Message-ID: <3AB23BBC.B3B4C872@21rst-century.com> Date: Fri, 16 Mar 2001 11:13: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,pdf MIME-Version: 1.0 To: Ali Boudani CC: ssm-interest@external.cisco.com Subject: Re: SSm, simple multicast and Express References: <3AB1E51C.C53269B5@irisa.fr> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ali Boudani wrote: > If I understood well (maybe), SSM has replaced Simple Multicast and > EXPRESS > But what was the problem in those 2 protocoles?? > > thanx The only problem is, they weren't adopted. (i.e., there is nothing fundamentaly wrong with them that I know of, things just evolved differently.) Regards Marshall Eubanks T.M. 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 tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Mar 16 14:50:00 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09426 for ; Fri, 16 Mar 2001 14:50:00 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA24625 for ; Fri, 16 Mar 2001 10:41:43 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GIfcH29457 for ; Fri, 16 Mar 2001 10:41:38 -0800 (PST) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2GIfA321972 for ; Fri, 16 Mar 2001 10:41:10 -0800 (PST) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id TAA22205 for ; Fri, 16 Mar 2001 19:26:36 +0100 (MET) Message-ID: <3AB25ADD.110C8D0@irisa.fr> Date: Fri, 16 Mar 2001 19:26:37 +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 Subject: SSM Implementation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Is there any implementation for SSM?? Is there any code written, or it is just in the stage of developpement?? thanx From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Mar 16 15:28:04 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10607 for ; Fri, 16 Mar 2001 15:28:03 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA16807 for ; Fri, 16 Mar 2001 11:19:26 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GJJM402056 for ; Fri, 16 Mar 2001 11:19:22 -0800 (PST) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2GJIr307574 for ; Fri, 16 Mar 2001 11:18:53 -0800 (PST) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id UAA25593 for ; Fri, 16 Mar 2001 20:04:20 +0100 (MET) Message-ID: <3AB263B5.7E572CF2@irisa.fr> Date: Fri, 16 Mar 2001 20:04:21 +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 Subject: Interdomain SSM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Does SSM need an interdomain protocol as the case in PIM-SM ?? From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Fri Mar 16 15:42:15 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12571 for ; Fri, 16 Mar 2001 15:42:14 -0500 (EST) Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.25.24]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA04769; Fri, 16 Mar 2001 11:29:27 -0800 (PST) Received: (eckert@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA26779; Fri, 16 Mar 2001 11:29:27 -0800 (PST) Date: Fri, 16 Mar 2001 11:29:27 -0800 From: Toerless Eckert To: Ali Boudani Cc: ssm-interest@external.cisco.com Subject: Re: SSM Implementation Message-ID: <20010316112926.D11879@irp-view7.cisco.com> References: <3AB25ADD.110C8D0@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AB25ADD.110C8D0@irisa.fr>; from aboudani@irisa.fr on Fri, Mar 16, 2001 at 07:26:37PM +0100 On Fri, Mar 16, 2001 at 07:26:37PM +0100, Ali Boudani wrote: > > Is there any implementation for SSM?? > Is there any code written, or it is just in the stage of developpement?? SSM is in Cisco IOS starting with 12.0(15)S, 12.1(5)E, 12.2(1). See the pointer to SSM on ftp://ftpeng.cisco.com/ipmulticast.html Also note that to enable SSM you only need to have SSM software on the routers besides receivers. In the rest of the nework you can have standard PIM-SM routers. Cheers Toerless P.S.: Sorry if this was unppropriate for this mailing list. I hope it was not. From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Fri Mar 16 15:43:19 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12586 for ; Fri, 16 Mar 2001 15:43:19 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA04710 for ; Fri, 16 Mar 2001 11:29:25 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GJTOV11648 for ; Fri, 16 Mar 2001 11:29:24 -0800 (PST) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2GJTNI11613 for ; Fri, 16 Mar 2001 11:29:24 -0800 (PST) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id UAA26505 for ; Fri, 16 Mar 2001 20:14:20 +0100 (MET) Message-ID: <3AB2660D.94FA586D@irisa.fr> Date: Fri, 16 Mar 2001 20:14:21 +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 Subject: drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry , if I am asking too much questions but I didnt found any draft speaking about PIM-SS and PIM-SO. where can i found them?? and why this work isnt progressing or what is the future of SSM (as a particular case from PIM) thanx From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Fri Mar 16 15:49:30 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12717 for ; Fri, 16 Mar 2001 15:49:28 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA14218; Fri, 16 Mar 2001 11:42:42 -0800 (PST) Received: from cisco.com (dhcp-171-69-127-181.cisco.com [171.69.127.181]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AKA00968 (AUTH jmeylor); Fri, 16 Mar 2001 11:42:41 -0800 (PST) Message-ID: <3AB26CFB.8AEFE030@cisco.com> Date: Fri, 16 Mar 2001 11:43:55 -0800 From: John Meylor X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ali Boudani CC: ssm-interest@external.cisco.com Subject: Re: SSM Implementation References: <3AB25ADD.110C8D0@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ali Boudani wrote: > > Is there any implementation for SSM?? > Is there any code written, or it is just in the stage of developpement?? A cisco implementation has been tested and is deployed by customers in production images. Includes: SSM and IGMPv3 ssm-support@cisco.com or ftp://ftpeng.cisco.com/ipmulticast.html for expansion on vendor details. john From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Mar 16 16:59:52 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13827 for ; Fri, 16 Mar 2001 16:59:51 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id MAA13459 for ; Fri, 16 Mar 2001 12:57:36 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2GKvXH09525 for ; Fri, 16 Mar 2001 12:57:33 -0800 (PST) Received: from mail.mc.net (mail.mc.net [209.172.128.4]) by proxy3.cisco.com (8.11.2/8.11.2) with SMTP id f2GKvXI21286 for ; Fri, 16 Mar 2001 12:57:33 -0800 (PST) Received: (qmail 22567 invoked from network); 16 Mar 2001 20:53:43 -0000 Received: from caryas2-23.mc.net (HELO HOFF2000) (209.172.133.23) by mail.mc.net with SMTP; 16 Mar 2001 20:53:43 -0000 From: "Timothy Hoff" To: "Ali Boudani" , Subject: RE: SSM Implementation Date: Fri, 16 Mar 2001 14:44:55 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3AB25ADD.110C8D0@irisa.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Rating: mail.mc.net 1.6.1 0/1000/N Content-Transfer-Encoding: 7bit SSM is supported in Cisco IOS beginning with release 12.1(3)T. However, 12.1(5)T or later is recommended. There is also support for URD and IGMPv3 lite as transition tools until IGMPv3 is widely available in host operating systems. --teh -----Original Message----- From: Ali Boudani [mailto:aboudani@irisa.fr] Sent: Friday, March 16, 2001 12:27 PM To: ssm-interest@external.cisco.com Subject: SSM Implementation Is there any implementation for SSM?? Is there any code written, or it is just in the stage of developpement?? thanx From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri Mar 16 17:09:05 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13952 for ; Fri, 16 Mar 2001 17:09:04 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA06785 for ; Fri, 16 Mar 2001 13:08:10 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GL7nQ07724 for ; Fri, 16 Mar 2001 13:07:49 -0800 (PST) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2GL3w511814 for ; Fri, 16 Mar 2001 13:03:58 -0800 (PST) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 834929; Fri, 16 Mar 2001 15:50:10 -0500 Message-ID: <3AB27C67.69D99D23@21rst-century.com> Date: Fri, 16 Mar 2001 15:46:01 -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,pdf MIME-Version: 1.0 To: Ali Boudani CC: ssm-interest@external.cisco.com Subject: Re: drafts References: <3AB2660D.94FA586D@irisa.fr> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ali Boudani wrote: > Sorry , if I am asking too much questions but I didnt found any draft > speaking about PIM-SS and PIM-SO. > where can i found them?? > > and why this work isnt progressing or what is the future of SSM (as a > particular case from PIM) > thanx Look at PIm-SM-v2 - which includes sections on SSM http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-02.txt the IGMP v3 draft http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-07.txt and the following specific drafts : http://www.ietf.org/internet-drafts/draft-holbrook-ssm-arch-02.txt http://www.ietf.org/internet-drafts/draft-holbrook-idmr-igmpv3-ssm-01.txt -- Regards Marshall Eubanks T.M. 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 tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri Mar 16 17:20:54 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14128 for ; Fri, 16 Mar 2001 17:20:53 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA06804 for ; Fri, 16 Mar 2001 13:08:11 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GL7pt07760 for ; Fri, 16 Mar 2001 13:07:51 -0800 (PST) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2GL40511831 for ; Fri, 16 Mar 2001 13:04:00 -0800 (PST) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 834932; Fri, 16 Mar 2001 15:52:24 -0500 Message-ID: <3AB27CEE.D49D54D8@21rst-century.com> Date: Fri, 16 Mar 2001 15:48:16 -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,pdf MIME-Version: 1.0 To: Ali Boudani CC: ssm-interest@external.cisco.com Subject: Re: Interdomain SSM References: <3AB263B5.7E572CF2@irisa.fr> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ali Boudani wrote: > Does SSM need an interdomain protocol as the case in PIM-SM ?? Source discovery is done out of band (you get the (S,G) from a web page, say), and the routing is MBGP same as PIM-SM. -- Regards Marshall Eubanks T.M. 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 tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Fri Mar 16 18:05:01 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14581 for ; Fri, 16 Mar 2001 18:04:56 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id NAA26848 for ; Fri, 16 Mar 2001 13:55:00 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GLuC319717 for ; Fri, 16 Mar 2001 13:56:12 -0800 (PST) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2GLqSI16447 for ; Fri, 16 Mar 2001 13:52:28 -0800 (PST) Received: from nsamail01.us.newbridge.com (nsamail01.us.newbridge.com [138.120.244.77]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA29840 for ; Fri, 16 Mar 2001 15:37:21 -0600 (CST) Received: from alcatel.com ([198.205.41.19]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA4BAB; Fri, 16 Mar 2001 16:35:11 -0500 Message-ID: <3AB289F8.AD518174@alcatel.com> Date: Fri, 16 Mar 2001 16:47:36 -0500 From: "Nagesh Chintada" Organization: Carrier Internetworking Division, Alcatel X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ali Boudani CC: ssm-interest@external.cisco.com Subject: Re: Interdomain SSM References: <3AB263B5.7E572CF2@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think you won't need MSDP since the source is assumed to be known to the receivers. Nagesh Ali Boudani wrote: > Does SSM need an interdomain protocol as the case in PIM-SM ?? From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Fri Mar 16 19:07:55 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15758 for ; Fri, 16 Mar 2001 19:07:55 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA01317 for ; Fri, 16 Mar 2001 15:06:27 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2GN6N728290 for ; Fri, 16 Mar 2001 15:06:23 -0800 (PST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2GN6OI16586 for ; Fri, 16 Mar 2001 15:06:24 -0800 (PST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id PAA12674; Fri, 16 Mar 2001 15:01:16 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id PAA00273; Fri, 16 Mar 2001 15:01:16 -0800 (PST) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200103162301.PAA00273@garnet.juniper.net> To: Ali Boudani cc: ssm-interest@external.cisco.com, pusateri@juniper.net Subject: Re: Interdomain SSM In-Reply-To: Message from Ali Boudani of "Fri, 16 Mar 2001 20:04:21 +0100." <3AB263B5.7E572CF2@irisa.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <270.984783676.1@garnet.juniper.net> Date: Fri, 16 Mar 2001 15:01:16 -0800 From: Tom Pusateri In message <3AB263B5.7E572CF2@irisa.fr> you write: >Does SSM need an interdomain protocol as the case in PIM-SM ?? In the interdomain case, multicast domains are connected by pure source trees. MSDP facilitates the discovery of the sources but the trees are simply pim sparse mode source trees. Since SSM uses pim source trees, this turns out to be the same thing intra-domain or inter-domain. This is one the nicest properties of SSM. Thanks, Tom From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri Mar 16 19:14:20 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15846 for ; Fri, 16 Mar 2001 19:14:20 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA16133 for ; Fri, 16 Mar 2001 15:03:34 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2GN3E112864 for ; Fri, 16 Mar 2001 15:03:14 -0800 (PST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2GMxN513001 for ; Fri, 16 Mar 2001 14:59:24 -0800 (PST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id OAA12062; Fri, 16 Mar 2001 14:54:22 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id OAA98269; Fri, 16 Mar 2001 14:54:21 -0800 (PST) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200103162254.OAA98269@garnet.juniper.net> To: Ali Boudani cc: ssm-interest@external.cisco.com, pusateri@juniper.net Subject: Re: SSM Implementation In-Reply-To: Message from Ali Boudani of "Fri, 16 Mar 2001 19:26:37 +0100." <3AB25ADD.110C8D0@irisa.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98266.984783261.1@garnet.juniper.net> Date: Fri, 16 Mar 2001 14:54:21 -0800 From: Tom Pusateri In message <3AB25ADD.110C8D0@irisa.fr> you write: > >Is there any implementation for SSM?? >Is there any code written, or it is just in the stage of developpement?? > >thanx Well, the cool thing about SSM is that it uses protocols that were either already done (PIM sparse mode) or were already in the works (IGMP v3). This means that in most cases, you can run SSM over existing PIM implementations and just need IGMPv3 at the edge of your network directly connected to your hosts. In particular, all JUNOS versions from the beginning support PIM SSM. JUNOS 4.4 adds IGMP v3 SSM-only support. Thanks, Tom From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Sat Mar 17 07:53:21 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06208 for ; Sat, 17 Mar 2001 07:53:20 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id EAA14019 for ; Sat, 17 Mar 2001 04:00:03 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2HBxxH09066 for ; Sat, 17 Mar 2001 03:59:59 -0800 (PST) Received: from public.bjnet.edu.cn (public.bjnet.edu.cn [202.112.55.66]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2HBu6516246 for ; Sat, 17 Mar 2001 03:56:07 -0800 (PST) Received: from cernet-frank (compass12.compass.edu.cn [202.112.55.99]) by public.bjnet.edu.cn (8.8.8/8.8.8) with SMTP id TAA23484 for ; Sat, 17 Mar 2001 19:25:23 +0800 (CST) Message-Id: <200103171125.TAA23484@public.bjnet.edu.cn> Date: Sat, 17 Mar 2001 19:41:19 +0800 From: "feng@public.bjnet.edu.cn" To: "ssm-interest@external.cisco.com" X-mailer: FoxMail 3.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear sir, I am right now a graduate student. I am currently very interested in MAAA, and want to do some research work on it. But I have a few questions and want to get some advice on my future research work. 1.MAAA is now the dynamic solution on multicast address allocation. It may be used in the MSDP/PIM-SM/BGP+ inter-domain multicast routing architecture, since the MASC/BGMP is not consider to be deploy in ipv4. But right now SSM is consider to be deployed in ipv4. Since SSM have a lot of advantage over the traditional open group model, Somebody say that SSM is expected to be the major protocol for IPv4. It is true? If it is true then MAAA will not be widely deployed, it that right? 2.GLOP is propose to be another solution to the address problem. Even it is thought to be a temporary one, it is very simple. It said that ISP prefer it because MAAA is so complex. 3.As a lot of components in MAAA are right now RFCs and Internet-Drafts. What will be the future focus on MAAA, or broadly speaking what will be the future focus on multicast address allocation. I wonder what kinds of research work can be done or just let the ISP to deploy it. Thank you for all. I am looking forward to your suggestions and advices. Guohan Lu CERNET From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Sat Mar 17 12:52:21 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08089 for ; Sat, 17 Mar 2001 12:52:20 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id HAA17921; Sat, 17 Mar 2001 07:03:22 -0800 (PST) From: ph_adams22@yahoo.com Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2HF4Xw13725; Sat, 17 Mar 2001 07:04:33 -0800 (PST) Received: from serv.mail.com (HSE-Ottawa-ppp158340.sympatico.ca [64.229.133.249]) by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f2HF0du06447; Sat, 17 Mar 2001 07:00:39 -0800 (PST) Subject: It's Your Turn ! Date: Sat, 17 Mar 2001 06:26:08 Message-Id: <316.522123.679845@serv.mail.com> AS SEEN ON NATIONAL TV: Making over half million dollars every 4 to 5 months right from your home !! THANK'S TO THE COMPUTER AGE AND THE INTERNET ! ================================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can -follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so gladI finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $610,470.00 in 21 weeks, with money still coming in." Pam Hedland, Fort Lee, New Jersey. =================================================== Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything.'' More testimonials later but first, ===== PRINT THIS NOW FOR YOUR FUTUREREFERENCE ====== $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: =====Order all 5 reports shown on the list below ===== For each report, send $5 CASH (US FUNDS ONLY), THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. === When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00. Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work !!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ========================================================== **** Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1: BY SENDING BULK E-MAIL LEGALLY ========================================================== Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's=100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4 .... $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGUREOUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ========================================================= REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even one 4th of those people mailed 100,000e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET ======================================================= Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and dd METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receivethe report. =========== AVAILABLE REPORTS ==================== ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY ONLY!!) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ==================================================== REPORT # 1: "The Insider's Guide to Advertising for Free on the Net" Order Report #1 from: B. McDonald Suite 409 1500 Bank St Ottawa, ON K1H 1B8 Canada ___________________________________________________________ REPORT # 2: "The Insider's Guide to Sending Bulk e-mail on the Net" Order Report # 2 from: T. Richardson P.O. Box 753 Richland, MO. 65556 USA ____________________________________________________________ REPORT # 3: "Secret to Multilevel Marketing on the Net" Order Report # 3 from : C.J. Kalata P.O. Box 130157 Roseville, MN 55113 USA ____________________________________________________________ REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" Order Report # 4 from: R. B. Box. 21115, Grande Prairie Alberta, T8V-6W7 Canada ____________________________________________________________ REPORT #5: "How to Send Out 0ne Million e-mails for Free" Order Report # 5 from: B. Taylor P.O.Box 26001 Fredericton, N.B. E3A 5V8 Canada _____________________________________________________________ $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: === If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. === After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. === Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ====================================================== FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ..........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ============ MORE TESTIMONIALS ================ "My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jodyaboutreceiving ''junk mail''. I made fun of the whole thing,spoutingmy knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois ====================================================== ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ======================================================= ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks." Susan De Suza, New York, N.Y. ======================================================= ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20,560.00 and by the end of third month my total cash count was $362,840.00. Life is beautiful, Thanx to internet.". Fred Dellaca, Westport, New Zealand ======================================================= ORDER YOUR REPORTS TODAY AND GET STARTED ON 'YOUR' ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Wed Mar 21 11:23:01 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28336 for ; Wed, 21 Mar 2001 11:23:00 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id HAA25236 for ; Wed, 21 Mar 2001 07:01:46 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2LF2xE08497 for ; Wed, 21 Mar 2001 07:02:59 -0800 (PST) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2LEx7Z03180 for ; Wed, 21 Mar 2001 06:59:07 -0800 (PST) Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by letters.cs.ucsb.edu (8.9.3+Sun/8.9.3) with ESMTP id GAA21990; Wed, 21 Mar 2001 06:45:54 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id GAA20383 for ; Wed, 21 Mar 2001 06:45:53 -0800 (PST) Date: Wed, 21 Mar 2001 06:45:53 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200103211445.GAA20383@jackson.cs.ucsb.edu> To: aboudani@irisa.fr, tme@21rst-century.com Subject: Re: SSm, simple multicast and Express Cc: ssm-interest@external.cisco.com Well, Express was never a draft... it was a research paper. Simple was a draft but would have required a wholesale change in the infrastructure. SSM is based on PIM and so is less dramatic a change to the existing infrastructure. Maybe SSM stands for SUPER Simple Multicast!!! :-) What is wrong with ISM? Does it stand for Independent Source Multicast?!? :-) -Kevin >>Ali Boudani wrote: >> >>> If I understood well (maybe), SSM has replaced Simple Multicast and >>> EXPRESS >>> But what was the problem in those 2 protocoles?? >>> >>> thanx >> >>The only problem is, they weren't adopted. >> >>(i.e., there is nothing fundamentaly wrong with them that I know of, things just >>evolved differently.) >> >> Regards >> Marshall Eubanks From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Wed Mar 21 12:34:43 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02351 for ; Wed, 21 Mar 2001 12:34:42 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA27322 for ; Wed, 21 Mar 2001 08:19:28 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2LGJ6g29001 for ; Wed, 21 Mar 2001 08:19:06 -0800 (PST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2LGJ5Y07644 for ; Wed, 21 Mar 2001 08:19:06 -0800 (PST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14fl5L-0003DD-00; Wed, 21 Mar 2001 16:03:43 +0000 Date: Wed, 21 Mar 2001 16:03:38 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: "Kevin C. Almeroth" cc: aboudani@irisa.fr, tme@21rst-century.com, ssm-interest@external.cisco.com Subject: Re: SSm, simple multicast and Express In-Reply-To: <200103211445.GAA20383@jackson.cs.ucsb.edu> 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 *14fl5L-0003DD-00*JlL11ztIoz.* On Wed, 21 Mar 2001, Kevin C. Almeroth wrote: > SSM is based on PIM and so is less dramatic a change to the existing infrastructure. > > > > Maybe SSM stands for SUPER Simple Multicast!!! :-) well, simplifying the number of senders to one, at a fixed location, means that the protocol's got a slightly better chance of deployment. And once you also simplify the number of receivers to one, at a fixed location, chances of deployment will increase dramatically, not least because it will be a far less dramatic change to the existing infrastructure. (Call it SSS - Super Simple Stream.) L. PGP From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Wed Mar 21 21:52:48 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04045 for ; Wed, 21 Mar 2001 21:52:48 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA04429 for ; Wed, 21 Mar 2001 17:49:03 -0800 (PST) From: biotechstox61@msn.com Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2M1mgi16599 for ; Wed, 21 Mar 2001 17:48:42 -0800 (PST) Received: from mail.2500sz.com ([211.95.85.36]) by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f2M1mZZ13190 for ; Wed, 21 Mar 2001 17:48:35 -0800 (PST) Received: (qmail 91613 invoked by uid 0); 15 Mar 2001 17:38:23 -0000 Received: from unknown (HELO msn.com) (unknown) by unknown with SMTP; 15 Mar 2001 17:38:23 -0000 To: ssm-interest@external.cisco.com Subject: FREE Biotech Stock Info! 86 Date: Thu, 15 Mar 2001 12:35:11 Message-Id: <692.222374.42420@msn.com> Reply-To: biotechinfo2005@yahoo.com Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Do you want to capitalize on the Biotech Revolution

Do you want to capitalize on the Biotech Revolution? Would you like to add groundbreaking biotech, pharmaceutical and medical device companies to your portfolio mix? Does hearing about exciting IPO and private placement offerings from life sciences companies interest you?

The exclusive Ruddy-Carlisle Biotech Infoline service keeps you abreast of investment opportunities in the life sciences space. Just sign up for it once and get important information instantly delivered to study at your leisure. Our service is 100% FREE! Sign up!

Ruddy-Carlisle Biotech Infoline:

  • Instantly delivers key life sciences investment information directly to you!
  • Learn about biotech, pharmaceutical & medical device investment opportunities before others!
  • Includes IPO & private placement information!
  • 100% FREE!

For the entire last decade there were only three profitable biotech companies. At the end of this year, ten are projected. At the end of 2003, over forty are projected! The genomic promise is about to be delivered and investors know it. The Ruddy-Carlisle Biotech Infoline provides you with critical, decision-making, information that aids the chance of investment success in this lucrative space. Sign up!

Please Note- Your information will only be shared with companies that are in the life sciences space and pass our rigorous inspection. Only the best opportunities will come to you. Ruddy-Carlisle respects your privacy. Sign up!

 

 

List Removal Instructions- Simply click here: remove to be instantly and permanently removed from our list. Send the blank email to the address specified. Please do not try to reply to this message. From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu Mar 22 02:58:38 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02938 for ; Thu, 22 Mar 2001 02:58:37 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id XAA14151 for ; Wed, 21 Mar 2001 23:03:36 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2M74ni19279 for ; Wed, 21 Mar 2001 23:04:49 -0800 (PST) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2M74hZ22043 for ; Wed, 21 Mar 2001 23:04:43 -0800 (PST) Received: from [63.87.12.233] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 836642; Thu, 22 Mar 2001 01:50:53 -0500 Message-ID: <3AB9A0F8.EB68E70F@21rst-century.com> Date: Thu, 22 Mar 2001 01:51:35 -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: ssmmailing list , mbone mail list , MboneD Mail List , Tony Ballardie Subject: Auto-tunnel Rant Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello All; Today there was no time in the MBONED meeting to have a general discussion of the various auto-tunneling proposals, which was unfortunate. I will therefore inflict what I would have said there upon on the list. I should say that I have respect for all of the authors of these proposals, and (although I might have specific problems with aspects of each) I have no doubt that they could be made to work, given sufficient time and effort. My comments are not a reflection on the technical, but instead the business, aspects of these proposals. I also recognized that there also might be specific applications where auto-tunneling could be useful - I am specifically responding to the proposals to emulate SSM, which is intended to assist broadcast. I think that the promotion of auto-tunnels for the purpose of furthering multicast deployment is WRONG. It is, IMHO, NOT productive to expend time and effort in this direction. It diverts resources from the real goal, which is multicast deployment. If deployed, it will cause problems that will be inevitably be blamed on multicast. Furthermore, I know of NO broadcaster who is requesting it. From a broadcast standpoint, unicast fail-over is much preferable to auto-tunnels - it is more under the broadcasters control, and almost certain to be cheaper - and unicast failover is too expensive to be easily profitable. It will also take time (6 months ? a year ? two ?) to implement any tunnel scheme, and I can easily see ISP's putting multicast off to wait and see on the auto-tunnel deployment. For all of these reasons I sincerely hope that neither the SSM nor the MBONED group back any of these proposed tunnel schemes. 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-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 22 11:20:32 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14014 for ; Thu, 22 Mar 2001 11:20:31 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA18290 for ; Thu, 22 Mar 2001 07:00:19 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2MExwF09417 for ; Thu, 22 Mar 2001 06:59:59 -0800 (PST) Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2MExLb29442 for ; Thu, 22 Mar 2001 06:59:22 -0800 (PST) Received: from dstc.edu.au (sunburn.dstc.edu.au [130.102.176.16]) by piglet.dstc.edu.au (8.11.3/8.11.3) with ESMTP id f2MEiMZ09378; Fri, 23 Mar 2001 00:44:22 +1000 (EST) To: tme@21rst-century.com cc: ssmmailing list , mbone mail list , MboneD Mail List , Tony Ballardie Subject: Re: Auto-tunnel Rant In-reply-to: Your message of "Thu, 22 Mar 2001 01:51:35 EST." <3AB9A0F8.EB68E70F@21rst-century.com> Date: Fri, 23 Mar 2001 00:44:22 +1000 Message-ID: <7650.985272262@dstc.edu.au> From: George Michaelson X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) I believe large amounts of edge network will *never* be multicast enabled because the clue density drops as you approach the edge. So without this feature, end-users in 2 or 3 subtier networks will be unable to link back to core multicast meshes. Surely your arguments apply just as equally to the proliferation of auto-discovery of unicast route/path methods embedded in the applications? And, while s/w developers may have less motivation, content *hosters* have to scale backend platforms for large amounts of parallel feed knowing that they could reduce their copy cycle to a fraction if they had effective fanout. Watching two people in the same cubicle connect to the same service and listen to the same source on a 2 second lag from each other tends to re-inforce a view there is a role for a simple lightweight tunnel method. You might as well rant against SSH enabled VPN and Cisco GRE at the same time. cheers -George From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 22 12:23:40 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15262 for ; Thu, 22 Mar 2001 12:23:39 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA21141 for ; Thu, 22 Mar 2001 07:56:38 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2MFuG124696 for ; Thu, 22 Mar 2001 07:56:16 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f2MFu9i10949 for ; Thu, 22 Mar 2001 07:56:09 -0800 (PST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 22 Mar 2001 15:50:35 +0000 To: George Michaelson cc: tme@21rst-century.com, ssmmailing list , mbone mail list , MboneD Mail List , Tony Ballardie Subject: Re: Auto-tunnel Rant In-reply-to: Your message of "Fri, 23 Mar 2001 00:44:22 +1000." <7650.985272262@dstc.edu.au> Date: Thu, 22 Mar 2001 15:50:35 +0000 Message-ID: <7374.985276235@cs.ucl.ac.uk> From: Jon Crowcroft In message <7650.985272262@dstc.edu.au>, George Michaelson typed: >>I believe large amounts of edge network will *never* be multicast enabled >>because the clue density drops as you approach the edge. i would ameliorate this comment - as edge nets have lans (e.g. dsl access via ether not usb) edge sites might well have multicast but be one hop removed from the core, but with no applciatio nlevel box between them and coree multicast capable nets. >>So without this feature, end-users in 2 or 3 subtier networks will be >>unable to link back to core multicast meshes. >>Surely your arguments apply just as equally to the proliferation of >>auto-discovery of unicast route/path methods embedded in the applications? >> >>And, while s/w developers may have less motivation, content *hosters* have >>to scale backend platforms for large amounts of parallel feed knowing that >>they could reduce their copy cycle to a fraction if they had effective fanout. >> >>Watching two people in the same cubicle connect to the same service and >>listen to the same source on a 2 second lag from each other tends to >>re-inforce a view there is a role for a simple lightweight tunnel method. >> >>You might as well rant against SSH enabled VPN and Cisco GRE at the same >>time. >> >>cheers >> -George cheers jon From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 22 13:53:13 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17470 for ; Thu, 22 Mar 2001 13:53:12 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA20006 for ; Thu, 22 Mar 2001 09:25:32 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2MHPCb06917 for ; Thu, 22 Mar 2001 09:25:12 -0800 (PST) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2MHOab14761 for ; Thu, 22 Mar 2001 09:24:36 -0800 (PST) Received: from tingle.mcs.anl.gov (vpnclient151.mcs.anl.gov [140.221.11.151]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id LAA24376; Thu, 22 Mar 2001 11:19:27 -0600 Message-Id: <4.3.2.7.2.20010322102947.00b88eb0@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Mar 2001 11:17:17 -0600 To: tme@21rst-century.com From: Bill Nickless Subject: Re: Auto-tunnel Rant Cc: ssmmailing list , mbone mail list , MboneD Mail List , Tony Ballardie In-Reply-To: <3AB9A0F8.EB68E70F@21rst-century.com> Mime-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- At 01:51 AM 3/22/2001 -0500, Marshall Eubanks wrote: > I think that the promotion of auto-tunnels for the purpose of >furthering multicast deployment is WRONG. It is, IMHO, NOT productive to >expend time and effort in this direction. It diverts resources from the >real goal, which is multicast deployment. If deployed, it will cause >problems that will be inevitably be blamed on multicast. As I've been playing Multicast Bully, one of the hardest things I've had to do is to get people who think they've got a working multicast deployment to fix it. (Fix it means MSDP/PIM-SM/MBGP). These are usually people who have a DVMRP tunnel off to a service provider. I've also seen situations where an organization has their service provider run a PIM RP. Adding another set of non-BCP multicast deployment options using these auto-tunneling procedures will inevitably increase the problem space. I'm already having to ask people why their MSDP SA advertisements are coming from an RP in an unrelated university in another state (probably because of old dense mode connections). If we need tunnels to get around broken service providers, let's do them explicitly so that we know where they are and can take them out when clues get appropriately spread out. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQCVAwUBOroznKwgm7ipJDXBAQF5mQP/bzFA6JtxA3S1EgMlNCjDglOCjQTSTWNl BS+WOU1VWM0YWwTYYi+WyTV9yeapaHBrESk4eCYbqi+9DHKVxNqemPcWM+91+hwB wL1zvdeQHhxY5hnPgfv+DabpAVctSDrI9+jUHtfWuzUMwn5rCOH5FNPczbL/26a+ 4g6IRVYpGRA= =p0yN -----END PGP SIGNATURE----- From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 22 13:54:13 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17500 for ; Thu, 22 Mar 2001 13:54:12 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA10566 for ; Thu, 22 Mar 2001 09:53:37 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2MHrGS05062 for ; Thu, 22 Mar 2001 09:53:16 -0800 (PST) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2MHmtb26903 for ; Thu, 22 Mar 2001 09:48:55 -0800 (PST) Received: from [63.87.12.233] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 836803; Thu, 22 Mar 2001 12:22:42 -0500 Message-ID: <3ABA350F.EA27E1E7@21rst-century.com> Date: Thu, 22 Mar 2001 12:23:26 -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 Nickless CC: ssmmailing list , mbone mail list , MboneD Mail List , Tony Ballardie Subject: Re: Auto-tunnel Rant References: <4.3.2.7.2.20010322102947.00b88eb0@pop.mcs.anl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bill Nickless wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > At 01:51 AM 3/22/2001 -0500, Marshall Eubanks wrote: > > I think that the promotion of auto-tunnels for the purpose of > >furthering multicast deployment is WRONG. It is, IMHO, NOT productive to > >expend time and effort in this direction. It diverts resources from the > >real goal, which is multicast deployment. If deployed, it will cause > >problems that will be inevitably be blamed on multicast. > > As I've been playing Multicast Bully, one of the hardest things I've had to > do is to get people who think they've got a working multicast deployment to > fix it. (Fix it means MSDP/PIM-SM/MBGP). These are usually people who > have a DVMRP tunnel off to a service provider. I've also seen situations > where an organization has their service provider run a PIM RP. > > Adding another set of non-BCP multicast deployment options using these > auto-tunneling procedures will inevitably increase the problem space. I'm > already having to ask people why their MSDP SA advertisements are coming > from an RP in an unrelated university in another state (probably because of > old dense mode connections). > > If we need tunnels to get around broken service providers, let's do them > explicitly so that we know where they are and can take them out when clues > get appropriately spread out. Bill; Keep up the good work. I appreciate it. Just to clear things up, I have nothing against tunnels per se - use, have 'em, will sell you one. Its putting a lot of effort into auto-tunnels that I do not regard as a good idea. > === > Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 > PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.5.8 for non-commercial use > > iQCVAwUBOroznKwgm7ipJDXBAQF5mQP/bzFA6JtxA3S1EgMlNCjDglOCjQTSTWNl > BS+WOU1VWM0YWwTYYi+WyTV9yeapaHBrESk4eCYbqi+9DHKVxNqemPcWM+91+hwB > wL1zvdeQHhxY5hnPgfv+DabpAVctSDrI9+jUHtfWuzUMwn5rCOH5FNPczbL/26a+ > 4g6IRVYpGRA= > =p0yN > -----END PGP SIGNATURE----- -- 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-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 22 14:15:25 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18178 for ; Thu, 22 Mar 2001 14:15:24 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA28061 for ; Thu, 22 Mar 2001 09:52:27 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA28931; Thu, 22 Mar 2001 09:51:54 -0800 (PST) Date: Thu, 22 Mar 2001 09:51:54 -0800 From: Toerless Eckert To: Jon Crowcroft Cc: George Michaelson , tme@21rst-century.com, ssmmailing list , mbone mail list , MboneD Mail List , Tony Ballardie Subject: Re: Auto-tunnel Rant Message-ID: <20010322095154.U6277@cypher.cisco.com> References: <7650.985272262@dstc.edu.au> <7374.985276235@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7374.985276235@cs.ucl.ac.uk>; from J.Crowcroft@cs.ucl.ac.uk on Thu, Mar 22, 2001 at 03:50:35PM +0000 On Thu, Mar 22, 2001 at 03:50:35PM +0000, Jon Crowcroft wrote: > > i would ameliorate this comment - as edge nets have lans (e.g. dsl > access via ether not usb) edge sites might well have multicast but be > one hop removed from the core, but with no applciatio nlevel box > between them and coree multicast capable nets. Point not taken: If the network administrator is able and willing to update his last-hop-router to do not only multicast but also the tunnel-trick, why shouldn't he want to deploy multicast throughout his network in the first place ? If necessary he would just do a tunnel-transit on his networks exit router towards the Internet. That is just one tunnel, and we are doing this for over 10 years now. If that model isn't working for someone, than why the heck should something copletely new with maybe a bit less of configuration ??? (hey, you still have to get the tunnel box working somehow, even if you don't have to configure the remote tunnel endpoint adress!) I think the tunnel solution that we don't have is one where the PC user can easily take the initiative to get things going, but given that it would be possible for an ISP to offer this today with some amount of initial work, i wonder if we just don't have it because ISPs do not want to offer this: If let's say a Tier1 ISP wants to offer a multicast service down to Tier2/Tier3 customers that don't have contiguous IP Multicast connectivity because their intermediate ISPs don't provide it: Why does that ISP not try to get a dialin service provisioned based on some large-enough dial-in router he puts someplace in his core with for example L2TP tunnels with Radius authentication and appropriate access-lists managed from some web-server via a CGI script that will create accounts for users whose IP source addresses are verified to come from the ISPs downstream tiers, and which also passes some windows install script down to the PC to configure the L2TP tunnel on the windows PC. Ok, so i haven't tried to sit down to check out all loose ends here, but it seems to me as if this would all just be a question of packaging for available components together with some level of web programming (and maybe, uhm.. some bug fixing in components). Sure, it's ugly in the eyes of the IETF snob, but it could be a "one-click solution for the user to get IP multicast", and certainly faster to realize than solutions depending on development of completely new protocols. Those completely new protocols in my view can just be an outgrowth, trying to improve on such a solution (or similar ones) where necessary. Thus, if such a solution isn't even tried to be deployed, then why would it be commercially viable to improve on it ? Uglyness was never an important factor for commercial success or failure in networking (yeah, we need fashion-networking, that's it!). Cheers Toerless P.S.: "ameliorate" - cool ;-)) From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 22 15:33:16 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20685 for ; Thu, 22 Mar 2001 15:33:15 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA13341 for ; Thu, 22 Mar 2001 11:30:21 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2MJUKM05357 for ; Thu, 22 Mar 2001 11:30:20 -0800 (PST) Received: from puck.nether.net (root@puck.nether.net [204.42.254.5]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2MJUM200174 for ; Thu, 22 Mar 2001 11:30:22 -0800 (PST) Received: (from jared@localhost) by puck.nether.net (8.11.1/8.9.3) id f2MJNax22031; Thu, 22 Mar 2001 14:23:36 -0500 (envelope-from jared) Date: Thu, 22 Mar 2001 14:23:36 -0500 From: Jared Mauch To: Marshall Eubanks Cc: Bill Nickless , ssmmailing list , mbone mail list , MboneD Mail List , Tony Ballardie Subject: Re: Auto-tunnel Rant Message-ID: <20010322142336.B4776@puck.nether.net> References: <4.3.2.7.2.20010322102947.00b88eb0@pop.mcs.anl.gov> <3ABA350F.EA27E1E7@21rst-century.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ABA350F.EA27E1E7@21rst-century.com>; from tme@21rst-century.com on Thu, Mar 22, 2001 at 12:23:26PM -0500 On Thu, Mar 22, 2001 at 12:23:26PM -0500, Marshall Eubanks wrote: > > > Bill Nickless wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > At 01:51 AM 3/22/2001 -0500, Marshall Eubanks wrote: > > > I think that the promotion of auto-tunnels for the purpose of > > >furthering multicast deployment is WRONG. It is, IMHO, NOT productive to > > >expend time and effort in this direction. It diverts resources from the > > >real goal, which is multicast deployment. If deployed, it will cause > > >problems that will be inevitably be blamed on multicast. > > > > As I've been playing Multicast Bully, one of the hardest things I've had to > > do is to get people who think they've got a working multicast deployment to > > fix it. (Fix it means MSDP/PIM-SM/MBGP). These are usually people who > > have a DVMRP tunnel off to a service provider. I've also seen situations > > where an organization has their service provider run a PIM RP. > > > > Adding another set of non-BCP multicast deployment options using these > > auto-tunneling procedures will inevitably increase the problem space. I'm > > already having to ask people why their MSDP SA advertisements are coming > > from an RP in an unrelated university in another state (probably because of > > old dense mode connections). > > > > If we need tunnels to get around broken service providers, let's do them > > explicitly so that we know where they are and can take them out when clues > > get appropriately spread out. > > Bill; > > Keep up the good work. I appreciate it. > > Just to clear things up, > I have nothing against tunnels per se - use, have 'em, will sell you one. > Its putting a lot of effort into auto-tunnels that I do not regard as a good idea. I must also agree. I like the idea of the tunnels in theory but in practice I have a lot of concerns in running a network that supports multicast. We have native multicast (almost) everywhere and available to customers. I do not like the idea of my routers doing auto tunnels across my customers network to their downstream customer. They need to be educated and become more savvy in their operations. I think that instead of putting effort into auto-tunnels that more time should be spent working on educating the community. The problem is that people associate multicast with dvmrp and mbone which is problematic. They remember having a 10M dvmrp link and don't understand that pim sm+msdp+ssm don't have that dramatic bandiwdth downside. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 22 16:29:00 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22054 for ; Thu, 22 Mar 2001 16:28:59 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA10632 for ; Thu, 22 Mar 2001 12:05:59 -0800 (PST) Received: from localhost (jzwiebel@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA12051; Thu, 22 Mar 2001 12:05:15 -0800 (PST) Message-Id: <200103222005.MAA12051@cisco.com> To: Jared Mauch cc: Marshall Eubanks , Bill Nickless , ssmmailing list , mbone mail list , MboneD Mail List , Tony Ballardie Subject: Re: Auto-tunnel Rant In-reply-to: Your message of "Thu, 22 Mar 2001 14:23:36 EST." <20010322142336.B4776@puck.nether.net> Date: Thu, 22 Mar 2001 12:05:15 -0800 From: "John M. Zwiebel" 2cents: IMHO, the auto-tunnels should be taken care of by a CDN (or layer 4-7 replicator) rather than done automatically by routers. Most CDN folks claim they want to "avoid the congestion in the core" Sounds nice. Problem is that folks on the edge may not want that information at the same time its being offered. The trick is to multicast it to the edge, to be cached for delivery on demand to the user. CDN is a tool. Multicast is a tool. Pick the right tool for the job. ^ On Thu, Mar 22, 2001 at 12:23:26PM -0500, Marshall Eubanks wrote: ^ > ^ > ^ > Bill Nickless wrote: ^ > > ^ > > -----BEGIN PGP SIGNED MESSAGE----- ^ > > ^ > > At 01:51 AM 3/22/2001 -0500, Marshall Eubanks wrote: ^ > > > I think that the promotion of auto-tunnels for the purpose of ^ > > >furthering multicast deployment is WRONG. It is, IMHO, NOT productive t o ^ > > >expend time and effort in this direction. It diverts resources from the ^ > > >real goal, which is multicast deployment. If deployed, it will cause ^ > > >problems that will be inevitably be blamed on multicast. ^ > > ^ > > As I've been playing Multicast Bully, one of the hardest things I've had to ^ > > do is to get people who think they've got a working multicast deployment to ^ > > fix it. (Fix it means MSDP/PIM-SM/MBGP). These are usually people who ^ > > have a DVMRP tunnel off to a service provider. I've also seen situation s ^ > > where an organization has their service provider run a PIM RP. ^ > > ^ > > Adding another set of non-BCP multicast deployment options using these ^ > > auto-tunneling procedures will inevitably increase the problem space. I 'm ^ > > already having to ask people why their MSDP SA advertisements are coming ^ > > from an RP in an unrelated university in another state (probably because of ^ > > old dense mode connections). ^ > > ^ > > If we need tunnels to get around broken service providers, let's do them ^ > > explicitly so that we know where they are and can take them out when clu es ^ > > get appropriately spread out. ^ > ^ > Bill; ^ > ^ > Keep up the good work. I appreciate it. ^ > ^ > Just to clear things up, ^ > I have nothing against tunnels per se - use, have 'em, will sell you one. ^ > Its putting a lot of effort into auto-tunnels that I do not regard as a go od idea. ^ ^ ^ I must also agree. I like the idea of the tunnels in ^ theory but in practice I have a lot of concerns in running a network ^ that supports multicast. We have native multicast (almost) everywhere ^ and available to customers. I do not like the idea of my routers ^ doing auto tunnels across my customers network to their downstream ^ customer. They need to be educated and become more savvy in their ^ operations. ^ ^ I think that instead of putting effort into auto-tunnels that ^ more time should be spent working on educating the community. The problem ^ is that people associate multicast with dvmrp and mbone which is ^ problematic. They remember having a 10M dvmrp link and don't understand ^ that pim sm+msdp+ssm don't have that dramatic bandiwdth downside. ^ ^ - Jared ^ ^ -- ^ Jared Mauch | pgp key available via finger from jared@puck.nether.net ^ clue++; | http://puck.nether.net/~jared/ My statements are only mine. ------------------------------------------------------------------------------ John Zwiebel Phone: 408-526-5303 Cisco Systems Inc. IP Multicast Group From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 22 16:35:08 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22258 for ; Thu, 22 Mar 2001 16:35:08 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA16357 for ; Thu, 22 Mar 2001 12:08:14 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2MK7ra21939 for ; Thu, 22 Mar 2001 12:07:53 -0800 (PST) Received: from ns.live.com (ns.live.com [208.184.148.162]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2MK7s220317 for ; Thu, 22 Mar 2001 12:07:54 -0800 (PST) Received: (from rsf@localhost) by ns.live.com (8.9.3/8.9.3) id MAA92521; Thu, 22 Mar 2001 12:03:02 -0800 (PST) (envelope-from rsf) Message-Id: <4.3.1.1.20010322134023.00b31650@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 22 Mar 2001 14:02:28 -0600 To: Jared Mauch From: Ross Finlayson Subject: Re: Auto-tunnel Rant Cc: ssmmailing list , mbone mail list , MboneD Mail List In-Reply-To: <20010322142336.B4776@puck.nether.net> References: <3ABA350F.EA27E1E7@21rst-century.com> <4.3.2.7.2.20010322102947.00b88eb0@pop.mcs.anl.gov> <3ABA350F.EA27E1E7@21rst-century.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:23 PM 3/22/01, Jared Mauch wrote: >We have native multicast (almost) everywhere >and available to customers. I do not like the idea of my routers >doing auto tunnels across my customers network to their downstream >customer. If your downstream ISP customers don't support native multicast (even though you do), then they will be multi-unicasting across your network in any case. If this multi-unicasting happens to be using a tunneling protocol, and you just choose to ignore this, then it will make no difference to you. It'll be basically the same[*] traffic either way. However, if your downstream customers *are* using an automatic tunneling protocol, then you - as an upstream provider - now have the *choice* of reducing this traffic by inserting your own tunneling server(s) into the stream. But it's your choice. If you don't want to worry about this, then you don't have to do anything. > They need to be educated and become more savvy in their >operations. Yes, we all agree that this is the ideal solution. I wish you continued success in educating your downstream ISP customers :-) Ross. [*] This assumes that if your non-native-multicast-enabled downstream customers don't have multicast tunneling available, then they will just send/receive plain UDP unicast packets instead. One could argue, however, that if they don't have the ability to do multicast tunneling, then they will use TCP instead, or just throw up their hands and do nothing. This, I think, is a better argument to make regarding the possible use of automatic multicast tunneling by your downstream customers. You might argue that multicast tunneling would lead to an increase of *UDP* traffic across your network, and that this might be something you decide to be concerned about. Ross. From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu Mar 22 17:57:21 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24562 for ; Thu, 22 Mar 2001 17:57:21 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA24085 for ; Thu, 22 Mar 2001 13:33:58 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2MLXtj10161 for ; Thu, 22 Mar 2001 13:33:55 -0800 (PST) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2MLXJb13898 for ; Thu, 22 Mar 2001 13:33:19 -0800 (PST) Received: from nsamail01.us.newbridge.com (nsamail01.us.newbridge.com [138.120.244.77]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA12493 for ; Thu, 22 Mar 2001 15:18:48 -0600 (CST) Received: from alcatel.com ([198.205.41.19]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA9D7; Thu, 22 Mar 2001 16:16:29 -0500 Message-ID: <3ABA6EAF.23AF710E@alcatel.com> Date: Thu, 22 Mar 2001 16:29:19 -0500 From: "Nagesh Chintada" Organization: Carrier Internetworking Division, Alcatel X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: SSM , "pim@catarina.usc.edu" , "msdp@network-services.uoregon.edu" Subject: Why MSDP? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greetings, I have a very basic question: First, the context: For inter-domain Multicasting, one would typically deploy PIM-SM/MBGP/MSDP protocols..... MBGP for announcing routes that include subnets containing multicast sources, and MSDP to announce sources. Since MBGP already has the capability to announce multicast routes, why not announce host routes of multicast sources as well, using MBGP? If necessary, one can think of a simple extension to MBGP to mark the host route as a "source route". IMHO, this will make it much easier to deploy Multicast without having to worry about delpoying MSDP. Any comments? Best Regards, Nagesh From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 22 18:06:46 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24857 for ; Thu, 22 Mar 2001 18:06:45 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA24266 for ; Thu, 22 Mar 2001 13:54:49 -0800 (PST) Received: from localhost (jzwiebel@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA12217; Thu, 22 Mar 2001 13:54:27 -0800 (PST) Message-Id: <200103222154.NAA12217@cisco.com> To: "Nagesh Chintada" cc: SSM , "pim@catarina.usc.edu" , "msdp@network-services.uoregon.edu" Subject: Re: Why MSDP? In-reply-to: Your message of "Thu, 22 Mar 2001 16:29:19 EST." <3ABA6EAF.23AF710E@alcatel.com> Date: Thu, 22 Mar 2001 13:54:26 -0800 From: "John M. Zwiebel" MSDP is required for ISM - or "internet standard multicast". ISM is not SSM in that it allows building of shared-trees within an AS which SSM does not. The receiver does not need to know who the senders to a given group are. SSM builds only shortest-path trees because the host can signal to the last hop router the specific hosts (senders) it wants to listen to. This rendezvous mechanism is outside of the PIM protocol and can be discovered any way the application writer wants it to be. MSDP is not required (and not used) to support SSM groups. Host routes are not needed in MBGP to be able to join toward the shortest-path across the internet. ^ Greetings, ^ ^ I have a very basic question: ^ ^ First, the context: ^ For inter-domain Multicasting, one would typically deploy ^ PIM-SM/MBGP/MSDP protocols..... ^ MBGP for announcing routes that include subnets containing multicast ^ sources, and MSDP ^ to announce sources. ^ ^ Since MBGP already has the capability to announce multicast routes, why ^ not announce host routes of multicast sources as well, using MBGP? If ^ necessary, one can think of a simple extension to MBGP to mark the host ^ route as a "source route". IMHO, this will make it much easier to deploy ^ Multicast without having to worry about delpoying MSDP. ^ ^ Any comments? ^ ^ Best Regards, ^ Nagesh ^ ------------------------------------------------------------------------------ John Zwiebel Phone: 408-526-5303 Cisco Systems Inc. IP Multicast Group From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 22 18:20:47 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25304 for ; Thu, 22 Mar 2001 18:20:47 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA18122 for ; Thu, 22 Mar 2001 14:30:33 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2MMUD405768 for ; Thu, 22 Mar 2001 14:30:13 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2MMTbb11160 for ; Thu, 22 Mar 2001 14:29:37 -0800 (PST) Received: from leningrad (gate.webfountain.com [63.161.54.3]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id OAA28488; Thu, 22 Mar 2001 14:15:57 -0800 X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad From: "Mike Luby" To: "John M. Zwiebel" , "Nagesh Chintada" Cc: "SSM" , , Subject: RE: Why MSDP? Date: Thu, 22 Mar 2001 14:21:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200103222154.NAA12217@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit John, One of the things that I think we might have come to consensus on at the IETF on Tuesday is to start calling the multicast service model defined in RFC 1112 as "Any-Source Multicas" (ASM) hereafter (instead of ISM or anything else). This was raised by Dave Meyer in the SSM working group meeting, and after a short discussion the consensus seemed to be that nobody liked the term Internet Standard Multicast (ISM) because of its connotations towards other models of multicast (as not being Internet Standards), that there was a strong need for a common name for this service model, and that although ASM was not the first choice of all people, ASM is the first choice of quite a number of people and nobody had strong objections to ASM. Michael Luby Chief Technical Officer Digital Fountain, Inc. 600 Alabama Street San Francisco, CA 94110 www.digitalfountain.com luby@digitalfountain.com (415) 401-2100 (main) (415) 401-2120 (direct) (415) 401-2199 (fax) -----Original Message----- From: John M. Zwiebel [mailto:jzwiebel@cisco.com] Sent: Thursday, March 22, 2001 1:54 PM To: Nagesh Chintada Cc: SSM; pim@catarina.usc.edu; msdp@network-services.uoregon.edu Subject: Re: Why MSDP? MSDP is required for ISM - or "internet standard multicast". ISM is not SSM in that it allows building of shared-trees within an AS which SSM does not. The receiver does not need to know who the senders to a given group are. SSM builds only shortest-path trees because the host can signal to the last hop router the specific hosts (senders) it wants to listen to. This rendezvous mechanism is outside of the PIM protocol and can be discovered any way the application writer wants it to be. MSDP is not required (and not used) to support SSM groups. Host routes are not needed in MBGP to be able to join toward the shortest-path across the internet. ^ Greetings, ^ ^ I have a very basic question: ^ ^ First, the context: ^ For inter-domain Multicasting, one would typically deploy ^ PIM-SM/MBGP/MSDP protocols..... ^ MBGP for announcing routes that include subnets containing multicast ^ sources, and MSDP ^ to announce sources. ^ ^ Since MBGP already has the capability to announce multicast routes, why ^ not announce host routes of multicast sources as well, using MBGP? If ^ necessary, one can think of a simple extension to MBGP to mark the host ^ route as a "source route". IMHO, this will make it much easier to deploy ^ Multicast without having to worry about delpoying MSDP. ^ ^ Any comments? ^ ^ Best Regards, ^ Nagesh ^ ---------------------------------------------------------------------------- -- John Zwiebel Phone: 408-526-5303 Cisco Systems Inc. IP Multicast Group From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 22 18:55:48 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26557 for ; Thu, 22 Mar 2001 18:55:47 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA28451 for ; Thu, 22 Mar 2001 14:35:37 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2MMZal04640 for ; Thu, 22 Mar 2001 14:35:36 -0800 (PST) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2MMZ1b13407 for ; Thu, 22 Mar 2001 14:35:02 -0800 (PST) Received: from nsamail01.us.newbridge.com (nsamail01.us.newbridge.com [138.120.244.77]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA23565 for ; Thu, 22 Mar 2001 16:20:30 -0600 (CST) Received: from alcatel.com ([198.205.41.19]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA23C2; Thu, 22 Mar 2001 17:18:11 -0500 Message-ID: <3ABA7D24.AB10ACD7@alcatel.com> Date: Thu, 22 Mar 2001 17:31:00 -0500 From: "Nagesh Chintada" Organization: Carrier Internetworking Division, Alcatel X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "John M. Zwiebel" CC: SSM , "pim@catarina.usc.edu" , "msdp@network-services.uoregon.edu" Subject: Re: Why MSDP? References: <200103222154.NAA12217@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit John, See below. "John M. Zwiebel" wrote: > MSDP is required for ISM - or "internet standard multicast". > ISM is not SSM in that it allows building of shared-trees within > an AS which SSM does not. The receiver does not need to know > who the senders to a given group are. Agreed. > > > SSM builds only shortest-path trees because the host can signal > to the last hop router the specific hosts (senders) it wants to > listen to. This rendezvous mechanism is outside of the PIM > protocol and can be discovered any way the application writer > wants it to be. > Agreed. > > MSDP is not required (and not used) to support SSM groups. > Agreed. > > Host routes are not needed in MBGP to be able to join toward the > shortest-path across the internet. > Agreed. for SSM. My question is perhaps not clear, and is nothing to do with SSM. To rephrase, if all that MSDP is doing is to advertize sources, why not let MBGP to do the same? Note that once an RP detects a new source ( via MBGP advt rather than MSDP in this case), it can send a Join to the source in the neighboring domain and setup the tree as it currently does. I agree that the implementations will have to rely on policy for MBGP route insertion in the originating domain and redistribution ( perhaps?) to PIM in the destination domain. I hope that is clear. - Nagesh > > ^ Greetings, > ^ > ^ I have a very basic question: > ^ > ^ First, the context: > ^ For inter-domain Multicasting, one would typically deploy > ^ PIM-SM/MBGP/MSDP protocols..... > ^ MBGP for announcing routes that include subnets containing multicast > ^ sources, and MSDP > ^ to announce sources. > ^ > ^ Since MBGP already has the capability to announce multicast routes, why > ^ not announce host routes of multicast sources as well, using MBGP? If > ^ necessary, one can think of a simple extension to MBGP to mark the host > ^ route as a "source route". IMHO, this will make it much easier to deploy > ^ Multicast without having to worry about delpoying MSDP. > ^ > ^ Any comments? > ^ > ^ Best Regards, > ^ Nagesh > ^ > > ------------------------------------------------------------------------------ > John Zwiebel Phone: 408-526-5303 > Cisco Systems Inc. > IP Multicast Group From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 22 19:26:38 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27432 for ; Thu, 22 Mar 2001 19:26:37 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA11931 for ; Thu, 22 Mar 2001 15:38:28 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2MNc1o01981 for ; Thu, 22 Mar 2001 15:38:04 -0800 (PST) Received: from tahoe.allegronetworks.com (tahoe.allegronetworks.com [63.115.58.10]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2MNXgb10749 for ; Thu, 22 Mar 2001 15:33:42 -0800 (PST) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Mar 2001 15:30:53 -0800 Message-ID: From: Mike diVittorio To: "'Nagesh Chintada'" , "John M. Zwiebel" Cc: SSM , pim@catarina.usc.edu, msdp@network-services.uoregon.edu Subject: RE: Why MSDP? Date: Thu, 22 Mar 2001 15:30:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I have no idea how I got on this distribution, but it does sound like exciting stuff. Please remove me if you are able. Thanks. Mike -----Original Message----- From: Nagesh Chintada [mailto:nagesh.chintada@alcatel.com] Sent: Thursday, March 22, 2001 2:31 PM To: John M. Zwiebel Cc: SSM; pim@catarina.usc.edu; msdp@network-services.uoregon.edu Subject: Re: Why MSDP? John, See below. "John M. Zwiebel" wrote: > MSDP is required for ISM - or "internet standard multicast". > ISM is not SSM in that it allows building of shared-trees within > an AS which SSM does not. The receiver does not need to know > who the senders to a given group are. Agreed. > > > SSM builds only shortest-path trees because the host can signal > to the last hop router the specific hosts (senders) it wants to > listen to. This rendezvous mechanism is outside of the PIM > protocol and can be discovered any way the application writer > wants it to be. > Agreed. > > MSDP is not required (and not used) to support SSM groups. > Agreed. > > Host routes are not needed in MBGP to be able to join toward the > shortest-path across the internet. > Agreed. for SSM. My question is perhaps not clear, and is nothing to do with SSM. To rephrase, if all that MSDP is doing is to advertize sources, why not let MBGP to do the same? Note that once an RP detects a new source ( via MBGP advt rather than MSDP in this case), it can send a Join to the source in the neighboring domain and setup the tree as it currently does. I agree that the implementations will have to rely on policy for MBGP route insertion in the originating domain and redistribution ( perhaps?) to PIM in the destination domain. I hope that is clear. - Nagesh > > ^ Greetings, > ^ > ^ I have a very basic question: > ^ > ^ First, the context: > ^ For inter-domain Multicasting, one would typically deploy > ^ PIM-SM/MBGP/MSDP protocols..... > ^ MBGP for announcing routes that include subnets containing multicast > ^ sources, and MSDP > ^ to announce sources. > ^ > ^ Since MBGP already has the capability to announce multicast routes, why > ^ not announce host routes of multicast sources as well, using MBGP? If > ^ necessary, one can think of a simple extension to MBGP to mark the host > ^ route as a "source route". IMHO, this will make it much easier to deploy > ^ Multicast without having to worry about delpoying MSDP. > ^ > ^ Any comments? > ^ > ^ Best Regards, > ^ Nagesh > ^ > > ---------------------------------------------------------------------------- -- > John Zwiebel Phone: 408-526-5303 > Cisco Systems Inc. > IP Multicast Group From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 22 19:42:53 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27900 for ; Thu, 22 Mar 2001 19:42:52 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA09790 for ; Thu, 22 Mar 2001 15:34:40 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2MNYd105179 for ; Thu, 22 Mar 2001 15:34:39 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2MNUu226151 for ; Thu, 22 Mar 2001 15:30:56 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id E58661E035; Thu, 22 Mar 2001 18:25:50 -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 SAA03605; Thu, 22 Mar 2001 18:25:49 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id RAA13581; Thu, 22 Mar 2001 17:25:48 -0600 (CST) Message-Id: <200103222325.RAA13581@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: nagesh.chintada@alcatel.com Subject: Re: Why MSDP? Cc: ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu Date: Thu, 22 Mar 2001 17:25:48 -0600 Versions: dmail (solaris) 2.2g/makemail 2.9a One reason: the timescales for change of active source indications are much different than BGP was designed to carry. BGP wants to carry data that doesn't change very often, e.g. see route dampening. Sources can come and go at an arbitrary rate, so the rate of change of the information is potentially much higher. Bill From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 22 20:07:56 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28644 for ; Thu, 22 Mar 2001 20:07:55 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA13024 for ; Thu, 22 Mar 2001 16:02:14 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2N01s227815 for ; Thu, 22 Mar 2001 16:01:54 -0800 (PST) Received: from puck.nether.net (root@puck.nether.net [204.42.254.5]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2N01Ib22293 for ; Thu, 22 Mar 2001 16:01:18 -0800 (PST) Received: (from jared@localhost) by puck.nether.net (8.11.1/8.9.3) id f2MNsKU27704; Thu, 22 Mar 2001 18:54:20 -0500 (envelope-from jared) Date: Thu, 22 Mar 2001 18:54:20 -0500 From: Jared Mauch To: Ross Finlayson Cc: Jared Mauch , ssmmailing list , mbone mail list , MboneD Mail List Subject: Re: Auto-tunnel Rant Message-ID: <20010322185420.Z4776@puck.nether.net> References: <3ABA350F.EA27E1E7@21rst-century.com> <4.3.2.7.2.20010322102947.00b88eb0@pop.mcs.anl.gov> <3ABA350F.EA27E1E7@21rst-century.com> <20010322142336.B4776@puck.nether.net> <4.3.1.1.20010322134023.00b31650@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.1.1.20010322134023.00b31650@localhost>; from finlayson@live.com on Thu, Mar 22, 2001 at 02:02:28PM -0600 On Thu, Mar 22, 2001 at 02:02:28PM -0600, Ross Finlayson wrote: > At 01:23 PM 3/22/01, Jared Mauch wrote: > >We have native multicast (almost) everywhere > >and available to customers. I do not like the idea of my routers > >doing auto tunnels across my customers network to their downstream > >customer. > > If your downstream ISP customers don't support native multicast (even > though you do), then they will be multi-unicasting across your network in > any case. If this multi-unicasting happens to be using a tunneling > protocol, and you just choose to ignore this, then it will make no > difference to you. It'll be basically the same[*] traffic either way. > > However, if your downstream customers *are* using an automatic tunneling > protocol, then you - as an upstream provider - now have the *choice* of > reducing this traffic by inserting your own tunneling server(s) into the > stream. But it's your choice. If you don't want to worry about this, then > you don't have to do anything. I'd rather my customers configure native multicast as we have this service available. I'd like to educate my customers to the point that they can turn on pim on their routers and avoid this tunneling. I don't want to have my routers send tunnels to the customer network when if they request/properly configure they can have native multicast. > > They need to be educated and become more savvy in their > >operations. > > Yes, we all agree that this is the ideal solution. I wish you continued > success in educating your downstream ISP customers :-) I think they don't know it's available, or there's not sufficent edge demand that they are requesting multicast. - Jared > [*] This assumes that if your non-native-multicast-enabled downstream > customers don't have multicast tunneling available, then they will just > send/receive plain UDP unicast packets instead. One could argue, however, > that if they don't have the ability to do multicast tunneling, then they > will use TCP instead, or just throw up their hands and do nothing. > > This, I think, is a better argument to make regarding the possible use of > automatic multicast tunneling by your downstream customers. You might > argue that multicast tunneling would lead to an increase of *UDP* traffic > across your network, and that this might be something you decide to be > concerned about. > > Ross. -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 22 20:25:15 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29111 for ; Thu, 22 Mar 2001 20:25:14 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA18034 for ; Thu, 22 Mar 2001 16:34:54 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2N0YtG22758 for ; Thu, 22 Mar 2001 16:34:55 -0800 (PST) Received: from dino-pc.procket.com (flowpoint.procket.com [205.253.146.41]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2N0UYb04187 for ; Thu, 22 Mar 2001 16:30:35 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id QAA30267; Thu, 22 Mar 2001 16:26:37 -0800 Date: Thu, 22 Mar 2001 16:26:37 -0800 Message-Id: <200103230026.QAA30267@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: finlayson@live.com CC: jared@puck.nether.net, ssm-interest@external.cisco.com, mbone@ISI.EDU, mboned@network-services.uoregon.edu In-reply-to: <4.3.1.1.20010322134023.00b31650@localhost> (message from Ross Finlayson on Thu, 22 Mar 2001 14:02:28 -0600) Subject: Re: Auto-tunnel Rant References: <3ABA350F.EA27E1E7@21rst-century.com> <4.3.2.7.2.20010322102947.00b88eb0@pop.mcs.anl.gov> <3ABA350F.EA27E1E7@21rst-century.com> <4.3.1.1.20010322134023.00b31650@localhost> >> This, I think, is a better argument to make regarding the possible use of >> automatic multicast tunneling by your downstream customers. You might >> argue that multicast tunneling would lead to an increase of *UDP* traffic >> across your network, and that this might be something you decide to be >> concerned about. If we put auto-tunneling in the hosts, we will have a Pointcast situation all over again. Which is, a lot of duplicate data going over the same links. Which is no different than mulit-unicast. And we make no progress. You don't want to make networking easy for PC users, you want to make applications easy to use. The network plumbing should be done by skilled professionals, which means they are more likely to deploy tunnels correctly or not at all. Dino From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu Mar 22 20:57:33 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00146 for ; Thu, 22 Mar 2001 20:57:33 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id QAA18981 for ; Thu, 22 Mar 2001 16:54:34 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2N0tnV07877 for ; Thu, 22 Mar 2001 16:55:49 -0800 (PST) Received: from mx2out.umbc.edu (mx2out.umbc.edu [130.85.253.52]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2N0tDb13383 for ; Thu, 22 Mar 2001 16:55:13 -0800 (PST) Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id TAA11124; Thu, 22 Mar 2001 19:41:35 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id TAA884565; Thu, 22 Mar 2001 19:41:35 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Thu, 22 Mar 2001 19:41:35 -0500 From: Vijay Gill X-X-Sender: To: Bill Fenner cc: , , , Subject: Re: Why MSDP? In-Reply-To: <200103222325.RAA13581@windsor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 22 Mar 2001, Bill Fenner wrote: > > One reason: the timescales for change of active source indications are > much different than BGP was designed to carry. BGP wants to carry > data that doesn't change very often, e.g. see route dampening. Sources > can come and go at an arbitrary rate, so the rate of change of the > information is potentially much higher. So churn wasn't ok for BGP, but its ok in MSDP? Just wondering. /vijay From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu Mar 22 21:07:35 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00515 for ; Thu, 22 Mar 2001 21:07:35 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id RAA03668 for ; Thu, 22 Mar 2001 17:08:38 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2N18Zh18041 for ; Thu, 22 Mar 2001 17:08:35 -0800 (PST) Received: from dino-pc.procket.com (flowpoint.procket.com [205.253.146.41]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2N180b18433 for ; Thu, 22 Mar 2001 17:08:00 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id RAA30379; Thu, 22 Mar 2001 17:04:56 -0800 Date: Thu, 22 Mar 2001 17:04:56 -0800 Message-Id: <200103230104.RAA30379@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: luby@digitalfountain.com CC: jzwiebel@cisco.com, nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu In-reply-to: Subject: Re: Why MSDP? References: >> John, >> One of the things that I think we might have come to consensus on at the >> IETF on Tuesday is to start calling the multicast service model defined in >> RFC 1112 as "Any-Source Multicas" (ASM) hereafter (instead of ISM or Now that we're talking about names, Any-Source-Multicast presumes that SSM can't have multiple sources. You can certainly have a small conference with 3 participants which are each sourcing data, each using their own source-tree. But I'm in favor of keeping acroynms as simple as possible, so I would suggest: SSM - single source multicast (because changing this will really confuse people - again) OM - original multicast Dino From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 22 21:45:55 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02772 for ; Thu, 22 Mar 2001 21:45:55 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA02612 for ; Thu, 22 Mar 2001 17:59:59 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA18274; Thu, 22 Mar 2001 17:59:20 -0800 (PST) Date: Thu, 22 Mar 2001 17:59:20 -0800 From: Toerless Eckert To: Dino Farinacci Cc: luby@digitalfountain.com, jzwiebel@cisco.com, nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu Subject: Re: Why MSDP? Message-ID: <20010322175920.U6277@cypher.cisco.com> References: <200103230104.RAA30379@dino-pc.procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103230104.RAA30379@dino-pc.procket.com>; from dino@procket.com on Thu, Mar 22, 2001 at 05:04:56PM -0800 On Thu, Mar 22, 2001 at 05:04:56PM -0800, Dino Farinacci wrote: > But I'm in favor of keeping acroynms as simple as possible, so I would > suggest: > > SSM - single source multicast (because changing this will really > confuse people - again) Well, i thought we'd already called this "Source Specific Multicast" for quite a while. At least in all the specs in the SSM working group. And if you have that meaning of SSM, then ASM makes a very good distinction: In SSM you the receiver must be SPECIFIC about which source you want traffic from (and right, it can be more than one), and in ASM you take traffic from ANY source. > OM - original multicast Oh no, yet another abbreviation ;-)) Cheers Toerless From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Mar 22 22:50:07 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06014 for ; Thu, 22 Mar 2001 22:50:07 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA01233 for ; Thu, 22 Mar 2001 18:52:36 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2N2qDi15704 for ; Thu, 22 Mar 2001 18:52:13 -0800 (PST) Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2N2mS206871 for ; Thu, 22 Mar 2001 18:48:28 -0800 (PST) Received: from dstc.edu.au (sunburn.dstc.edu.au [130.102.176.16]) by piglet.dstc.edu.au (8.11.3/8.11.3) with ESMTP id f2N2X0417530; Fri, 23 Mar 2001 12:33:00 +1000 (EST) To: Dino Farinacci cc: finlayson@live.com, jared@puck.nether.net, ssm-interest@external.cisco.com, mbone@ISI.EDU, mboned@network-services.uoregon.edu Subject: Re: Auto-tunnel Rant In-reply-to: Your message of "Thu, 22 Mar 2001 16:26:37 PST." <200103230026.QAA30267@dino-pc.procket.com> Date: Fri, 23 Mar 2001 12:32:59 +1000 Message-ID: <12583.985314779@dstc.edu.au> From: George Michaelson X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) There is probably a layering violation opr encapsulated traffic fubar but I do want to ask, why its not possible for a multicast enabled upstream to intercept a tunnel, and just *make* the endpoint terminate there which should (in a global multicast) do the right thing anyway. Obviously, 'private' tunnels are just that: but if a public framework which is acting as a 'find me a multicast' is going to tunnel over an enabled fabric, why not tear it open there? I can't see what the multicast-centric answer is that makes this bad the ISP is multicasting already: they can't object to the traffic class its traffic efficient its actually a higher QoS than the user asked for since the mesh will have true local scopes So its the layer or privacy violation thats a problem? -George From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Mar 22 22:59:06 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06300 for ; Thu, 22 Mar 2001 22:59:05 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id TAA00567 for ; Thu, 22 Mar 2001 19:07:04 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2N371S17817 for ; Thu, 22 Mar 2001 19:07:01 -0800 (PST) Received: from puck.nether.net (root@puck.nether.net [204.42.254.5]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2N373211223 for ; Thu, 22 Mar 2001 19:07:03 -0800 (PST) Received: (from jared@localhost) by puck.nether.net (8.11.1/8.9.3) id f2N2vLW02952; Thu, 22 Mar 2001 21:57:21 -0500 (envelope-from jared) Date: Thu, 22 Mar 2001 21:57:21 -0500 From: Jared Mauch To: George Michaelson Cc: Dino Farinacci , finlayson@live.com, jared@puck.nether.net, ssm-interest@external.cisco.com, mbone@ISI.EDU, mboned@network-services.uoregon.edu Subject: Re: Auto-tunnel Rant Message-ID: <20010322215721.J31741@puck.nether.net> References: <200103230026.QAA30267@dino-pc.procket.com> <12583.985314779@dstc.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <12583.985314779@dstc.edu.au>; from ggm@dstc.edu.au on Fri, Mar 23, 2001 at 12:32:59PM +1000 My concern becomes that lets say streaming vendor X becomes a customer of my global ip network because we support native multicast and offer this as a service. I am not opposed to tunneling over equipment within my network that does not support pim-sm, ssm, etc.. What I am opposed to is now the rest of the non-multicast enabled internet turns my routers into big tunneling machines to provide services across my public and private peering links to other networks customers that do not have multicast deployed. This means I may end up with hundreds of tunnels out each peering link and increasing the burden on my routers. This means that I am not paid for this packet replication across the private/public link and is now giving my customer 100x the bandwidth for the cost of a single outgoing stream when it costs me more than that to deliver it to other networks. If the network offers multicast delivering this traffic to them in an efficent manner is acceptable. While I wouldn't mind becoming the #1 provider, I don't want to provide tunneling across any interprovider links that I have (that are not customers). Education in deploying SSM, and pim-sm multicast I think is important in getting deployment rates higher than what they are presently. These are my concerns. - Jared On Fri, Mar 23, 2001 at 12:32:59PM +1000, George Michaelson wrote: > > There is probably a layering violation opr encapsulated traffic fubar > but I do want to ask, why its not possible for a multicast enabled > upstream to intercept a tunnel, and just *make* the endpoint terminate there > which should (in a global multicast) do the right thing anyway. > > Obviously, 'private' tunnels are just that: but if a public framework > which is acting as a 'find me a multicast' is going to tunnel over an > enabled fabric, why not tear it open there? > > I can't see what the multicast-centric answer is that makes this bad > > the ISP is multicasting already: they can't object to the traffic > class > > its traffic efficient > > its actually a higher QoS than the user asked for since the mesh > will have true local scopes > > So its the layer or privacy violation thats a problem? > > -George > -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri Mar 23 00:50:03 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10190 for ; Fri, 23 Mar 2001 00:50:03 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA07218; Thu, 22 Mar 2001 21:01:58 -0800 (PST) Received: from cisco.com (dhcp-171-69-127-181.cisco.com [171.69.127.181]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AAE02652 (AUTH jmeylor); Thu, 22 Mar 2001 21:01:36 -0800 (PST) Message-ID: <3ABAD8FA.418BD624@cisco.com> Date: Thu, 22 Mar 2001 21:02:50 -0800 From: John Meylor X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Toerless Eckert CC: Dino Farinacci , luby@digitalfountain.com, jzwiebel@cisco.com, nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu Subject: Re: Why MSDP? References: <200103230104.RAA30379@dino-pc.procket.com> <20010322175920.U6277@cypher.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Toerless Eckert wrote: > > On Thu, Mar 22, 2001 at 05:04:56PM -0800, Dino Farinacci wrote: > > But I'm in favor of keeping acroynms as simple as possible, so I would > > suggest: > > > > SSM - single source multicast (because changing this will really > > confuse people - again) > > Well, i thought we'd already called this "Source Specific Multicast" for quite > a while. At least in all the specs in the SSM working group. right, it treats sources specifically, rather than all sources generally, but can address several sources specifically so it isn't really limited to a "single source". Dino, I think this would resolve your point, correct? And based on this conclusion from last year, all the SSM related drafts use Source Specific in the expansion, so SSM = Source Specific Multicast would require the least (zero) change. > And if you have that meaning of SSM, then ASM makes a very good distinction: > In SSM you the receiver must be SPECIFIC about which source you want traffic > from (and right, it can be more than one), and in ASM you take traffic from > ANY source. agree, ASM seems fine to me. John John From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri Mar 23 00:50:25 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10207 for ; Fri, 23 Mar 2001 00:50:25 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA06908; Thu, 22 Mar 2001 21:00:56 -0800 (PST) Received: from cisco.com (dhcp-171-69-127-181.cisco.com [171.69.127.181]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AAE02634 (AUTH jmeylor); Thu, 22 Mar 2001 21:00:34 -0800 (PST) Message-ID: <3ABAD8BC.789E27CD@cisco.com> Date: Thu, 22 Mar 2001 21:01:48 -0800 From: John Meylor X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Gill CC: Bill Fenner , nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu Subject: Re: Why MSDP? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Gill wrote: > > On Thu, 22 Mar 2001, Bill Fenner wrote: > > > > > One reason: the timescales for change of active source indications are > > much different than BGP was designed to carry. BGP wants to carry > > data that doesn't change very often, e.g. see route dampening. Sources > > can come and go at an arbitrary rate, so the rate of change of the > > information is potentially much higher. > > So churn wasn't ok for BGP, but its ok in MSDP? Just wondering. Vijay, yes, sa turnover and cache size variability in MSDP is perfectly normal and expected behavior in the interdomain msdp topology, (reflecting sources becoming active or non-active which is cool) and with basic filtering in place (for bogus/unwanted registers, sa-messages, etc) this "churn" is ok. (Of course in BGP you don't expect lots and lots of prefixes to be coming and going regularly, so thats not ok.) However, just as with unicast reachability in BGP, if you don't control what information you are receiving or announcing (eg in bgp from redistributing igp, or not filtering on peering), then msdp churn can quickly become "not ok". I think one of the conclusions drawn at MBONED WG this week was to define some standard policy practices for PIM/MSDP which could help make sure we can avoid unwanted contributions to churn in msdp topology, see Marshall Eubanks talk. John From owner-extdom.ssm-interest@rtp-msg-core-1.cisco.com Fri Mar 23 01:00:27 2001 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10528 for ; Fri, 23 Mar 2001 01:00:27 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id AAA08653 for ; Fri, 23 Mar 2001 00:12:37 -0500 (EST) Received: from localhost (jzwiebel@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA21762; Thu, 22 Mar 2001 21:12:41 -0800 (PST) Message-Id: <200103230512.VAA21762@cisco.com> To: Dino Farinacci cc: finlayson@live.com, jared@puck.nether.net, ssm-interest@external.cisco.com, mbone@ISI.EDU, mboned@network-services.uoregon.edu Subject: Re: Auto-tunnel Rant In-reply-to: Your message of "Thu, 22 Mar 2001 16:26:37 PST." <200103230026.QAA30267@dino-pc.procket.com> Date: Thu, 22 Mar 2001 21:12:40 -0800 From: "John M. Zwiebel" ^ ^ You don't want to make networking easy for PC users, you want to make ^ applications easy to use. The network plumbing should be done by skilled ^ professionals, which means they are more likely to deploy tunnels correctly ^ or not at all. You mean, skilled professionals like "us"??? ;-> ------------------------------------------------------------------------------ John Zwiebel Phone: 408-526-5303 Cisco Systems Inc. IP Multicast Group From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Mar 23 01:20:34 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12933 for ; Fri, 23 Mar 2001 01:20:34 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id VAA01342 for ; Thu, 22 Mar 2001 21:34:17 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2N5YDJ20568 for ; Thu, 22 Mar 2001 21:34:13 -0800 (PST) Received: from mx1out.umbc.edu (mx1out.umbc.edu [130.85.253.51]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2N5YF215983 for ; Thu, 22 Mar 2001 21:34:16 -0800 (PST) Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id AAA07008; Fri, 23 Mar 2001 00:19:56 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id AAA926775; Fri, 23 Mar 2001 00:19:55 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Fri, 23 Mar 2001 00:19:55 -0500 From: Vijay Gill X-X-Sender: To: John Meylor cc: Bill Fenner , , , , Subject: Re: Why MSDP? In-Reply-To: <3ABAD8BC.789E27CD@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 22 Mar 2001, John Meylor wrote: > > So churn wasn't ok for BGP, but its ok in MSDP? Just wondering. > > Vijay, yes, [snip] > for PIM/MSDP which could help make sure we can avoid > unwanted contributions to churn in msdp topology, see > Marshall Eubanks talk. John, thanks for the very useful explanation. The question was asked half in jest, without expecting any serious answers, but the answer is appreciated nevertheless. Anyway, jhall and I still owe you a pizza, let us know when and where. /vijay From owner-extdom.ssm-interest@rtp-msg-core-1.cisco.com Fri Mar 23 01:22:57 2001 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13360 for ; Fri, 23 Mar 2001 01:22:56 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id AAA08784 for ; Fri, 23 Mar 2001 00:23:47 -0500 (EST) Received: from localhost (jzwiebel@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA23713; Thu, 22 Mar 2001 21:23:55 -0800 (PST) Message-Id: <200103230523.VAA23713@cisco.com> To: eckert@cisco.com cc: Dino Farinacci , luby@digitalfountain.com, nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu Subject: Re: Why MSDP? In-reply-to: Your message of "Thu, 22 Mar 2001 17:59:20 PST." <20010322175920.U6277@cypher.cisco.com> Date: Thu, 22 Mar 2001 21:23:55 -0800 From: "John M. Zwiebel" How about MMP -- (M)SDP/(M)BPG/(P)IM. ^ On Thu, Mar 22, 2001 at 05:04:56PM -0800, Dino Farinacci wrote: ^ > But I'm in favor of keeping acroynms as simple as possible, so I would ^ > suggest: ^ > ^ > SSM - single source multicast (because changing this will really ^ > confuse people - again) ^ ^ Well, i thought we'd already called this "Source Specific Multicast" for qui te ^ a while. At least in all the specs in the SSM working group. ^ ^ And if you have that meaning of SSM, then ASM makes a very good distinction: ^ In SSM you the receiver must be SPECIFIC about which source you want traffic ^ from (and right, it can be more than one), and in ASM you take traffic from ^ ANY source. ^ ^ > OM - original multicast ^ ^ Oh no, yet another abbreviation ;-)) ^ ^ Cheers ^ Toerless ------------------------------------------------------------------------------ John Zwiebel Phone: 408-526-5303 Cisco Systems Inc. IP Multicast Group From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Fri Mar 23 02:46:11 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27165 for ; Fri, 23 Mar 2001 02:46:10 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id WAA22222 for ; Thu, 22 Mar 2001 22:53:04 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2N6sHd28671 for ; Thu, 22 Mar 2001 22:54:17 -0800 (PST) Received: from dino-pc.procket.com (flowpoint.procket.com [205.253.146.41]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2N6rhb14592 for ; Thu, 22 Mar 2001 22:53:43 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id WAA31117; Thu, 22 Mar 2001 22:51:46 -0800 Date: Thu, 22 Mar 2001 22:51:46 -0800 Message-Id: <200103230651.WAA31117@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: jmeylor@cisco.com CC: eckert@cisco.com, luby@digitalfountain.com, jzwiebel@cisco.com, nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu In-reply-to: <3ABAD8FA.418BD624@cisco.com> (message from John Meylor on Thu, 22 Mar 2001 21:02:50 -0800) Subject: Re: Why MSDP? References: <200103230104.RAA30379@dino-pc.procket.com> <20010322175920.U6277@cypher.cisco.com> <3ABAD8FA.418BD624@cisco.com> >> right, it treats sources specifically, rather than all sources >> generally, but can address several sources specifically >> so it isn't really limited to a "single source". >> Dino, I think this would resolve your point, correct? Right. I did't mean to imply single source. I really thought that was the acronym expansion. I wanted to propose what was already decided on and just consider an alternative name for ASM or ISM. Dino From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri Mar 23 03:03:27 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27791 for ; Fri, 23 Mar 2001 03:03:27 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id XAA16356 for ; Thu, 22 Mar 2001 23:14:41 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2N7EL109179 for ; Thu, 22 Mar 2001 23:14:21 -0800 (PST) Received: from dino-pc.procket.com (flowpoint.procket.com [205.253.146.41]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2N7Dkb18792 for ; Thu, 22 Mar 2001 23:13:46 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id XAA31151; Thu, 22 Mar 2001 23:10:16 -0800 Date: Thu, 22 Mar 2001 23:10:16 -0800 Message-Id: <200103230710.XAA31151@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: ggm@dstc.edu.au CC: finlayson@live.com, jared@puck.nether.net, ssm-interest@external.cisco.com, mbone@ISI.EDU, mboned@network-services.uoregon.edu In-reply-to: <12583.985314779@dstc.edu.au> (message from George Michaelson on Fri, 23 Mar 2001 12:32:59 +1000) Subject: Re: Auto-tunnel Rant References: <12583.985314779@dstc.edu.au> >> There is probably a layering violation opr encapsulated traffic fubar >> but I do want to ask, why its not possible for a multicast enabled >> upstream to intercept a tunnel, and just *make* the endpoint terminate there >> which should (in a global multicast) do the right thing anyway. Because the number of tunnels cannot be bounded. Even if you configure who is allowed to connect to you, as Radia indicated in her talk, you still have to configure something, so it may as well be a list of tunnels. I was arguing for static versus dynamic tunnels at MBONED. It is extremely dangerous to abuse a router with unknown fanout. As I indicated in MBONED, memory sizes, switching capacity, buffer memory k capacity are all based on the speeds and feeds the router is designed for. When replication is based on the physical interfaces, you can engineer a box that actually does wire-speed multicast. Once you add tunnels (unbounded or an unknown number) to the equation, you lose throughput in a big way. I also mentioned a very simple solution: o PCs (windows) can already do multicast over their dial-up adaptors. o Therefore IGMP messages can go to the dialed-up NAS device at the ISP. o If you configure the NAS device to GRE tunnel to existing Juniper or cisco boxes which reside in the multicast-capable cloud, you're done. Problem solved. This is a lot different than asking a tier 2 or tier 3 ISP to run native multicast. Of course, that is what we should encourage them to do but the whole idea of doing tunnels at the edge of the network is to nudge these access ISPs to see the light of multicast. So we have to proceed one slow step at a time unfortunately. The NAS boxes don't even have to do full multicast routing. Simply forward IGMP reports received on an async line over the tunnel to the multicast configured router in the backbone. Doing this gets you 1-to-many source-tree based unbiqituous multicast. AOL, Earthlink, and UUnet, are you listening? Dino From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Fri Mar 23 11:59:31 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24667 for ; Fri, 23 Mar 2001 11:59:30 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA07364 for ; Fri, 23 Mar 2001 07:18:17 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2NFIEX08048 for ; Fri, 23 Mar 2001 07:18:14 -0800 (PST) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2NFI6i24432 for ; Fri, 23 Mar 2001 07:18:06 -0800 (PST) Received: from nsamail01.us.newbridge.com (nsamail01.us.newbridge.com [138.120.244.77]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA00526 for ; Fri, 23 Mar 2001 09:03:06 -0600 (CST) Received: from alcatel.com ([198.205.41.19]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA5E8C; Fri, 23 Mar 2001 10:00:46 -0500 Message-ID: <3ABB6820.12ECDD15@alcatel.com> Date: Fri, 23 Mar 2001 10:13:36 -0500 From: "Nagesh Chintada" Organization: Carrier Internetworking Division, Alcatel X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu Subject: Re: Why MSDP? References: <200103222325.RAA13581@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bill, Isn't it true that MBGP alread is used to announce multicast routes to these sources? They may not be host routes but still MBGP is carrying routes for these sources! Agreed that distributing source routes is a little more work for MBGP, but IMHO it is far less work that deploying MSDP protocol. And BGP does indeed handle a large amount of route changes..... Besides, relying on an MBGP solution will 1. Make it much easier to deploy PIM-SM interdomain. It becomes as easy ( or so they say) as deploying SSM interdomain. 2. Eliminate the extra traffic that is carried by MSDP msgs. 3. Make it that much easier to manage 4. Probably speed up adoption of multicast by ISPs. I think there are lots of advantages to using MBGP... can someone explain what I may be missing here? Cheers, Nagesh Bill Fenner wrote: > One reason: the timescales for change of active source indications are > much different than BGP was designed to carry. BGP wants to carry > data that doesn't change very often, e.g. see route dampening. Sources > can come and go at an arbitrary rate, so the rate of change of the > information is potentially much higher. > > Bill From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Mar 23 12:18:18 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26041 for ; Fri, 23 Mar 2001 12:18:18 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id HAA20038 for ; Fri, 23 Mar 2001 07:47:54 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2NFloX05420 for ; Fri, 23 Mar 2001 07:47:50 -0800 (PST) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2NFlFW08596 for ; Fri, 23 Mar 2001 07:47:15 -0800 (PST) Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by letters.cs.ucsb.edu (8.9.3+Sun/8.9.3) with ESMTP id HAA09755; Fri, 23 Mar 2001 07:32:49 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id HAA29445 for ; Fri, 23 Mar 2001 07:32:48 -0800 (PST) Date: Fri, 23 Mar 2001 07:32:48 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200103231532.HAA29445@jackson.cs.ucsb.edu> To: mbone@ISI.EDU, mboned@network-services.uoregon.edu, ssm-interest@external.cisco.com Subject: Re: Auto-tunnel Rant Well, I'll add my voice to the rest of the noise. As I see it, auto-tunneling is fine. Why? 1. Let's not get in the business of protecting people from themselves (in reference to Dino's comment about large fanout is bad... it is, sure, but who cares?) 2. Let people run whatever they want in their own cloud. To force people to only do network-layer multicast is wrong because: (a) You should be able to do whatever you want (See 1.) (b) We are in a transition period and not every single device supports multicast. Until every single device can handle multicast we need things like tunneling (any maybe auto-). Why? See 3. 3. An infrastructure that has devices that don't support multicast and so no way for the eyeballs on the other end to see the content is ultimately defeating for multicast. Yes we can be multicast advocates, but saying that someone can't play in our sandbox because they haven't bought the latest equipment from Vendor X hurts us more than it hurts the rest of the world. In the end: who cares if there is tunneling? or even auto-tunneling? Who cares if people expend effort deploying non-network-layer multicast? If they weren't smart enough in the first place they probably wouldn't have been smart enough to deploy multicast anyway. NOW... the real question is should the IETF be standardizing a way to do this? My intuition... NO. Let some clever vendor sell a piece of hardware or software that makes it mostly seemless. Done. It creates pain that is solved by... ta dah: network-layer multicast. -Kevin From owner-extdom.ssm-interest@rtp-msg-core-1.cisco.com Fri Mar 23 12:31:40 2001 Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27037 for ; Fri, 23 Mar 2001 12:31:39 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA01959 for ; Fri, 23 Mar 2001 11:20:57 -0500 (EST) Received: from localhost (jzwiebel@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA26251; Fri, 23 Mar 2001 08:21:32 -0800 (PST) Message-Id: <200103231621.IAA26251@cisco.com> To: almeroth@cs.ucsb.edu (Kevin C. Almeroth) cc: mbone@ISI.EDU, mboned@network-services.uoregon.edu, ssm-interest@external.cisco.com Subject: Re: Auto-tunnel Rant In-reply-to: Your message of "Fri, 23 Mar 2001 07:32:48 PST." <200103231532.HAA29445@jackson.cs.ucsb.edu> Date: Fri, 23 Mar 2001 08:21:31 -0800 From: "John M. Zwiebel" ^ ^ NOW... the real question is should the IETF be standardizing ^ a way to do this? My intuition... NO. Let some clever vendor ^ sell a piece of hardware or software that makes it mostly ^ seemless. Done. It creates pain that is solved by... ^ ta dah: network-layer multicast. ^ IMHO, as soon as you say this, it means it isn't going to happen on routers so why are we talking about it? ------------------------------------------------------------------------------ John Zwiebel Phone: 408-526-5303 Cisco Systems Inc. IP Multicast Group From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Fri Mar 23 12:42:59 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27906 for ; Fri, 23 Mar 2001 12:42:58 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA07666 for ; Fri, 23 Mar 2001 08:10:12 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2NG9Xi26195 for ; Fri, 23 Mar 2001 08:09:33 -0800 (PST) Received: from guppy.vub.ac.be (guppy.vub.ac.be [134.184.129.2]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2NG9Yk18526 for ; Fri, 23 Mar 2001 08:09:35 -0800 (PST) Received: from info1.vub.ac.be (info1.vub.ac.be [134.184.1.1]) by guppy.vub.ac.be (8.9.1b+Sun/3.17.1.ap (guppy)) id RAA23046; Fri, 23 Mar 2001 17:06:51 +0100 (MET) for Received: from info.vub.ac.be by info1.vub.ac.be (SMI-8.6/SMI-SVR4-INFO-HUB-110196) id RAA17195; Fri, 23 Mar 2001 17:09:26 +0100 Message-ID: <3ABB7480.A6AF3B06@info.vub.ac.be> Date: Fri, 23 Mar 2001 17:06:24 +0100 From: Pieter Liefooghe X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jared Mauch CC: George Michaelson , Dino Farinacci , finlayson@live.com, ssm-interest@external.cisco.com, mbone@ISI.EDU, mboned@network-services.uoregon.edu Subject: Re: Auto-tunnel Rant References: <200103230026.QAA30267@dino-pc.procket.com> <12583.985314779@dstc.edu.au> <20010322215721.J31741@puck.nether.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jared Mauch wrote: > My concern becomes that lets say streaming vendor X > becomes a customer of my global ip network because we support > native multicast and offer this as a service. I am not opposed > to tunneling over equipment within my network that does not support > pim-sm, ssm, etc.. What I am opposed to is now the rest of > the non-multicast enabled internet turns my routers into > big tunneling machines to provide services across my public and > private peering links to other networks customers that do not > have multicast deployed. Due to lack of time I was unable to present all different possible deployment scenarios as I intended, but the CastGate architecture has a solution for you concerns. In the CastGate architecture, you as an ISP can deploy your own Tunnel Database Server to enforce a local policy. You can make sure that only YOUR customers get tunnels (....Or even only those who have paid for it - when interfaced via Radius), you are not required to participate in the "Global" effort! (though it would be nice ;-) ) The deployment of the Tunnel Database is very simple just indicate for which of your own networks you want to enable tunnels (omit country entry) and install some Tunnel Servers (possibly relay Tunnel Servers) at "strategic" locations in your network. This is different from the other proposals who - as described in their drafts - have no way to enforce a policy. In the CastGate architecture, if one tunnel end-point does not want to act as tunnel point for a certain client, then the client can still find a tunnel end-point located in the country or the region (so called public tunnel servers). All other tunnel proposals - especially the AMT draft doesn't have a solution for this because the anycast will always yield the same relay who is the "nearest". The Auto tunnel proposal by Ross, does have a solution for this...it travels up the path towards the sender to find a router to terminate the tunnel... but whatever happens the traffic is anyway going to go through the downstream routers (also the router who decided not to terminate the tunnel). Pieter From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri Mar 23 13:01:57 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29265 for ; Fri, 23 Mar 2001 13:01:56 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA21345 for ; Fri, 23 Mar 2001 08:58:06 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2NGok405079 for ; Fri, 23 Mar 2001 08:50:46 -0800 (PST) Received: from darkwing.uoregon.edu (llynch@darkwing.uoregon.edu [128.223.142.13]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2NGkPW05019 for ; Fri, 23 Mar 2001 08:46:25 -0800 (PST) Received: from localhost (llynch@localhost) by darkwing.uoregon.edu (8.10.1/8.10.1) with ESMTP id f2NGVrV29796; Fri, 23 Mar 2001 08:31:53 -0800 (PST) Date: Fri, 23 Mar 2001 08:31:53 -0800 (PST) From: "Lucy E. Lynch" To: Pieter Liefooghe cc: , , Subject: Re: Auto-tunnel Rant In-Reply-To: <3ABB7480.A6AF3B06@info.vub.ac.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 23 Mar 2001, Pieter Liefooghe wrote: > > Due to lack of time I was unable to present all different possible deployment > scenarios as I intended, but the CastGate architecture has a solution for you > concerns. Pieter - Are your GateCast slides available somewhere? Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch@darkwing.uoregon.edu (541) 346-1774 Cell: (541) 912-7998 5419127998@mobile.att.net From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri Mar 23 13:26:44 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00110 for ; Fri, 23 Mar 2001 13:26:39 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA08870 for ; Fri, 23 Mar 2001 09:19:03 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2NHIhY03538 for ; Fri, 23 Mar 2001 09:18:43 -0800 (PST) Received: from guppy.vub.ac.be (guppy.vub.ac.be [134.184.129.2]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2NHEni03731 for ; Fri, 23 Mar 2001 09:14:50 -0800 (PST) Received: from info1.vub.ac.be (info1.vub.ac.be [134.184.1.1]) by guppy.vub.ac.be (8.9.1b+Sun/3.17.1.ap (guppy)) id SAA01215; Fri, 23 Mar 2001 18:12:25 +0100 (MET) for Received: from info.vub.ac.be by info1.vub.ac.be (SMI-8.6/SMI-SVR4-INFO-HUB-110196) id SAA17469; Fri, 23 Mar 2001 18:15:00 +0100 Message-ID: <3ABB83DE.4C50ED1A@info.vub.ac.be> Date: Fri, 23 Mar 2001 18:11:58 +0100 From: Pieter Liefooghe X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Lucy E. Lynch" CC: ssm-interest@external.cisco.com, mbone@ISI.EDU, mboned@network-services.uoregon.edu Subject: Re: Auto-tunnel Rant References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Lucy E. Lynch" wrote: > On Fri, 23 Mar 2001, Pieter Liefooghe wrote: > > > > Due to lack of time I was unable to present all different possible deployment > > scenarios as I intended, but the CastGate architecture has a solution for you > > concerns. > > Pieter - > > Are your GateCast slides available somewhere? Yes, http://www.castguide.com/IETF/IETF-liefooghe-castgate.pdf the castgate draft can also be found at: http://www.castguide.com/IETF/draft-liefooghe-castgate-00.txt If you or anyone on this list has any question about it...just ask! Pieter From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Fri Mar 23 13:33:11 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00234 for ; Fri, 23 Mar 2001 13:33:10 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id JAA06966 for ; Fri, 23 Mar 2001 09:33:51 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2NHZ5h16921 for ; Fri, 23 Mar 2001 09:35:05 -0800 (PST) Received: from guppy.vub.ac.be (guppy.vub.ac.be [134.184.129.2]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2NHYvi16023 for ; Fri, 23 Mar 2001 09:34:57 -0800 (PST) Received: from info1.vub.ac.be (info1.vub.ac.be [134.184.1.1]) by guppy.vub.ac.be (8.9.1b+Sun/3.17.1.ap (guppy)) id SAA03120; Fri, 23 Mar 2001 18:32:37 +0100 (MET) for Received: from info.vub.ac.be by info1.vub.ac.be (SMI-8.6/SMI-SVR4-INFO-HUB-110196) id SAA17559; Fri, 23 Mar 2001 18:35:12 +0100 Message-ID: <3ABB8899.2AD24A6D@info.vub.ac.be> Date: Fri, 23 Mar 2001 18:32:10 +0100 From: Pieter Liefooghe X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jared Mauch CC: "Kevin C. Almeroth" , mbone@ISI.EDU, mboned@network-services.uoregon.edu, ssm-interest@external.cisco.com Subject: Re: Auto-tunnel Rant References: <200103231532.HAA29445@jackson.cs.ucsb.edu> <20010323115228.L28133@puck.nether.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jared Mauch wrote: > On Fri, Mar 23, 2001 at 07:32:48AM -0800, Kevin C. Almeroth wrote: > > Well, I'll add my voice to the rest of the noise. As I see it, > > auto-tunneling is fine. Why? > > > > 1. Let's not get in the business of protecting people from > > themselves (in reference to Dino's comment about large > > fanout is bad... it is, sure, but who cares?) > > Those of us who are customers of router vendors (not > server/software vendors) have concerns about this impacting our > routers should they spend time creating tunnels. large fanout > is bad in this case as to get upgrades to the cpu/power in these > takes 18 months as compared to the server market that gets a faster > cpu every few months and it is easier to add extra machines when it's > needed. That is the idea behind the CastGate proposal, it even allows to distribute the tunnel end-points over your network....the CastGate client will use - if allowed by your policy - the Tunnel server reacheable via the least congested path! I don't need routers in the proposal, I use PC's who are really cheap as compared to even basic routers. ;-) > > 2. Let people run whatever they want in their own cloud. > > To force people to only do network-layer multicast is > > wrong because: > > > > (a) You should be able to do whatever you want (See 1.) > > > > (b) We are in a transition period and not every > > single device supports multicast. Until every > > single device can handle multicast we need things > > like tunneling (any maybe auto-). Why? See 3. > > > > 3. An infrastructure that has devices that don't support > > multicast and so no way for the eyeballs on the other > > end to see the content is ultimately defeating for > > multicast. Yes we can be multicast advocates, but saying > > that someone can't play in our sandbox because they > > haven't bought the latest equipment from Vendor X hurts > > us more than it hurts the rest of the world. > > > > In the end: who cares if there is tunneling? or even > > I don't care about tunneling, unless the burden gets > palced on my routers. As mentioned above, CastGate Tunnel Servers (and Tunnel Database Servers) are just PC's located in strategic locations in your network. > > > > auto-tunneling? Who cares if people expend effort deploying > > non-network-layer multicast? If they weren't smart enough in > > the first place they probably wouldn't have been smart enough > > to deploy multicast anyway. > > > > NOW... the real question is should the IETF be standardizing > > a way to do this? My intuition... NO. Let some clever vendor > > sell a piece of hardware or software that makes it mostly > > seemless. I guess, I will just finish building all my components and let it loose..(give me another month or so)...we will see what happens ;-) Bye, Pieter From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri Mar 23 13:39:38 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00394 for ; Fri, 23 Mar 2001 13:39:38 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA06407 for ; Fri, 23 Mar 2001 09:15:49 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2NH3Ni16587 for ; Fri, 23 Mar 2001 09:03:23 -0800 (PST) Received: from puck.nether.net (root@puck.nether.net [204.42.254.5]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2NGx2W10943 for ; Fri, 23 Mar 2001 08:59:02 -0800 (PST) Received: (from jared@localhost) by puck.nether.net (8.11.1/8.9.3) id f2NGqSi29890; Fri, 23 Mar 2001 11:52:28 -0500 (envelope-from jared) Date: Fri, 23 Mar 2001 11:52:28 -0500 From: Jared Mauch To: "Kevin C. Almeroth" Cc: mbone@ISI.EDU, mboned@network-services.uoregon.edu, ssm-interest@external.cisco.com Subject: Re: Auto-tunnel Rant Message-ID: <20010323115228.L28133@puck.nether.net> References: <200103231532.HAA29445@jackson.cs.ucsb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103231532.HAA29445@jackson.cs.ucsb.edu>; from almeroth@cs.ucsb.edu on Fri, Mar 23, 2001 at 07:32:48AM -0800 On Fri, Mar 23, 2001 at 07:32:48AM -0800, Kevin C. Almeroth wrote: > Well, I'll add my voice to the rest of the noise. As I see it, > auto-tunneling is fine. Why? > > 1. Let's not get in the business of protecting people from > themselves (in reference to Dino's comment about large > fanout is bad... it is, sure, but who cares?) Those of us who are customers of router vendors (not server/software vendors) have concerns about this impacting our routers should they spend time creating tunnels. large fanout is bad in this case as to get upgrades to the cpu/power in these takes 18 months as compared to the server market that gets a faster cpu every few months and it is easier to add extra machines when it's needed. > 2. Let people run whatever they want in their own cloud. > To force people to only do network-layer multicast is > wrong because: > > (a) You should be able to do whatever you want (See 1.) > > (b) We are in a transition period and not every > single device supports multicast. Until every > single device can handle multicast we need things > like tunneling (any maybe auto-). Why? See 3. > > 3. An infrastructure that has devices that don't support > multicast and so no way for the eyeballs on the other > end to see the content is ultimately defeating for > multicast. Yes we can be multicast advocates, but saying > that someone can't play in our sandbox because they > haven't bought the latest equipment from Vendor X hurts > us more than it hurts the rest of the world. > > In the end: who cares if there is tunneling? or even I don't care about tunneling, unless the burden gets palced on my routers. > auto-tunneling? Who cares if people expend effort deploying > non-network-layer multicast? If they weren't smart enough in > the first place they probably wouldn't have been smart enough > to deploy multicast anyway. > > NOW... the real question is should the IETF be standardizing > a way to do this? My intuition... NO. Let some clever vendor > sell a piece of hardware or software that makes it mostly > seemless. Done. It creates pain that is solved by... > ta dah: network-layer multicast. :) - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Mar 23 14:03:53 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00823 for ; Fri, 23 Mar 2001 14:03:52 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA14649 for ; Fri, 23 Mar 2001 09:46:54 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2NHkpq00613 for ; Fri, 23 Mar 2001 09:46:51 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2NHkEW03469 for ; Fri, 23 Mar 2001 09:46:15 -0800 (PST) Received: from leningrad (gate.webfountain.com [63.161.54.3]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id JAA14811; Fri, 23 Mar 2001 09:45:30 -0800 X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad From: "Mike Luby" To: "Pieter Liefooghe" , "Jared Mauch" Cc: "Kevin C. Almeroth" , , , Subject: RE: Auto-tunnel Rant Date: Fri, 23 Mar 2001 09:50:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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.2919.6600 Importance: Normal In-reply-to: <3ABB8899.2AD24A6D@info.vub.ac.be> Content-Transfer-Encoding: 7bit I'm confused by the email that is on these mailing lists. Are we still discussing possible standards, or have we moved on to advertisements for company products? Michael Luby Chief Technical Officer Digital Fountain, Inc. 600 Alabama Street San Francisco, CA 94110 www.digitalfountain.com luby@digitalfountain.com (415) 401-2100 (main) (415) 401-2120 (direct) (415) 401-2199 (fax) -----Original Message----- From: Pieter Liefooghe [mailto:pieter@info.vub.ac.be] Sent: Friday, March 23, 2001 9:32 AM To: Jared Mauch Cc: Kevin C. Almeroth; mbone@ISI.EDU; mboned@network-services.uoregon.edu; ssm-interest@external.cisco.com Subject: Re: Auto-tunnel Rant Jared Mauch wrote: > On Fri, Mar 23, 2001 at 07:32:48AM -0800, Kevin C. Almeroth wrote: > > Well, I'll add my voice to the rest of the noise. As I see it, > > auto-tunneling is fine. Why? > > > > 1. Let's not get in the business of protecting people from > > themselves (in reference to Dino's comment about large > > fanout is bad... it is, sure, but who cares?) > > Those of us who are customers of router vendors (not > server/software vendors) have concerns about this impacting our > routers should they spend time creating tunnels. large fanout > is bad in this case as to get upgrades to the cpu/power in these > takes 18 months as compared to the server market that gets a faster > cpu every few months and it is easier to add extra machines when it's > needed. That is the idea behind the CastGate proposal, it even allows to distribute the tunnel end-points over your network....the CastGate client will use - if allowed by your policy - the Tunnel server reacheable via the least congested path! I don't need routers in the proposal, I use PC's who are really cheap as compared to even basic routers. ;-) > > 2. Let people run whatever they want in their own cloud. > > To force people to only do network-layer multicast is > > wrong because: > > > > (a) You should be able to do whatever you want (See 1.) > > > > (b) We are in a transition period and not every > > single device supports multicast. Until every > > single device can handle multicast we need things > > like tunneling (any maybe auto-). Why? See 3. > > > > 3. An infrastructure that has devices that don't support > > multicast and so no way for the eyeballs on the other > > end to see the content is ultimately defeating for > > multicast. Yes we can be multicast advocates, but saying > > that someone can't play in our sandbox because they > > haven't bought the latest equipment from Vendor X hurts > > us more than it hurts the rest of the world. > > > > In the end: who cares if there is tunneling? or even > > I don't care about tunneling, unless the burden gets > palced on my routers. As mentioned above, CastGate Tunnel Servers (and Tunnel Database Servers) are just PC's located in strategic locations in your network. > > > > auto-tunneling? Who cares if people expend effort deploying > > non-network-layer multicast? If they weren't smart enough in > > the first place they probably wouldn't have been smart enough > > to deploy multicast anyway. > > > > NOW... the real question is should the IETF be standardizing > > a way to do this? My intuition... NO. Let some clever vendor > > sell a piece of hardware or software that makes it mostly > > seemless. I guess, I will just finish building all my components and let it loose..(give me another month or so)...we will see what happens ;-) Bye, Pieter From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Mar 23 14:31:47 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01657 for ; Fri, 23 Mar 2001 14:31:47 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA23272 for ; Fri, 23 Mar 2001 09:58:33 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2NHwTa09561 for ; Fri, 23 Mar 2001 09:58:29 -0800 (PST) Received: from guppy.vub.ac.be (guppy.vub.ac.be [134.184.129.2]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2NHwMi00095 for ; Fri, 23 Mar 2001 09:58:23 -0800 (PST) Received: from info1.vub.ac.be (info1.vub.ac.be [134.184.1.1]) by guppy.vub.ac.be (8.9.1b+Sun/3.17.1.ap (guppy)) id SAA05615; Fri, 23 Mar 2001 18:56:02 +0100 (MET) for Received: from info.vub.ac.be by info1.vub.ac.be (SMI-8.6/SMI-SVR4-INFO-HUB-110196) id SAA17656; Fri, 23 Mar 2001 18:58:38 +0100 Message-ID: <3ABB8E17.A85164A@info.vub.ac.be> Date: Fri, 23 Mar 2001 18:55:35 +0100 From: Pieter Liefooghe X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mike Luby CC: Jared Mauch , "Kevin C. Almeroth" , mbone@ISI.EDU, mboned@network-services.uoregon.edu, ssm-interest@external.cisco.com Subject: Re: Auto-tunnel Rant References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mike Luby wrote: > I'm confused by the email that is on these mailing lists. Are we still > discussing possible standards, or have we moved on to advertisements for > company products? I'm just selling my Idea...something wrong with this? BTW I belong to a research group of a University...not a company and do not intend to make any money with this. Bye, Pieter > > > Michael Luby > Chief Technical Officer > Digital Fountain, Inc. > 600 Alabama Street > San Francisco, CA 94110 > > www.digitalfountain.com > luby@digitalfountain.com > (415) 401-2100 (main) > (415) 401-2120 (direct) > (415) 401-2199 (fax) > > -----Original Message----- > From: Pieter Liefooghe [mailto:pieter@info.vub.ac.be] > Sent: Friday, March 23, 2001 9:32 AM > To: Jared Mauch > Cc: Kevin C. Almeroth; mbone@ISI.EDU; > mboned@network-services.uoregon.edu; ssm-interest@external.cisco.com > Subject: Re: Auto-tunnel Rant > > Jared Mauch wrote: > > > On Fri, Mar 23, 2001 at 07:32:48AM -0800, Kevin C. Almeroth wrote: > > > Well, I'll add my voice to the rest of the noise. As I see it, > > > auto-tunneling is fine. Why? > > > > > > 1. Let's not get in the business of protecting people from > > > themselves (in reference to Dino's comment about large > > > fanout is bad... it is, sure, but who cares?) > > > > Those of us who are customers of router vendors (not > > server/software vendors) have concerns about this impacting our > > routers should they spend time creating tunnels. large fanout > > is bad in this case as to get upgrades to the cpu/power in these > > takes 18 months as compared to the server market that gets a faster > > cpu every few months and it is easier to add extra machines when it's > > needed. > > That is the idea behind the CastGate proposal, it even allows to distribute > the > tunnel end-points over your network....the CastGate client will use - if > allowed by your policy - the Tunnel server reacheable via the least > congested > path! > I don't need routers in the proposal, I use PC's who are really cheap as > compared to even basic routers. ;-) > > > > 2. Let people run whatever they want in their own cloud. > > > To force people to only do network-layer multicast is > > > wrong because: > > > > > > (a) You should be able to do whatever you want (See 1.) > > > > > > (b) We are in a transition period and not every > > > single device supports multicast. Until every > > > single device can handle multicast we need things > > > like tunneling (any maybe auto-). Why? See 3. > > > > > > 3. An infrastructure that has devices that don't support > > > multicast and so no way for the eyeballs on the other > > > end to see the content is ultimately defeating for > > > multicast. Yes we can be multicast advocates, but saying > > > that someone can't play in our sandbox because they > > > haven't bought the latest equipment from Vendor X hurts > > > us more than it hurts the rest of the world. > > > > > > In the end: who cares if there is tunneling? or even > > > > I don't care about tunneling, unless the burden gets > > palced on my routers. > > As mentioned above, CastGate Tunnel Servers (and Tunnel Database Servers) > are > just PC's located in strategic locations in your network. > > > > > > > > auto-tunneling? Who cares if people expend effort deploying > > > non-network-layer multicast? If they weren't smart enough in > > > the first place they probably wouldn't have been smart enough > > > to deploy multicast anyway. > > > > > > NOW... the real question is should the IETF be standardizing > > > a way to do this? My intuition... NO. Let some clever vendor > > > sell a piece of hardware or software that makes it mostly > > > seemless. > > I guess, I will just finish building all my components and let it > loose..(give > me another month or so)...we will see what happens ;-) > > Bye, > > Pieter From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Sat Mar 24 10:01:38 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03932 for ; Sat, 24 Mar 2001 10:01:37 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA27151 for ; Sat, 24 Mar 2001 06:03:54 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2OE3Wu20172 for ; Sat, 24 Mar 2001 06:03:32 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2OE3Qi02381 for ; Sat, 24 Mar 2001 06:03:27 -0800 (PST) Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Sat, 24 Mar 2001 07:46:21 -0600 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 24 Mar 2001 05:46:09 -0800 Message-ID: <5D630265EF50D311ABB60008C7917DB604593F61@zsc4c004.us.nortel.com> From: "Sundeep Singatwaria" To: "'Dino Farinacci'" , ggm@dstc.edu.au Cc: finlayson@live.com, jared@puck.nether.net, ssm-interest@external.cisco.com, mbone@ISI.EDU, mboned@network-services.uoregon.edu Subject: RE: Auto-tunnel Rant Date: Sat, 24 Mar 2001 05:46:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B468.C7441460" 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_01C0B468.C7441460 Content-Type: text/plain; charset="iso-8859-1" Dino, -----Original Message----- From: Dino Farinacci [mailto:dino@procket.com] Sent: Thursday, March 22, 2001 11:10 PM To: ggm@dstc.edu.au Cc: finlayson@live.com; jared@puck.nether.net; ssm-interest@external.cisco.com; mbone@ISI.EDU; mboned@network-services.uoregon.edu Subject: Re: Auto-tunnel Rant >> There is probably a layering violation opr encapsulated traffic fubar >> but I do want to ask, why its not possible for a multicast enabled >> upstream to intercept a tunnel, and just *make* the endpoint terminate there >> which should (in a global multicast) do the right thing anyway. Because the number of tunnels cannot be bounded. Even if you configure who is allowed to connect to you, as Radia indicated in her talk, you still have to configure something, so it may as well be a list of tunnels. I was arguing for static versus dynamic tunnels at MBONED. It is extremely dangerous to abuse a router with unknown fanout. As I indicated in MBONED, memory sizes, switching capacity, buffer memory k capacity are all based on the speeds and feeds the router is designed for. When replication is based on the physical interfaces, you can engineer a box that actually does wire-speed multicast. Once you add tunnels (unbounded or an unknown number) to the equation, you lose throughput in a big way. I also mentioned a very simple solution: o PCs (windows) can already do multicast over their dial-up adaptors. o Therefore IGMP messages can go to the dialed-up NAS device at the ISP. o If you configure the NAS device to GRE tunnel to existing Juniper or cisco boxes which reside in the multicast-capable cloud, you're done. Upstream you can send IGMP request to the multicast enabled router. How about a case in which the multicast enabled router is multiple hops away from the NAS device and the routers in between do not support multicast. How is the traffic going to flow downstream without creation of tunnels. Am I missing something here ? I think the folks who allow tunnels to be created would be well aware that their routers wouldn't be able to give wire speed performance. Problem solved. This is a lot different than asking a tier 2 or tier 3 ISP to run native multicast. Of course, that is what we should encourage them to do but the whole idea of doing tunnels at the edge of the network is to nudge these access ISPs to see the light of multicast. So we have to proceed one slow step at a time unfortunately. The NAS boxes don't even have to do full multicast routing. Simply forward IGMP reports received on an async line over the tunnel to the multicast configured router in the backbone. Doing this gets you 1-to-many source-tree based unbiqituous multicast. AOL, Earthlink, and UUnet, are you listening? Dino ------_=_NextPart_001_01C0B468.C7441460 Content-Type: text/html; charset="iso-8859-1" RE: Auto-tunnel Rant

Dino,

-----Original Message-----
From: Dino Farinacci [mailto:dino@procket.com]
Sent: Thursday, March 22, 2001 11:10 PM
To: ggm@dstc.edu.au
Cc: finlayson@live.com; jared@puck.nether.net;
ssm-interest@external.cisco.com; mbone@ISI.EDU;
mboned@network-services.uoregon.edu
Subject: Re: Auto-tunnel Rant


>> There is probably a layering violation opr encapsulated traffic fubar
>> but I do want to ask, why its not possible for a multicast enabled
>> upstream to intercept a tunnel, and just *make* the endpoint terminate there
>> which should (in a global multicast) do the right thing anyway.

    Because the number of tunnels cannot be bounded. Even if you configure
    who is allowed to connect to you, as Radia indicated in her talk, you
    still have to configure something, so it may as well be a list of tunnels.

    I was arguing for static versus dynamic tunnels at MBONED.
   
    It is extremely dangerous to abuse a router with unknown fanout. As I
    indicated in MBONED, memory sizes, switching capacity, buffer memory k
    capacity are all based on the speeds and feeds the router is designed for.
    When replication is based on the physical interfaces, you can engineer a
    box that actually does wire-speed multicast. Once you add tunnels
    (unbounded or an unknown number) to the equation, you lose throughput in
    a big way.

    I also mentioned a very simple solution:

    o PCs (windows) can already do multicast over their dial-up adaptors.
    o Therefore IGMP messages can go to the dialed-up NAS device at the ISP.
    o If you configure the NAS device to GRE tunnel to existing Juniper or
      cisco boxes which reside in the multicast-capable cloud, you're done.

Upstream you can send IGMP request to the multicast enabled router. How about
a case in which the multicast enabled router is multiple hops away from the
NAS device and the routers in between do not support multicast. How is the traffic
going to flow downstream without creation of tunnels. Am I missing something here ?

I think the folks who allow tunnels to be created would be well aware that their
routers wouldn't be able to give wire speed performance.

    Problem solved.

    This is a lot different than asking a tier 2 or tier 3 ISP to run native
    multicast. Of course, that is what we should encourage them to do but
    the whole idea of doing tunnels at the edge of the network is to nudge
    these access ISPs to see the light of multicast. So we have to proceed
    one slow step at a time unfortunately.

    The NAS boxes don't even have to do full multicast routing. Simply forward
    IGMP reports received on an async line over the tunnel to the multicast
    configured router in the backbone.

    Doing this gets you 1-to-many source-tree based unbiqituous multicast.

    AOL, Earthlink, and UUnet, are you listening?

Dino

------_=_NextPart_001_01C0B468.C7441460-- From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Sun Mar 25 04:27:51 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09013 for ; Sun, 25 Mar 2001 04:27:50 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id AAA23198 for ; Sun, 25 Mar 2001 00:09:18 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2P89FC14478 for ; Sun, 25 Mar 2001 00:09:15 -0800 (PST) Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2P89J220962 for ; Sun, 25 Mar 2001 00:09:19 -0800 (PST) Received: from localhost (cs2773-200.houston.rr.com [24.27.73.200]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2P81Bei013083 for ; Sun, 25 Mar 2001 02:04:16 -0600 Message-Id: <200103250804.f2P81Bei013083@sm10.texas.rr.com> X-Sender: hermag@excite.com From: "hermag@excite.com" To: ssm-interest@external.cisco.com Date: Sun, 25 Mar 2001 02:58:00 -0600 Subject: Would you like to recieve information on how to register your pet online for free? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__18614451_7258.95" This is a Multipart MIME message. ------=_NextPart_000_001__18614451_7258.95 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__18614451_7258.95 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4 dD0iIzAwMDAwMCI+DQo8cD5IZWxsbyE8L3A+DQo8cD5Xb3VsZCB5b3UgbGlrZSB0byBrbm93 IGhvdyB0byByZWdpc3RlciB5b3VyIHBldCBvbmxpbmUgZm9yIGZyZWU/PC9wPg0KPHA+SWYg eW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGV2ZXIgcmVjZWl2aW5nIGFub3Ro ZXIgZW1haWwgcGxlYXNlIHR5cGUgDQogIFJFTU9WRSBvbmx5IGluIHRoZSByZXR1cm4gc3Vi amVjdCBoZWFkZXIuIFdlIHJlc3BlY3QgeW91ciByaWdodCB0byBwcml2YWN5LjwvcD4NCjxw PklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cg dG8gcmVnaXN0ZXIgeW91ciBwZXQgZm9yIA0KICBmcmVlIGp1c3QgcmVwbHkgdG8gdGhpcyBl bWFpbCBtZXNzYWdlIHdpdGggUExFQVNFIFNFTkQgSU5GTyBvbmx5IGluIHRoZSBzdWJqZWN0 IA0KICBoZWFkZXIuPC9wPg0KPHA+PC9wPg0KPHA+VGhhbmsgWW91PGJyPg0KPC9wPg0KPC9i b2R5Pg0KPC9odG1sPg0K ------=_NextPart_000_001__18614451_7258.95-- From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Sun Mar 25 15:41:28 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10661 for ; Sun, 25 Mar 2001 15:41:27 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA15851 for ; Sun, 25 Mar 2001 11:27:41 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2PJRbq06982 for ; Sun, 25 Mar 2001 11:27:37 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2PJRVi05613 for ; Sun, 25 Mar 2001 11:27:31 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 67E2C4CEB1; Sun, 25 Mar 2001 14:23:04 -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 OAA27078; Sun, 25 Mar 2001 14:23:02 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA00500; Sun, 25 Mar 2001 13:23:02 -0600 (CST) Message-Id: <200103251923.NAA00500@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: nagesh.chintada@alcatel.com Subject: Re: Why MSDP? Cc: ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu References: <200103222325.RAA13581@windsor.research.att.com> <3ABB6820.12ECDD15@alcatel.com> Date: Sun, 25 Mar 2001 13:23:02 -0600 Versions: dmail (solaris) 2.2g/makemail 2.9a >Isn't it true that MBGP alread is used to announce multicast routes to >these sources? Yes, but these announcements don't change when the sources start or stop sending traffic. >I think there are lots of advantages to using MBGP... can someone explain >what I may be missing here? You are missing the timescale argument that I wrote in my first reply. Bill From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Mon Mar 26 19:42:05 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22739 for ; Mon, 26 Mar 2001 19:42:05 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA27693 for ; Mon, 26 Mar 2001 15:39:39 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2QNdaV12771 for ; Mon, 26 Mar 2001 15:39:36 -0800 (PST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2QNdSi11568 for ; Mon, 26 Mar 2001 15:39:28 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 26 Mar 2001 15:38:24 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Mar 2001 15:38:34 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 26 Mar 2001 15:38:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4673.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Auto-tunnel Rant Date: Mon, 26 Mar 2001 15:38:33 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657405266EA3@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: Auto-tunnel Rant Thread-Index: AcCzxDRuBrtRXUGmR3CXNqIVJ1vsyQCiNgPA From: "Dave Thaler" To: "Pieter Liefooghe" , "Jared Mauch" Cc: "Kevin C. Almeroth" , , , X-OriginalArrivalTime: 26 Mar 2001 23:38:34.0632 (UTC) FILETIME=[DF96E880:01C0B64D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA22739 > > On Fri, Mar 23, 2001 at 07:32:48AM -0800, Kevin C. Almeroth wrote: > > > Well, I'll add my voice to the rest of the noise. As I see it, > > > auto-tunneling is fine. Why? > > > > > > 1. Let's not get in the business of protecting people from > > > themselves (in reference to Dino's comment about large > > > fanout is bad... it is, sure, but who cares?) > > > > Those of us who are customers of router vendors (not > > server/software vendors) have concerns about this impacting our > > routers should they spend time creating tunnels. large fanout > > is bad in this case as to get upgrades to the cpu/power in these > > takes 18 months as compared to the server market that gets a faster > > cpu every few months and it is easier to add extra machines > when it's > > needed. > > That is the idea behind the CastGate proposal, it even allows > to distribute the > tunnel end-points over your network....the CastGate client > will use - if > allowed by your policy - the Tunnel server reacheable via > the least congested > path! > I don't need routers in the proposal, I use PC's who are > really cheap as > compared to even basic routers. ;-) Actually I think that PCs would do for any of the auto-tunnel proposals. None of them (to my knowledge) from this IETF assumed that replication would be done by a normal router. Rather, my understanding is that they all assume a tunnel endpoint server, where that server could be a PC or could be a special-purpose router box that is decided for this purpose. -Dave From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Tue Mar 27 03:44:01 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15351 for ; Tue, 27 Mar 2001 03:44:00 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id XAA17721 for ; Mon, 26 Mar 2001 23:39:01 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2R7cwL07578 for ; Mon, 26 Mar 2001 23:38:58 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2R7Z6i04249 for ; Mon, 26 Mar 2001 23:35:07 -0800 (PST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f2R7HOl09200; Tue, 27 Mar 2001 09:17:24 +0200 (MET DST) 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 C1256A1C.00280568; Tue, 27 Mar 2001 09:17:08 +0200 Message-ID: <3AC03E72.64C41448@alcatel.be> Date: Tue, 27 Mar 2001 09:17:06 +0200 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: Pieter Liefooghe , Jared Mauch , "Kevin C. Almeroth" , mbone@ISI.EDU, mboned@network-services.uoregon.edu, ssm-interest@external.cisco.com Subject: Re: Auto-tunnel Rant References: <5B90AD65A9E8934987DB0C8C0762657405266EA3@DF-BOWWOW.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > > That is the idea behind the CastGate proposal, it even allows > > to distribute the > > tunnel end-points over your network....the CastGate client > > will use - if > > allowed by your policy - the Tunnel server reacheable via > > the least congested > > path! > > I don't need routers in the proposal, I use PC's who are > > really cheap as > > compared to even basic routers. ;-) > > Actually I think that PCs would do for any of the auto-tunnel > proposals. None of them (to my knowledge) from this IETF assumed > that replication would be done by a normal router. Rather, > my understanding is that they all assume a tunnel endpoint server, > where that server could be a PC or could be a special-purpose router > box that is decided for this purpose. That was also my understanding: the relay box is just a workstation or PC one adds to the multicast topology (this functionality shouldn't be included by high-end routers). If it is able to feed a few hundred tunneled streams it can put some pressure on the downstream unicast-only providers, and hopefully they will at last enable native multicast. The dial-in solution of Dino will also work, but than one still needs the co-operation of the ISP that doesn't want to co-operate in deploying multicast in the first place. Also since for auto-tunneling hosts and boxes in the network have to talk to eachother I believe it is a subject for standardization (opposed to what Kevin said). cheers, dirk > > -Dave -- Dirk Ooms mailto:dirk.ooms@alcatel.be tel:+32 3 2404732 Network Strategy Group (NSG) http://aww.alcatel.com/nsg Alcatel http://www.alcatel.com From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Tue Mar 27 12:43:40 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24065 for ; Tue, 27 Mar 2001 12:43:39 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA29172 for ; Tue, 27 Mar 2001 08:23:04 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2RGMxb25528 for ; Tue, 27 Mar 2001 08:22:59 -0800 (PST) Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.cabletron.com [12.25.1.120]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f2RGN4p16971 for ; Tue, 27 Mar 2001 08:23:04 -0800 (PST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id LAA08144 for ; Tue, 27 Mar 2001 11:15:54 -0500 (EST) Received: from cnc-exc2.ctron.com(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma008073; Tue, 27 Mar 01 11:15:38 -0500 Received: by cnc-exc2.ctron.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Mar 2001 11:09:11 -0500 Message-ID: From: "Humphries, Kevin" To: "'ssm-interest@external.cisco.com'" Date: Tue, 27 Mar 2001 11:09:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B6D8.42918C80" 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_01C0B6D8.42918C80 Content-Type: text/plain; charset="iso-8859-1" subscribe khumphri@enterasys.com end ===<>===<>===<>===<>===<>===<>===<>===<>=== Kevin Humphries Firmware Engineer SLC Engineering 801.887.9811 Email: khumphri@enterasys.com Web: http://www.enterasys.com/ ------_=_NextPart_001_01C0B6D8.42918C80 Content-Type: text/html; charset="iso-8859-1"

subscribe khumphri@enterasys.com
end

===<>===<>===<>===<>===<>===<>===<>===<>===
Kevin Humphries
Firmware Engineer
SLC Engineering
801.887.9811
Email: khumphri@enterasys.com
Web: http://www.enterasys.com/

------_=_NextPart_001_01C0B6D8.42918C80-- From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Tue Mar 27 12:57:23 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24416 for ; Tue, 27 Mar 2001 12:57:22 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA03520 for ; Tue, 27 Mar 2001 08:30:25 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2RGULM02482 for ; Tue, 27 Mar 2001 08:30:21 -0800 (PST) Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.cabletron.com [12.25.1.120]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2RGPw801323 for ; Tue, 27 Mar 2001 08:25:58 -0800 (PST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id LAA08633 for ; Tue, 27 Mar 2001 11:19:32 -0500 (EST) Received: from cnc-exc2.ctron.com(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma008529; Tue, 27 Mar 01 11:19:18 -0500 Received: by cnc-exc2.ctron.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Mar 2001 11:12:52 -0500 Message-ID: From: "Humphries, Kevin" To: "'ssm-interest@external.cisco.com'" Subject: Sorry . . . Date: Tue, 27 Mar 2001 11:12:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B6D8.C627B5BA" 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_01C0B6D8.C627B5BA Content-Type: text/plain; charset="iso-8859-1" I apologize for the misdirected mail message. I grabed the wrong email address. Kevin > -----Original Message----- > From: Humphries, Kevin > Sent: Tuesday, March 27, 2001 9:09 AM > To: 'ssm-interest@external.cisco.com' > Subject: > > > subscribe khumphri@enterasys.com > end > > ===<>===<>===<>===<>===<>===<>===<>===<>=== > Kevin Humphries > Firmware Engineer > SLC Engineering > 801.887.9811 > Email: khumphri@enterasys.com > Web: http://www.enterasys.com/ > ------_=_NextPart_001_01C0B6D8.C627B5BA Content-Type: text/html; charset="iso-8859-1" Sorry . . .

I apologize for the misdirected mail message.  I grabed the wrong email address.

Kevin

> -----Original Message-----
> From: Humphries, Kevin
> Sent: Tuesday, March 27, 2001 9:09 AM
> To: 'ssm-interest@external.cisco.com'
> Subject:
>
>
> subscribe khumphri@enterasys.com
> end
>
> ===<>===<>===<>===<>===<>===<>===<>===<>===
> Kevin Humphries
> Firmware Engineer
> SLC Engineering
> 801.887.9811
> Email: khumphri@enterasys.com
> Web: http://www.enterasys.com/
>

------_=_NextPart_001_01C0B6D8.C627B5BA-- From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Tue Mar 27 15:12:10 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28220 for ; Tue, 27 Mar 2001 15:12:10 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id KAA22948 for ; Tue, 27 Mar 2001 10:50:27 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2RIpiY25550 for ; Tue, 27 Mar 2001 10:51:44 -0800 (PST) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f2RIpai14965 for ; Tue, 27 Mar 2001 10:51:37 -0800 (PST) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id UAA13735; Tue, 27 Mar 2001 20:38:21 +0200 (MET DST) Message-ID: <3AC0DE28.9A30D6B8@irisa.fr> Date: Tue, 27 Mar 2001 20:38:32 +0200 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: Bill Fenner CC: nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu Subject: Re: Why MSDP? References: <200103222325.RAA13581@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, > One reason: the timescales for change of active source indications are > much different than BGP was designed to carry. BGP wants to carry > data that doesn't change very often, e.g. see route dampening. Sources > can come and go at an arbitrary rate, so the rate of change of the > information is potentially much higher. I think that the main problem is that we are using multiple RPs instead of one RP (RP for each domain) and that is why we are needing the MSDP. Isnt true ?? PS : we are using multiple RPs to avoid administrative dependencies between domains. Ali From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Mar 30 10:43:28 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21572 for ; Fri, 30 Mar 2001 10:43:28 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id GAA13927 for ; Fri, 30 Mar 2001 06:26:25 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f2UEQNF17617 for ; Fri, 30 Mar 2001 06:26:23 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy2.cisco.com (8.11.2/8.11.2) with SMTP id f2UEPeW07447 for ; Fri, 30 Mar 2001 06:25:41 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 30 Mar 2001 15:21:16 +0100 To: ssm-interest@external.cisco.com, pim@catarina.usc.edu Subject: has anyone done PIM SM/SSM v2 in NS2? Date: Fri, 30 Mar 2001 15:21:16 +0100 Message-ID: <10258.985962076@cs.ucl.ac.uk> From: Jon Crowcroft we're interested to know if anyone has pim sm/ssm as of latest specs in ns2 (or is working on it!).... cheers jon From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Mar 30 12:29:11 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27407 for ; Fri, 30 Mar 2001 12:29:10 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA18258 for ; Fri, 30 Mar 2001 08:28:04 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f2UGRxL06643 for ; Fri, 30 Mar 2001 08:27:59 -0800 (PST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f2UGNXW28657 for ; Fri, 30 Mar 2001 08:23:33 -0800 (PST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14j1SX-0001qu-00; Fri, 30 Mar 2001 17:09:09 +0100 Date: Fri, 30 Mar 2001 17:09:08 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Jon Crowcroft cc: ssm-interest@external.cisco.com, pim@catarina.usc.edu, ns-users mailing list Subject: Re: has anyone done PIM SM/SSM v2 in NS2? In-Reply-To: <10258.985962076@cs.ucl.ac.uk> 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 *14j1SX-0001qu-00*XjX1xUIiDaA* [widening to include ns-users.] On Fri, 30 Mar 2001, Jon Crowcroft wrote: > Date: Fri, 30 Mar 2001 15:21:16 +0100 > From: Jon Crowcroft > To: ssm-interest@external.cisco.com, pim@catarina.usc.edu > Subject: has anyone done PIM SM/SSM v2 in NS2? > > > we're interested to know if anyone has pim sm/ssm as of latest specs > in ns2 (or is working on it!).... Updating: http://www.isi.edu/cgi-bin/nsnam/cvsweb/ns-2/tcl/pim/Attic/ to better match PIM-SM (as was, never mind now) and changes in ns multicast internals strikes me as a large task... L. PGP