From routing-discussion-admin@ietf.org Mon Mar 1 02:04:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13667 for ; Mon, 1 Mar 2004 02:04:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhT7-0008DZ-T7; Mon, 01 Mar 2004 02:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIsW-0001l1-7A for routing-discussion@optimus.ietf.org; Thu, 26 Feb 2004 05:36:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03126 for ; Thu, 26 Feb 2004 05:36:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIsS-0004gl-00 for routing-discussion@ietf.org; Thu, 26 Feb 2004 05:36:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwIra-0004bt-00 for routing-discussion@ietf.org; Thu, 26 Feb 2004 05:35:30 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1AwIqg-0004XA-00; Thu, 26 Feb 2004 05:34:34 -0500 Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 26 Feb 2004 11:34:32 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : RE : WG Review: Routing Area Working Group (rtgwg) Date: Thu, 26 Feb 2004 11:34:32 +0100 Message-ID: <57F140DC5CDA10438C41674629DE0D8701904500@parmhs4.rd.francetelecom.fr> Thread-Topic: RE : WG Review: Routing Area Working Group (rtgwg) Thread-Index: AcP7KaXYGKn37HGyRIS5WsXINEqZHgBJp1VA From: "PROUST Christophe FTRD/DMI/CAE" To: Cc: , "Alex Zinin" X-OriginalArrivalTime: 26 Feb 2004 10:34:33.0001 (UTC) FILETIME=[1F5AE990:01C3FC54] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all contributors, I recently made a proposal at the IETF that aims at load balancing=20 flows among available network resources. It relies both=20 on a new forwarding paradigm and a new routing capability.=20 The Internet-Draft is available at the following location : =09 http://www.ietf.org/internet-drafts/draft-proust-flow-routing-00.txt Please, feel free to comment in any way you consider helpful,=20 I would be thankful, =09 Yours sincerly, =20 Christophe Proust France Telecom R&D 42 rue des Coutures 14000 - Caen - France +33 2 31 75 93 08 christophe.proust@francetelecom.com _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 1 02:04:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13664 for ; Mon, 1 Mar 2004 02:04:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhTB-0008EO-0H; Mon, 01 Mar 2004 02:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxL4I-0007mW-PE for routing-discussion@optimus.ietf.org; Sun, 29 Feb 2004 02:08:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06001 for ; Sun, 29 Feb 2004 02:08:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxL4F-0006PY-00 for routing-discussion@ietf.org; Sun, 29 Feb 2004 02:08:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxL3E-0006Jh-00 for routing-discussion@ietf.org; Sun, 29 Feb 2004 02:07:48 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxL2w-0006ET-00; Sun, 29 Feb 2004 02:07:31 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id F2E6D2D4935; Sun, 29 Feb 2004 02:07:01 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01346-05-7; Sun, 29 Feb 2004 02:07:01 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CD0312D482A; Sun, 29 Feb 2004 02:06:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Date: Sun, 29 Feb 2004 02:06:59 -0500 Message-ID: Thread-Topic: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Thread-Index: AcP+g7am4ahwRSX7SrCpT9w2tOLLOwABzoFg From: "Susan Hares" To: "Alex Zinin" , "John Leslie" Cc: "Eric Rosen" , , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Alex: My suggestion just gives a practical means to assign the AFI/SAFI. I think it fits within your concept.=20 Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Sunday, February 29, 2004 12:17 AM To: John Leslie Cc: Eric Rosen; routing-discussion@ietf.org; rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt John, > As I think about this, we perhaps need the equivalent of the = RFC1918 > free-for-all zones: particular codes which may be used for = interoperability > testing, but are subject to other incompatible uses. Experimental allocation policy should cover this. See RFC 3692. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 1 02:04:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13688 for ; Mon, 1 Mar 2004 02:04:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhT9-0008Dt-06; Mon, 01 Mar 2004 02:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRLP-0004UE-33 for routing-discussion@optimus.ietf.org; Thu, 26 Feb 2004 14:38:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAB04722 for ; Thu, 26 Feb 2004 14:38:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRLM-0003ir-00 for routing-discussion@ietf.org; Thu, 26 Feb 2004 14:38:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRKS-0003dW-00 for routing-discussion@ietf.org; Thu, 26 Feb 2004 14:37:52 -0500 Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx with esmtp (Exim 4.12) id 1AwRJr-0003Ss-00; Thu, 26 Feb 2004 14:37:15 -0500 Received: from lb-laptop.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 60E0FAE88; Thu, 26 Feb 2004 14:36:36 -0500 (EST) Message-Id: <6.0.3.0.2.20040226143327.03467ea8@mail.labn.net> X-Sender: lberger@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 26 Feb 2004 14:36:35 -0500 To: Kireeti Kompella From: Lou Berger Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Cc: Mukesh.Gupta@nokia.com, zinin@psg.com, routing-discussion@ietf.org, rtg-dir@ietf.org In-Reply-To: <20040226081555.S11637@kummer.juniper.net> References: <8D260779A766FB4A9C1739A476F84FA401F799BA@daebe009.americas.nokia.com> <20040226081555.S11637@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , How about linking assignment expiration to expiration of the draft, 3 months after? If the draft makes it to RFC, no issue, if the draft takes a long time through the editors queue (which can take ~1.5 years!), no issue, if the draft keeps changing, no issue. If the draft dies, so does the assignment. Lou At 11:24 AM 2/26/2004, Kireeti Kompella wrote: >On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: > > > I finally got a chance to read the draft. The idea is good. I just > > have a couple of questions/concerns about the expiry of the early > > allocations.. > > > > - Do you think that "at most one renewal" would work in practice ? > > There might be instances where there is a genuine need to keep > > the early allocations for more than a year (Consider VRRPv3). > > How do we deal with that situation ? If it is not possible to > > renew the allocations more than once, do we need to ask for > > early allocations with new numbers (which ofcourse will make > > the situation worse) or we should just ask/let IANA to delete > > and reassign those numbers (which would create problems as well). > >We mulled a bit over how many times the allocations should be renewed. >The idea is that early allocation should NOT be requested as sson as >an ID is written :-) One renewal may be a bit too aggressive, but >it gives two years. Perhaps two renewals is okay, but no more (imho). > > > - The draft seems to put the responsibility of changing the status > > of the early allocations on the WG chairs ? I know that our chairs > > are very very responsible but I think, it will be a good idea to > > have an alternate mechanism in place such that the early allocations > > are marked deprecated/deleted automatically after a timeout. > >Automatic expiry was actually in the first version, but not everyone >felt comfortable with that. We can (and should) review this, and >perhaps make clearer what expiry means. > >Note that NOT adding to either IANA's or the IESG's workload is an >explicit goal. Whatever we can do to avoid adding to WG chairs' >workload is a 'nice-to-have' :-) > >Kireeti. >------- > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Mar 1 02:04:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13748 for ; Mon, 1 Mar 2004 02:04:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhTS-0008QM-6t for routing-discussion-archive@odin.ietf.org; Mon, 01 Mar 2004 02:04:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2174LVZ032053 for routing-discussion-archive@odin.ietf.org; Mon, 1 Mar 2004 02:04:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhT9-0008E9-NU; Mon, 01 Mar 2004 02:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax6uu-0002Pk-31 for routing-discussion@optimus.ietf.org; Sat, 28 Feb 2004 11:02:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23083 for ; Sat, 28 Feb 2004 11:02:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax6ur-0007St-00 for routing-discussion@ietf.org; Sat, 28 Feb 2004 11:02:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax6tw-0007Nx-00 for routing-discussion@ietf.org; Sat, 28 Feb 2004 11:01:16 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Ax6tX-0007Ig-00 for routing-discussion@ietf.org; Sat, 28 Feb 2004 11:00:51 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 396C82D491D for ; Sat, 28 Feb 2004 11:00:21 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 88819-02-6 for ; Sat, 28 Feb 2004 11:00:21 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 871882D4916 for ; Sat, 28 Feb 2004 11:00:19 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RTG Area meeting in Seoul Date: Sat, 28 Feb 2004 11:00:19 -0500 Message-ID: Thread-Topic: RTG Area meeting in Seoul Thread-Index: AcPyZTISWscKXWyoSzaMl1jITawENADpoSig From: "Susan Hares" To: "Alex Zinin" , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Alex: Should we add my document on afi/safi assignment to the list? Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Friday, February 13, 2004 2:08 PM To: routing-discussion@ietf.org Subject: RTG Area meeting in Seoul Folks- We're going to have an open area meeting in Seoul on Monday evening. At this point we have two drafts to discuss: =20 draft-atlas-ip-local-protect-00.txt draft-kompella-zinin-early-allocation-00.txt Please send me your requests if you want a slot on the agenda. We will also need a scribe. If you're good at minutes-taking and will be attending the session, please consider volunteering. Thanks. =20 --=20 Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Mar 1 02:04:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13749 for ; Mon, 1 Mar 2004 02:04:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhTS-0008QL-6n for routing-discussion-archive@odin.ietf.org; Mon, 01 Mar 2004 02:04:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2174LUl032048 for routing-discussion-archive@odin.ietf.org; Mon, 1 Mar 2004 02:04:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhT7-0008DZ-T7; Mon, 01 Mar 2004 02:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwIsW-0001l1-7A for routing-discussion@optimus.ietf.org; Thu, 26 Feb 2004 05:36:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03126 for ; Thu, 26 Feb 2004 05:36:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwIsS-0004gl-00 for routing-discussion@ietf.org; Thu, 26 Feb 2004 05:36:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwIra-0004bt-00 for routing-discussion@ietf.org; Thu, 26 Feb 2004 05:35:30 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1AwIqg-0004XA-00; Thu, 26 Feb 2004 05:34:34 -0500 Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 26 Feb 2004 11:34:32 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : RE : WG Review: Routing Area Working Group (rtgwg) Date: Thu, 26 Feb 2004 11:34:32 +0100 Message-ID: <57F140DC5CDA10438C41674629DE0D8701904500@parmhs4.rd.francetelecom.fr> Thread-Topic: RE : WG Review: Routing Area Working Group (rtgwg) Thread-Index: AcP7KaXYGKn37HGyRIS5WsXINEqZHgBJp1VA From: "PROUST Christophe FTRD/DMI/CAE" To: Cc: , "Alex Zinin" X-OriginalArrivalTime: 26 Feb 2004 10:34:33.0001 (UTC) FILETIME=[1F5AE990:01C3FC54] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all contributors, I recently made a proposal at the IETF that aims at load balancing=20 flows among available network resources. It relies both=20 on a new forwarding paradigm and a new routing capability.=20 The Internet-Draft is available at the following location : =09 http://www.ietf.org/internet-drafts/draft-proust-flow-routing-00.txt Please, feel free to comment in any way you consider helpful,=20 I would be thankful, =09 Yours sincerly, =20 Christophe Proust France Telecom R&D 42 rue des Coutures 14000 - Caen - France +33 2 31 75 93 08 christophe.proust@francetelecom.com _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Mar 1 02:04:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13785 for ; Mon, 1 Mar 2004 02:04:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhTS-0008QN-70 for routing-discussion-archive@odin.ietf.org; Mon, 01 Mar 2004 02:04:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2174LP5032050 for routing-discussion-archive@odin.ietf.org; Mon, 1 Mar 2004 02:04:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhTB-0008EO-0H; Mon, 01 Mar 2004 02:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxL4I-0007mW-PE for routing-discussion@optimus.ietf.org; Sun, 29 Feb 2004 02:08:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06001 for ; Sun, 29 Feb 2004 02:08:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxL4F-0006PY-00 for routing-discussion@ietf.org; Sun, 29 Feb 2004 02:08:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxL3E-0006Jh-00 for routing-discussion@ietf.org; Sun, 29 Feb 2004 02:07:48 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxL2w-0006ET-00; Sun, 29 Feb 2004 02:07:31 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id F2E6D2D4935; Sun, 29 Feb 2004 02:07:01 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01346-05-7; Sun, 29 Feb 2004 02:07:01 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CD0312D482A; Sun, 29 Feb 2004 02:06:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Date: Sun, 29 Feb 2004 02:06:59 -0500 Message-ID: Thread-Topic: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Thread-Index: AcP+g7am4ahwRSX7SrCpT9w2tOLLOwABzoFg From: "Susan Hares" To: "Alex Zinin" , "John Leslie" Cc: "Eric Rosen" , , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Alex: My suggestion just gives a practical means to assign the AFI/SAFI. I think it fits within your concept.=20 Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Sunday, February 29, 2004 12:17 AM To: John Leslie Cc: Eric Rosen; routing-discussion@ietf.org; rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt John, > As I think about this, we perhaps need the equivalent of the = RFC1918 > free-for-all zones: particular codes which may be used for = interoperability > testing, but are subject to other incompatible uses. Experimental allocation policy should cover this. See RFC 3692. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 1 02:51:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13684 for ; Mon, 1 Mar 2004 02:04:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhT9-0008E9-NU; Mon, 01 Mar 2004 02:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax6uu-0002Pk-31 for routing-discussion@optimus.ietf.org; Sat, 28 Feb 2004 11:02:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23083 for ; Sat, 28 Feb 2004 11:02:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax6ur-0007St-00 for routing-discussion@ietf.org; Sat, 28 Feb 2004 11:02:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax6tw-0007Nx-00 for routing-discussion@ietf.org; Sat, 28 Feb 2004 11:01:16 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Ax6tX-0007Ig-00 for routing-discussion@ietf.org; Sat, 28 Feb 2004 11:00:51 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 396C82D491D for ; Sat, 28 Feb 2004 11:00:21 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 88819-02-6 for ; Sat, 28 Feb 2004 11:00:21 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 871882D4916 for ; Sat, 28 Feb 2004 11:00:19 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RTG Area meeting in Seoul Date: Sat, 28 Feb 2004 11:00:19 -0500 Message-ID: Thread-Topic: RTG Area meeting in Seoul Thread-Index: AcPyZTISWscKXWyoSzaMl1jITawENADpoSig From: "Susan Hares" To: "Alex Zinin" , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Alex: Should we add my document on afi/safi assignment to the list? Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Friday, February 13, 2004 2:08 PM To: routing-discussion@ietf.org Subject: RTG Area meeting in Seoul Folks- We're going to have an open area meeting in Seoul on Monday evening. At this point we have two drafts to discuss: =20 draft-atlas-ip-local-protect-00.txt draft-kompella-zinin-early-allocation-00.txt Please send me your requests if you want a slot on the agenda. We will also need a scribe. If you're good at minutes-taking and will be attending the session, please consider volunteering. Thanks. =20 --=20 Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Mar 1 02:51:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13750 for ; Mon, 1 Mar 2004 02:04:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhTS-0008QO-76 for routing-discussion-archive@odin.ietf.org; Mon, 01 Mar 2004 02:04:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2174LIG032052 for routing-discussion-archive@odin.ietf.org; Mon, 1 Mar 2004 02:04:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhT9-0008Dt-06; Mon, 01 Mar 2004 02:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRLP-0004UE-33 for routing-discussion@optimus.ietf.org; Thu, 26 Feb 2004 14:38:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAB04722 for ; Thu, 26 Feb 2004 14:38:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRLM-0003ir-00 for routing-discussion@ietf.org; Thu, 26 Feb 2004 14:38:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRKS-0003dW-00 for routing-discussion@ietf.org; Thu, 26 Feb 2004 14:37:52 -0500 Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx with esmtp (Exim 4.12) id 1AwRJr-0003Ss-00; Thu, 26 Feb 2004 14:37:15 -0500 Received: from lb-laptop.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 60E0FAE88; Thu, 26 Feb 2004 14:36:36 -0500 (EST) Message-Id: <6.0.3.0.2.20040226143327.03467ea8@mail.labn.net> X-Sender: lberger@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 26 Feb 2004 14:36:35 -0500 To: Kireeti Kompella From: Lou Berger Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Cc: Mukesh.Gupta@nokia.com, zinin@psg.com, routing-discussion@ietf.org, rtg-dir@ietf.org In-Reply-To: <20040226081555.S11637@kummer.juniper.net> References: <8D260779A766FB4A9C1739A476F84FA401F799BA@daebe009.americas.nokia.com> <20040226081555.S11637@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , How about linking assignment expiration to expiration of the draft, 3 months after? If the draft makes it to RFC, no issue, if the draft takes a long time through the editors queue (which can take ~1.5 years!), no issue, if the draft keeps changing, no issue. If the draft dies, so does the assignment. Lou At 11:24 AM 2/26/2004, Kireeti Kompella wrote: >On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: > > > I finally got a chance to read the draft. The idea is good. I just > > have a couple of questions/concerns about the expiry of the early > > allocations.. > > > > - Do you think that "at most one renewal" would work in practice ? > > There might be instances where there is a genuine need to keep > > the early allocations for more than a year (Consider VRRPv3). > > How do we deal with that situation ? If it is not possible to > > renew the allocations more than once, do we need to ask for > > early allocations with new numbers (which ofcourse will make > > the situation worse) or we should just ask/let IANA to delete > > and reassign those numbers (which would create problems as well). > >We mulled a bit over how many times the allocations should be renewed. >The idea is that early allocation should NOT be requested as sson as >an ID is written :-) One renewal may be a bit too aggressive, but >it gives two years. Perhaps two renewals is okay, but no more (imho). > > > - The draft seems to put the responsibility of changing the status > > of the early allocations on the WG chairs ? I know that our chairs > > are very very responsible but I think, it will be a good idea to > > have an alternate mechanism in place such that the early allocations > > are marked deprecated/deleted automatically after a timeout. > >Automatic expiry was actually in the first version, but not everyone >felt comfortable with that. We can (and should) review this, and >perhaps make clearer what expiry means. > >Note that NOT adding to either IANA's or the IESG's workload is an >explicit goal. Whatever we can do to avoid adding to WG chairs' >workload is a 'nice-to-have' :-) > >Kireeti. >------- > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 1 03:22:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01251 for ; Mon, 1 Mar 2004 03:22:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigf-0006Kt-Cy; Mon, 01 Mar 2004 03:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifq-0006GO-Bt for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 03:21:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01004 for ; Mon, 1 Mar 2004 03:21:13 -0500 (EST) From: kireeti@juniper.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxibF-0004AF-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:16:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiaO-00043l-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:15:36 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxiZc-0003sb-00; Mon, 01 Mar 2004 03:14:48 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i218EIPg027691; Mon, 1 Mar 2004 00:14:18 -0800 (PST) (envelope-from kireeti@kummer.juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) id i218EIIa027690; Mon, 1 Mar 2004 00:14:18 -0800 (PST) Date: Mon, 1 Mar 2004 00:14:18 -0800 (PST) Message-Id: <200403010814.i218EIIa027690@kummer.juniper.net> To: lberger@labn.net, zinin@psg.com Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Cc: kireeti@juniper.net, Mukesh.Gupta@nokia.com, routing-discussion@ietf.org, rtg-dir@ietf.org In-Reply-To: <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , > okay, got found your message. I think this should work for most > cases. I'd suggest adding text that allows for >1 renewal with IESG > approval (in unusual circumstances). Okay, unless I hear strong arguments to the contrary, I will add >1 renewals to the doc. Kireeti. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 1 03:22:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01268 for ; Mon, 1 Mar 2004 03:22:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigl-0006MS-Bp; Mon, 01 Mar 2004 03:22:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifu-0006H5-SZ for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 03:21:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01057 for ; Mon, 1 Mar 2004 03:21:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiZG-0003w3-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:14:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiYH-0003p2-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:13:26 -0500 Received: from hs22.order-vault.net ([65.18.133.138]) by ietf-mx with esmtp (Exim 4.12) id 1AxiXI-0003gA-00; Mon, 01 Mar 2004 03:12:25 -0500 Received: from lb-laptop.labn.net (labn.net [65.18.134.4]) (authenticated (0 bits)) by hs22.order-vault.net (8.11.6/8.11.6) with ESMTP id i218B6p01313; Mon, 1 Mar 2004 03:11:06 -0500 Message-Id: <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 01 Mar 2004 03:11:03 -0500 To: Alex Zinin From: Lou Berger Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Cc: Kireeti Kompella , Mukesh.Gupta@nokia.com, routing-discussion@ietf.org, In-Reply-To: <391404519.20040229142116@psg.com> References: <6.0.3.0.2.20040226205121.0620ebf8@mo-ex1> <391404519.20040229142116@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Alex, okay, got found your message. I think this should work for most cases. I'd suggest adding text that allows for >1 renewal with IESG approval (in unusual circumstances). Lou At 12:21 AM 2/29/2004, Alex Zinin wrote: >Lou, > > This would tie expiration to the author's ability to resubmit the draft, > rather than to how the doc progresses. We could instead say that once > the doc > is submitted to the IESG, the codepoint is "frozen". > >-- >Alex >http://www.psg.com/~zinin/ > >Friday, February 27, 2004, 10:51:35 AM, Lou Berger wrote: > > > [resend] > > > How about linking assignment expiration to expiration of the draft, 3 > > months after? If the draft makes it to RFC, no issue, if the draft > takes a > > long time through the editors queue (which can take ~1.5 years!), no > issue, > > if the draft keeps changing, no issue. If the draft dies, so does the > > assignment. > > > Lou > > > At 11:24 AM 2/26/2004, Kireeti Kompella wrote: > >>On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: > >> > >> > I finally got a chance to read the draft. The idea is good. I just > >> > have a couple of questions/concerns about the expiry of the early > >> > allocations.. > >> > > >> > - Do you think that "at most one renewal" would work in practice ? > >> > There might be instances where there is a genuine need to keep > >> > the early allocations for more than a year (Consider VRRPv3). > >> > How do we deal with that situation ? If it is not possible to > >> > renew the allocations more than once, do we need to ask for > >> > early allocations with new numbers (which ofcourse will make > >> > the situation worse) or we should just ask/let IANA to delete > >> > and reassign those numbers (which would create problems as well). > >> > >>We mulled a bit over how many times the allocations should be renewed. > >>The idea is that early allocation should NOT be requested as sson as > >>an ID is written :-) One renewal may be a bit too aggressive, but > >>it gives two years. Perhaps two renewals is okay, but no more (imho). > >> > >> > - The draft seems to put the responsibility of changing the status > >> > of the early allocations on the WG chairs ? I know that our chairs > >> > are very very responsible but I think, it will be a good idea to > >> > have an alternate mechanism in place such that the early allocations > >> > are marked deprecated/deleted automatically after a timeout. > >> > >>Automatic expiry was actually in the first version, but not everyone > >>felt comfortable with that. We can (and should) review this, and > >>perhaps make clearer what expiry means. > >> > >>Note that NOT adding to either IANA's or the IESG's workload is an > >>explicit goal. Whatever we can do to avoid adding to WG chairs' > >>workload is a 'nice-to-have' :-) > >> > >>Kireeti. > >>------- > >> > >>_______________________________________________ > >>routing-discussion mailing list > >>routing-discussion@ietf.org > >>https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 1 03:22:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01269 for ; Mon, 1 Mar 2004 03:22:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigj-0006MJ-HF; Mon, 01 Mar 2004 03:22:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axift-0006Gw-R6 for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 03:21:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01043 for ; Mon, 1 Mar 2004 03:21:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiZK-0003wd-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:14:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiYM-0003pp-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:13:31 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxiXN-0003k7-00; Mon, 01 Mar 2004 03:12:29 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxiXN-000HP1-L4; Mon, 01 Mar 2004 08:12:29 +0000 Date: Mon, 1 Mar 2004 17:12:06 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <7834347198.20040301171206@psg.com> To: Lou Berger CC: Kireeti Kompella , Mukesh.Gupta@nokia.com, routing-discussion@ietf.org, Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> References: <6.0.3.0.2.20040226205121.0620ebf8@mo-ex1> <391404519.20040229142116@psg.com> <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Fair enough. -- Alex http://www.psg.com/~zinin/ Monday, March 1, 2004, 5:11:03 PM, Lou Berger wrote: > Alex, > okay, got found your message. I think this should work for most > cases. I'd suggest adding text that allows for >1 renewal with IESG > approval (in unusual circumstances). > Lou > At 12:21 AM 2/29/2004, Alex Zinin wrote: >>Lou, >> >> This would tie expiration to the author's ability to resubmit the draft, >> rather than to how the doc progresses. We could instead say that once >> the doc >> is submitted to the IESG, the codepoint is "frozen". >> >>-- >>Alex >>http://www.psg.com/~zinin/ >> >>Friday, February 27, 2004, 10:51:35 AM, Lou Berger wrote: >> >> > [resend] >> >> > How about linking assignment expiration to expiration of the draft, 3 >> > months after? If the draft makes it to RFC, no issue, if the draft >> takes a >> > long time through the editors queue (which can take ~1.5 years!), no >> issue, >> > if the draft keeps changing, no issue. If the draft dies, so does the >> > assignment. >> >> > Lou >> >> > At 11:24 AM 2/26/2004, Kireeti Kompella wrote: >> >>On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: >> >> >> >> > I finally got a chance to read the draft. The idea is good. I just >> >> > have a couple of questions/concerns about the expiry of the early >> >> > allocations.. >> >> > >> >> > - Do you think that "at most one renewal" would work in practice ? >> >> > There might be instances where there is a genuine need to keep >> >> > the early allocations for more than a year (Consider VRRPv3). >> >> > How do we deal with that situation ? If it is not possible to >> >> > renew the allocations more than once, do we need to ask for >> >> > early allocations with new numbers (which ofcourse will make >> >> > the situation worse) or we should just ask/let IANA to delete >> >> > and reassign those numbers (which would create problems as well). >> >> >> >>We mulled a bit over how many times the allocations should be renewed. >> >>The idea is that early allocation should NOT be requested as sson as >> >>an ID is written :-) One renewal may be a bit too aggressive, but >> >>it gives two years. Perhaps two renewals is okay, but no more (imho). >> >> >> >> > - The draft seems to put the responsibility of changing the status >> >> > of the early allocations on the WG chairs ? I know that our chairs >> >> > are very very responsible but I think, it will be a good idea to >> >> > have an alternate mechanism in place such that the early allocations >> >> > are marked deprecated/deleted automatically after a timeout. >> >> >> >>Automatic expiry was actually in the first version, but not everyone >> >>felt comfortable with that. We can (and should) review this, and >> >>perhaps make clearer what expiry means. >> >> >> >>Note that NOT adding to either IANA's or the IESG's workload is an >> >>explicit goal. Whatever we can do to avoid adding to WG chairs' >> >>workload is a 'nice-to-have' :-) >> >> >> >>Kireeti. >> >>------- >> >> >> >>_______________________________________________ >> >>routing-discussion mailing list >> >>routing-discussion@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 1 12:34:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23729 for ; Mon, 1 Mar 2004 12:34:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpw0-0002h9-Qi; Mon, 01 Mar 2004 11:06:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpvc-0002Mu-D7 for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 11:06:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13887 for ; Mon, 1 Mar 2004 11:05:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axphm-0007RK-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 10:51:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxpTT-0002dW-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 10:36:58 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Axp1j-0002xB-00; Mon, 01 Mar 2004 10:08:15 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2004 07:06:33 -0800 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i21F7gT4028601; Mon, 1 Mar 2004 10:07:42 -0500 (EST) Message-Id: <200403011507.i21F7gT4028601@rtp-core-1.cisco.com> To: Alex Zinin cc: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-reply-to: Your message of Sun, 29 Feb 2004 14:14:01 +0900. <32969213.20040229141401@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 01 Mar 2004 10:07:42 -0500 From: Eric Rosen X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , > I think you're missing the problem. It is not the size of the space. It is > the circular dependency between IANA allocation and STD action. I think there is only a practical problem if the space is small. If the space is large, the problem is easily solved by making a part of it available for FCFS assignment. In fact, it seems evident that it doesn't make any sense to put a large space in the "STD action" category, as there is no means to enforce it. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 1 12:46:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24205 for ; Mon, 1 Mar 2004 12:46:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrUQ-0004P1-B4; Mon, 01 Mar 2004 12:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrUM-0004OF-5z for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 12:45:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24170 for ; Mon, 1 Mar 2004 12:45:55 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrUK-0000me-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 12:45:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrTP-0000gt-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 12:45:00 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AxrSy-0000as-00; Mon, 01 Mar 2004 12:44:32 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21HiRT26019; Mon, 1 Mar 2004 19:44:27 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 19:44:24 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i21HiOmJ032192; Mon, 1 Mar 2004 19:44:24 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00BriZNt; Mon, 01 Mar 2004 19:44:23 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21HiLO27705; Mon, 1 Mar 2004 19:44:22 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 09:43:43 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Date: Mon, 1 Mar 2004 11:43:41 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401547311@daebe009.americas.nokia.com> Thread-Topic: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Thread-Index: AcP/ZYhIyqRAsFFORx2VxOn7reii7gATyAMQ To: , , Cc: , X-OriginalArrivalTime: 01 Mar 2004 17:43:43.0941 (UTC) FILETIME=[BDC38750:01C3FFB4] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Okay, unless I hear strong arguments to the contrary, I will add >1 > renewals to the doc. If at all it matters, count my vote for this too. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Mar 1 12:46:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24210 for ; Mon, 1 Mar 2004 12:46:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrUj-0004RP-6s for routing-discussion-archive@odin.ietf.org; Mon, 01 Mar 2004 12:46:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21HkLJb016994 for routing-discussion-archive@odin.ietf.org; Mon, 1 Mar 2004 12:46:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrUQ-0004P1-B4; Mon, 01 Mar 2004 12:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrUM-0004OF-5z for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 12:45:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24170 for ; Mon, 1 Mar 2004 12:45:55 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrUK-0000me-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 12:45:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrTP-0000gt-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 12:45:00 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AxrSy-0000as-00; Mon, 01 Mar 2004 12:44:32 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21HiRT26019; Mon, 1 Mar 2004 19:44:27 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 19:44:24 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i21HiOmJ032192; Mon, 1 Mar 2004 19:44:24 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00BriZNt; Mon, 01 Mar 2004 19:44:23 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21HiLO27705; Mon, 1 Mar 2004 19:44:22 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 09:43:43 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Date: Mon, 1 Mar 2004 11:43:41 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401547311@daebe009.americas.nokia.com> Thread-Topic: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Thread-Index: AcP/ZYhIyqRAsFFORx2VxOn7reii7gATyAMQ To: , , Cc: , X-OriginalArrivalTime: 01 Mar 2004 17:43:43.0941 (UTC) FILETIME=[BDC38750:01C3FFB4] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Okay, unless I hear strong arguments to the contrary, I will add >1 > renewals to the doc. If at all it matters, count my vote for this too. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 1 14:28:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29105 for ; Mon, 1 Mar 2004 14:28:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt57-0002gM-D3; Mon, 01 Mar 2004 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt55-0002fi-2b for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 14:27:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29080 for ; Mon, 1 Mar 2004 14:27:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4w-0004yt-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 14:27:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt3x-0004rZ-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 14:26:50 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Axt2y-0004g6-00; Mon, 01 Mar 2004 14:25:48 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i21JPI1K049498; Mon, 1 Mar 2004 11:25:18 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i21JPI65049495; Mon, 1 Mar 2004 11:25:18 -0800 (PST) Date: Mon, 1 Mar 2004 11:25:18 -0800 (PST) Message-Id: <200403011925.i21JPI65049495@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Lou Berger Cc: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <6.0.3.0.2.20040226143327.03467ea8@mail.labn.net> References: <8D260779A766FB4A9C1739A476F84FA401F799BA@daebe009.americas.nokia.com> <20040226081555.S11637@kummer.juniper.net> <6.0.3.0.2.20040226143327.03467ea8@mail.labn.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Lou Berger writes: > How about linking assignment expiration to expiration of the draft, > 3 months after? If the draft makes it to RFC, no issue, if the > draft takes a long time through the editors queue (which can take > ~1.5 years!), no issue, if the draft keeps changing, no issue. If > the draft dies, so does the assignment. Just make sure you don't try to reuse the same assigned number for something else in less than 10 years, if it ever gets into software... That is about the lifetime for 'deprecated' behaviour. While the ietf may be able to assume that an assigment "dies"... the decision may not be so simple in the real world. I would at least like to have a good idea of everyone that claims to have implemented said code point... Ask your self the question: How many networks are running TDP, which is a protocol that "died" in the ietf ? And would you like to reuse its code point ? I'm sure that people can come up w/ many other examples. Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 1 19:39:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16213 for ; Mon, 1 Mar 2004 19:39:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxw4-0007Vt-QF; Mon, 01 Mar 2004 19:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxvU-0007N7-3f for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 19:38:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15975 for ; Mon, 1 Mar 2004 19:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxvS-0000Vu-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 19:38:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxuU-0000Lc-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 19:37:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxxtO-0000CP-00; Mon, 01 Mar 2004 19:36:14 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxxtO-000FC9-KT; Tue, 02 Mar 2004 00:36:14 +0000 Date: Tue, 2 Mar 2004 09:35:53 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4055365811.20040302093553@psg.com> To: Eric Rosen CC: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <200403011507.i21F7gT4028601@rtp-core-1.cisco.com> References: <200403011507.i21F7gT4028601@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eric, > I think there is only a practical problem if the space is small. If the > space is large, the problem is easily solved by making a part of it > available for FCFS assignment. In fact, it seems evident that it doesn't > make any sense to put a large space in the "STD action" category, as there > is no means to enforce it. I see your point now. Note that "STD action" and a space being small are not directly related--it is feasible to use "STD action" even if the space is big enough (e.g. for change control), and on the other hand, it is possible to use other policies for scarce resources (Expert Review, IESG Approval, IETF Consensus). Also note, that there several existing registries with "STD action" as the policy and that need this issue solved. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Mar 1 19:39:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16215 for ; Mon, 1 Mar 2004 19:39:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxwQ-0007fR-Ly for routing-discussion-archive@odin.ietf.org; Mon, 01 Mar 2004 19:39:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220dMtm029382 for routing-discussion-archive@odin.ietf.org; Mon, 1 Mar 2004 19:39:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxw4-0007Vt-QF; Mon, 01 Mar 2004 19:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxvU-0007N7-3f for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 19:38:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15975 for ; Mon, 1 Mar 2004 19:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxvS-0000Vu-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 19:38:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxuU-0000Lc-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 19:37:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxxtO-0000CP-00; Mon, 01 Mar 2004 19:36:14 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxxtO-000FC9-KT; Tue, 02 Mar 2004 00:36:14 +0000 Date: Tue, 2 Mar 2004 09:35:53 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4055365811.20040302093553@psg.com> To: Eric Rosen CC: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <200403011507.i21F7gT4028601@rtp-core-1.cisco.com> References: <200403011507.i21F7gT4028601@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eric, > I think there is only a practical problem if the space is small. If the > space is large, the problem is easily solved by making a part of it > available for FCFS assignment. In fact, it seems evident that it doesn't > make any sense to put a large space in the "STD action" category, as there > is no means to enforce it. I see your point now. Note that "STD action" and a space being small are not directly related--it is feasible to use "STD action" even if the space is big enough (e.g. for change control), and on the other hand, it is possible to use other policies for scarce resources (Expert Review, IESG Approval, IETF Consensus). Also note, that there several existing registries with "STD action" as the policy and that need this issue solved. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 12 17:04:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21641 for ; Fri, 12 Mar 2004 17:04:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ul7-0005YO-Iy; Fri, 12 Mar 2004 17:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ukt-0005Y3-B6 for routing-discussion@optimus.ietf.org; Fri, 12 Mar 2004 17:03:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21615 for ; Fri, 12 Mar 2004 17:03:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ukr-0002MF-00 for routing-discussion@ietf.org; Fri, 12 Mar 2004 17:03:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uk4-0002Kk-00 for routing-discussion@ietf.org; Fri, 12 Mar 2004 17:02:57 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B1ujJ-0002HU-00; Fri, 12 Mar 2004 17:02:09 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1ujJ-0003da-46; Fri, 12 Mar 2004 22:02:09 +0000 Date: Fri, 12 Mar 2004 14:01:44 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <105224538989.20040312140144@psg.com> To: minutes@ietf.org CC: routing-discussion@ietf.org Subject: Minutes for IETF59/RTG Area MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks to Adrian for taking the minutes! I'll submit presented slides as well. -- Alex http://www.psg.com/~zinin/ Intro Bill: Routing Area Web page fallen into disuse New routing area directorate folks to replace Tony and Tony. New routing working group as catch-all Close BGMP, IDMR - Saying this for 2 years - Now date is set to wind them up (July 2004) - Real target! Create BFD WG before San Diego Create RPSEC WG especially for BGP security around October. - Requirements are coming somewhat from other SDOs. Dave: What is the disposition of the BGP draft? Bill: See slide later WG reports BGMP - after approval as experimental found bug. - no AS number in BGP open message, but text said to use it! - new revision planned Dave: Will we have no stds track IDR protocol for multicast? Bill: Yes, that's what it means Dave: SSM makes stds track then this means we endorse SSM as *the* multicast IDR for IPv4 Bill: Good point. But since scaling problems with one, and almost no interest in BGMP Dave: Different to say no interest in BGMP and no interest in multicast IDR Bill: But clearly no interest in scalable protocol Maybe this means there is no interest? Dave: But there is interest. And experimental protocol is deployed. Have been asking this for some time. This seems to be a statement to solve implicitly using SSM Bill: Don't think this is what we're saying. Peter: There is ASN traffic in the n/w MSTP does the job today. Has problems but not seen them. It is holding together and being used. Try to figure out the growth of MSTP in the Internet and try to predict when we will hit the problem. Someone needs to figure a protocol to address all required functions Bill: Hard to say where effort to figure out IDR multicast should go WG charter doesn't help. cf IDMR WG. Takes more than a place to do the work. Takes energy and ideas and feeling is that those aren't coming. CCAMP Adrian: No questions. IDMR Bill: Dave Thaler: what is the status of DVMRP. no security Bill: pushing for proposed std track since it has uses in certain environments IDR Yakhov: Finished base spec. Very significant. Many docs now go to IESG Can now progress other items Can now start new work - cannot pick it all up - need feedback for priority list - SPs and vendors - please input Sue: Thanks for BGP implementation reports respondents Thanks to the people who processed the 260 questionnaires ISIS Alex: New co chairs for ISIS Should ISIS stds go to stds track? IGP pt-2-pt pending revision OSPF Alex: graceful restart recently approve v3 authentication and MIB update to ADs 2547 extension for loop prevention minor comments from IESG interesting discussions on mailing list multi-address families, and multi-area adjacencies MANET Alex: DSR spec is pending update after AD review RPSEC Alex: Needs more input on requirements. Please do help. Security requirements for BGP security (see previous new WG) Routing WG Alex: New WG No documents yet. Wrong! MPLS/SPF for traffic engineering - expect comments and last call soon Please subscribe to the mailing list rtgwg-request@ietf.org MPLS Loa: Had meeting Monday Most cycles on TE - P2MP - OAM framework A couple of docs about to IESG or with updates after review (7 or 8 of these) 12 docs in RFC ed queue about to be released as references are sorted out ??Topic?? Bill: Spec updated to fix a blackhole Means spec was reviewed very well! IESG in a month or so SSM Some delay while discussing Apple(?)'s claim on IPR Believed to be resolved VRRP Bill: v2 approved v3 (IPv6) - some issues found - most resolved Routing Research charter Avri: see slides Closed groups are going to do quarterly reports to the list and an annual gathering Research proposals please - short term (for example as rejected by WG) - complete the work in 6-18 months - longer term - e.g. is there life after BGP? - e.g. routing and protocol scalability This is research so if the end result was "bad idea" this would still be good research. meeting slot planned for ietf 60 interim (co-sponsored) meeting is planned Alex: How to get onto closed mailing list? Avri Send to main list asking for "in" Alex: How do you get deliverables from a research group Avri We have to work with them to set up milestones Keep open line between rtg area and rtg working group IANA Alex: Who read the draft? answer ----? see slides Issue - deployment of drafts uses interim codepoints Often considerable deployments Other non-rtg similar issues. AFI/SAFI Sue: see slides Used *before* reach problem stated by Alex Kireeti wants an AFI Alex: Thanks to Kireeti Bill: RFC3692 on experimental alloc suggests pick a small set and designate them for experimental alloc default behavior is non-support - needs to be turned on by operator Bob: IPv6 had discussion on ICMP codes ended up with 3 options could use extendible codes IPv6 leant towards alloc when adopted by WG - becomes permanent when RFC Need a generic way not just rtg-area Alex: that is intention Bill have you adopted any ideas? Bob: No, beginning to put language in Bill: in case of temp alloc, concern is you assign to a proposal, but WG now needs to massage packet format, but it is already deployed with a number, what do you do? new number? Bob: Up to WG chairs as per Alex What about individual submissions? Alex: This doc tries to address stds action policy not individual - would need to go through IESG Kireeti No early allocation for individual drafts Bob: Same problem for ICMP etc because this is "IESG action" Kireeti: Alex and Kireeti is stds action for early alloc Sue is talking about experimental which might go to stds track Alex: Would this be useful to IPv6 Bob: Yes WG would consider using it twiddling values in experimental by end user might be not good Kireeti: This is experimental only Bill: Would not be good for major deployment Dave: In last proposal not clear whether to assign a range but not a specific number, or if WG says specific number. Bill: RFC doesn't say Dave: Not asking about RFC. What about configurable for experimental. Is usage agree ahead of time, or is it up to the implementer to force operator to type it in? Bill: Either. must be config because it is from experimental range and someone may have conflicts Dave: Compare different proposals. like subrange == experimental Or mark as temporary out of ordinary == good because no change in implementation if no changes Bill: disadvantage if you rev or peter out. cannot reclaim until timeout Dave: Bob and Brian, 27 allocated over ten years Time limit may not be important in large space Kireeti: Not all codespaces (eg IP protocols is implicit stds action) have explicit actions associated Proposal is specifically for stds action space Need stable allocation Experimental is not a big deal if there is a change First come first served is dangerous in a different way Dave said what does one year mean when it expires? need to make this clearer. Early is in some sense temporary If spec dies it becomes "deprecated" and then time that out (e.g. RSVP case, value was not marked deprecated so IANA re-allocated) Alex: Sense of the room, about draft-kompella-zinin approach is useful? "pretty good" approach is not right? - just Kireeti ;) ditto Afi/safi useful? very few not useful? none need to ask in IDR IP/LDP loop protection Alia: see slides pre-compute an alternate path cf. IGP fast reroute questions after second presentation next hop fast re-route Naiming: see slides Yakhov: slide 3 R1 R2 is pt to pt, but suppose multiaccess media? Alia: if all nodes in same area, and R2 is the primary neighbor then R1 can assume traffic is from R2 Yakhov: If SPF takes zero time then would there be any value Alia: propagate is non zero install time is non zero Yakhov: not need to propagate to all Alia: Some cases there may be more than one router Yakhov: If only one? Alia: If more than one then it is valid Kireeti: 80% if no U-turns? Alia: 79.5 Kireeti: Real network? Alia: Yes Kireeti: U-turns in real networks? Alia: Yes Cengiz: I tried without u-turns even then in the networks I tried I had 90% Kireeti: I'm surprised that the number is so low w/o uturns because network is dense Alia: topology dependent analysis based on src/dest pairs lots of traffic not covered by loop free percentage of traffic is not same as percentage pairs Rahul: what if equal cost paths to neighbor Alia It works Rahul: R2 is PLR R1 u-turn neighbor How does R1 know where to put traffic Alia: If there is only one primary neighbor [note taker got confused ....] Rahul: when I said doesn't work I meant reduces Alia: never reduces below loop free w/out utirn Yakhov: Covers node failure? Alia: Yes Ina???? Deployment considerations in n/w Alia: Need to support IGP extensions for u-turn ??? How fast Alia: depends on h/w per interface forwarding table Kireeti: What effect on the size of the routing table A Forwarding table not routing table Kireeti: bad? Alia: Not as bad as one per i/f since max two Kireeti: has naiming done coverage? Alex: take discussion to RTGWG (not routing discussion list) RIFT David Meyer: slides send questions to the GROW meeting OIF routing Lyndon Ong: there is liaison statement - need to find out relationship to get people access to it OIF has been working on E-NNI routing specification based on OSPF model for transport n/w is similar to ITU work elements grouped into domains and connected to each other through E-NNI reference points some domains may use distributed control and others may use EMS but still interface to other domains through sig + routing protocols hierarchy domains == RA (routing area) model is similar to ITU model domains may be partitioned to give mulit-level hierarchical relationship Assumptions see slide Status see slide testing at OFC in 2003 did not test any hierarchy extensions not a std solution defined as prototype for testing Rahul: concerning to see changes to OSPF without telling OSPF WG hierarchy is alarming I'm expressing concern Lyndon: recognise concern hierarchy is not simple and not something we have been testing bringing it here now Dimitri: How does this differ from CCAMP DT routing for ITU since that work follows ITU model Why take this experimental solution and not develop based on DT Lyndon: problems here are consistent w/ problems in DT difference here is that OIF has gone ahead and defined what some of these extensions might look like Russ: please give ptr to url Alex: liaison will be available Kireeti: CCAMP chair hat on worked on it for a while and bring it now say this is for testing which is good but now you have brought it to us if ask for rubber stamp won't happen but you need codepoints and we want a good relationship tell us the requirements, and we will extend since we know protocols big risk of two sets of solutions that are different compare with RSVP work where OIF/ITU work is not compatible protocols are understood here where implementers and deployers are found are you asking for rubber stamp what is end goal? Lyndon: not approved through OIF as an implementation agreement it is a draft if we can work out how to do it in OSPF then it is not too late Kireeti: do you want us to take your changes do what with them? Lyndon: oif did send a liaison asking for comment/feedback sent to ccamp chairs and routing area directors expectation is not rubber stamp expectation is that this group have a look at the problems that generated these prototype extensions hope is that these problems will be addressed through std extensions of OSPF whether the extensions change is up to this group Kireeti: would have been better to bring requirements Arthi: we can work through the problems and have solutions to them and get discussions Lyndon: work wasn't done for the sake of it people looked at specs and said "we don't know how to do something" Zafar Ali: need to understand overlap with ITU requirements follow same model Lyndon: should look for delta to ASON requirements Zafar: if so we can overlap the solution space Dimitri: how much is change to basic protocol and how much to TE LSAs? how has OIF evaluated impact analysis Lyndon: expertise for impact is in this group changes were to achieve specific functions Alex: there is concern about OSPF extensions being defined elsewhere your answer is your not trying to define a std your intention is to experiment and see what the extensions might look like your intention is to come here and work with us apology to Christophe - out of time _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Mar 12 17:04:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21642 for ; Fri, 12 Mar 2004 17:04:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ulM-0005Zo-Po for routing-discussion-archive@odin.ietf.org; Fri, 12 Mar 2004 17:04:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CM4GYM021435 for routing-discussion-archive@odin.ietf.org; Fri, 12 Mar 2004 17:04:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ul7-0005YO-Iy; Fri, 12 Mar 2004 17:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ukt-0005Y3-B6 for routing-discussion@optimus.ietf.org; Fri, 12 Mar 2004 17:03:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21615 for ; Fri, 12 Mar 2004 17:03:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ukr-0002MF-00 for routing-discussion@ietf.org; Fri, 12 Mar 2004 17:03:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uk4-0002Kk-00 for routing-discussion@ietf.org; Fri, 12 Mar 2004 17:02:57 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B1ujJ-0002HU-00; Fri, 12 Mar 2004 17:02:09 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1ujJ-0003da-46; Fri, 12 Mar 2004 22:02:09 +0000 Date: Fri, 12 Mar 2004 14:01:44 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <105224538989.20040312140144@psg.com> To: minutes@ietf.org CC: routing-discussion@ietf.org Subject: Minutes for IETF59/RTG Area MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks to Adrian for taking the minutes! I'll submit presented slides as well. -- Alex http://www.psg.com/~zinin/ Intro Bill: Routing Area Web page fallen into disuse New routing area directorate folks to replace Tony and Tony. New routing working group as catch-all Close BGMP, IDMR - Saying this for 2 years - Now date is set to wind them up (July 2004) - Real target! Create BFD WG before San Diego Create RPSEC WG especially for BGP security around October. - Requirements are coming somewhat from other SDOs. Dave: What is the disposition of the BGP draft? Bill: See slide later WG reports BGMP - after approval as experimental found bug. - no AS number in BGP open message, but text said to use it! - new revision planned Dave: Will we have no stds track IDR protocol for multicast? Bill: Yes, that's what it means Dave: SSM makes stds track then this means we endorse SSM as *the* multicast IDR for IPv4 Bill: Good point. But since scaling problems with one, and almost no interest in BGMP Dave: Different to say no interest in BGMP and no interest in multicast IDR Bill: But clearly no interest in scalable protocol Maybe this means there is no interest? Dave: But there is interest. And experimental protocol is deployed. Have been asking this for some time. This seems to be a statement to solve implicitly using SSM Bill: Don't think this is what we're saying. Peter: There is ASN traffic in the n/w MSTP does the job today. Has problems but not seen them. It is holding together and being used. Try to figure out the growth of MSTP in the Internet and try to predict when we will hit the problem. Someone needs to figure a protocol to address all required functions Bill: Hard to say where effort to figure out IDR multicast should go WG charter doesn't help. cf IDMR WG. Takes more than a place to do the work. Takes energy and ideas and feeling is that those aren't coming. CCAMP Adrian: No questions. IDMR Bill: Dave Thaler: what is the status of DVMRP. no security Bill: pushing for proposed std track since it has uses in certain environments IDR Yakhov: Finished base spec. Very significant. Many docs now go to IESG Can now progress other items Can now start new work - cannot pick it all up - need feedback for priority list - SPs and vendors - please input Sue: Thanks for BGP implementation reports respondents Thanks to the people who processed the 260 questionnaires ISIS Alex: New co chairs for ISIS Should ISIS stds go to stds track? IGP pt-2-pt pending revision OSPF Alex: graceful restart recently approve v3 authentication and MIB update to ADs 2547 extension for loop prevention minor comments from IESG interesting discussions on mailing list multi-address families, and multi-area adjacencies MANET Alex: DSR spec is pending update after AD review RPSEC Alex: Needs more input on requirements. Please do help. Security requirements for BGP security (see previous new WG) Routing WG Alex: New WG No documents yet. Wrong! MPLS/SPF for traffic engineering - expect comments and last call soon Please subscribe to the mailing list rtgwg-request@ietf.org MPLS Loa: Had meeting Monday Most cycles on TE - P2MP - OAM framework A couple of docs about to IESG or with updates after review (7 or 8 of these) 12 docs in RFC ed queue about to be released as references are sorted out ??Topic?? Bill: Spec updated to fix a blackhole Means spec was reviewed very well! IESG in a month or so SSM Some delay while discussing Apple(?)'s claim on IPR Believed to be resolved VRRP Bill: v2 approved v3 (IPv6) - some issues found - most resolved Routing Research charter Avri: see slides Closed groups are going to do quarterly reports to the list and an annual gathering Research proposals please - short term (for example as rejected by WG) - complete the work in 6-18 months - longer term - e.g. is there life after BGP? - e.g. routing and protocol scalability This is research so if the end result was "bad idea" this would still be good research. meeting slot planned for ietf 60 interim (co-sponsored) meeting is planned Alex: How to get onto closed mailing list? Avri Send to main list asking for "in" Alex: How do you get deliverables from a research group Avri We have to work with them to set up milestones Keep open line between rtg area and rtg working group IANA Alex: Who read the draft? answer ----? see slides Issue - deployment of drafts uses interim codepoints Often considerable deployments Other non-rtg similar issues. AFI/SAFI Sue: see slides Used *before* reach problem stated by Alex Kireeti wants an AFI Alex: Thanks to Kireeti Bill: RFC3692 on experimental alloc suggests pick a small set and designate them for experimental alloc default behavior is non-support - needs to be turned on by operator Bob: IPv6 had discussion on ICMP codes ended up with 3 options could use extendible codes IPv6 leant towards alloc when adopted by WG - becomes permanent when RFC Need a generic way not just rtg-area Alex: that is intention Bill have you adopted any ideas? Bob: No, beginning to put language in Bill: in case of temp alloc, concern is you assign to a proposal, but WG now needs to massage packet format, but it is already deployed with a number, what do you do? new number? Bob: Up to WG chairs as per Alex What about individual submissions? Alex: This doc tries to address stds action policy not individual - would need to go through IESG Kireeti No early allocation for individual drafts Bob: Same problem for ICMP etc because this is "IESG action" Kireeti: Alex and Kireeti is stds action for early alloc Sue is talking about experimental which might go to stds track Alex: Would this be useful to IPv6 Bob: Yes WG would consider using it twiddling values in experimental by end user might be not good Kireeti: This is experimental only Bill: Would not be good for major deployment Dave: In last proposal not clear whether to assign a range but not a specific number, or if WG says specific number. Bill: RFC doesn't say Dave: Not asking about RFC. What about configurable for experimental. Is usage agree ahead of time, or is it up to the implementer to force operator to type it in? Bill: Either. must be config because it is from experimental range and someone may have conflicts Dave: Compare different proposals. like subrange == experimental Or mark as temporary out of ordinary == good because no change in implementation if no changes Bill: disadvantage if you rev or peter out. cannot reclaim until timeout Dave: Bob and Brian, 27 allocated over ten years Time limit may not be important in large space Kireeti: Not all codespaces (eg IP protocols is implicit stds action) have explicit actions associated Proposal is specifically for stds action space Need stable allocation Experimental is not a big deal if there is a change First come first served is dangerous in a different way Dave said what does one year mean when it expires? need to make this clearer. Early is in some sense temporary If spec dies it becomes "deprecated" and then time that out (e.g. RSVP case, value was not marked deprecated so IANA re-allocated) Alex: Sense of the room, about draft-kompella-zinin approach is useful? "pretty good" approach is not right? - just Kireeti ;) ditto Afi/safi useful? very few not useful? none need to ask in IDR IP/LDP loop protection Alia: see slides pre-compute an alternate path cf. IGP fast reroute questions after second presentation next hop fast re-route Naiming: see slides Yakhov: slide 3 R1 R2 is pt to pt, but suppose multiaccess media? Alia: if all nodes in same area, and R2 is the primary neighbor then R1 can assume traffic is from R2 Yakhov: If SPF takes zero time then would there be any value Alia: propagate is non zero install time is non zero Yakhov: not need to propagate to all Alia: Some cases there may be more than one router Yakhov: If only one? Alia: If more than one then it is valid Kireeti: 80% if no U-turns? Alia: 79.5 Kireeti: Real network? Alia: Yes Kireeti: U-turns in real networks? Alia: Yes Cengiz: I tried without u-turns even then in the networks I tried I had 90% Kireeti: I'm surprised that the number is so low w/o uturns because network is dense Alia: topology dependent analysis based on src/dest pairs lots of traffic not covered by loop free percentage of traffic is not same as percentage pairs Rahul: what if equal cost paths to neighbor Alia It works Rahul: R2 is PLR R1 u-turn neighbor How does R1 know where to put traffic Alia: If there is only one primary neighbor [note taker got confused ....] Rahul: when I said doesn't work I meant reduces Alia: never reduces below loop free w/out utirn Yakhov: Covers node failure? Alia: Yes Ina???? Deployment considerations in n/w Alia: Need to support IGP extensions for u-turn ??? How fast Alia: depends on h/w per interface forwarding table Kireeti: What effect on the size of the routing table A Forwarding table not routing table Kireeti: bad? Alia: Not as bad as one per i/f since max two Kireeti: has naiming done coverage? Alex: take discussion to RTGWG (not routing discussion list) RIFT David Meyer: slides send questions to the GROW meeting OIF routing Lyndon Ong: there is liaison statement - need to find out relationship to get people access to it OIF has been working on E-NNI routing specification based on OSPF model for transport n/w is similar to ITU work elements grouped into domains and connected to each other through E-NNI reference points some domains may use distributed control and others may use EMS but still interface to other domains through sig + routing protocols hierarchy domains == RA (routing area) model is similar to ITU model domains may be partitioned to give mulit-level hierarchical relationship Assumptions see slide Status see slide testing at OFC in 2003 did not test any hierarchy extensions not a std solution defined as prototype for testing Rahul: concerning to see changes to OSPF without telling OSPF WG hierarchy is alarming I'm expressing concern Lyndon: recognise concern hierarchy is not simple and not something we have been testing bringing it here now Dimitri: How does this differ from CCAMP DT routing for ITU since that work follows ITU model Why take this experimental solution and not develop based on DT Lyndon: problems here are consistent w/ problems in DT difference here is that OIF has gone ahead and defined what some of these extensions might look like Russ: please give ptr to url Alex: liaison will be available Kireeti: CCAMP chair hat on worked on it for a while and bring it now say this is for testing which is good but now you have brought it to us if ask for rubber stamp won't happen but you need codepoints and we want a good relationship tell us the requirements, and we will extend since we know protocols big risk of two sets of solutions that are different compare with RSVP work where OIF/ITU work is not compatible protocols are understood here where implementers and deployers are found are you asking for rubber stamp what is end goal? Lyndon: not approved through OIF as an implementation agreement it is a draft if we can work out how to do it in OSPF then it is not too late Kireeti: do you want us to take your changes do what with them? Lyndon: oif did send a liaison asking for comment/feedback sent to ccamp chairs and routing area directors expectation is not rubber stamp expectation is that this group have a look at the problems that generated these prototype extensions hope is that these problems will be addressed through std extensions of OSPF whether the extensions change is up to this group Kireeti: would have been better to bring requirements Arthi: we can work through the problems and have solutions to them and get discussions Lyndon: work wasn't done for the sake of it people looked at specs and said "we don't know how to do something" Zafar Ali: need to understand overlap with ITU requirements follow same model Lyndon: should look for delta to ASON requirements Zafar: if so we can overlap the solution space Dimitri: how much is change to basic protocol and how much to TE LSAs? how has OIF evaluated impact analysis Lyndon: expertise for impact is in this group changes were to achieve specific functions Alex: there is concern about OSPF extensions being defined elsewhere your answer is your not trying to define a std your intention is to experiment and see what the extensions might look like your intention is to come here and work with us apology to Christophe - out of time _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 12 20:47:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05707 for ; Fri, 12 Mar 2004 20:47:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yEv-0001dv-8O; Fri, 12 Mar 2004 20:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yEm-0001df-T1 for routing-discussion@optimus.ietf.org; Fri, 12 Mar 2004 20:46:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05694 for ; Fri, 12 Mar 2004 20:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1yEk-0001ej-00 for routing-discussion@ietf.org; Fri, 12 Mar 2004 20:46:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1yDm-0001dZ-00 for routing-discussion@ietf.org; Fri, 12 Mar 2004 20:45:51 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B1yDT-0001cZ-00 for routing-discussion@ietf.org; Fri, 12 Mar 2004 20:45:31 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1yDT-000Osc-Vm for routing-discussion@ietf.org; Sat, 13 Mar 2004 01:45:32 +0000 Date: Fri, 12 Mar 2004 17:03:20 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <76235435418.20040312170320@psg.com> To: routing-discussion@ietf.org Subject: Corrected minutes for IETF59/RTG Area MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- Minutes with some corrections below. I'll see if there are any more before submitting a corrected ver to minutes@ -- Alex Intro Bill: Routing Area Web page fallen into disuse New routing area directorate folks: Dimitri, Loa New WG chairs for ISIS: Chris Hopps, Dave Ward. Thanks a lot to Tony and Tony. New routing working group (RTGWG) as catch-all for small projects Close BGMP, IDMR - Saying this for 2 years - Now date is set to wind them up (July 2004) - Real target! Create BFD WG before San Diego Create RPSEC WG especially for BGP security around October. - Requirements are coming somewhat from other SDOs. - Will take requirements from RPSEC Dave: What is the disposition of the BGMP draft? Bill: See slide later WG reports BGMP - after approval as experimental found bug. - no AS number in BGP open message, but text said to use it! - new revision planned Dave: Will we have no stds track inter-domain routing protocol for multicast? Bill: Yes, that's what it means Dave: SSM makes stds track then this means we endorse SSM as *the* multicast IDR for IPv4 Bill: Good point. But since scaling problems with one, and almost no interest in BGMP Dave: Different to say no interest in BGMP and no interest in multicast IDR Bill: But clearly no interest in scalable protocol Maybe this means there is no interest? Dave: But there is interest. And experimental protocol is deployed. Have been asking this for some time. This seems to be a statement to solve implicitly using SSM Bill: Don't think this is what we're saying. Peter: There is ASN traffic in the n/w MSDP does the job today. Has problems but not seen them. It is holding together and being used. Try to figure out the growth of MSDP in the Internet and try to predict when we will hit the problem. Someone needs to figure a protocol to address all required functions Bill: Hard to say where effort to figure out IDR multicast should go WG charter doesn't help. cf IDMR WG. Takes more than a place to do the work. Takes energy and ideas and feeling is that those aren't coming. CCAMP Adrian: No questions. IDMR Bill: Dave Thaler: what is the status of DVMRP. no security Bill: pushing for proposed std track since it has uses in certain environments IDR Yakhov: Finished base spec. Very significant. Many docs now go to IESG Can now progress other items Can now start new work - cannot pick it all up - need feedback for priority list - SPs and vendors - please input Sue: Thanks for BGP implementation reports respondents Thanks to the people who processed the 260 questions in the implementation questionnaire ISIS Alex: New co chairs for ISIS Discussion in the WG: should ISIS stds go to stds track? IGP pt-2-pt pending revision OSPF Alex: graceful restart recently approved v3 authentication and MIB update to ADs 2547 extension for loop prevention minor comments from IESG interesting discussions on mailing list: - MANET extensions - multi-address families, - multi-area adjacencies MANET Alex: DSR spec is pending update after AD review Will be making a decision wrt the direction with MANET-OSPF extensiosn RPSEC Alex: Needs more input on requirements. Please do help. Security requirements for BGP security (see previous new WG) Routing WG Alex: New WG No documents yet. Wrong! MPLS/SPF for traffic engineering - expect comments and last call soon Please subscribe to the mailing list rtgwg-request@ietf.org MPLS Loa: Had meeting Monday Most cycles on TE - P2MP - OAM framework A couple of docs about to IESG or with updates after review (7 or 8 of these) 12 docs in RFC ed queue about to be released as references are sorted out PIM Bill: Spec updated to fix a blackhole Means spec was reviewed very well! IESG in a month or so SSM Had some delay while discussing Apple's claim on IPR Believed to be resolved VRRP Bill: v2 approved v3 (IPv6) - some issues found - most resolved Routing Research charter Avri: see slides Closed groups are going to do quarterly reports to the list and an annual gathering Research proposals please - short term (for example as rejected by WG) - complete the work in 6-18 months - longer term - e.g. is there life after BGP? - e.g. routing and protocol scalability This is research so if the end result was "bad idea" this would still be good research. meeting slot planned for ietf 60 interim (co-sponsored) meeting is planned Alex: How to get onto closed mailing list? Avri Send to main list asking for "in" Alex: How do you get deliverables from a research group Avri We have to work with them to set up milestones Keep open line between rtg area and rtg working group IANA Alex: Who read the draft? About 15 ppl: not bad see slides Issue - deployment of drafts uses interim codepoints Often considerable deployments Other non-rtg similar issues. AFI/SAFI Sue: see slides Used *before* reach problem stated by Alex Kireeti wants an AFI Alex: Thanks to Kireeti for co-authoring, he wrote most of the text Bill: RFC3692 on experimental alloc suggests pick a small set and designate them for experimental alloc default behavior is non-support - needs to be turned on by operator Bob: IPv6 had discussion on ICMP codes ended up with 3 options could use extendible codes IPv6 leant towards alloc when adopted by WG - becomes permanent when RFC Need a generic way not just rtg-area Alex: that is intention Bill have you adopted any ideas? Bob: No, beginning to put language in Bill: in case of temp alloc, concern is you assign to a proposal, but WG now needs to massage packet format, but it is already deployed with a number, what do you do? new number? Bob: Up to WG chairs as per Alex What about individual submissions? Alex: This doc tries to address stds action policy not individual - would need to go through IESG Kireeti No early allocation for individual drafts Bob: Same problem for ICMP etc because this is "IESG action" Kireeti: Alex and Kireeti is stds action for early alloc Sue is talking about experimental which might go to stds track Alex: Would this be useful to IPv6 Bob: Yes WG would consider using it twiddling values in experimental by end user might be not good Kireeti: This is experimental only Bill: Would not be good for major deployment Dave: In last proposal not clear whether to assign a range but not a specific number, or if WG says specific number. Bill: RFC doesn't say Dave: Not asking about RFC. What about configurable for experimental. Is usage agree ahead of time, or is it up to the implementer to force operator to type it in? Bill: Either. must be config because it is from experimental range and someone may have conflicts Dave: Compare different proposals. like subrange == experimental Or mark as temporary out of ordinary == good because no change in implementation if no changes Bill: disadvantage if you rev or peter out. cannot reclaim until timeout Dave: Bob and Brian, 27 allocated over ten years Time limit may not be important in large space Kireeti: Not all codespaces (eg IP protocols is implicit stds action) have explicit actions associated Proposal is specifically for stds action space Need stable allocation Experimental is not a big deal if there is a change First come first served is dangerous in a different way Dave said what does one year mean when it expires? need to make this clearer. Early is in some sense temporary If spec dies it becomes "deprecated" and then time that out (e.g. RSVP case, value was not marked deprecated so IANA re-allocated) Alex: Sense of the room, about draft-kompella-zinin approach is useful? "pretty good" approach is not right? - just Kireeti ;) ditto Afi/safi useful? very few not useful? none need to ask in IDR IP/LDP loop protection Alia: see slides pre-compute an alternate path cf. IGP fast reroute questions after second presentation next hop fast re-route Naiming: see slides Yakhov: slide 3 R1 R2 is pt to pt, but suppose multiaccess media? Alia: if all nodes in same area, and R2 is the primary neighbor then R1 can assume traffic is from R2 Yakhov: If SPF takes zero time then would there be any value Alia: propagate is non zero install time is non zero Yakhov: not need to propagate to all Alia: Some cases there may be more than one router Yakhov: If only one? Alia: If more than one then it is valid Kireeti: 80% if no U-turns? Alia: 79.5 Kireeti: Real network? Alia: Yes Kireeti: U-turns in real networks? Alia: Yes Cengiz: I tried without u-turns even then in the networks I tried I had 90% Kireeti: I'm surprised that the number is so low w/o uturns because network is dense Alia: topology dependent analysis based on src/dest pairs lots of traffic not covered by loop free percentage of traffic is not same as percentage pairs Rahul: what if equal cost paths to neighbor Alia It works Rahul: R2 is PLR R1 u-turn neighbor How does R1 know where to put traffic Alia: If there is only one primary neighbor [note taker got confused ....] Rahul: when I said doesn't work I meant reduces Alia: never reduces below loop free w/out utirn Yakhov: Covers node failure? Alia: Yes Ina???? Deployment considerations in n/w Alia: Need to support IGP extensions for u-turn ??? How fast Alia: depends on h/w per interface forwarding table Kireeti: What effect on the size of the routing table A Forwarding table not routing table Kireeti: bad? Alia: Not as bad as one per i/f since max two Kireeti: has naiming done coverage? Alex: take discussion to RTGWG (not routing discussion list) RIFT David Meyer: slides send questions to the GROW meeting OIF routing Lyndon Ong: there is liaison statement - need to find out relationship to get people access to it OIF has been working on E-NNI routing specification based on OSPF model for transport n/w is similar to ITU work elements grouped into domains and connected to each other through E-NNI reference points some domains may use distributed control and others may use EMS but still interface to other domains through sig + routing protocols hierarchy domains == RA (routing area) model is similar to ITU model domains may be partitioned to give mulit-level hierarchical relationship Assumptions see slide Status see slide testing at OFC in 2003 did not test any hierarchy extensions not a std solution defined as prototype for testing Rahul: concerning to see changes to OSPF without telling OSPF WG hierarchy is alarming I'm expressing concern Lyndon: recognise concern hierarchy is not simple and not something we have been testing bringing it here now Dimitri: How does this differ from CCAMP DT routing for ITU since that work follows ITU model Why take this experimental solution and not develop based on DT Lyndon: problems here are consistent w/ problems in DT difference here is that OIF has gone ahead and defined what some of these extensions might look like Russ: please give ptr to url Alex: liaison will be available Kireeti: CCAMP chair hat on worked on it for a while and bring it now say this is for testing which is good but now you have brought it to us if ask for rubber stamp won't happen but you need codepoints and we want a good relationship tell us the requirements, and we will extend since we know protocols big risk of two sets of solutions that are different compare with RSVP work where OIF/ITU work is not compatible protocols are understood here where implementers and deployers are found are you asking for rubber stamp what is end goal? Lyndon: not approved through OIF as an implementation agreement it is a draft if we can work out how to do it in OSPF then it is not too late Kireeti: do you want us to take your changes do what with them? Lyndon: oif did send a liaison asking for comment/feedback sent to ccamp chairs and routing area directors expectation is not rubber stamp expectation is that this group have a look at the problems that generated these prototype extensions hope is that these problems will be addressed through std extensions of OSPF whether the extensions change is up to this group Kireeti: would have been better to bring requirements Arthi: we can work through the problems and have solutions to them and get discussions Lyndon: work wasn't done for the sake of it people looked at specs and said "we don't know how to do something" Zafar Ali: need to understand overlap with ITU requirements follow same model Lyndon: should look for delta to ASON requirements Zafar: if so we can overlap the solution space Dimitri: how much is change to basic protocol and how much to TE LSAs? how has OIF evaluated impact analysis Lyndon: expertise for impact is in this group changes were to achieve specific functions Alex: there is concern about OSPF extensions being defined elsewhere your answer is your not trying to define a std your intention is to experiment and see what the extensions might look like your intention is to come here and work with us apology to Christophe - out of time _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Mar 12 21:36:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05708 for ; Fri, 12 Mar 2004 20:47:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yFB-0001gg-RB for routing-discussion-archive@odin.ietf.org; Fri, 12 Mar 2004 20:47:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D1lHut006483 for routing-discussion-archive@odin.ietf.org; Fri, 12 Mar 2004 20:47:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yEv-0001dv-8O; Fri, 12 Mar 2004 20:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yEm-0001df-T1 for routing-discussion@optimus.ietf.org; Fri, 12 Mar 2004 20:46:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05694 for ; Fri, 12 Mar 2004 20:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1yEk-0001ej-00 for routing-discussion@ietf.org; Fri, 12 Mar 2004 20:46:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1yDm-0001dZ-00 for routing-discussion@ietf.org; Fri, 12 Mar 2004 20:45:51 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B1yDT-0001cZ-00 for routing-discussion@ietf.org; Fri, 12 Mar 2004 20:45:31 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1yDT-000Osc-Vm for routing-discussion@ietf.org; Sat, 13 Mar 2004 01:45:32 +0000 Date: Fri, 12 Mar 2004 17:03:20 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <76235435418.20040312170320@psg.com> To: routing-discussion@ietf.org Subject: Corrected minutes for IETF59/RTG Area MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- Minutes with some corrections below. I'll see if there are any more before submitting a corrected ver to minutes@ -- Alex Intro Bill: Routing Area Web page fallen into disuse New routing area directorate folks: Dimitri, Loa New WG chairs for ISIS: Chris Hopps, Dave Ward. Thanks a lot to Tony and Tony. New routing working group (RTGWG) as catch-all for small projects Close BGMP, IDMR - Saying this for 2 years - Now date is set to wind them up (July 2004) - Real target! Create BFD WG before San Diego Create RPSEC WG especially for BGP security around October. - Requirements are coming somewhat from other SDOs. - Will take requirements from RPSEC Dave: What is the disposition of the BGMP draft? Bill: See slide later WG reports BGMP - after approval as experimental found bug. - no AS number in BGP open message, but text said to use it! - new revision planned Dave: Will we have no stds track inter-domain routing protocol for multicast? Bill: Yes, that's what it means Dave: SSM makes stds track then this means we endorse SSM as *the* multicast IDR for IPv4 Bill: Good point. But since scaling problems with one, and almost no interest in BGMP Dave: Different to say no interest in BGMP and no interest in multicast IDR Bill: But clearly no interest in scalable protocol Maybe this means there is no interest? Dave: But there is interest. And experimental protocol is deployed. Have been asking this for some time. This seems to be a statement to solve implicitly using SSM Bill: Don't think this is what we're saying. Peter: There is ASN traffic in the n/w MSDP does the job today. Has problems but not seen them. It is holding together and being used. Try to figure out the growth of MSDP in the Internet and try to predict when we will hit the problem. Someone needs to figure a protocol to address all required functions Bill: Hard to say where effort to figure out IDR multicast should go WG charter doesn't help. cf IDMR WG. Takes more than a place to do the work. Takes energy and ideas and feeling is that those aren't coming. CCAMP Adrian: No questions. IDMR Bill: Dave Thaler: what is the status of DVMRP. no security Bill: pushing for proposed std track since it has uses in certain environments IDR Yakhov: Finished base spec. Very significant. Many docs now go to IESG Can now progress other items Can now start new work - cannot pick it all up - need feedback for priority list - SPs and vendors - please input Sue: Thanks for BGP implementation reports respondents Thanks to the people who processed the 260 questions in the implementation questionnaire ISIS Alex: New co chairs for ISIS Discussion in the WG: should ISIS stds go to stds track? IGP pt-2-pt pending revision OSPF Alex: graceful restart recently approved v3 authentication and MIB update to ADs 2547 extension for loop prevention minor comments from IESG interesting discussions on mailing list: - MANET extensions - multi-address families, - multi-area adjacencies MANET Alex: DSR spec is pending update after AD review Will be making a decision wrt the direction with MANET-OSPF extensiosn RPSEC Alex: Needs more input on requirements. Please do help. Security requirements for BGP security (see previous new WG) Routing WG Alex: New WG No documents yet. Wrong! MPLS/SPF for traffic engineering - expect comments and last call soon Please subscribe to the mailing list rtgwg-request@ietf.org MPLS Loa: Had meeting Monday Most cycles on TE - P2MP - OAM framework A couple of docs about to IESG or with updates after review (7 or 8 of these) 12 docs in RFC ed queue about to be released as references are sorted out PIM Bill: Spec updated to fix a blackhole Means spec was reviewed very well! IESG in a month or so SSM Had some delay while discussing Apple's claim on IPR Believed to be resolved VRRP Bill: v2 approved v3 (IPv6) - some issues found - most resolved Routing Research charter Avri: see slides Closed groups are going to do quarterly reports to the list and an annual gathering Research proposals please - short term (for example as rejected by WG) - complete the work in 6-18 months - longer term - e.g. is there life after BGP? - e.g. routing and protocol scalability This is research so if the end result was "bad idea" this would still be good research. meeting slot planned for ietf 60 interim (co-sponsored) meeting is planned Alex: How to get onto closed mailing list? Avri Send to main list asking for "in" Alex: How do you get deliverables from a research group Avri We have to work with them to set up milestones Keep open line between rtg area and rtg working group IANA Alex: Who read the draft? About 15 ppl: not bad see slides Issue - deployment of drafts uses interim codepoints Often considerable deployments Other non-rtg similar issues. AFI/SAFI Sue: see slides Used *before* reach problem stated by Alex Kireeti wants an AFI Alex: Thanks to Kireeti for co-authoring, he wrote most of the text Bill: RFC3692 on experimental alloc suggests pick a small set and designate them for experimental alloc default behavior is non-support - needs to be turned on by operator Bob: IPv6 had discussion on ICMP codes ended up with 3 options could use extendible codes IPv6 leant towards alloc when adopted by WG - becomes permanent when RFC Need a generic way not just rtg-area Alex: that is intention Bill have you adopted any ideas? Bob: No, beginning to put language in Bill: in case of temp alloc, concern is you assign to a proposal, but WG now needs to massage packet format, but it is already deployed with a number, what do you do? new number? Bob: Up to WG chairs as per Alex What about individual submissions? Alex: This doc tries to address stds action policy not individual - would need to go through IESG Kireeti No early allocation for individual drafts Bob: Same problem for ICMP etc because this is "IESG action" Kireeti: Alex and Kireeti is stds action for early alloc Sue is talking about experimental which might go to stds track Alex: Would this be useful to IPv6 Bob: Yes WG would consider using it twiddling values in experimental by end user might be not good Kireeti: This is experimental only Bill: Would not be good for major deployment Dave: In last proposal not clear whether to assign a range but not a specific number, or if WG says specific number. Bill: RFC doesn't say Dave: Not asking about RFC. What about configurable for experimental. Is usage agree ahead of time, or is it up to the implementer to force operator to type it in? Bill: Either. must be config because it is from experimental range and someone may have conflicts Dave: Compare different proposals. like subrange == experimental Or mark as temporary out of ordinary == good because no change in implementation if no changes Bill: disadvantage if you rev or peter out. cannot reclaim until timeout Dave: Bob and Brian, 27 allocated over ten years Time limit may not be important in large space Kireeti: Not all codespaces (eg IP protocols is implicit stds action) have explicit actions associated Proposal is specifically for stds action space Need stable allocation Experimental is not a big deal if there is a change First come first served is dangerous in a different way Dave said what does one year mean when it expires? need to make this clearer. Early is in some sense temporary If spec dies it becomes "deprecated" and then time that out (e.g. RSVP case, value was not marked deprecated so IANA re-allocated) Alex: Sense of the room, about draft-kompella-zinin approach is useful? "pretty good" approach is not right? - just Kireeti ;) ditto Afi/safi useful? very few not useful? none need to ask in IDR IP/LDP loop protection Alia: see slides pre-compute an alternate path cf. IGP fast reroute questions after second presentation next hop fast re-route Naiming: see slides Yakhov: slide 3 R1 R2 is pt to pt, but suppose multiaccess media? Alia: if all nodes in same area, and R2 is the primary neighbor then R1 can assume traffic is from R2 Yakhov: If SPF takes zero time then would there be any value Alia: propagate is non zero install time is non zero Yakhov: not need to propagate to all Alia: Some cases there may be more than one router Yakhov: If only one? Alia: If more than one then it is valid Kireeti: 80% if no U-turns? Alia: 79.5 Kireeti: Real network? Alia: Yes Kireeti: U-turns in real networks? Alia: Yes Cengiz: I tried without u-turns even then in the networks I tried I had 90% Kireeti: I'm surprised that the number is so low w/o uturns because network is dense Alia: topology dependent analysis based on src/dest pairs lots of traffic not covered by loop free percentage of traffic is not same as percentage pairs Rahul: what if equal cost paths to neighbor Alia It works Rahul: R2 is PLR R1 u-turn neighbor How does R1 know where to put traffic Alia: If there is only one primary neighbor [note taker got confused ....] Rahul: when I said doesn't work I meant reduces Alia: never reduces below loop free w/out utirn Yakhov: Covers node failure? Alia: Yes Ina???? Deployment considerations in n/w Alia: Need to support IGP extensions for u-turn ??? How fast Alia: depends on h/w per interface forwarding table Kireeti: What effect on the size of the routing table A Forwarding table not routing table Kireeti: bad? Alia: Not as bad as one per i/f since max two Kireeti: has naiming done coverage? Alex: take discussion to RTGWG (not routing discussion list) RIFT David Meyer: slides send questions to the GROW meeting OIF routing Lyndon Ong: there is liaison statement - need to find out relationship to get people access to it OIF has been working on E-NNI routing specification based on OSPF model for transport n/w is similar to ITU work elements grouped into domains and connected to each other through E-NNI reference points some domains may use distributed control and others may use EMS but still interface to other domains through sig + routing protocols hierarchy domains == RA (routing area) model is similar to ITU model domains may be partitioned to give mulit-level hierarchical relationship Assumptions see slide Status see slide testing at OFC in 2003 did not test any hierarchy extensions not a std solution defined as prototype for testing Rahul: concerning to see changes to OSPF without telling OSPF WG hierarchy is alarming I'm expressing concern Lyndon: recognise concern hierarchy is not simple and not something we have been testing bringing it here now Dimitri: How does this differ from CCAMP DT routing for ITU since that work follows ITU model Why take this experimental solution and not develop based on DT Lyndon: problems here are consistent w/ problems in DT difference here is that OIF has gone ahead and defined what some of these extensions might look like Russ: please give ptr to url Alex: liaison will be available Kireeti: CCAMP chair hat on worked on it for a while and bring it now say this is for testing which is good but now you have brought it to us if ask for rubber stamp won't happen but you need codepoints and we want a good relationship tell us the requirements, and we will extend since we know protocols big risk of two sets of solutions that are different compare with RSVP work where OIF/ITU work is not compatible protocols are understood here where implementers and deployers are found are you asking for rubber stamp what is end goal? Lyndon: not approved through OIF as an implementation agreement it is a draft if we can work out how to do it in OSPF then it is not too late Kireeti: do you want us to take your changes do what with them? Lyndon: oif did send a liaison asking for comment/feedback sent to ccamp chairs and routing area directors expectation is not rubber stamp expectation is that this group have a look at the problems that generated these prototype extensions hope is that these problems will be addressed through std extensions of OSPF whether the extensions change is up to this group Kireeti: would have been better to bring requirements Arthi: we can work through the problems and have solutions to them and get discussions Lyndon: work wasn't done for the sake of it people looked at specs and said "we don't know how to do something" Zafar Ali: need to understand overlap with ITU requirements follow same model Lyndon: should look for delta to ASON requirements Zafar: if so we can overlap the solution space Dimitri: how much is change to basic protocol and how much to TE LSAs? how has OIF evaluated impact analysis Lyndon: expertise for impact is in this group changes were to achieve specific functions Alex: there is concern about OSPF extensions being defined elsewhere your answer is your not trying to define a std your intention is to experiment and see what the extensions might look like your intention is to come here and work with us apology to Christophe - out of time _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 19 04:48:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24809 for ; Fri, 19 Mar 2004 04:48:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gbi-000451-2Q; Fri, 19 Mar 2004 04:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gam-00043N-4p for routing-discussion@optimus.ietf.org; Fri, 19 Mar 2004 04:47:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24761 for ; Fri, 19 Mar 2004 04:47:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Gaj-0004Kk-00 for routing-discussion@ietf.org; Fri, 19 Mar 2004 04:47:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4GZw-0004H1-00 for routing-discussion@ietf.org; Fri, 19 Mar 2004 04:46:13 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1B4GZ8-0004By-00 for routing-discussion@ietf.org; Fri, 19 Mar 2004 04:45:23 -0500 Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 Mar 2004 10:45:22 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40D96.E5C5B555" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Slides of a presentation planned during rtgarea meeting at IETF 59 Date: Fri, 19 Mar 2004 10:45:22 +0100 Message-ID: <57F140DC5CDA10438C41674629DE0D8701A50D10@parmhs4.rd.francetelecom.fr> Thread-Topic: Slides of a presentation planned during rtgarea meeting at IETF 59 Thread-Index: AcQNluTYBn3SqgjsS0GV9M3UdW2ZdQ== From: "PROUST Christophe FTRD/DMI/CAE" To: X-OriginalArrivalTime: 19 Mar 2004 09:45:22.0668 (UTC) FILETIME=[E5E852C0:01C40D96] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C40D96.E5C5B555 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all,=20 Thanks for your attention, I put the slides of the presentation that I had planned to present=20 during the rtgarea meeting at the last IETF meeting in Korea,=20 but due to lack of time my presentation had to be finally cancelled. The slides quickly explain the basic ideas contained in the draft entitled draft-proust-flow-routing-00.txt upon which an architecture for flow routing is elaborated. =09 If you want to have a look at it, please do so,=20 the slides are available at this web page: http://perso.wanadoo.fr/proustc/index.html If you could give me some feedback I would appreciate,=20 =09 Thank you ! Christophe ------_=_NextPart_001_01C40D96.E5C5B555 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Slides of a presentation planned during rtgarea meeting at IETF = 59

        Dear all,

        Thanks for your attention, I put the slides of the = presentation that I had planned to present
        during the rtgarea meeting at the last IETF meeting in = Korea,
        but due to lack of time my presentation had to be finally = cancelled.
        The slides quickly explain the basic ideas contained in = the draft entitled
        draft-proust-flow-routing-00.txt upon which an = architecture for flow routing is elaborated.
       =20
        If you want to have a look at it, please do so,
        the slides are available at this web page: http://perso.wanadoo.fr/proustc/index.html

        If you could give me some feedback I would appreciate, =
       =20
        Thank you !

        Christophe

------_=_NextPart_001_01C40D96.E5C5B555-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Mar 19 04:48:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24811 for ; Fri, 19 Mar 2004 04:48:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gby-00045d-GX for routing-discussion-archive@odin.ietf.org; Fri, 19 Mar 2004 04:48:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J9mICi015720 for routing-discussion-archive@odin.ietf.org; Fri, 19 Mar 2004 04:48:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gbi-000451-2Q; Fri, 19 Mar 2004 04:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Gam-00043N-4p for routing-discussion@optimus.ietf.org; Fri, 19 Mar 2004 04:47:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24761 for ; Fri, 19 Mar 2004 04:47:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Gaj-0004Kk-00 for routing-discussion@ietf.org; Fri, 19 Mar 2004 04:47:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4GZw-0004H1-00 for routing-discussion@ietf.org; Fri, 19 Mar 2004 04:46:13 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1B4GZ8-0004By-00 for routing-discussion@ietf.org; Fri, 19 Mar 2004 04:45:23 -0500 Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 Mar 2004 10:45:22 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40D96.E5C5B555" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Slides of a presentation planned during rtgarea meeting at IETF 59 Date: Fri, 19 Mar 2004 10:45:22 +0100 Message-ID: <57F140DC5CDA10438C41674629DE0D8701A50D10@parmhs4.rd.francetelecom.fr> Thread-Topic: Slides of a presentation planned during rtgarea meeting at IETF 59 Thread-Index: AcQNluTYBn3SqgjsS0GV9M3UdW2ZdQ== From: "PROUST Christophe FTRD/DMI/CAE" To: X-OriginalArrivalTime: 19 Mar 2004 09:45:22.0668 (UTC) FILETIME=[E5E852C0:01C40D96] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C40D96.E5C5B555 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all,=20 Thanks for your attention, I put the slides of the presentation that I had planned to present=20 during the rtgarea meeting at the last IETF meeting in Korea,=20 but due to lack of time my presentation had to be finally cancelled. The slides quickly explain the basic ideas contained in the draft entitled draft-proust-flow-routing-00.txt upon which an architecture for flow routing is elaborated. =09 If you want to have a look at it, please do so,=20 the slides are available at this web page: http://perso.wanadoo.fr/proustc/index.html If you could give me some feedback I would appreciate,=20 =09 Thank you ! Christophe ------_=_NextPart_001_01C40D96.E5C5B555 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Slides of a presentation planned during rtgarea meeting at IETF = 59

        Dear all,

        Thanks for your attention, I put the slides of the = presentation that I had planned to present
        during the rtgarea meeting at the last IETF meeting in = Korea,
        but due to lack of time my presentation had to be finally = cancelled.
        The slides quickly explain the basic ideas contained in = the draft entitled
        draft-proust-flow-routing-00.txt upon which an = architecture for flow routing is elaborated.
       =20
        If you want to have a look at it, please do so,
        the slides are available at this web page: http://perso.wanadoo.fr/proustc/index.html

        If you could give me some feedback I would appreciate, =
       =20
        Thank you !

        Christophe

------_=_NextPart_001_01C40D96.E5C5B555-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 14:23:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19453 for ; Tue, 23 Mar 2004 14:23:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rTN-0000tk-61; Tue, 23 Mar 2004 14:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rSn-0000ol-0e for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 14:21:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19241 for ; Tue, 23 Mar 2004 14:21:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rSk-0003dX-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:21:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rRm-0003Yt-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:20:23 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B5rQp-0003SZ-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:19:23 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i2NJIkl28733; Tue, 23 Mar 2004 11:18:47 -0800 (PST) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2NJIfJ32214; Tue, 23 Mar 2004 11:18:41 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200403231918.i2NJIfJ32214@merlot.juniper.net> To: eckert@cisco.com cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com, pusateri@juniper.net Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message from eckert@cisco.com of "Tue, 23 Mar 2004 09:42:03 PST." <20040323174203.GW17887@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <66329.1080069521.1@juniper.net> Date: Tue, 23 Mar 2004 11:18:41 -0800 From: Tom Pusateri X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , In message <20040323174203.GW17887@cisco.com> you write: >I was told that in the routing area meeting of the 59th ietf, >it was declared that BGMP will go to experimental and DVMRP to PS. > >I was wondering what kind of discussion has preceeded these >decisions, as and what the large group of people is that is in >agreement with it. > >As for me, i would strongly suggest to make BGMP today informational >and DVMRP historic: > >I don't think there's sufficient proof that the IETF wants for the >model proposed by BGMP to be the standard solution for interdomain >ASM, nor do i see any real activity in taking BGMP from powerpoint >to the real world (*oops*, from drafts to routers). As far as DVMRP >is concerned, i think it should be classified historic because >it violates what i would consider to be the most fundamental Internet >IP multicast routing architecture principle: Separation/independence >of RPF and tree building. > >Cheers > Toerless Each routing protocol submitted as a proposed standard has an applicability statement describing its use. While you may not use DVMRP for global multicast, it is a viable alternative in certain cases. Therefore, there is no reason not to move it forward as a proposed standard as long as the areas where it is applicable are specified. Now, as for "the most fundamental Internet IP multicast routing architecture principle: Separation/independence of RPF and tree building", this has caused as many problems as it has solved so I wouldn't be waving this flag... Tom _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 14:23:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19470 for ; Tue, 23 Mar 2004 14:23:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rU0-0000zu-0F for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 14:22:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NJMdc7003757 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 14:22:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rTN-0000tk-61; Tue, 23 Mar 2004 14:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rSn-0000ol-0e for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 14:21:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19241 for ; Tue, 23 Mar 2004 14:21:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rSk-0003dX-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:21:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rRm-0003Yt-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:20:23 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B5rQp-0003SZ-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:19:23 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i2NJIkl28733; Tue, 23 Mar 2004 11:18:47 -0800 (PST) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2NJIfJ32214; Tue, 23 Mar 2004 11:18:41 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200403231918.i2NJIfJ32214@merlot.juniper.net> To: eckert@cisco.com cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com, pusateri@juniper.net Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message from eckert@cisco.com of "Tue, 23 Mar 2004 09:42:03 PST." <20040323174203.GW17887@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <66329.1080069521.1@juniper.net> Date: Tue, 23 Mar 2004 11:18:41 -0800 From: Tom Pusateri X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , In message <20040323174203.GW17887@cisco.com> you write: >I was told that in the routing area meeting of the 59th ietf, >it was declared that BGMP will go to experimental and DVMRP to PS. > >I was wondering what kind of discussion has preceeded these >decisions, as and what the large group of people is that is in >agreement with it. > >As for me, i would strongly suggest to make BGMP today informational >and DVMRP historic: > >I don't think there's sufficient proof that the IETF wants for the >model proposed by BGMP to be the standard solution for interdomain >ASM, nor do i see any real activity in taking BGMP from powerpoint >to the real world (*oops*, from drafts to routers). As far as DVMRP >is concerned, i think it should be classified historic because >it violates what i would consider to be the most fundamental Internet >IP multicast routing architecture principle: Separation/independence >of RPF and tree building. > >Cheers > Toerless Each routing protocol submitted as a proposed standard has an applicability statement describing its use. While you may not use DVMRP for global multicast, it is a viable alternative in certain cases. Therefore, there is no reason not to move it forward as a proposed standard as long as the areas where it is applicable are specified. Now, as for "the most fundamental Internet IP multicast routing architecture principle: Separation/independence of RPF and tree building", this has caused as many problems as it has solved so I wouldn't be waving this flag... Tom _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 14:32:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20146 for ; Tue, 23 Mar 2004 14:32:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rd7-0001wz-HE for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 14:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NJW5lI007428 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 14:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rd3-0001sM-Cb; Tue, 23 Mar 2004 14:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rcY-0001ma-9u for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 14:31:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20044 for ; Tue, 23 Mar 2004 14:31:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rcV-0004ao-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:31:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rba-0004Vz-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:30:31 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rai-0004Nf-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:29:36 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2NJSt912206; Tue, 23 Mar 2004 21:28:55 +0200 Date: Tue, 23 Mar 2004 21:28:55 +0200 (EET) From: Pekka Savola To: Tom Pusateri cc: eckert@cisco.com, , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403231918.i2NJIfJ32214@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, 23 Mar 2004, Tom Pusateri wrote: > Each routing protocol submitted as a proposed standard has an > applicability statement describing its use. While you may not use > DVMRP for global multicast, it is a viable alternative in certain > cases. > > Therefore, there is no reason not to move it forward as a proposed > standard as long as the areas where it is applicable are specified. I'd argue for moving it to Informational, and placing a strong disclaimer in the spec itself. We can achieve interoperability and deployment in those specific cases without going to standards track; IMHO, Informational would send the correct signal to the IETF and the community about the "applicability" (or lack thereof) of the protocol in general. FWIW, BGMP should also be Informational. It's useful to document it, but again, it needs stronger disclaimers so that folks don't think it's actually useful as specified. I'll certainly raise these issues in the appropriate Last Calls or other fora when given a chanche if the PS + Exp line continues.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 14:45:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20847 for ; Tue, 23 Mar 2004 14:45:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rpg-0003E2-2N; Tue, 23 Mar 2004 14:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rkR-0002sO-Fm for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 14:39:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20479 for ; Tue, 23 Mar 2004 14:39:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rkO-0005Fa-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:39:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rji-0005BD-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:38:54 -0500 Received: from mail-dark.research.att.com ([192.20.225.112]) by ietf-mx with esmtp (Exim 4.12) id 1B5rj1-000553-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:38:11 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-dark.research.att.com (Postfix) with ESMTP id 8C981E80EB; Tue, 23 Mar 2004 14:37:41 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 7C30EF3A9C; Tue, 23 Mar 2004 14:37:41 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i2NJbeb10375; Tue, 23 Mar 2004 11:37:40 -0800 (PST) Message-Id: <200403231937.i2NJbeb10375@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Date: Tue, 23 Mar 2004 11:37:39 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >I was wondering what kind of discussion has preceeded these >decisions, as and what the large group of people is that is in >agreement with it. The BGMP status was a bug in the presentation; it is indeed planning to go to Informational (although the only feedback on the BGMP WG mailing list was that it should go Experimental instead). The DVMRP status discussion happened on the IDMR WG list. As far as I know, nothing has changed about DVMRP being an acceptable routing protocol for small networks. It achieves not insignificant optimization by combining tree buidling and route dissemination. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 15:11:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23669 for ; Tue, 23 Mar 2004 15:11:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sEJ-0004oi-3h; Tue, 23 Mar 2004 15:10:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5pww-0007KY-31 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 12:44:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14478 for ; Tue, 23 Mar 2004 12:44:22 -0500 (EST) From: eckert@cisco.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5pwu-0004fp-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 12:44:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5pw6-0004cz-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 12:43:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B5pvB-0004Xe-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 12:42:37 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 23 Mar 2004 09:42:24 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2NHg4aD018466; Tue, 23 Mar 2004 09:42:04 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA29076; Tue, 23 Mar 2004 09:42:03 -0800 (PST) Date: Tue, 23 Mar 2004 09:42:03 -0800 To: routing-discussion@ietf.org Cc: mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: BGMP & DVMRP status Q. Message-ID: <20040323174203.GW17887@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , I was told that in the routing area meeting of the 59th ietf, it was declared that BGMP will go to experimental and DVMRP to PS. I was wondering what kind of discussion has preceeded these decisions, as and what the large group of people is that is in agreement with it. As for me, i would strongly suggest to make BGMP today informational and DVMRP historic: I don't think there's sufficient proof that the IETF wants for the model proposed by BGMP to be the standard solution for interdomain ASM, nor do i see any real activity in taking BGMP from powerpoint to the real world (*oops*, from drafts to routers). As far as DVMRP is concerned, i think it should be classified historic because it violates what i would consider to be the most fundamental Internet IP multicast routing architecture principle: Separation/independence of RPF and tree building. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 15:11:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23681 for ; Tue, 23 Mar 2004 15:11:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sEU-0004yn-6V for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 15:10:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NKAf8r019007 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 15:10:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sEJ-0004oi-3h; Tue, 23 Mar 2004 15:10:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5pww-0007KY-31 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 12:44:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14478 for ; Tue, 23 Mar 2004 12:44:22 -0500 (EST) From: eckert@cisco.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5pwu-0004fp-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 12:44:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5pw6-0004cz-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 12:43:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B5pvB-0004Xe-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 12:42:37 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 23 Mar 2004 09:42:24 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2NHg4aD018466; Tue, 23 Mar 2004 09:42:04 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA29076; Tue, 23 Mar 2004 09:42:03 -0800 (PST) Date: Tue, 23 Mar 2004 09:42:03 -0800 To: routing-discussion@ietf.org Cc: mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: BGMP & DVMRP status Q. Message-ID: <20040323174203.GW17887@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , I was told that in the routing area meeting of the 59th ietf, it was declared that BGMP will go to experimental and DVMRP to PS. I was wondering what kind of discussion has preceeded these decisions, as and what the large group of people is that is in agreement with it. As for me, i would strongly suggest to make BGMP today informational and DVMRP historic: I don't think there's sufficient proof that the IETF wants for the model proposed by BGMP to be the standard solution for interdomain ASM, nor do i see any real activity in taking BGMP from powerpoint to the real world (*oops*, from drafts to routers). As far as DVMRP is concerned, i think it should be classified historic because it violates what i would consider to be the most fundamental Internet IP multicast routing architecture principle: Separation/independence of RPF and tree building. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 15:14:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24225 for ; Tue, 23 Mar 2004 15:14:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sHh-0006Ry-Be; Tue, 23 Mar 2004 15:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sHD-0006KU-51 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:13:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24125 for ; Tue, 23 Mar 2004 15:13:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sHB-0001p2-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:13:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5sGT-0001kX-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:12:46 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5sFj-0001Xt-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:11:59 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2NKBQwx004944; Tue, 23 Mar 2004 12:11:26 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i2NKBQ4t004943; Tue, 23 Mar 2004 12:11:26 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 23 Mar 2004 12:11:26 -0800 From: David Meyer To: eckert@cisco.com Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323201126.GA4507@1-4-5.net> References: <20040323174203.GW17887@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040323174203.GW17887@cisco.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 09:42:03AM -0800, eckert@cisco.com wrote: >> I was told that in the routing area meeting of the 59th ietf, >> it was declared that BGMP will go to experimental and DVMRP to PS. >> >> I was wondering what kind of discussion has preceeded these >> decisions, as and what the large group of people is that is in >> agreement with it. >> >> As for me, i would strongly suggest to make BGMP today informational >> and DVMRP historic: >> >> I don't think there's sufficient proof that the IETF wants for the >> model proposed by BGMP to be the standard solution for interdomain >> ASM, nor do i see any real activity in taking BGMP from powerpoint >> to the real world (*oops*, from drafts to routers). As far as DVMRP >> is concerned, i think it should be classified historic because >> it violates what i would consider to be the most fundamental Internet >> IP multicast routing architecture principle: Separation/independence >> of RPF and tree building. >> Regarding BGMP: It is not that advancing BGMP to Experimental is in and of itself problematic; in fact, this seems completely reasonable and is arguably consistent with what it means to advance to Experimental. Rather, my concern is the around implicit statement the IETF is making by taking both of the IPv4 ASM candidate protocols (MSDP and BGMP) to Experimental and SSM to PS. Just to be very clear here, taking SSM to PS is again completely reasonable. My concern, however, is whether the combination of these actions implicitly states something like "inter-domain IPv4 ASM isn't an IETF standards track activity". The reasoning might go something like "What does the IETF have on standards track for inter-domain ASM...?" (well, nothing), and go from there. Of course, one might argue that bidir is the eventual solution here, and hence "someday" this argument will be moot. So one of the problems here, as Bill correctly pointed out, is that we don't have anyone working on an alternative (and that this can be taken as a measure of the interest in a hypothetical alternate IPv4 inter-domain ASM protocol). It might also be taken as a statement like "MSDP works well enough"...but then why don't we put MSDP on standards track? Well, other than that no one likes its architecture, etc. Summary ------ It is the statement potentially implied by our classification of the various protocols described above which is of concern. In particular, it doesn't seem outside the realm of possibility for one to conclude that inter-domain ASM isn't an IETF standards track activity (which of course, mod some future event with bidir, it currently is not). However, it would seem clear that this not our intended statement. This, combined with the fact such a conclusion would not reflect deployment practices in the IPv4 Internet, is what I find troubling. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 15:14:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24226 for ; Tue, 23 Mar 2004 15:14:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sHl-0006Wi-W7 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 15:14:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NKE5Xa025071 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 15:14:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sHh-0006Ry-Be; Tue, 23 Mar 2004 15:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sHD-0006KU-51 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:13:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24125 for ; Tue, 23 Mar 2004 15:13:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sHB-0001p2-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:13:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5sGT-0001kX-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:12:46 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5sFj-0001Xt-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:11:59 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2NKBQwx004944; Tue, 23 Mar 2004 12:11:26 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i2NKBQ4t004943; Tue, 23 Mar 2004 12:11:26 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 23 Mar 2004 12:11:26 -0800 From: David Meyer To: eckert@cisco.com Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323201126.GA4507@1-4-5.net> References: <20040323174203.GW17887@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040323174203.GW17887@cisco.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 09:42:03AM -0800, eckert@cisco.com wrote: >> I was told that in the routing area meeting of the 59th ietf, >> it was declared that BGMP will go to experimental and DVMRP to PS. >> >> I was wondering what kind of discussion has preceeded these >> decisions, as and what the large group of people is that is in >> agreement with it. >> >> As for me, i would strongly suggest to make BGMP today informational >> and DVMRP historic: >> >> I don't think there's sufficient proof that the IETF wants for the >> model proposed by BGMP to be the standard solution for interdomain >> ASM, nor do i see any real activity in taking BGMP from powerpoint >> to the real world (*oops*, from drafts to routers). As far as DVMRP >> is concerned, i think it should be classified historic because >> it violates what i would consider to be the most fundamental Internet >> IP multicast routing architecture principle: Separation/independence >> of RPF and tree building. >> Regarding BGMP: It is not that advancing BGMP to Experimental is in and of itself problematic; in fact, this seems completely reasonable and is arguably consistent with what it means to advance to Experimental. Rather, my concern is the around implicit statement the IETF is making by taking both of the IPv4 ASM candidate protocols (MSDP and BGMP) to Experimental and SSM to PS. Just to be very clear here, taking SSM to PS is again completely reasonable. My concern, however, is whether the combination of these actions implicitly states something like "inter-domain IPv4 ASM isn't an IETF standards track activity". The reasoning might go something like "What does the IETF have on standards track for inter-domain ASM...?" (well, nothing), and go from there. Of course, one might argue that bidir is the eventual solution here, and hence "someday" this argument will be moot. So one of the problems here, as Bill correctly pointed out, is that we don't have anyone working on an alternative (and that this can be taken as a measure of the interest in a hypothetical alternate IPv4 inter-domain ASM protocol). It might also be taken as a statement like "MSDP works well enough"...but then why don't we put MSDP on standards track? Well, other than that no one likes its architecture, etc. Summary ------ It is the statement potentially implied by our classification of the various protocols described above which is of concern. In particular, it doesn't seem outside the realm of possibility for one to conclude that inter-domain ASM isn't an IETF standards track activity (which of course, mod some future event with bidir, it currently is not). However, it would seem clear that this not our intended statement. This, combined with the fact such a conclusion would not reflect deployment practices in the IPv4 Internet, is what I find troubling. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 15:18:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20145 for ; Tue, 23 Mar 2004 14:32:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rd3-0001sM-Cb; Tue, 23 Mar 2004 14:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rcY-0001ma-9u for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 14:31:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20044 for ; Tue, 23 Mar 2004 14:31:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rcV-0004ao-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:31:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rba-0004Vz-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:30:31 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rai-0004Nf-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:29:36 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2NJSt912206; Tue, 23 Mar 2004 21:28:55 +0200 Date: Tue, 23 Mar 2004 21:28:55 +0200 (EET) From: Pekka Savola To: Tom Pusateri cc: eckert@cisco.com, , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403231918.i2NJIfJ32214@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, 23 Mar 2004, Tom Pusateri wrote: > Each routing protocol submitted as a proposed standard has an > applicability statement describing its use. While you may not use > DVMRP for global multicast, it is a viable alternative in certain > cases. > > Therefore, there is no reason not to move it forward as a proposed > standard as long as the areas where it is applicable are specified. I'd argue for moving it to Informational, and placing a strong disclaimer in the spec itself. We can achieve interoperability and deployment in those specific cases without going to standards track; IMHO, Informational would send the correct signal to the IETF and the community about the "applicability" (or lack thereof) of the protocol in general. FWIW, BGMP should also be Informational. It's useful to document it, but again, it needs stronger disclaimers so that folks don't think it's actually useful as specified. I'll certainly raise these issues in the appropriate Last Calls or other fora when given a chanche if the PS + Exp line continues.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 15:33:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20849 for ; Tue, 23 Mar 2004 14:45:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rpu-0003Km-0q for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 14:45:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NJjHYq012739 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 14:45:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rpg-0003E2-2N; Tue, 23 Mar 2004 14:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rkR-0002sO-Fm for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 14:39:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20479 for ; Tue, 23 Mar 2004 14:39:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rkO-0005Fa-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:39:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rji-0005BD-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:38:54 -0500 Received: from mail-dark.research.att.com ([192.20.225.112]) by ietf-mx with esmtp (Exim 4.12) id 1B5rj1-000553-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 14:38:11 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-dark.research.att.com (Postfix) with ESMTP id 8C981E80EB; Tue, 23 Mar 2004 14:37:41 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 7C30EF3A9C; Tue, 23 Mar 2004 14:37:41 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i2NJbeb10375; Tue, 23 Mar 2004 11:37:40 -0800 (PST) Message-Id: <200403231937.i2NJbeb10375@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Date: Tue, 23 Mar 2004 11:37:39 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >I was wondering what kind of discussion has preceeded these >decisions, as and what the large group of people is that is in >agreement with it. The BGMP status was a bug in the presentation; it is indeed planning to go to Informational (although the only feedback on the BGMP WG mailing list was that it should go Experimental instead). The DVMRP status discussion happened on the IDMR WG list. As far as I know, nothing has changed about DVMRP being an acceptable routing protocol for small networks. It achieves not insignificant optimization by combining tree buidling and route dissemination. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 15:39:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26331 for ; Tue, 23 Mar 2004 15:39:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sfs-00027o-Js; Tue, 23 Mar 2004 15:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sfC-000243-B6 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:38:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26272 for ; Tue, 23 Mar 2004 15:38:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sfA-00045T-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:38:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5seF-0003wI-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:37:19 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B5scz-0003ik-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:36:01 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i2NKZPl29088; Tue, 23 Mar 2004 12:35:25 -0800 (PST) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2NKZKJ42048; Tue, 23 Mar 2004 12:35:20 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200403232035.i2NKZKJ42048@merlot.juniper.net> To: David Meyer cc: eckert@cisco.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com, pusateri@juniper.net Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message from David Meyer of "Tue, 23 Mar 2004 12:11:26 PST." <20040323201126.GA4507@1-4-5.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94489.1080074119.1@juniper.net> Date: Tue, 23 Mar 2004 12:35:19 -0800 From: Tom Pusateri X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , In message <20040323201126.GA4507@1-4-5.net> you write: > > Summary > ------ > It is the statement potentially implied by our > classification of the various protocols described above > which is of concern. In particular, it doesn't seem > outside the realm of possibility for one to conclude that > inter-domain ASM isn't an IETF standards track activity > (which of course, mod some future event with bidir, it > currently is not). However, it would seem clear that this > not our intended statement. This, combined with the fact > such a conclusion would not reflect deployment practices > in the IPv4 Internet, is what I find troubling. > > Dave I don't think we should worry about what we "imply". Each protocol should be moved forward according to the best information we have available without unnecesary delay. If someone wants to waste their time making inferences from the combination of these actions then so be it but it certainly should not concern us. Tom _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 15:39:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26344 for ; Tue, 23 Mar 2004 15:39:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sgL-00029I-6M for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 15:39:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NKdTsK008226 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 15:39:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sfs-00027o-Js; Tue, 23 Mar 2004 15:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sfC-000243-B6 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:38:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26272 for ; Tue, 23 Mar 2004 15:38:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sfA-00045T-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:38:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5seF-0003wI-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:37:19 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B5scz-0003ik-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:36:01 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i2NKZPl29088; Tue, 23 Mar 2004 12:35:25 -0800 (PST) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2NKZKJ42048; Tue, 23 Mar 2004 12:35:20 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200403232035.i2NKZKJ42048@merlot.juniper.net> To: David Meyer cc: eckert@cisco.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com, pusateri@juniper.net Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message from David Meyer of "Tue, 23 Mar 2004 12:11:26 PST." <20040323201126.GA4507@1-4-5.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94489.1080074119.1@juniper.net> Date: Tue, 23 Mar 2004 12:35:19 -0800 From: Tom Pusateri X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , In message <20040323201126.GA4507@1-4-5.net> you write: > > Summary > ------ > It is the statement potentially implied by our > classification of the various protocols described above > which is of concern. In particular, it doesn't seem > outside the realm of possibility for one to conclude that > inter-domain ASM isn't an IETF standards track activity > (which of course, mod some future event with bidir, it > currently is not). However, it would seem clear that this > not our intended statement. This, combined with the fact > such a conclusion would not reflect deployment practices > in the IPv4 Internet, is what I find troubling. > > Dave I don't think we should worry about what we "imply". Each protocol should be moved forward according to the best information we have available without unnecesary delay. If someone wants to waste their time making inferences from the combination of these actions then so be it but it certainly should not concern us. Tom _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 16:03:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28771 for ; Tue, 23 Mar 2004 16:03:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5t37-0005se-36; Tue, 23 Mar 2004 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5t2o-0005rr-42 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:02:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28725 for ; Tue, 23 Mar 2004 16:02:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5t2m-0007BB-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:02:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5t1s-00076y-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:01:45 -0500 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5t1Q-00071D-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:01:16 -0500 Received: from sith.maoz.com (localhost.localdomain [127.0.0.1]) by sith.maoz.com (8.12.11/8.12.11) with ESMTP id i2NL0hRn001328; Tue, 23 Mar 2004 13:00:43 -0800 Received: (from jhall@localhost) by sith.maoz.com (8.12.11/8.12.8/Submit) id i2NL0hdW001327; Tue, 23 Mar 2004 16:00:43 -0500 From: Jeremy Hall Message-Id: <200403232100.i2NL0hdW001327@sith.maoz.com> Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <20040323204924.GL17887@cisco.com> from Toerless Eckert at "Mar 23, 2004 12:49:24 pm" To: Toerless Eckert Date: Tue, 23 Mar 2004 16:00:43 -0500 (EST) CC: Jeremy Hall , David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In the new year, Toerless Eckert wrote: > On Tue, Mar 23, 2004 at 03:39:56PM -0500, Jeremy Hall wrote: > > If we are using MSDP as "the official method" of ASM interdomain > > controlling, then the IETF status should reflect that. It's confusing > > enough to have all the multicast protocols in their various status, but as > > it is now, you have to have history in running the stuff to be able to > > successfully deploy it, or in the least, have a mentor that can point you > > in the right direction. What is wrong other than philosophical scaling > > issues with making the status of the protocols consistent with what is > > deployed? > > Other question: How would changing the IETF status of the documents > improve on the chance of getting working IP multicast deployment. > Eg: Almost all of the protocol specs are everything but helpful to > understand the challenges of IP multicast deployment. > If we make it clear what is useful, but not relevant to current deployment, new implementors will have an easier time deciding what exactly to implement and how to make that happen. With more vendors coming online WRT multicast, the more likelihood the code will be present on day 1 when a new router vendor is deployed into the industry. _J > Cheers > Toerless > _______________________________________________________________ > user interface: http://darkwing.uoregon.edu/~llynch/mboned.html > web archive: http://darkwing.uoregon.edu/~llynch/mboned/ > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 16:03:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28773 for ; Tue, 23 Mar 2004 16:03:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5t3C-0005tl-QB for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:03:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NL36KT022673 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:03:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5t37-0005se-36; Tue, 23 Mar 2004 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5t2o-0005rr-42 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:02:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28725 for ; Tue, 23 Mar 2004 16:02:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5t2m-0007BB-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:02:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5t1s-00076y-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:01:45 -0500 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5t1Q-00071D-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:01:16 -0500 Received: from sith.maoz.com (localhost.localdomain [127.0.0.1]) by sith.maoz.com (8.12.11/8.12.11) with ESMTP id i2NL0hRn001328; Tue, 23 Mar 2004 13:00:43 -0800 Received: (from jhall@localhost) by sith.maoz.com (8.12.11/8.12.8/Submit) id i2NL0hdW001327; Tue, 23 Mar 2004 16:00:43 -0500 From: Jeremy Hall Message-Id: <200403232100.i2NL0hdW001327@sith.maoz.com> Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <20040323204924.GL17887@cisco.com> from Toerless Eckert at "Mar 23, 2004 12:49:24 pm" To: Toerless Eckert Date: Tue, 23 Mar 2004 16:00:43 -0500 (EST) CC: Jeremy Hall , David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In the new year, Toerless Eckert wrote: > On Tue, Mar 23, 2004 at 03:39:56PM -0500, Jeremy Hall wrote: > > If we are using MSDP as "the official method" of ASM interdomain > > controlling, then the IETF status should reflect that. It's confusing > > enough to have all the multicast protocols in their various status, but as > > it is now, you have to have history in running the stuff to be able to > > successfully deploy it, or in the least, have a mentor that can point you > > in the right direction. What is wrong other than philosophical scaling > > issues with making the status of the protocols consistent with what is > > deployed? > > Other question: How would changing the IETF status of the documents > improve on the chance of getting working IP multicast deployment. > Eg: Almost all of the protocol specs are everything but helpful to > understand the challenges of IP multicast deployment. > If we make it clear what is useful, but not relevant to current deployment, new implementors will have an easier time deciding what exactly to implement and how to make that happen. With more vendors coming online WRT multicast, the more likelihood the code will be present on day 1 when a new router vendor is deployed into the industry. _J > Cheers > Toerless > _______________________________________________________________ > user interface: http://darkwing.uoregon.edu/~llynch/mboned.html > web archive: http://darkwing.uoregon.edu/~llynch/mboned/ > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 16:05:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29126 for ; Tue, 23 Mar 2004 16:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5t54-0006AZ-DJ for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:05:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NL52Ss023709 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5t53-00069e-Qt; Tue, 23 Mar 2004 16:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5t4w-00068d-Er for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:04:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29047 for ; Tue, 23 Mar 2004 16:04:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5t4u-0007R1-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:04:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5t3n-0007It-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:03:44 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5t3P-0007Cx-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:03:20 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2NL2klw005761; Tue, 23 Mar 2004 13:02:46 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i2NL2kDF005760; Tue, 23 Mar 2004 13:02:46 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 23 Mar 2004 13:02:46 -0800 From: David Meyer To: Tom Pusateri Cc: eckert@cisco.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323210246.GA5582@1-4-5.net> References: <20040323201126.GA4507@1-4-5.net> <200403232035.i2NKZKJ42048@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232035.i2NKZKJ42048@merlot.juniper.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 12:35:19PM -0800, Tom Pusateri wrote: >> In message <20040323201126.GA4507@1-4-5.net> you write: >> > >> > Summary >> > ------ >> > It is the statement potentially implied by our >> > classification of the various protocols described above >> > which is of concern. In particular, it doesn't seem >> > outside the realm of possibility for one to conclude that >> > inter-domain ASM isn't an IETF standards track activity >> > (which of course, mod some future event with bidir, it >> > currently is not). However, it would seem clear that this >> > not our intended statement. This, combined with the fact >> > such a conclusion would not reflect deployment practices >> > in the IPv4 Internet, is what I find troubling. >> > >> > Dave >> Tom, >> I don't think we should worry about what we "imply". Each protocol >> should be moved forward according to the best information we have >> available without unnecesary delay. With regard to the latter statement, no disagreement (and FWIW, I didn't take anything said in this thread as suggesting anything should be unnecessarily delayed). >> If someone wants to waste their time making inferences from >> the combination of these actions then so be it but it >> certainly should not concern us. Understand. The implication thing just occurred to me during the open routing area meeting, and so I thought I might recount it here. Basically, since I try to take a system-wide view of what the IETF does (both in terms of its technology, as well as its process), occasionally things like this turn up. In any event, if it is all a non-issue, so much the better. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 16:14:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29917 for ; Tue, 23 Mar 2004 16:14:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tDl-00078s-6A; Tue, 23 Mar 2004 16:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tDC-00075t-4I for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:13:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24897 for ; Tue, 23 Mar 2004 15:23:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sQn-0002GK-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:23:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5sOu-0002CK-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:21:29 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5sOg-0002AA-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:21:14 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2NKKfRr005090; Tue, 23 Mar 2004 12:20:41 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i2NKKfOd005089; Tue, 23 Mar 2004 12:20:41 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 23 Mar 2004 12:20:41 -0800 From: David Meyer To: Bill Fenner Cc: eckert@cisco.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323202041.GA5021@1-4-5.net> References: <200403231937.i2NJbeb10375@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403231937.i2NJbeb10375@windsor.research.att.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 11:37:39AM -0800, Bill Fenner wrote: >> >> >I was wondering what kind of discussion has preceeded these >> >decisions, as and what the large group of people is that is in >> >agreement with it. >> >> The BGMP status was a bug in the presentation; it is indeed planning >> to go to Informational (although the only feedback on the BGMP WG >> mailing list was that it should go Experimental instead). Ok, thanks. I thought I remembered something different (and the minutes are a little light on this topic). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 16:36:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03495 for ; Tue, 23 Mar 2004 16:36:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tZ8-0000a5-Gb for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NLa6SX002211 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tZ3-0000Yq-2M; Tue, 23 Mar 2004 16:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tYP-0000Wo-AE for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:35:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03299 for ; Tue, 23 Mar 2004 16:35:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tYN-0005Xo-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:35:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5tWk-0005Fi-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:33:39 -0500 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1B5tVP-0004rm-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:32:15 -0500 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-white.research.att.com (Postfix) with ESMTP id 6BB6866404F; Tue, 23 Mar 2004 16:31:45 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id 5BF6CF3AB5; Tue, 23 Mar 2004 16:31:45 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i2NLVil11930; Tue, 23 Mar 2004 13:31:44 -0800 (PST) Message-Id: <200403232131.i2NLVil11930@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com References: <200403231937.i2NJbeb10375@windsor.research.att.com> <20040323202225.GH17887@cisco.com> Date: Tue, 23 Mar 2004 13:31:43 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >I can not find an applicability statement outlining that >DVMRP is only considered to be acceptable for small networks because >of both flood & prune behavior, non-modular protocol design and >non-scalable RPF routing protocol. Can you point me to that statement >in the draft ? I would suggest reading the DVMRP applicability statement draft. It has statements about scalability of broadcast and prune and the route exchange. It also mentions that DVMRP can avoid duplicates by precomputing broadcast trees, as well as the state disadvantages of precomputing trees. draft-ietf-idmr-dvmrp-v3-as-00.txt is expired, but you can find a copy at http://rtg.ietf.org/~fenner/draft-ietf-idmr-dvmrp-v3-as-00.txt Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 16:51:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29127 for ; Tue, 23 Mar 2004 16:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5t53-00069e-Qt; Tue, 23 Mar 2004 16:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5t4w-00068d-Er for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:04:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29047 for ; Tue, 23 Mar 2004 16:04:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5t4u-0007R1-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:04:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5t3n-0007It-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:03:44 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5t3P-0007Cx-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:03:20 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2NL2klw005761; Tue, 23 Mar 2004 13:02:46 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i2NL2kDF005760; Tue, 23 Mar 2004 13:02:46 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 23 Mar 2004 13:02:46 -0800 From: David Meyer To: Tom Pusateri Cc: eckert@cisco.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323210246.GA5582@1-4-5.net> References: <20040323201126.GA4507@1-4-5.net> <200403232035.i2NKZKJ42048@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232035.i2NKZKJ42048@merlot.juniper.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 12:35:19PM -0800, Tom Pusateri wrote: >> In message <20040323201126.GA4507@1-4-5.net> you write: >> > >> > Summary >> > ------ >> > It is the statement potentially implied by our >> > classification of the various protocols described above >> > which is of concern. In particular, it doesn't seem >> > outside the realm of possibility for one to conclude that >> > inter-domain ASM isn't an IETF standards track activity >> > (which of course, mod some future event with bidir, it >> > currently is not). However, it would seem clear that this >> > not our intended statement. This, combined with the fact >> > such a conclusion would not reflect deployment practices >> > in the IPv4 Internet, is what I find troubling. >> > >> > Dave >> Tom, >> I don't think we should worry about what we "imply". Each protocol >> should be moved forward according to the best information we have >> available without unnecesary delay. With regard to the latter statement, no disagreement (and FWIW, I didn't take anything said in this thread as suggesting anything should be unnecessarily delayed). >> If someone wants to waste their time making inferences from >> the combination of these actions then so be it but it >> certainly should not concern us. Understand. The implication thing just occurred to me during the open routing area meeting, and so I thought I might recount it here. Basically, since I try to take a system-wide view of what the IETF does (both in terms of its technology, as well as its process), occasionally things like this turn up. In any event, if it is all a non-issue, so much the better. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 16:53:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04811 for ; Tue, 23 Mar 2004 16:53:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tpV-0002e3-Ih; Tue, 23 Mar 2004 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tpQ-0002do-HS for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:52:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04804 for ; Tue, 23 Mar 2004 16:52:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tpO-0007NL-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:52:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5toK-0007H5-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:51:49 -0500 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1B5tny-0007Bi-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:51:26 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mail-white.research.att.com (Postfix) with ESMTP id EE1EF664018; Tue, 23 Mar 2004 16:50:56 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id D4FAAF3AB5; Tue, 23 Mar 2004 16:50:56 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i2NLoud12156; Tue, 23 Mar 2004 13:50:56 -0800 (PST) Message-Id: <200403232150.i2NLoud12156@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. Cc: jhall@maoz.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> Date: Tue, 23 Mar 2004 13:50:54 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >I think if we can not get an agreeement about this fundamental point >in the IETF (and i was under the impression that we did have this >agreeement since 1993/4 when PIM was first introduced), then i think >it will be very hard to agree on any other points about the IP multicast >architecture. I don't think that the integration of routing and tree building protocol is a problem on the scale that DVMRP is useful. It may affect the scalability, but other of DVMRP's problems are probably more important. [Sorry, combining replies to two different messages] >So you think that new vendors should implement DVMRP ? Well, should new vendors implement RIP? Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 16:53:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04813 for ; Tue, 23 Mar 2004 16:53:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tpa-0002fX-KB for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:53:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NLr6qQ010182 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tpV-0002e3-Ih; Tue, 23 Mar 2004 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tpQ-0002do-HS for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:52:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04804 for ; Tue, 23 Mar 2004 16:52:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tpO-0007NL-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:52:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5toK-0007H5-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:51:49 -0500 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1B5tny-0007Bi-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:51:26 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mail-white.research.att.com (Postfix) with ESMTP id EE1EF664018; Tue, 23 Mar 2004 16:50:56 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id D4FAAF3AB5; Tue, 23 Mar 2004 16:50:56 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i2NLoud12156; Tue, 23 Mar 2004 13:50:56 -0800 (PST) Message-Id: <200403232150.i2NLoud12156@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. Cc: jhall@maoz.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> Date: Tue, 23 Mar 2004 13:50:54 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >I think if we can not get an agreeement about this fundamental point >in the IETF (and i was under the impression that we did have this >agreeement since 1993/4 when PIM was first introduced), then i think >it will be very hard to agree on any other points about the IP multicast >architecture. I don't think that the integration of routing and tree building protocol is a problem on the scale that DVMRP is useful. It may affect the scalability, but other of DVMRP's problems are probably more important. [Sorry, combining replies to two different messages] >So you think that new vendors should implement DVMRP ? Well, should new vendors implement RIP? Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 16:59:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05520 for ; Tue, 23 Mar 2004 16:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tvI-0003Qm-V8; Tue, 23 Mar 2004 16:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tuU-0003Lp-17 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:58:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05302 for ; Tue, 23 Mar 2004 16:58:06 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tuR-0000S5-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:58:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ttH-0000G5-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:56:55 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[nlED8UGIhq8zuJlzsaEsdnmoCHZF3Nrd]) by ietf-mx with esmtp (Exim 4.12) id 1B5tsL-00005N-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:55:57 -0500 Received: from shepfarm.com (IDENT:Z0EF+IZYrX+zurmscLHMY47ejPzWZlXo@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2NNbSTk006822; Tue, 23 Mar 2004 15:37:28 -0800 Date: Tue, 23 Mar 2004 15:37:28 -0800 (PST) To: Bill Fenner cc: eckert@cisco.com, , , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403232150.i2NLoud12156@windsor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , > Well, should new vendors implement RIP? This should be determined by each vendor - NOT the IETF. Greg > Bill > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 16:59:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05540 for ; Tue, 23 Mar 2004 16:59:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tvK-0003U8-QH for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NLx2cW013315 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tvI-0003Qm-V8; Tue, 23 Mar 2004 16:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tuU-0003Lp-17 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:58:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05302 for ; Tue, 23 Mar 2004 16:58:06 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tuR-0000S5-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:58:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ttH-0000G5-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:56:55 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[nlED8UGIhq8zuJlzsaEsdnmoCHZF3Nrd]) by ietf-mx with esmtp (Exim 4.12) id 1B5tsL-00005N-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:55:57 -0500 Received: from shepfarm.com (IDENT:Z0EF+IZYrX+zurmscLHMY47ejPzWZlXo@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2NNbSTk006822; Tue, 23 Mar 2004 15:37:28 -0800 Date: Tue, 23 Mar 2004 15:37:28 -0800 (PST) To: Bill Fenner cc: eckert@cisco.com, , , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403232150.i2NLoud12156@windsor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , > Well, should new vendors implement RIP? This should be determined by each vendor - NOT the IETF. Greg > Bill > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 17:03:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29918 for ; Tue, 23 Mar 2004 16:14:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tDq-0007Bz-3Q for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:14:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NLE6uP027622 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 16:14:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tDl-00078s-6A; Tue, 23 Mar 2004 16:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tDC-00075t-4I for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:13:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24897 for ; Tue, 23 Mar 2004 15:23:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sQn-0002GK-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:23:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5sOu-0002CK-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:21:29 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5sOg-0002AA-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:21:14 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2NKKfRr005090; Tue, 23 Mar 2004 12:20:41 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i2NKKfOd005089; Tue, 23 Mar 2004 12:20:41 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 23 Mar 2004 12:20:41 -0800 From: David Meyer To: Bill Fenner Cc: eckert@cisco.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323202041.GA5021@1-4-5.net> References: <200403231937.i2NJbeb10375@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403231937.i2NJbeb10375@windsor.research.att.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 11:37:39AM -0800, Bill Fenner wrote: >> >> >I was wondering what kind of discussion has preceeded these >> >decisions, as and what the large group of people is that is in >> >agreement with it. >> >> The BGMP status was a bug in the presentation; it is indeed planning >> to go to Informational (although the only feedback on the BGMP WG >> mailing list was that it should go Experimental instead). Ok, thanks. I thought I remembered something different (and the minutes are a little light on this topic). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 17:09:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06413 for ; Tue, 23 Mar 2004 17:09:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5u50-0004Ym-4o; Tue, 23 Mar 2004 17:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5u3b-0004H1-TT for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 17:07:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06240 for ; Tue, 23 Mar 2004 17:07:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5u3Z-0001d0-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 17:07:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5u2e-0001Vb-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 17:06:37 -0500 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5u1n-0001Mq-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 17:05:43 -0500 Received: from sith.maoz.com (localhost.localdomain [127.0.0.1]) by sith.maoz.com (8.12.11/8.12.11) with ESMTP id i2NM5BIq002062; Tue, 23 Mar 2004 14:05:11 -0800 Received: (from jhall@localhost) by sith.maoz.com (8.12.11/8.12.8/Submit) id i2NM5BPf002061; Tue, 23 Mar 2004 17:05:11 -0500 From: Jeremy Hall Message-Id: <200403232205.i2NM5BPf002061@sith.maoz.com> Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <20040323211339.GO17887@cisco.com> from Toerless Eckert at "Mar 23, 2004 01:13:39 pm" To: Toerless Eckert Date: Tue, 23 Mar 2004 17:05:11 -0500 (EST) CC: Jeremy Hall , David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In the new year, Toerless Eckert wrote: > On Tue, Mar 23, 2004 at 04:00:43PM -0500, Jeremy Hall wrote: > > > Other question: How would changing the IETF status of the documents > > > improve on the chance of getting working IP multicast deployment. > > > Eg: Almost all of the protocol specs are everything but helpful to > > > understand the challenges of IP multicast deployment. > > > > > If we make it clear what is useful, but not relevant to current > > deployment, new implementors will have an easier time deciding what > > exactly to implement and how to make that happen. With more vendors > > coming online WRT multicast, the more likelihood the code will be present > > on day 1 when a new router vendor is deployed into the industry. > > So you think that new vendors should implement DVMRP ? > AFAIK that recommendation was made several years ago. Since DVMRP is still deployed, it should be considered for implementation by potential vendors. > I also have my doubts about the way you describe the behavior of vendors > who now get into the game. I don't think they care about what's written > in the specs themselves - in my experience, commodity vendors do implement > whatever tops their RFPs as long as it is an RFC - never mind it's status. > If a vendor waited for an RFP, it is already behind the game curve. Vendors that already understand the industry are welcomed inthusiastically by ISPs. Vendors that must be hand-held are more the norm and thus we're used to it, but if this happened in the unicast world, nobody would tolerate it. Imagine if there was as much confusion surrounding MPLS as there is surrounding multicast. Sure there are many flavours of MPLS out there, but the fundamentals aren't disputed. Are RSVP and LDP considered experimental protocols? > Last but not least: Let's not target vendors but rather users with > whatever we do, eg: ISPs and enterprises! By making the relevant protocols proposed standards, ISPs have an easier time getting the vendors to comply. In the end, resistence is futile to progress, and anything that does not provide a clear direction is resistence. I'm not saying we have to throw out this protocol or that one, I'm simply saying we need to unite together and decide what the direction should be, whatever that might be. AFAIK ISM and ASM have been going strongly for several years, perhaps we should come to the table and make some hard choices. _J > _______________________________________________________________ > user interface: http://darkwing.uoregon.edu/~llynch/mboned.html > web archive: http://darkwing.uoregon.edu/~llynch/mboned/ > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 17:23:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03496 for ; Tue, 23 Mar 2004 16:36:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tZ3-0000Yq-2M; Tue, 23 Mar 2004 16:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tYP-0000Wo-AE for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:35:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03299 for ; Tue, 23 Mar 2004 16:35:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tYN-0005Xo-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:35:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5tWk-0005Fi-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:33:39 -0500 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1B5tVP-0004rm-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:32:15 -0500 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-white.research.att.com (Postfix) with ESMTP id 6BB6866404F; Tue, 23 Mar 2004 16:31:45 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id 5BF6CF3AB5; Tue, 23 Mar 2004 16:31:45 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i2NLVil11930; Tue, 23 Mar 2004 13:31:44 -0800 (PST) Message-Id: <200403232131.i2NLVil11930@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com References: <200403231937.i2NJbeb10375@windsor.research.att.com> <20040323202225.GH17887@cisco.com> Date: Tue, 23 Mar 2004 13:31:43 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >I can not find an applicability statement outlining that >DVMRP is only considered to be acceptable for small networks because >of both flood & prune behavior, non-modular protocol design and >non-scalable RPF routing protocol. Can you point me to that statement >in the draft ? I would suggest reading the DVMRP applicability statement draft. It has statements about scalability of broadcast and prune and the route exchange. It also mentions that DVMRP can avoid duplicates by precomputing broadcast trees, as well as the state disadvantages of precomputing trees. draft-ietf-idmr-dvmrp-v3-as-00.txt is expired, but you can find a copy at http://rtg.ietf.org/~fenner/draft-ietf-idmr-dvmrp-v3-as-00.txt Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 17:58:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06412 for ; Tue, 23 Mar 2004 17:09:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5u59-0004bc-A1 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 17:09:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NM9BRk017702 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 17:09:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5u50-0004Ym-4o; Tue, 23 Mar 2004 17:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5u3b-0004H1-TT for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 17:07:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06240 for ; Tue, 23 Mar 2004 17:07:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5u3Z-0001d0-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 17:07:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5u2e-0001Vb-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 17:06:37 -0500 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5u1n-0001Mq-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 17:05:43 -0500 Received: from sith.maoz.com (localhost.localdomain [127.0.0.1]) by sith.maoz.com (8.12.11/8.12.11) with ESMTP id i2NM5BIq002062; Tue, 23 Mar 2004 14:05:11 -0800 Received: (from jhall@localhost) by sith.maoz.com (8.12.11/8.12.8/Submit) id i2NM5BPf002061; Tue, 23 Mar 2004 17:05:11 -0500 From: Jeremy Hall Message-Id: <200403232205.i2NM5BPf002061@sith.maoz.com> Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <20040323211339.GO17887@cisco.com> from Toerless Eckert at "Mar 23, 2004 01:13:39 pm" To: Toerless Eckert Date: Tue, 23 Mar 2004 17:05:11 -0500 (EST) CC: Jeremy Hall , David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In the new year, Toerless Eckert wrote: > On Tue, Mar 23, 2004 at 04:00:43PM -0500, Jeremy Hall wrote: > > > Other question: How would changing the IETF status of the documents > > > improve on the chance of getting working IP multicast deployment. > > > Eg: Almost all of the protocol specs are everything but helpful to > > > understand the challenges of IP multicast deployment. > > > > > If we make it clear what is useful, but not relevant to current > > deployment, new implementors will have an easier time deciding what > > exactly to implement and how to make that happen. With more vendors > > coming online WRT multicast, the more likelihood the code will be present > > on day 1 when a new router vendor is deployed into the industry. > > So you think that new vendors should implement DVMRP ? > AFAIK that recommendation was made several years ago. Since DVMRP is still deployed, it should be considered for implementation by potential vendors. > I also have my doubts about the way you describe the behavior of vendors > who now get into the game. I don't think they care about what's written > in the specs themselves - in my experience, commodity vendors do implement > whatever tops their RFPs as long as it is an RFC - never mind it's status. > If a vendor waited for an RFP, it is already behind the game curve. Vendors that already understand the industry are welcomed inthusiastically by ISPs. Vendors that must be hand-held are more the norm and thus we're used to it, but if this happened in the unicast world, nobody would tolerate it. Imagine if there was as much confusion surrounding MPLS as there is surrounding multicast. Sure there are many flavours of MPLS out there, but the fundamentals aren't disputed. Are RSVP and LDP considered experimental protocols? > Last but not least: Let's not target vendors but rather users with > whatever we do, eg: ISPs and enterprises! By making the relevant protocols proposed standards, ISPs have an easier time getting the vendors to comply. In the end, resistence is futile to progress, and anything that does not provide a clear direction is resistence. I'm not saying we have to throw out this protocol or that one, I'm simply saying we need to unite together and decide what the direction should be, whatever that might be. AFAIK ISM and ASM have been going strongly for several years, perhaps we should come to the table and make some hard choices. _J > _______________________________________________________________ > user interface: http://darkwing.uoregon.edu/~llynch/mboned.html > web archive: http://darkwing.uoregon.edu/~llynch/mboned/ > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 18:20:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10957 for ; Tue, 23 Mar 2004 18:20:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBi-0000vG-99; Tue, 23 Mar 2004 18:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sZU-00019t-BX for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:32:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25643 for ; Tue, 23 Mar 2004 15:32:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sZS-0003D9-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:32:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5sYD-00032y-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:31:06 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5sX7-0002nx-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:29:57 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2004 12:35:31 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2NKTOUe003537; Tue, 23 Mar 2004 12:29:25 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA27246; Tue, 23 Mar 2004 12:29:24 -0800 (PST) Date: Tue, 23 Mar 2004 12:29:23 -0800 From: Toerless Eckert To: Pekka Savola Cc: Tom Pusateri , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323202923.GI17887@cisco.com> References: <200403231918.i2NJIfJ32214@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Actually i think historic is more appropriate than informational because i would hope that status does both honor the important role it actually has played in the development of ip multicast but it as well would makes a point about preferring PIM-DM over DVMRP even for small scale deployments for reasons of being better in line with the automatic RPF/unicast congruency and modularization between routing and tree building. If at all, i would recommend DVMRP today only for small, maybe ad-hoc networks that do not run _any_ unicast, but only multicast (so that you actually do not have a unicast routing protocol nor unicast reachability in the network). Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 18:20:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10964 for ; Tue, 23 Mar 2004 18:20:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBo-00010i-6Q; Tue, 23 Mar 2004 18:20:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5toB-0002a9-Mh for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:51:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04735 for ; Tue, 23 Mar 2004 16:51:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5to9-0007FI-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:51:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5tnD-0007B3-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:50:39 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5tml-00076q-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:50:11 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2004 13:55:46 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2NLncKj023167; Tue, 23 Mar 2004 13:49:39 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA03223; Tue, 23 Mar 2004 13:49:38 -0800 (PST) Date: Tue, 23 Mar 2004 13:49:38 -0800 From: Toerless Eckert To: Bill Fenner Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323214938.GQ17887@cisco.com> References: <200403231937.i2NJbeb10375@windsor.research.att.com> <20040323202225.GH17887@cisco.com> <200403232131.i2NLVil11930@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232131.i2NLVil11930@windsor.research.att.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 01:31:43PM -0800, Bill Fenner wrote: > I would suggest reading the DVMRP applicability statement draft. > It has statements about scalability of broadcast and prune and the > route exchange. It also mentions that DVMRP can avoid duplicates by > precomputing broadcast trees, as well as the state disadvantages of > precomputing trees. > > draft-ietf-idmr-dvmrp-v3-as-00.txt is expired, but you can find > a copy at http://rtg.ietf.org/~fenner/draft-ietf-idmr-dvmrp-v3-as-00.txt Thanks ! Now if we could persuade the IETF that 100GB hard disk space to hold all historical documents on a known public place then this stupid timeout thing would hit me over and over again *mumble* _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 18:20:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10971 for ; Tue, 23 Mar 2004 18:20:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBi-0000vO-Rc; Tue, 23 Mar 2004 18:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sm5-0002nL-OS for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:45:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27117 for ; Tue, 23 Mar 2004 15:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sm4-00055v-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:45:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5skQ-0004kb-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:43:43 -0500 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5shK-0004E0-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:40:30 -0500 Received: from sith.maoz.com (localhost.localdomain [127.0.0.1]) by sith.maoz.com (8.12.11/8.12.11) with ESMTP id i2NKdvBs001052; Tue, 23 Mar 2004 12:39:57 -0800 Received: (from jhall@localhost) by sith.maoz.com (8.12.11/8.12.8/Submit) id i2NKdvHr001051; Tue, 23 Mar 2004 15:39:57 -0500 From: Jeremy Hall Message-Id: <200403232039.i2NKdvHr001051@sith.maoz.com> Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <20040323201126.GA4507@1-4-5.net> from David Meyer at "Mar 23, 2004 12:11:26 pm" To: David Meyer Date: Tue, 23 Mar 2004 15:39:56 -0500 (EST) CC: eckert@cisco.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In the new year, David Meyer wrote: > On Tue, Mar 23, 2004 at 09:42:03AM -0800, eckert@cisco.com wrote: > >> I was told that in the routing area meeting of the 59th ietf, > >> it was declared that BGMP will go to experimental and DVMRP to PS. > >> > My concern, however, is whether the combination of these > actions implicitly states something like "inter-domain > IPv4 ASM isn't an IETF standards track activity". The > reasoning might go something like "What does the IETF > have on standards track for inter-domain ASM...?" (well, > nothing), and go from there. Of course, one might argue > that bidir is the eventual solution here, and hence > "someday" this argument will be moot. > If we are using MSDP as "the official method" of ASM interdomain controlling, then the IETF status should reflect that. It's confusing enough to have all the multicast protocols in their various status, but as it is now, you have to have history in running the stuff to be able to successfully deploy it, or in the least, have a mentor that can point you in the right direction. What is wrong other than philosophical scaling issues with making the status of the protocols consistent with what is deployed? _J _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 18:20:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11069 for ; Tue, 23 Mar 2004 18:20:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBy-0001B5-5m for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNKGX6003959 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBi-0000vO-Rc; Tue, 23 Mar 2004 18:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sm5-0002nL-OS for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:45:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27117 for ; Tue, 23 Mar 2004 15:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sm4-00055v-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:45:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5skQ-0004kb-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:43:43 -0500 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5shK-0004E0-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:40:30 -0500 Received: from sith.maoz.com (localhost.localdomain [127.0.0.1]) by sith.maoz.com (8.12.11/8.12.11) with ESMTP id i2NKdvBs001052; Tue, 23 Mar 2004 12:39:57 -0800 Received: (from jhall@localhost) by sith.maoz.com (8.12.11/8.12.8/Submit) id i2NKdvHr001051; Tue, 23 Mar 2004 15:39:57 -0500 From: Jeremy Hall Message-Id: <200403232039.i2NKdvHr001051@sith.maoz.com> Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <20040323201126.GA4507@1-4-5.net> from David Meyer at "Mar 23, 2004 12:11:26 pm" To: David Meyer Date: Tue, 23 Mar 2004 15:39:56 -0500 (EST) CC: eckert@cisco.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In the new year, David Meyer wrote: > On Tue, Mar 23, 2004 at 09:42:03AM -0800, eckert@cisco.com wrote: > >> I was told that in the routing area meeting of the 59th ietf, > >> it was declared that BGMP will go to experimental and DVMRP to PS. > >> > My concern, however, is whether the combination of these > actions implicitly states something like "inter-domain > IPv4 ASM isn't an IETF standards track activity". The > reasoning might go something like "What does the IETF > have on standards track for inter-domain ASM...?" (well, > nothing), and go from there. Of course, one might argue > that bidir is the eventual solution here, and hence > "someday" this argument will be moot. > If we are using MSDP as "the official method" of ASM interdomain controlling, then the IETF status should reflect that. It's confusing enough to have all the multicast protocols in their various status, but as it is now, you have to have history in running the stuff to be able to successfully deploy it, or in the least, have a mentor that can point you in the right direction. What is wrong other than philosophical scaling issues with making the status of the protocols consistent with what is deployed? _J _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 18:20:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11066 for ; Tue, 23 Mar 2004 18:20:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBy-0001B1-2T for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNKFfq003956 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBl-0000vm-5C; Tue, 23 Mar 2004 18:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ssJ-0004Jn-AM for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:51:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28237 for ; Tue, 23 Mar 2004 15:51:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ssH-0006GT-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:51:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5srJ-000694-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:50:50 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5sqT-0005va-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:49:57 -0500 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2NKnPUe023019; Tue, 23 Mar 2004 12:49:25 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA10030; Tue, 23 Mar 2004 12:49:25 -0800 (PST) Date: Tue, 23 Mar 2004 12:49:24 -0800 From: Toerless Eckert To: Jeremy Hall Cc: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323204924.GL17887@cisco.com> References: <20040323201126.GA4507@1-4-5.net> <200403232039.i2NKdvHr001051@sith.maoz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232039.i2NKdvHr001051@sith.maoz.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 03:39:56PM -0500, Jeremy Hall wrote: > If we are using MSDP as "the official method" of ASM interdomain > controlling, then the IETF status should reflect that. It's confusing > enough to have all the multicast protocols in their various status, but as > it is now, you have to have history in running the stuff to be able to > successfully deploy it, or in the least, have a mentor that can point you > in the right direction. What is wrong other than philosophical scaling > issues with making the status of the protocols consistent with what is > deployed? Other question: How would changing the IETF status of the documents improve on the chance of getting working IP multicast deployment. Eg: Almost all of the protocol specs are everything but helpful to understand the challenges of IP multicast deployment. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 18:20:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11112 for ; Tue, 23 Mar 2004 18:20:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBj-0000vW-Ka; Tue, 23 Mar 2004 18:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5smC-0002on-2v for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:45:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27136 for ; Tue, 23 Mar 2004 15:45:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5smA-00058Q-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:45:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5skc-0004mU-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:43:58 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5shV-0004FX-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:40:41 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2004 12:46:15 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2NKe8GX020348; Tue, 23 Mar 2004 12:40:09 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA05940; Tue, 23 Mar 2004 12:40:08 -0800 (PST) Date: Tue, 23 Mar 2004 12:40:08 -0800 From: Toerless Eckert To: David Meyer Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323204008.GJ17887@cisco.com> References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040323201126.GA4507@1-4-5.net> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Dave, All your questions are valid. I think we might want to start trying to resolve them by defining through IMDOC first what the architecture looks like - and do it in such a way that the most useful classification of the involved protocols will be clearer at the end of the process. Imagine for example everybody who has Internet at home today would be able to do IP multicast across the Internet to everybody else in the Internet. Do you really think that would work with ASM ? And i am not even talking about MSDP scalability, let's assume we have really brutally well scaling implementations (*grin*). I am talking about the basic DoS problem of the ASM service model and the nature of the Internet at large. Eg: I think the ASM service model (rfc1112) can only be internet standards track for scopes that have certain characteristics of control and/or membership (either lots of control or friendly membership). This can never be the case for the Internet, neither in IPv4 nor in IPv6. We only see it working because effectively what is global scope in IP multicast today consists of a pretty small subset of the Internet which actually is still quite friendly. On the other hand, ASM of course makes perfect sense for all smaller scopes that do have this property (not only todays limited Internet multicast scope, but more specifically enterprise scopes, scopes of research networks across continents, etc..). So, besides the point that i think we should clarify the applicability of ASM along these lines in IMDOC: What impact would this applicability limitation of ASM have on the RFC status of both the service model RFC (1112 - which needs to be reworked to include ipv6 anyhow) as well as the protocols ? Eg: Are there protocols on standards track that have similar applicability limitations ? Cheers Toerless On Tue, Mar 23, 2004 at 12:11:26PM -0800, David Meyer wrote: > On Tue, Mar 23, 2004 at 09:42:03AM -0800, eckert@cisco.com wrote: > >> I was told that in the routing area meeting of the 59th ietf, > >> it was declared that BGMP will go to experimental and DVMRP to PS. > >> > >> I was wondering what kind of discussion has preceeded these > >> decisions, as and what the large group of people is that is in > >> agreement with it. > >> > >> As for me, i would strongly suggest to make BGMP today informational > >> and DVMRP historic: > >> > >> I don't think there's sufficient proof that the IETF wants for the > >> model proposed by BGMP to be the standard solution for interdomain > >> ASM, nor do i see any real activity in taking BGMP from powerpoint > >> to the real world (*oops*, from drafts to routers). As far as DVMRP > >> is concerned, i think it should be classified historic because > >> it violates what i would consider to be the most fundamental Internet > >> IP multicast routing architecture principle: Separation/independence > >> of RPF and tree building. > >> > > Regarding BGMP: > > It is not that advancing BGMP to Experimental is in and of > itself problematic; in fact, this seems completely > reasonable and is arguably consistent with what it means > to advance to Experimental. Rather, my concern is the > around implicit statement the IETF is making by taking > both of the IPv4 ASM candidate protocols (MSDP and BGMP) > to Experimental and SSM to PS. Just to be very clear > here, taking SSM to PS is again completely reasonable. > > My concern, however, is whether the combination of these > actions implicitly states something like "inter-domain > IPv4 ASM isn't an IETF standards track activity". The > reasoning might go something like "What does the IETF > have on standards track for inter-domain ASM...?" (well, > nothing), and go from there. Of course, one might argue > that bidir is the eventual solution here, and hence > "someday" this argument will be moot. > > So one of the problems here, as Bill correctly pointed > out, is that we don't have anyone working on an > alternative (and that this can be taken as a measure of > the interest in a hypothetical alternate IPv4 > inter-domain ASM protocol). It might also be taken as a > statement like "MSDP works well enough"...but then why > don't we put MSDP on standards track? Well, other than > that no one likes its architecture, etc. > > Summary > ------ > It is the statement potentially implied by our > classification of the various protocols described above > which is of concern. In particular, it doesn't seem > outside the realm of possibility for one to conclude that > inter-domain ASM isn't an IETF standards track activity > (which of course, mod some future event with bidir, it > currently is not). However, it would seem clear that this > not our intended statement. This, combined with the fact > such a conclusion would not reflect deployment practices > in the IPv4 Internet, is what I find troubling. > > Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 18:20:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11164 for ; Tue, 23 Mar 2004 18:20:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBy-0001B4-3l for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNKFm5003964 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBo-00010i-6Q; Tue, 23 Mar 2004 18:20:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5toB-0002a9-Mh for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:51:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04735 for ; Tue, 23 Mar 2004 16:51:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5to9-0007FI-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:51:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5tnD-0007B3-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:50:39 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5tml-00076q-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:50:11 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2004 13:55:46 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2NLncKj023167; Tue, 23 Mar 2004 13:49:39 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA03223; Tue, 23 Mar 2004 13:49:38 -0800 (PST) Date: Tue, 23 Mar 2004 13:49:38 -0800 From: Toerless Eckert To: Bill Fenner Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323214938.GQ17887@cisco.com> References: <200403231937.i2NJbeb10375@windsor.research.att.com> <20040323202225.GH17887@cisco.com> <200403232131.i2NLVil11930@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232131.i2NLVil11930@windsor.research.att.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 01:31:43PM -0800, Bill Fenner wrote: > I would suggest reading the DVMRP applicability statement draft. > It has statements about scalability of broadcast and prune and the > route exchange. It also mentions that DVMRP can avoid duplicates by > precomputing broadcast trees, as well as the state disadvantages of > precomputing trees. > > draft-ietf-idmr-dvmrp-v3-as-00.txt is expired, but you can find > a copy at http://rtg.ietf.org/~fenner/draft-ietf-idmr-dvmrp-v3-as-00.txt Thanks ! Now if we could persuade the IETF that 100GB hard disk space to hold all historical documents on a known public place then this stupid timeout thing would hit me over and over again *mumble* _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 18:20:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11162 for ; Tue, 23 Mar 2004 18:20:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBy-0001B0-2R for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNKFDj003963 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBj-0000vW-Ka; Tue, 23 Mar 2004 18:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5smC-0002on-2v for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:45:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27136 for ; Tue, 23 Mar 2004 15:45:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5smA-00058Q-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:45:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5skc-0004mU-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:43:58 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5shV-0004FX-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:40:41 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2004 12:46:15 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2NKe8GX020348; Tue, 23 Mar 2004 12:40:09 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA05940; Tue, 23 Mar 2004 12:40:08 -0800 (PST) Date: Tue, 23 Mar 2004 12:40:08 -0800 From: Toerless Eckert To: David Meyer Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323204008.GJ17887@cisco.com> References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040323201126.GA4507@1-4-5.net> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Dave, All your questions are valid. I think we might want to start trying to resolve them by defining through IMDOC first what the architecture looks like - and do it in such a way that the most useful classification of the involved protocols will be clearer at the end of the process. Imagine for example everybody who has Internet at home today would be able to do IP multicast across the Internet to everybody else in the Internet. Do you really think that would work with ASM ? And i am not even talking about MSDP scalability, let's assume we have really brutally well scaling implementations (*grin*). I am talking about the basic DoS problem of the ASM service model and the nature of the Internet at large. Eg: I think the ASM service model (rfc1112) can only be internet standards track for scopes that have certain characteristics of control and/or membership (either lots of control or friendly membership). This can never be the case for the Internet, neither in IPv4 nor in IPv6. We only see it working because effectively what is global scope in IP multicast today consists of a pretty small subset of the Internet which actually is still quite friendly. On the other hand, ASM of course makes perfect sense for all smaller scopes that do have this property (not only todays limited Internet multicast scope, but more specifically enterprise scopes, scopes of research networks across continents, etc..). So, besides the point that i think we should clarify the applicability of ASM along these lines in IMDOC: What impact would this applicability limitation of ASM have on the RFC status of both the service model RFC (1112 - which needs to be reworked to include ipv6 anyhow) as well as the protocols ? Eg: Are there protocols on standards track that have similar applicability limitations ? Cheers Toerless On Tue, Mar 23, 2004 at 12:11:26PM -0800, David Meyer wrote: > On Tue, Mar 23, 2004 at 09:42:03AM -0800, eckert@cisco.com wrote: > >> I was told that in the routing area meeting of the 59th ietf, > >> it was declared that BGMP will go to experimental and DVMRP to PS. > >> > >> I was wondering what kind of discussion has preceeded these > >> decisions, as and what the large group of people is that is in > >> agreement with it. > >> > >> As for me, i would strongly suggest to make BGMP today informational > >> and DVMRP historic: > >> > >> I don't think there's sufficient proof that the IETF wants for the > >> model proposed by BGMP to be the standard solution for interdomain > >> ASM, nor do i see any real activity in taking BGMP from powerpoint > >> to the real world (*oops*, from drafts to routers). As far as DVMRP > >> is concerned, i think it should be classified historic because > >> it violates what i would consider to be the most fundamental Internet > >> IP multicast routing architecture principle: Separation/independence > >> of RPF and tree building. > >> > > Regarding BGMP: > > It is not that advancing BGMP to Experimental is in and of > itself problematic; in fact, this seems completely > reasonable and is arguably consistent with what it means > to advance to Experimental. Rather, my concern is the > around implicit statement the IETF is making by taking > both of the IPv4 ASM candidate protocols (MSDP and BGMP) > to Experimental and SSM to PS. Just to be very clear > here, taking SSM to PS is again completely reasonable. > > My concern, however, is whether the combination of these > actions implicitly states something like "inter-domain > IPv4 ASM isn't an IETF standards track activity". The > reasoning might go something like "What does the IETF > have on standards track for inter-domain ASM...?" (well, > nothing), and go from there. Of course, one might argue > that bidir is the eventual solution here, and hence > "someday" this argument will be moot. > > So one of the problems here, as Bill correctly pointed > out, is that we don't have anyone working on an > alternative (and that this can be taken as a measure of > the interest in a hypothetical alternate IPv4 > inter-domain ASM protocol). It might also be taken as a > statement like "MSDP works well enough"...but then why > don't we put MSDP on standards track? Well, other than > that no one likes its architecture, etc. > > Summary > ------ > It is the statement potentially implied by our > classification of the various protocols described above > which is of concern. In particular, it doesn't seem > outside the realm of possibility for one to conclude that > inter-domain ASM isn't an IETF standards track activity > (which of course, mod some future event with bidir, it > currently is not). However, it would seem clear that this > not our intended statement. This, combined with the fact > such a conclusion would not reflect deployment practices > in the IPv4 Internet, is what I find troubling. > > Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 18:33:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11953 for ; Tue, 23 Mar 2004 18:33:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vOH-0002rO-HS; Tue, 23 Mar 2004 18:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vNt-0002qh-0P for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 18:32:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11932 for ; Tue, 23 Mar 2004 18:32:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vNq-0001Ab-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:32:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vMw-00017L-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:31:39 -0500 Received: from mail-dark.research.att.com ([192.20.225.112]) by ietf-mx with esmtp (Exim 4.12) id 1B5vMJ-0000zJ-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:30:59 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-dark.research.att.com (Postfix) with ESMTP id 5D971E80E5; Tue, 23 Mar 2004 18:30:24 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 4E5B9F3A9C; Tue, 23 Mar 2004 18:30:24 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i2NNUNk13398; Tue, 23 Mar 2004 15:30:23 -0800 (PST) Message-Id: <200403232330.i2NNUNk13398@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> <20040323232041.GR17887@cisco.com> Date: Tue, 23 Mar 2004 15:30:22 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >If they think they have a market for RIP, then they should implement it, >as well as IGMP proxying or PIM-DM, but not DVMRP. I don't get it. DVMRP is more flexible than IGMP proxying and more efficient than PIM-DM, but you want the IETF to try to remove it from the selection of tools that a customer may have available? Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 18:56:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12858 for ; Tue, 23 Mar 2004 18:56:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vkX-00055g-G1; Tue, 23 Mar 2004 18:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vkE-00055R-1c for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 18:55:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12851 for ; Tue, 23 Mar 2004 18:55:37 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vkA-0003F3-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:55:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vjE-0003Bd-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:54:40 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[+sXTbFHHEpJhgGB1xGMzcuspDCeMWWQb]) by ietf-mx with esmtp (Exim 4.12) id 1B5vix-00037z-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:54:23 -0500 Received: from shepfarm.com (IDENT:6xJ01gb/VBmRbV4uXv1Zy1+/9ySsm1o3@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2O1ZnTk007288; Tue, 23 Mar 2004 17:35:49 -0800 Date: Tue, 23 Mar 2004 17:35:49 -0800 (PST) To: Toerless Eckert cc: Bill Fenner , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <20040323232041.GR17887@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , > If they think they have a market for RIP, then they should implement it, > as well as IGMP proxying or PIM-DM, but not DVMRP. Huh, I thought the customers decided what they want to deploy? We (vendors) can make recommendations, and I would hope that they (customers) research the options (IETF) on their own. But to think Toerless has the final word on what can and can't be deploy kinda' scares me. Do I need to go buy blue shoes now too?? ;-) ;-) Greg _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 18:56:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12872 for ; Tue, 23 Mar 2004 18:56:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vki-000572-LF for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:56:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNuCbs019631 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:56:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vkX-00055g-G1; Tue, 23 Mar 2004 18:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vkE-00055R-1c for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 18:55:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12851 for ; Tue, 23 Mar 2004 18:55:37 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vkA-0003F3-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:55:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vjE-0003Bd-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:54:40 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[+sXTbFHHEpJhgGB1xGMzcuspDCeMWWQb]) by ietf-mx with esmtp (Exim 4.12) id 1B5vix-00037z-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:54:23 -0500 Received: from shepfarm.com (IDENT:6xJ01gb/VBmRbV4uXv1Zy1+/9ySsm1o3@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2O1ZnTk007288; Tue, 23 Mar 2004 17:35:49 -0800 Date: Tue, 23 Mar 2004 17:35:49 -0800 (PST) To: Toerless Eckert cc: Bill Fenner , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <20040323232041.GR17887@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , > If they think they have a market for RIP, then they should implement it, > as well as IGMP proxying or PIM-DM, but not DVMRP. Huh, I thought the customers decided what they want to deploy? We (vendors) can make recommendations, and I would hope that they (customers) research the options (IETF) on their own. But to think Toerless has the final word on what can and can't be deploy kinda' scares me. Do I need to go buy blue shoes now too?? ;-) ;-) Greg _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 19:08:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11065 for ; Tue, 23 Mar 2004 18:20:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBy-0001B3-38 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNKFVJ003962 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBi-0000vG-99; Tue, 23 Mar 2004 18:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sZU-00019t-BX for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:32:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25643 for ; Tue, 23 Mar 2004 15:32:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sZS-0003D9-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:32:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5sYD-00032y-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:31:06 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5sX7-0002nx-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:29:57 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2004 12:35:31 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2NKTOUe003537; Tue, 23 Mar 2004 12:29:25 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA27246; Tue, 23 Mar 2004 12:29:24 -0800 (PST) Date: Tue, 23 Mar 2004 12:29:23 -0800 From: Toerless Eckert To: Pekka Savola Cc: Tom Pusateri , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323202923.GI17887@cisco.com> References: <200403231918.i2NJIfJ32214@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Actually i think historic is more appropriate than informational because i would hope that status does both honor the important role it actually has played in the development of ip multicast but it as well would makes a point about preferring PIM-DM over DVMRP even for small scale deployments for reasons of being better in line with the automatic RPF/unicast congruency and modularization between routing and tree building. If at all, i would recommend DVMRP today only for small, maybe ad-hoc networks that do not run _any_ unicast, but only multicast (so that you actually do not have a unicast routing protocol nor unicast reachability in the network). Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 19:08:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10956 for ; Tue, 23 Mar 2004 18:20:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBk-0000ve-BP; Tue, 23 Mar 2004 18:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sqZ-00048a-CC for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:50:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27929 for ; Tue, 23 Mar 2004 15:50:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sqX-000601-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:50:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5spF-0005mc-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:48:42 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5snc-0005LL-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:47:00 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2004 12:51:24 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2NKkRKj012940; Tue, 23 Mar 2004 12:46:27 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA07735; Tue, 23 Mar 2004 12:46:26 -0800 (PST) Date: Tue, 23 Mar 2004 12:46:25 -0800 From: Toerless Eckert To: Tom Pusateri Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323204625.GK17887@cisco.com> References: <20040323174203.GW17887@cisco.com> <200403231918.i2NJIfJ32214@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403231918.i2NJIfJ32214@merlot.juniper.net> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 11:18:41AM -0800, Tom Pusateri wrote: > Now, as for "the most fundamental Internet IP multicast routing > architecture principle: Separation/independence of RPF and tree > building", this has caused as many problems as it has solved so I > wouldn't be waving this flag... If this is your opinion, then i think we have a major disagreement. I think if we can not get an agreeement about this fundamental point in the IETF (and i was under the impression that we did have this agreeement since 1993/4 when PIM was first introduced), then i think it will be very hard to agree on any other points about the IP multicast architecture. Note that i think it is perfectly fine to have separe unicast and multicast topologies, it just has to be a problem of routing protocols, not a problem of tree building protocols. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 19:08:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10954 for ; Tue, 23 Mar 2004 18:20:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBl-0000vm-5C; Tue, 23 Mar 2004 18:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ssJ-0004Jn-AM for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:51:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28237 for ; Tue, 23 Mar 2004 15:51:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ssH-0006GT-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:51:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5srJ-000694-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:50:50 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5sqT-0005va-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:49:57 -0500 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2NKnPUe023019; Tue, 23 Mar 2004 12:49:25 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA10030; Tue, 23 Mar 2004 12:49:25 -0800 (PST) Date: Tue, 23 Mar 2004 12:49:24 -0800 From: Toerless Eckert To: Jeremy Hall Cc: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323204924.GL17887@cisco.com> References: <20040323201126.GA4507@1-4-5.net> <200403232039.i2NKdvHr001051@sith.maoz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232039.i2NKdvHr001051@sith.maoz.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 03:39:56PM -0500, Jeremy Hall wrote: > If we are using MSDP as "the official method" of ASM interdomain > controlling, then the IETF status should reflect that. It's confusing > enough to have all the multicast protocols in their various status, but as > it is now, you have to have history in running the stuff to be able to > successfully deploy it, or in the least, have a mentor that can point you > in the right direction. What is wrong other than philosophical scaling > issues with making the status of the protocols consistent with what is > deployed? Other question: How would changing the IETF status of the documents improve on the chance of getting working IP multicast deployment. Eg: Almost all of the protocol specs are everything but helpful to understand the challenges of IP multicast deployment. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 19:08:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11064 for ; Tue, 23 Mar 2004 18:20:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBx-00019p-Dc for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNKFrP003960 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBk-0000ve-BP; Tue, 23 Mar 2004 18:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sqZ-00048a-CC for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 15:50:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27929 for ; Tue, 23 Mar 2004 15:50:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sqX-000601-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:50:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5spF-0005mc-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:48:42 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5snc-0005LL-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:47:00 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2004 12:51:24 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2NKkRKj012940; Tue, 23 Mar 2004 12:46:27 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA07735; Tue, 23 Mar 2004 12:46:26 -0800 (PST) Date: Tue, 23 Mar 2004 12:46:25 -0800 From: Toerless Eckert To: Tom Pusateri Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323204625.GK17887@cisco.com> References: <20040323174203.GW17887@cisco.com> <200403231918.i2NJIfJ32214@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403231918.i2NJIfJ32214@merlot.juniper.net> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 11:18:41AM -0800, Tom Pusateri wrote: > Now, as for "the most fundamental Internet IP multicast routing > architecture principle: Separation/independence of RPF and tree > building", this has caused as many problems as it has solved so I > wouldn't be waving this flag... If this is your opinion, then i think we have a major disagreement. I think if we can not get an agreeement about this fundamental point in the IETF (and i was under the impression that we did have this agreeement since 1993/4 when PIM was first introduced), then i think it will be very hard to agree on any other points about the IP multicast architecture. Note that i think it is perfectly fine to have separe unicast and multicast topologies, it just has to be a problem of routing protocols, not a problem of tree building protocols. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 19:08:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10953 for ; Tue, 23 Mar 2004 18:20:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBl-0000vu-U4; Tue, 23 Mar 2004 18:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tDD-00075t-BB for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:13:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24962 for ; Tue, 23 Mar 2004 15:24:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sRn-0002Js-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:24:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5sQp-0002H6-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:23:27 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5sQM-0002Cm-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:22:59 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2004 12:28:33 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2NKMQUe026250; Tue, 23 Mar 2004 12:22:26 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA24963; Tue, 23 Mar 2004 12:22:26 -0800 (PST) Date: Tue, 23 Mar 2004 12:22:25 -0800 From: Toerless Eckert To: Bill Fenner Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323202225.GH17887@cisco.com> References: <200403231937.i2NJbeb10375@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403231937.i2NJbeb10375@windsor.research.att.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 11:37:39AM -0800, Bill Fenner wrote: > > >I was wondering what kind of discussion has preceeded these > >decisions, as and what the large group of people is that is in > >agreement with it. > > The BGMP status was a bug in the presentation; it is indeed planning > to go to Informational (although the only feedback on the BGMP WG > mailing list was that it should go Experimental instead). Ok. > The DVMRP status discussion happened on the IDMR WG list. As far as > I know, nothing has changed about DVMRP being an acceptable routing > protocol for small networks. It achieves not insignificant optimization > by combining tree buidling and route dissemination. I can not find an applicability statement outlining that DVMRP is only considered to be acceptable for small networks because of both flood & prune behavior, non-modular protocol design and non-scalable RPF routing protocol. Can you point me to that statement in the draft ? Thanks Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 19:08:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11068 for ; Tue, 23 Mar 2004 18:20:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBy-0001B2-2s for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNKFNx003955 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBl-0000vu-U4; Tue, 23 Mar 2004 18:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tDD-00075t-BB for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:13:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24962 for ; Tue, 23 Mar 2004 15:24:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sRn-0002Js-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:24:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5sQp-0002H6-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:23:27 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5sQM-0002Cm-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 15:22:59 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2004 12:28:33 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2NKMQUe026250; Tue, 23 Mar 2004 12:22:26 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA24963; Tue, 23 Mar 2004 12:22:26 -0800 (PST) Date: Tue, 23 Mar 2004 12:22:25 -0800 From: Toerless Eckert To: Bill Fenner Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323202225.GH17887@cisco.com> References: <200403231937.i2NJbeb10375@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403231937.i2NJbeb10375@windsor.research.att.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 11:37:39AM -0800, Bill Fenner wrote: > > >I was wondering what kind of discussion has preceeded these > >decisions, as and what the large group of people is that is in > >agreement with it. > > The BGMP status was a bug in the presentation; it is indeed planning > to go to Informational (although the only feedback on the BGMP WG > mailing list was that it should go Experimental instead). Ok. > The DVMRP status discussion happened on the IDMR WG list. As far as > I know, nothing has changed about DVMRP being an acceptable routing > protocol for small networks. It achieves not insignificant optimization > by combining tree buidling and route dissemination. I can not find an applicability statement outlining that DVMRP is only considered to be acceptable for small networks because of both flood & prune behavior, non-modular protocol design and non-scalable RPF routing protocol. Can you point me to that statement in the draft ? Thanks Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 19:08:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10960 for ; Tue, 23 Mar 2004 18:20:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBm-0000wA-Iz; Tue, 23 Mar 2004 18:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tJJ-0007bo-Oh for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:19:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01063 for ; Tue, 23 Mar 2004 16:19:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tJH-0002ix-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:19:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5tHH-0002Gd-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:17:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B5tE0-0001R2-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:14:17 -0500 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2NLDgew008559; Tue, 23 Mar 2004 13:13:42 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA20661; Tue, 23 Mar 2004 13:13:41 -0800 (PST) Date: Tue, 23 Mar 2004 13:13:39 -0800 From: Toerless Eckert To: Jeremy Hall Cc: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323211339.GO17887@cisco.com> References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232100.i2NL0hdW001327@sith.maoz.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 04:00:43PM -0500, Jeremy Hall wrote: > > Other question: How would changing the IETF status of the documents > > improve on the chance of getting working IP multicast deployment. > > Eg: Almost all of the protocol specs are everything but helpful to > > understand the challenges of IP multicast deployment. > > > If we make it clear what is useful, but not relevant to current > deployment, new implementors will have an easier time deciding what > exactly to implement and how to make that happen. With more vendors > coming online WRT multicast, the more likelihood the code will be present > on day 1 when a new router vendor is deployed into the industry. So you think that new vendors should implement DVMRP ? I also have my doubts about the way you describe the behavior of vendors who now get into the game. I don't think they care about what's written in the specs themselves - in my experience, commodity vendors do implement whatever tops their RFPs as long as it is an RFC - never mind it's status. Last but not least: Let's not target vendors but rather users with whatever we do, eg: ISPs and enterprises! _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 19:08:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11067 for ; Tue, 23 Mar 2004 18:20:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBy-0001Az-2P for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNKFXC003957 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vBm-0000wA-Iz; Tue, 23 Mar 2004 18:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tJJ-0007bo-Oh for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 16:19:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01063 for ; Tue, 23 Mar 2004 16:19:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tJH-0002ix-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:19:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5tHH-0002Gd-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:17:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1B5tE0-0001R2-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 16:14:17 -0500 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2NLDgew008559; Tue, 23 Mar 2004 13:13:42 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA20661; Tue, 23 Mar 2004 13:13:41 -0800 (PST) Date: Tue, 23 Mar 2004 13:13:39 -0800 From: Toerless Eckert To: Jeremy Hall Cc: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323211339.GO17887@cisco.com> References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232100.i2NL0hdW001327@sith.maoz.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 04:00:43PM -0500, Jeremy Hall wrote: > > Other question: How would changing the IETF status of the documents > > improve on the chance of getting working IP multicast deployment. > > Eg: Almost all of the protocol specs are everything but helpful to > > understand the challenges of IP multicast deployment. > > > If we make it clear what is useful, but not relevant to current > deployment, new implementors will have an easier time deciding what > exactly to implement and how to make that happen. With more vendors > coming online WRT multicast, the more likelihood the code will be present > on day 1 when a new router vendor is deployed into the industry. So you think that new vendors should implement DVMRP ? I also have my doubts about the way you describe the behavior of vendors who now get into the game. I don't think they care about what's written in the specs themselves - in my experience, commodity vendors do implement whatever tops their RFPs as long as it is an RFC - never mind it's status. Last but not least: Let's not target vendors but rather users with whatever we do, eg: ISPs and enterprises! _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 19:11:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13590 for ; Tue, 23 Mar 2004 19:11:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vz3-0006JJ-TW; Tue, 23 Mar 2004 19:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vtt-0005tk-1F for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:05:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13337 for ; Tue, 23 Mar 2004 19:05:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vtp-0004BK-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:05:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vt4-000489-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:04:51 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B5vsi-00042H-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:04:28 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O2AsAw086480; Tue, 23 Mar 2004 18:10:54 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O03ld1026382; Tue, 23 Mar 2004 16:03:47 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O03k9u010632; Tue, 23 Mar 2004 16:03:46 -0800 Date: Tue, 23 Mar 2004 16:03:46 -0800 Message-Id: <200403240003.i2O03k9u010632@dino-pc.procket.com> From: Dino Farinacci To: fenner@research.att.com CC: eckert@cisco.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu In-reply-to: <200403232330.i2NNUNk13398@windsor.research.att.com> (message from Bill Fenner on Tue, 23 Mar 2004 15:30:22 -0800) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> <20040323232041.GR17887@cisco.com> <200403232330.i2NNUNk13398@windsor.research.att.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> I don't get it. DVMRP is more flexible than IGMP proxying and more >> efficient than PIM-DM, but you want the IETF to try to remove it from >> the selection of tools that a customer may have available? The IETF should not make any subjective calls on technology. They have been wrong in the past and will continue to be wrong in the future. We (the IETF) need to build the right stuff. And sometimes that means, not the too creative stuff. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 19:11:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13605 for ; Tue, 23 Mar 2004 19:11:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vzF-0006NX-Rx for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 19:11:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O0BDn7024492 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 19:11:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vz3-0006JJ-TW; Tue, 23 Mar 2004 19:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vtt-0005tk-1F for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:05:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13337 for ; Tue, 23 Mar 2004 19:05:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vtp-0004BK-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:05:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vt4-000489-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:04:51 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B5vsi-00042H-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:04:28 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O2AsAw086480; Tue, 23 Mar 2004 18:10:54 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O03ld1026382; Tue, 23 Mar 2004 16:03:47 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O03k9u010632; Tue, 23 Mar 2004 16:03:46 -0800 Date: Tue, 23 Mar 2004 16:03:46 -0800 Message-Id: <200403240003.i2O03k9u010632@dino-pc.procket.com> From: Dino Farinacci To: fenner@research.att.com CC: eckert@cisco.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu In-reply-to: <200403232330.i2NNUNk13398@windsor.research.att.com> (message from Bill Fenner on Tue, 23 Mar 2004 15:30:22 -0800) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> <20040323232041.GR17887@cisco.com> <200403232330.i2NNUNk13398@windsor.research.att.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> I don't get it. DVMRP is more flexible than IGMP proxying and more >> efficient than PIM-DM, but you want the IETF to try to remove it from >> the selection of tools that a customer may have available? The IETF should not make any subjective calls on technology. They have been wrong in the past and will continue to be wrong in the future. We (the IETF) need to build the right stuff. And sometimes that means, not the too creative stuff. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 19:23:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11955 for ; Tue, 23 Mar 2004 18:33:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vOM-0002vb-4U for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNX6cT011101 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vOH-0002rO-HS; Tue, 23 Mar 2004 18:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vNt-0002qh-0P for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 18:32:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11932 for ; Tue, 23 Mar 2004 18:32:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vNq-0001Ab-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:32:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vMw-00017L-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:31:39 -0500 Received: from mail-dark.research.att.com ([192.20.225.112]) by ietf-mx with esmtp (Exim 4.12) id 1B5vMJ-0000zJ-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:30:59 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-dark.research.att.com (Postfix) with ESMTP id 5D971E80E5; Tue, 23 Mar 2004 18:30:24 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 4E5B9F3A9C; Tue, 23 Mar 2004 18:30:24 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i2NNUNk13398; Tue, 23 Mar 2004 15:30:23 -0800 (PST) Message-Id: <200403232330.i2NNUNk13398@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> <20040323232041.GR17887@cisco.com> Date: Tue, 23 Mar 2004 15:30:22 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >If they think they have a market for RIP, then they should implement it, >as well as IGMP proxying or PIM-DM, but not DVMRP. I don't get it. DVMRP is more flexible than IGMP proxying and more efficient than PIM-DM, but you want the IETF to try to remove it from the selection of tools that a customer may have available? Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 19:23:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11959 for ; Tue, 23 Mar 2004 18:33:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vOI-0002sF-Q7; Tue, 23 Mar 2004 18:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vEB-0001rl-Eg for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 18:22:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11233 for ; Tue, 23 Mar 2004 18:22:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vE8-0000CJ-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:22:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vDF-00008x-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:21:37 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5vCs-00005M-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:21:14 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2004 15:26:50 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2NNKgBB017267; Tue, 23 Mar 2004 15:20:42 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA17890; Tue, 23 Mar 2004 15:20:42 -0800 (PST) Date: Tue, 23 Mar 2004 15:20:41 -0800 From: Toerless Eckert To: Bill Fenner Cc: jhall@maoz.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323232041.GR17887@cisco.com> References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232150.i2NLoud12156@windsor.research.att.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 01:50:54PM -0800, Bill Fenner wrote: > I don't think that the integration of routing and tree building protocol > is a problem on the scale that DVMRP is useful. It may affect the > scalability, but other of DVMRP's problems are probably more important. > > [Sorry, combining replies to two different messages] > >So you think that new vendors should implement DVMRP ? > > Well, should new vendors implement RIP? If they think they have a market for RIP, then they should implement it, as well as IGMP proxying or PIM-DM, but not DVMRP. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 19:23:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11960 for ; Tue, 23 Mar 2004 18:33:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vOM-0002vc-4P for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNX6PG011100 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 18:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vOI-0002sF-Q7; Tue, 23 Mar 2004 18:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vEB-0001rl-Eg for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 18:22:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11233 for ; Tue, 23 Mar 2004 18:22:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vE8-0000CJ-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:22:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vDF-00008x-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:21:37 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5vCs-00005M-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 18:21:14 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 23 Mar 2004 15:26:50 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2NNKgBB017267; Tue, 23 Mar 2004 15:20:42 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA17890; Tue, 23 Mar 2004 15:20:42 -0800 (PST) Date: Tue, 23 Mar 2004 15:20:41 -0800 From: Toerless Eckert To: Bill Fenner Cc: jhall@maoz.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040323232041.GR17887@cisco.com> References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232150.i2NLoud12156@windsor.research.att.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 01:50:54PM -0800, Bill Fenner wrote: > I don't think that the integration of routing and tree building protocol > is a problem on the scale that DVMRP is useful. It may affect the > scalability, but other of DVMRP's problems are probably more important. > > [Sorry, combining replies to two different messages] > >So you think that new vendors should implement DVMRP ? > > Well, should new vendors implement RIP? If they think they have a market for RIP, then they should implement it, as well as IGMP proxying or PIM-DM, but not DVMRP. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 19:39:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14770 for ; Tue, 23 Mar 2004 19:39:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wQ8-0000ji-IL; Tue, 23 Mar 2004 19:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wPu-0000iY-M7 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:38:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14741 for ; Tue, 23 Mar 2004 19:38:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wPs-00077i-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:38:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wP2-000732-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:37:53 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B5wOC-0006vY-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:37:00 -0500 Received: (qmail 51746 invoked from network); 24 Mar 2004 00:42:48 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 00:42:48 -0000 Message-ID: <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 09:39:37 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Toerless Eckert CC: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> In-Reply-To: <20040323204008.GJ17887@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Toerless Eckert wrote: > Imagine for example everybody who has Internet at home today would be > able to do IP multicast across the Internet to everybody else in the > Internet. Do you really think that would work with ASM ? And i am > not even talking about MSDP scalability, let's assume we have really > brutally well scaling implementations (*grin*). I am talking about > the basic DoS problem of the ASM service model and the nature of the > Internet at large. Neither MSDP nor BGMP scales, regardless of how you implement it. > Eg: Are there protocols on standards track that have similar applicability > limitations ? All. However, more fundamental problem is that almost no one understand what is the appropriate scalability requirement for multicast. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 19:39:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14779 for ; Tue, 23 Mar 2004 19:39:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wQE-0000l1-Mt for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 19:39:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O0d6hb002883 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 19:39:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wQ8-0000ji-IL; Tue, 23 Mar 2004 19:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wPu-0000iY-M7 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:38:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14741 for ; Tue, 23 Mar 2004 19:38:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wPs-00077i-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:38:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wP2-000732-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:37:53 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B5wOC-0006vY-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:37:00 -0500 Received: (qmail 51746 invoked from network); 24 Mar 2004 00:42:48 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 00:42:48 -0000 Message-ID: <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 09:39:37 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Toerless Eckert CC: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> In-Reply-To: <20040323204008.GJ17887@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Toerless Eckert wrote: > Imagine for example everybody who has Internet at home today would be > able to do IP multicast across the Internet to everybody else in the > Internet. Do you really think that would work with ASM ? And i am > not even talking about MSDP scalability, let's assume we have really > brutally well scaling implementations (*grin*). I am talking about > the basic DoS problem of the ASM service model and the nature of the > Internet at large. Neither MSDP nor BGMP scales, regardless of how you implement it. > Eg: Are there protocols on standards track that have similar applicability > limitations ? All. However, more fundamental problem is that almost no one understand what is the appropriate scalability requirement for multicast. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 19:51:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15175 for ; Tue, 23 Mar 2004 19:51:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wbk-0001fx-U4; Tue, 23 Mar 2004 19:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wbQ-0001Zx-Aj for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:50:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15152 for ; Tue, 23 Mar 2004 19:50:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wbO-0000D3-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:50:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5waY-000094-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:49:47 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B5wZk-0007nq-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:48:56 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O2tFAw086922; Tue, 23 Mar 2004 18:55:15 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O0m7d1028356; Tue, 23 Mar 2004 16:48:07 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O0m65d011919; Tue, 23 Mar 2004 16:48:06 -0800 Date: Tue, 23 Mar 2004 16:48:06 -0800 Message-Id: <200403240048.i2O0m65d011919@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 09:39:37 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> Neither MSDP nor BGMP scales, regardless of how you implement it. Correction. Any protocol scales to a specific level or size. From my inspection, MSDP seems to be holding around 2500-3000 sources right now. What has done that before it's time? And BGMP could work too, it's all a matter of cost and complexity. After all we got OSPF to work, you think that was cheap? >> However, more fundamental problem is that almost no one >> understand what is the appropriate scalability requirement >> for multicast. I think people do, but as time goes on, things keep changing and people change their mind. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 20:00:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15596 for ; Tue, 23 Mar 2004 20:00:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkX-0002JZ-AY; Tue, 23 Mar 2004 20:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wiF-00025s-Fh for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:57:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15498 for ; Tue, 23 Mar 2004 19:57:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wiD-0000s1-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:57:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5whJ-0000oV-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:56:45 -0500 Received: from mail-dark.research.att.com ([192.20.225.112]) by ietf-mx with esmtp (Exim 4.12) id 1B5wgw-0000kd-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:56:22 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-dark.research.att.com (Postfix) with ESMTP id 1FCEAE80E5; Tue, 23 Mar 2004 19:55:49 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 0A770F3A9C; Tue, 23 Mar 2004 19:55:49 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i2O0tlj14483; Tue, 23 Mar 2004 16:55:47 -0800 (PST) Message-Id: <200403240055.i2O0tlj14483@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> <20040323232041.GR17887@cisco.com> <200403232330.i2NNUNk13398@windsor.research.att.com> <20040324004254.GX17887@cisco.com> Date: Tue, 23 Mar 2004 16:55:44 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >architecturally, i think the IETF should promote IGMP proxying over >DVMRP for simple routers because of explicit join vs. flood & prune as >well as simplicity I think that IGMP proxying is too simple to be deployed in networks with more than one router. >and it should promote PIM-DM over DVMRP because of >clear separation of RPF and trees. I still don't see why this aspect is so important. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 20:00:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15599 for ; Tue, 23 Mar 2004 20:00:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkk-0002Qe-RT for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:00:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O10IAa009099 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:00:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkV-0002IY-Uf; Tue, 23 Mar 2004 20:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5whD-0001xE-Bf for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:56:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15454 for ; Tue, 23 Mar 2004 19:56:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5whB-0000nb-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:56:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wgC-0000j3-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:55:37 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5wfG-0000aO-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:54:38 -0500 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2O0s5Kj002712; Tue, 23 Mar 2004 16:54:06 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA09523; Tue, 23 Mar 2004 16:54:05 -0800 (PST) Date: Tue, 23 Mar 2004 16:54:05 -0800 From: Toerless Eckert To: Masataka Ohta Cc: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324005405.GY17887@cisco.com> References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, Mar 24, 2004 at 09:39:37AM +0900, Masataka Ohta wrote: > Neither MSDP nor BGMP scales, regardless of how you implement it. > > > Eg: Are there protocols on standards track that have similar applicability > > limitations ? > > All. ;-)) > However, more fundamental problem is that almost no one > understand what is the appropriate scalability requirement > for multicast. Good point. I actually have pretty simple ideas about the level of scalability at which i'd call multicast successfull enough for the time being: - IP multicast service connectivity between all hosts that also have IP unicast connnectivity. - few 100k worth of active application instances across the Internet core. And i think we can do this with SSM or ASM/embeddeRP today. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 20:00:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15594 for ; Tue, 23 Mar 2004 20:00:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkV-0002IY-Uf; Tue, 23 Mar 2004 20:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5whD-0001xE-Bf for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:56:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15454 for ; Tue, 23 Mar 2004 19:56:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5whB-0000nb-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:56:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wgC-0000j3-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:55:37 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5wfG-0000aO-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:54:38 -0500 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2O0s5Kj002712; Tue, 23 Mar 2004 16:54:06 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA09523; Tue, 23 Mar 2004 16:54:05 -0800 (PST) Date: Tue, 23 Mar 2004 16:54:05 -0800 From: Toerless Eckert To: Masataka Ohta Cc: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324005405.GY17887@cisco.com> References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, Mar 24, 2004 at 09:39:37AM +0900, Masataka Ohta wrote: > Neither MSDP nor BGMP scales, regardless of how you implement it. > > > Eg: Are there protocols on standards track that have similar applicability > > limitations ? > > All. ;-)) > However, more fundamental problem is that almost no one > understand what is the appropriate scalability requirement > for multicast. Good point. I actually have pretty simple ideas about the level of scalability at which i'd call multicast successfull enough for the time being: - IP multicast service connectivity between all hosts that also have IP unicast connnectivity. - few 100k worth of active application instances across the Internet core. And i think we can do this with SSM or ASM/embeddeRP today. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 20:00:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15702 for ; Tue, 23 Mar 2004 20:00:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkY-0002LI-Pj; Tue, 23 Mar 2004 20:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wVe-000154-LM for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:44:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15010 for ; Tue, 23 Mar 2004 19:44:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wVc-0007aL-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:44:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wUj-0007WU-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:43:46 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5wUR-0007S5-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:43:27 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2004 16:47:54 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2O0gtKj022610; Tue, 23 Mar 2004 16:42:55 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA01313; Tue, 23 Mar 2004 16:42:55 -0800 (PST) Date: Tue, 23 Mar 2004 16:42:54 -0800 From: Toerless Eckert To: Bill Fenner Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324004254.GX17887@cisco.com> References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> <20040323232041.GR17887@cisco.com> <200403232330.i2NNUNk13398@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232330.i2NNUNk13398@windsor.research.att.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 03:30:22PM -0800, Bill Fenner wrote: > > >If they think they have a market for RIP, then they should implement it, > >as well as IGMP proxying or PIM-DM, but not DVMRP. > > I don't get it. DVMRP is more flexible than IGMP proxying and more > efficient than PIM-DM Are we playing quartett with cards of protocols now ? If so, then yes, you win. If not: architecturally, i think the IETF should promote IGMP proxying over DVMRP for simple routers because of explicit join vs. flood & prune as well as simplicity, and it should promote PIM-DM over DVMRP because of clear separation of RPF and trees. > but you want the IETF to try to remove it from > the selection of tools that a customer may have available? Where did i say that the IETF should remove it from the selection ? I just said that it fits best into worthy historic artefacts section of the shelf - in my opinion. Or else: please define what the selection of the IETF is. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 20:09:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15992 for ; Tue, 23 Mar 2004 20:09:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wtG-0003PE-Gh for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:09:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O196eg013083 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:09:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wtA-0003O4-Sg; Tue, 23 Mar 2004 20:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wsn-0003N4-VQ for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:08:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15962 for ; Tue, 23 Mar 2004 20:08:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wsl-0001cI-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:08:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wrr-0001Yb-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:07:40 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B5wrM-0001VP-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:07:09 -0500 Received: (qmail 51916 invoked from network); 24 Mar 2004 01:13:07 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 01:13:07 -0000 Message-ID: <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 10:09:55 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Toerless Eckert CC: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> In-Reply-To: <20040324005405.GY17887@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Toerless Eckert wrote: >>However, more fundamental problem is that almost no one >>understand what is the appropriate scalability requirement >>for multicast. > Good point. I actually have pretty simple ideas about the level of > scalability at which i'd call multicast successfull enough for the time > being: > > - IP multicast service connectivity between all hosts that also > have IP unicast connnectivity. > - few 100k worth of active application instances across the Internet core. > > And i think we can do this with SSM or ASM/embeddeRP today. Not at all. The basic problem is that multicast routing table entries can not be aggregated, as was proven in our INET'98 paper, which makes multicast communication resource (routing table entry) reserving one. That is, multicast scales only if people pay money proportional to the duration and area of the communication and the payment mechanisms are scalably automated. Note that RSVP and related protocols made it completely wrongly. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 20:09:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15993 for ; Tue, 23 Mar 2004 20:09:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wtA-0003O4-Sg; Tue, 23 Mar 2004 20:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wsn-0003N4-VQ for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:08:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15962 for ; Tue, 23 Mar 2004 20:08:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wsl-0001cI-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:08:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wrr-0001Yb-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:07:40 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B5wrM-0001VP-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:07:09 -0500 Received: (qmail 51916 invoked from network); 24 Mar 2004 01:13:07 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 01:13:07 -0000 Message-ID: <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 10:09:55 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Toerless Eckert CC: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> In-Reply-To: <20040324005405.GY17887@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Toerless Eckert wrote: >>However, more fundamental problem is that almost no one >>understand what is the appropriate scalability requirement >>for multicast. > Good point. I actually have pretty simple ideas about the level of > scalability at which i'd call multicast successfull enough for the time > being: > > - IP multicast service connectivity between all hosts that also > have IP unicast connnectivity. > - few 100k worth of active application instances across the Internet core. > > And i think we can do this with SSM or ASM/embeddeRP today. Not at all. The basic problem is that multicast routing table entries can not be aggregated, as was proven in our INET'98 paper, which makes multicast communication resource (routing table entry) reserving one. That is, multicast scales only if people pay money proportional to the duration and area of the communication and the payment mechanisms are scalably automated. Note that RSVP and related protocols made it completely wrongly. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 20:15:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16409 for ; Tue, 23 Mar 2004 20:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wyz-0003wU-SS; Tue, 23 Mar 2004 20:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wym-0003w6-Db for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:14:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16372 for ; Tue, 23 Mar 2004 20:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wyk-0002GY-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:14:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wxm-0002C5-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:13:46 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B5wx3-00022h-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:13:01 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O3JLAw087141; Tue, 23 Mar 2004 19:19:21 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O1CEd1029291; Tue, 23 Mar 2004 17:12:14 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O1CAnp012572; Tue, 23 Mar 2004 17:12:10 -0800 Date: Tue, 23 Mar 2004 17:12:10 -0800 Message-Id: <200403240112.i2O1CAnp012572@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 09:59:39 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <200403240048.i2O0m65d011919@dino-pc.procket.com> <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> You misunderstand the word "scale". Does any protocol then scale if I decide that my table size needs to be 5,000,000 routes? I guess IPv6 scales because it has 128 bits? ;-) Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 20:15:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16411 for ; Tue, 23 Mar 2004 20:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wz4-0003ym-2o for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:15:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O1F60m015217 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:15:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wyz-0003wU-SS; Tue, 23 Mar 2004 20:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wym-0003w6-Db for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:14:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16372 for ; Tue, 23 Mar 2004 20:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wyk-0002GY-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:14:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wxm-0002C5-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:13:46 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B5wx3-00022h-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:13:01 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O3JLAw087141; Tue, 23 Mar 2004 19:19:21 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O1CEd1029291; Tue, 23 Mar 2004 17:12:14 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O1CAnp012572; Tue, 23 Mar 2004 17:12:10 -0800 Date: Tue, 23 Mar 2004 17:12:10 -0800 Message-Id: <200403240112.i2O1CAnp012572@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 09:59:39 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <200403240048.i2O0m65d011919@dino-pc.procket.com> <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> You misunderstand the word "scale". Does any protocol then scale if I decide that my table size needs to be 5,000,000 routes? I guess IPv6 scales because it has 128 bits? ;-) Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 20:17:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16507 for ; Tue, 23 Mar 2004 20:17:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5x15-0004Ak-0g for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:17:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O1HAeC016004 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:17:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5x0w-000475-3B; Tue, 23 Mar 2004 20:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5x0X-00046K-N6 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:16:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16480 for ; Tue, 23 Mar 2004 20:16:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5x0V-0002QJ-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:16:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wzY-0002LC-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:15:36 -0500 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1B5wye-0002Ce-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:14:40 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O3O7pL064641; Tue, 23 Mar 2004 19:24:07 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O1Drd1029348; Tue, 23 Mar 2004 17:13:53 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O1DrZU012583; Tue, 23 Mar 2004 17:13:53 -0800 Date: Tue, 23 Mar 2004 17:13:53 -0800 Message-Id: <200403240113.i2O1DrZU012583@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 10:09:55 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> The basic problem is that multicast routing table entries can >> not be aggregated, as was proven in our INET'98 paper, which >> makes multicast communication resource (routing table entry) >> reserving one. If you use a shared tree where a group range uses the same root, you can aggregate the state. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 20:18:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16566 for ; Tue, 23 Mar 2004 20:18:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5x1t-0004L1-Pc for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:18:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O1I1s4016674 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5x1t-0004KC-E9; Tue, 23 Mar 2004 20:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5x1h-0004JR-Ua for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:17:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16550 for ; Tue, 23 Mar 2004 20:17:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5x1f-0002XT-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:17:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5x0m-0002Si-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:16:53 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5wzw-0002Ig-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:16:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2004 17:20:27 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2O1FSUe014998; Tue, 23 Mar 2004 17:15:28 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA16312; Tue, 23 Mar 2004 17:15:28 -0800 (PST) Date: Tue, 23 Mar 2004 17:15:28 -0800 From: Toerless Eckert To: Bill Fenner Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324011528.GC17887@cisco.com> References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> <20040323232041.GR17887@cisco.com> <200403232330.i2NNUNk13398@windsor.research.att.com> <20040324004254.GX17887@cisco.com> <200403240055.i2O0tlj14483@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403240055.i2O0tlj14483@windsor.research.att.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 04:55:44PM -0800, Bill Fenner wrote: > > >architecturally, i think the IETF should promote IGMP proxying over > >DVMRP for simple routers because of explicit join vs. flood & prune as > >well as simplicity > > I think that IGMP proxying is too simple to be deployed in networks with > more than one router. To be more precise - any stub network without redundancy or with extreme simple redundancy. Like for example two PIM core router connecting to 20 DSL-RBAS routers that are only running IGMP proxy and that connect each to maybe - 20k users@home, each of which has a home router also with IGMP proxy. To me that is something like 400,020 routers. But based on your definition of a network, it might as well be 400,020 networks of one router each... There is a set of other similar stub network scenarios where i'd pray to get IGMP proxying any time before i get a flood&prune edge. (of course a fully PIM/SM/Bidir/SSM based network is better, but i think that wasn't considered to be under contention anyhow, right ?) > >and it should promote PIM-DM over DVMRP because of > >clear separation of RPF and trees. > > I still don't see why this aspect is so important. Reuse of operational (unicast) knowledge, strong promotion of congruent ubiquitous deployment, knowledge separation between unicast topology and multicast tree engineering and troubleshooting, simplicity, minimization of reinvention of the wheel, personal preferences, pigheadedness. Nevertheless, i would never admire a PIM-DM trophy in a museum, while i would do so for DVMRP: If we have to recommend a flood&prune protocol in the IETF at all, then i would simply choose PIM-DM out of necessity (reasons above), as much as i may admire the more elegant design of DVMRP. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 20:29:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17093 for ; Tue, 23 Mar 2004 20:29:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5xCX-000560-KG; Tue, 23 Mar 2004 20:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5xCT-000551-2e for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:28:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17006 for ; Tue, 23 Mar 2004 20:28:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5xCQ-0003as-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:28:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5xBT-0003QQ-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:27:56 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B5x9e-0003Es-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:26:02 -0500 Received: (qmail 52029 invoked from network); 24 Mar 2004 01:32:01 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 01:32:01 -0000 Message-ID: <4060E451.4000006@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 10:28:49 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> In-Reply-To: <200403240113.i2O1DrZU012583@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: >>>The basic problem is that multicast routing table entries can >>>not be aggregated, as was proven in our INET'98 paper, which >>>makes multicast communication resource (routing table entry) >>>reserving one. > If you use a shared tree where a group range uses the same root, you > can aggregate the state. Wrong, completely. Route from source to the tree root, which essentially is unicast, can be aggregated. Route from the root to the receivers can not be. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 20:29:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17095 for ; Tue, 23 Mar 2004 20:29:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5xCd-00058I-MF for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O1T7xm019659 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:29:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5xCX-000560-KG; Tue, 23 Mar 2004 20:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5xCT-000551-2e for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:28:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17006 for ; Tue, 23 Mar 2004 20:28:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5xCQ-0003as-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:28:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5xBT-0003QQ-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:27:56 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B5x9e-0003Es-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:26:02 -0500 Received: (qmail 52029 invoked from network); 24 Mar 2004 01:32:01 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 01:32:01 -0000 Message-ID: <4060E451.4000006@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 10:28:49 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> In-Reply-To: <200403240113.i2O1DrZU012583@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: >>>The basic problem is that multicast routing table entries can >>>not be aggregated, as was proven in our INET'98 paper, which >>>makes multicast communication resource (routing table entry) >>>reserving one. > If you use a shared tree where a group range uses the same root, you > can aggregate the state. Wrong, completely. Route from source to the tree root, which essentially is unicast, can be aggregated. Route from the root to the receivers can not be. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 20:38:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15176 for ; Tue, 23 Mar 2004 19:51:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wbv-0001hY-EM for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 19:51:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O0pBaM006509 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 19:51:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wbk-0001fx-U4; Tue, 23 Mar 2004 19:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wbQ-0001Zx-Aj for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:50:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15152 for ; Tue, 23 Mar 2004 19:50:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wbO-0000D3-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:50:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5waY-000094-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:49:47 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B5wZk-0007nq-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:48:56 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O2tFAw086922; Tue, 23 Mar 2004 18:55:15 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O0m7d1028356; Tue, 23 Mar 2004 16:48:07 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O0m65d011919; Tue, 23 Mar 2004 16:48:06 -0800 Date: Tue, 23 Mar 2004 16:48:06 -0800 Message-Id: <200403240048.i2O0m65d011919@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 09:39:37 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> Neither MSDP nor BGMP scales, regardless of how you implement it. Correction. Any protocol scales to a specific level or size. From my inspection, MSDP seems to be holding around 2500-3000 sources right now. What has done that before it's time? And BGMP could work too, it's all a matter of cost and complexity. After all we got OSPF to work, you think that was cheap? >> However, more fundamental problem is that almost no one >> understand what is the appropriate scalability requirement >> for multicast. I think people do, but as time goes on, things keep changing and people change their mind. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 20:38:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17649 for ; Tue, 23 Mar 2004 20:38:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5xLH-0006P9-M3 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:38:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O1c3Hp024571 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5xLE-0006Mo-N5; Tue, 23 Mar 2004 20:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5xKx-0006Hc-4G for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:37:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17593 for ; Tue, 23 Mar 2004 20:37:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5xKu-0004XN-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:37:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5xK4-0004Rl-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:36:49 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B5xJE-0004MG-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:35:56 -0500 Received: (qmail 52075 invoked from network); 24 Mar 2004 01:41:55 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 01:41:55 -0000 Message-ID: <4060E6A2.3060107@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 10:38:42 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <200403240048.i2O0m65d011919@dino-pc.procket.com> <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> <200403240112.i2O1CAnp012572@dino-pc.procket.com> In-Reply-To: <200403240112.i2O1CAnp012572@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: >>>You misunderstand the word "scale". > Does any protocol then scale if I decide that my table size needs to be > 5,000,000 routes? Yes, of course. With a proper parallel architecture and protocol, it costs about O(N*log(N)) to support N routes that 5,000,000 is doable. > I guess IPv6 scales because it has 128 bits? ;-) It does not, though IP architecture does scale. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 20:48:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15595 for ; Tue, 23 Mar 2004 20:00:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkY-0002KX-4J; Tue, 23 Mar 2004 20:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wj9-0002Cq-9u for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:58:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15513 for ; Tue, 23 Mar 2004 19:58:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wj7-0000wC-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:58:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wiF-0000sI-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:57:43 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B5whQ-0000ot-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:56:53 -0500 Received: (qmail 51856 invoked from network); 24 Mar 2004 01:02:51 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 01:02:51 -0000 Message-ID: <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 09:59:39 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <200403240048.i2O0m65d011919@dino-pc.procket.com> In-Reply-To: <200403240048.i2O0m65d011919@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: >>>Neither MSDP nor BGMP scales, regardless of how you implement it. > Correction. Any protocol scales to a specific level or size. You misunderstand the word "scale". Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 20:48:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15598 for ; Tue, 23 Mar 2004 20:00:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkk-0002Qd-Qw for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:00:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O10ITg009098 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:00:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkY-0002KX-4J; Tue, 23 Mar 2004 20:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wj9-0002Cq-9u for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:58:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15513 for ; Tue, 23 Mar 2004 19:58:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wj7-0000wC-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:58:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wiF-0000sI-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:57:43 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B5whQ-0000ot-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:56:53 -0500 Received: (qmail 51856 invoked from network); 24 Mar 2004 01:02:51 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 01:02:51 -0000 Message-ID: <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 09:59:39 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <200403240048.i2O0m65d011919@dino-pc.procket.com> In-Reply-To: <200403240048.i2O0m65d011919@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: >>>Neither MSDP nor BGMP scales, regardless of how you implement it. > Correction. Any protocol scales to a specific level or size. You misunderstand the word "scale". Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 20:48:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15620 for ; Tue, 23 Mar 2004 20:00:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkk-0002Qf-RE for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:00:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O10IDh009100 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:00:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkX-0002JZ-AY; Tue, 23 Mar 2004 20:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wiF-00025s-Fh for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:57:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15498 for ; Tue, 23 Mar 2004 19:57:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wiD-0000s1-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:57:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5whJ-0000oV-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:56:45 -0500 Received: from mail-dark.research.att.com ([192.20.225.112]) by ietf-mx with esmtp (Exim 4.12) id 1B5wgw-0000kd-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:56:22 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-dark.research.att.com (Postfix) with ESMTP id 1FCEAE80E5; Tue, 23 Mar 2004 19:55:49 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 0A770F3A9C; Tue, 23 Mar 2004 19:55:49 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i2O0tlj14483; Tue, 23 Mar 2004 16:55:47 -0800 (PST) Message-Id: <200403240055.i2O0tlj14483@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> <20040323232041.GR17887@cisco.com> <200403232330.i2NNUNk13398@windsor.research.att.com> <20040324004254.GX17887@cisco.com> Date: Tue, 23 Mar 2004 16:55:44 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >architecturally, i think the IETF should promote IGMP proxying over >DVMRP for simple routers because of explicit join vs. flood & prune as >well as simplicity I think that IGMP proxying is too simple to be deployed in networks with more than one router. >and it should promote PIM-DM over DVMRP because of >clear separation of RPF and trees. I still don't see why this aspect is so important. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 23 20:48:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15597 for ; Tue, 23 Mar 2004 20:00:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkk-0002Pz-Os for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:00:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O10Iru009097 for routing-discussion-archive@odin.ietf.org; Tue, 23 Mar 2004 20:00:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wkY-0002LI-Pj; Tue, 23 Mar 2004 20:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5wVe-000154-LM for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 19:44:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15010 for ; Tue, 23 Mar 2004 19:44:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5wVc-0007aL-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:44:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wUj-0007WU-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:43:46 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5wUR-0007S5-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 19:43:27 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2004 16:47:54 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2O0gtKj022610; Tue, 23 Mar 2004 16:42:55 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA01313; Tue, 23 Mar 2004 16:42:55 -0800 (PST) Date: Tue, 23 Mar 2004 16:42:54 -0800 From: Toerless Eckert To: Bill Fenner Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324004254.GX17887@cisco.com> References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> <20040323232041.GR17887@cisco.com> <200403232330.i2NNUNk13398@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232330.i2NNUNk13398@windsor.research.att.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 03:30:22PM -0800, Bill Fenner wrote: > > >If they think they have a market for RIP, then they should implement it, > >as well as IGMP proxying or PIM-DM, but not DVMRP. > > I don't get it. DVMRP is more flexible than IGMP proxying and more > efficient than PIM-DM Are we playing quartett with cards of protocols now ? If so, then yes, you win. If not: architecturally, i think the IETF should promote IGMP proxying over DVMRP for simple routers because of explicit join vs. flood & prune as well as simplicity, and it should promote PIM-DM over DVMRP because of clear separation of RPF and trees. > but you want the IETF to try to remove it from > the selection of tools that a customer may have available? Where did i say that the IETF should remove it from the selection ? I just said that it fits best into worthy historic artefacts section of the shelf - in my opinion. Or else: please define what the selection of the IETF is. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 21:03:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16506 for ; Tue, 23 Mar 2004 20:17:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5x0w-000475-3B; Tue, 23 Mar 2004 20:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5x0X-00046K-N6 for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:16:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16480 for ; Tue, 23 Mar 2004 20:16:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5x0V-0002QJ-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:16:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5wzY-0002LC-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:15:36 -0500 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1B5wye-0002Ce-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:14:40 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O3O7pL064641; Tue, 23 Mar 2004 19:24:07 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O1Drd1029348; Tue, 23 Mar 2004 17:13:53 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O1DrZU012583; Tue, 23 Mar 2004 17:13:53 -0800 Date: Tue, 23 Mar 2004 17:13:53 -0800 Message-Id: <200403240113.i2O1DrZU012583@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 10:09:55 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> The basic problem is that multicast routing table entries can >> not be aggregated, as was proven in our INET'98 paper, which >> makes multicast communication resource (routing table entry) >> reserving one. If you use a shared tree where a group range uses the same root, you can aggregate the state. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 21:08:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16567 for ; Tue, 23 Mar 2004 20:18:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5x1t-0004KC-E9; Tue, 23 Mar 2004 20:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5x1h-0004JR-Ua for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:17:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16550 for ; Tue, 23 Mar 2004 20:17:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5x1f-0002XT-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:17:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5x0m-0002Si-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:16:53 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5wzw-0002Ig-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:16:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2004 17:20:27 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2O1FSUe014998; Tue, 23 Mar 2004 17:15:28 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA16312; Tue, 23 Mar 2004 17:15:28 -0800 (PST) Date: Tue, 23 Mar 2004 17:15:28 -0800 From: Toerless Eckert To: Bill Fenner Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324011528.GC17887@cisco.com> References: <20040323204924.GL17887@cisco.com> <200403232100.i2NL0hdW001327@sith.maoz.com> <20040323211339.GO17887@cisco.com> <200403232150.i2NLoud12156@windsor.research.att.com> <20040323232041.GR17887@cisco.com> <200403232330.i2NNUNk13398@windsor.research.att.com> <20040324004254.GX17887@cisco.com> <200403240055.i2O0tlj14483@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403240055.i2O0tlj14483@windsor.research.att.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 04:55:44PM -0800, Bill Fenner wrote: > > >architecturally, i think the IETF should promote IGMP proxying over > >DVMRP for simple routers because of explicit join vs. flood & prune as > >well as simplicity > > I think that IGMP proxying is too simple to be deployed in networks with > more than one router. To be more precise - any stub network without redundancy or with extreme simple redundancy. Like for example two PIM core router connecting to 20 DSL-RBAS routers that are only running IGMP proxy and that connect each to maybe - 20k users@home, each of which has a home router also with IGMP proxy. To me that is something like 400,020 routers. But based on your definition of a network, it might as well be 400,020 networks of one router each... There is a set of other similar stub network scenarios where i'd pray to get IGMP proxying any time before i get a flood&prune edge. (of course a fully PIM/SM/Bidir/SSM based network is better, but i think that wasn't considered to be under contention anyhow, right ?) > >and it should promote PIM-DM over DVMRP because of > >clear separation of RPF and trees. > > I still don't see why this aspect is so important. Reuse of operational (unicast) knowledge, strong promotion of congruent ubiquitous deployment, knowledge separation between unicast topology and multicast tree engineering and troubleshooting, simplicity, minimization of reinvention of the wheel, personal preferences, pigheadedness. Nevertheless, i would never admire a PIM-DM trophy in a museum, while i would do so for DVMRP: If we have to recommend a flood&prune protocol in the IETF at all, then i would simply choose PIM-DM out of necessity (reasons above), as much as i may admire the more elegant design of DVMRP. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 23 21:28:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17648 for ; Tue, 23 Mar 2004 20:38:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5xLE-0006Mo-N5; Tue, 23 Mar 2004 20:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5xKx-0006Hc-4G for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 20:37:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17593 for ; Tue, 23 Mar 2004 20:37:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5xKu-0004XN-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:37:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5xK4-0004Rl-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:36:49 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B5xJE-0004MG-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 20:35:56 -0500 Received: (qmail 52075 invoked from network); 24 Mar 2004 01:41:55 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 01:41:55 -0000 Message-ID: <4060E6A2.3060107@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 10:38:42 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <200403240048.i2O0m65d011919@dino-pc.procket.com> <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> <200403240112.i2O1CAnp012572@dino-pc.procket.com> In-Reply-To: <200403240112.i2O1CAnp012572@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: >>>You misunderstand the word "scale". > Does any protocol then scale if I decide that my table size needs to be > 5,000,000 routes? Yes, of course. With a proper parallel architecture and protocol, it costs about O(N*log(N)) to support N routes that 5,000,000 is doable. > I guess IPv6 scales because it has 128 bits? ;-) It does not, though IP architecture does scale. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 01:09:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29223 for ; Wed, 24 Mar 2004 01:09:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61ZV-0008ER-2I; Wed, 24 Mar 2004 01:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61YY-0008Br-NR for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:08:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29107 for ; Wed, 24 Mar 2004 01:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61YV-0003Xo-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:07:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61Xc-0003Mv-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:07:04 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B61X9-0003C5-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:06:35 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O8CqAw089296; Wed, 24 Mar 2004 00:12:52 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O65id1010977; Tue, 23 Mar 2004 22:05:44 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O65eYI013376; Tue, 23 Mar 2004 22:05:40 -0800 Date: Tue, 23 Mar 2004 22:05:40 -0800 Message-Id: <200403240605.i2O65eYI013376@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <4060E451.4000006@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 10:28:49 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> Wrong, completely. >> >> Route from source to the tree root, which essentially is unicast, >> can be aggregated. >> >> Route from the root to the receivers can not be. Sorry, I have an existance proof (read: implementation). Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 01:09:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29240 for ; Wed, 24 Mar 2004 01:09:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61Zf-0008G4-Sf for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:09:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O69B3K031717 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:09:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61ZV-0008ER-2I; Wed, 24 Mar 2004 01:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61YY-0008Br-NR for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:08:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29107 for ; Wed, 24 Mar 2004 01:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61YV-0003Xo-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:07:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61Xc-0003Mv-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:07:04 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B61X9-0003C5-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:06:35 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O8CqAw089296; Wed, 24 Mar 2004 00:12:52 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O65id1010977; Tue, 23 Mar 2004 22:05:44 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O65eYI013376; Tue, 23 Mar 2004 22:05:40 -0800 Date: Tue, 23 Mar 2004 22:05:40 -0800 Message-Id: <200403240605.i2O65eYI013376@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <4060E451.4000006@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 10:28:49 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> Wrong, completely. >> >> Route from source to the tree root, which essentially is unicast, >> can be aggregated. >> >> Route from the root to the receivers can not be. Sorry, I have an existance proof (read: implementation). Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 01:13:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29569 for ; Wed, 24 Mar 2004 01:13:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61dN-0000g6-3B; Wed, 24 Mar 2004 01:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61cm-0000eB-Mx for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:12:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29408 for ; Wed, 24 Mar 2004 01:12:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61cj-0004Ib-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:12:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61bX-00045M-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:11:07 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B61ak-0003uK-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:10:19 -0500 Received: (qmail 52992 invoked from network); 24 Mar 2004 06:16:21 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 06:16:21 -0000 Message-ID: <406126F2.90903@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 15:13:06 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> In-Reply-To: <200403240605.i2O65eYI013376@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: >>>Wrong, completely. >>> >>>Route from source to the tree root, which essentially is unicast, >>>can be aggregated. >>> >>>Route from the root to the receivers can not be. > Sorry, I have an existance proof (read: implementation). Sorry, you don't have any proof. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 01:22:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29977 for ; Wed, 24 Mar 2004 01:22:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61lg-00019r-L0; Wed, 24 Mar 2004 01:21:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61fc-0000tl-Mm for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:15:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29725 for ; Wed, 24 Mar 2004 01:15:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61fZ-0004uq-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61eK-0004hU-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:14:01 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B61dT-0004Jf-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:13:08 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O8JSAw089374; Wed, 24 Mar 2004 00:19:28 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O6CKd1011353; Tue, 23 Mar 2004 22:12:20 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O6CKbI013415; Tue, 23 Mar 2004 22:12:20 -0800 Date: Tue, 23 Mar 2004 22:12:20 -0800 Message-Id: <200403240612.i2O6CKbI013415@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <406126F2.90903@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 15:13:06 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> Sorry, you don't have any proof. Then I guess I nothing more to discuss with you. Thanks for wasting my time. I can only blame myself. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 01:35:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00539 for ; Wed, 24 Mar 2004 01:35:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61yh-00025g-7Y; Wed, 24 Mar 2004 01:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61yV-00024f-IN for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:34:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00465 for ; Wed, 24 Mar 2004 01:34:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61yS-0000bG-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:34:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61xU-0000Pc-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:33:49 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B61wa-00004L-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:32:52 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O8dIAw089527; Wed, 24 Mar 2004 00:39:18 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O6W6d1012305; Tue, 23 Mar 2004 22:32:06 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O6W6aA013496; Tue, 23 Mar 2004 22:32:06 -0800 Date: Tue, 23 Mar 2004 22:32:06 -0800 Message-Id: <200403240632.i2O6W6aA013496@dino-pc.procket.com> From: Dino Farinacci To: kimai@labs.fujitsu.com CC: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <20040324132957Q.kimai@labs.fujitsu.com> (message from IMAI Yuji on Wed, 24 Mar 2004 13:29:57 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <200403240048.i2O0m65d011919@dino-pc.procket.com> <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> Could you tell us why you consider 5,000 is enough and >> 5,000,000 is too much for the Internet, please? My point is that "scaling" is relative. >> Please, could you tell us why you consider 5,000 is enough and >> 5,000,000 is too much for the Internet, Dino? I said "routes" in the general sense. And when I was typing the message I was thinking unicast routes. But I do believe we can build routers that can support 50K to 100K multicast routes. We can for unicast so I don't see why we can't do it for multicast. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 01:35:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00552 for ; Wed, 24 Mar 2004 01:35:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61yl-00027l-2J for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:35:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O6Z7Kq008130 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:35:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61yh-00025g-7Y; Wed, 24 Mar 2004 01:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61yV-00024f-IN for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:34:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00465 for ; Wed, 24 Mar 2004 01:34:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61yS-0000bG-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:34:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61xU-0000Pc-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:33:49 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B61wa-00004L-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:32:52 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O8dIAw089527; Wed, 24 Mar 2004 00:39:18 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O6W6d1012305; Tue, 23 Mar 2004 22:32:06 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O6W6aA013496; Tue, 23 Mar 2004 22:32:06 -0800 Date: Tue, 23 Mar 2004 22:32:06 -0800 Message-Id: <200403240632.i2O6W6aA013496@dino-pc.procket.com> From: Dino Farinacci To: kimai@labs.fujitsu.com CC: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <20040324132957Q.kimai@labs.fujitsu.com> (message from IMAI Yuji on Wed, 24 Mar 2004 13:29:57 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <200403240048.i2O0m65d011919@dino-pc.procket.com> <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> Could you tell us why you consider 5,000 is enough and >> 5,000,000 is too much for the Internet, please? My point is that "scaling" is relative. >> Please, could you tell us why you consider 5,000 is enough and >> 5,000,000 is too much for the Internet, Dino? I said "routes" in the general sense. And when I was typing the message I was thinking unicast routes. But I do believe we can build routers that can support 50K to 100K multicast routes. We can for unicast so I don't see why we can't do it for multicast. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 01:36:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00619 for ; Wed, 24 Mar 2004 01:36:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61ze-0002Py-OA; Wed, 24 Mar 2004 01:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61yq-0002BQ-BT for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:35:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00534 for ; Wed, 24 Mar 2004 01:35:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61yn-0000dw-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:35:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61xq-0000Sy-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:34:10 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B61xO-0000Hf-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:33:42 -0500 Received: (qmail 53112 invoked from network); 24 Mar 2004 06:39:45 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 06:39:45 -0000 Message-ID: <40612C6E.7070906@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 15:36:30 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> In-Reply-To: <200403240612.i2O6CKbI013415@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: >>>Sorry, you don't have any proof. > > > Then I guess I nothing more to discuss with you. Thank you confirming that you have nothing to discuss rest of us. Bye. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 01:43:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01172 for ; Wed, 24 Mar 2004 01:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B626R-0003UU-BM for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O6h33m013413 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B626P-0003Tz-A0; Wed, 24 Mar 2004 01:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B625a-0003Sd-Qd for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:42:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01079 for ; Wed, 24 Mar 2004 01:42:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B625X-00022i-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:42:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B624g-0001qE-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:41:14 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B623y-0001co-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:40:30 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O8kpAw089593; Wed, 24 Mar 2004 00:46:51 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O6dhd1012920; Tue, 23 Mar 2004 22:39:43 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O6dhVt013525; Tue, 23 Mar 2004 22:39:43 -0800 Date: Tue, 23 Mar 2004 22:39:43 -0800 Message-Id: <200403240639.i2O6dhVt013525@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <40612C6E.7070906@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 15:36:30 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> Thank you confirming that you have nothing to discuss >> rest of us. Bye. No, just you (see original email below). I'm having several very good private discussions on this topic as I type. Dino ------------------------------------------------------------------------------- Date: Wed, 24 Mar 2004 15:36:30 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403240612.i2O6CKbI013415@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Dino Farinacci wrote: >>>Sorry, you don't have any proof. > > > Then I guess I nothing more to discuss with you. Thank you confirming that you have nothing to discuss rest of us. Bye. Masataka Ohta ------------------------------------------------------------------------------- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 01:43:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01189 for ; Wed, 24 Mar 2004 01:43:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B626P-0003Tz-A0; Wed, 24 Mar 2004 01:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B625a-0003Sd-Qd for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:42:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01079 for ; Wed, 24 Mar 2004 01:42:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B625X-00022i-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:42:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B624g-0001qE-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:41:14 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B623y-0001co-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:40:30 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O8kpAw089593; Wed, 24 Mar 2004 00:46:51 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O6dhd1012920; Tue, 23 Mar 2004 22:39:43 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O6dhVt013525; Tue, 23 Mar 2004 22:39:43 -0800 Date: Tue, 23 Mar 2004 22:39:43 -0800 Message-Id: <200403240639.i2O6dhVt013525@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <40612C6E.7070906@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 15:36:30 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> Thank you confirming that you have nothing to discuss >> rest of us. Bye. No, just you (see original email below). I'm having several very good private discussions on this topic as I type. Dino ------------------------------------------------------------------------------- Date: Wed, 24 Mar 2004 15:36:30 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403240612.i2O6CKbI013415@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Dino Farinacci wrote: >>>Sorry, you don't have any proof. > > > Then I guess I nothing more to discuss with you. Thank you confirming that you have nothing to discuss rest of us. Bye. Masataka Ohta ------------------------------------------------------------------------------- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 01:48:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01465 for ; Wed, 24 Mar 2004 01:48:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62BE-00045S-PZ; Wed, 24 Mar 2004 01:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62AK-00044l-H8 for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:47:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01399 for ; Wed, 24 Mar 2004 01:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B62AH-00031B-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:47:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B629P-0002py-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:46:08 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B628X-0002eF-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:45:13 -0500 Received: (qmail 53194 invoked from network); 24 Mar 2004 06:51:17 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 06:51:17 -0000 Message-ID: <40612F22.3090700@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 15:48:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> <200403240639.i2O6dhVt013525@dino-pc.procket.com> In-Reply-To: <200403240639.i2O6dhVt013525@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: > I'm having several very good private discussions on this topic as I type. That's fine. Please keep them private forever. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 01:48:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01466 for ; Wed, 24 Mar 2004 01:48:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62BL-00048F-9q for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:48:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O6m7Oi015821 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:48:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62BE-00045S-PZ; Wed, 24 Mar 2004 01:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62AK-00044l-H8 for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:47:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01399 for ; Wed, 24 Mar 2004 01:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B62AH-00031B-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:47:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B629P-0002py-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:46:08 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B628X-0002eF-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:45:13 -0500 Received: (qmail 53194 invoked from network); 24 Mar 2004 06:51:17 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 06:51:17 -0000 Message-ID: <40612F22.3090700@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 15:48:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> <200403240639.i2O6dhVt013525@dino-pc.procket.com> In-Reply-To: <200403240639.i2O6dhVt013525@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: > I'm having several very good private discussions on this topic as I type. That's fine. Please keep them private forever. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 01:58:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02058 for ; Wed, 24 Mar 2004 01:58:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62Ku-0004iZ-Vs; Wed, 24 Mar 2004 01:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62K2-0004hK-I8 for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:57:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01972 for ; Wed, 24 Mar 2004 01:57:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B62Jz-0005BZ-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:57:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B62J8-0004zY-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:56:11 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B62IN-0004jz-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:55:23 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2004 22:59:54 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2O6sqUe011102; Tue, 23 Mar 2004 22:54:52 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id WAA03281; Tue, 23 Mar 2004 22:54:51 -0800 (PST) Date: Tue, 23 Mar 2004 22:54:51 -0800 From: Toerless Eckert To: Jeremy Hall Cc: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324065451.GM17887@cisco.com> References: <20040323211339.GO17887@cisco.com> <200403232205.i2NM5BPf002061@sith.maoz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232205.i2NM5BPf002061@sith.maoz.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 05:05:11PM -0500, Jeremy Hall wrote: > > I also have my doubts about the way you describe the behavior of vendors > > who now get into the game. I don't think they care about what's written > > in the specs themselves - in my experience, commodity vendors do implement > > whatever tops their RFPs as long as it is an RFC - never mind it's status. > > > If a vendor waited for an RFP, it is already behind the game curve. > Vendors that already understand the industry are welcomed inthusiastically > by ISPs. Vendors that must be hand-held are more the norm and thus we're > used to it, but if this happened in the unicast world, nobody would > tolerate it. Imagine if there was as much confusion surrounding MPLS as > there is surrounding multicast. Sure there are many flavours of MPLS out > there, but the fundamentals aren't disputed. Are RSVP and LDP considered > experimental protocols? Quite in agreement, Jeremy. I specifically said commodity vendors, and the diffeentiation i make is that a commodity vendor is one that would never bother to implement something that's still a draft. > > Last but not least: Let's not target vendors but rather users with > > whatever we do, eg: ISPs and enterprises! > > By making the relevant protocols proposed standards, ISPs have an easier > time getting the vendors to comply. Yes, but for this to happen, the ISPs have to drive the process. IETF participation of customers in protocols is quite varyng, and for those that primarily are of interest (maybe only today) to enterprises, unfortunately there isn't much participation. > In the end, resistence is futile to progress, and anything that does > not provide a clear direction is resistence. ? Come again, Locutus ? ;-) > I'm not saying we have to throw out this protocol or that one, I'm simply > saying we need to unite together and decide what the direction should be, > whatever that might be. AFAIK ISM and ASM have been going strongly for > several years, perhaps we should come to the table and make some hard > choices. What would you propose ? Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 01:58:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02061 for ; Wed, 24 Mar 2004 01:58:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62Kx-0004jm-SR for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:58:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O6w3En018201 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62Ku-0004iZ-Vs; Wed, 24 Mar 2004 01:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62K2-0004hK-I8 for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:57:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01972 for ; Wed, 24 Mar 2004 01:57:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B62Jz-0005BZ-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:57:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B62J8-0004zY-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:56:11 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B62IN-0004jz-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:55:23 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2004 22:59:54 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2O6sqUe011102; Tue, 23 Mar 2004 22:54:52 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id WAA03281; Tue, 23 Mar 2004 22:54:51 -0800 (PST) Date: Tue, 23 Mar 2004 22:54:51 -0800 From: Toerless Eckert To: Jeremy Hall Cc: David Meyer , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324065451.GM17887@cisco.com> References: <20040323211339.GO17887@cisco.com> <200403232205.i2NM5BPf002061@sith.maoz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232205.i2NM5BPf002061@sith.maoz.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Tue, Mar 23, 2004 at 05:05:11PM -0500, Jeremy Hall wrote: > > I also have my doubts about the way you describe the behavior of vendors > > who now get into the game. I don't think they care about what's written > > in the specs themselves - in my experience, commodity vendors do implement > > whatever tops their RFPs as long as it is an RFC - never mind it's status. > > > If a vendor waited for an RFP, it is already behind the game curve. > Vendors that already understand the industry are welcomed inthusiastically > by ISPs. Vendors that must be hand-held are more the norm and thus we're > used to it, but if this happened in the unicast world, nobody would > tolerate it. Imagine if there was as much confusion surrounding MPLS as > there is surrounding multicast. Sure there are many flavours of MPLS out > there, but the fundamentals aren't disputed. Are RSVP and LDP considered > experimental protocols? Quite in agreement, Jeremy. I specifically said commodity vendors, and the diffeentiation i make is that a commodity vendor is one that would never bother to implement something that's still a draft. > > Last but not least: Let's not target vendors but rather users with > > whatever we do, eg: ISPs and enterprises! > > By making the relevant protocols proposed standards, ISPs have an easier > time getting the vendors to comply. Yes, but for this to happen, the ISPs have to drive the process. IETF participation of customers in protocols is quite varyng, and for those that primarily are of interest (maybe only today) to enterprises, unfortunately there isn't much participation. > In the end, resistence is futile to progress, and anything that does > not provide a clear direction is resistence. ? Come again, Locutus ? ;-) > I'm not saying we have to throw out this protocol or that one, I'm simply > saying we need to unite together and decide what the direction should be, > whatever that might be. AFAIK ISM and ASM have been going strongly for > several years, perhaps we should come to the table and make some hard > choices. What would you propose ? Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 02:00:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29570 for ; Wed, 24 Mar 2004 01:13:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61dP-0000hq-5p for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:13:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O6D3Pr002690 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61dN-0000g6-3B; Wed, 24 Mar 2004 01:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61cm-0000eB-Mx for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:12:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29408 for ; Wed, 24 Mar 2004 01:12:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61cj-0004Ib-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:12:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61bX-00045M-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:11:07 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B61ak-0003uK-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:10:19 -0500 Received: (qmail 52992 invoked from network); 24 Mar 2004 06:16:21 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 06:16:21 -0000 Message-ID: <406126F2.90903@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 15:13:06 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> In-Reply-To: <200403240605.i2O65eYI013376@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: >>>Wrong, completely. >>> >>>Route from source to the tree root, which essentially is unicast, >>>can be aggregated. >>> >>>Route from the root to the receivers can not be. > Sorry, I have an existance proof (read: implementation). Sorry, you don't have any proof. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 02:08:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29979 for ; Wed, 24 Mar 2004 01:22:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61lj-0001CR-GF for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:21:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O6Ld8N004533 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:21:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61lg-00019r-L0; Wed, 24 Mar 2004 01:21:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61fc-0000tl-Mm for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:15:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29725 for ; Wed, 24 Mar 2004 01:15:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61fZ-0004uq-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61eK-0004hU-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:14:01 -0500 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1B61dT-0004Jf-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:13:08 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i2O8JSAw089374; Wed, 24 Mar 2004 00:19:28 -0800 (PST) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2O6CKd1011353; Tue, 23 Mar 2004 22:12:20 -0800 (PST) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i2O6CKbI013415; Tue, 23 Mar 2004 22:12:20 -0800 Date: Tue, 23 Mar 2004 22:12:20 -0800 Message-Id: <200403240612.i2O6CKbI013415@dino-pc.procket.com> From: Dino Farinacci To: mohta@necom830.hpcl.titech.ac.jp CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com In-reply-to: <406126F2.90903@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Wed, 24 Mar 2004 15:13:06 +0900) Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , >> Sorry, you don't have any proof. Then I guess I nothing more to discuss with you. Thanks for wasting my time. I can only blame myself. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 02:23:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00620 for ; Wed, 24 Mar 2004 01:36:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61zf-0002Uy-Fu for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:36:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O6a3UT009508 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 01:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61ze-0002Py-OA; Wed, 24 Mar 2004 01:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61yq-0002BQ-BT for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 01:35:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00534 for ; Wed, 24 Mar 2004 01:35:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61yn-0000dw-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:35:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61xq-0000Sy-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:34:10 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B61xO-0000Hf-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 01:33:42 -0500 Received: (qmail 53112 invoked from network); 24 Mar 2004 06:39:45 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 06:39:45 -0000 Message-ID: <40612C6E.7070906@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 15:36:30 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dino Farinacci CC: eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> In-Reply-To: <200403240612.i2O6CKbI013415@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino Farinacci wrote: >>>Sorry, you don't have any proof. > > > Then I guess I nothing more to discuss with you. Thank you confirming that you have nothing to discuss rest of us. Bye. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 02:25:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25474 for ; Wed, 24 Mar 2004 02:25:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62l3-00065A-4e; Wed, 24 Mar 2004 02:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62kP-0005xZ-5F for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 02:24:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24265 for ; Wed, 24 Mar 2004 02:24:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B62kL-0002g2-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:24:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B62jJ-0002TS-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:23:14 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B62iq-0002HB-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:22:44 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B62ip-000125-4t; Wed, 24 Mar 2004 07:22:43 +0000 Date: Tue, 23 Mar 2004 23:20:19 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <189134218726.20040323232019@psg.com> To: Masataka Ohta CC: Dino Farinacci , eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <40612F22.3090700@necom830.hpcl.titech.ac.jp> References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> <200403240639.i2O6dhVt013525@dino-pc.procket.com> <40612F22.3090700@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Masataka, Please keep it technical and refrain from using offensive tone. -- Alex Zinin Tuesday, March 23, 2004, 10:48:02 PM, Masataka Ohta wrote: > Dino Farinacci wrote: >> I'm having several very good private discussions on this topic as I type. > That's fine. Please keep them private forever. > Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 02:25:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25512 for ; Wed, 24 Mar 2004 02:25:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62lA-0006AV-WA for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 02:25:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O7P8pC023625 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 02:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62l3-00065A-4e; Wed, 24 Mar 2004 02:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62kP-0005xZ-5F for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 02:24:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24265 for ; Wed, 24 Mar 2004 02:24:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B62kL-0002g2-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:24:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B62jJ-0002TS-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:23:14 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B62iq-0002HB-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:22:44 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B62ip-000125-4t; Wed, 24 Mar 2004 07:22:43 +0000 Date: Tue, 23 Mar 2004 23:20:19 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <189134218726.20040323232019@psg.com> To: Masataka Ohta CC: Dino Farinacci , eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <40612F22.3090700@necom830.hpcl.titech.ac.jp> References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> <200403240639.i2O6dhVt013525@dino-pc.procket.com> <40612F22.3090700@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Masataka, Please keep it technical and refrain from using offensive tone. -- Alex Zinin Tuesday, March 23, 2004, 10:48:02 PM, Masataka Ohta wrote: > Dino Farinacci wrote: >> I'm having several very good private discussions on this topic as I type. > That's fine. Please keep them private forever. > Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 02:33:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00904 for ; Wed, 24 Mar 2004 02:33:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62t0-000887-54 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 02:33:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O7XEDv031252 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 02:33:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62sr-00086D-D8; Wed, 24 Mar 2004 02:33:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62op-0007LK-OI for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 02:28:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28561 for ; Wed, 24 Mar 2004 02:28:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B62ol-0003Zf-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:28:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B62np-0003OR-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:27:53 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B62mp-0003C2-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:26:52 -0500 Received: (qmail 53394 invoked from network); 24 Mar 2004 07:32:55 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 07:32:55 -0000 Message-ID: <406138E3.70202@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 16:29:39 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: routing-discussion@ietf.org, mboned@lists.uoregon.edu CC: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> <200403240639.i2O6dhVt013525@dino-pc.procket.com> In-Reply-To: <200403240639.i2O6dhVt013525@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all (save Dino); Below is a short lecture on scalability of multicast and routing. For detailed explanation, see section 2 of my INET paper: http://www.isoc.org/inet98/proceedings/6d/6d_3.htm Routes can be aggregated because 1) packets are routed with destination addresses 2) similar addresses are assigned to hosts in an area With multicast, assumption 2) does not hold. A multicast address is assigned to a dynamic set of destinations in various areas. Those who believe otherwise should first try to solve easier problem of aggregating unicast routes without CIDR. Assign a multicast address to each /24 in IPv4 swamp and aggregate them. With resource reservation with QoS routing, assumption 1) does not hold. In either case, separate routing table entry is necessary for each communication, which is why the communication must be charged proportional to the duration and area of the communication. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 02:43:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01572 for ; Wed, 24 Mar 2004 02:43:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B632S-00019a-UR; Wed, 24 Mar 2004 02:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B631f-00017Q-0o for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 02:42:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01410 for ; Wed, 24 Mar 2004 02:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B631b-0006Jl-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:42:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B630c-00067n-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:41:07 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B62zs-0005wH-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:40:21 -0500 Received: (qmail 53473 invoked from network); 24 Mar 2004 07:46:25 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 07:46:25 -0000 Message-ID: <40613C0D.7010700@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 16:43:09 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Alex Zinin CC: Dino Farinacci , eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> <200403240639.i2O6dhVt013525@dino-pc.procket.com> <40612F22.3090700@necom830.hpcl.titech.ac.jp> <189134218726.20040323232019@psg.com> In-Reply-To: <189134218726.20040323232019@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex Zinin wrote: > Please keep it technical and refrain from using offensive tone. I kept it technical like saying: >>>Route from source to the tree root, which essentially is unicast, >>>can be aggregated. >>> >>>Route from the root to the receivers can not be. What is the technical point of Dino denying my technical statement by just saying: > Sorry, I have an existance proof (read: implementation). without giving any technical point or reference? Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 02:46:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01783 for ; Wed, 24 Mar 2004 02:46:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B635P-0001VU-Hf; Wed, 24 Mar 2004 02:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B634i-0001T3-7A for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 02:45:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01642 for ; Wed, 24 Mar 2004 02:45:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B634e-0006yM-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:45:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B633f-0006i8-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:44:16 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B632f-0006Wj-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:43:13 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B632e-0004uc-S7; Wed, 24 Mar 2004 07:43:12 +0000 Date: Tue, 23 Mar 2004 23:40:44 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <102135443787.20040323234044@psg.com> To: Masataka Ohta CC: Dino Farinacci , eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <40613C0D.7010700@necom830.hpcl.titech.ac.jp> References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> <200403240639.i2O6dhVt013525@dino-pc.procket.com> <40612F22.3090700@necom830.hpcl.titech.ac.jp> <189134218726.20040323232019@psg.com> <40613C0D.7010700@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'll take this off the list. -- Alex Zinin Tuesday, March 23, 2004, 11:43:09 PM, Masataka Ohta wrote: > Alex Zinin wrote: >> Please keep it technical and refrain from using offensive tone. > I kept it technical like saying: >>>>Route from source to the tree root, which essentially is unicast, >>>>can be aggregated. >>>> >>>>Route from the root to the receivers can not be. > What is the technical point of Dino denying my technical statement > by just saying: >> Sorry, I have an existance proof (read: implementation). > without giving any technical point or reference? > Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 03:21:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00906 for ; Wed, 24 Mar 2004 02:33:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62sr-00086D-D8; Wed, 24 Mar 2004 02:33:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62op-0007LK-OI for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 02:28:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28561 for ; Wed, 24 Mar 2004 02:28:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B62ol-0003Zf-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:28:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B62np-0003OR-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:27:53 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B62mp-0003C2-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:26:52 -0500 Received: (qmail 53394 invoked from network); 24 Mar 2004 07:32:55 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 07:32:55 -0000 Message-ID: <406138E3.70202@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 16:29:39 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: routing-discussion@ietf.org, mboned@lists.uoregon.edu CC: eckert@cisco.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> <200403240639.i2O6dhVt013525@dino-pc.procket.com> In-Reply-To: <200403240639.i2O6dhVt013525@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all (save Dino); Below is a short lecture on scalability of multicast and routing. For detailed explanation, see section 2 of my INET paper: http://www.isoc.org/inet98/proceedings/6d/6d_3.htm Routes can be aggregated because 1) packets are routed with destination addresses 2) similar addresses are assigned to hosts in an area With multicast, assumption 2) does not hold. A multicast address is assigned to a dynamic set of destinations in various areas. Those who believe otherwise should first try to solve easier problem of aggregating unicast routes without CIDR. Assign a multicast address to each /24 in IPv4 swamp and aggregate them. With resource reservation with QoS routing, assumption 1) does not hold. In either case, separate routing table entry is necessary for each communication, which is why the communication must be charged proportional to the duration and area of the communication. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 03:33:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01573 for ; Wed, 24 Mar 2004 02:43:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B632Y-0001BS-It for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 02:43:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O7h6bc004540 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 02:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B632S-00019a-UR; Wed, 24 Mar 2004 02:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B631f-00017Q-0o for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 02:42:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01410 for ; Wed, 24 Mar 2004 02:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B631b-0006Jl-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:42:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B630c-00067n-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:41:07 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B62zs-0005wH-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:40:21 -0500 Received: (qmail 53473 invoked from network); 24 Mar 2004 07:46:25 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 07:46:25 -0000 Message-ID: <40613C0D.7010700@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 16:43:09 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Alex Zinin CC: Dino Farinacci , eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> <200403240639.i2O6dhVt013525@dino-pc.procket.com> <40612F22.3090700@necom830.hpcl.titech.ac.jp> <189134218726.20040323232019@psg.com> In-Reply-To: <189134218726.20040323232019@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex Zinin wrote: > Please keep it technical and refrain from using offensive tone. I kept it technical like saying: >>>Route from source to the tree root, which essentially is unicast, >>>can be aggregated. >>> >>>Route from the root to the receivers can not be. What is the technical point of Dino denying my technical statement by just saying: > Sorry, I have an existance proof (read: implementation). without giving any technical point or reference? Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 03:33:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01784 for ; Wed, 24 Mar 2004 02:46:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B635R-0001Y7-Uj for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 02:46:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O7k5WX005941 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 02:46:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B635P-0001VU-Hf; Wed, 24 Mar 2004 02:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B634i-0001T3-7A for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 02:45:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01642 for ; Wed, 24 Mar 2004 02:45:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B634e-0006yM-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:45:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B633f-0006i8-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:44:16 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B632f-0006Wj-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 02:43:13 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B632e-0004uc-S7; Wed, 24 Mar 2004 07:43:12 +0000 Date: Tue, 23 Mar 2004 23:40:44 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <102135443787.20040323234044@psg.com> To: Masataka Ohta CC: Dino Farinacci , eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <40613C0D.7010700@necom830.hpcl.titech.ac.jp> References: <20040323174203.GW17887@cisco.com> <20040323201126.GA4507@1-4-5.net> <20040323204008.GJ17887@cisco.com> <4060D8C9.5070602@necom830.hpcl.titech.ac.jp> <20040324005405.GY17887@cisco.com> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <200403240113.i2O1DrZU012583@dino-pc.procket.com> <4060E451.4000006@necom830.hpcl.titech.ac.jp> <200403240605.i2O65eYI013376@dino-pc.procket.com> <406126F2.90903@necom830.hpcl.titech.ac.jp> <200403240612.i2O6CKbI013415@dino-pc.procket.com> <40612C6E.7070906@necom830.hpcl.titech.ac.jp> <200403240639.i2O6dhVt013525@dino-pc.procket.com> <40612F22.3090700@necom830.hpcl.titech.ac.jp> <189134218726.20040323232019@psg.com> <40613C0D.7010700@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'll take this off the list. -- Alex Zinin Tuesday, March 23, 2004, 11:43:09 PM, Masataka Ohta wrote: > Alex Zinin wrote: >> Please keep it technical and refrain from using offensive tone. > I kept it technical like saying: >>>>Route from source to the tree root, which essentially is unicast, >>>>can be aggregated. >>>> >>>>Route from the root to the receivers can not be. > What is the technical point of Dino denying my technical statement > by just saying: >> Sorry, I have an existance proof (read: implementation). > without giving any technical point or reference? > Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 06:21:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14446 for ; Wed, 24 Mar 2004 06:21:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66RR-0007Q7-5f; Wed, 24 Mar 2004 06:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66Qi-0007O9-6r for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 06:20:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14333 for ; Wed, 24 Mar 2004 06:20:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66Qe-0001DQ-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:20:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66Pj-0000zx-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:19:15 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B66Ov-0000lS-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:18:25 -0500 Received: (qmail 54476 invoked from network); 24 Mar 2004 11:24:26 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 11:24:26 -0000 Message-ID: <40616F22.1020608@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 20:21:06 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: IMAI Yuji CC: dino@procket.com, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <200403240048.i2O0m65d011919@dino-pc.procket.com> <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> In-Reply-To: <20040324132957Q.kimai@labs.fujitsu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit IMAI san; > Could you tell us why you consider 5,000 is enough and > 5,000,000 is too much for the Internet, please? > > Reading your mail, you may feel 5,000,000 routes is ridiculous > requirement. I agree with you if we can limit to use > multicast only for alternative usage of current broadcasting > media like TV and radio. Without regulation on radio wave frequency, there will be a lot lot lot more than 5,000 broadcasters. If multicast is freely available, people with more than two family members at a distance, the number of which will be a lot more than 5,000,000, will want to have a multicast group or two for thier families. That's essentially why multicast must be charged. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 06:21:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14475 for ; Wed, 24 Mar 2004 06:21:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66RY-0007Rm-D6 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 06:21:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OBL8OZ028600 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 06:21:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66RR-0007Q7-5f; Wed, 24 Mar 2004 06:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66Qi-0007O9-6r for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 06:20:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14333 for ; Wed, 24 Mar 2004 06:20:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66Qe-0001DQ-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:20:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66Pj-0000zx-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:19:15 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B66Ov-0000lS-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:18:25 -0500 Received: (qmail 54476 invoked from network); 24 Mar 2004 11:24:26 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 11:24:26 -0000 Message-ID: <40616F22.1020608@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Mar 2004 20:21:06 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: IMAI Yuji CC: dino@procket.com, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <200403240048.i2O0m65d011919@dino-pc.procket.com> <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> In-Reply-To: <20040324132957Q.kimai@labs.fujitsu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit IMAI san; > Could you tell us why you consider 5,000 is enough and > 5,000,000 is too much for the Internet, please? > > Reading your mail, you may feel 5,000,000 routes is ridiculous > requirement. I agree with you if we can limit to use > multicast only for alternative usage of current broadcasting > media like TV and radio. Without regulation on radio wave frequency, there will be a lot lot lot more than 5,000 broadcasters. If multicast is freely available, people with more than two family members at a distance, the number of which will be a lot more than 5,000,000, will want to have a multicast group or two for thier families. That's essentially why multicast must be charged. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 06:34:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15123 for ; Wed, 24 Mar 2004 06:34:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66e4-0008QN-TJ for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 06:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OBY4mE032379 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 06:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66e2-0008PO-4j; Wed, 24 Mar 2004 06:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66dO-0008OT-3P for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 06:33:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15034 for ; Wed, 24 Mar 2004 06:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66dK-00041I-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:33:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66cF-0003mx-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:32:12 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by ietf-mx with esmtp (Exim 4.12) id 1B66bQ-0003Ng-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:31:20 -0500 Received: from m3.gw.fujitsu.co.jp ([10.0.50.73]) by fgwmail6.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id i2OBUo6M005499 for ; Wed, 24 Mar 2004 20:30:50 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from s4.gw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id i2OBUnYx031020 for ; Wed, 24 Mar 2004 20:30:49 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.1]) by s4.gw.fujitsu.co.jp (8.12.10) id i2OBUnI6001764 for ; Wed, 24 Mar 2004 20:30:49 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp by dm.kawasaki.flab.fujitsu.co.jp (8.9.3p2/3.7W-030904-Fujitsu Labs. Kawasaki Domain Mail Master (NAVGW)) id UAA27112; Wed, 24 Mar 2004 20:30:48 +0900 (JST) Received: from guardian.kawasaki.flab.fujitsu.co.jp ([10.25.131.195]) by dm.kawasaki.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2004032420304722068 ; Wed, 24 Mar 2004 20:30:47 +0900 Received: from localhost (localhost [127.0.0.1]) by guardian.kawasaki.flab.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id i2OBfO767821; Wed, 24 Mar 2004 20:41:24 +0900 (JST) (envelope-from kimai@labs.fujitsu.com) To: dino@procket.com Cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403240632.i2O6W6aA013496@dino-pc.procket.com> References: <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> <200403240632.i2O6W6aA013496@dino-pc.procket.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20040324204123N.kimai@labs.fujitsu.com> Date: Wed, 24 Mar 2004 20:41:23 +0900 From: IMAI Yuji X-Dispatcher: imput version 20000228(IM140) Lines: 92 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino, and all. I don't want to be involved in the flaming war. I just want to know and share the truth of multicast. From: Dino Farinacci Subject: Re: mboned: BGMP & DVMRP status Q. Date: Tue, 23 Mar 2004 22:32:06 -0800 > >> Please, could you tell us why you consider 5,000 is enough and > >> 5,000,000 is too much for the Internet, Dino? > > I said "routes" in the general sense. And when I was typing the message > I was thinking unicast routes. Then, you used "routes" as unicast one in following sentence you said, didn't you. ========================================================================= From: Dino Farinacci Message-Id: <200403240112.i2O1CAnp012572@dino-pc.procket.com> Subject: Re: mboned: BGMP & DVMRP status Q. Date: Tue, 23 Mar 2004 17:12:10 -0800 > >> You misunderstand the word "scale". > > Does any protocol then scale if I decide that my table size needs to be > 5,000,000 routes? ========================================================================== OK, Next let's talk about MULTICAST route. As I wrote in previous mail, I want scalable multicast protocol to handle millions of (S,G) type MULTICAST routes. Do you think it reasonable requirement or crazy one, Dino? > But I do believe we can build routers that can support 50K to 100K > multicast routes. To discuss precisely, let me know "100K multicast routes" above are grains of (S,G) entry or aggregated multicast entries by your method. If you mean (S,G), Dino said same opinion with Ohta. Exactly saying, Ohta may be much more aggressive than Dino. He told me once it is easy to handle 1,000,000 (S,G) type multicast routes. As he wrote in his paper of INET98, he analyzed that in order to support 1,000,000 multicast routes, router must store grain (S,G) entries without aggregation and router must handle keep alive messages relatively equal the number of route entry. If he is correct, such router must process keep alive messages almost 4,000 times per second. For me, his analysis seems correct theoretically. However I am not sure it is possible to make, sell and be accepted such monster router in the market. It must cost too expensive. > We can for unicast so I don't see why we can't do it > for multicast. For me, above sentence sounds too rude. (If my expression is politically wrong, I apologize previously.) If we can do the things for multicast as same as for unicast, we have already achieved the multicast deployed Internet ten years ago by the similar method we have deployed unicast. /* * Yes. Ohta always sounds offensive because that's his * style. I don't like his way. However, reading his paper, we * can be aware the point why multicast is not so easy. I keep in * my mind to carefully consider to separate his essence of * theory from impression of him. */ Let me go back and ask all who believe aggregation of multicast route is possible. Show us the method or proof much more precisely. I looked for and read several papers that claims so but I could not be convinced. Alex and Bill, please stop me if above question is trivial in this community and you have convinced about multicast aggregation. And I appreciate if we could avoid the word "believe". It seems easily cause religiouss flaming. Thank you. ---- Yuji _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 07:28:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15124 for ; Wed, 24 Mar 2004 06:34:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66e2-0008PO-4j; Wed, 24 Mar 2004 06:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66dO-0008OT-3P for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 06:33:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15034 for ; Wed, 24 Mar 2004 06:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66dK-00041I-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:33:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66cF-0003mx-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:32:12 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by ietf-mx with esmtp (Exim 4.12) id 1B66bQ-0003Ng-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:31:20 -0500 Received: from m3.gw.fujitsu.co.jp ([10.0.50.73]) by fgwmail6.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id i2OBUo6M005499 for ; Wed, 24 Mar 2004 20:30:50 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from s4.gw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id i2OBUnYx031020 for ; Wed, 24 Mar 2004 20:30:49 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.1]) by s4.gw.fujitsu.co.jp (8.12.10) id i2OBUnI6001764 for ; Wed, 24 Mar 2004 20:30:49 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp by dm.kawasaki.flab.fujitsu.co.jp (8.9.3p2/3.7W-030904-Fujitsu Labs. Kawasaki Domain Mail Master (NAVGW)) id UAA27112; Wed, 24 Mar 2004 20:30:48 +0900 (JST) Received: from guardian.kawasaki.flab.fujitsu.co.jp ([10.25.131.195]) by dm.kawasaki.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2004032420304722068 ; Wed, 24 Mar 2004 20:30:47 +0900 Received: from localhost (localhost [127.0.0.1]) by guardian.kawasaki.flab.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id i2OBfO767821; Wed, 24 Mar 2004 20:41:24 +0900 (JST) (envelope-from kimai@labs.fujitsu.com) To: dino@procket.com Cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403240632.i2O6W6aA013496@dino-pc.procket.com> References: <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> <200403240632.i2O6W6aA013496@dino-pc.procket.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20040324204123N.kimai@labs.fujitsu.com> Date: Wed, 24 Mar 2004 20:41:23 +0900 From: IMAI Yuji X-Dispatcher: imput version 20000228(IM140) Lines: 92 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino, and all. I don't want to be involved in the flaming war. I just want to know and share the truth of multicast. From: Dino Farinacci Subject: Re: mboned: BGMP & DVMRP status Q. Date: Tue, 23 Mar 2004 22:32:06 -0800 > >> Please, could you tell us why you consider 5,000 is enough and > >> 5,000,000 is too much for the Internet, Dino? > > I said "routes" in the general sense. And when I was typing the message > I was thinking unicast routes. Then, you used "routes" as unicast one in following sentence you said, didn't you. ========================================================================= From: Dino Farinacci Message-Id: <200403240112.i2O1CAnp012572@dino-pc.procket.com> Subject: Re: mboned: BGMP & DVMRP status Q. Date: Tue, 23 Mar 2004 17:12:10 -0800 > >> You misunderstand the word "scale". > > Does any protocol then scale if I decide that my table size needs to be > 5,000,000 routes? ========================================================================== OK, Next let's talk about MULTICAST route. As I wrote in previous mail, I want scalable multicast protocol to handle millions of (S,G) type MULTICAST routes. Do you think it reasonable requirement or crazy one, Dino? > But I do believe we can build routers that can support 50K to 100K > multicast routes. To discuss precisely, let me know "100K multicast routes" above are grains of (S,G) entry or aggregated multicast entries by your method. If you mean (S,G), Dino said same opinion with Ohta. Exactly saying, Ohta may be much more aggressive than Dino. He told me once it is easy to handle 1,000,000 (S,G) type multicast routes. As he wrote in his paper of INET98, he analyzed that in order to support 1,000,000 multicast routes, router must store grain (S,G) entries without aggregation and router must handle keep alive messages relatively equal the number of route entry. If he is correct, such router must process keep alive messages almost 4,000 times per second. For me, his analysis seems correct theoretically. However I am not sure it is possible to make, sell and be accepted such monster router in the market. It must cost too expensive. > We can for unicast so I don't see why we can't do it > for multicast. For me, above sentence sounds too rude. (If my expression is politically wrong, I apologize previously.) If we can do the things for multicast as same as for unicast, we have already achieved the multicast deployed Internet ten years ago by the similar method we have deployed unicast. /* * Yes. Ohta always sounds offensive because that's his * style. I don't like his way. However, reading his paper, we * can be aware the point why multicast is not so easy. I keep in * my mind to carefully consider to separate his essence of * theory from impression of him. */ Let me go back and ask all who believe aggregation of multicast route is possible. Show us the method or proof much more precisely. I looked for and read several papers that claims so but I could not be convinced. Alex and Bill, please stop me if above question is trivial in this community and you have convinced about multicast aggregation. And I appreciate if we could avoid the word "believe". It seems easily cause religiouss flaming. Thank you. ---- Yuji _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 07:46:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18930 for ; Wed, 24 Mar 2004 07:46:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67lg-0007oW-OC; Wed, 24 Mar 2004 07:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67kr-0007jq-Qi for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 07:45:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18827 for ; Wed, 24 Mar 2004 07:45:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B67kr-00054k-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 07:45:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B67jq-0004qR-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 07:44:07 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by ietf-mx with esmtp (Exim 4.12) id 1B67io-0004Qk-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 07:43:02 -0500 Received: from m2.gw.fujitsu.co.jp ([10.0.50.72]) by fgwmail6.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id i2OCgU6M026166 for ; Wed, 24 Mar 2004 21:42:30 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from s0.gw.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id i2OCgUsj022814 for ; Wed, 24 Mar 2004 21:42:30 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.1]) by s0.gw.fujitsu.co.jp (8.12.10) id i2OCgTnD011435 for ; Wed, 24 Mar 2004 21:42:29 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp by dm.kawasaki.flab.fujitsu.co.jp (8.9.3p2/3.7W-030904-Fujitsu Labs. Kawasaki Domain Mail Master (NAVGW)) id VAA01384; Wed, 24 Mar 2004 21:42:29 +0900 (JST) Received: from guardian.kawasaki.flab.fujitsu.co.jp ([10.25.131.195]) by dm.kawasaki.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2004032421422409888 ; Wed, 24 Mar 2004 21:42:24 +0900 Received: from localhost (localhost [127.0.0.1]) by guardian.kawasaki.flab.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id i2OCr1767908; Wed, 24 Mar 2004 21:53:01 +0900 (JST) (envelope-from kimai@labs.fujitsu.com) To: mohta@necom830.hpcl.titech.ac.jp Cc: dino@procket.com, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <40616F22.1020608@necom830.hpcl.titech.ac.jp> References: <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> <40616F22.1020608@necom830.hpcl.titech.ac.jp> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20040324215300H.kimai@labs.fujitsu.com> Date: Wed, 24 Mar 2004 21:53:00 +0900 From: IMAI Yuji X-Dispatcher: imput version 20000228(IM140) Lines: 54 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Masataka, From: Masataka Ohta Subject: Re: mboned: BGMP & DVMRP status Q. Date: Wed, 24 Mar 2004 20:21:06 +0900 > > Could you tell us why you consider 5,000 is enough and > > 5,000,000 is too much for the Internet, please? > > > > Reading your mail, you may feel 5,000,000 routes is ridiculous > > requirement. I agree with you if we can limit to use > > multicast only for alternative usage of current broadcasting > > media like TV and radio. > > Without regulation on radio wave frequency, there will be a lot > lot lot more than 5,000 broadcasters. > > If multicast is freely available, people with more than two > family members at a distance, the number of which will be a lot > more than 5,000,000, will want to have a multicast group or two > for thier families. > > That's essentially why multicast must be charged. You just talking only about the number of POTENTIAL users. Realistically thinking, configuring and keeping multicast peering costs so expensive that small broadcasters could not pay the money for ISPs. Look squarely at the real current status of multicast. Many distinguished operators and researchers of Internet2 involved in keeping "countable" multicast channels for Access Grid. Inter-domain multicast channel is precious resource, now. And it's you who said From: Masataka Ohta Subject: Re: mboned: BGMP & DVMRP status Q. Date: Wed, 24 Mar 2004 10:09:55 +0900 > That is, multicast scales only if people pay money proportional > to the duration and area of the communication and the payment > mechanisms are scalably automated. How much will you price the multicast channel for the IESG conference by Access Grid? Most difficult point is how to share the expense among ISPs. As it includes political layer factor, it seems almost impossible to decide automatically. Such complicated contract and negotiation will be possible only by limited mega-media. Or you say it's just my "believing" and start flaming? ---- Yuji _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 07:46:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18937 for ; Wed, 24 Mar 2004 07:46:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67ln-0007ql-Ut for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 07:46:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OCk7pg030171 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 07:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67lg-0007oW-OC; Wed, 24 Mar 2004 07:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67kr-0007jq-Qi for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 07:45:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18827 for ; Wed, 24 Mar 2004 07:45:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B67kr-00054k-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 07:45:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B67jq-0004qR-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 07:44:07 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by ietf-mx with esmtp (Exim 4.12) id 1B67io-0004Qk-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 07:43:02 -0500 Received: from m2.gw.fujitsu.co.jp ([10.0.50.72]) by fgwmail6.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id i2OCgU6M026166 for ; Wed, 24 Mar 2004 21:42:30 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from s0.gw.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id i2OCgUsj022814 for ; Wed, 24 Mar 2004 21:42:30 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.1]) by s0.gw.fujitsu.co.jp (8.12.10) id i2OCgTnD011435 for ; Wed, 24 Mar 2004 21:42:29 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp by dm.kawasaki.flab.fujitsu.co.jp (8.9.3p2/3.7W-030904-Fujitsu Labs. Kawasaki Domain Mail Master (NAVGW)) id VAA01384; Wed, 24 Mar 2004 21:42:29 +0900 (JST) Received: from guardian.kawasaki.flab.fujitsu.co.jp ([10.25.131.195]) by dm.kawasaki.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2004032421422409888 ; Wed, 24 Mar 2004 21:42:24 +0900 Received: from localhost (localhost [127.0.0.1]) by guardian.kawasaki.flab.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id i2OCr1767908; Wed, 24 Mar 2004 21:53:01 +0900 (JST) (envelope-from kimai@labs.fujitsu.com) To: mohta@necom830.hpcl.titech.ac.jp Cc: dino@procket.com, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <40616F22.1020608@necom830.hpcl.titech.ac.jp> References: <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> <40616F22.1020608@necom830.hpcl.titech.ac.jp> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20040324215300H.kimai@labs.fujitsu.com> Date: Wed, 24 Mar 2004 21:53:00 +0900 From: IMAI Yuji X-Dispatcher: imput version 20000228(IM140) Lines: 54 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Masataka, From: Masataka Ohta Subject: Re: mboned: BGMP & DVMRP status Q. Date: Wed, 24 Mar 2004 20:21:06 +0900 > > Could you tell us why you consider 5,000 is enough and > > 5,000,000 is too much for the Internet, please? > > > > Reading your mail, you may feel 5,000,000 routes is ridiculous > > requirement. I agree with you if we can limit to use > > multicast only for alternative usage of current broadcasting > > media like TV and radio. > > Without regulation on radio wave frequency, there will be a lot > lot lot more than 5,000 broadcasters. > > If multicast is freely available, people with more than two > family members at a distance, the number of which will be a lot > more than 5,000,000, will want to have a multicast group or two > for thier families. > > That's essentially why multicast must be charged. You just talking only about the number of POTENTIAL users. Realistically thinking, configuring and keeping multicast peering costs so expensive that small broadcasters could not pay the money for ISPs. Look squarely at the real current status of multicast. Many distinguished operators and researchers of Internet2 involved in keeping "countable" multicast channels for Access Grid. Inter-domain multicast channel is precious resource, now. And it's you who said From: Masataka Ohta Subject: Re: mboned: BGMP & DVMRP status Q. Date: Wed, 24 Mar 2004 10:09:55 +0900 > That is, multicast scales only if people pay money proportional > to the duration and area of the communication and the payment > mechanisms are scalably automated. How much will you price the multicast channel for the IESG conference by Access Grid? Most difficult point is how to share the expense among ISPs. As it includes political layer factor, it seems almost impossible to decide automatically. Such complicated contract and negotiation will be possible only by limited mega-media. Or you say it's just my "believing" and start flaming? ---- Yuji _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 10:51:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02198 for ; Wed, 24 Mar 2004 10:51:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ael-0006Xf-0M; Wed, 24 Mar 2004 10:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66eE-0008S5-RZ for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 06:34:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15084 for ; Wed, 24 Mar 2004 06:34:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66eA-0004EO-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:34:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66d6-0003zB-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:33:04 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66c1-0003bs-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:31:57 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2OBVpOr028714; Wed, 24 Mar 2004 11:31:51 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA03581; Wed, 24 Mar 2004 11:31:49 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2OBVn808732; Wed, 24 Mar 2004 11:31:49 GMT Date: Wed, 24 Mar 2004 11:31:49 +0000 From: Tim Chown To: Toerless Eckert Cc: Bill Fenner , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324113149.GC6957@login.ecs.soton.ac.uk> References: <200403231937.i2NJbeb10375@windsor.research.att.com> <20040323202225.GH17887@cisco.com> <200403232131.i2NLVil11930@windsor.research.att.com> <20040323214938.GQ17887@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040323214938.GQ17887@cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , www.watersprings.org is your friend. On Tue, Mar 23, 2004 at 01:49:38PM -0800, Toerless Eckert wrote: > On Tue, Mar 23, 2004 at 01:31:43PM -0800, Bill Fenner wrote: > > I would suggest reading the DVMRP applicability statement draft. > > It has statements about scalability of broadcast and prune and the > > route exchange. It also mentions that DVMRP can avoid duplicates by > > precomputing broadcast trees, as well as the state disadvantages of > > precomputing trees. > > > > draft-ietf-idmr-dvmrp-v3-as-00.txt is expired, but you can find > > a copy at http://rtg.ietf.org/~fenner/draft-ietf-idmr-dvmrp-v3-as-00.txt > > Thanks ! > > Now if we could persuade the IETF that 100GB hard disk space to hold > all historical documents on a known public place then this stupid timeout > thing would hit me over and over again *mumble* > _______________________________________________________________ > user interface: http://darkwing.uoregon.edu/~llynch/mboned.html > web archive: http://darkwing.uoregon.edu/~llynch/mboned/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 10:51:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02197 for ; Wed, 24 Mar 2004 10:51:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Aek-0006XV-Ec; Wed, 24 Mar 2004 10:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64C8-0000w7-B6 for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 03:57:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06446 for ; Wed, 24 Mar 2004 03:57:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B64C5-0007gl-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 03:57:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B64BI-0007Vm-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 03:56:13 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by ietf-mx with esmtp (Exim 4.12) id 1B64AT-00078t-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 03:55:21 -0500 Received: from m3.gw.fujitsu.co.jp ([10.0.50.73]) by fgwmail6.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id i2O8sp6M014223 for ; Wed, 24 Mar 2004 17:54:51 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from s6.gw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id i2O8spYx007074 for ; Wed, 24 Mar 2004 17:54:51 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.1]) by s6.gw.fujitsu.co.jp (8.12.10) id i2O8soNc024186 for ; Wed, 24 Mar 2004 17:54:50 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp by dm.kawasaki.flab.fujitsu.co.jp (8.9.3p2/3.7W-030904-Fujitsu Labs. Kawasaki Domain Mail Master (NAVGW)) id RAA15826; Wed, 24 Mar 2004 17:54:50 +0900 (JST) Received: from guardian.kawasaki.flab.fujitsu.co.jp ([10.25.131.195]) by dm.kawasaki.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2004032417544825151 ; Wed, 24 Mar 2004 17:54:49 +0900 Received: from localhost (localhost [127.0.0.1]) by guardian.kawasaki.flab.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id i2O95P767651; Wed, 24 Mar 2004 18:05:25 +0900 (JST) (envelope-from kimai@labs.fujitsu.com) To: dino@procket.com Cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403240632.i2O6W6aA013496@dino-pc.procket.com> References: <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> <200403240632.i2O6W6aA013496@dino-pc.procket.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20040324180524X.kimai@labs.fujitsu.com> Date: Wed, 24 Mar 2004 18:05:24 +0900 From: IMAI Yuji X-Dispatcher: imput version 20000228(IM140) Lines: 83 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, all. From: Dino Farinacci Subject: Re: mboned: BGMP & DVMRP status Q. Date: Tue, 23 Mar 2004 22:32:06 -0800 > >> Could you tell us why you consider 5,000 is enough and > >> 5,000,000 is too much for the Internet, please? > > My point is that "scaling" is relative. > > >> Please, could you tell us why you consider 5,000 is enough and > >> 5,000,000 is too much for the Internet, Dino? > > I said "routes" in the general sense. And when I was typing the message > I was thinking unicast routes. > > But I do believe we can build routers that can support 50K to 100K > multicast routes. We can for unicast so I don't see why we can't do it > for multicast. > > Dino My mail to ask Dino the question on routing-discussion is hold by mailman on www1.ietf.org, I attach it once again. Sorry for mess. ---- Yuji ============================================================================ Subject: Re: mboned: BGMP & DVMRP status Q. From: IMAI Yuji To: dino@procket.com Cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Date: Wed, 24 Mar 2004 13:29:57 +0900 X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Dino, > Does any protocol then scale if I decide that my table size needs to be > 5,000,000 routes? Could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, please? Reading your mail, you may feel 5,000,000 routes is ridiculous requirement. I agree with you if we can limit to use multicast only for alternative usage of current broadcasting media like TV and radio. 5,000 will be enough because almost channel flows from the anchor desks in N.Y., L.A. or Atlanta spread over world wide Internet. Since such flow of popular programs are always received by many ISPs, each routing entry may be very stable and you may be able to assign multicast addresses to aggregate neatly. However, once we want the application like instant message systems with vic & rat, situation change drastically. In other words, why don't you want to provide Access Grid service for the consumer market? Members of a virtual venue are sparsely distributed over the Internet subscribing different ASes. Using SSM or PIM-SM in short cut mode, number of routing entry become as same as number of transmitters. That means routes grows up to millions very easily. To make matter worse, curious customers rapidly loiter from venue to venue, joining and pruning (S,G). Whenever they zap the channel, PIM-SSM signaling travels from receiver to most nearest branching router marking or erasing routing entries. That's why I want you to scale your routers up to millions multicast routes. If you will not, neither we will be support instant video message on the multicast. Again. Please, could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, Dino? ---- Yuji _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 10:51:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02231 for ; Wed, 24 Mar 2004 10:51:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Aej-0006XH-KH; Wed, 24 Mar 2004 10:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ztm-0002vm-Fl for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 23:21:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24185 for ; Tue, 23 Mar 2004 23:21:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ztk-0004f1-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 23:21:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5zsr-0004WU-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 23:20:54 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by ietf-mx with esmtp (Exim 4.12) id 1B5zrv-0004LB-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 23:19:55 -0500 Received: from m5.gw.fujitsu.co.jp ([10.0.50.75]) by fgwmail6.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id i2O4JO6M028432 for ; Wed, 24 Mar 2004 13:19:24 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from s6.gw.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id i2O4JOYt023830 for ; Wed, 24 Mar 2004 13:19:24 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.1]) by s6.gw.fujitsu.co.jp (8.12.10) id i2O4JNNc006834 for ; Wed, 24 Mar 2004 13:19:23 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp by dm.kawasaki.flab.fujitsu.co.jp (8.9.3p2/3.7W-030904-Fujitsu Labs. Kawasaki Domain Mail Master (NAVGW)) id NAA24863; Wed, 24 Mar 2004 13:19:23 +0900 (JST) Received: from guardian.kawasaki.flab.fujitsu.co.jp ([10.25.131.195]) by dm.kawasaki.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2004032413192100861 ; Wed, 24 Mar 2004 13:19:21 +0900 Received: from localhost (localhost [127.0.0.1]) by guardian.kawasaki.flab.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id i2O4Tv767352; Wed, 24 Mar 2004 13:29:57 +0900 (JST) (envelope-from kimai@labs.fujitsu.com) To: dino@procket.com Cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403240112.i2O1CAnp012572@dino-pc.procket.com> References: <200403240048.i2O0m65d011919@dino-pc.procket.com> <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> <200403240112.i2O1CAnp012572@dino-pc.procket.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20040324132957Q.kimai@labs.fujitsu.com> Date: Wed, 24 Mar 2004 13:29:57 +0900 From: IMAI Yuji X-Dispatcher: imput version 20000228(IM140) Lines: 42 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino, > Does any protocol then scale if I decide that my table size needs to be > 5,000,000 routes? Could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, please? Reading your mail, you may feel 5,000,000 routes is ridiculous requirement. I agree with you if we can limit to use multicast only for alternative usage of current broadcasting media like TV and radio. 5,000 will be enough because almost channel flows from the anchor desks in N.Y., L.A. or Atlanta spread over world wide Internet. Since such flow of popular programs are always received by many ISPs, each routing entry may be very stable and you may be able to assign multicast addresses to aggregate neatly. However, once we want the application like instant message systems with vic & rat, situation change drastically. In other words, why don't you want to provide Access Grid service for the consumer market? Members of a virtual venue are sparsely distributed over the Internet subscribing different ASes. Using SSM or PIM-SM in short cut mode, number of routing entry become as same as number of transmitters. That means routes grows up to millions very easily. To make matter worse, curious customers rapidly loiter from venue to venue, joining and pruning (S,G). Whenever they zap the channel, PIM-SSM signaling travels from receiver to most nearest branching router marking or erasing routing entries. That's why I want you to scale your routers up to millions multicast routes. If you will not, neither we will be support instant video message on the multicast. Again. Please, could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, Dino? ---- Yuji _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 10:51:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02242 for ; Wed, 24 Mar 2004 10:51:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Aeu-0006ay-JK for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 10:51:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OFpCBX025296 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 10:51:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ael-0006Xf-0M; Wed, 24 Mar 2004 10:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B66eE-0008S5-RZ for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 06:34:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15084 for ; Wed, 24 Mar 2004 06:34:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66eA-0004EO-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:34:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B66d6-0003zB-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:33:04 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B66c1-0003bs-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 06:31:57 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2OBVpOr028714; Wed, 24 Mar 2004 11:31:51 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA03581; Wed, 24 Mar 2004 11:31:49 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2OBVn808732; Wed, 24 Mar 2004 11:31:49 GMT Date: Wed, 24 Mar 2004 11:31:49 +0000 From: Tim Chown To: Toerless Eckert Cc: Bill Fenner , routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324113149.GC6957@login.ecs.soton.ac.uk> References: <200403231937.i2NJbeb10375@windsor.research.att.com> <20040323202225.GH17887@cisco.com> <200403232131.i2NLVil11930@windsor.research.att.com> <20040323214938.GQ17887@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040323214938.GQ17887@cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , www.watersprings.org is your friend. On Tue, Mar 23, 2004 at 01:49:38PM -0800, Toerless Eckert wrote: > On Tue, Mar 23, 2004 at 01:31:43PM -0800, Bill Fenner wrote: > > I would suggest reading the DVMRP applicability statement draft. > > It has statements about scalability of broadcast and prune and the > > route exchange. It also mentions that DVMRP can avoid duplicates by > > precomputing broadcast trees, as well as the state disadvantages of > > precomputing trees. > > > > draft-ietf-idmr-dvmrp-v3-as-00.txt is expired, but you can find > > a copy at http://rtg.ietf.org/~fenner/draft-ietf-idmr-dvmrp-v3-as-00.txt > > Thanks ! > > Now if we could persuade the IETF that 100GB hard disk space to hold > all historical documents on a known public place then this stupid timeout > thing would hit me over and over again *mumble* > _______________________________________________________________ > user interface: http://darkwing.uoregon.edu/~llynch/mboned.html > web archive: http://darkwing.uoregon.edu/~llynch/mboned/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 10:51:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02265 for ; Wed, 24 Mar 2004 10:51:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Aeu-0006as-JD for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 10:51:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OFpCJF025297 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 10:51:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Aej-0006XH-KH; Wed, 24 Mar 2004 10:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ztm-0002vm-Fl for routing-discussion@optimus.ietf.org; Tue, 23 Mar 2004 23:21:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24185 for ; Tue, 23 Mar 2004 23:21:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ztk-0004f1-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 23:21:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5zsr-0004WU-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 23:20:54 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by ietf-mx with esmtp (Exim 4.12) id 1B5zrv-0004LB-00 for routing-discussion@ietf.org; Tue, 23 Mar 2004 23:19:55 -0500 Received: from m5.gw.fujitsu.co.jp ([10.0.50.75]) by fgwmail6.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id i2O4JO6M028432 for ; Wed, 24 Mar 2004 13:19:24 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from s6.gw.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id i2O4JOYt023830 for ; Wed, 24 Mar 2004 13:19:24 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.1]) by s6.gw.fujitsu.co.jp (8.12.10) id i2O4JNNc006834 for ; Wed, 24 Mar 2004 13:19:23 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp by dm.kawasaki.flab.fujitsu.co.jp (8.9.3p2/3.7W-030904-Fujitsu Labs. Kawasaki Domain Mail Master (NAVGW)) id NAA24863; Wed, 24 Mar 2004 13:19:23 +0900 (JST) Received: from guardian.kawasaki.flab.fujitsu.co.jp ([10.25.131.195]) by dm.kawasaki.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2004032413192100861 ; Wed, 24 Mar 2004 13:19:21 +0900 Received: from localhost (localhost [127.0.0.1]) by guardian.kawasaki.flab.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id i2O4Tv767352; Wed, 24 Mar 2004 13:29:57 +0900 (JST) (envelope-from kimai@labs.fujitsu.com) To: dino@procket.com Cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403240112.i2O1CAnp012572@dino-pc.procket.com> References: <200403240048.i2O0m65d011919@dino-pc.procket.com> <4060DD7B.8080309@necom830.hpcl.titech.ac.jp> <200403240112.i2O1CAnp012572@dino-pc.procket.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20040324132957Q.kimai@labs.fujitsu.com> Date: Wed, 24 Mar 2004 13:29:57 +0900 From: IMAI Yuji X-Dispatcher: imput version 20000228(IM140) Lines: 42 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dino, > Does any protocol then scale if I decide that my table size needs to be > 5,000,000 routes? Could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, please? Reading your mail, you may feel 5,000,000 routes is ridiculous requirement. I agree with you if we can limit to use multicast only for alternative usage of current broadcasting media like TV and radio. 5,000 will be enough because almost channel flows from the anchor desks in N.Y., L.A. or Atlanta spread over world wide Internet. Since such flow of popular programs are always received by many ISPs, each routing entry may be very stable and you may be able to assign multicast addresses to aggregate neatly. However, once we want the application like instant message systems with vic & rat, situation change drastically. In other words, why don't you want to provide Access Grid service for the consumer market? Members of a virtual venue are sparsely distributed over the Internet subscribing different ASes. Using SSM or PIM-SM in short cut mode, number of routing entry become as same as number of transmitters. That means routes grows up to millions very easily. To make matter worse, curious customers rapidly loiter from venue to venue, joining and pruning (S,G). Whenever they zap the channel, PIM-SSM signaling travels from receiver to most nearest branching router marking or erasing routing entries. That's why I want you to scale your routers up to millions multicast routes. If you will not, neither we will be support instant video message on the multicast. Again. Please, could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, Dino? ---- Yuji _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 10:51:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02282 for ; Wed, 24 Mar 2004 10:51:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Aeu-0006ab-Hy for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 10:51:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OFpCkv025295 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 10:51:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Aek-0006XV-Ec; Wed, 24 Mar 2004 10:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64C8-0000w7-B6 for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 03:57:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06446 for ; Wed, 24 Mar 2004 03:57:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B64C5-0007gl-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 03:57:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B64BI-0007Vm-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 03:56:13 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by ietf-mx with esmtp (Exim 4.12) id 1B64AT-00078t-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 03:55:21 -0500 Received: from m3.gw.fujitsu.co.jp ([10.0.50.73]) by fgwmail6.fujitsu.co.jp (8.12.10/Fujitsu Gateway) id i2O8sp6M014223 for ; Wed, 24 Mar 2004 17:54:51 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from s6.gw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id i2O8spYx007074 for ; Wed, 24 Mar 2004 17:54:51 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.1]) by s6.gw.fujitsu.co.jp (8.12.10) id i2O8soNc024186 for ; Wed, 24 Mar 2004 17:54:50 +0900 (envelope-from kimai@labs.fujitsu.com) Received: from dm.kawasaki.flab.fujitsu.co.jp by dm.kawasaki.flab.fujitsu.co.jp (8.9.3p2/3.7W-030904-Fujitsu Labs. Kawasaki Domain Mail Master (NAVGW)) id RAA15826; Wed, 24 Mar 2004 17:54:50 +0900 (JST) Received: from guardian.kawasaki.flab.fujitsu.co.jp ([10.25.131.195]) by dm.kawasaki.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2004032417544825151 ; Wed, 24 Mar 2004 17:54:49 +0900 Received: from localhost (localhost [127.0.0.1]) by guardian.kawasaki.flab.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id i2O95P767651; Wed, 24 Mar 2004 18:05:25 +0900 (JST) (envelope-from kimai@labs.fujitsu.com) To: dino@procket.com Cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403240632.i2O6W6aA013496@dino-pc.procket.com> References: <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> <200403240632.i2O6W6aA013496@dino-pc.procket.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20040324180524X.kimai@labs.fujitsu.com> Date: Wed, 24 Mar 2004 18:05:24 +0900 From: IMAI Yuji X-Dispatcher: imput version 20000228(IM140) Lines: 83 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, all. From: Dino Farinacci Subject: Re: mboned: BGMP & DVMRP status Q. Date: Tue, 23 Mar 2004 22:32:06 -0800 > >> Could you tell us why you consider 5,000 is enough and > >> 5,000,000 is too much for the Internet, please? > > My point is that "scaling" is relative. > > >> Please, could you tell us why you consider 5,000 is enough and > >> 5,000,000 is too much for the Internet, Dino? > > I said "routes" in the general sense. And when I was typing the message > I was thinking unicast routes. > > But I do believe we can build routers that can support 50K to 100K > multicast routes. We can for unicast so I don't see why we can't do it > for multicast. > > Dino My mail to ask Dino the question on routing-discussion is hold by mailman on www1.ietf.org, I attach it once again. Sorry for mess. ---- Yuji ============================================================================ Subject: Re: mboned: BGMP & DVMRP status Q. From: IMAI Yuji To: dino@procket.com Cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Date: Wed, 24 Mar 2004 13:29:57 +0900 X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Dino, > Does any protocol then scale if I decide that my table size needs to be > 5,000,000 routes? Could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, please? Reading your mail, you may feel 5,000,000 routes is ridiculous requirement. I agree with you if we can limit to use multicast only for alternative usage of current broadcasting media like TV and radio. 5,000 will be enough because almost channel flows from the anchor desks in N.Y., L.A. or Atlanta spread over world wide Internet. Since such flow of popular programs are always received by many ISPs, each routing entry may be very stable and you may be able to assign multicast addresses to aggregate neatly. However, once we want the application like instant message systems with vic & rat, situation change drastically. In other words, why don't you want to provide Access Grid service for the consumer market? Members of a virtual venue are sparsely distributed over the Internet subscribing different ASes. Using SSM or PIM-SM in short cut mode, number of routing entry become as same as number of transmitters. That means routes grows up to millions very easily. To make matter worse, curious customers rapidly loiter from venue to venue, joining and pruning (S,G). Whenever they zap the channel, PIM-SSM signaling travels from receiver to most nearest branching router marking or erasing routing entries. That's why I want you to scale your routers up to millions multicast routes. If you will not, neither we will be support instant video message on the multicast. Again. Please, could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, Dino? ---- Yuji _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 11:25:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04344 for ; Wed, 24 Mar 2004 11:25:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BBe-00029e-8J; Wed, 24 Mar 2004 11:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BAz-00025R-Nq for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 11:24:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04282 for ; Wed, 24 Mar 2004 11:24:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BAy-0000fN-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:24:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BA4-0000ci-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:23:25 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1B6B9H-0000VY-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:22:35 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2OGM54e017251; Wed, 24 Mar 2004 08:22:05 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i2OGM5pv017250; Wed, 24 Mar 2004 08:22:05 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 24 Mar 2004 08:22:05 -0800 From: David Meyer To: mboned@lists.uoregon.edu Cc: routing-discussion@ietf.org, zinin@psg.com, fenner@research.att.com Subject: list etiquette [was Re: mboned: BGMP & DVMRP status Q.] Message-ID: <20040324162205.GA16980@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Folks, Just a small note on the thread quoted above: As we all know, IETF mailing lists are maintained for the discussion of IETF technical issues. As such, please keep a professional tone, and stay focused on the technical aspects of the issue(s) at hand. Thanks, Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 11:27:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04486 for ; Wed, 24 Mar 2004 11:27:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BDa-0002Ws-BB; Wed, 24 Mar 2004 11:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BCr-0002VL-4V for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 11:26:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04401 for ; Wed, 24 Mar 2004 11:26:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BCq-0000lI-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:26:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BBx-0000ib-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:25:22 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6BBG-0000dQ-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:24:38 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2OGO70Y518812; Wed, 24 Mar 2004 11:24:07 -0500 Received: from d03nm690.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2OGNun5381978; Wed, 24 Mar 2004 09:23:59 -0700 In-Reply-To: <20040324132957Q.kimai@labs.fujitsu.com> Importance: Normal Subject: Re: mboned: BGMP & DVMRP status Q. To: IMAI Yuji Cc: dino@procket.com, mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Rick Boivie Date: Wed, 24 Mar 2004 11:23:35 -0500 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 03/24/2004 09:23:59 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE4F2DFCAD2128f9e8a93df938690918c0ABBE4F2DFCAD212" Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --0__=0ABBE4F2DFCAD2128f9e8a93df938690918c0ABBE4F2DFCAD212 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Yuji, I agree. It's seems pretty clear that current multicast schemes do not provide v= ery good support for an important class of applications (including IP telephony, videoconferencing, e-meetings, multiplayer games and other applications in which there are= likely to be very large numbers of distinct multicast groups). As the Internet Architecture Board said (in RFC 2902) "providing for ma= ny groups of small conferences ... scales badly given the current multicast model= ". So if we want tapplications like the above to work when there is limite= d bandwidth in the first mile (e.g. DSL, cable modem, wireless etc.) we need a multicast scheme that can support very large or unlimited numbers of small groups. Rick Boivie IBM T. J. Watson Research Center rhboivie@us.ibm.com IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM Sent by: routing-discussion-admin@ietf.org To: dino@procket.com cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.ne= t, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Dino, > Does any protocol then scale if I decide that my table size needs= to be > 5,000,000 routes? Could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, please? Reading your mail, you may feel 5,000,000 routes is ridiculous requirement. I agree with you if we can limit to use multicast only for alternative usage of current broadcasting media like TV and radio. 5,000 will be enough because almost channel flows from the anchor desks in N.Y., L.A. or Atlanta spread over world wide Internet. Since such flow of popular programs are always received by many ISPs, each routing entry may be very stable and you may be able to assign multicast addresses to aggregate neatly. However, once we want the application like instant message systems with vic & rat, situation change drastically. In other words, why don't you want to provide Access Grid service for the consumer market? Members of a virtual venue are sparsely distributed over the Internet subscribing different ASes. Using SSM or PIM-SM in short cut mode, number of routing entry become as same as number of transmitters. That means routes grows up to millions very easily. To make matter worse, curious customers rapidly loiter from venue to venue, joining and pruning (S,G). Whenever they zap the channel, PIM-SSM signaling travels from receiver to most nearest branching router marking or erasing routing entries. That's why I want you to scale your routers up to millions multicast routes. If you will not, neither we will be support instant video message on the multicast. Again. Please, could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, Dino? ---- Yuji _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion= --0__=0ABBE4F2DFCAD2128f9e8a93df938690918c0ABBE4F2DFCAD212 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Yuji,
I agree.

It's seems pretty clear that current multicast schemes do not provide v= ery good support
for an important class of applications (including IP telephony, videoco= nferencing,
e-meetings, multiplayer games and other applications in which there are= likely
to be very large numbers of distinct multicast groups).

As the Internet Architecture Board said (in RFC 2902) "providing f= or many groups
of small conferences ... scales badly given the current multicast model= ".

So if we want tapplications like the above to work when there is limite= d bandwidth
in the first mile (e.g. DSL, cable modem, wireless etc.) we need a mult= icast scheme that
can support very large or unlimited numbers of small groups.


Rick Boivie
IBM T. J. Watson Research Center
rhboivie@us.ibm.com

Sent by: routing-discussion-admin= @ietf.org

To: dino@= procket.com
cc: mohta@ne= com830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-disc= ussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@resear= ch.att.com
Subject: Re:= mboned: BGMP & DVMRP status Q.



Dino,

>     Does any protocol then scale if I decide that my= table size needs to be
>     5,000,000 routes?

    Could you tell us why you consider 5,000 is enough and
    5,000,000 is too much for the Internet, please?

    Reading your mail, you may feel 5,000,000 routes is ridiculous
    requirement. I agree with you if we can limit to use
    multicast only for alternative usage of current broadcasting
    media like TV and radio. 5,000 will be enough because almost
    channel flows from the anchor desks in N.Y., L.A. or Atlanta
    spread over world wide Internet. Since such flow of popular
    programs are always received by many ISPs, each routing entry
    may be very stable and you may be able to assign multicast
    addresses to aggregate neatly.

    However, once we want the application like instant message
    systems with vic & rat, situation change drastically. In other
    words, why don't you want to provide Access Grid service for
    the consumer market? Members of a virtual venue are sparsely
    distributed over the Internet subscribing different
    ASes. Using SSM or PIM-SM in short cut mode, number of routing
    entry become as same as number of transmitters. That means routes
    grows up to millions very easily.

    To make matter worse, curious customers rapidly loiter from
    venue to venue, joining and pruning (S,G). Whenever they zap
    the channel, PIM-SSM signaling travels from receiver to most
    nearest branching router marking or erasing routing entries.

    That's why I want you to scale your routers up to millions
    multicast routes. If you will not, neither we will be support
    instant video message on the multicast.

    Again.

    Please, could you tell us why you consider 5,000 is enough and
    5,000,000 is too much for the Internet, Dino?
----
Yuji

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion = --0__=0ABBE4F2DFCAD2128f9e8a93df938690918c0ABBE4F2DFCAD212-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 11:27:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04502 for ; Wed, 24 Mar 2004 11:27:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BDd-0002Xj-6b for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 11:27:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OGR5lD009775 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 11:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BDa-0002Ws-BB; Wed, 24 Mar 2004 11:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BCr-0002VL-4V for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 11:26:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04401 for ; Wed, 24 Mar 2004 11:26:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BCq-0000lI-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:26:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BBx-0000ib-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:25:22 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6BBG-0000dQ-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:24:38 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2OGO70Y518812; Wed, 24 Mar 2004 11:24:07 -0500 Received: from d03nm690.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2OGNun5381978; Wed, 24 Mar 2004 09:23:59 -0700 In-Reply-To: <20040324132957Q.kimai@labs.fujitsu.com> Importance: Normal Subject: Re: mboned: BGMP & DVMRP status Q. To: IMAI Yuji Cc: dino@procket.com, mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Rick Boivie Date: Wed, 24 Mar 2004 11:23:35 -0500 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 03/24/2004 09:23:59 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE4F2DFCAD2128f9e8a93df938690918c0ABBE4F2DFCAD212" Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --0__=0ABBE4F2DFCAD2128f9e8a93df938690918c0ABBE4F2DFCAD212 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Yuji, I agree. It's seems pretty clear that current multicast schemes do not provide v= ery good support for an important class of applications (including IP telephony, videoconferencing, e-meetings, multiplayer games and other applications in which there are= likely to be very large numbers of distinct multicast groups). As the Internet Architecture Board said (in RFC 2902) "providing for ma= ny groups of small conferences ... scales badly given the current multicast model= ". So if we want tapplications like the above to work when there is limite= d bandwidth in the first mile (e.g. DSL, cable modem, wireless etc.) we need a multicast scheme that can support very large or unlimited numbers of small groups. Rick Boivie IBM T. J. Watson Research Center rhboivie@us.ibm.com IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM Sent by: routing-discussion-admin@ietf.org To: dino@procket.com cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.ne= t, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Dino, > Does any protocol then scale if I decide that my table size needs= to be > 5,000,000 routes? Could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, please? Reading your mail, you may feel 5,000,000 routes is ridiculous requirement. I agree with you if we can limit to use multicast only for alternative usage of current broadcasting media like TV and radio. 5,000 will be enough because almost channel flows from the anchor desks in N.Y., L.A. or Atlanta spread over world wide Internet. Since such flow of popular programs are always received by many ISPs, each routing entry may be very stable and you may be able to assign multicast addresses to aggregate neatly. However, once we want the application like instant message systems with vic & rat, situation change drastically. In other words, why don't you want to provide Access Grid service for the consumer market? Members of a virtual venue are sparsely distributed over the Internet subscribing different ASes. Using SSM or PIM-SM in short cut mode, number of routing entry become as same as number of transmitters. That means routes grows up to millions very easily. To make matter worse, curious customers rapidly loiter from venue to venue, joining and pruning (S,G). Whenever they zap the channel, PIM-SSM signaling travels from receiver to most nearest branching router marking or erasing routing entries. That's why I want you to scale your routers up to millions multicast routes. If you will not, neither we will be support instant video message on the multicast. Again. Please, could you tell us why you consider 5,000 is enough and 5,000,000 is too much for the Internet, Dino? ---- Yuji _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion= --0__=0ABBE4F2DFCAD2128f9e8a93df938690918c0ABBE4F2DFCAD212 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Yuji,
I agree.

It's seems pretty clear that current multicast schemes do not provide v= ery good support
for an important class of applications (including IP telephony, videoco= nferencing,
e-meetings, multiplayer games and other applications in which there are= likely
to be very large numbers of distinct multicast groups).

As the Internet Architecture Board said (in RFC 2902) "providing f= or many groups
of small conferences ... scales badly given the current multicast model= ".

So if we want tapplications like the above to work when there is limite= d bandwidth
in the first mile (e.g. DSL, cable modem, wireless etc.) we need a mult= icast scheme that
can support very large or unlimited numbers of small groups.


Rick Boivie
IBM T. J. Watson Research Center
rhboivie@us.ibm.com

Sent by: routing-discussion-admin= @ietf.org

To: dino@= procket.com
cc: mohta@ne= com830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, routing-disc= ussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@resear= ch.att.com
Subject: Re:= mboned: BGMP & DVMRP status Q.



Dino,

>     Does any protocol then scale if I decide that my= table size needs to be
>     5,000,000 routes?

    Could you tell us why you consider 5,000 is enough and
    5,000,000 is too much for the Internet, please?

    Reading your mail, you may feel 5,000,000 routes is ridiculous
    requirement. I agree with you if we can limit to use
    multicast only for alternative usage of current broadcasting
    media like TV and radio. 5,000 will be enough because almost
    channel flows from the anchor desks in N.Y., L.A. or Atlanta
    spread over world wide Internet. Since such flow of popular
    programs are always received by many ISPs, each routing entry
    may be very stable and you may be able to assign multicast
    addresses to aggregate neatly.

    However, once we want the application like instant message
    systems with vic & rat, situation change drastically. In other
    words, why don't you want to provide Access Grid service for
    the consumer market? Members of a virtual venue are sparsely
    distributed over the Internet subscribing different
    ASes. Using SSM or PIM-SM in short cut mode, number of routing
    entry become as same as number of transmitters. That means routes
    grows up to millions very easily.

    To make matter worse, curious customers rapidly loiter from
    venue to venue, joining and pruning (S,G). Whenever they zap
    the channel, PIM-SSM signaling travels from receiver to most
    nearest branching router marking or erasing routing entries.

    That's why I want you to scale your routers up to millions
    multicast routes. If you will not, neither we will be support
    instant video message on the multicast.

    Again.

    Please, could you tell us why you consider 5,000 is enough and
    5,000,000 is too much for the Internet, Dino?
----
Yuji

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion = --0__=0ABBE4F2DFCAD2128f9e8a93df938690918c0ABBE4F2DFCAD212-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 12:13:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04345 for ; Wed, 24 Mar 2004 11:25:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BBw-0002Hq-11 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 11:25:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OGPJle008759 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 11:25:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BBe-00029e-8J; Wed, 24 Mar 2004 11:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BAz-00025R-Nq for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 11:24:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04282 for ; Wed, 24 Mar 2004 11:24:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BAy-0000fN-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:24:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BA4-0000ci-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:23:25 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1B6B9H-0000VY-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 11:22:35 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2OGM54e017251; Wed, 24 Mar 2004 08:22:05 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i2OGM5pv017250; Wed, 24 Mar 2004 08:22:05 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 24 Mar 2004 08:22:05 -0800 From: David Meyer To: mboned@lists.uoregon.edu Cc: routing-discussion@ietf.org, zinin@psg.com, fenner@research.att.com Subject: list etiquette [was Re: mboned: BGMP & DVMRP status Q.] Message-ID: <20040324162205.GA16980@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Folks, Just a small note on the thread quoted above: As we all know, IETF mailing lists are maintained for the discussion of IETF technical issues. As such, please keep a professional tone, and stay focused on the technical aspects of the issue(s) at hand. Thanks, Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 13:05:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09889 for ; Wed, 24 Mar 2004 13:05:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Cjr-0004vM-IU; Wed, 24 Mar 2004 13:04:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ciq-0004q8-LB for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 13:03:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09840 for ; Wed, 24 Mar 2004 13:03:21 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Cio-00002X-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:03:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Chu-0007nM-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:02:27 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[6tDhWHoCG/pd1tMFa8tBApdZvGgb2Egx]) by ietf-mx with esmtp (Exim 4.12) id 1B6ChW-0007kB-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:02:02 -0500 Received: from shepfarm.com (IDENT:XZFUSm8iLKNLowqMzFaPvGjf4Er5xE0v@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2OJh7Tk009613; Wed, 24 Mar 2004 11:43:09 -0800 Date: Wed, 24 Mar 2004 11:43:06 -0800 (PST) To: Rick Boivie cc: IMAI Yuji , , , , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, 24 Mar 2004, Rick Boivie wrote: > As the Internet Architecture Board said (in RFC 2902) "providing for many > groups > of small conferences ... scales badly given the current multicast model". > > So if we want tapplications like the above to work when there is limited > bandwidth > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > multicast scheme that > can support very large or unlimited numbers of small groups. > > Rick Boivie > IBM T. J. Watson Research Center > rhboivie@us.ibm.com Rick, I'd love to have those problems!!! ;-) ..but for now, we don't even have a good live example due to the lack of last-mile deployment. Yes, I'd love to improve on the scaling of our current mcast solutions, but until the deployment warrents it, let's focus on solving the deployment barriers. Then when the availablity of mcast begins attracting apps and users we can gather imperical data as to what about the current scheme does and does not scale. As an example, please recall NetAid. This WAS a successful large audience mcast event which exposed the scaling limits in RTCP - which was solveable at the application layer. Until we have other similar examples exposing other limitations, I feel we are just shooting in the air. Greg > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM > > Sent by: routing-discussion-admin@ietf.org > > > To: dino@procket.com > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, > routing-discussion@ietf.org, mboned@lists.uoregon.edu, > zinin@psg.com, fenner@research.att.com > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > Dino, > > > Does any protocol then scale if I decide that my table size needs to > be > > 5,000,000 routes? > > Could you tell us why you consider 5,000 is enough and > 5,000,000 is too much for the Internet, please? > > Reading your mail, you may feel 5,000,000 routes is ridiculous > requirement. I agree with you if we can limit to use > multicast only for alternative usage of current broadcasting > media like TV and radio. 5,000 will be enough because almost > channel flows from the anchor desks in N.Y., L.A. or Atlanta > spread over world wide Internet. Since such flow of popular > programs are always received by many ISPs, each routing entry > may be very stable and you may be able to assign multicast > addresses to aggregate neatly. > > However, once we want the application like instant message > systems with vic & rat, situation change drastically. In other > words, why don't you want to provide Access Grid service for > the consumer market? Members of a virtual venue are sparsely > distributed over the Internet subscribing different > ASes. Using SSM or PIM-SM in short cut mode, number of routing > entry become as same as number of transmitters. That means routes > grows up to millions very easily. > > To make matter worse, curious customers rapidly loiter from > venue to venue, joining and pruning (S,G). Whenever they zap > the channel, PIM-SSM signaling travels from receiver to most > nearest branching router marking or erasing routing entries. > > That's why I want you to scale your routers up to millions > multicast routes. If you will not, neither we will be support > instant video message on the multicast. > > Again. > > Please, could you tell us why you consider 5,000 is enough and > 5,000,000 is too much for the Internet, Dino? > ---- > Yuji > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 13:05:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09906 for ; Wed, 24 Mar 2004 13:05:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ck1-0004x0-NY for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 13:04:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OI4baS019031 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 13:04:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Cjr-0004vM-IU; Wed, 24 Mar 2004 13:04:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ciq-0004q8-LB for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 13:03:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09840 for ; Wed, 24 Mar 2004 13:03:21 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Cio-00002X-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:03:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Chu-0007nM-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:02:27 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[6tDhWHoCG/pd1tMFa8tBApdZvGgb2Egx]) by ietf-mx with esmtp (Exim 4.12) id 1B6ChW-0007kB-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:02:02 -0500 Received: from shepfarm.com (IDENT:XZFUSm8iLKNLowqMzFaPvGjf4Er5xE0v@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2OJh7Tk009613; Wed, 24 Mar 2004 11:43:09 -0800 Date: Wed, 24 Mar 2004 11:43:06 -0800 (PST) To: Rick Boivie cc: IMAI Yuji , , , , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, 24 Mar 2004, Rick Boivie wrote: > As the Internet Architecture Board said (in RFC 2902) "providing for many > groups > of small conferences ... scales badly given the current multicast model". > > So if we want tapplications like the above to work when there is limited > bandwidth > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > multicast scheme that > can support very large or unlimited numbers of small groups. > > Rick Boivie > IBM T. J. Watson Research Center > rhboivie@us.ibm.com Rick, I'd love to have those problems!!! ;-) ..but for now, we don't even have a good live example due to the lack of last-mile deployment. Yes, I'd love to improve on the scaling of our current mcast solutions, but until the deployment warrents it, let's focus on solving the deployment barriers. Then when the availablity of mcast begins attracting apps and users we can gather imperical data as to what about the current scheme does and does not scale. As an example, please recall NetAid. This WAS a successful large audience mcast event which exposed the scaling limits in RTCP - which was solveable at the application layer. Until we have other similar examples exposing other limitations, I feel we are just shooting in the air. Greg > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM > > Sent by: routing-discussion-admin@ietf.org > > > To: dino@procket.com > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, > routing-discussion@ietf.org, mboned@lists.uoregon.edu, > zinin@psg.com, fenner@research.att.com > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > Dino, > > > Does any protocol then scale if I decide that my table size needs to > be > > 5,000,000 routes? > > Could you tell us why you consider 5,000 is enough and > 5,000,000 is too much for the Internet, please? > > Reading your mail, you may feel 5,000,000 routes is ridiculous > requirement. I agree with you if we can limit to use > multicast only for alternative usage of current broadcasting > media like TV and radio. 5,000 will be enough because almost > channel flows from the anchor desks in N.Y., L.A. or Atlanta > spread over world wide Internet. Since such flow of popular > programs are always received by many ISPs, each routing entry > may be very stable and you may be able to assign multicast > addresses to aggregate neatly. > > However, once we want the application like instant message > systems with vic & rat, situation change drastically. In other > words, why don't you want to provide Access Grid service for > the consumer market? Members of a virtual venue are sparsely > distributed over the Internet subscribing different > ASes. Using SSM or PIM-SM in short cut mode, number of routing > entry become as same as number of transmitters. That means routes > grows up to millions very easily. > > To make matter worse, curious customers rapidly loiter from > venue to venue, joining and pruning (S,G). Whenever they zap > the channel, PIM-SSM signaling travels from receiver to most > nearest branching router marking or erasing routing entries. > > That's why I want you to scale your routers up to millions > multicast routes. If you will not, neither we will be support > instant video message on the multicast. > > Again. > > Please, could you tell us why you consider 5,000 is enough and > 5,000,000 is too much for the Internet, Dino? > ---- > Yuji > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 13:58:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13543 for ; Wed, 24 Mar 2004 13:58:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DZg-0004iz-Vi; Wed, 24 Mar 2004 13:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DZ0-0004i1-DX for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 13:57:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13459 for ; Wed, 24 Mar 2004 13:57:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6DYx-00050F-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:57:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6DXz-0004vz-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:56:17 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1B6DX8-0004oh-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:55:22 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2OIsgfS627110; Wed, 24 Mar 2004 13:54:43 -0500 Received: from d03nm690.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2OIsfn3312466; Wed, 24 Mar 2004 11:54:42 -0700 In-Reply-To: Importance: Normal Subject: Re: mboned: BGMP & DVMRP status Q. To: shep@shepfarm.com Cc: IMAI Yuji , , , , , , , , X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Rick Boivie Date: Wed, 24 Mar 2004 13:54:34 -0500 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 03/24/2004 11:54:41 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE4F2DFF5DE738f9e8a93df938690918c0ABBE4F2DFF5DE73" Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --0__=0ABBE4F2DFF5DE738f9e8a93df938690918c0ABBE4F2DFF5DE73 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Greg said: >I'd love to have those problems!!! ;-) ..but for now, we don't even ha= ve a >good live example due to the lack of last-mile deployment. There seems to be plenty of last mile broadband deployed. Note that Nielsen/NetRatings says that 49.5 million or 38% of home Internet users in the US connect via broadband. http://www.nielsen-netratings.com/pr/pr_040108_us.pdf The % of homes with broadband is even higher in some other countries of= course. So lack of last mile deployment doesn't seem to be the issue. Rather the problem seems to be that multicast doesn't provide very good suppor= t for large numbers of small groups -- as the IAB said in RFC 2902. My 2 cents. Rick shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM Sent by: routing-discussion-admin@ietf.org To: Rick Boivie/Hawthorne/IBM@IBMUS cc: IMAI Yuji , , , , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. On Wed, 24 Mar 2004, Rick Boivie wrote: > As the Internet Architecture Board said (in RFC 2902) "providing for = many > groups > of small conferences ... scales badly given the current multicast mod= el". > > So if we want tapplications like the above to work when there is limi= ted > bandwidth > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > multicast scheme that > can support very large or unlimited numbers of small groups. > > Rick Boivie > IBM T. J. Watson Research Center > rhboivie@us.ibm.com Rick, I'd love to have those problems!!! ;-) ..but for now, we don't even hav= e a good live example due to the lack of last-mile deployment. Yes, I'd love to improve on the scaling of our current mcast solutions,= but until the deployment warrents it, let's focus on solving the deployment barriers. Then when the availablity of mcast begins attracti= ng apps and users we can gather imperical data as to what about the curren= t scheme does and does not scale. As an example, please recall NetAid. This WAS a successful large audien= ce mcast event which exposed the scaling limits in RTCP - which was solvea= ble at the application layer. Until we have other similar examples exposing= other limitations, I feel we are just shooting in the air. Greg > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM= > > Sent by: routing-discussion-admin@ietf.org > > > To: dino@procket.com > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.= net, > routing-discussion@ietf.org, mboned@lists.uoregon.edu, > zinin@psg.com, fenner@research.att.com > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > Dino, > > > Does any protocol then scale if I decide that my table size nee= ds to > be > > 5,000,000 routes? > > Could you tell us why you consider 5,000 is enough and > 5,000,000 is too much for the Internet, please? > > Reading your mail, you may feel 5,000,000 routes is ridiculous > requirement. I agree with you if we can limit to use > multicast only for alternative usage of current broadcasting > media like TV and radio. 5,000 will be enough because almost > channel flows from the anchor desks in N.Y., L.A. or Atlanta > spread over world wide Internet. Since such flow of popular > programs are always received by many ISPs, each routing entry > may be very stable and you may be able to assign multicast > addresses to aggregate neatly. > > However, once we want the application like instant message > systems with vic & rat, situation change drastically. In other > words, why don't you want to provide Access Grid service for > the consumer market? Members of a virtual venue are sparsely > distributed over the Internet subscribing different > ASes. Using SSM or PIM-SM in short cut mode, number of routing > entry become as same as number of transmitters. That means routes > grows up to millions very easily. > > To make matter worse, curious customers rapidly loiter from > venue to venue, joining and pruning (S,G). Whenever they zap > the channel, PIM-SSM signaling travels from receiver to most > nearest branching router marking or erasing routing entries. > > That's why I want you to scale your routers up to millions > multicast routes. If you will not, neither we will be support > instant video message on the multicast. > > Again. > > Please, could you tell us why you consider 5,000 is enough and > 5,000,000 is too much for the Internet, Dino? > ---- > Yuji > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion= --0__=0ABBE4F2DFF5DE738f9e8a93df938690918c0ABBE4F2DFF5DE73 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Greg said:
>I'd love to have those problems!!! ;-) ..but for now, we don't = even have a
>good live example due to the lack of last-mile deployment.
=
There seems to be plenty of last mile broadband deployed.  Not= e
that Nielsen/NetRatings says that 49.5 million or 38% of home Inter= net
users in the US connect via broadband.
h= ttp://www.nielsen-netratings.com/pr/pr_040108_us.pdf

The % of homes with broadband is even higher in some other countrie= s of course.

So lack of last mile deployment doesn't seem to be the issue.  = ;Rather
the problem seems to be that multicast doesn't provide very good su= pport
for large numbers of small groups  --  as the IAB said in= RFC 2902.

My 2 cents.

Rick  



Sent by: routing-discussion-admin= @ietf.org

To: Rick = Boivie/Hawthorne/IBM@IBMUS
cc: IMAI Yuj= i <kimai@labs.fujitsu.com>, <dino@procket.com>, <mohta@n= ecom830.hpcl.titech.ac.jp>, <eckert@cisco.com>, <dmm@1-4-5.= net>, <routing-discussion@ietf.org>, <mboned@lists.uoregon.= edu>, <zinin@psg.com>, <fenner@research.att.com><= font size=3D"2" color=3D"#800080">
Subject: Re:= mboned: BGMP & DVMRP status Q.





On Wed, 24 Mar 2004, Rick Boivie wrote:
> As the Internet Architecture Board said (in RFC 2902) "provid= ing for many
> groups
> of small conferences ... scales badly given the current multicast = model".
>
> So if we want tapplications like the above to work when there is l= imited
> bandwidth
> in the first mile (e.g. DSL, cable modem, wireless etc.) we need a=
> multicast scheme that
> can support very large or unlimited numbers of small groups.
>
> Rick Boivie
> IBM T. J. Watson Research Center
> rhboivie@us.ibm.com

Rick,

I'd love to have those problems!!! ;-) ..but for now, we don't even= have a
good live example due to the lack of last-mile deployment.

Yes, I'd love to improve on the scaling of our current mcast soluti= ons,
but until the deployment warrents it, let's focus on solving the
deployment barriers. Then when the availablity of mcast begins attracti= ng
apps and users we can gather imperical data as to what about the curren= t
scheme does and does not scale.

As an example, please recall NetAid. This WAS a successful large au= dience
mcast event which exposed the scaling limits in RTCP - which was solvea= ble
at the application layer. Until we have other similar examples exposing=
other limitations, I feel we are just shooting in the air.

Greg

>
> IMAI Yuji <kimai@labs.fujitsu.com>@ietf.org on 03/23/2004 11= :29:57 PM
>
> Sent by:    routing-discussion-admin@ietf.org
>
>
> To:    dino@procket.com
> cc:    mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.co= m, dmm@1-4-5.net,
>        routing-discussion@ietf.org, mboned@lis= ts.uoregon.edu,
>        zinin@psg.com, fenner@research.att.com<= br> > Subject:    Re: mboned: BGMP & DVMRP status Q.
>
>
>
> Dino,
>
> >     Does any protocol then scale if I decide that m= y table size needs to
> be
> >     5,000,000 routes?
>
>   Could you tell us why you consider 5,000 is enough and
>   5,000,000 is too much for the Internet, please?
>
>   Reading your mail, you may feel 5,000,000 routes is ridicul= ous
>   requirement. I agree with you if we can limit to use
>   multicast only for alternative usage of current broadcastin= g
>   media like TV and radio. 5,000 will be enough because almos= t
>   channel flows from the anchor desks in N.Y., L.A. or Atlant= a
>   spread over world wide Internet. Since such flow of popular=
>   programs are always received by many ISPs, each routing ent= ry
>   may be very stable and you may be able to assign multicast<= br> >   addresses to aggregate neatly.
>
>   However, once we want the application like instant message<= br> >   systems with vic & rat, situation change drastically. I= n other
>   words, why don't you want to provide Access Grid service fo= r
>   the consumer market? Members of a virtual venue are sparsel= y
>   distributed over the Internet subscribing different
>   ASes. Using SSM or PIM-SM in short cut mode, number of rout= ing
>   entry become as same as number of transmitters. That means = routes
>   grows up to millions very easily.
>
>   To make matter worse, curious customers rapidly loiter from=
>   venue to venue, joining and pruning (S,G). Whenever they za= p
>   the channel, PIM-SSM signaling travels from receiver to mos= t
>   nearest branching router marking or erasing routing entries= .
>
>   That's why I want you to scale your routers up to millions<= br> >   multicast routes. If you will not, neither we will be suppo= rt
>   instant video message on the multicast.
>
>   Again.
>
>   Please, could you tell us why you consider 5,000 is enough = and
>   5,000,000 is too much for the Internet, Dino?
> ----
> Yuji
>
> _______________________________________________
> routing-discussion mailing list
> routing-discussion@ietf.org
>  https://www1.ietf.org/mailman/listinfo/routing-discu= ssion


_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion = --0__=0ABBE4F2DFF5DE738f9e8a93df938690918c0ABBE4F2DFF5DE73-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 13:58:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13560 for ; Wed, 24 Mar 2004 13:58:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Da1-0004n1-NY for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 13:58:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OIwLlO018407 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 13:58:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DZg-0004iz-Vi; Wed, 24 Mar 2004 13:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DZ0-0004i1-DX for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 13:57:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13459 for ; Wed, 24 Mar 2004 13:57:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6DYx-00050F-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:57:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6DXz-0004vz-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:56:17 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1B6DX8-0004oh-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:55:22 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2OIsgfS627110; Wed, 24 Mar 2004 13:54:43 -0500 Received: from d03nm690.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2OIsfn3312466; Wed, 24 Mar 2004 11:54:42 -0700 In-Reply-To: Importance: Normal Subject: Re: mboned: BGMP & DVMRP status Q. To: shep@shepfarm.com Cc: IMAI Yuji , , , , , , , , X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Rick Boivie Date: Wed, 24 Mar 2004 13:54:34 -0500 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 03/24/2004 11:54:41 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE4F2DFF5DE738f9e8a93df938690918c0ABBE4F2DFF5DE73" Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --0__=0ABBE4F2DFF5DE738f9e8a93df938690918c0ABBE4F2DFF5DE73 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Greg said: >I'd love to have those problems!!! ;-) ..but for now, we don't even ha= ve a >good live example due to the lack of last-mile deployment. There seems to be plenty of last mile broadband deployed. Note that Nielsen/NetRatings says that 49.5 million or 38% of home Internet users in the US connect via broadband. http://www.nielsen-netratings.com/pr/pr_040108_us.pdf The % of homes with broadband is even higher in some other countries of= course. So lack of last mile deployment doesn't seem to be the issue. Rather the problem seems to be that multicast doesn't provide very good suppor= t for large numbers of small groups -- as the IAB said in RFC 2902. My 2 cents. Rick shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM Sent by: routing-discussion-admin@ietf.org To: Rick Boivie/Hawthorne/IBM@IBMUS cc: IMAI Yuji , , , , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. On Wed, 24 Mar 2004, Rick Boivie wrote: > As the Internet Architecture Board said (in RFC 2902) "providing for = many > groups > of small conferences ... scales badly given the current multicast mod= el". > > So if we want tapplications like the above to work when there is limi= ted > bandwidth > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > multicast scheme that > can support very large or unlimited numbers of small groups. > > Rick Boivie > IBM T. J. Watson Research Center > rhboivie@us.ibm.com Rick, I'd love to have those problems!!! ;-) ..but for now, we don't even hav= e a good live example due to the lack of last-mile deployment. Yes, I'd love to improve on the scaling of our current mcast solutions,= but until the deployment warrents it, let's focus on solving the deployment barriers. Then when the availablity of mcast begins attracti= ng apps and users we can gather imperical data as to what about the curren= t scheme does and does not scale. As an example, please recall NetAid. This WAS a successful large audien= ce mcast event which exposed the scaling limits in RTCP - which was solvea= ble at the application layer. Until we have other similar examples exposing= other limitations, I feel we are just shooting in the air. Greg > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM= > > Sent by: routing-discussion-admin@ietf.org > > > To: dino@procket.com > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.= net, > routing-discussion@ietf.org, mboned@lists.uoregon.edu, > zinin@psg.com, fenner@research.att.com > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > Dino, > > > Does any protocol then scale if I decide that my table size nee= ds to > be > > 5,000,000 routes? > > Could you tell us why you consider 5,000 is enough and > 5,000,000 is too much for the Internet, please? > > Reading your mail, you may feel 5,000,000 routes is ridiculous > requirement. I agree with you if we can limit to use > multicast only for alternative usage of current broadcasting > media like TV and radio. 5,000 will be enough because almost > channel flows from the anchor desks in N.Y., L.A. or Atlanta > spread over world wide Internet. Since such flow of popular > programs are always received by many ISPs, each routing entry > may be very stable and you may be able to assign multicast > addresses to aggregate neatly. > > However, once we want the application like instant message > systems with vic & rat, situation change drastically. In other > words, why don't you want to provide Access Grid service for > the consumer market? Members of a virtual venue are sparsely > distributed over the Internet subscribing different > ASes. Using SSM or PIM-SM in short cut mode, number of routing > entry become as same as number of transmitters. That means routes > grows up to millions very easily. > > To make matter worse, curious customers rapidly loiter from > venue to venue, joining and pruning (S,G). Whenever they zap > the channel, PIM-SSM signaling travels from receiver to most > nearest branching router marking or erasing routing entries. > > That's why I want you to scale your routers up to millions > multicast routes. If you will not, neither we will be support > instant video message on the multicast. > > Again. > > Please, could you tell us why you consider 5,000 is enough and > 5,000,000 is too much for the Internet, Dino? > ---- > Yuji > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion= --0__=0ABBE4F2DFF5DE738f9e8a93df938690918c0ABBE4F2DFF5DE73 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Greg said:
>I'd love to have those problems!!! ;-) ..but for now, we don't = even have a
>good live example due to the lack of last-mile deployment.
=
There seems to be plenty of last mile broadband deployed.  Not= e
that Nielsen/NetRatings says that 49.5 million or 38% of home Inter= net
users in the US connect via broadband.
h= ttp://www.nielsen-netratings.com/pr/pr_040108_us.pdf

The % of homes with broadband is even higher in some other countrie= s of course.

So lack of last mile deployment doesn't seem to be the issue.  = ;Rather
the problem seems to be that multicast doesn't provide very good su= pport
for large numbers of small groups  --  as the IAB said in= RFC 2902.

My 2 cents.

Rick  



Sent by: routing-discussion-admin= @ietf.org

To: Rick = Boivie/Hawthorne/IBM@IBMUS
cc: IMAI Yuj= i <kimai@labs.fujitsu.com>, <dino@procket.com>, <mohta@n= ecom830.hpcl.titech.ac.jp>, <eckert@cisco.com>, <dmm@1-4-5.= net>, <routing-discussion@ietf.org>, <mboned@lists.uoregon.= edu>, <zinin@psg.com>, <fenner@research.att.com><= font size=3D"2" color=3D"#800080">
Subject: Re:= mboned: BGMP & DVMRP status Q.





On Wed, 24 Mar 2004, Rick Boivie wrote:
> As the Internet Architecture Board said (in RFC 2902) "provid= ing for many
> groups
> of small conferences ... scales badly given the current multicast = model".
>
> So if we want tapplications like the above to work when there is l= imited
> bandwidth
> in the first mile (e.g. DSL, cable modem, wireless etc.) we need a=
> multicast scheme that
> can support very large or unlimited numbers of small groups.
>
> Rick Boivie
> IBM T. J. Watson Research Center
> rhboivie@us.ibm.com

Rick,

I'd love to have those problems!!! ;-) ..but for now, we don't even= have a
good live example due to the lack of last-mile deployment.

Yes, I'd love to improve on the scaling of our current mcast soluti= ons,
but until the deployment warrents it, let's focus on solving the
deployment barriers. Then when the availablity of mcast begins attracti= ng
apps and users we can gather imperical data as to what about the curren= t
scheme does and does not scale.

As an example, please recall NetAid. This WAS a successful large au= dience
mcast event which exposed the scaling limits in RTCP - which was solvea= ble
at the application layer. Until we have other similar examples exposing=
other limitations, I feel we are just shooting in the air.

Greg

>
> IMAI Yuji <kimai@labs.fujitsu.com>@ietf.org on 03/23/2004 11= :29:57 PM
>
> Sent by:    routing-discussion-admin@ietf.org
>
>
> To:    dino@procket.com
> cc:    mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.co= m, dmm@1-4-5.net,
>        routing-discussion@ietf.org, mboned@lis= ts.uoregon.edu,
>        zinin@psg.com, fenner@research.att.com<= br> > Subject:    Re: mboned: BGMP & DVMRP status Q.
>
>
>
> Dino,
>
> >     Does any protocol then scale if I decide that m= y table size needs to
> be
> >     5,000,000 routes?
>
>   Could you tell us why you consider 5,000 is enough and
>   5,000,000 is too much for the Internet, please?
>
>   Reading your mail, you may feel 5,000,000 routes is ridicul= ous
>   requirement. I agree with you if we can limit to use
>   multicast only for alternative usage of current broadcastin= g
>   media like TV and radio. 5,000 will be enough because almos= t
>   channel flows from the anchor desks in N.Y., L.A. or Atlant= a
>   spread over world wide Internet. Since such flow of popular=
>   programs are always received by many ISPs, each routing ent= ry
>   may be very stable and you may be able to assign multicast<= br> >   addresses to aggregate neatly.
>
>   However, once we want the application like instant message<= br> >   systems with vic & rat, situation change drastically. I= n other
>   words, why don't you want to provide Access Grid service fo= r
>   the consumer market? Members of a virtual venue are sparsel= y
>   distributed over the Internet subscribing different
>   ASes. Using SSM or PIM-SM in short cut mode, number of rout= ing
>   entry become as same as number of transmitters. That means = routes
>   grows up to millions very easily.
>
>   To make matter worse, curious customers rapidly loiter from=
>   venue to venue, joining and pruning (S,G). Whenever they za= p
>   the channel, PIM-SSM signaling travels from receiver to mos= t
>   nearest branching router marking or erasing routing entries= .
>
>   That's why I want you to scale your routers up to millions<= br> >   multicast routes. If you will not, neither we will be suppo= rt
>   instant video message on the multicast.
>
>   Again.
>
>   Please, could you tell us why you consider 5,000 is enough = and
>   5,000,000 is too much for the Internet, Dino?
> ----
> Yuji
>
> _______________________________________________
> routing-discussion mailing list
> routing-discussion@ietf.org
>  https://www1.ietf.org/mailman/listinfo/routing-discu= ssion


_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion = --0__=0ABBE4F2DFF5DE738f9e8a93df938690918c0ABBE4F2DFF5DE73-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 14:32:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15113 for ; Wed, 24 Mar 2004 14:32:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6E6b-0007Nh-Lz; Wed, 24 Mar 2004 14:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6E60-0007MJ-By for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 14:31:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15038 for ; Wed, 24 Mar 2004 14:31:21 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6E5x-0007ee-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:31:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6E50-0007b6-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:30:23 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[GDvYiWEbwZmkC9R7DN1FLjiFYvBfoBr4]) by ietf-mx with esmtp (Exim 4.12) id 1B6E4B-0007XU-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:29:31 -0500 Received: from shepfarm.com (IDENT:EnTk3CWNozlxh3n8BAZYdeSRIlVkRdvb@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2OLAsTk009798; Wed, 24 Mar 2004 13:10:54 -0800 Date: Wed, 24 Mar 2004 13:10:53 -0800 (PST) To: Rick Boivie cc: IMAI Yuji , , , , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, 24 Mar 2004, Rick Boivie wrote: > Greg said: > >I'd love to have those problems!!! ;-) ..but for now, we don't even have a > >good live example due to the lack of last-mile deployment. > > There seems to be plenty of last mile broadband deployed. Note > that Nielsen/NetRatings says that 49.5 million or 38% of home Internet > users in the US connect via broadband. > http://www.nielsen-netratings.com/pr/pr_040108_us.pdf > > The % of homes with broadband is even higher in some other countries of > course. > > So lack of last mile deployment doesn't seem to be the issue. Rather > the problem seems to be that multicast doesn't provide very good support > for large numbers of small groups -- as the IAB said in RFC 2902. > > My 2 cents. ..and what percentage of them have mcast enabled? Even better, what percentage of them have mcast enabled to the mcast-anabled Internet and not just a walled-garden deployment? I'd say less than 1%. Greg > Rick > > > > > shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM > > Sent by: routing-discussion-admin@ietf.org > > > To: Rick Boivie/Hawthorne/IBM@IBMUS > cc: IMAI Yuji , , > , , > , , > , , > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > On Wed, 24 Mar 2004, Rick Boivie wrote: > > As the Internet Architecture Board said (in RFC 2902) "providing for many > > groups > > of small conferences ... scales badly given the current multicast model". > > > > So if we want tapplications like the above to work when there is limited > > bandwidth > > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > > multicast scheme that > > can support very large or unlimited numbers of small groups. > > > > Rick Boivie > > IBM T. J. Watson Research Center > > rhboivie@us.ibm.com > > Rick, > > I'd love to have those problems!!! ;-) ..but for now, we don't even have a > good live example due to the lack of last-mile deployment. > > Yes, I'd love to improve on the scaling of our current mcast solutions, > but until the deployment warrents it, let's focus on solving the > deployment barriers. Then when the availablity of mcast begins attracting > apps and users we can gather imperical data as to what about the current > scheme does and does not scale. > > As an example, please recall NetAid. This WAS a successful large audience > mcast event which exposed the scaling limits in RTCP - which was solveable > at the application layer. Until we have other similar examples exposing > other limitations, I feel we are just shooting in the air. > > Greg > > > > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM > > > > Sent by: routing-discussion-admin@ietf.org > > > > > > To: dino@procket.com > > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, > > routing-discussion@ietf.org, mboned@lists.uoregon.edu, > > zinin@psg.com, fenner@research.att.com > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > > > Dino, > > > > > Does any protocol then scale if I decide that my table size needs > to > > be > > > 5,000,000 routes? > > > > Could you tell us why you consider 5,000 is enough and > > 5,000,000 is too much for the Internet, please? > > > > Reading your mail, you may feel 5,000,000 routes is ridiculous > > requirement. I agree with you if we can limit to use > > multicast only for alternative usage of current broadcasting > > media like TV and radio. 5,000 will be enough because almost > > channel flows from the anchor desks in N.Y., L.A. or Atlanta > > spread over world wide Internet. Since such flow of popular > > programs are always received by many ISPs, each routing entry > > may be very stable and you may be able to assign multicast > > addresses to aggregate neatly. > > > > However, once we want the application like instant message > > systems with vic & rat, situation change drastically. In other > > words, why don't you want to provide Access Grid service for > > the consumer market? Members of a virtual venue are sparsely > > distributed over the Internet subscribing different > > ASes. Using SSM or PIM-SM in short cut mode, number of routing > > entry become as same as number of transmitters. That means routes > > grows up to millions very easily. > > > > To make matter worse, curious customers rapidly loiter from > > venue to venue, joining and pruning (S,G). Whenever they zap > > the channel, PIM-SSM signaling travels from receiver to most > > nearest branching router marking or erasing routing entries. > > > > That's why I want you to scale your routers up to millions > > multicast routes. If you will not, neither we will be support > > instant video message on the multicast. > > > > Again. > > > > Please, could you tell us why you consider 5,000 is enough and > > 5,000,000 is too much for the Internet, Dino? > > ---- > > Yuji > > > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 14:32:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15130 for ; Wed, 24 Mar 2004 14:32:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6E6r-0007O7-3h for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 14:32:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OJWGoZ028399 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 14:32:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6E6b-0007Nh-Lz; Wed, 24 Mar 2004 14:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6E60-0007MJ-By for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 14:31:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15038 for ; Wed, 24 Mar 2004 14:31:21 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6E5x-0007ee-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:31:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6E50-0007b6-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:30:23 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[GDvYiWEbwZmkC9R7DN1FLjiFYvBfoBr4]) by ietf-mx with esmtp (Exim 4.12) id 1B6E4B-0007XU-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:29:31 -0500 Received: from shepfarm.com (IDENT:EnTk3CWNozlxh3n8BAZYdeSRIlVkRdvb@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2OLAsTk009798; Wed, 24 Mar 2004 13:10:54 -0800 Date: Wed, 24 Mar 2004 13:10:53 -0800 (PST) To: Rick Boivie cc: IMAI Yuji , , , , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, 24 Mar 2004, Rick Boivie wrote: > Greg said: > >I'd love to have those problems!!! ;-) ..but for now, we don't even have a > >good live example due to the lack of last-mile deployment. > > There seems to be plenty of last mile broadband deployed. Note > that Nielsen/NetRatings says that 49.5 million or 38% of home Internet > users in the US connect via broadband. > http://www.nielsen-netratings.com/pr/pr_040108_us.pdf > > The % of homes with broadband is even higher in some other countries of > course. > > So lack of last mile deployment doesn't seem to be the issue. Rather > the problem seems to be that multicast doesn't provide very good support > for large numbers of small groups -- as the IAB said in RFC 2902. > > My 2 cents. ..and what percentage of them have mcast enabled? Even better, what percentage of them have mcast enabled to the mcast-anabled Internet and not just a walled-garden deployment? I'd say less than 1%. Greg > Rick > > > > > shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM > > Sent by: routing-discussion-admin@ietf.org > > > To: Rick Boivie/Hawthorne/IBM@IBMUS > cc: IMAI Yuji , , > , , > , , > , , > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > On Wed, 24 Mar 2004, Rick Boivie wrote: > > As the Internet Architecture Board said (in RFC 2902) "providing for many > > groups > > of small conferences ... scales badly given the current multicast model". > > > > So if we want tapplications like the above to work when there is limited > > bandwidth > > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > > multicast scheme that > > can support very large or unlimited numbers of small groups. > > > > Rick Boivie > > IBM T. J. Watson Research Center > > rhboivie@us.ibm.com > > Rick, > > I'd love to have those problems!!! ;-) ..but for now, we don't even have a > good live example due to the lack of last-mile deployment. > > Yes, I'd love to improve on the scaling of our current mcast solutions, > but until the deployment warrents it, let's focus on solving the > deployment barriers. Then when the availablity of mcast begins attracting > apps and users we can gather imperical data as to what about the current > scheme does and does not scale. > > As an example, please recall NetAid. This WAS a successful large audience > mcast event which exposed the scaling limits in RTCP - which was solveable > at the application layer. Until we have other similar examples exposing > other limitations, I feel we are just shooting in the air. > > Greg > > > > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM > > > > Sent by: routing-discussion-admin@ietf.org > > > > > > To: dino@procket.com > > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, > > routing-discussion@ietf.org, mboned@lists.uoregon.edu, > > zinin@psg.com, fenner@research.att.com > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > > > Dino, > > > > > Does any protocol then scale if I decide that my table size needs > to > > be > > > 5,000,000 routes? > > > > Could you tell us why you consider 5,000 is enough and > > 5,000,000 is too much for the Internet, please? > > > > Reading your mail, you may feel 5,000,000 routes is ridiculous > > requirement. I agree with you if we can limit to use > > multicast only for alternative usage of current broadcasting > > media like TV and radio. 5,000 will be enough because almost > > channel flows from the anchor desks in N.Y., L.A. or Atlanta > > spread over world wide Internet. Since such flow of popular > > programs are always received by many ISPs, each routing entry > > may be very stable and you may be able to assign multicast > > addresses to aggregate neatly. > > > > However, once we want the application like instant message > > systems with vic & rat, situation change drastically. In other > > words, why don't you want to provide Access Grid service for > > the consumer market? Members of a virtual venue are sparsely > > distributed over the Internet subscribing different > > ASes. Using SSM or PIM-SM in short cut mode, number of routing > > entry become as same as number of transmitters. That means routes > > grows up to millions very easily. > > > > To make matter worse, curious customers rapidly loiter from > > venue to venue, joining and pruning (S,G). Whenever they zap > > the channel, PIM-SSM signaling travels from receiver to most > > nearest branching router marking or erasing routing entries. > > > > That's why I want you to scale your routers up to millions > > multicast routes. If you will not, neither we will be support > > instant video message on the multicast. > > > > Again. > > > > Please, could you tell us why you consider 5,000 is enough and > > 5,000,000 is too much for the Internet, Dino? > > ---- > > Yuji > > > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 14:37:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15522 for ; Wed, 24 Mar 2004 14:37:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EBS-0008Gz-PJ; Wed, 24 Mar 2004 14:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EAm-00086V-UW for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 14:36:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15384 for ; Wed, 24 Mar 2004 14:36:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6EAk-0000Kk-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:36:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6E9o-0000Fh-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:35:20 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B6E8q-00009C-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:34:20 -0500 Received: (qmail 56781 invoked from network); 24 Mar 2004 19:40:28 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 19:40:28 -0000 Message-ID: <4061E35F.2080700@necom830.hpcl.titech.ac.jp> Date: Thu, 25 Mar 2004 04:37:03 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: IMAI Yuji CC: dino@procket.com, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> <40616F22.1020608@necom830.hpcl.titech.ac.jp> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <20040324215300H.kimai@labs.fujitsu.com> In-Reply-To: <20040324215300H.kimai@labs.fujitsu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit IMAI Yuji wrote: >>Without regulation on radio wave frequency, there will be a lot >>lot lot more than 5,000 broadcasters. >> >>If multicast is freely available, people with more than two >>family members at a distance, the number of which will be a lot >>more than 5,000,000, will want to have a multicast group or two >>for thier families. > >>That's essentially why multicast must be charged. > You just talking only about the number of POTENTIAL users. I'm talking about the number of potential groups or senders. Who else are talking about the miserably small number of currently active groups? Note that, as you know, in Japan, there should be a lot more than 5,000 home users receiving multicast. >>That is, multicast scales only if people pay money proportional >>to the duration and area of the communication and the payment >>mechanisms are scalably automated. > How much will you price the multicast channel for the IESG > conference by Access Grid? It involves not only routing table entry but also bandwidth reservation. So, the answer depends on how expensive unicast bandwidth reservation will be, which, IMHO, should cost more than routing table reservation. For example, if trans-ocean 6Mbps unicast costs $1/min, multicast conference with 10 members involving trans-pacific and trans- atlantic link will cost a little more than $2/min. Multicast should costs less than doing it with multiple unicast. Or, people just use multiple unicast. > Most difficult point is how to > share the expense among ISPs. As it includes political layer > factor, it seems almost impossible to decide automatically. It involves policy a lot different from that of BGP but is not political. The difficulty is to think with BGP and its policy where communications are flat rated and ASes have their policy to choose the most favorable next hops. However, you must be aware that, with telephony, end users have the right to choose the most favorable long distance and international operators. With resource reservation, those who pays have the rights to have policies. That is, end users choose the route most favorable to them. It means we can't use DV routing protocol, such as BGP, but must use LS routing protocol with rate information flooded to end users, which means there must be aggressive aggregation. For multicast policy, it should also be noted that down stream side of a tree can not have any policy or the tree will be destroyed to have loops due to inconsistent policies. So, the policy can be set only by the root or the sender. It is a proof why BGMP and MSDP are no good. > Such complicated contract and negotiation will be possible > only by limited mega-media. Or you say it's just my > "believing" and start flaming? It has nothing multicast specific. So, you are saying only mega-media can use telephony. In the real world, money is the tool to hide complicated contract and negotiation. You can just pay the designated money. There can be arbitrary complex bilateral agreements between telephone operators and resource reserving ISPs. But, so are ISPs today with BGP. The important point is that end users just pay. We have designed and implemented such LS protocol and an associated signaling protocol. Search the web with HQLIP and SRSVP. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 14:37:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15523 for ; Wed, 24 Mar 2004 14:37:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EBs-0008U6-Ce for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 14:37:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OJbSW3032595 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 14:37:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EBS-0008Gz-PJ; Wed, 24 Mar 2004 14:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EAm-00086V-UW for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 14:36:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15384 for ; Wed, 24 Mar 2004 14:36:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6EAk-0000Kk-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:36:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6E9o-0000Fh-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:35:20 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B6E8q-00009C-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:34:20 -0500 Received: (qmail 56781 invoked from network); 24 Mar 2004 19:40:28 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 19:40:28 -0000 Message-ID: <4061E35F.2080700@necom830.hpcl.titech.ac.jp> Date: Thu, 25 Mar 2004 04:37:03 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: IMAI Yuji CC: dino@procket.com, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: <200403240112.i2O1CAnp012572@dino-pc.procket.com> <20040324132957Q.kimai@labs.fujitsu.com> <40616F22.1020608@necom830.hpcl.titech.ac.jp> <4060DFE3.6090202@necom830.hpcl.titech.ac.jp> <20040324215300H.kimai@labs.fujitsu.com> In-Reply-To: <20040324215300H.kimai@labs.fujitsu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit IMAI Yuji wrote: >>Without regulation on radio wave frequency, there will be a lot >>lot lot more than 5,000 broadcasters. >> >>If multicast is freely available, people with more than two >>family members at a distance, the number of which will be a lot >>more than 5,000,000, will want to have a multicast group or two >>for thier families. > >>That's essentially why multicast must be charged. > You just talking only about the number of POTENTIAL users. I'm talking about the number of potential groups or senders. Who else are talking about the miserably small number of currently active groups? Note that, as you know, in Japan, there should be a lot more than 5,000 home users receiving multicast. >>That is, multicast scales only if people pay money proportional >>to the duration and area of the communication and the payment >>mechanisms are scalably automated. > How much will you price the multicast channel for the IESG > conference by Access Grid? It involves not only routing table entry but also bandwidth reservation. So, the answer depends on how expensive unicast bandwidth reservation will be, which, IMHO, should cost more than routing table reservation. For example, if trans-ocean 6Mbps unicast costs $1/min, multicast conference with 10 members involving trans-pacific and trans- atlantic link will cost a little more than $2/min. Multicast should costs less than doing it with multiple unicast. Or, people just use multiple unicast. > Most difficult point is how to > share the expense among ISPs. As it includes political layer > factor, it seems almost impossible to decide automatically. It involves policy a lot different from that of BGP but is not political. The difficulty is to think with BGP and its policy where communications are flat rated and ASes have their policy to choose the most favorable next hops. However, you must be aware that, with telephony, end users have the right to choose the most favorable long distance and international operators. With resource reservation, those who pays have the rights to have policies. That is, end users choose the route most favorable to them. It means we can't use DV routing protocol, such as BGP, but must use LS routing protocol with rate information flooded to end users, which means there must be aggressive aggregation. For multicast policy, it should also be noted that down stream side of a tree can not have any policy or the tree will be destroyed to have loops due to inconsistent policies. So, the policy can be set only by the root or the sender. It is a proof why BGMP and MSDP are no good. > Such complicated contract and negotiation will be possible > only by limited mega-media. Or you say it's just my > "believing" and start flaming? It has nothing multicast specific. So, you are saying only mega-media can use telephony. In the real world, money is the tool to hide complicated contract and negotiation. You can just pay the designated money. There can be arbitrary complex bilateral agreements between telephone operators and resource reserving ISPs. But, so are ISPs today with BGP. The important point is that end users just pay. We have designed and implemented such LS protocol and an associated signaling protocol. Search the web with HQLIP and SRSVP. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 14:39:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15657 for ; Wed, 24 Mar 2004 14:39:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EDN-0000XE-CO; Wed, 24 Mar 2004 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ECo-0000UW-0f for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 14:38:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15579 for ; Wed, 24 Mar 2004 14:38:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ECl-0000aq-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:38:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6EBt-0000TN-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:37:30 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B6EAt-0000MQ-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:36:28 -0500 Received: (qmail 56794 invoked from network); 24 Mar 2004 19:42:40 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 19:42:40 -0000 Message-ID: <4061E3E2.30001@necom830.hpcl.titech.ac.jp> Date: Thu, 25 Mar 2004 04:39:14 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Rick Boivie CC: shep@shepfarm.com, IMAI Yuji , dino@procket.com, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rick Boivie wrote: > So lack of last mile deployment doesn't seem to be the issue. Rather > the problem seems to be that multicast doesn't provide very good support > for large numbers of small groups -- as the IAB said in RFC 2902. More serious problem is to provide very good support for large numbers of medium sized groups. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 14:39:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15668 for ; Wed, 24 Mar 2004 14:39:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EDT-0000Zp-Ml for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 14:39:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OJd7Kq002139 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 14:39:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EDN-0000XE-CO; Wed, 24 Mar 2004 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ECo-0000UW-0f for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 14:38:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15579 for ; Wed, 24 Mar 2004 14:38:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ECl-0000aq-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:38:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6EBt-0000TN-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:37:30 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B6EAt-0000MQ-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:36:28 -0500 Received: (qmail 56794 invoked from network); 24 Mar 2004 19:42:40 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 19:42:40 -0000 Message-ID: <4061E3E2.30001@necom830.hpcl.titech.ac.jp> Date: Thu, 25 Mar 2004 04:39:14 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Rick Boivie CC: shep@shepfarm.com, IMAI Yuji , dino@procket.com, eckert@cisco.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rick Boivie wrote: > So lack of last mile deployment doesn't seem to be the issue. Rather > the problem seems to be that multicast doesn't provide very good support > for large numbers of small groups -- as the IAB said in RFC 2902. More serious problem is to provide very good support for large numbers of medium sized groups. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 14:53:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16359 for ; Wed, 24 Mar 2004 14:53:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EQw-00021F-0P; Wed, 24 Mar 2004 14:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EQZ-0001zr-TR for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 14:52:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16318 for ; Wed, 24 Mar 2004 14:52:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6EQX-00022p-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:52:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6EPe-0001wr-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:51:43 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6EOv-0001o3-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:50:57 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Mar 2004 11:56:43 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2OJoOUe020641; Wed, 24 Mar 2004 11:50:24 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA29902; Wed, 24 Mar 2004 11:50:02 -0800 (PST) Date: Wed, 24 Mar 2004 11:50:02 -0800 From: Toerless Eckert To: John Zwiebel Cc: Rick Boivie , "" , "" , "" , "" , IMAI Yuji , "" , Dino Farinacci , "" Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324195002.GZ17887@cisco.com> References: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, Mar 24, 2004 at 10:52:33AM -0800, John Zwiebel wrote: > It -might- be a good idea to suggest some number of participants > in a conference (or whatever kind of application) under which > unicast should be the preferred transport method. But that would also be relative to the total size of the tree in terms of how many total hops are on it. Or the shape of the treee. Imagine you've got a group of 50,000 people watching a sports game. We would probably say that using multicast offhand is fine for this size of receivers, but if 49,999 are in the USA and one lonely guy in mongolia wants to watch it too, you'd probably argue that the 10 hop branch down to mongolia might not want to waste a state on that. On the other hand if this tree actually has 25,000 viewers in mongolia and 25,000 in the USA (because it's i don't know mongoliva vs. the us at the game of soccer) , then the long branch into mongolia would not be a problem. At some point in time i'd really love to have someone revisit the idea which i think in the past Dino and DaveO claimed ownership for: carry forward across PIM joins the total number of viewers on the downstream branch. This total number of viewers would be an excellent measure of importance of a particular OIF entry and could also be used to derive a per viewer cost model. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 14:53:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16363 for ; Wed, 24 Mar 2004 14:53:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ER0-00022S-HA for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 14:53:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OJr6SE007835 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 14:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EQw-00021F-0P; Wed, 24 Mar 2004 14:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EQZ-0001zr-TR for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 14:52:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16318 for ; Wed, 24 Mar 2004 14:52:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6EQX-00022p-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:52:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6EPe-0001wr-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:51:43 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6EOv-0001o3-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:50:57 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Mar 2004 11:56:43 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2OJoOUe020641; Wed, 24 Mar 2004 11:50:24 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA29902; Wed, 24 Mar 2004 11:50:02 -0800 (PST) Date: Wed, 24 Mar 2004 11:50:02 -0800 From: Toerless Eckert To: John Zwiebel Cc: Rick Boivie , "" , "" , "" , "" , IMAI Yuji , "" , Dino Farinacci , "" Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040324195002.GZ17887@cisco.com> References: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, Mar 24, 2004 at 10:52:33AM -0800, John Zwiebel wrote: > It -might- be a good idea to suggest some number of participants > in a conference (or whatever kind of application) under which > unicast should be the preferred transport method. But that would also be relative to the total size of the tree in terms of how many total hops are on it. Or the shape of the treee. Imagine you've got a group of 50,000 people watching a sports game. We would probably say that using multicast offhand is fine for this size of receivers, but if 49,999 are in the USA and one lonely guy in mongolia wants to watch it too, you'd probably argue that the 10 hop branch down to mongolia might not want to waste a state on that. On the other hand if this tree actually has 25,000 viewers in mongolia and 25,000 in the USA (because it's i don't know mongoliva vs. the us at the game of soccer) , then the long branch into mongolia would not be a problem. At some point in time i'd really love to have someone revisit the idea which i think in the past Dino and DaveO claimed ownership for: carry forward across PIM joins the total number of viewers on the downstream branch. This total number of viewers would be an excellent measure of importance of a particular OIF entry and could also be used to derive a per viewer cost model. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 15:14:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18078 for ; Wed, 24 Mar 2004 15:14:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ekz-0003pz-4I for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 15:13:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OKDjui014741 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 15:13:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EkF-0003ds-PB; Wed, 24 Mar 2004 15:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ejd-0003Gy-SF for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 15:12:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17856 for ; Wed, 24 Mar 2004 15:12:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ejc-0003Z7-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:12:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Eiq-0003Vu-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:11:33 -0500 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 1B6Ei6-0003O1-00 for Routing-discussion@ietf.org; Wed, 24 Mar 2004 15:10:46 -0500 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i2OKAF0132558; Wed, 24 Mar 2004 14:10:15 -0600 Message-Id: <5.2.0.9.2.20040324140900.0436b828@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 24 Mar 2004 14:10:07 -0600 To: Routing-discussion@ietf.org, mboned@lists.uoregon.edu From: Bill Nickless Subject: Re: mboned: BGMP & DVMRP status Q. Mime-Version: 1.0 Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Resent to get through the various mail filters) At 10:52 AM 3/24/2004 -0800, John Zwiebel wrote: >It -might- be a good idea to suggest some number of participants >in a conference (or whatever kind of application) under which >unicast should be the preferred transport method. > >It would be "fine" with me if everything was multicast (in fact >I'd probably prefer it) but that would interfere with the deployment >of some applications. > >I'm looking for a way of suggesting to the user that "for right now, >until certain multicast questions are answered and deployment established, >you should use unicast with a view toward transitioning to multicast >as each of these barriers are removed. > >It makes the app developers problem more difficult to solve, but >provides a realistic roadmap with which they can make informed decisions. This is not inconsistent with an end-to-end automatic tunneling model, designed in such a way that the internetwork can optimize the transport when the capability is available or desired. What do I mean? Consider the existing SSM model. Multicast traffic is requested by interested receivers, and is identified by the (S,G) (Source,Group) addresses. This receiver request effectively "grafts" the receiver onto a source-rooted distribution tree for the (S,G). Once the distribution tree is created, traffic flows from the source to each interested receiver. Such a process could be implemented entirely by hosts, without any explicit network support. The distribution tree would still be rooted at the source, but the tree would look more like a star. In other words, for small groups the source host itself would receive the receiver traffic requests and handle the replication. Each receiver would get a copy of the requested traffic over the existing unicast infrastructure. Explicit network support could be deployed incrementally. If the network element (router?) was prepared to do multicast replication, it would intercept any receiver traffic requests and "bundle" them together as they go towards the source. Likewise, as the traffic comes from the source towards interested receivers, the network element would handle replication. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP: 021D EB98 03B3 2E83 3D71 0397 251D 819A D0BE EA32 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQGHrJSUdgZrQvuoyEQJaWwCfdFR6XjRROtlpaTWwSaKOAH5ZZ70AoLEA x0kx0AXPodclO5uIlOdcDHqH =iCR2 -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 15:18:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18623 for ; Wed, 24 Mar 2004 15:18:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ep7-0005Cf-B0; Wed, 24 Mar 2004 15:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EVG-0002dK-As for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 14:57:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16596 for ; Wed, 24 Mar 2004 14:57:27 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6EVD-0002UD-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:57:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6EUN-0002Qp-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:56:36 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[bbfMjE4L45S9FRvUV7gUd7RqKkA5zY/b]) by ietf-mx with esmtp (Exim 4.12) id 1B6ETo-0002Ma-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:56:00 -0500 Received: from shepfarm.com (IDENT:4cVK0C/EKFcvYfaHPbNcoGS2VJVLM0Pc@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2OLbNTk009912; Wed, 24 Mar 2004 13:37:23 -0800 Date: Wed, 24 Mar 2004 13:37:22 -0800 (PST) To: John Zwiebel cc: Rick Boivie , "" , "" , "" , "" , IMAI Yuji , Toerless Eckert , "" , Dino Farinacci , "" Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Plus, please remember, ANY application with more than one source only gains the benefits of mcast transit at the source, not the receivers. Each receiver still has receive traffic from each source. So sure, the network still gains from mcast replication, but the receivers last mile still has N incoming streams. Greg On Wed, 24 Mar 2004, John Zwiebel wrote: > > > > On Wed, 24 Mar 2004, Rick Boivie wrote: > >> As the Internet Architecture Board said (in RFC 2902) "providing for > >> many > >> groups > >> of small conferences ... scales badly given the current multicast > >> model". > >> > >> So if we want tapplications like the above to work when there is > >> limited > >> bandwidth > >> in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > >> multicast scheme that > >> can support very large or unlimited numbers of small groups. > >> > >> Rick Boivie > >> IBM T. J. Watson Research Center > >> rhboivie@us.ibm.com > > I'd like to ask how many receivers it takes to make the transition > from a "small group" to a "large group". > > Considering: > -- the last-hop deployment problems > -- the limited BW on the last hop > -- the current difficulty of providing a SSM based multicast tree > -- the perceived limit of the total number of groups msdp can handle > (currently about 4000, based on the fact that we're handling less > than that now) > > It -might- be a good idea to suggest some number of participants > in a conference (or whatever kind of application) under which > unicast should be the preferred transport method. > > It would be "fine" with me if everything was multicast (in fact > I'd probably prefer it) but that would interfere with the deployment > of some applications. > > I'm looking for a way of suggesting to the user that "for right now, > until certain multicast questions are answered and deployment > established, > you should use unicast with a view toward transitioning to multicast > as each of these barriers are removed. > > It makes the app developers problem more difficult to solve, but > provides a realistic roadmap with which they can make informed > decisions. > > _______________________________________________________________ > user interface: http://darkwing.uoregon.edu/~llynch/mboned.html > web archive: http://darkwing.uoregon.edu/~llynch/mboned/ > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 15:18:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18624 for ; Wed, 24 Mar 2004 15:18:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ep8-0005Dl-0U; Wed, 24 Mar 2004 15:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ecu-0008I9-IM for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 15:05:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17077 for ; Wed, 24 Mar 2004 15:05:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ecq-00030g-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:05:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Ebs-0002xH-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:04:21 -0500 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 1B6Eb3-0002r5-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:03:30 -0500 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i2OJh0044576; Wed, 24 Mar 2004 13:43:03 -0600 Message-Id: <5.2.0.9.2.20040324132507.042ff658@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 24 Mar 2004 13:42:43 -0600 To: John Zwiebel From: Bill Nickless Subject: Re: mboned: BGMP & DVMRP status Q. Cc: Rick Boivie , "" , "" , "" , Rick Boivie , "" , John Zwiebel , IMAI Yuji , Toerless Eckert , "" , Dino Farinacci , "" In-Reply-To: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> References: Mime-Version: 1.0 Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 10:52 AM 3/24/2004 -0800, John Zwiebel wrote: >It -might- be a good idea to suggest some number of participants >in a conference (or whatever kind of application) under which >unicast should be the preferred transport method. > >It would be "fine" with me if everything was multicast (in fact >I'd probably prefer it) but that would interfere with the deployment >of some applications. > >I'm looking for a way of suggesting to the user that "for right now, >until certain multicast questions are answered and deployment established, >you should use unicast with a view toward transitioning to multicast >as each of these barriers are removed. > >It makes the app developers problem more difficult to solve, but >provides a realistic roadmap with which they can make informed decisions. This is not inconsistent with an end-to-end automatic tunneling model, designed in such a way that the internetwork can optimize the transport when the capability is available or desired. What do I mean? Consider the existing SSM model. Multicast traffic is requested by interested receivers, and is identified by the (S,G) (Source,Group) addresses. This receiver request effectively "grafts" the receiver onto a source-rooted distribution tree for the (S,G). Once the distribution tree is created, traffic flows from the source to each interested receiver. Such a process could be implemented entirely by hosts, without any explicit network support. The distribution tree would still be rooted at the source, but the tree would look more like a star. In other words, for small groups the source host itself would receive the receiver traffic requests and handle the replication. Each receiver would get a copy of the requested traffic over the existing unicast infrastructure. Explicit network support could be deployed incrementally. If the network element (router?) was prepared to do multicast replication, it would intercept any receiver traffic requests and "bundle" them together as they go towards the source. Likewise, as the traffic comes from the source towards interested receivers, the network element would handle replication. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP: 021D EB98 03B3 2E83 3D71 0397 251D 819A D0BE EA32 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQGHkuSUdgZrQvuoyEQJhjACfXxJwKsm6HKWVhhVLoo/Ns8MtYxUAoPeO sfT+08RPbtHMMivUTORTLXS/ =JQ1P -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 15:19:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18703 for ; Wed, 24 Mar 2004 15:19:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EpF-0005Q4-Ne for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 15:18:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OKI9Q3020609 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 15:18:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ep6-0005Bs-PA; Wed, 24 Mar 2004 15:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DY5-0004bv-0D for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 13:56:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13328 for ; Wed, 24 Mar 2004 13:56:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6DY2-0004wD-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:56:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6DXF-0004rP-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:55:30 -0500 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1B6DWF-0004hy-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:54:27 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i2OL2ppL073762; Wed, 24 Mar 2004 13:02:52 -0800 (PST) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2OIqZd1009608; Wed, 24 Mar 2004 10:52:35 -0800 (PST) Received: from [10.1.5.14] ([10.1.5.14]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Mar 2004 10:52:35 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> Content-Transfer-Encoding: 7bit Cc: "" , "" , "" , Rick Boivie , "" , John Zwiebel , IMAI Yuji , Toerless Eckert , "" , Dino Farinacci , "" From: John Zwiebel Subject: Re: mboned: BGMP & DVMRP status Q. Date: Wed, 24 Mar 2004 10:52:33 -0800 To: Rick Boivie X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 24 Mar 2004 18:52:35.0023 (UTC) FILETIME=[2B94DDF0:01C411D1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > On Wed, 24 Mar 2004, Rick Boivie wrote: >> As the Internet Architecture Board said (in RFC 2902) "providing for >> many >> groups >> of small conferences ... scales badly given the current multicast >> model". >> >> So if we want tapplications like the above to work when there is >> limited >> bandwidth >> in the first mile (e.g. DSL, cable modem, wireless etc.) we need a >> multicast scheme that >> can support very large or unlimited numbers of small groups. >> >> Rick Boivie >> IBM T. J. Watson Research Center >> rhboivie@us.ibm.com I'd like to ask how many receivers it takes to make the transition from a "small group" to a "large group". Considering: -- the last-hop deployment problems -- the limited BW on the last hop -- the current difficulty of providing a SSM based multicast tree -- the perceived limit of the total number of groups msdp can handle (currently about 4000, based on the fact that we're handling less than that now) It -might- be a good idea to suggest some number of participants in a conference (or whatever kind of application) under which unicast should be the preferred transport method. It would be "fine" with me if everything was multicast (in fact I'd probably prefer it) but that would interfere with the deployment of some applications. I'm looking for a way of suggesting to the user that "for right now, until certain multicast questions are answered and deployment established, you should use unicast with a view toward transitioning to multicast as each of these barriers are removed. It makes the app developers problem more difficult to solve, but provides a realistic roadmap with which they can make informed decisions. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 15:19:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18704 for ; Wed, 24 Mar 2004 15:19:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EpF-0005Mn-Ez for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 15:18:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OKI9TW020607 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 15:18:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ep7-0005Cf-B0; Wed, 24 Mar 2004 15:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EVG-0002dK-As for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 14:57:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16596 for ; Wed, 24 Mar 2004 14:57:27 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6EVD-0002UD-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:57:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6EUN-0002Qp-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:56:36 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[bbfMjE4L45S9FRvUV7gUd7RqKkA5zY/b]) by ietf-mx with esmtp (Exim 4.12) id 1B6ETo-0002Ma-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 14:56:00 -0500 Received: from shepfarm.com (IDENT:4cVK0C/EKFcvYfaHPbNcoGS2VJVLM0Pc@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2OLbNTk009912; Wed, 24 Mar 2004 13:37:23 -0800 Date: Wed, 24 Mar 2004 13:37:22 -0800 (PST) To: John Zwiebel cc: Rick Boivie , "" , "" , "" , "" , IMAI Yuji , Toerless Eckert , "" , Dino Farinacci , "" Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Plus, please remember, ANY application with more than one source only gains the benefits of mcast transit at the source, not the receivers. Each receiver still has receive traffic from each source. So sure, the network still gains from mcast replication, but the receivers last mile still has N incoming streams. Greg On Wed, 24 Mar 2004, John Zwiebel wrote: > > > > On Wed, 24 Mar 2004, Rick Boivie wrote: > >> As the Internet Architecture Board said (in RFC 2902) "providing for > >> many > >> groups > >> of small conferences ... scales badly given the current multicast > >> model". > >> > >> So if we want tapplications like the above to work when there is > >> limited > >> bandwidth > >> in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > >> multicast scheme that > >> can support very large or unlimited numbers of small groups. > >> > >> Rick Boivie > >> IBM T. J. Watson Research Center > >> rhboivie@us.ibm.com > > I'd like to ask how many receivers it takes to make the transition > from a "small group" to a "large group". > > Considering: > -- the last-hop deployment problems > -- the limited BW on the last hop > -- the current difficulty of providing a SSM based multicast tree > -- the perceived limit of the total number of groups msdp can handle > (currently about 4000, based on the fact that we're handling less > than that now) > > It -might- be a good idea to suggest some number of participants > in a conference (or whatever kind of application) under which > unicast should be the preferred transport method. > > It would be "fine" with me if everything was multicast (in fact > I'd probably prefer it) but that would interfere with the deployment > of some applications. > > I'm looking for a way of suggesting to the user that "for right now, > until certain multicast questions are answered and deployment > established, > you should use unicast with a view toward transitioning to multicast > as each of these barriers are removed. > > It makes the app developers problem more difficult to solve, but > provides a realistic roadmap with which they can make informed > decisions. > > _______________________________________________________________ > user interface: http://darkwing.uoregon.edu/~llynch/mboned.html > web archive: http://darkwing.uoregon.edu/~llynch/mboned/ > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 15:19:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18702 for ; Wed, 24 Mar 2004 15:19:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EpF-0005Mg-E6 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 15:18:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OKI90D020608 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 15:18:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ep8-0005Dl-0U; Wed, 24 Mar 2004 15:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ecu-0008I9-IM for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 15:05:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17077 for ; Wed, 24 Mar 2004 15:05:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ecq-00030g-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:05:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Ebs-0002xH-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:04:21 -0500 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 1B6Eb3-0002r5-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:03:30 -0500 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i2OJh0044576; Wed, 24 Mar 2004 13:43:03 -0600 Message-Id: <5.2.0.9.2.20040324132507.042ff658@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 24 Mar 2004 13:42:43 -0600 To: John Zwiebel From: Bill Nickless Subject: Re: mboned: BGMP & DVMRP status Q. Cc: Rick Boivie , "" , "" , "" , Rick Boivie , "" , John Zwiebel , IMAI Yuji , Toerless Eckert , "" , Dino Farinacci , "" In-Reply-To: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> References: Mime-Version: 1.0 Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 10:52 AM 3/24/2004 -0800, John Zwiebel wrote: >It -might- be a good idea to suggest some number of participants >in a conference (or whatever kind of application) under which >unicast should be the preferred transport method. > >It would be "fine" with me if everything was multicast (in fact >I'd probably prefer it) but that would interfere with the deployment >of some applications. > >I'm looking for a way of suggesting to the user that "for right now, >until certain multicast questions are answered and deployment established, >you should use unicast with a view toward transitioning to multicast >as each of these barriers are removed. > >It makes the app developers problem more difficult to solve, but >provides a realistic roadmap with which they can make informed decisions. This is not inconsistent with an end-to-end automatic tunneling model, designed in such a way that the internetwork can optimize the transport when the capability is available or desired. What do I mean? Consider the existing SSM model. Multicast traffic is requested by interested receivers, and is identified by the (S,G) (Source,Group) addresses. This receiver request effectively "grafts" the receiver onto a source-rooted distribution tree for the (S,G). Once the distribution tree is created, traffic flows from the source to each interested receiver. Such a process could be implemented entirely by hosts, without any explicit network support. The distribution tree would still be rooted at the source, but the tree would look more like a star. In other words, for small groups the source host itself would receive the receiver traffic requests and handle the replication. Each receiver would get a copy of the requested traffic over the existing unicast infrastructure. Explicit network support could be deployed incrementally. If the network element (router?) was prepared to do multicast replication, it would intercept any receiver traffic requests and "bundle" them together as they go towards the source. Likewise, as the traffic comes from the source towards interested receivers, the network element would handle replication. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP: 021D EB98 03B3 2E83 3D71 0397 251D 819A D0BE EA32 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQGHkuSUdgZrQvuoyEQJhjACfXxJwKsm6HKWVhhVLoo/Ns8MtYxUAoPeO sfT+08RPbtHMMivUTORTLXS/ =JQ1P -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 15:38:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19904 for ; Wed, 24 Mar 2004 15:38:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6F8T-0001qE-75; Wed, 24 Mar 2004 15:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6F7v-0001PJ-Ew for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 15:37:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19892 for ; Wed, 24 Mar 2004 15:37:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6F7t-000614-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:37:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6F6t-0005tI-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:36:23 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 1B6F60-0005hJ-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:35:28 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA23075; Wed, 24 Mar 2004 12:34:44 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id MAA25474; Wed, 24 Mar 2004 12:34:43 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i2OKWGk05908; Wed, 24 Mar 2004 12:32:16 -0800 (PST) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Wed, 24 Mar 2004 15:31:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: mboned: BGMP & DVMRP status Q. Date: Wed, 24 Mar 2004 15:31:32 -0500 Message-ID: Thread-Topic: mboned: BGMP & DVMRP status Q. Thread-Index: AcQR3GiCYP+UW+4SQFOor+wLtRvF8AAAUpAQ From: "Manfredi, Albert E" To: "Toerless Eckert" , "John Zwiebel" Cc: , X-OriginalArrivalTime: 24 Mar 2004 20:31:33.0173 (UTC) FILETIME=[FEFEA650:01C411DE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > From: Toerless Eckert [mailto:eckert@cisco.com] > We would probably > say that using multicast offhand is fine for this size of=20 > receivers, but > if 49,999 are in the USA and one lonely guy in mongolia wants=20 > to watch it too, > you'd probably argue that the 10 hop branch down to mongolia=20 > might not want=20 > to waste a state on that. But you wouldn't begrudge a unicast connection to that guy in Mongolia, = so why conceptually should multicast be different? Seems like a PIM-SM = type of model should be capable of supporting the 50K-1 US users and one = Mongolian user, or vice versa? The trick is to locate the rendezvous point correctly, or to allow for = multiple RPs when the multicast tree calls for them? If two large = clusters of users are spread far apart, seems like two RPs and a tunnel = between them makes sense. But done dynamically, maybe using topology = info already available to multicast routers. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 15:38:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19907 for ; Wed, 24 Mar 2004 15:38:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6F8Z-0001si-NY for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 15:38:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OKc7RH007225 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 15:38:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6F8T-0001qE-75; Wed, 24 Mar 2004 15:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6F7v-0001PJ-Ew for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 15:37:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19892 for ; Wed, 24 Mar 2004 15:37:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6F7t-000614-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:37:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6F6t-0005tI-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:36:23 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 1B6F60-0005hJ-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:35:28 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA23075; Wed, 24 Mar 2004 12:34:44 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id MAA25474; Wed, 24 Mar 2004 12:34:43 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i2OKWGk05908; Wed, 24 Mar 2004 12:32:16 -0800 (PST) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Wed, 24 Mar 2004 15:31:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: mboned: BGMP & DVMRP status Q. Date: Wed, 24 Mar 2004 15:31:32 -0500 Message-ID: Thread-Topic: mboned: BGMP & DVMRP status Q. Thread-Index: AcQR3GiCYP+UW+4SQFOor+wLtRvF8AAAUpAQ From: "Manfredi, Albert E" To: "Toerless Eckert" , "John Zwiebel" Cc: , X-OriginalArrivalTime: 24 Mar 2004 20:31:33.0173 (UTC) FILETIME=[FEFEA650:01C411DE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > From: Toerless Eckert [mailto:eckert@cisco.com] > We would probably > say that using multicast offhand is fine for this size of=20 > receivers, but > if 49,999 are in the USA and one lonely guy in mongolia wants=20 > to watch it too, > you'd probably argue that the 10 hop branch down to mongolia=20 > might not want=20 > to waste a state on that. But you wouldn't begrudge a unicast connection to that guy in Mongolia, = so why conceptually should multicast be different? Seems like a PIM-SM = type of model should be capable of supporting the 50K-1 US users and one = Mongolian user, or vice versa? The trick is to locate the rendezvous point correctly, or to allow for = multiple RPs when the multicast tree calls for them? If two large = clusters of users are spread far apart, seems like two RPs and a tunnel = between them makes sense. But done dynamically, maybe using topology = info already available to multicast routers. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 16:03:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18074 for ; Wed, 24 Mar 2004 15:14:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EkF-0003ds-PB; Wed, 24 Mar 2004 15:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ejd-0003Gy-SF for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 15:12:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17856 for ; Wed, 24 Mar 2004 15:12:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ejc-0003Z7-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:12:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Eiq-0003Vu-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 15:11:33 -0500 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 1B6Ei6-0003O1-00 for Routing-discussion@ietf.org; Wed, 24 Mar 2004 15:10:46 -0500 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i2OKAF0132558; Wed, 24 Mar 2004 14:10:15 -0600 Message-Id: <5.2.0.9.2.20040324140900.0436b828@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 24 Mar 2004 14:10:07 -0600 To: Routing-discussion@ietf.org, mboned@lists.uoregon.edu From: Bill Nickless Subject: Re: mboned: BGMP & DVMRP status Q. Mime-Version: 1.0 Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Resent to get through the various mail filters) At 10:52 AM 3/24/2004 -0800, John Zwiebel wrote: >It -might- be a good idea to suggest some number of participants >in a conference (or whatever kind of application) under which >unicast should be the preferred transport method. > >It would be "fine" with me if everything was multicast (in fact >I'd probably prefer it) but that would interfere with the deployment >of some applications. > >I'm looking for a way of suggesting to the user that "for right now, >until certain multicast questions are answered and deployment established, >you should use unicast with a view toward transitioning to multicast >as each of these barriers are removed. > >It makes the app developers problem more difficult to solve, but >provides a realistic roadmap with which they can make informed decisions. This is not inconsistent with an end-to-end automatic tunneling model, designed in such a way that the internetwork can optimize the transport when the capability is available or desired. What do I mean? Consider the existing SSM model. Multicast traffic is requested by interested receivers, and is identified by the (S,G) (Source,Group) addresses. This receiver request effectively "grafts" the receiver onto a source-rooted distribution tree for the (S,G). Once the distribution tree is created, traffic flows from the source to each interested receiver. Such a process could be implemented entirely by hosts, without any explicit network support. The distribution tree would still be rooted at the source, but the tree would look more like a star. In other words, for small groups the source host itself would receive the receiver traffic requests and handle the replication. Each receiver would get a copy of the requested traffic over the existing unicast infrastructure. Explicit network support could be deployed incrementally. If the network element (router?) was prepared to do multicast replication, it would intercept any receiver traffic requests and "bundle" them together as they go towards the source. Likewise, as the traffic comes from the source towards interested receivers, the network element would handle replication. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP: 021D EB98 03B3 2E83 3D71 0397 251D 819A D0BE EA32 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQGHrJSUdgZrQvuoyEQJaWwCfdFR6XjRROtlpaTWwSaKOAH5ZZ70AoLEA x0kx0AXPodclO5uIlOdcDHqH =iCR2 -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 16:08:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18622 for ; Wed, 24 Mar 2004 15:18:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ep6-0005Bs-PA; Wed, 24 Mar 2004 15:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DY5-0004bv-0D for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 13:56:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13328 for ; Wed, 24 Mar 2004 13:56:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6DY2-0004wD-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:56:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6DXF-0004rP-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:55:30 -0500 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1B6DWF-0004hy-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 13:54:27 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i2OL2ppL073762; Wed, 24 Mar 2004 13:02:52 -0800 (PST) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2OIqZd1009608; Wed, 24 Mar 2004 10:52:35 -0800 (PST) Received: from [10.1.5.14] ([10.1.5.14]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Mar 2004 10:52:35 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> Content-Transfer-Encoding: 7bit Cc: "" , "" , "" , Rick Boivie , "" , John Zwiebel , IMAI Yuji , Toerless Eckert , "" , Dino Farinacci , "" From: John Zwiebel Subject: Re: mboned: BGMP & DVMRP status Q. Date: Wed, 24 Mar 2004 10:52:33 -0800 To: Rick Boivie X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 24 Mar 2004 18:52:35.0023 (UTC) FILETIME=[2B94DDF0:01C411D1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > On Wed, 24 Mar 2004, Rick Boivie wrote: >> As the Internet Architecture Board said (in RFC 2902) "providing for >> many >> groups >> of small conferences ... scales badly given the current multicast >> model". >> >> So if we want tapplications like the above to work when there is >> limited >> bandwidth >> in the first mile (e.g. DSL, cable modem, wireless etc.) we need a >> multicast scheme that >> can support very large or unlimited numbers of small groups. >> >> Rick Boivie >> IBM T. J. Watson Research Center >> rhboivie@us.ibm.com I'd like to ask how many receivers it takes to make the transition from a "small group" to a "large group". Considering: -- the last-hop deployment problems -- the limited BW on the last hop -- the current difficulty of providing a SSM based multicast tree -- the perceived limit of the total number of groups msdp can handle (currently about 4000, based on the fact that we're handling less than that now) It -might- be a good idea to suggest some number of participants in a conference (or whatever kind of application) under which unicast should be the preferred transport method. It would be "fine" with me if everything was multicast (in fact I'd probably prefer it) but that would interfere with the deployment of some applications. I'm looking for a way of suggesting to the user that "for right now, until certain multicast questions are answered and deployment established, you should use unicast with a view toward transitioning to multicast as each of these barriers are removed. It makes the app developers problem more difficult to solve, but provides a realistic roadmap with which they can make informed decisions. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 17:14:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25007 for ; Wed, 24 Mar 2004 17:14:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6GdM-0004qB-PH; Wed, 24 Mar 2004 17:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Gco-0004ej-De for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 17:13:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24979 for ; Wed, 24 Mar 2004 17:13:23 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Gcm-0005zX-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 17:13:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Gbr-0005xq-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 17:12:27 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[4cP0SaUeA3ZBDnmeoTkm/uTW5kU118Ou]) by ietf-mx with esmtp (Exim 4.12) id 1B6Gb6-0005w5-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 17:11:40 -0500 Received: from shepfarm.com (IDENT:TX269rPNZIAcf3bYSfk1Ba0fd5xi0am2@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2ONr1Tk010286; Wed, 24 Mar 2004 15:53:01 -0800 Date: Wed, 24 Mar 2004 15:53:01 -0800 (PST) To: Masataka Ohta cc: Rick Boivie , IMAI Yuji , , , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <4061E3E2.30001@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Thu, 25 Mar 2004, Masataka Ohta wrote: > Rick Boivie wrote: > > > So lack of last mile deployment doesn't seem to be the issue. Rather > > the problem seems to be that multicast doesn't provide very good support > > for large numbers of small groups -- as the IAB said in RFC 2902. > > More serious problem is to provide very good support for > large numbers of medium sized groups. > > Masataka Ohta Really? More serious? I don't doubt that it is an issue - in the future - I just know of no current networks suffering from global mcast scaling today. The scaling issue I'm facing involves me, and my ability to gain console access to every router on earth in order to enable PIM. Until that is solved, or the need for me to do it myself is eliminated, then I'd love to help tackle the scaling issues we encounter. Greg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 17:14:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25024 for ; Wed, 24 Mar 2004 17:14:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Gdo-0004sI-Jf for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 17:14:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OMESdT018697 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 17:14:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6GdM-0004qB-PH; Wed, 24 Mar 2004 17:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Gco-0004ej-De for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 17:13:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24979 for ; Wed, 24 Mar 2004 17:13:23 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Gcm-0005zX-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 17:13:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Gbr-0005xq-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 17:12:27 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[4cP0SaUeA3ZBDnmeoTkm/uTW5kU118Ou]) by ietf-mx with esmtp (Exim 4.12) id 1B6Gb6-0005w5-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 17:11:40 -0500 Received: from shepfarm.com (IDENT:TX269rPNZIAcf3bYSfk1Ba0fd5xi0am2@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2ONr1Tk010286; Wed, 24 Mar 2004 15:53:01 -0800 Date: Wed, 24 Mar 2004 15:53:01 -0800 (PST) To: Masataka Ohta cc: Rick Boivie , IMAI Yuji , , , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <4061E3E2.30001@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Thu, 25 Mar 2004, Masataka Ohta wrote: > Rick Boivie wrote: > > > So lack of last mile deployment doesn't seem to be the issue. Rather > > the problem seems to be that multicast doesn't provide very good support > > for large numbers of small groups -- as the IAB said in RFC 2902. > > More serious problem is to provide very good support for > large numbers of medium sized groups. > > Masataka Ohta Really? More serious? I don't doubt that it is an issue - in the future - I just know of no current networks suffering from global mcast scaling today. The scaling issue I'm facing involves me, and my ability to gain console access to every router on earth in order to enable PIM. Until that is solved, or the need for me to do it myself is eliminated, then I'd love to help tackle the scaling issues we encounter. Greg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 18:01:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27357 for ; Wed, 24 Mar 2004 18:01:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6HMr-0001Oa-G6; Wed, 24 Mar 2004 18:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6HMT-00016k-Rv for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 18:00:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27260 for ; Wed, 24 Mar 2004 18:00:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6HMR-0001bt-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 18:00:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6HLU-0001Ye-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 17:59:36 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B6HL3-0001VT-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 17:59:09 -0500 Received: (qmail 57711 invoked from network); 24 Mar 2004 23:05:24 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 23:05:24 -0000 Message-ID: <40621362.5030808@necom830.hpcl.titech.ac.jp> Date: Thu, 25 Mar 2004 08:01:54 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Toerless Eckert CC: John Zwiebel , Rick Boivie , "" , "" , "" , IMAI Yuji , "" , Dino Farinacci , "" Subject: Re: mboned: BGMP & DVMRP status Q. References: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> <20040324195002.GZ17887@cisco.com> In-Reply-To: <20040324195002.GZ17887@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Toerless Eckert wrote: > But that would also be relative to the total size of the tree in terms > of how many total hops are on it. Or the shape of the treee. Imagine > you've got a group of 50,000 people watching a sports game. We would probably > say that using multicast offhand is fine for this size of receivers, but > if 49,999 are in the USA and one lonely guy in mongolia wants to watch it too, > you'd probably argue that the 10 hop branch down to mongolia might not want > to waste a state on that. Who, do you mean is "you" which argue? > On the other hand if this tree actually has > 25,000 viewers in mongolia and 25,000 in the USA What if there are 1 receivers in different 100 countries? What is there are 10 receivers in Mongolia? There is no generic answer and they are policy issues of the groups to be determined by the groups' administrators. A realistic approach is to let the root optionally allow to specify the areas of multicast, which is what I implemented. Group administrators should use OOB mechanism to guess the expected number of receivers in each area. > At some point in time i'd really love to have someone revisit the idea > which i think in the past Dino and DaveO claimed ownership for: carry > forward across PIM joins the total number of viewers on the downstream > branch. This total number of viewers would be an excellent measure of > importance of a particular OIF entry and could also be used to derive a > per viewer cost model. That is a stupid idea ignoring network cost and familiar facts that both routes and receivers change dynamically. First, the issue is cost performance one that mere number of receivers without cost information to reach them is useless. Second, at some point of the tree in USA, the number of receivers will often reach 1 that there will be transition, just like the case with mongolia, to unicast. However, the mechanism is almost useless to reduce the number of routing table entries on the backbone, where the resource is most precious. Third, it involves interaction between intermediate routers and a upper layer protocol in addition to IGMP to let the upper layer protocol issue unicast packets to control individual receivers, which does not scale. Forth, even if there is enough number of receivers in Mongolia, they may be using different transpacific links, sharing the same one or the situation changes dynamically. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 18:01:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27360 for ; Wed, 24 Mar 2004 18:01:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6HNB-0001h0-Po for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 18:01:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ON1Lhs006496 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 18:01:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6HMr-0001Oa-G6; Wed, 24 Mar 2004 18:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6HMT-00016k-Rv for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 18:00:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27260 for ; Wed, 24 Mar 2004 18:00:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6HMR-0001bt-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 18:00:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6HLU-0001Ye-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 17:59:36 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B6HL3-0001VT-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 17:59:09 -0500 Received: (qmail 57711 invoked from network); 24 Mar 2004 23:05:24 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2004 23:05:24 -0000 Message-ID: <40621362.5030808@necom830.hpcl.titech.ac.jp> Date: Thu, 25 Mar 2004 08:01:54 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Toerless Eckert CC: John Zwiebel , Rick Boivie , "" , "" , "" , IMAI Yuji , "" , Dino Farinacci , "" Subject: Re: mboned: BGMP & DVMRP status Q. References: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> <20040324195002.GZ17887@cisco.com> In-Reply-To: <20040324195002.GZ17887@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Toerless Eckert wrote: > But that would also be relative to the total size of the tree in terms > of how many total hops are on it. Or the shape of the treee. Imagine > you've got a group of 50,000 people watching a sports game. We would probably > say that using multicast offhand is fine for this size of receivers, but > if 49,999 are in the USA and one lonely guy in mongolia wants to watch it too, > you'd probably argue that the 10 hop branch down to mongolia might not want > to waste a state on that. Who, do you mean is "you" which argue? > On the other hand if this tree actually has > 25,000 viewers in mongolia and 25,000 in the USA What if there are 1 receivers in different 100 countries? What is there are 10 receivers in Mongolia? There is no generic answer and they are policy issues of the groups to be determined by the groups' administrators. A realistic approach is to let the root optionally allow to specify the areas of multicast, which is what I implemented. Group administrators should use OOB mechanism to guess the expected number of receivers in each area. > At some point in time i'd really love to have someone revisit the idea > which i think in the past Dino and DaveO claimed ownership for: carry > forward across PIM joins the total number of viewers on the downstream > branch. This total number of viewers would be an excellent measure of > importance of a particular OIF entry and could also be used to derive a > per viewer cost model. That is a stupid idea ignoring network cost and familiar facts that both routes and receivers change dynamically. First, the issue is cost performance one that mere number of receivers without cost information to reach them is useless. Second, at some point of the tree in USA, the number of receivers will often reach 1 that there will be transition, just like the case with mongolia, to unicast. However, the mechanism is almost useless to reduce the number of routing table entries on the backbone, where the resource is most precious. Third, it involves interaction between intermediate routers and a upper layer protocol in addition to IGMP to let the upper layer protocol issue unicast packets to control individual receivers, which does not scale. Forth, even if there is enough number of receivers in Mongolia, they may be using different transpacific links, sharing the same one or the situation changes dynamically. Masataka Ohta _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 18:45:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00524 for ; Wed, 24 Mar 2004 18:45:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6I3R-0002Y1-MI; Wed, 24 Mar 2004 18:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6I2s-0002Te-ON for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 18:44:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00457 for ; Wed, 24 Mar 2004 18:44:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6I2p-0004f8-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 18:44:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6I1r-0004cD-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 18:43:23 -0500 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 1B6I0s-0004Y7-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 18:42:22 -0500 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i2ONfU0283324; Wed, 24 Mar 2004 17:41:30 -0600 Message-Id: <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 24 Mar 2004 17:41:22 -0600 To: shep@shepfarm.com From: Bill Nickless Subject: Re: mboned: BGMP & DVMRP status Q. Cc: , In-Reply-To: References: <4061E3E2.30001@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 03:53 PM 3/24/2004 -0800, shep@shepfarm.com wrote: >The scaling issue I'm facing involves me, and my ability to gain console >access to every router on earth in order to enable PIM. Until that is >solved, or the need for me to do it myself is eliminated, then I'd love >to help tackle the scaling issues we encounter. > >Greg My scaling issue is getting the money to replace every IEEE 802.1 bridge on earth with one that can do IGMPv3 snooping properly. Oh yeah, MLDv2 too. And scheduling downtime to do the necessary forklift upgrades. When I write "every" I'm quite sure it's well in excess of 99%. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP: 021D EB98 03B3 2E83 3D71 0397 251D 819A D0BE EA32 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQGIcqSUdgZrQvuoyEQKq4gCfS47gIiDrySYYoBQjf8RqDTkmH4QAn148 jHxcX1lrXsfLcl7ud0bEO2YU =OOwn -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 18:45:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00541 for ; Wed, 24 Mar 2004 18:45:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6I3h-0002dI-Nl for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 18:45:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ONjHex010098 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 18:45:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6I3R-0002Y1-MI; Wed, 24 Mar 2004 18:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6I2s-0002Te-ON for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 18:44:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00457 for ; Wed, 24 Mar 2004 18:44:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6I2p-0004f8-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 18:44:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6I1r-0004cD-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 18:43:23 -0500 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 1B6I0s-0004Y7-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 18:42:22 -0500 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i2ONfU0283324; Wed, 24 Mar 2004 17:41:30 -0600 Message-Id: <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 24 Mar 2004 17:41:22 -0600 To: shep@shepfarm.com From: Bill Nickless Subject: Re: mboned: BGMP & DVMRP status Q. Cc: , In-Reply-To: References: <4061E3E2.30001@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 03:53 PM 3/24/2004 -0800, shep@shepfarm.com wrote: >The scaling issue I'm facing involves me, and my ability to gain console >access to every router on earth in order to enable PIM. Until that is >solved, or the need for me to do it myself is eliminated, then I'd love >to help tackle the scaling issues we encounter. > >Greg My scaling issue is getting the money to replace every IEEE 802.1 bridge on earth with one that can do IGMPv3 snooping properly. Oh yeah, MLDv2 too. And scheduling downtime to do the necessary forklift upgrades. When I write "every" I'm quite sure it's well in excess of 99%. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP: 021D EB98 03B3 2E83 3D71 0397 251D 819A D0BE EA32 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQGIcqSUdgZrQvuoyEQKq4gCfS47gIiDrySYYoBQjf8RqDTkmH4QAn148 jHxcX1lrXsfLcl7ud0bEO2YU =OOwn -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 24 20:24:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04856 for ; Wed, 24 Mar 2004 20:24:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6JbE-00071n-HJ; Wed, 24 Mar 2004 20:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Jap-00070m-Ek for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 20:23:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04780 for ; Wed, 24 Mar 2004 20:23:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Jan-0003aM-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 20:23:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6JZn-0003Uw-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 20:22:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B6JYs-0003OM-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 20:21:34 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2004 17:21:06 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2P1L2BB011421; Wed, 24 Mar 2004 17:21:02 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA16305; Wed, 24 Mar 2004 17:21:02 -0800 (PST) Date: Wed, 24 Mar 2004 17:21:01 -0800 From: Toerless Eckert To: Bill Nickless Cc: shep@shepfarm.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040325012101.GC17887@cisco.com> References: <4061E3E2.30001@necom830.hpcl.titech.ac.jp> <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, Mar 24, 2004 at 05:41:22PM -0600, Bill Nickless wrote: > My scaling issue is getting the money to replace every IEEE 802.1 bridge on > earth with one that can do IGMPv3 snooping properly. Oh yeah, MLDv2 > too. And scheduling downtime to do the necessary forklift upgrades. > > When I write "every" I'm quite sure it's well in excess of 99%. The other option of course is always to forget snooping, disable it and be happy. With the typical size of broadcast domains (getting smaller), attachment speed (getting faster, 100Mbps standard) as well as processing speed of the hosts themselves (> 1Gbps PCs) and relative speed of the possible aggregate of multicast traffic to be received (< 10 Mbps at best in typical enterprises), this rather is getting less than more of a problem - within an enterprise environment with i'd hope overwhelmingly friendly user population (recipe doesn't work for public access or universities or the like). On the other hand: If you do have that many switches and are able to act like a single determined buyer for all of them, then it should be no problem to get exactly the feature you want from a vendor. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 24 20:24:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04859 for ; Wed, 24 Mar 2004 20:24:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6JbS-00073e-N2 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 20:24:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P1OEf2027124 for routing-discussion-archive@odin.ietf.org; Wed, 24 Mar 2004 20:24:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6JbE-00071n-HJ; Wed, 24 Mar 2004 20:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Jap-00070m-Ek for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 20:23:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04780 for ; Wed, 24 Mar 2004 20:23:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Jan-0003aM-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 20:23:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6JZn-0003Uw-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 20:22:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B6JYs-0003OM-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 20:21:34 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2004 17:21:06 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i2P1L2BB011421; Wed, 24 Mar 2004 17:21:02 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA16305; Wed, 24 Mar 2004 17:21:02 -0800 (PST) Date: Wed, 24 Mar 2004 17:21:01 -0800 From: Toerless Eckert To: Bill Nickless Cc: shep@shepfarm.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040325012101.GC17887@cisco.com> References: <4061E3E2.30001@necom830.hpcl.titech.ac.jp> <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, Mar 24, 2004 at 05:41:22PM -0600, Bill Nickless wrote: > My scaling issue is getting the money to replace every IEEE 802.1 bridge on > earth with one that can do IGMPv3 snooping properly. Oh yeah, MLDv2 > too. And scheduling downtime to do the necessary forklift upgrades. > > When I write "every" I'm quite sure it's well in excess of 99%. The other option of course is always to forget snooping, disable it and be happy. With the typical size of broadcast domains (getting smaller), attachment speed (getting faster, 100Mbps standard) as well as processing speed of the hosts themselves (> 1Gbps PCs) and relative speed of the possible aggregate of multicast traffic to be received (< 10 Mbps at best in typical enterprises), this rather is getting less than more of a problem - within an enterprise environment with i'd hope overwhelmingly friendly user population (recipe doesn't work for public access or universities or the like). On the other hand: If you do have that many switches and are able to act like a single determined buyer for all of them, then it should be no problem to get exactly the feature you want from a vendor. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 25 10:49:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01997 for ; Thu, 25 Mar 2004 10:49:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X5Q-0003C4-Ko; Thu, 25 Mar 2004 10:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X4h-000346-7g for routing-discussion@optimus.ietf.org; Thu, 25 Mar 2004 10:47:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01857 for ; Thu, 25 Mar 2004 10:47:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6X4e-0001cs-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:47:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6X3q-0001XF-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:46:27 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B6X35-0001N6-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:45:39 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i2PFj0l43089; Thu, 25 Mar 2004 07:45:00 -0800 (PST) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2PFitJ09492; Thu, 25 Mar 2004 07:44:55 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200403251544.i2PFitJ09492@merlot.juniper.net> To: Bill Nickless cc: shep@shepfarm.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu, pusateri@juniper.net Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message from Bill Nickless of "Wed, 24 Mar 2004 17:41:22 CST." <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33685.1080229494.1@juniper.net> Date: Thu, 25 Mar 2004 07:44:55 -0800 From: Tom Pusateri X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , In message <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> you write: > >At 03:53 PM 3/24/2004 -0800, shep@shepfarm.com wrote: > >>The scaling issue I'm facing involves me, and my ability to gain console >>access to every router on earth in order to enable PIM. Until that is >>solved, or the need for me to do it myself is eliminated, then I'd love >>to help tackle the scaling issues we encounter. >> >>Greg > >My scaling issue is getting the money to replace every IEEE 802.1 bridge on >earth with one that can do IGMPv3 snooping properly. Oh yeah, MLDv2 >too. And scheduling downtime to do the necessary forklift upgrades. > >When I write "every" I'm quite sure it's well in excess of 99%. I was thinking that AMT might suit this purpose nicely. Even if you have multicast connectivity but you don't have IGMPv3, you can deploy a relay to get around those old switches until they can be replaced. http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-02.txt Tom _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Mar 25 10:49:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02007 for ; Thu, 25 Mar 2004 10:49:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X63-0003Jk-Gs for routing-discussion-archive@odin.ietf.org; Thu, 25 Mar 2004 10:48:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PFmhUU012750 for routing-discussion-archive@odin.ietf.org; Thu, 25 Mar 2004 10:48:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X5Q-0003C4-Ko; Thu, 25 Mar 2004 10:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6X4h-000346-7g for routing-discussion@optimus.ietf.org; Thu, 25 Mar 2004 10:47:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01857 for ; Thu, 25 Mar 2004 10:47:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6X4e-0001cs-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:47:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6X3q-0001XF-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:46:27 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1B6X35-0001N6-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:45:39 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i2PFj0l43089; Thu, 25 Mar 2004 07:45:00 -0800 (PST) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2PFitJ09492; Thu, 25 Mar 2004 07:44:55 -0800 (PST) (envelope-from pusateri@juniper.net) Message-Id: <200403251544.i2PFitJ09492@merlot.juniper.net> To: Bill Nickless cc: shep@shepfarm.com, routing-discussion@ietf.org, mboned@lists.uoregon.edu, pusateri@juniper.net Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message from Bill Nickless of "Wed, 24 Mar 2004 17:41:22 CST." <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33685.1080229494.1@juniper.net> Date: Thu, 25 Mar 2004 07:44:55 -0800 From: Tom Pusateri X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , In message <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> you write: > >At 03:53 PM 3/24/2004 -0800, shep@shepfarm.com wrote: > >>The scaling issue I'm facing involves me, and my ability to gain console >>access to every router on earth in order to enable PIM. Until that is >>solved, or the need for me to do it myself is eliminated, then I'd love >>to help tackle the scaling issues we encounter. >> >>Greg > >My scaling issue is getting the money to replace every IEEE 802.1 bridge on >earth with one that can do IGMPv3 snooping properly. Oh yeah, MLDv2 >too. And scheduling downtime to do the necessary forklift upgrades. > >When I write "every" I'm quite sure it's well in excess of 99%. I was thinking that AMT might suit this purpose nicely. Even if you have multicast connectivity but you don't have IGMPv3, you can deploy a relay to get around those old switches until they can be replaced. http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-02.txt Tom _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Mar 25 10:59:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02776 for ; Thu, 25 Mar 2004 10:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XG4-000588-Jb for routing-discussion-archive@odin.ietf.org; Thu, 25 Mar 2004 10:59:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PFx4dI019718 for routing-discussion-archive@odin.ietf.org; Thu, 25 Mar 2004 10:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XG0-00057E-Jh; Thu, 25 Mar 2004 10:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XF4-00056a-DU for routing-discussion@optimus.ietf.org; Thu, 25 Mar 2004 10:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02719 for ; Thu, 25 Mar 2004 10:57:58 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XF1-0002H0-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:58:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XE8-0002Fo-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:57:05 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[EyWQvOZX7NLwP00JrPGYxTsGp9qXxPcE]) by ietf-mx with esmtp (Exim 4.12) id 1B6XDh-0002E5-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:56:37 -0500 Received: from shepfarm.com (IDENT:2acaBIk+qyjCul3MhDxA6dsovcaRVDWA@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2PHbpTk012415; Thu, 25 Mar 2004 09:37:51 -0800 Date: Thu, 25 Mar 2004 09:37:51 -0800 (PST) To: Tom Pusateri cc: Bill Nickless , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403251544.i2PFitJ09492@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Thu, 25 Mar 2004, Tom Pusateri wrote: > In message <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> you write: > > > >At 03:53 PM 3/24/2004 -0800, shep@shepfarm.com wrote: > > > >>The scaling issue I'm facing involves me, and my ability to gain console > >>access to every router on earth in order to enable PIM. Until that is > >>solved, or the need for me to do it myself is eliminated, then I'd love > >>to help tackle the scaling issues we encounter. > >> > >>Greg > > > >My scaling issue is getting the money to replace every IEEE 802.1 bridge on > >earth with one that can do IGMPv3 snooping properly. Oh yeah, MLDv2 > >too. And scheduling downtime to do the necessary forklift upgrades. > > > >When I write "every" I'm quite sure it's well in excess of 99%. > > I was thinking that AMT might suit this purpose nicely. Even if you > have multicast connectivity but you don't have IGMPv3, you can deploy > a relay to get around those old switches until they can be replaced. > > http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-02.txt > > Tom Thanks Tom!! I was just about to write the same thing :) Additionally, AMT will also solve my need to enable PIM on every router. =D The gap I see in the current AMT spec involves the anycast solution for mcast/ucast boundary detection. I feel this solution is too crippling in that it only addresses last-mile unicast networks but does not allow for the bridging of mcast islands over ucast oceans - for mcast enabled enterprises, and certain mcast-challanged IXs. It also may make load-balancing too complex/difficult/challanging/ugly.. dunno - pick one. Greg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 25 11:48:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02777 for ; Thu, 25 Mar 2004 10:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XG0-00057E-Jh; Thu, 25 Mar 2004 10:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XF4-00056a-DU for routing-discussion@optimus.ietf.org; Thu, 25 Mar 2004 10:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02719 for ; Thu, 25 Mar 2004 10:57:58 -0500 (EST) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XF1-0002H0-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:58:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XE8-0002Fo-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:57:05 -0500 Received: from shepfarm.com ([198.58.3.10] ident=[EyWQvOZX7NLwP00JrPGYxTsGp9qXxPcE]) by ietf-mx with esmtp (Exim 4.12) id 1B6XDh-0002E5-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 10:56:37 -0500 Received: from shepfarm.com (IDENT:2acaBIk+qyjCul3MhDxA6dsovcaRVDWA@shepfarm.com [198.58.3.10]) by shepfarm.com (8.12.10/8.11.3) with ESMTP id i2PHbpTk012415; Thu, 25 Mar 2004 09:37:51 -0800 Date: Thu, 25 Mar 2004 09:37:51 -0800 (PST) To: Tom Pusateri cc: Bill Nickless , , Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: <200403251544.i2PFitJ09492@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Thu, 25 Mar 2004, Tom Pusateri wrote: > In message <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> you write: > > > >At 03:53 PM 3/24/2004 -0800, shep@shepfarm.com wrote: > > > >>The scaling issue I'm facing involves me, and my ability to gain console > >>access to every router on earth in order to enable PIM. Until that is > >>solved, or the need for me to do it myself is eliminated, then I'd love > >>to help tackle the scaling issues we encounter. > >> > >>Greg > > > >My scaling issue is getting the money to replace every IEEE 802.1 bridge on > >earth with one that can do IGMPv3 snooping properly. Oh yeah, MLDv2 > >too. And scheduling downtime to do the necessary forklift upgrades. > > > >When I write "every" I'm quite sure it's well in excess of 99%. > > I was thinking that AMT might suit this purpose nicely. Even if you > have multicast connectivity but you don't have IGMPv3, you can deploy > a relay to get around those old switches until they can be replaced. > > http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-02.txt > > Tom Thanks Tom!! I was just about to write the same thing :) Additionally, AMT will also solve my need to enable PIM on every router. =D The gap I see in the current AMT spec involves the anycast solution for mcast/ucast boundary detection. I feel this solution is too crippling in that it only addresses last-mile unicast networks but does not allow for the bridging of mcast islands over ucast oceans - for mcast enabled enterprises, and certain mcast-challanged IXs. It also may make load-balancing too complex/difficult/challanging/ugly.. dunno - pick one. Greg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 25 14:20:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14664 for ; Thu, 25 Mar 2004 14:20:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aO5-0004Fq-V9; Thu, 25 Mar 2004 14:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aMA-00043t-Nc for routing-discussion@optimus.ietf.org; Thu, 25 Mar 2004 14:17:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14539 for ; Thu, 25 Mar 2004 14:17:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aM8-0001L7-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 14:17:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aLJ-0001I7-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 14:16:41 -0500 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 1B6aKS-00019l-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 14:15:49 -0500 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i2PJFH0274080; Thu, 25 Mar 2004 13:15:17 -0600 Message-Id: <5.2.0.9.2.20040325125630.03fc7098@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 25 Mar 2004 13:13:06 -0600 To: Tom Pusateri From: Bill Nickless Subject: Re: mboned: BGMP & DVMRP status Q. Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu In-Reply-To: <200403251544.i2PFitJ09492@merlot.juniper.net> References: <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 07:44 AM 3/25/2004 -0800, Tom Pusateri wrote: >I was thinking that AMT might suit this purpose nicely. Even if you >have multicast connectivity but you don't have IGMPv3, you can deploy >a relay to get around those old switches until they can be replaced. > >http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-02.txt AMT is close to what I discussed earlier in this thread. However, AMT (as I read in the referenced draft) requires host support *and* explicit network support for deployment. AMT also requires the allocation and management of (an) AMT Subnet Prefix and AMT Unicast AS ID(s). The system I outlined earlier in this thread only requires host support to operate correctly, which means deployment can be driven directly by interested applications. Later, after a critical mass of deployment exists, it's possible to extend the underlying network to do more efficient replication. But again, this network capability is not required for correct operation by early adopters. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP: 021D EB98 03B3 2E83 3D71 0397 251D 819A D0BE EA32 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQGMvwyUdgZrQvuoyEQLvnQCcCgbks5/Ulai6zaYR7BU8pTpeCE4AoIwr OyETnmVpIxDcWOxwmLqyvLze =41PY -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Mar 25 14:20:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14667 for ; Thu, 25 Mar 2004 14:20:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aOO-0004Gx-EW for routing-discussion-archive@odin.ietf.org; Thu, 25 Mar 2004 14:19:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PJJq3N016423 for routing-discussion-archive@odin.ietf.org; Thu, 25 Mar 2004 14:19:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aO5-0004Fq-V9; Thu, 25 Mar 2004 14:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6aMA-00043t-Nc for routing-discussion@optimus.ietf.org; Thu, 25 Mar 2004 14:17:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14539 for ; Thu, 25 Mar 2004 14:17:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6aM8-0001L7-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 14:17:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6aLJ-0001I7-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 14:16:41 -0500 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 1B6aKS-00019l-00 for routing-discussion@ietf.org; Thu, 25 Mar 2004 14:15:49 -0500 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i2PJFH0274080; Thu, 25 Mar 2004 13:15:17 -0600 Message-Id: <5.2.0.9.2.20040325125630.03fc7098@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 25 Mar 2004 13:13:06 -0600 To: Tom Pusateri From: Bill Nickless Subject: Re: mboned: BGMP & DVMRP status Q. Cc: routing-discussion@ietf.org, mboned@lists.uoregon.edu In-Reply-To: <200403251544.i2PFitJ09492@merlot.juniper.net> References: <5.2.0.9.2.20040324173833.045f5de0@pop.mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 07:44 AM 3/25/2004 -0800, Tom Pusateri wrote: >I was thinking that AMT might suit this purpose nicely. Even if you >have multicast connectivity but you don't have IGMPv3, you can deploy >a relay to get around those old switches until they can be replaced. > >http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-02.txt AMT is close to what I discussed earlier in this thread. However, AMT (as I read in the referenced draft) requires host support *and* explicit network support for deployment. AMT also requires the allocation and management of (an) AMT Subnet Prefix and AMT Unicast AS ID(s). The system I outlined earlier in this thread only requires host support to operate correctly, which means deployment can be driven directly by interested applications. Later, after a critical mass of deployment exists, it's possible to extend the underlying network to do more efficient replication. But again, this network capability is not required for correct operation by early adopters. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP: 021D EB98 03B3 2E83 3D71 0397 251D 819A D0BE EA32 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQGMvwyUdgZrQvuoyEQLvnQCcCgbks5/Ulai6zaYR7BU8pTpeCE4AoIwr OyETnmVpIxDcWOxwmLqyvLze =41PY -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 26 11:58:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01343 for ; Fri, 26 Mar 2004 11:58:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6uee-0000Uc-PF; Fri, 26 Mar 2004 11:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6udp-0000T0-7V for routing-discussion@optimus.ietf.org; Fri, 26 Mar 2004 11:57:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01296 for ; Fri, 26 Mar 2004 11:57:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6udn-000336-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 11:57:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ucu-00031A-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 11:56:14 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6ucd-0002yS-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 11:55:55 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2QGtD0Y044808; Fri, 26 Mar 2004 11:55:13 -0500 Received: from d03nm690.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2QGtB75067808; Fri, 26 Mar 2004 09:55:11 -0700 In-Reply-To: Importance: Normal Subject: Re: mboned: BGMP & DVMRP status Q. To: shep@shepfarm.com Cc: IMAI Yuji , , , , , , , , X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Rick Boivie Date: Fri, 26 Mar 2004 11:55:11 -0500 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 03/26/2004 09:55:12 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE4F0DFC2CE278f9e8a93df938690918c0ABBE4F0DFC2CE27" Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --0__=0ABBE4F0DFC2CE278f9e8a93df938690918c0ABBE4F0DFC2CE27 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Greg wrote: >..and what percentage of them have mcast enabled? Even better, what >percentage of them have mcast enabled to the mcast-anabled Internet an= d >not just a walled-garden deployment? I'd say less than 1%. And that probably won't change anytime soon since: - the route protocol traffic would be huge if millions or 10's of mill= ions of people started using multicast for videoconferencing, say - the bandwidth used for the data could be huge if large numbers of pe= ople started using multicast for large conferences So if we want to support large numbers of videoconferences say, it seem= s we need a scheme that - has minimal (or zero) route protocol traffic - limits the amount of bandwidth a given user can use e.g. enough to s= end to 10 or 20 (or x?) destinations, say. And in those rare occasions = when somebody needs to send to a very larger number of destinations, they= can reserve a "broadcast channel" using traditional multicast schemes an= d perhaps pay for that (?) has Ohta has suggested. I might also add that xcast seems to be exactly the right approach for supporting large numbers of videoconferences since - there's zero route protocol traffic - xcast (as currently constituted) limits the amount of bandwidth a gi= ven user can use So xcast can eliminate the problems that to this point have held back t= he broad adoption of multicast and videoconferencing. Rick shep@shepfarm.com on 03/24/2004 04:10:53 PM To: Rick Boivie/Hawthorne/IBM@IBMUS cc: IMAI Yuji , , , , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. On Wed, 24 Mar 2004, Rick Boivie wrote: > Greg said: > >I'd love to have those problems!!! ;-) ..but for now, we don't even = have a > >good live example due to the lack of last-mile deployment. > > There seems to be plenty of last mile broadband deployed. Note > that Nielsen/NetRatings says that 49.5 million or 38% of home Interne= t > users in the US connect via broadband. > http://www.nielsen-netratings.com/pr/pr_040108_us.pdf > > The % of homes with broadband is even higher in some other countries = of > course. > > So lack of last mile deployment doesn't seem to be the issue. Rather= > the problem seems to be that multicast doesn't provide very good supp= ort > for large numbers of small groups -- as the IAB said in RFC 2902. > > My 2 cents. ..and what percentage of them have mcast enabled? Even better, what percentage of them have mcast enabled to the mcast-anabled Internet and= not just a walled-garden deployment? I'd say less than 1%. Greg > Rick > > > > > shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM > > Sent by: routing-discussion-admin@ietf.org > > > To: Rick Boivie/Hawthorne/IBM@IBMUS > cc: IMAI Yuji , , > , , > , , > , , > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > On Wed, 24 Mar 2004, Rick Boivie wrote: > > As the Internet Architecture Board said (in RFC 2902) "providing fo= r many > > groups > > of small conferences ... scales badly given the current multicast model". > > > > So if we want tapplications like the above to work when there is limited > > bandwidth > > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > > multicast scheme that > > can support very large or unlimited numbers of small groups. > > > > Rick Boivie > > IBM T. J. Watson Research Center > > rhboivie@us.ibm.com > > Rick, > > I'd love to have those problems!!! ;-) ..but for now, we don't even h= ave a > good live example due to the lack of last-mile deployment. > > Yes, I'd love to improve on the scaling of our current mcast solution= s, > but until the deployment warrents it, let's focus on solving the > deployment barriers. Then when the availablity of mcast begins attrac= ting > apps and users we can gather imperical data as to what about the curr= ent > scheme does and does not scale. > > As an example, please recall NetAid. This WAS a successful large audi= ence > mcast event which exposed the scaling limits in RTCP - which was solveable > at the application layer. Until we have other similar examples exposi= ng > other limitations, I feel we are just shooting in the air. > > Greg > > > > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 = PM > > > > Sent by: routing-discussion-admin@ietf.org > > > > > > To: dino@procket.com > > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, > > routing-discussion@ietf.org, mboned@lists.uoregon.edu, > > zinin@psg.com, fenner@research.att.com > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > > > Dino, > > > > > Does any protocol then scale if I decide that my table size n= eeds > to > > be > > > 5,000,000 routes? > > > > Could you tell us why you consider 5,000 is enough and > > 5,000,000 is too much for the Internet, please? > > > > Reading your mail, you may feel 5,000,000 routes is ridiculous > > requirement. I agree with you if we can limit to use > > multicast only for alternative usage of current broadcasting > > media like TV and radio. 5,000 will be enough because almost > > channel flows from the anchor desks in N.Y., L.A. or Atlanta > > spread over world wide Internet. Since such flow of popular > > programs are always received by many ISPs, each routing entry > > may be very stable and you may be able to assign multicast > > addresses to aggregate neatly. > > > > However, once we want the application like instant message > > systems with vic & rat, situation change drastically. In other > > words, why don't you want to provide Access Grid service for > > the consumer market? Members of a virtual venue are sparsely > > distributed over the Internet subscribing different > > ASes. Using SSM or PIM-SM in short cut mode, number of routing > > entry become as same as number of transmitters. That means routes= > > grows up to millions very easily. > > > > To make matter worse, curious customers rapidly loiter from > > venue to venue, joining and pruning (S,G). Whenever they zap > > the channel, PIM-SSM signaling travels from receiver to most > > nearest branching router marking or erasing routing entries. > > > > That's why I want you to scale your routers up to millions > > multicast routes. If you will not, neither we will be support > > instant video message on the multicast. > > > > Again. > > > > Please, could you tell us why you consider 5,000 is enough and > > 5,000,000 is too much for the Internet, Dino? > > ---- > > Yuji > > > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion = --0__=0ABBE4F0DFC2CE278f9e8a93df938690918c0ABBE4F0DFC2CE27 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Greg wrote:
>..and what percentage of them have mcast enabled? Even better, = what
>percentage of them have mcast enabled to the mcast-anabled Internet= and
>not just a walled-garden deployment? I'd say less than 1%.
=
And that probably won't change anytime soon since:
-  the route protocol traffic would be huge if millions or 10'= s of millions
  of people started using multicast for videoconferencing, sa= y
-  the bandwidth used for the data could be huge if large numb= ers of people started
  using multicast for large conferences

So if we want to support large numbers of videoconferences say, it = seems we
need a scheme that
-  has minimal (or zero) route protocol traffic
-  limits the amount of bandwidth a given user can use e.g. en= ough to send
  to 10 or 20 (or x?) destinations, say.  And in those r= are occasions when
  somebody needs to send to a very larger number of destinati= ons, they can
  reserve a "broadcast channel" using traditional m= ulticast schemes and perhaps
  pay for that (?) has Ohta has suggested.

I might also add that xcast seems to be exactly the right approach = for supporting
large numbers of videoconferences since
-  there's zero route protocol traffic
-  xcast (as currently constituted) limits the amount of bandw= idth a given user
  can use

So xcast can eliminate the problems that to this point have held ba= ck the
broad adoption of multicast and videoconferencing.

Rick

 


To: Rick = Boivie/Hawthorne/IBM@IBMUS
cc: IMAI Yuj= i <kimai@labs.fujitsu.com>, <dino@procket.com>, <mohta@n= ecom830.hpcl.titech.ac.jp>, <eckert@cisco.com>, <dmm@1-4-5.= net>, <routing-discussion@ietf.org>, <mboned@lists.uoregon.= edu>, <zinin@psg.com>, <fenner@research.att.com><= font size=3D"2" color=3D"#800080">
Subject: Re:= mboned: BGMP & DVMRP status Q.



On Wed, 24 Mar 2004, Rick Boivie wrote:

> Greg said:
> >I'd love to have those problems!!! ;-) ..but for now, we don't= even have a
> >good live example due to the lack of last-mile deployment.
= >
> There seems to be plenty of last mile broadband deployed.  No= te
> that Nielsen/NetRatings says that 49.5 million or 38% of home Inte= rnet
> users in the US connect via broadband.
> http://www.nielsen-netratings.com/pr/pr_040108_us.pdf=
>
> The % of homes with broadband is even higher in some other countri= es of
> course.
>
> So lack of last mile deployment doesn't seem to be the issue. &nbs= p;Rather
> the problem seems to be that multicast doesn't provide very good s= upport
> for large numbers of small groups  --  as the IAB said i= n RFC 2902.
>
> My 2 cents.

..and what percentage of them have mcast enabled? Even better, what=
percentage of them have mcast enabled to the mcast-anabled Internet and=
not just a walled-garden deployment? I'd say less than 1%.

Greg

> Rick
>
>
>
>
> shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM
>
> Sent by:    routing-discussion-admin@ietf.org
>
>
> To:    Rick Boivie/Hawthorne/IBM@IBMUS
> cc:    IMAI Yuji <kimai@labs.fujitsu.com>, <din= o@procket.com>,
>        <mohta@necom830.hpcl.titech.ac.jp>= ;, <eckert@cisco.com>,
>        <dmm@1-4-5.net>, <routing-disc= ussion@ietf.org>,
>        <mboned@lists.uoregon.edu>, <z= inin@psg.com>,
>        <fenner@research.att.com>
> Subject:    Re: mboned: BGMP & DVMRP status Q.
>
>
>
>
>
> On Wed, 24 Mar 2004, Rick Boivie wrote:
> > As the Internet Architecture Board said (in RFC 2902) "p= roviding for many
> > groups
> > of small conferences ... scales badly given the current multi= cast model".
> >
> > So if we want tapplications like the above to work when there= is limited
> > bandwidth
> > in the first mile (e.g. DSL, cable modem, wireless etc.) we n= eed a
> > multicast scheme that
> > can support very large or unlimited numbers of small groups.<= br> > >
> > Rick Boivie
> > IBM T. J. Watson Research Center
> > rhboivie@us.ibm.com
>
> Rick,
>
> I'd love to have those problems!!! ;-) ..but for now, we don't eve= n have a
> good live example due to the lack of last-mile deployment.
>
> Yes, I'd love to improve on the scaling of our current mcast solut= ions,
> but until the deployment warrents it, let's focus on solving the > deployment barriers. Then when the availablity of mcast begins att= racting
> apps and users we can gather imperical data as to what about the c= urrent
> scheme does and does not scale.
>
> As an example, please recall NetAid. This WAS a successful large a= udience
> mcast event which exposed the scaling limits in RTCP - which was s= olveable
> at the application layer. Until we have other similar examples exp= osing
> other limitations, I feel we are just shooting in the air.
>
> Greg
>
> >
> > IMAI Yuji <kimai@labs.fujitsu.com>@ietf.org on 03/23/20= 04 11:29:57 PM
> >
> > Sent by:    routing-discussion-admin@ietf.org
> >
> >
> > To:    dino@procket.com
> > cc:    mohta@necom830.hpcl.titech.ac.jp, eckert@cis= co.com, dmm@1-4-5.net,
> >        routing-discussion@ietf.org, mbone= d@lists.uoregon.edu,
> >        zinin@psg.com, fenner@research.att= .com
> > Subject:    Re: mboned: BGMP & DVMRP status Q.<= br> > >
> >
> >
> > Dino,
> >
> > >     Does any protocol then scale if I decide t= hat my table size needs
> to
> > be
> > >     5,000,000 routes?
> >
> >   Could you tell us why you consider 5,000 is enough and=
> >   5,000,000 is too much for the Internet, please?
> >
> >   Reading your mail, you may feel 5,000,000 routes is ri= diculous
> >   requirement. I agree with you if we can limit to use > >   multicast only for alternative usage of current broadc= asting
> >   media like TV and radio. 5,000 will be enough because = almost
> >   channel flows from the anchor desks in N.Y., L.A. or A= tlanta
> >   spread over world wide Internet. Since such flow of po= pular
> >   programs are always received by many ISPs, each routin= g entry
> >   may be very stable and you may be able to assign multi= cast
> >   addresses to aggregate neatly.
> >
> >   However, once we want the application like instant mes= sage
> >   systems with vic & rat, situation change drastical= ly. In other
> >   words, why don't you want to provide Access Grid servi= ce for
> >   the consumer market? Members of a virtual venue are sp= arsely
> >   distributed over the Internet subscribing different > >   ASes. Using SSM or PIM-SM in short cut mode, number of= routing
> >   entry become as same as number of transmitters. That m= eans routes
> >   grows up to millions very easily.
> >
> >   To make matter worse, curious customers rapidly loiter= from
> >   venue to venue, joining and pruning (S,G). Whenever th= ey zap
> >   the channel, PIM-SSM signaling travels from receiver t= o most
> >   nearest branching router marking or erasing routing en= tries.
> >
> >   That's why I want you to scale your routers up to mill= ions
> >   multicast routes. If you will not, neither we will be = support
> >   instant video message on the multicast.
> >
> >   Again.
> >
> >   Please, could you tell us why you consider 5,000 is en= ough and
> >   5,000,000 is too much for the Internet, Dino?
> > ----
> > Yuji
> >
> > _______________________________________________
> > routing-discussion mailing list
> > routing-discussion@ietf.org
> >  https://www1.ietf.org/mailman/listinfo/routing-= discussion
>
>
> _______________________________________________
> routing-discussion mailing list
> routing-discussion@ietf.org
>  https://www1.ietf.org/mailman/listinfo/routing-discu= ssion

= --0__=0ABBE4F0DFC2CE278f9e8a93df938690918c0ABBE4F0DFC2CE27-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Mar 26 11:58:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01376 for ; Fri, 26 Mar 2004 11:58:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6uey-0000Vw-JS for routing-discussion-archive@odin.ietf.org; Fri, 26 Mar 2004 11:58:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QGwKWf001975 for routing-discussion-archive@odin.ietf.org; Fri, 26 Mar 2004 11:58:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6uee-0000Uc-PF; Fri, 26 Mar 2004 11:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6udp-0000T0-7V for routing-discussion@optimus.ietf.org; Fri, 26 Mar 2004 11:57:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01296 for ; Fri, 26 Mar 2004 11:57:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6udn-000336-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 11:57:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ucu-00031A-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 11:56:14 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1B6ucd-0002yS-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 11:55:55 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2QGtD0Y044808; Fri, 26 Mar 2004 11:55:13 -0500 Received: from d03nm690.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2QGtB75067808; Fri, 26 Mar 2004 09:55:11 -0700 In-Reply-To: Importance: Normal Subject: Re: mboned: BGMP & DVMRP status Q. To: shep@shepfarm.com Cc: IMAI Yuji , , , , , , , , X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Rick Boivie Date: Fri, 26 Mar 2004 11:55:11 -0500 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 03/26/2004 09:55:12 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE4F0DFC2CE278f9e8a93df938690918c0ABBE4F0DFC2CE27" Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --0__=0ABBE4F0DFC2CE278f9e8a93df938690918c0ABBE4F0DFC2CE27 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Greg wrote: >..and what percentage of them have mcast enabled? Even better, what >percentage of them have mcast enabled to the mcast-anabled Internet an= d >not just a walled-garden deployment? I'd say less than 1%. And that probably won't change anytime soon since: - the route protocol traffic would be huge if millions or 10's of mill= ions of people started using multicast for videoconferencing, say - the bandwidth used for the data could be huge if large numbers of pe= ople started using multicast for large conferences So if we want to support large numbers of videoconferences say, it seem= s we need a scheme that - has minimal (or zero) route protocol traffic - limits the amount of bandwidth a given user can use e.g. enough to s= end to 10 or 20 (or x?) destinations, say. And in those rare occasions = when somebody needs to send to a very larger number of destinations, they= can reserve a "broadcast channel" using traditional multicast schemes an= d perhaps pay for that (?) has Ohta has suggested. I might also add that xcast seems to be exactly the right approach for supporting large numbers of videoconferences since - there's zero route protocol traffic - xcast (as currently constituted) limits the amount of bandwidth a gi= ven user can use So xcast can eliminate the problems that to this point have held back t= he broad adoption of multicast and videoconferencing. Rick shep@shepfarm.com on 03/24/2004 04:10:53 PM To: Rick Boivie/Hawthorne/IBM@IBMUS cc: IMAI Yuji , , , , , , , , Subject: Re: mboned: BGMP & DVMRP status Q. On Wed, 24 Mar 2004, Rick Boivie wrote: > Greg said: > >I'd love to have those problems!!! ;-) ..but for now, we don't even = have a > >good live example due to the lack of last-mile deployment. > > There seems to be plenty of last mile broadband deployed. Note > that Nielsen/NetRatings says that 49.5 million or 38% of home Interne= t > users in the US connect via broadband. > http://www.nielsen-netratings.com/pr/pr_040108_us.pdf > > The % of homes with broadband is even higher in some other countries = of > course. > > So lack of last mile deployment doesn't seem to be the issue. Rather= > the problem seems to be that multicast doesn't provide very good supp= ort > for large numbers of small groups -- as the IAB said in RFC 2902. > > My 2 cents. ..and what percentage of them have mcast enabled? Even better, what percentage of them have mcast enabled to the mcast-anabled Internet and= not just a walled-garden deployment? I'd say less than 1%. Greg > Rick > > > > > shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM > > Sent by: routing-discussion-admin@ietf.org > > > To: Rick Boivie/Hawthorne/IBM@IBMUS > cc: IMAI Yuji , , > , , > , , > , , > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > On Wed, 24 Mar 2004, Rick Boivie wrote: > > As the Internet Architecture Board said (in RFC 2902) "providing fo= r many > > groups > > of small conferences ... scales badly given the current multicast model". > > > > So if we want tapplications like the above to work when there is limited > > bandwidth > > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > > multicast scheme that > > can support very large or unlimited numbers of small groups. > > > > Rick Boivie > > IBM T. J. Watson Research Center > > rhboivie@us.ibm.com > > Rick, > > I'd love to have those problems!!! ;-) ..but for now, we don't even h= ave a > good live example due to the lack of last-mile deployment. > > Yes, I'd love to improve on the scaling of our current mcast solution= s, > but until the deployment warrents it, let's focus on solving the > deployment barriers. Then when the availablity of mcast begins attrac= ting > apps and users we can gather imperical data as to what about the curr= ent > scheme does and does not scale. > > As an example, please recall NetAid. This WAS a successful large audi= ence > mcast event which exposed the scaling limits in RTCP - which was solveable > at the application layer. Until we have other similar examples exposi= ng > other limitations, I feel we are just shooting in the air. > > Greg > > > > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 = PM > > > > Sent by: routing-discussion-admin@ietf.org > > > > > > To: dino@procket.com > > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, dmm@1-4-5.net, > > routing-discussion@ietf.org, mboned@lists.uoregon.edu, > > zinin@psg.com, fenner@research.att.com > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > > > Dino, > > > > > Does any protocol then scale if I decide that my table size n= eeds > to > > be > > > 5,000,000 routes? > > > > Could you tell us why you consider 5,000 is enough and > > 5,000,000 is too much for the Internet, please? > > > > Reading your mail, you may feel 5,000,000 routes is ridiculous > > requirement. I agree with you if we can limit to use > > multicast only for alternative usage of current broadcasting > > media like TV and radio. 5,000 will be enough because almost > > channel flows from the anchor desks in N.Y., L.A. or Atlanta > > spread over world wide Internet. Since such flow of popular > > programs are always received by many ISPs, each routing entry > > may be very stable and you may be able to assign multicast > > addresses to aggregate neatly. > > > > However, once we want the application like instant message > > systems with vic & rat, situation change drastically. In other > > words, why don't you want to provide Access Grid service for > > the consumer market? Members of a virtual venue are sparsely > > distributed over the Internet subscribing different > > ASes. Using SSM or PIM-SM in short cut mode, number of routing > > entry become as same as number of transmitters. That means routes= > > grows up to millions very easily. > > > > To make matter worse, curious customers rapidly loiter from > > venue to venue, joining and pruning (S,G). Whenever they zap > > the channel, PIM-SSM signaling travels from receiver to most > > nearest branching router marking or erasing routing entries. > > > > That's why I want you to scale your routers up to millions > > multicast routes. If you will not, neither we will be support > > instant video message on the multicast. > > > > Again. > > > > Please, could you tell us why you consider 5,000 is enough and > > 5,000,000 is too much for the Internet, Dino? > > ---- > > Yuji > > > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion = --0__=0ABBE4F0DFC2CE278f9e8a93df938690918c0ABBE4F0DFC2CE27 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Greg wrote:
>..and what percentage of them have mcast enabled? Even better, = what
>percentage of them have mcast enabled to the mcast-anabled Internet= and
>not just a walled-garden deployment? I'd say less than 1%.
=
And that probably won't change anytime soon since:
-  the route protocol traffic would be huge if millions or 10'= s of millions
  of people started using multicast for videoconferencing, sa= y
-  the bandwidth used for the data could be huge if large numb= ers of people started
  using multicast for large conferences

So if we want to support large numbers of videoconferences say, it = seems we
need a scheme that
-  has minimal (or zero) route protocol traffic
-  limits the amount of bandwidth a given user can use e.g. en= ough to send
  to 10 or 20 (or x?) destinations, say.  And in those r= are occasions when
  somebody needs to send to a very larger number of destinati= ons, they can
  reserve a "broadcast channel" using traditional m= ulticast schemes and perhaps
  pay for that (?) has Ohta has suggested.

I might also add that xcast seems to be exactly the right approach = for supporting
large numbers of videoconferences since
-  there's zero route protocol traffic
-  xcast (as currently constituted) limits the amount of bandw= idth a given user
  can use

So xcast can eliminate the problems that to this point have held ba= ck the
broad adoption of multicast and videoconferencing.

Rick

 


To: Rick = Boivie/Hawthorne/IBM@IBMUS
cc: IMAI Yuj= i <kimai@labs.fujitsu.com>, <dino@procket.com>, <mohta@n= ecom830.hpcl.titech.ac.jp>, <eckert@cisco.com>, <dmm@1-4-5.= net>, <routing-discussion@ietf.org>, <mboned@lists.uoregon.= edu>, <zinin@psg.com>, <fenner@research.att.com><= font size=3D"2" color=3D"#800080">
Subject: Re:= mboned: BGMP & DVMRP status Q.



On Wed, 24 Mar 2004, Rick Boivie wrote:

> Greg said:
> >I'd love to have those problems!!! ;-) ..but for now, we don't= even have a
> >good live example due to the lack of last-mile deployment.
= >
> There seems to be plenty of last mile broadband deployed.  No= te
> that Nielsen/NetRatings says that 49.5 million or 38% of home Inte= rnet
> users in the US connect via broadband.
> http://www.nielsen-netratings.com/pr/pr_040108_us.pdf=
>
> The % of homes with broadband is even higher in some other countri= es of
> course.
>
> So lack of last mile deployment doesn't seem to be the issue. &nbs= p;Rather
> the problem seems to be that multicast doesn't provide very good s= upport
> for large numbers of small groups  --  as the IAB said i= n RFC 2902.
>
> My 2 cents.

..and what percentage of them have mcast enabled? Even better, what=
percentage of them have mcast enabled to the mcast-anabled Internet and=
not just a walled-garden deployment? I'd say less than 1%.

Greg

> Rick
>
>
>
>
> shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM
>
> Sent by:    routing-discussion-admin@ietf.org
>
>
> To:    Rick Boivie/Hawthorne/IBM@IBMUS
> cc:    IMAI Yuji <kimai@labs.fujitsu.com>, <din= o@procket.com>,
>        <mohta@necom830.hpcl.titech.ac.jp>= ;, <eckert@cisco.com>,
>        <dmm@1-4-5.net>, <routing-disc= ussion@ietf.org>,
>        <mboned@lists.uoregon.edu>, <z= inin@psg.com>,
>        <fenner@research.att.com>
> Subject:    Re: mboned: BGMP & DVMRP status Q.
>
>
>
>
>
> On Wed, 24 Mar 2004, Rick Boivie wrote:
> > As the Internet Architecture Board said (in RFC 2902) "p= roviding for many
> > groups
> > of small conferences ... scales badly given the current multi= cast model".
> >
> > So if we want tapplications like the above to work when there= is limited
> > bandwidth
> > in the first mile (e.g. DSL, cable modem, wireless etc.) we n= eed a
> > multicast scheme that
> > can support very large or unlimited numbers of small groups.<= br> > >
> > Rick Boivie
> > IBM T. J. Watson Research Center
> > rhboivie@us.ibm.com
>
> Rick,
>
> I'd love to have those problems!!! ;-) ..but for now, we don't eve= n have a
> good live example due to the lack of last-mile deployment.
>
> Yes, I'd love to improve on the scaling of our current mcast solut= ions,
> but until the deployment warrents it, let's focus on solving the > deployment barriers. Then when the availablity of mcast begins att= racting
> apps and users we can gather imperical data as to what about the c= urrent
> scheme does and does not scale.
>
> As an example, please recall NetAid. This WAS a successful large a= udience
> mcast event which exposed the scaling limits in RTCP - which was s= olveable
> at the application layer. Until we have other similar examples exp= osing
> other limitations, I feel we are just shooting in the air.
>
> Greg
>
> >
> > IMAI Yuji <kimai@labs.fujitsu.com>@ietf.org on 03/23/20= 04 11:29:57 PM
> >
> > Sent by:    routing-discussion-admin@ietf.org
> >
> >
> > To:    dino@procket.com
> > cc:    mohta@necom830.hpcl.titech.ac.jp, eckert@cis= co.com, dmm@1-4-5.net,
> >        routing-discussion@ietf.org, mbone= d@lists.uoregon.edu,
> >        zinin@psg.com, fenner@research.att= .com
> > Subject:    Re: mboned: BGMP & DVMRP status Q.<= br> > >
> >
> >
> > Dino,
> >
> > >     Does any protocol then scale if I decide t= hat my table size needs
> to
> > be
> > >     5,000,000 routes?
> >
> >   Could you tell us why you consider 5,000 is enough and=
> >   5,000,000 is too much for the Internet, please?
> >
> >   Reading your mail, you may feel 5,000,000 routes is ri= diculous
> >   requirement. I agree with you if we can limit to use > >   multicast only for alternative usage of current broadc= asting
> >   media like TV and radio. 5,000 will be enough because = almost
> >   channel flows from the anchor desks in N.Y., L.A. or A= tlanta
> >   spread over world wide Internet. Since such flow of po= pular
> >   programs are always received by many ISPs, each routin= g entry
> >   may be very stable and you may be able to assign multi= cast
> >   addresses to aggregate neatly.
> >
> >   However, once we want the application like instant mes= sage
> >   systems with vic & rat, situation change drastical= ly. In other
> >   words, why don't you want to provide Access Grid servi= ce for
> >   the consumer market? Members of a virtual venue are sp= arsely
> >   distributed over the Internet subscribing different > >   ASes. Using SSM or PIM-SM in short cut mode, number of= routing
> >   entry become as same as number of transmitters. That m= eans routes
> >   grows up to millions very easily.
> >
> >   To make matter worse, curious customers rapidly loiter= from
> >   venue to venue, joining and pruning (S,G). Whenever th= ey zap
> >   the channel, PIM-SSM signaling travels from receiver t= o most
> >   nearest branching router marking or erasing routing en= tries.
> >
> >   That's why I want you to scale your routers up to mill= ions
> >   multicast routes. If you will not, neither we will be = support
> >   instant video message on the multicast.
> >
> >   Again.
> >
> >   Please, could you tell us why you consider 5,000 is en= ough and
> >   5,000,000 is too much for the Internet, Dino?
> > ----
> > Yuji
> >
> > _______________________________________________
> > routing-discussion mailing list
> > routing-discussion@ietf.org
> >  https://www1.ietf.org/mailman/listinfo/routing-= discussion
>
>
> _______________________________________________
> routing-discussion mailing list
> routing-discussion@ietf.org
>  https://www1.ietf.org/mailman/listinfo/routing-discu= ssion

= --0__=0ABBE4F0DFC2CE278f9e8a93df938690918c0ABBE4F0DFC2CE27-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Mar 26 12:06:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01671 for ; Fri, 26 Mar 2004 12:06:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6umV-0001aF-0C for routing-discussion-archive@odin.ietf.org; Fri, 26 Mar 2004 12:06:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QH669l006084 for routing-discussion-archive@odin.ietf.org; Fri, 26 Mar 2004 12:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6umP-0001Yo-Mc; Fri, 26 Mar 2004 12:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ulY-0001S0-LI for routing-discussion@optimus.ietf.org; Fri, 26 Mar 2004 12:05:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01608 for ; Fri, 26 Mar 2004 12:05:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ulX-0003aB-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:05:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ukf-0003TX-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:04:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B6ujm-0003Mc-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:03:18 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 26 Mar 2004 09:02:52 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2QH2jew005027; Fri, 26 Mar 2004 09:02:45 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA14463; Fri, 26 Mar 2004 09:02:45 -0800 (PST) Date: Fri, 26 Mar 2004 09:02:44 -0800 From: Toerless Eckert To: Rick Boivie Cc: shep@shepfarm.com, IMAI Yuji , dino@procket.com, mohta@necom830.hpcl.titech.ac.jp, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040326170244.GR2179@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , If there was demand for 10th of millions of users doing video-conferencing between 1..10 people, then you'd already see big hosting servers with some (proprietary) application that would allow you to do this by mean of a simple unicast hub&spoke traffic flow model between participating clients and this server. Yes, there actually like this deployed already, yes, it may be increasing in use with the proliferation of VoIP, but as long as you don't see folks running those servers crying for help from the network, proposing protocol development for this type of application does not seem to target any specific business case problem, right ? Or what am i missing here ? Cheers Toerless On Fri, Mar 26, 2004 at 11:55:11AM -0500, Rick Boivie wrote: > > > > > > Greg wrote: > >..and what percentage of them have mcast enabled? Even better, what > >percentage of them have mcast enabled to the mcast-anabled Internet and > >not just a walled-garden deployment? I'd say less than 1%. > > And that probably won't change anytime soon since: > - the route protocol traffic would be huge if millions or 10's of millions > of people started using multicast for videoconferencing, say > - the bandwidth used for the data could be huge if large numbers of people > started > using multicast for large conferences > > So if we want to support large numbers of videoconferences say, it seems we > need a scheme that > - has minimal (or zero) route protocol traffic > - limits the amount of bandwidth a given user can use e.g. enough to send > to 10 or 20 (or x?) destinations, say. And in those rare occasions when > somebody needs to send to a very larger number of destinations, they can > reserve a "broadcast channel" using traditional multicast schemes and > perhaps > pay for that (?) has Ohta has suggested. > > I might also add that xcast seems to be exactly the right approach for > supporting > large numbers of videoconferences since > - there's zero route protocol traffic > - xcast (as currently constituted) limits the amount of bandwidth a given > user > can use > > So xcast can eliminate the problems that to this point have held back the > broad adoption of multicast and videoconferencing. > > Rick > > > > > > shep@shepfarm.com on 03/24/2004 04:10:53 PM > > To: Rick Boivie/Hawthorne/IBM@IBMUS > cc: IMAI Yuji , , > , , > , , > , , > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > On Wed, 24 Mar 2004, Rick Boivie wrote: > > > Greg said: > > >I'd love to have those problems!!! ;-) ..but for now, we don't even have > a > > >good live example due to the lack of last-mile deployment. > > > > There seems to be plenty of last mile broadband deployed. Note > > that Nielsen/NetRatings says that 49.5 million or 38% of home Internet > > users in the US connect via broadband. > > http://www.nielsen-netratings.com/pr/pr_040108_us.pdf > > > > The % of homes with broadband is even higher in some other countries of > > course. > > > > So lack of last mile deployment doesn't seem to be the issue. Rather > > the problem seems to be that multicast doesn't provide very good support > > for large numbers of small groups -- as the IAB said in RFC 2902. > > > > My 2 cents. > > ..and what percentage of them have mcast enabled? Even better, what > percentage of them have mcast enabled to the mcast-anabled Internet and > not just a walled-garden deployment? I'd say less than 1%. > > Greg > > > Rick > > > > > > > > > > shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM > > > > Sent by: routing-discussion-admin@ietf.org > > > > > > To: Rick Boivie/Hawthorne/IBM@IBMUS > > cc: IMAI Yuji , , > > , , > > , , > > , , > > > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > > > > > > > On Wed, 24 Mar 2004, Rick Boivie wrote: > > > As the Internet Architecture Board said (in RFC 2902) "providing for > many > > > groups > > > of small conferences ... scales badly given the current multicast > model". > > > > > > So if we want tapplications like the above to work when there is > limited > > > bandwidth > > > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > > > multicast scheme that > > > can support very large or unlimited numbers of small groups. > > > > > > Rick Boivie > > > IBM T. J. Watson Research Center > > > rhboivie@us.ibm.com > > > > Rick, > > > > I'd love to have those problems!!! ;-) ..but for now, we don't even have > a > > good live example due to the lack of last-mile deployment. > > > > Yes, I'd love to improve on the scaling of our current mcast solutions, > > but until the deployment warrents it, let's focus on solving the > > deployment barriers. Then when the availablity of mcast begins attracting > > apps and users we can gather imperical data as to what about the current > > scheme does and does not scale. > > > > As an example, please recall NetAid. This WAS a successful large audience > > mcast event which exposed the scaling limits in RTCP - which was > solveable > > at the application layer. Until we have other similar examples exposing > > other limitations, I feel we are just shooting in the air. > > > > Greg > > > > > > > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM > > > > > > Sent by: routing-discussion-admin@ietf.org > > > > > > > > > To: dino@procket.com > > > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, > dmm@1-4-5.net, > > > routing-discussion@ietf.org, mboned@lists.uoregon.edu, > > > zinin@psg.com, fenner@research.att.com > > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > > > > > > > Dino, > > > > > > > Does any protocol then scale if I decide that my table size needs > > to > > > be > > > > 5,000,000 routes? > > > > > > Could you tell us why you consider 5,000 is enough and > > > 5,000,000 is too much for the Internet, please? > > > > > > Reading your mail, you may feel 5,000,000 routes is ridiculous > > > requirement. I agree with you if we can limit to use > > > multicast only for alternative usage of current broadcasting > > > media like TV and radio. 5,000 will be enough because almost > > > channel flows from the anchor desks in N.Y., L.A. or Atlanta > > > spread over world wide Internet. Since such flow of popular > > > programs are always received by many ISPs, each routing entry > > > may be very stable and you may be able to assign multicast > > > addresses to aggregate neatly. > > > > > > However, once we want the application like instant message > > > systems with vic & rat, situation change drastically. In other > > > words, why don't you want to provide Access Grid service for > > > the consumer market? Members of a virtual venue are sparsely > > > distributed over the Internet subscribing different > > > ASes. Using SSM or PIM-SM in short cut mode, number of routing > > > entry become as same as number of transmitters. That means routes > > > grows up to millions very easily. > > > > > > To make matter worse, curious customers rapidly loiter from > > > venue to venue, joining and pruning (S,G). Whenever they zap > > > the channel, PIM-SSM signaling travels from receiver to most > > > nearest branching router marking or erasing routing entries. > > > > > > That's why I want you to scale your routers up to millions > > > multicast routes. If you will not, neither we will be support > > > instant video message on the multicast. > > > > > > Again. > > > > > > Please, could you tell us why you consider 5,000 is enough and > > > 5,000,000 is too much for the Internet, Dino? > > > ---- > > > Yuji > > > > > > _______________________________________________ > > > routing-discussion mailing list > > > routing-discussion@ietf.org > > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > > > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion -- Thanks Toerless Eckert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Mar 26 12:47:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04192 for ; Fri, 26 Mar 2004 12:47:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6vQD-0005Ir-1x for routing-discussion-archive@odin.ietf.org; Fri, 26 Mar 2004 12:47:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QHl9G5020343 for routing-discussion-archive@odin.ietf.org; Fri, 26 Mar 2004 12:47:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6vQ6-0005G1-8b; Fri, 26 Mar 2004 12:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6vAr-00046J-Ng for routing-discussion@optimus.ietf.org; Fri, 26 Mar 2004 12:31:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02990 for ; Fri, 26 Mar 2004 12:31:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6vAq-0005pG-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:31:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6v9r-0005iW-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:30:16 -0500 Received: from mta1.cl.cam.ac.uk ([128.232.0.15] ident=[0anmxN97brLm21h92brrB3fSqbKk60BY]) by ietf-mx with esmtp (Exim 4.12) id 1B6v90-0005ev-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:29:22 -0500 Received: from nidd.cl.cam.ac.uk ([128.232.8.175] helo=cl.cam.ac.uk ident=[Obga/2J1xp+GRIVuQWkXqf0eYBgNBUU9]) by mta1.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 1B6v8a-0005lM-00; Fri, 26 Mar 2004 17:28:56 +0000 To: Toerless Eckert cc: Rick Boivie , shep@shepfarm.com, IMAI Yuji , dino@procket.com, mohta@necom830.hpcl.titech.ac.jp, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com, Jon.Crowcroft@cl.cam.ac.uk Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message from Toerless Eckert of "Fri, 26 Mar 2004 09:02:44 PST." <20040326170244.GR2179@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24625.1080322132.1@cl.cam.ac.uk> Date: Fri, 26 Mar 2004 17:28:52 +0000 From: Jon Crowcroft Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , In missive <20040326170244.GR2179@cisco.com>, Toerless Eckert typed: >>If there was demand for 10th of millions of users doing video-conferencing >>between 1..10 people, then you'd already see big hosting servers with >>some (proprietary) application that would allow you to do this by >>mean of a simple unicast hub&spoke traffic flow model between participating >>clients and this server. Yes, there actually like this deployed already, >>yes, it may be increasing in use with the proliferation of VoIP, but as long >>as you don't see folks running those servers crying for help from the network, >>proposing protocol development for this type of application does not >>seem to target any specific business case problem, right ? >>Or what am i missing here ? Toerless you're missing the fact that there was no business for unicast IP - the web came 10 years after anyhow engineers dont do business cases - last time they did they did a load of .com crap - we are tryting to engineer varioius types of network support for scalable group communication - there is NO point in discsussing why we shouldnt do multicast on a list dedicated to deployment of multicast - thats for other lists (like ipv6 has ipv6haters - people who want to laugh at multicast should set up a "friends of the ISP profiteers doing unnecesary packet replication, and overcharing media server" maillist and go discuss how silly we all are there- (but remember what the chinese say (beware you may become what you laugh at) build it (and build it right) and they will come... any how all the h323 stuff for doing loads of hub based video conf is a real pain to configure and run - thats why we dd all the mmconf stuff on ip multicast - it was because doing something in the net was gong to reduce the pain for application developers. the problem is that we did it all when the net wasnt fast enough so we were asking for 3 thigns to be changed simulatenously - qos or overprovision force voice/video, do multicast , and do rtp tool sets - this was 2 things too many - but starting now, the net is provisioned ok, the rtp tools and end system s/w are all there, so now we only need to do 1 thing right....multicast -most the pieces for multicast are lying around now...just a lot of people who know how to put them togetehr have got bored and gone on to other stuff (like setting up p2p systems , or doing wireless and mobile right, or creating lists for laughing at people who revist the same wrong arguments on IETF lists year after year:) comment on percetnage argument below - what percentage of end systems/hosts sites have ipv4 deployed (i.e. non natted so you can reach their server with unicast)? grenville armiatage had some stats which showed that walled garden unicast is pretty bad. we dont see people not doing voip because of that, we see lots of creative nat traversal work - keep the faith... >>On Fri, Mar 26, 2004 at 11:55:11AM -0500, Rick Boivie wrote: >>> >>> >>> >>> >>> >>> Greg wrote: >>> >..and what percentage of them have mcast enabled? Even better, what >>> >percentage of them have mcast enabled to the mcast-anabled Internet and >>> >not just a walled-garden deployment? I'd say less than 1%. >>> >>> And that probably won't change anytime soon since: >>> - the route protocol traffic would be huge if millions or 10's of millions >>> of people started using multicast for videoconferencing, say >>> - the bandwidth used for the data could be huge if large numbers of people >>> started >>> using multicast for large conferences >>> >>> So if we want to support large numbers of videoconferences say, it seems we >>> need a scheme that >>> - has minimal (or zero) route protocol traffic >>> - limits the amount of bandwidth a given user can use e.g. enough to send >>> to 10 or 20 (or x?) destinations, say. And in those rare occasions when >>> somebody needs to send to a very larger number of destinations, they can >>> reserve a "broadcast channel" using traditional multicast schemes and >>> perhaps >>> pay for that (?) has Ohta has suggested. >>> >>> I might also add that xcast seems to be exactly the right approach for >>> supporting >>> large numbers of videoconferences since >>> - there's zero route protocol traffic >>> - xcast (as currently constituted) limits the amount of bandwidth a given >>> user >>> can use >>> >>> So xcast can eliminate the problems that to this point have held back the >>> broad adoption of multicast and videoconferencing. >>> >>> Rick >>> >>> >>> >>> >>> >>> shep@shepfarm.com on 03/24/2004 04:10:53 PM >>> >>> To: Rick Boivie/Hawthorne/IBM@IBMUS >>> cc: IMAI Yuji , , >>> , , >>> , , >>> , , >>> >>> Subject: Re: mboned: BGMP & DVMRP status Q. >>> >>> >>> >>> On Wed, 24 Mar 2004, Rick Boivie wrote: >>> >>> > Greg said: >>> > >I'd love to have those problems!!! ;-) ..but for now, we don't even have >>> a >>> > >good live example due to the lack of last-mile deployment. >>> > >>> > There seems to be plenty of last mile broadband deployed. Note >>> > that Nielsen/NetRatings says that 49.5 million or 38% of home Internet >>> > users in the US connect via broadband. >>> > http://www.nielsen-netratings.com/pr/pr_040108_us.pdf >>> > >>> > The % of homes with broadband is even higher in some other countries of >>> > course. >>> > >>> > So lack of last mile deployment doesn't seem to be the issue. Rather >>> > the problem seems to be that multicast doesn't provide very good support >>> > for large numbers of small groups -- as the IAB said in RFC 2902. >>> > >>> > My 2 cents. >>> >>> ..and what percentage of them have mcast enabled? Even better, what >>> percentage of them have mcast enabled to the mcast-anabled Internet and >>> not just a walled-garden deployment? I'd say less than 1%. >>> >>> Greg >>> >>> > Rick >>> > >>> > >>> > >>> > >>> > shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM >>> > >>> > Sent by: routing-discussion-admin@ietf.org >>> > >>> > >>> > To: Rick Boivie/Hawthorne/IBM@IBMUS >>> > cc: IMAI Yuji , , >>> > , , >>> > , , >>> > , , >>> > >>> > Subject: Re: mboned: BGMP & DVMRP status Q. >>> > >>> > >>> > >>> > >>> > >>> > On Wed, 24 Mar 2004, Rick Boivie wrote: >>> > > As the Internet Architecture Board said (in RFC 2902) "providing for >>> many >>> > > groups >>> > > of small conferences ... scales badly given the current multicast >>> model". >>> > > >>> > > So if we want tapplications like the above to work when there is >>> limited >>> > > bandwidth >>> > > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a >>> > > multicast scheme that >>> > > can support very large or unlimited numbers of small groups. >>> > > >>> > > Rick Boivie >>> > > IBM T. J. Watson Research Center >>> > > rhboivie@us.ibm.com >>> > >>> > Rick, >>> > >>> > I'd love to have those problems!!! ;-) ..but for now, we don't even have >>> a >>> > good live example due to the lack of last-mile deployment. >>> > >>> > Yes, I'd love to improve on the scaling of our current mcast solutions, >>> > but until the deployment warrents it, let's focus on solving the >>> > deployment barriers. Then when the availablity of mcast begins attracting >>> > apps and users we can gather imperical data as to what about the current >>> > scheme does and does not scale. >>> > >>> > As an example, please recall NetAid. This WAS a successful large audience >>> > mcast event which exposed the scaling limits in RTCP - which was >>> solveable >>> > at the application layer. Until we have other similar examples exposing >>> > other limitations, I feel we are just shooting in the air. >>> > >>> > Greg >>> > >>> > > >>> > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM >>> > > >>> > > Sent by: routing-discussion-admin@ietf.org >>> > > >>> > > >>> > > To: dino@procket.com >>> > > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, >>> dmm@1-4-5.net, >>> > > routing-discussion@ietf.org, mboned@lists.uoregon.edu, >>> > > zinin@psg.com, fenner@research.att.com >>> > > Subject: Re: mboned: BGMP & DVMRP status Q. >>> > > >>> > > >>> > > >>> > > Dino, >>> > > >>> > > > Does any protocol then scale if I decide that my table size needs >>> > to >>> > > be >>> > > > 5,000,000 routes? >>> > > >>> > > Could you tell us why you consider 5,000 is enough and >>> > > 5,000,000 is too much for the Internet, please? >>> > > >>> > > Reading your mail, you may feel 5,000,000 routes is ridiculous >>> > > requirement. I agree with you if we can limit to use >>> > > multicast only for alternative usage of current broadcasting >>> > > media like TV and radio. 5,000 will be enough because almost >>> > > channel flows from the anchor desks in N.Y., L.A. or Atlanta >>> > > spread over world wide Internet. Since such flow of popular >>> > > programs are always received by many ISPs, each routing entry >>> > > may be very stable and you may be able to assign multicast >>> > > addresses to aggregate neatly. >>> > > >>> > > However, once we want the application like instant message >>> > > systems with vic & rat, situation change drastically. In other >>> > > words, why don't you want to provide Access Grid service for >>> > > the consumer market? Members of a virtual venue are sparsely >>> > > distributed over the Internet subscribing different >>> > > ASes. Using SSM or PIM-SM in short cut mode, number of routing >>> > > entry become as same as number of transmitters. That means routes >>> > > grows up to millions very easily. >>> > > >>> > > To make matter worse, curious customers rapidly loiter from >>> > > venue to venue, joining and pruning (S,G). Whenever they zap >>> > > the channel, PIM-SSM signaling travels from receiver to most >>> > > nearest branching router marking or erasing routing entries. >>> > > >>> > > That's why I want you to scale your routers up to millions >>> > > multicast routes. If you will not, neither we will be support >>> > > instant video message on the multicast. >>> > > >>> > > Again. >>> > > >>> > > Please, could you tell us why you consider 5,000 is enough and >>> > > 5,000,000 is too much for the Internet, Dino? >>> > > ---- >>> > > Yuji >>> > > >>> > > _______________________________________________ >>> > > routing-discussion mailing list >>> > > routing-discussion@ietf.org >>> > > https://www1.ietf.org/mailman/listinfo/routing-discussion >>> > >>> > >>> > _______________________________________________ >>> > routing-discussion mailing list >>> > routing-discussion@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/routing-discussion >> >>-- >>Thanks >> Toerless Eckert >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion cheers jon _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 26 12:47:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04186 for ; Fri, 26 Mar 2004 12:47:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6vQ5-0005Fs-Nr; Fri, 26 Mar 2004 12:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6MnE-0005eJ-KX for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 23:48:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13454 for ; Wed, 24 Mar 2004 23:48:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6MnC-000589-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 23:48:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6MmE-00053N-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 23:47:35 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6MlD-0004wT-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 23:46:32 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2P4kGOr021455; Thu, 25 Mar 2004 04:46:16 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id EAA27139; Thu, 25 Mar 2004 04:46:10 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2P4kAC20080; Thu, 25 Mar 2004 04:46:10 GMT Date: Thu, 25 Mar 2004 04:46:10 +0000 From: Tim Chown To: John Zwiebel Cc: Rick Boivie , "" , "" , "" , "" , IMAI Yuji , Toerless Eckert , "" , Dino Farinacci , "" Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040325044610.GB20045@login.ecs.soton.ac.uk> References: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, Mar 24, 2004 at 10:52:33AM -0800, John Zwiebel wrote: > > Considering: > -- the current difficulty of providing a SSM based multicast tree Hi John, Do you have a pointer to documentation describing the issues causing this difficulty? Thanks, Tim _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 26 12:53:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01672 for ; Fri, 26 Mar 2004 12:06:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6umP-0001Yo-Mc; Fri, 26 Mar 2004 12:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ulY-0001S0-LI for routing-discussion@optimus.ietf.org; Fri, 26 Mar 2004 12:05:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01608 for ; Fri, 26 Mar 2004 12:05:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ulX-0003aB-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:05:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ukf-0003TX-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:04:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B6ujm-0003Mc-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:03:18 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 26 Mar 2004 09:02:52 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2QH2jew005027; Fri, 26 Mar 2004 09:02:45 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA14463; Fri, 26 Mar 2004 09:02:45 -0800 (PST) Date: Fri, 26 Mar 2004 09:02:44 -0800 From: Toerless Eckert To: Rick Boivie Cc: shep@shepfarm.com, IMAI Yuji , dino@procket.com, mohta@necom830.hpcl.titech.ac.jp, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040326170244.GR2179@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , If there was demand for 10th of millions of users doing video-conferencing between 1..10 people, then you'd already see big hosting servers with some (proprietary) application that would allow you to do this by mean of a simple unicast hub&spoke traffic flow model between participating clients and this server. Yes, there actually like this deployed already, yes, it may be increasing in use with the proliferation of VoIP, but as long as you don't see folks running those servers crying for help from the network, proposing protocol development for this type of application does not seem to target any specific business case problem, right ? Or what am i missing here ? Cheers Toerless On Fri, Mar 26, 2004 at 11:55:11AM -0500, Rick Boivie wrote: > > > > > > Greg wrote: > >..and what percentage of them have mcast enabled? Even better, what > >percentage of them have mcast enabled to the mcast-anabled Internet and > >not just a walled-garden deployment? I'd say less than 1%. > > And that probably won't change anytime soon since: > - the route protocol traffic would be huge if millions or 10's of millions > of people started using multicast for videoconferencing, say > - the bandwidth used for the data could be huge if large numbers of people > started > using multicast for large conferences > > So if we want to support large numbers of videoconferences say, it seems we > need a scheme that > - has minimal (or zero) route protocol traffic > - limits the amount of bandwidth a given user can use e.g. enough to send > to 10 or 20 (or x?) destinations, say. And in those rare occasions when > somebody needs to send to a very larger number of destinations, they can > reserve a "broadcast channel" using traditional multicast schemes and > perhaps > pay for that (?) has Ohta has suggested. > > I might also add that xcast seems to be exactly the right approach for > supporting > large numbers of videoconferences since > - there's zero route protocol traffic > - xcast (as currently constituted) limits the amount of bandwidth a given > user > can use > > So xcast can eliminate the problems that to this point have held back the > broad adoption of multicast and videoconferencing. > > Rick > > > > > > shep@shepfarm.com on 03/24/2004 04:10:53 PM > > To: Rick Boivie/Hawthorne/IBM@IBMUS > cc: IMAI Yuji , , > , , > , , > , , > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > On Wed, 24 Mar 2004, Rick Boivie wrote: > > > Greg said: > > >I'd love to have those problems!!! ;-) ..but for now, we don't even have > a > > >good live example due to the lack of last-mile deployment. > > > > There seems to be plenty of last mile broadband deployed. Note > > that Nielsen/NetRatings says that 49.5 million or 38% of home Internet > > users in the US connect via broadband. > > http://www.nielsen-netratings.com/pr/pr_040108_us.pdf > > > > The % of homes with broadband is even higher in some other countries of > > course. > > > > So lack of last mile deployment doesn't seem to be the issue. Rather > > the problem seems to be that multicast doesn't provide very good support > > for large numbers of small groups -- as the IAB said in RFC 2902. > > > > My 2 cents. > > ..and what percentage of them have mcast enabled? Even better, what > percentage of them have mcast enabled to the mcast-anabled Internet and > not just a walled-garden deployment? I'd say less than 1%. > > Greg > > > Rick > > > > > > > > > > shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM > > > > Sent by: routing-discussion-admin@ietf.org > > > > > > To: Rick Boivie/Hawthorne/IBM@IBMUS > > cc: IMAI Yuji , , > > , , > > , , > > , , > > > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > > > > > > > On Wed, 24 Mar 2004, Rick Boivie wrote: > > > As the Internet Architecture Board said (in RFC 2902) "providing for > many > > > groups > > > of small conferences ... scales badly given the current multicast > model". > > > > > > So if we want tapplications like the above to work when there is > limited > > > bandwidth > > > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a > > > multicast scheme that > > > can support very large or unlimited numbers of small groups. > > > > > > Rick Boivie > > > IBM T. J. Watson Research Center > > > rhboivie@us.ibm.com > > > > Rick, > > > > I'd love to have those problems!!! ;-) ..but for now, we don't even have > a > > good live example due to the lack of last-mile deployment. > > > > Yes, I'd love to improve on the scaling of our current mcast solutions, > > but until the deployment warrents it, let's focus on solving the > > deployment barriers. Then when the availablity of mcast begins attracting > > apps and users we can gather imperical data as to what about the current > > scheme does and does not scale. > > > > As an example, please recall NetAid. This WAS a successful large audience > > mcast event which exposed the scaling limits in RTCP - which was > solveable > > at the application layer. Until we have other similar examples exposing > > other limitations, I feel we are just shooting in the air. > > > > Greg > > > > > > > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM > > > > > > Sent by: routing-discussion-admin@ietf.org > > > > > > > > > To: dino@procket.com > > > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, > dmm@1-4-5.net, > > > routing-discussion@ietf.org, mboned@lists.uoregon.edu, > > > zinin@psg.com, fenner@research.att.com > > > Subject: Re: mboned: BGMP & DVMRP status Q. > > > > > > > > > > > > Dino, > > > > > > > Does any protocol then scale if I decide that my table size needs > > to > > > be > > > > 5,000,000 routes? > > > > > > Could you tell us why you consider 5,000 is enough and > > > 5,000,000 is too much for the Internet, please? > > > > > > Reading your mail, you may feel 5,000,000 routes is ridiculous > > > requirement. I agree with you if we can limit to use > > > multicast only for alternative usage of current broadcasting > > > media like TV and radio. 5,000 will be enough because almost > > > channel flows from the anchor desks in N.Y., L.A. or Atlanta > > > spread over world wide Internet. Since such flow of popular > > > programs are always received by many ISPs, each routing entry > > > may be very stable and you may be able to assign multicast > > > addresses to aggregate neatly. > > > > > > However, once we want the application like instant message > > > systems with vic & rat, situation change drastically. In other > > > words, why don't you want to provide Access Grid service for > > > the consumer market? Members of a virtual venue are sparsely > > > distributed over the Internet subscribing different > > > ASes. Using SSM or PIM-SM in short cut mode, number of routing > > > entry become as same as number of transmitters. That means routes > > > grows up to millions very easily. > > > > > > To make matter worse, curious customers rapidly loiter from > > > venue to venue, joining and pruning (S,G). Whenever they zap > > > the channel, PIM-SSM signaling travels from receiver to most > > > nearest branching router marking or erasing routing entries. > > > > > > That's why I want you to scale your routers up to millions > > > multicast routes. If you will not, neither we will be support > > > instant video message on the multicast. > > > > > > Again. > > > > > > Please, could you tell us why you consider 5,000 is enough and > > > 5,000,000 is too much for the Internet, Dino? > > > ---- > > > Yuji > > > > > > _______________________________________________ > > > routing-discussion mailing list > > > routing-discussion@ietf.org > > > https://www1.ietf.org/mailman/listinfo/routing-discussion > > > > > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www1.ietf.org/mailman/listinfo/routing-discussion -- Thanks Toerless Eckert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Mar 26 13:33:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04190 for ; Fri, 26 Mar 2004 12:47:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6vQD-0005Ip-1x for routing-discussion-archive@odin.ietf.org; Fri, 26 Mar 2004 12:47:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QHl9U1020344 for routing-discussion-archive@odin.ietf.org; Fri, 26 Mar 2004 12:47:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6vQ5-0005Fs-Nr; Fri, 26 Mar 2004 12:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6MnE-0005eJ-KX for routing-discussion@optimus.ietf.org; Wed, 24 Mar 2004 23:48:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13454 for ; Wed, 24 Mar 2004 23:48:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6MnC-000589-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 23:48:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6MmE-00053N-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 23:47:35 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6MlD-0004wT-00 for routing-discussion@ietf.org; Wed, 24 Mar 2004 23:46:32 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2P4kGOr021455; Thu, 25 Mar 2004 04:46:16 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id EAA27139; Thu, 25 Mar 2004 04:46:10 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2P4kAC20080; Thu, 25 Mar 2004 04:46:10 GMT Date: Thu, 25 Mar 2004 04:46:10 +0000 From: Tim Chown To: John Zwiebel Cc: Rick Boivie , "" , "" , "" , "" , IMAI Yuji , Toerless Eckert , "" , Dino Farinacci , "" Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040325044610.GB20045@login.ecs.soton.ac.uk> References: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6904A60C-7DC4-11D8-A089-00039307689E@procket.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Wed, Mar 24, 2004 at 10:52:33AM -0800, John Zwiebel wrote: > > Considering: > -- the current difficulty of providing a SSM based multicast tree Hi John, Do you have a pointer to documentation describing the issues causing this difficulty? Thanks, Tim _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 26 13:33:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04187 for ; Fri, 26 Mar 2004 12:47:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6vQ6-0005G1-8b; Fri, 26 Mar 2004 12:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6vAr-00046J-Ng for routing-discussion@optimus.ietf.org; Fri, 26 Mar 2004 12:31:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02990 for ; Fri, 26 Mar 2004 12:31:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6vAq-0005pG-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:31:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6v9r-0005iW-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:30:16 -0500 Received: from mta1.cl.cam.ac.uk ([128.232.0.15] ident=[0anmxN97brLm21h92brrB3fSqbKk60BY]) by ietf-mx with esmtp (Exim 4.12) id 1B6v90-0005ev-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 12:29:22 -0500 Received: from nidd.cl.cam.ac.uk ([128.232.8.175] helo=cl.cam.ac.uk ident=[Obga/2J1xp+GRIVuQWkXqf0eYBgNBUU9]) by mta1.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 1B6v8a-0005lM-00; Fri, 26 Mar 2004 17:28:56 +0000 To: Toerless Eckert cc: Rick Boivie , shep@shepfarm.com, IMAI Yuji , dino@procket.com, mohta@necom830.hpcl.titech.ac.jp, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com, Jon.Crowcroft@cl.cam.ac.uk Subject: Re: mboned: BGMP & DVMRP status Q. In-Reply-To: Message from Toerless Eckert of "Fri, 26 Mar 2004 09:02:44 PST." <20040326170244.GR2179@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24625.1080322132.1@cl.cam.ac.uk> Date: Fri, 26 Mar 2004 17:28:52 +0000 From: Jon Crowcroft Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , In missive <20040326170244.GR2179@cisco.com>, Toerless Eckert typed: >>If there was demand for 10th of millions of users doing video-conferencing >>between 1..10 people, then you'd already see big hosting servers with >>some (proprietary) application that would allow you to do this by >>mean of a simple unicast hub&spoke traffic flow model between participating >>clients and this server. Yes, there actually like this deployed already, >>yes, it may be increasing in use with the proliferation of VoIP, but as long >>as you don't see folks running those servers crying for help from the network, >>proposing protocol development for this type of application does not >>seem to target any specific business case problem, right ? >>Or what am i missing here ? Toerless you're missing the fact that there was no business for unicast IP - the web came 10 years after anyhow engineers dont do business cases - last time they did they did a load of .com crap - we are tryting to engineer varioius types of network support for scalable group communication - there is NO point in discsussing why we shouldnt do multicast on a list dedicated to deployment of multicast - thats for other lists (like ipv6 has ipv6haters - people who want to laugh at multicast should set up a "friends of the ISP profiteers doing unnecesary packet replication, and overcharing media server" maillist and go discuss how silly we all are there- (but remember what the chinese say (beware you may become what you laugh at) build it (and build it right) and they will come... any how all the h323 stuff for doing loads of hub based video conf is a real pain to configure and run - thats why we dd all the mmconf stuff on ip multicast - it was because doing something in the net was gong to reduce the pain for application developers. the problem is that we did it all when the net wasnt fast enough so we were asking for 3 thigns to be changed simulatenously - qos or overprovision force voice/video, do multicast , and do rtp tool sets - this was 2 things too many - but starting now, the net is provisioned ok, the rtp tools and end system s/w are all there, so now we only need to do 1 thing right....multicast -most the pieces for multicast are lying around now...just a lot of people who know how to put them togetehr have got bored and gone on to other stuff (like setting up p2p systems , or doing wireless and mobile right, or creating lists for laughing at people who revist the same wrong arguments on IETF lists year after year:) comment on percetnage argument below - what percentage of end systems/hosts sites have ipv4 deployed (i.e. non natted so you can reach their server with unicast)? grenville armiatage had some stats which showed that walled garden unicast is pretty bad. we dont see people not doing voip because of that, we see lots of creative nat traversal work - keep the faith... >>On Fri, Mar 26, 2004 at 11:55:11AM -0500, Rick Boivie wrote: >>> >>> >>> >>> >>> >>> Greg wrote: >>> >..and what percentage of them have mcast enabled? Even better, what >>> >percentage of them have mcast enabled to the mcast-anabled Internet and >>> >not just a walled-garden deployment? I'd say less than 1%. >>> >>> And that probably won't change anytime soon since: >>> - the route protocol traffic would be huge if millions or 10's of millions >>> of people started using multicast for videoconferencing, say >>> - the bandwidth used for the data could be huge if large numbers of people >>> started >>> using multicast for large conferences >>> >>> So if we want to support large numbers of videoconferences say, it seems we >>> need a scheme that >>> - has minimal (or zero) route protocol traffic >>> - limits the amount of bandwidth a given user can use e.g. enough to send >>> to 10 or 20 (or x?) destinations, say. And in those rare occasions when >>> somebody needs to send to a very larger number of destinations, they can >>> reserve a "broadcast channel" using traditional multicast schemes and >>> perhaps >>> pay for that (?) has Ohta has suggested. >>> >>> I might also add that xcast seems to be exactly the right approach for >>> supporting >>> large numbers of videoconferences since >>> - there's zero route protocol traffic >>> - xcast (as currently constituted) limits the amount of bandwidth a given >>> user >>> can use >>> >>> So xcast can eliminate the problems that to this point have held back the >>> broad adoption of multicast and videoconferencing. >>> >>> Rick >>> >>> >>> >>> >>> >>> shep@shepfarm.com on 03/24/2004 04:10:53 PM >>> >>> To: Rick Boivie/Hawthorne/IBM@IBMUS >>> cc: IMAI Yuji , , >>> , , >>> , , >>> , , >>> >>> Subject: Re: mboned: BGMP & DVMRP status Q. >>> >>> >>> >>> On Wed, 24 Mar 2004, Rick Boivie wrote: >>> >>> > Greg said: >>> > >I'd love to have those problems!!! ;-) ..but for now, we don't even have >>> a >>> > >good live example due to the lack of last-mile deployment. >>> > >>> > There seems to be plenty of last mile broadband deployed. Note >>> > that Nielsen/NetRatings says that 49.5 million or 38% of home Internet >>> > users in the US connect via broadband. >>> > http://www.nielsen-netratings.com/pr/pr_040108_us.pdf >>> > >>> > The % of homes with broadband is even higher in some other countries of >>> > course. >>> > >>> > So lack of last mile deployment doesn't seem to be the issue. Rather >>> > the problem seems to be that multicast doesn't provide very good support >>> > for large numbers of small groups -- as the IAB said in RFC 2902. >>> > >>> > My 2 cents. >>> >>> ..and what percentage of them have mcast enabled? Even better, what >>> percentage of them have mcast enabled to the mcast-anabled Internet and >>> not just a walled-garden deployment? I'd say less than 1%. >>> >>> Greg >>> >>> > Rick >>> > >>> > >>> > >>> > >>> > shep@shepfarm.com@ietf.org on 03/24/2004 02:43:06 PM >>> > >>> > Sent by: routing-discussion-admin@ietf.org >>> > >>> > >>> > To: Rick Boivie/Hawthorne/IBM@IBMUS >>> > cc: IMAI Yuji , , >>> > , , >>> > , , >>> > , , >>> > >>> > Subject: Re: mboned: BGMP & DVMRP status Q. >>> > >>> > >>> > >>> > >>> > >>> > On Wed, 24 Mar 2004, Rick Boivie wrote: >>> > > As the Internet Architecture Board said (in RFC 2902) "providing for >>> many >>> > > groups >>> > > of small conferences ... scales badly given the current multicast >>> model". >>> > > >>> > > So if we want tapplications like the above to work when there is >>> limited >>> > > bandwidth >>> > > in the first mile (e.g. DSL, cable modem, wireless etc.) we need a >>> > > multicast scheme that >>> > > can support very large or unlimited numbers of small groups. >>> > > >>> > > Rick Boivie >>> > > IBM T. J. Watson Research Center >>> > > rhboivie@us.ibm.com >>> > >>> > Rick, >>> > >>> > I'd love to have those problems!!! ;-) ..but for now, we don't even have >>> a >>> > good live example due to the lack of last-mile deployment. >>> > >>> > Yes, I'd love to improve on the scaling of our current mcast solutions, >>> > but until the deployment warrents it, let's focus on solving the >>> > deployment barriers. Then when the availablity of mcast begins attracting >>> > apps and users we can gather imperical data as to what about the current >>> > scheme does and does not scale. >>> > >>> > As an example, please recall NetAid. This WAS a successful large audience >>> > mcast event which exposed the scaling limits in RTCP - which was >>> solveable >>> > at the application layer. Until we have other similar examples exposing >>> > other limitations, I feel we are just shooting in the air. >>> > >>> > Greg >>> > >>> > > >>> > > IMAI Yuji @ietf.org on 03/23/2004 11:29:57 PM >>> > > >>> > > Sent by: routing-discussion-admin@ietf.org >>> > > >>> > > >>> > > To: dino@procket.com >>> > > cc: mohta@necom830.hpcl.titech.ac.jp, eckert@cisco.com, >>> dmm@1-4-5.net, >>> > > routing-discussion@ietf.org, mboned@lists.uoregon.edu, >>> > > zinin@psg.com, fenner@research.att.com >>> > > Subject: Re: mboned: BGMP & DVMRP status Q. >>> > > >>> > > >>> > > >>> > > Dino, >>> > > >>> > > > Does any protocol then scale if I decide that my table size needs >>> > to >>> > > be >>> > > > 5,000,000 routes? >>> > > >>> > > Could you tell us why you consider 5,000 is enough and >>> > > 5,000,000 is too much for the Internet, please? >>> > > >>> > > Reading your mail, you may feel 5,000,000 routes is ridiculous >>> > > requirement. I agree with you if we can limit to use >>> > > multicast only for alternative usage of current broadcasting >>> > > media like TV and radio. 5,000 will be enough because almost >>> > > channel flows from the anchor desks in N.Y., L.A. or Atlanta >>> > > spread over world wide Internet. Since such flow of popular >>> > > programs are always received by many ISPs, each routing entry >>> > > may be very stable and you may be able to assign multicast >>> > > addresses to aggregate neatly. >>> > > >>> > > However, once we want the application like instant message >>> > > systems with vic & rat, situation change drastically. In other >>> > > words, why don't you want to provide Access Grid service for >>> > > the consumer market? Members of a virtual venue are sparsely >>> > > distributed over the Internet subscribing different >>> > > ASes. Using SSM or PIM-SM in short cut mode, number of routing >>> > > entry become as same as number of transmitters. That means routes >>> > > grows up to millions very easily. >>> > > >>> > > To make matter worse, curious customers rapidly loiter from >>> > > venue to venue, joining and pruning (S,G). Whenever they zap >>> > > the channel, PIM-SSM signaling travels from receiver to most >>> > > nearest branching router marking or erasing routing entries. >>> > > >>> > > That's why I want you to scale your routers up to millions >>> > > multicast routes. If you will not, neither we will be support >>> > > instant video message on the multicast. >>> > > >>> > > Again. >>> > > >>> > > Please, could you tell us why you consider 5,000 is enough and >>> > > 5,000,000 is too much for the Internet, Dino? >>> > > ---- >>> > > Yuji >>> > > >>> > > _______________________________________________ >>> > > routing-discussion mailing list >>> > > routing-discussion@ietf.org >>> > > https://www1.ietf.org/mailman/listinfo/routing-discussion >>> > >>> > >>> > _______________________________________________ >>> > routing-discussion mailing list >>> > routing-discussion@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/routing-discussion >> >>-- >>Thanks >> Toerless Eckert >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion cheers jon _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 30 11:33:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27392 for ; Tue, 30 Mar 2004 11:33:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MAh-0007YD-7d; Tue, 30 Mar 2004 11:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MAC-0007Q7-K6 for routing-discussion@optimus.ietf.org; Tue, 30 Mar 2004 11:32:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27341 for ; Tue, 30 Mar 2004 11:32:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8MAB-0005NW-00 for routing-discussion@ietf.org; Tue, 30 Mar 2004 11:32:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8M9R-0005E7-00 for routing-discussion@ietf.org; Tue, 30 Mar 2004 11:31:46 -0500 Received: from web41801.mail.yahoo.com ([66.218.93.135]) by ietf-mx with smtp (Exim 4.12) id 1B8M8u-00052S-00 for routing-discussion@ietf.org; Tue, 30 Mar 2004 11:31:12 -0500 Message-ID: <20040330163038.60496.qmail@web41801.mail.yahoo.com> Received: from [63.158.252.52] by web41801.mail.yahoo.com via HTTP; Tue, 30 Mar 2004 08:30:38 PST Date: Tue, 30 Mar 2004 08:30:38 -0800 (PST) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2004: May 13-14, 2004, Las Vegas To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-644159121-1080664238=:60438" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --0-644159121-1080664238=:60438 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA27342 Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Internetworking 2004=20 May 13-14, 2004 Las Vegas Convention Center, Las Vegas, Nevada http://www.caitr.org/internetworking04/index.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Internetworking 2004, for the first time collocated with NetWorld+Interop= , aims to address some of the main issues of concern within IP networking= and the Internet. This exclusive leading-edge technology program covers = innovative solutions for Enterprises, Service Providers, networking equip= ment manufacturers, government and others.=20 =20 The Internetworking 2004 conference, comprised of comprehensive technical= sessions, panels, and case studies for real operational networks, is int= ended as a forum for technical discussions on topics including:=20 =20 =95 Voice over IP (VoIP) and Convergence =95 Multiservice Network Design and Planning =95 Virtual Private Networks (VPNs) =95 Routing: Unicast & Multicast=20 =95 Wireless Internet=20 =95 Next Generation Mobile Networks=20 =95 Quality of Service (QoS) =95 Network Security=20 =95 Network Processors=20 =95 Service Integration=20 =95 Operational Support Systems=20 =95 Network Survivability and Fault Management=20 =95 Internetworking IP and Optical Networks=20 ***EXCLUSIVE ALUMNI DISCOUNT*** We are pleased to extend a special alumni discount for the 2-day Internet= working 2004 Pass. Purchase the pass for $595.00, a $500.00 savings off t= he regular price. Visit for Priority Code and registration details.=20 We look forward to seeing you at the only end-to-end networking and commu= nications event. =20 Sincerely, The NetWorld+Interop Team http://www.interop.com/ --0-644159121-1080664238=:60438 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA27342 Content-Transfer-Encoding: quoted-printable

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /DIV>
Internetworking 2004
May 13-14, 2004
Las Vegas Convention Cen= ter, Las Vegas, Nevada
http://www.caitr.org/internetworking04/index.htm
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /DIV>
 
Internetworking 2004, for the first time collocated with NetWorld+In= terop, aims to address some of the main issues of concern within IP netwo= rking and the Internet. This exclusive leading-edge technology program co= vers innovative solutions for Enterprises, Service Providers, networking = equipment manufacturers, government and others.
 
The Internetworking 2004 conference, comprised of comprehensive tech= nical sessions, panels, and case studies for real operational networks, i= s intended as a forum for technical discussions on topics including:
 
=95 Voice over IP (VoIP) and Convergence
=95 Multiservice Network= Design and Planning
=95 Virtual Private Networks (VPNs)
=95 Routin= g: Unicast & Multicast
=95 Wireless Internet
=95 Next Generat= ion Mobile Networks
=95 Quality of Service (QoS)
=95 Network Secur= ity
=95 Network Processors
=95 Service Integration
=95 Operat= ional Support Systems
=95 Network Survivability and Fault Management =
=95 Internetworking IP and Optical Networks
***EXCLUSIVE ALUMNI DISCOUNT***
We are pleased to extend a s= pecial alumni discount for the 2-day Internetworking 2004 Pass. Purchase = the pass for $595.00, a $500.00 savings off the regular price. Visit= <= http://www.caitr.org/internetworking04/registration.htm> for Prior= ity Code and registration details.

We look forward to seeing you at the only end-to-end networking = and communications event.
 
Sincerely,
The NetWorld+Interop Team
http://www.interop.com/
--0-644159121-1080664238=:60438-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 30 12:19:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27391 for ; Tue, 30 Mar 2004 11:33:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MB4-0007gI-5w for routing-discussion-archive@odin.ietf.org; Tue, 30 Mar 2004 11:33:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UGXQlL029525 for routing-discussion-archive@odin.ietf.org; Tue, 30 Mar 2004 11:33:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MAh-0007YD-7d; Tue, 30 Mar 2004 11:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MAC-0007Q7-K6 for routing-discussion@optimus.ietf.org; Tue, 30 Mar 2004 11:32:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27341 for ; Tue, 30 Mar 2004 11:32:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8MAB-0005NW-00 for routing-discussion@ietf.org; Tue, 30 Mar 2004 11:32:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8M9R-0005E7-00 for routing-discussion@ietf.org; Tue, 30 Mar 2004 11:31:46 -0500 Received: from web41801.mail.yahoo.com ([66.218.93.135]) by ietf-mx with smtp (Exim 4.12) id 1B8M8u-00052S-00 for routing-discussion@ietf.org; Tue, 30 Mar 2004 11:31:12 -0500 Message-ID: <20040330163038.60496.qmail@web41801.mail.yahoo.com> Received: from [63.158.252.52] by web41801.mail.yahoo.com via HTTP; Tue, 30 Mar 2004 08:30:38 PST Date: Tue, 30 Mar 2004 08:30:38 -0800 (PST) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2004: May 13-14, 2004, Las Vegas To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-644159121-1080664238=:60438" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , --0-644159121-1080664238=:60438 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA27342 Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Internetworking 2004=20 May 13-14, 2004 Las Vegas Convention Center, Las Vegas, Nevada http://www.caitr.org/internetworking04/index.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Internetworking 2004, for the first time collocated with NetWorld+Interop= , aims to address some of the main issues of concern within IP networking= and the Internet. This exclusive leading-edge technology program covers = innovative solutions for Enterprises, Service Providers, networking equip= ment manufacturers, government and others.=20 =20 The Internetworking 2004 conference, comprised of comprehensive technical= sessions, panels, and case studies for real operational networks, is int= ended as a forum for technical discussions on topics including:=20 =20 =95 Voice over IP (VoIP) and Convergence =95 Multiservice Network Design and Planning =95 Virtual Private Networks (VPNs) =95 Routing: Unicast & Multicast=20 =95 Wireless Internet=20 =95 Next Generation Mobile Networks=20 =95 Quality of Service (QoS) =95 Network Security=20 =95 Network Processors=20 =95 Service Integration=20 =95 Operational Support Systems=20 =95 Network Survivability and Fault Management=20 =95 Internetworking IP and Optical Networks=20 ***EXCLUSIVE ALUMNI DISCOUNT*** We are pleased to extend a special alumni discount for the 2-day Internet= working 2004 Pass. Purchase the pass for $595.00, a $500.00 savings off t= he regular price. Visit for Priority Code and registration details.=20 We look forward to seeing you at the only end-to-end networking and commu= nications event. =20 Sincerely, The NetWorld+Interop Team http://www.interop.com/ --0-644159121-1080664238=:60438 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA27342 Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /DIV>
Internetworking 2004
May 13-14, 2004
Las Vegas Convention Cen= ter, Las Vegas, Nevada
http://www.caitr.org/internetworking04/index.htm
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /DIV>
 
Internetworking 2004, for the first time collocated with NetWorld+In= terop, aims to address some of the main issues of concern within IP netwo= rking and the Internet. This exclusive leading-edge technology program co= vers innovative solutions for Enterprises, Service Providers, networking = equipment manufacturers, government and others.
 
The Internetworking 2004 conference, comprised of comprehensive tech= nical sessions, panels, and case studies for real operational networks, i= s intended as a forum for technical discussions on topics including:
 
=95 Voice over IP (VoIP) and Convergence
=95 Multiservice Network= Design and Planning
=95 Virtual Private Networks (VPNs)
=95 Routin= g: Unicast & Multicast
=95 Wireless Internet
=95 Next Generat= ion Mobile Networks
=95 Quality of Service (QoS)
=95 Network Secur= ity
=95 Network Processors
=95 Service Integration
=95 Operat= ional Support Systems
=95 Network Survivability and Fault Management =
=95 Internetworking IP and Optical Networks
***EXCLUSIVE ALUMNI DISCOUNT***
We are pleased to extend a s= pecial alumni discount for the 2-day Internetworking 2004 Pass. Purchase = the pass for $595.00, a $500.00 savings off the regular price. Visit= <= http://www.caitr.org/internetworking04/registration.htm> for Prior= ity Code and registration details.

We look forward to seeing you at the only end-to-end networking = and communications event.
 
Sincerely,
The NetWorld+Interop Team
http://www.interop.com/
--0-644159121-1080664238=:60438-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 30 18:38:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03304 for ; Tue, 30 Mar 2004 18:38:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjB-0006Yx-QC for routing-discussion-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RNwZT7023962 for routing-discussion-archive@odin.ietf.org; Tue, 27 Jan 2004 18:58:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald58-0005M7-Ko; Tue, 27 Jan 2004 18:57:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al8lU-0006fp-Dv for routing-discussion@optimus.ietf.org; Mon, 26 Jan 2004 10:35:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09790 for ; Mon, 26 Jan 2004 10:35:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al8lR-0003M0-00 for routing-discussion@ietf.org; Mon, 26 Jan 2004 10:35:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al8kV-0003KE-00 for routing-discussion@ietf.org; Mon, 26 Jan 2004 10:34:04 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1Al8jd-0003Fl-00 for routing-discussion@ietf.org; Mon, 26 Jan 2004 10:33:09 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id i0QFWZ3K017852; Mon, 26 Jan 2004 07:32:35 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.10/Submit) id i0QFWYmY017851; Mon, 26 Jan 2004 07:32:34 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 26 Jan 2004 07:32:34 -0800 From: David Meyer To: George M Jones Cc: routing-discussion@ietf.org Subject: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure Message-ID: <20040126153234.GA17832@1-4-5.net> References: <1074875091.3052.104.camel@mm110847-2k.mitre.org> <20040123174343.GA17496@1-4-5.net> <1075117784.2914.33.camel@mm110847-2k.mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1075117784.2914.33.camel@mm110847-2k.mitre.org> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Mon, Jan 26, 2004 at 06:49:45AM -0500, George M Jones wrote: >> On Fri, 2004-01-23 at 12:43, David Meyer wrote: >> >> > >> >> > >> An earlier draft had a requirement for saving complete configuration >> > >> info, >> > >> including "hidden" and default values (e.g. if finger is enabled in >> > >> one release, but disabled in subsequent releases, the config should show >> > >> the settings even if they are set to the current default). I was >> > >> told this was impractical so it was removed. >> > >> > This turns out to be a major pain though, and it would be >> > "nice" if it would be possible. >> >> Seems like a reasonable candidate for reinstatement as a SHOULD. If >> there are business issues (support nightmare ?) or technical reasons it >> can't be done, that will leave wiggle-room while. It's on the to-do >> list, pending IESG feedback/action. Fine. >> > >> > 2.6.1 Support Rate Limiting >> > >> > >> > >> > @@@ I would imagine one would want a mechanism along the lines >> > >> > @@@ of GTSM here, so that you could protect the limited resource >> > >> > @@@ (whatever it may be) between the physical interface and the >> > >> > @@@ processor performing the management function(s). i.e., >> > >> rate-limiting >> > >> > @@@ may not be enough to stop an attacker who has deduced where >> > >> > @@@ the resource limitation (potential DoS) exists. >> > >> >> > >> The -00 draft included GTSM, but as it was not standardized, it was >> > >> moved >> > >> to the -info draft. See >> > >> > Will be RFC 3682 any day now. >> >> >> Excellent. >> >> I still think I'm not going to list it here. Earlier drafts (dating >> back to the pre-IETF versions) had a req that was essentialy RFC2644. >> That was dropped after it became an IETF draft because other docs in >> the same space covered it. Same thing will go for GTSM. Ok. >> > >> > 2.9.1 Ability to Accurately Count Filter Hits >> > >> > >> > >> > @@@ s/Accurately// >> > >> > @@@ i.e., as opposed to inaccurately count, I suppose >> > >> >> > >> Yes. The adverb was placed there deliberately as a result of >> > >> experience using filter counters that were not accurate. >> > >> > But isn't this like saying: No bugs in clocks? >> > >> > >> > 2.9.6 Filter Counters Must Be Accurate >> > >> > >> > >> > @@@ Again, as opposed to "inaccurate" filter counts? >> > >> >> > >> Yes. >> > >> > Again, who purposely builds inaccurate clocks for this >> > application (maybe someone does)? Wouldn't it (the >> > inaccurate counter) be a bug? i.e., isn't the requirement >> > just saying no bugs in the filter counters? >> >> >> 1 + 1 = 2. But there are major products out there that get it >> wrong (in the case of accurate filter counts). This needs to be said. Ok. >> > >> > @@@ also, it should be possible to log to a local device (say >> > >> > @@@ the console) >> > >> >> > >> This req had that sort of logging in view, as well as the possibility >> > >> of logging to local disk Let me know if there is wording that could >> > >> make it more clear >> > >> >> > >> > without hanging the box. >> > >> >> > >> What ? You want boxes to not crash ? Picky, picky :-) >> > >> > well, you know... >> >> Again, let me know if there is wording that you think would make this >> (need to log to the console) more explcit. >> >> >> >> > >> > 2.11.7 Logs Must Be Timestamped >> > >> > >> > >> > Requirement. The device MUST time-stamp all log messages. The >> > >> > time-stamp MUST be accurate to within a second or less. The >> > >> > time-stamp MUST include a timezone. >> > >> > >> > >> > @@@ and maybe it should be possible to turn timestamping off? >> > >> >> > >> Why ? >> > >> > Because I'm an operator and I have some (arbitrary) >> > reason want to, and a vendor wants to give it to me. That >> > shouldn't violate the BCP. In any event, that was my >> > thinking. >> >> Better ? >> >> By default, the device MUST time-stamp all log messages. The >> time-stamp MUST be accurate to within a second or less. The >> time-stamp MUST include a timezone. There MAY be a mechanism >> to disable the generation of timestamps. Sure. Thanks, Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 30 18:38:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03310 for ; Tue, 30 Mar 2004 18:38:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjB-0006WI-Jp for routing-discussion-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21JSNeS010484 for routing-discussion-archive@odin.ietf.org; Mon, 1 Mar 2004 14:28:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt57-0002gM-D3; Mon, 01 Mar 2004 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt55-0002fi-2b for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 14:27:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29080 for ; Mon, 1 Mar 2004 14:27:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4w-0004yt-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 14:27:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt3x-0004rZ-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 14:26:50 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Axt2y-0004g6-00; Mon, 01 Mar 2004 14:25:48 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i21JPI1K049498; Mon, 1 Mar 2004 11:25:18 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i21JPI65049495; Mon, 1 Mar 2004 11:25:18 -0800 (PST) Date: Mon, 1 Mar 2004 11:25:18 -0800 (PST) Message-Id: <200403011925.i21JPI65049495@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Lou Berger Cc: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <6.0.3.0.2.20040226143327.03467ea8@mail.labn.net> References: <8D260779A766FB4A9C1739A476F84FA401F799BA@daebe009.americas.nokia.com> <20040226081555.S11637@kummer.juniper.net> <6.0.3.0.2.20040226143327.03467ea8@mail.labn.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Lou Berger writes: > How about linking assignment expiration to expiration of the draft, > 3 months after? If the draft makes it to RFC, no issue, if the > draft takes a long time through the editors queue (which can take > ~1.5 years!), no issue, if the draft keeps changing, no issue. If > the draft dies, so does the assignment. Just make sure you don't try to reuse the same assigned number for something else in less than 10 years, if it ever gets into software... That is about the lifetime for 'deprecated' behaviour. While the ietf may be able to assume that an assigment "dies"... the decision may not be so simple in the real world. I would at least like to have a good idea of everyone that claims to have implemented said code point... Ask your self the question: How many networks are running TDP, which is a protocol that "died" in the ietf ? And would you like to reuse its code point ? I'm sure that people can come up w/ many other examples. Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 30 18:44:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04799 for ; Tue, 30 Mar 2004 18:44:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj5-0006a4-19 for routing-discussion-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21G7su1013100 for routing-discussion-archive@odin.ietf.org; Mon, 1 Mar 2004 11:07:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpw0-0002h9-Qi; Mon, 01 Mar 2004 11:06:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpvc-0002Mu-D7 for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 11:06:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13887 for ; Mon, 1 Mar 2004 11:05:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axphm-0007RK-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 10:51:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxpTT-0002dW-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 10:36:58 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Axp1j-0002xB-00; Mon, 01 Mar 2004 10:08:15 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2004 07:06:33 -0800 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i21F7gT4028601; Mon, 1 Mar 2004 10:07:42 -0500 (EST) Message-Id: <200403011507.i21F7gT4028601@rtp-core-1.cisco.com> To: Alex Zinin cc: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-reply-to: Your message of Sun, 29 Feb 2004 14:14:01 +0900. <32969213.20040229141401@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 01 Mar 2004 10:07:42 -0500 From: Eric Rosen X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , > I think you're missing the problem. It is not the size of the space. It is > the circular dependency between IANA allocation and STD action. I think there is only a practical problem if the space is small. If the space is large, the problem is easily solved by making a part of it available for FCFS assignment. In fact, it seems evident that it doesn't make any sense to put a large space in the "STD action" category, as there is no means to enforce it. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 30 18:45:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05031 for ; Tue, 30 Mar 2004 18:45:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj3-0006WI-My for routing-discussion-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i218MRCK024895 for routing-discussion-archive@odin.ietf.org; Mon, 1 Mar 2004 03:22:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigj-0006MJ-HF; Mon, 01 Mar 2004 03:22:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axift-0006Gw-R6 for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 03:21:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01043 for ; Mon, 1 Mar 2004 03:21:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiZK-0003wd-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:14:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiYM-0003pp-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:13:31 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxiXN-0003k7-00; Mon, 01 Mar 2004 03:12:29 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxiXN-000HP1-L4; Mon, 01 Mar 2004 08:12:29 +0000 Date: Mon, 1 Mar 2004 17:12:06 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <7834347198.20040301171206@psg.com> To: Lou Berger CC: Kireeti Kompella , Mukesh.Gupta@nokia.com, routing-discussion@ietf.org, Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> References: <6.0.3.0.2.20040226205121.0620ebf8@mo-ex1> <391404519.20040229142116@psg.com> <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Fair enough. -- Alex http://www.psg.com/~zinin/ Monday, March 1, 2004, 5:11:03 PM, Lou Berger wrote: > Alex, > okay, got found your message. I think this should work for most > cases. I'd suggest adding text that allows for >1 renewal with IESG > approval (in unusual circumstances). > Lou > At 12:21 AM 2/29/2004, Alex Zinin wrote: >>Lou, >> >> This would tie expiration to the author's ability to resubmit the draft, >> rather than to how the doc progresses. We could instead say that once >> the doc >> is submitted to the IESG, the codepoint is "frozen". >> >>-- >>Alex >>http://www.psg.com/~zinin/ >> >>Friday, February 27, 2004, 10:51:35 AM, Lou Berger wrote: >> >> > [resend] >> >> > How about linking assignment expiration to expiration of the draft, 3 >> > months after? If the draft makes it to RFC, no issue, if the draft >> takes a >> > long time through the editors queue (which can take ~1.5 years!), no >> issue, >> > if the draft keeps changing, no issue. If the draft dies, so does the >> > assignment. >> >> > Lou >> >> > At 11:24 AM 2/26/2004, Kireeti Kompella wrote: >> >>On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: >> >> >> >> > I finally got a chance to read the draft. The idea is good. I just >> >> > have a couple of questions/concerns about the expiry of the early >> >> > allocations.. >> >> > >> >> > - Do you think that "at most one renewal" would work in practice ? >> >> > There might be instances where there is a genuine need to keep >> >> > the early allocations for more than a year (Consider VRRPv3). >> >> > How do we deal with that situation ? If it is not possible to >> >> > renew the allocations more than once, do we need to ask for >> >> > early allocations with new numbers (which ofcourse will make >> >> > the situation worse) or we should just ask/let IANA to delete >> >> > and reassign those numbers (which would create problems as well). >> >> >> >>We mulled a bit over how many times the allocations should be renewed. >> >>The idea is that early allocation should NOT be requested as sson as >> >>an ID is written :-) One renewal may be a bit too aggressive, but >> >>it gives two years. Perhaps two renewals is okay, but no more (imho). >> >> >> >> > - The draft seems to put the responsibility of changing the status >> >> > of the early allocations on the WG chairs ? I know that our chairs >> >> > are very very responsible but I think, it will be a good idea to >> >> > have an alternate mechanism in place such that the early allocations >> >> > are marked deprecated/deleted automatically after a timeout. >> >> >> >>Automatic expiry was actually in the first version, but not everyone >> >>felt comfortable with that. We can (and should) review this, and >> >>perhaps make clearer what expiry means. >> >> >> >>Note that NOT adding to either IANA's or the IESG's workload is an >> >>explicit goal. Whatever we can do to avoid adding to WG chairs' >> >>workload is a 'nice-to-have' :-) >> >> >> >>Kireeti. >> >>------- >> >> >> >>_______________________________________________ >> >>routing-discussion mailing list >> >>routing-discussion@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 30 18:48:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05813 for ; Tue, 30 Mar 2004 18:48:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj1-0006WI-6N for routing-discussion-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i218MRO3024894 for routing-discussion-archive@odin.ietf.org; Mon, 1 Mar 2004 03:22:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigl-0006MS-Bp; Mon, 01 Mar 2004 03:22:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifu-0006H5-SZ for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 03:21:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01057 for ; Mon, 1 Mar 2004 03:21:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiZG-0003w3-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:14:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiYH-0003p2-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:13:26 -0500 Received: from hs22.order-vault.net ([65.18.133.138]) by ietf-mx with esmtp (Exim 4.12) id 1AxiXI-0003gA-00; Mon, 01 Mar 2004 03:12:25 -0500 Received: from lb-laptop.labn.net (labn.net [65.18.134.4]) (authenticated (0 bits)) by hs22.order-vault.net (8.11.6/8.11.6) with ESMTP id i218B6p01313; Mon, 1 Mar 2004 03:11:06 -0500 Message-Id: <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 01 Mar 2004 03:11:03 -0500 To: Alex Zinin From: Lou Berger Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Cc: Kireeti Kompella , Mukesh.Gupta@nokia.com, routing-discussion@ietf.org, In-Reply-To: <391404519.20040229142116@psg.com> References: <6.0.3.0.2.20040226205121.0620ebf8@mo-ex1> <391404519.20040229142116@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Alex, okay, got found your message. I think this should work for most cases. I'd suggest adding text that allows for >1 renewal with IESG approval (in unusual circumstances). Lou At 12:21 AM 2/29/2004, Alex Zinin wrote: >Lou, > > This would tie expiration to the author's ability to resubmit the draft, > rather than to how the doc progresses. We could instead say that once > the doc > is submitted to the IESG, the codepoint is "frozen". > >-- >Alex >http://www.psg.com/~zinin/ > >Friday, February 27, 2004, 10:51:35 AM, Lou Berger wrote: > > > [resend] > > > How about linking assignment expiration to expiration of the draft, 3 > > months after? If the draft makes it to RFC, no issue, if the draft > takes a > > long time through the editors queue (which can take ~1.5 years!), no > issue, > > if the draft keeps changing, no issue. If the draft dies, so does the > > assignment. > > > Lou > > > At 11:24 AM 2/26/2004, Kireeti Kompella wrote: > >>On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: > >> > >> > I finally got a chance to read the draft. The idea is good. I just > >> > have a couple of questions/concerns about the expiry of the early > >> > allocations.. > >> > > >> > - Do you think that "at most one renewal" would work in practice ? > >> > There might be instances where there is a genuine need to keep > >> > the early allocations for more than a year (Consider VRRPv3). > >> > How do we deal with that situation ? If it is not possible to > >> > renew the allocations more than once, do we need to ask for > >> > early allocations with new numbers (which ofcourse will make > >> > the situation worse) or we should just ask/let IANA to delete > >> > and reassign those numbers (which would create problems as well). > >> > >>We mulled a bit over how many times the allocations should be renewed. > >>The idea is that early allocation should NOT be requested as sson as > >>an ID is written :-) One renewal may be a bit too aggressive, but > >>it gives two years. Perhaps two renewals is okay, but no more (imho). > >> > >> > - The draft seems to put the responsibility of changing the status > >> > of the early allocations on the WG chairs ? I know that our chairs > >> > are very very responsible but I think, it will be a good idea to > >> > have an alternate mechanism in place such that the early allocations > >> > are marked deprecated/deleted automatically after a timeout. > >> > >>Automatic expiry was actually in the first version, but not everyone > >>felt comfortable with that. We can (and should) review this, and > >>perhaps make clearer what expiry means. > >> > >>Note that NOT adding to either IANA's or the IESG's workload is an > >>explicit goal. Whatever we can do to avoid adding to WG chairs' > >>workload is a 'nice-to-have' :-) > >> > >>Kireeti. > >>------- > >> > >>_______________________________________________ > >>routing-discussion mailing list > >>routing-discussion@ietf.org > >>https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 30 18:50:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06326 for ; Tue, 30 Mar 2004 18:50:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riz-0006ZK-Ru for routing-discussion-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i218MROj024892 for routing-discussion-archive@odin.ietf.org; Mon, 1 Mar 2004 03:22:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigf-0006Kt-Cy; Mon, 01 Mar 2004 03:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifq-0006GO-Bt for routing-discussion@optimus.ietf.org; Mon, 01 Mar 2004 03:21:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01004 for ; Mon, 1 Mar 2004 03:21:13 -0500 (EST) From: kireeti@juniper.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxibF-0004AF-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:16:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiaO-00043l-00 for routing-discussion@ietf.org; Mon, 01 Mar 2004 03:15:36 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxiZc-0003sb-00; Mon, 01 Mar 2004 03:14:48 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i218EIPg027691; Mon, 1 Mar 2004 00:14:18 -0800 (PST) (envelope-from kireeti@kummer.juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) id i218EIIa027690; Mon, 1 Mar 2004 00:14:18 -0800 (PST) Date: Mon, 1 Mar 2004 00:14:18 -0800 (PST) Message-Id: <200403010814.i218EIIa027690@kummer.juniper.net> To: lberger@labn.net, zinin@psg.com Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Cc: kireeti@juniper.net, Mukesh.Gupta@nokia.com, routing-discussion@ietf.org, rtg-dir@ietf.org In-Reply-To: <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , > okay, got found your message. I think this should work for most > cases. I'd suggest adding text that allows for >1 renewal with IESG > approval (in unusual circumstances). Okay, unless I hear strong arguments to the contrary, I will add >1 renewals to the doc. Kireeti. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 30 18:51:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06722 for ; Tue, 30 Mar 2004 18:51:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riy-0006ZK-CA for routing-discussion-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HFfIqG010451 for routing-discussion-archive@odin.ietf.org; Tue, 17 Feb 2004 10:41:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7IV-0001jV-LO; Tue, 17 Feb 2004 10:38:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Hg-0001Ld-Hq for routing-discussion@optimus.ietf.org; Tue, 17 Feb 2004 10:37:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05852 for ; Tue, 17 Feb 2004 10:37:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7He-00016a-00 for routing-discussion@ietf.org; Tue, 17 Feb 2004 10:37:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7Gl-00012h-00 for routing-discussion@ietf.org; Tue, 17 Feb 2004 10:36:19 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1At7Fy-0000yj-00; Tue, 17 Feb 2004 10:35:30 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1At7Fx-000512-8B; Tue, 17 Feb 2004 15:35:29 +0000 Date: Tue, 17 Feb 2004 07:35:03 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <60347214007.20040217073503@psg.com> To: routing-discussion@ietf.org CC: rtg-dir@ietf.org Subject: Fwd: WG Review: Routing Area Working Group (rtgwg) In-Reply-To: <200402171438.JAA00108@ietf.org> References: <200402171438.JAA00108@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- As the charter says, we would like to create this "generic" routing WG to give home to smaller work items that don't fit in existing WGs and are not big enough for their own ones, such as BTSH, or draft-hsmit-mpls-igp-spf-01.txt. Transport area has some positive experience with TSVWG, which RTGWG was modeled after. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: The IESG To: Cc: Date: Tuesday, February 17, 2004, 6:38:43 AM Subject: WG Review: Routing Area Working Group (rtgwg) ===8<==============Original message text=============== A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by February 19. Routing Area Working Group (rtgwg) ---------------------------------- Current Status: Proposed Working Group Description of Working Group: The Routing area receives occasional proposals for the development and publication of RFCs dealing with routing topics, but for which the required work does not rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and a single BOF would not provide the time to ensure a mature proposal. The rtgwg will serve as the forum for developing these types of proposals. The rtgwg mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion. The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose. ===8<===========End of original message text=========== _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Mar 30 18:57:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08309 for ; Tue, 30 Mar 2004 18:57:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riv-0006Yx-23 for routing-discussion-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFdIAv002939 for routing-discussion-archive@odin.ietf.org; Sat, 20 Sep 2003 11:39:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0joQ-0000Bg-DC; Sat, 20 Sep 2003 11:38:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0idG-0006f7-LH for routing-discussion@optimus.ietf.org; Sat, 20 Sep 2003 10:22:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25415 for ; Fri, 19 Sep 2003 18:58:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0UDL-0002aW-00 for routing-discussion@ietf.org; Fri, 19 Sep 2003 18:58:59 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1A0UDA-0002aH-00 for routing-discussion@ietf.org; Fri, 19 Sep 2003 18:58:48 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.22) id 1A0UCj-000JnT-3A for routing-discussion@ietf.org; Fri, 19 Sep 2003 22:58:21 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1096485395.20030919155731@psg.com> To: routing-discussion@ietf.org Subject: Review Request: draft-turk-bgp-dos (Configuring BGP to Block Denial-of-Service Attacks) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 15:57:31 -0700 Content-Transfer-Encoding: 7bit Folks, The RFC Editor received a request to publish draft-turk-bgp-dos-04.txt as an Informational RFC. Below is the Abstract from the draft: This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black- holing can be applied on a selection of routers rather than all BGP- speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. The document is available at: http://www.ietf.org/internet-drafts/draft-turk-bgp-dos-04.txt The IESG would like to solicit comments on this document to ensure sufficient community review. Please read the document and indicate if you support it going forward by October 3rd, 2003. This message will be forwarded as an FYI to certain individual WGs and directorates. However, please send your comments to routing-discussion@ietf.org or directly to me. -- Alex Zinin IETF RTG Area co-Director http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 31 12:53:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04187 for ; Wed, 31 Mar 2004 12:53:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jtd-0006eH-DA; Wed, 31 Mar 2004 12:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70dg-0002Td-VC for routing-discussion@optimus.ietf.org; Fri, 26 Mar 2004 18:21:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25265 for ; Fri, 26 Mar 2004 18:21:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B70dd-0004UF-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 18:21:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B70cf-0004RB-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 18:20:21 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B70c6-0004OT-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 18:19:46 -0500 Received: (qmail 69117 invoked from network); 26 Mar 2004 23:26:29 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 26 Mar 2004 23:26:29 -0000 Message-ID: <4064BB33.6010609@necom830.hpcl.titech.ac.jp> Date: Sat, 27 Mar 2004 08:22:27 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Jon Crowcroft CC: Toerless Eckert , Rick Boivie , shep@shepfarm.com, IMAI Yuji , dino@procket.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jon Crowcroft wrote: > build it (and build it right) and they will come... That's the point. All the standard track multicast protocols are built wrongly, ignoring the scalability property of multicast on the number of routing table entries. Dino is guilty. So are those who are for SSM. Multicast does not scale in a way they dreamed. Masataka Ohta PS Another major wrongness is in IGMP, which should be independent from multicast routing protocols but is revised as new multicast routing protocols are invented. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 31 12:54:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04221 for ; Wed, 31 Mar 2004 12:54:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ju5-0006gw-K8 for routing-discussion-archive@odin.ietf.org; Wed, 31 Mar 2004 12:53:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VHrTPe025692 for routing-discussion-archive@odin.ietf.org; Wed, 31 Mar 2004 12:53:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jtc-0006e9-RD; Wed, 31 Mar 2004 12:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ynJ-0005Y6-6Z for routing-discussion@optimus.ietf.org; Fri, 26 Mar 2004 16:23:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16025 for ; Fri, 26 Mar 2004 16:23:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ynH-0000tb-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 16:23:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ylC-0000Vo-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 16:21:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B6yjm-0000CD-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 16:19:34 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 26 Mar 2004 13:19:37 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2QLJJew023119; Fri, 26 Mar 2004 13:19:19 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA17841; Fri, 26 Mar 2004 13:19:18 -0800 (PST) Date: Fri, 26 Mar 2004 13:19:18 -0800 From: Toerless Eckert To: Jon Crowcroft Cc: Rick Boivie , shep@shepfarm.com, IMAI Yuji , dino@procket.com, mohta@necom830.hpcl.titech.ac.jp, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040326211918.GY2179@cisco.com> References: <20040326170244.GR2179@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Fri, Mar 26, 2004 at 05:28:52PM +0000, Jon Crowcroft wrote: > > you're missing the fact that there was no business for unicast IP - > the web came 10 years after No i am not missing that. See below. > anyhow engineers ... who work in research ... > dont do business cases > - last time they did they did a load of .com crap - > we are tryting to engineer varioius types of network support for scalable > group communication - there is NO point in discsussing why we shouldnt do [... skipping a few MB ranting ...] > creating lists for laughing at people who revist the same wrong arguments on IETF lists year after year:) > > John, i am not disagreeing with anything you say, i just wanted to mention the point that we do not live in a world anymore where the internet solution suite is grown solely through non-commercial interest. Yes, i would love to have the good old pre 1995 times back, because then we would be able to get multicast deployed much more easily. Short of going back in time we have to include the problem of how to create sufficient business incentive for commercial adoption into a plan to progress technology beyond the realms of research. And my only point about that piece was that i think there's so far way too little commercial provisioning of video-conference facilities... but that i think there's actually more pickup of that due to VoIP standardization, and maybe we will see sufficient demand for multi-party (video) conferencing within a few years to justify moving scalability solutions for the problem space into the network layer. Right now i would not hold my breath for this. And of course i completely agree with the fact that small group multicast is a fascinating research topic, and i would like to see more research based prototyping and deployment of this. I just wanted to point out that mboned is not necessarily the best target audience for such activity. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 31 13:08:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05289 for ; Wed, 31 Mar 2004 13:08:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8k8O-0008MK-T9; Wed, 31 Mar 2004 13:08:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8k7c-0008Bf-B4 for routing-discussion@optimus.ietf.org; Wed, 31 Mar 2004 13:07:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05220 for ; Wed, 31 Mar 2004 13:07:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8k7a-0000a0-00 for routing-discussion@ietf.org; Wed, 31 Mar 2004 13:07:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8k6p-0000WF-00 for routing-discussion@ietf.org; Wed, 31 Mar 2004 13:06:39 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx with esmtp (Exim 4.12) id 1B8k5w-0000OO-00 for routing-discussion@ietf.org; Wed, 31 Mar 2004 13:05:44 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA00761; Wed, 31 Mar 2004 12:04:29 -0600 (CST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id MAA17029; Wed, 31 Mar 2004 12:04:29 -0600 (CST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i2VI42E14958; Wed, 31 Mar 2004 10:04:02 -0800 (PST) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Wed, 31 Mar 2004 13:03:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: mboned: BGMP & DVMRP status Q. Date: Wed, 31 Mar 2004 13:03:26 -0500 Message-ID: Thread-Topic: mboned: BGMP & DVMRP status Q. Thread-Index: AcQXSZOKv1WFvQ5ATLKhQ5feiiMOtwAAFBjg From: "Manfredi, Albert E" To: "Masataka Ohta" Cc: , X-OriginalArrivalTime: 31 Mar 2004 18:03:27.0350 (UTC) FILETIME=[7785E960:01C4174A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Masataka Ohta wrote: > Another major wrongness is in IGMP, which should be independent > from multicast routing protocols but is revised as new multicast > routing protocols are invented. But IGMP is independent. I guess you're referring to v3, which adds the = source address filtering capability. But that has nothing to do with = routing. It has to do with providing the necessary extra specificity = when SSM is available. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 31 13:08:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05305 for ; Wed, 31 Mar 2004 13:08:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8k8c-0008Tc-Pi for routing-discussion-archive@odin.ietf.org; Wed, 31 Mar 2004 13:08:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VI8UpK032505 for routing-discussion-archive@odin.ietf.org; Wed, 31 Mar 2004 13:08:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8k8O-0008MK-T9; Wed, 31 Mar 2004 13:08:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8k7c-0008Bf-B4 for routing-discussion@optimus.ietf.org; Wed, 31 Mar 2004 13:07:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05220 for ; Wed, 31 Mar 2004 13:07:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8k7a-0000a0-00 for routing-discussion@ietf.org; Wed, 31 Mar 2004 13:07:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8k6p-0000WF-00 for routing-discussion@ietf.org; Wed, 31 Mar 2004 13:06:39 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx with esmtp (Exim 4.12) id 1B8k5w-0000OO-00 for routing-discussion@ietf.org; Wed, 31 Mar 2004 13:05:44 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA00761; Wed, 31 Mar 2004 12:04:29 -0600 (CST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id MAA17029; Wed, 31 Mar 2004 12:04:29 -0600 (CST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i2VI42E14958; Wed, 31 Mar 2004 10:04:02 -0800 (PST) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Wed, 31 Mar 2004 13:03:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: mboned: BGMP & DVMRP status Q. Date: Wed, 31 Mar 2004 13:03:26 -0500 Message-ID: Thread-Topic: mboned: BGMP & DVMRP status Q. Thread-Index: AcQXSZOKv1WFvQ5ATLKhQ5feiiMOtwAAFBjg From: "Manfredi, Albert E" To: "Masataka Ohta" Cc: , X-OriginalArrivalTime: 31 Mar 2004 18:03:27.0350 (UTC) FILETIME=[7785E960:01C4174A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Masataka Ohta wrote: > Another major wrongness is in IGMP, which should be independent > from multicast routing protocols but is revised as new multicast > routing protocols are invented. But IGMP is independent. I guess you're referring to v3, which adds the = source address filtering capability. But that has nothing to do with = routing. It has to do with providing the necessary extra specificity = when SSM is available. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Mar 31 13:39:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04220 for ; Wed, 31 Mar 2004 12:54:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ju5-0006hh-Mf for routing-discussion-archive@odin.ietf.org; Wed, 31 Mar 2004 12:53:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VHrT71025693 for routing-discussion-archive@odin.ietf.org; Wed, 31 Mar 2004 12:53:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jtd-0006eH-DA; Wed, 31 Mar 2004 12:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B70dg-0002Td-VC for routing-discussion@optimus.ietf.org; Fri, 26 Mar 2004 18:21:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25265 for ; Fri, 26 Mar 2004 18:21:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B70dd-0004UF-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 18:21:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B70cf-0004RB-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 18:20:21 -0500 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1B70c6-0004OT-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 18:19:46 -0500 Received: (qmail 69117 invoked from network); 26 Mar 2004 23:26:29 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 26 Mar 2004 23:26:29 -0000 Message-ID: <4064BB33.6010609@necom830.hpcl.titech.ac.jp> Date: Sat, 27 Mar 2004 08:22:27 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Jon Crowcroft CC: Toerless Eckert , Rick Boivie , shep@shepfarm.com, IMAI Yuji , dino@procket.com, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jon Crowcroft wrote: > build it (and build it right) and they will come... That's the point. All the standard track multicast protocols are built wrongly, ignoring the scalability property of multicast on the number of routing table entries. Dino is guilty. So are those who are for SSM. Multicast does not scale in a way they dreamed. Masataka Ohta PS Another major wrongness is in IGMP, which should be independent from multicast routing protocols but is revised as new multicast routing protocols are invented. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 31 13:39:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04189 for ; Wed, 31 Mar 2004 12:53:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8jtc-0006e9-RD; Wed, 31 Mar 2004 12:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ynJ-0005Y6-6Z for routing-discussion@optimus.ietf.org; Fri, 26 Mar 2004 16:23:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16025 for ; Fri, 26 Mar 2004 16:23:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ynH-0000tb-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 16:23:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ylC-0000Vo-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 16:21:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1B6yjm-0000CD-00 for routing-discussion@ietf.org; Fri, 26 Mar 2004 16:19:34 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 26 Mar 2004 13:19:37 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i2QLJJew023119; Fri, 26 Mar 2004 13:19:19 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA17841; Fri, 26 Mar 2004 13:19:18 -0800 (PST) Date: Fri, 26 Mar 2004 13:19:18 -0800 From: Toerless Eckert To: Jon Crowcroft Cc: Rick Boivie , shep@shepfarm.com, IMAI Yuji , dino@procket.com, mohta@necom830.hpcl.titech.ac.jp, dmm@1-4-5.net, routing-discussion@ietf.org, mboned@lists.uoregon.edu, zinin@psg.com, fenner@research.att.com Subject: Re: mboned: BGMP & DVMRP status Q. Message-ID: <20040326211918.GY2179@cisco.com> References: <20040326170244.GR2179@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , On Fri, Mar 26, 2004 at 05:28:52PM +0000, Jon Crowcroft wrote: > > you're missing the fact that there was no business for unicast IP - > the web came 10 years after No i am not missing that. See below. > anyhow engineers ... who work in research ... > dont do business cases > - last time they did they did a load of .com crap - > we are tryting to engineer varioius types of network support for scalable > group communication - there is NO point in discsussing why we shouldnt do [... skipping a few MB ranting ...] > creating lists for laughing at people who revist the same wrong arguments on IETF lists year after year:) > > John, i am not disagreeing with anything you say, i just wanted to mention the point that we do not live in a world anymore where the internet solution suite is grown solely through non-commercial interest. Yes, i would love to have the good old pre 1995 times back, because then we would be able to get multicast deployed much more easily. Short of going back in time we have to include the problem of how to create sufficient business incentive for commercial adoption into a plan to progress technology beyond the realms of research. And my only point about that piece was that i think there's so far way too little commercial provisioning of video-conference facilities... but that i think there's actually more pickup of that due to VoIP standardization, and maybe we will see sufficient demand for multi-party (video) conferencing within a few years to justify moving scalability solutions for the problem space into the network layer. Right now i would not hold my breath for this. And of course i completely agree with the fact that small group multicast is a fascinating research topic, and i would like to see more research based prototyping and deployment of this. I just wanted to point out that mboned is not necessarily the best target audience for such activity. Cheers Toerless _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion