From owner-idmr@cs.ucl.ac.uk Mon Jul 2 15:39:41 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17710 for ; Mon, 2 Jul 2001 15:39:40 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 2 Jul 2001 19:41:34 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 2 Jul 2001 18:50:19 +0100 Received: from carbon.btinternet.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 2 Jul 2001 18:50:17 +0100 Received: from [213.122.196.68] (helo=[10.0.1.2]) by carbon.btinternet.com with esmtp (Exim 3.22 #9) id 15H7pw-0005UI-00 for idmr@cs.ucl.ac.uk; Mon, 02 Jul 2001 18:50:17 +0100 User-Agent: Microsoft-Entourage/9.0.1.3108 Date: Mon, 02 Jul 2001 18:50:13 +0100 Subject: Multicast Fragmentation From: Alastair Matthews To: idmr Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Can anyone point me in the direction of references regarding Multicast and Fragmentation? It is apparent from the wording in numerous documents that Multicast packets should be sized to avoid fragmentation. RFC 1812 Routing Requirements for IP Version 4 Routers makes it clear the Multicast datagrams should be fragmented There are obvious problems with reassembly particularly with multiple sources, and router load. Any pointers to documents discussing this, or thoughts on the subject would be appreciated. Thanks in advance Alastair From owner-idmr@cs.ucl.ac.uk Thu Jul 5 08:54:51 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10571 for ; Thu, 5 Jul 2001 08:54:51 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 5 Jul 2001 12:55:18 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 5 Jul 2001 11:49:20 +0100 Received: from missouri.yamato.ibm.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 5 Jul 2001 11:49:08 +0100 Received: from kyoto.yamato.ibm.com (kyoto.yamato.ibm.com [9.68.27.152]) by missouri.yamato.ibm.com (8.11.4/8.11.2) with ESMTP id f65An56101722 for ; Thu, 5 Jul 2001 19:49:05 +0900 Received: from localhost (reno.ip.yamato.ibm.com [9.68.0.26]) by kyoto.yamato.ibm.com (8.11.1/3.7W) with ESMTP id f65An47123542 for ; Thu, 5 Jul 2001 19:49:04 +0900 To: idmr@cs.ucl.ac.uk Subject: question for igmpv3 and its api draft. X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010705194141N.asaeda@yamato.ibm.com> Date: Thu, 05 Jul 2001 19:41:41 +0900 From: Hitoshi Asaeda X-Dispatcher: imput version 20000228(IM140) Lines: 37 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit I have several question and comments for IGMPv3 and its API's draft. First, let's see an example. One application calls IPMulticastListen as socket s1: ( i, m, INCLUDE, {a, b, c} ), then kerel sends ALLOW ( i, m, {a, b, c} ). After this, another application calls the one as socket s2: ( i, m, EXCLUDE, {c} ). At this time, kernel sends TO_EX ( i, m, {} ), since the interface state becomes EXCLUDE ( i, m, {} )? Right? If so, it seems strange that we would request to receive the group packet from every source to upper router when we newly request EXCLUDE filter. Is it Okay? And this is a tiny question. Why did you name ALLOW_*NEW*_SOURCES and BLOCK_*OLD*_SOURCES? When source list is changed from the state of EXCLUDE to EXCLUDE, we may make a BLOCK report for *new* sources, like BLOCK_*NEW*_SOURCES. I mean we had better not specify *NEW* or *OLD* for these report types. Just ALLOW_SOURCES and BLOCK_SOURCES are reasonable for me. This may also be a tiny question.:) MSF draft defines filter_mode and number_of_sources whose sizes are u_int32_t. Why they are 32bit long? Especially, igmpv3's draft says number_of_sources in igmp header is 16bit long. These should be same values, I feel. Also, 8bit long filter_mode is enough. Is their any reason to define these values? Thanks. -- Hitoshi Asaeda From owner-idmr@cs.ucl.ac.uk Thu Jul 5 11:41:23 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17001 for ; Thu, 5 Jul 2001 11:41:22 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 5 Jul 2001 15:39:45 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 5 Jul 2001 15:39:39 +0100 Received: from net013s.hetnet.nl by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 5 Jul 2001 15:39:40 +0100 Received: from wdegraafdp866 ([209.131.52.217]) by hetnet.nl with Microsoft SMTPSVC(5.5.1877.687.68); Thu, 5 Jul 2001 16:38:09 +0200 Message-ID: <001801c10560$4f1aa4b0$d93483d1@inktomi.com> From: Wilbert de Graaf To: Hitoshi Asaeda Cc: idmr References: <20010705194141N.asaeda@yamato.ibm.com> Subject: Re: question for igmpv3 and its api draft. Date: Thu, 5 Jul 2001 07:39:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit > First, let's see an example. > One application calls IPMulticastListen as > socket s1: ( i, m, INCLUDE, {a, b, c} ), > then kerel sends > ALLOW ( i, m, {a, b, c} ). > After this, another application calls the one as > socket s2: ( i, m, EXCLUDE, {c} ). > At this time, kernel sends > TO_EX ( i, m, {} ), > since the interface state becomes EXCLUDE ( i, m, {} )? Right? > If so, it seems strange that we would request to receive the group > packet from every source to upper router when we newly request EXCLUDE > filter. > Is it Okay? The socket s1 won't necessarily get all packets from all sources, since the OS or socket library can filter the packets it delivers to the socket. Is this what you mean ? > And this is a tiny question. > Why did you name ALLOW_*NEW*_SOURCES and BLOCK_*OLD*_SOURCES? > When source list is changed from the state of EXCLUDE to EXCLUDE, we > may make a BLOCK report for *new* sources, like BLOCK_*NEW*_SOURCES. > I mean we had better not specify *NEW* or *OLD* for these report > types. Just ALLOW_SOURCES and BLOCK_SOURCES are reasonable for me. If you look at it from the 'age' of the source probably yes. But if you look at it from the host sending the packets they're always new I guess. In your example even a 'new' source used to be an 'allowed' source when it's not in the exclude list. So you can argue that makes it an old (allowed) source. > This may also be a tiny question.:) > MSF draft defines filter_mode and number_of_sources whose sizes are > u_int32_t. > Why they are 32bit long? > Especially, igmpv3's draft says number_of_sources in igmp header is > 16bit long. > These should be same values, I feel. Because a host isn't limited to send only one IGMP record per group, but could send multiple records in multiple messages, they don't have to be the same. Example: socket s: ( i, m, BLOCK, {a, b, c} ) msg 1: BLOCK { i, m, {a, b} } msg 2: BLOCK { i, m, {c} } > Also, 8bit long filter_mode is enough. > Is their any reason to define these values? Yes & don't know. Wilbert From owner-idmr@cs.ucl.ac.uk Fri Jul 6 01:46:54 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10001 for ; Fri, 6 Jul 2001 01:46:53 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 6 Jul 2001 06:02:09 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 6 Jul 2001 06:02:03 +0100 Received: from mail.producegate.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 6 Jul 2001 06:02:04 +0100 Received: from localhost (sh.producegate.net [211.123.211.167]) by producegate.net (8.11.4/8.11.0) with ESMTP id f6651wi21231 for ; Fri, 6 Jul 2001 14:01:58 +0900 (JST) To: idmr@cs.ucl.ac.uk Subject: Re: question for igmpv3 and its api draft. In-Reply-To: <001801c10560$4f1aa4b0$d93483d1@inktomi.com> References: <20010705194141N.asaeda@yamato.ibm.com> <001801c10560$4f1aa4b0$d93483d1@inktomi.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010706140158L.asaeda@producegate.net> Date: Fri, 06 Jul 2001 14:01:58 +0900 From: Hitoshi Asaeda X-Dispatcher: imput version 20000228(IM140) Lines: 71 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit > > One application calls IPMulticastListen as > > socket s1: ( i, m, INCLUDE, {a, b, c} ), > > then kerel sends > > ALLOW ( i, m, {a, b, c} ). > > After this, another application calls the one as > > socket s2: ( i, m, EXCLUDE, {c} ). > > At this time, kernel sends > > TO_EX ( i, m, {} ), > > since the interface state becomes EXCLUDE ( i, m, {} )? Right? > > If so, it seems strange that we would request to receive the group > > packet from every source to upper router when we newly request EXCLUDE > > filter. > > Is it Okay? > > The socket s1 won't necessarily get all packets from all sources, since the > OS or socket library can filter the packets it delivers to the socket. Is > this what you mean ? I doubt there is some strange situation when the node behaves based on the I-D. I'll show more datail example. One node sequentially has moved following filter modes for group m. 0. IN() as initial state. 1. IN(a,b,c) by application-1. node filter becomes IN(a,b,c). this triggers sending ALW(a,b,c). 2. EX(c) by application-2. node filter becomes EX(). this triggers sending TO_EX() (hereafter, let's call pattern-1), or nothing (hereafter, pattern-2) ? So, now, I may say two patterns for 3rd step. 3. IN(d) by application-3. node filter still be EX(). pattern-1. if last change sends TO_EX(), this *would* trigger sending nothing. pattern-2. if last change sends nothing, this *should* trigger sending ALW(d). In my understanding, it seems that I-D tells pattern-1, although I-D says; If the computed source list for either an ALLOW or a BLOCK record is empty, that record is omitted from the State-Change report. This is because this statement doesn't say about TO_IN/TO_EX here. So, we may be able to think "sending TO_EX with NULL source list" at this situation may be the answer. However, if we select pattern-1 with sending TO_EX(), at the moment 2nd step, the node is ready to receive every source's data (i.e., no source filter). This is strange because application-2 just requests not to receive the data from source-c. Neverthless, oppositely, if we select pattern-2 at 2nd step, we should send ALW(d) at 3rd step. But this report is not made along I-D's calculation rules. This is my thought. > > Why did you name ALLOW_*NEW*_SOURCES and BLOCK_*OLD*_SOURCES? > > When source list is changed from the state of EXCLUDE to EXCLUDE, we > > may make a BLOCK report for *new* sources, like BLOCK_*NEW*_SOURCES. > > I mean we had better not specify *NEW* or *OLD* for these report > > types. Just ALLOW_SOURCES and BLOCK_SOURCES are reasonable for me. > > If you look at it from the 'age' of the source probably yes. But if you look > at it from the host sending the packets they're always new I guess. In your > example even a 'new' source used to be an 'allowed' source when it's not in > the exclude list. So you can argue that makes it an old (allowed) source. So, you also mean specifying old/new is no meaning, don't you? Thanks. -- Hitoshi Asaeda From owner-idmr@cs.ucl.ac.uk Sun Jul 8 15:21:05 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15016 for ; Sun, 8 Jul 2001 15:21:04 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sun, 8 Jul 2001 18:43:34 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sun, 8 Jul 2001 18:43:29 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Sun, 8 Jul 2001 18:43:30 +0100 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 466521E437 for ; Sun, 8 Jul 2001 13:43:28 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA14883 for ; Sun, 8 Jul 2001 13:43:28 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA25191; Sun, 8 Jul 2001 10:43:27 -0700 (PDT) Message-Id: <200107081743.KAA25191@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idmr@cs.ucl.ac.uk Subject: No IDMR meeting at London IETF Date: Sun, 8 Jul 2001 10:43:27 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Dear IDMR, I don't plan to request a meeting session for IDMR at the London IETF. We do plan to have a MAGMA (Multicast/Anycast Group Membership) BOF; MAGMA a planned working group that will take over IGMP, MLD, etc. The plan is for IDMR to see IGMPv3, IGMP Router Discovery, and DVMRPv3 to Proposed Standard and then disband. Bill From owner-idmr@cs.ucl.ac.uk Tue Jul 10 18:26:01 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27436 for ; Tue, 10 Jul 2001 18:26:01 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 10 Jul 2001 22:45:13 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 10 Jul 2001 22:45:08 +0100 Received: from sj-msg-core-2.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 10 Jul 2001 22:45:10 +0100 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6ALjJl08496; Tue, 10 Jul 2001 14:45:19 -0700 (PDT) Received: from cisco.com (dhcp-171-69-127-182.cisco.com [171.69.127.182]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AMI06088 (AUTH jmeylor); Tue, 10 Jul 2001 14:45:06 -0700 (PDT) Message-ID: <3B4B777D.A7C7F7E3@cisco.com> Date: Tue, 10 Jul 2001 14:45:33 -0700 From: John Meylor X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: idmr@cs.ucl.ac.uk Subject: Re: No IDMR meeting at London IETF References: <200107081743.KAA25191@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Bill Fenner wrote: > > Dear IDMR, > > I don't plan to request a meeting session for IDMR at the London IETF. > We do plan to have a MAGMA (Multicast/Anycast Group Membership) BOF; > MAGMA a planned working group that will take over IGMP, MLD, etc. The > plan is for IDMR to see IGMPv3, IGMP Router Discovery, and DVMRPv3 > to Proposed Standard and then disband. Bill, Did you know yet the time for the MAGMA BoF? Its not on: http://www.ietf.org/meetings/agenda_51.txt John > > Bill From owner-idmr@cs.ucl.ac.uk Tue Jul 10 18:27:01 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27464 for ; Tue, 10 Jul 2001 18:27:01 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 10 Jul 2001 22:47:09 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 10 Jul 2001 22:47:01 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 10 Jul 2001 22:47:03 +0100 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 19F5F4D3B3; Tue, 10 Jul 2001 17:47:02 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA09156; Tue, 10 Jul 2001 17:47:01 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA24722; Tue, 10 Jul 2001 14:47:00 -0700 (PDT) Message-Id: <200107102147.OAA24722@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jmeylor@cisco.com Subject: Re: No IDMR meeting at London IETF Cc: idmr@cs.ucl.ac.uk References: <200107081743.KAA25191@windsor.research.att.com> <3B4B777D.A7C7F7E3@cisco.com> Date: Tue, 10 Jul 2001 14:47:00 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >Did you know yet the time for the MAGMA BoF? Not yet; when we get assigned a time I will forward it to this list. Bill From owner-idmr@cs.ucl.ac.uk Mon Jul 16 16:04:47 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29518 for ; Mon, 16 Jul 2001 16:04:47 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 16 Jul 2001 20:13:26 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 16 Jul 2001 20:13:20 +0100 Received: from h157s242a129n47.user.nortelnetworks.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 16 Jul 2001 20:13:18 +0100 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6GJCw927218 for ; Mon, 16 Jul 2001 15:12:58 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Mon, 16 Jul 2001 15:12:56 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3X1HX34F; Mon, 16 Jul 2001 15:12:53 -0400 Received: from nortelnetworks.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3NTP665N; Mon, 16 Jul 2001 15:12:52 -0400 Message-ID: <3B533CA4.70EF6504@nortelnetworks.com> Date: Mon, 16 Jul 2001 15:12:36 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Brian Haberman Reply-To: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk Subject: Re: No IDMR meeting at London IETF References: <200107081743.KAA25191@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit All, Currently, the MAGMA BoF is scheduled for Friday morning. I am in the process of trying to get that changed. :) MAGMA is still being reviewed by the IESG, but the mailing list is up and running. Info on the mailing list and other red-tape items can be found at http://www.innovationslab.net/magma. Thanks, Brian & Bill (your friendly neighborhood MAGMA co-chairs) Bill Fenner wrote: > > Dear IDMR, > > I don't plan to request a meeting session for IDMR at the London IETF. > We do plan to have a MAGMA (Multicast/Anycast Group Membership) BOF; > MAGMA a planned working group that will take over IGMP, MLD, etc. The > plan is for IDMR to see IGMPv3, IGMP Router Discovery, and DVMRPv3 > to Proposed Standard and then disband. > > Bill From owner-idmr@cs.ucl.ac.uk Tue Jul 17 14:55:45 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16236 for ; Tue, 17 Jul 2001 14:55:45 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 17 Jul 2001 19:00:11 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 17 Jul 2001 18:28:04 +0100 Received: from H-135-207-10-122.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 17 Jul 2001 18:28:00 +0100 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Message-Id: Date: Tue, 17 Jul 2001 13:25:25 -0400 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-idmr@cs.ucl.ac.uk Tue Jul 17 18:07:06 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25160 for ; Tue, 17 Jul 2001 18:07:05 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 17 Jul 2001 22:58:49 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 17 Jul 2001 21:31:07 +0100 Received: from shepfarm.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 17 Jul 2001 21:31:05 +0100 Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by shepfarm.com (8.11.3/8.11.3) with ESMTP id f6HLNOC03006; Tue, 17 Jul 2001 14:23:24 -0700 Date: Tue, 17 Jul 2001 14:23:24 -0700 (PDT) From: shep To: Bill Fenner cc: idmr@cs.ucl.ac.uk, magma@innovationslab.net Subject: Re: MAGMA BOF at London IETF: Monday 0900-1130 In-Reply-To: <200107172028.NAA27678@windsor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Thanks Bill!! Much better... Greg On Tue, 17 Jul 2001, Bill Fenner wrote: > > Dear IDMR and MAGMA-ers, > > The MAGMA BOF will meet in London at 0900 on Monday (this time > updated from 0900 Friday, hopefully this time is better for most people). > > The planned agenda includes discussing the expected charter and > working group documents, soliciting authors for specs without them > and additional work items that we missed when working on the charter. > If you have a specific desire for a slot to talk about a protocol/draft/etc, > please let the chairs know: > > Brian Haberman > Bill Fenner > > Thanks! > Bill > From owner-idmr@cs.ucl.ac.uk Tue Jul 17 18:10:09 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25554 for ; Tue, 17 Jul 2001 18:10:08 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 17 Jul 2001 21:28:40 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 17 Jul 2001 21:28:35 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 17 Jul 2001 21:28:33 +0100 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 6A5E31ECA8; Tue, 17 Jul 2001 16:28:32 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA21914; Tue, 17 Jul 2001 16:28:30 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA27678; Tue, 17 Jul 2001 13:28:31 -0700 (PDT) Message-Id: <200107172028.NAA27678@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idmr@cs.ucl.ac.uk, magma@innovationslab.net Subject: MAGMA BOF at London IETF: Monday 0900-1130 Date: Tue, 17 Jul 2001 13:28:30 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Dear IDMR and MAGMA-ers, The MAGMA BOF will meet in London at 0900 on Monday (this time updated from 0900 Friday, hopefully this time is better for most people). The planned agenda includes discussing the expected charter and working group documents, soliciting authors for specs without them and additional work items that we missed when working on the charter. If you have a specific desire for a slot to talk about a protocol/draft/etc, please let the chairs know: Brian Haberman Bill Fenner Thanks! Bill From owner-idmr@cs.ucl.ac.uk Thu Jul 19 15:15:28 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18637 for ; Thu, 19 Jul 2001 15:15:25 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 19 Jul 2001 19:01:52 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 19 Jul 2001 19:01:47 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 19 Jul 2001 19:01:44 +0100 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 8396E1E2CB; Thu, 19 Jul 2001 14:01:38 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA08048; Thu, 19 Jul 2001 14:01:37 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA15176; Thu, 19 Jul 2001 11:01:37 -0700 (PDT) Message-Id: <200107191801.LAA15176@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: magma@innovationlabs.net, idmr@cs.ucl.ac.uk Subject: Current MAGMA agenda Date: Thu, 19 Jul 2001 11:01:36 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk ----- Begin forwarded message: From: agenda@ietf.org Subject: 51st IETF - Multicast & Anycast Group Membership BOF (magma) Date: Wed, 18 Jul 2001 12:18:05 -0400 To: ietf-announce: ; Multicast & Anycast Group Membership BOF (magma) Monday, August 06 at 0900-1130 =============================== CHAIRS: Brian Haberman Bill Fenner AGENDA: Agenda Bashing 5 minutes Document Status (including ex-IDMR documents) 15 minutes IGMP Proxying 15 minutes Multicast Source Filters API 10 minutes MIB Discussion 15 minutes Anycast Extensions to MLD 15 minutes Author Recruiting 10 minutes MAGMA future 5 minutes Description of Working Group: Group management protocols are crucial to the operation of both multicast and anycast within the Internet. These protocols allow hosts to inform routers of their membership status within groups. This working group will be responsible for developing the functionalities required for group membership reporting and other related actions. This group will also address the initial authentication and access control issues associated with anycast group membership; this is likely to be limited to shared secrets and message authentication codes (MACs) much like current routing protocol security. Other aspects of Anycast, including architecture and routing, are outside the groups scope. The draft names listed below are the starting point for the work in the WG. MAGMA specifications will include: - Core IGMPv3/MLDv2 specifications. These specifications will describe the protocol used between hosts and routers to share group membership information. IGMPv3 and MLDv2 build on IGMPv2 and MLDv1 by adding two types of source-specific filtering; "include" (in which the system tells the router exactly which sources it desires) and "exclude" (in which the system tells the router that it does *not* desire a list of sources). - IGMPv3: The IDMR working group has submitted this for Proposed Standard. MAGMA takes ownership after publication as RFC. - MLDv2: draft-vida-mld-v2-00.txt - Multicast Source Filtering API. This specification describes the API used to interact with IGMPv3 and MLDv2 to indicate source filters. - draft-ietf-idmr-msf-api-01.txt - Host determination of network group membership. In a multicast environment, systems may be interested in learning whether or not there are any group members, in order to save the trouble of sending data that nobody is listening to. - Multicast Source Notification of Interest Protocol: draft-ietf-idmr-msnip-00 - Multicast forwarding in tree topologies using IGMP/MLD Proxying Create a single document from: o draft-ietf-idmr-igmp-proxy-00 o draft-he-mixed-igmp-proxy-00 - Source-Specific Multicast (SSM) consideration document. This work will describe the use of IGMPv3/MLDv2 in an SSM environment. - draft-holbrook-idmr-igmpv3-ssm-01.txt - Considerations for "IGMP snooping" switches (switches that watch IGMP exchanges in order to determine multicast forwarding behavior) - Multicast Router Discovery: The IDMR working group has submitted this for Proposed Standard. MAGMA takes ownership after publication as an RFC. - Snooping Considerations: draft-ietf-idmr-snoop-00.txt - Group management MIBs - update RFC 2933 for IGMPv3 - update RFC 3019 for MLDv2 - Interaction between IGMP/MLD and routing protocols - draft-ietf-idmr-igmpv3-and-routing-00.txt - Extensions to MLD supporting anycast group memberships including authentication and access control mechanisms - draft-haberman-ipngwg-host-anycast-00.txt In addition, this working group will coordinate with other IETF working groups where multicast and anycast group management protocols are utilized. ----- End forwarded message: From owner-idmr@cs.ucl.ac.uk Wed Jul 25 08:53:11 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17670 for ; Wed, 25 Jul 2001 08:53:10 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 25 Jul 2001 08:42:15 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 25 Jul 2001 08:42:08 +0100 Received: from alpo.casc.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 25 Jul 2001 08:42:07 +0100 Received: from lucent.com ([152.148.248.138]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id DAA06340 for ; Wed, 25 Jul 2001 03:42:04 -0400 (EDT) Message-ID: <3B5E78DE.EF7B92CC@lucent.com> Date: Wed, 25 Jul 2001 13:14:30 +0530 From: S Seema Rao X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk Subject: Querier electiion Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi, If there are more than 1 routers on a network running IGMPV1 and all of them use DVMRP, how is the querier router elected? IGMP-v1 does not specify any mechanism for querier election. RFC 1075 states that the router with the lowest IP address is elected as the querier. But the RFC does not specify any mechanism to elect the router with the lowest IP address, but only suggests that routing messages can be used to elect the querier. Is this election process in this case implementation specific? TIA, Seema From owner-idmr@cs.ucl.ac.uk Wed Jul 25 12:30:58 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07787 for ; Wed, 25 Jul 2001 12:30:55 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 25 Jul 2001 16:21:20 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 25 Jul 2001 16:21:14 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 25 Jul 2001 16:21:07 +0100 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id B34304CE66; Wed, 25 Jul 2001 11:21:05 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA25517; Wed, 25 Jul 2001 11:21:05 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA02681; Wed, 25 Jul 2001 08:21:05 -0700 (PDT) Message-Id: <200107251521.IAA02681@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: seemarao@lucent.com Subject: Re: Querier electiion Cc: idmr@cs.ucl.ac.uk Date: Wed, 25 Jul 2001 08:21:04 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk DVMRP implementations that I'm aware of use DVMRP Probe and/or Report messages to choose the router with the lowest IP address. Bill From owner-idmr@cs.ucl.ac.uk Thu Jul 26 13:32:01 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23356 for ; Thu, 26 Jul 2001 13:32:00 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 26 Jul 2001 17:21:27 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 26 Jul 2001 16:37:27 +0100 Received: from hnssysa.hns.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 26 Jul 2001 16:37:24 +0100 Received: from hns.com (alta14.hns.com [139.85.62.34]) by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id LAA10170 for ; Thu, 26 Jul 2001 11:36:47 -0400 (EDT) Message-ID: <3B603902.F5DB926E@hns.com> Date: Thu, 26 Jul 2001 11:36:34 -0400 From: John Border X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk Subject: Re draft-ietf-idmr-igmp-proxy-01.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit I found this document very interesting because it is a cleaner way (than what we currently) to solve a problem that we run into frequently. Is it headed for the standards track? (I don't know because I am not on this particular mailing.) The working group web page implies that it is but doesn't explicitly say so... John From owner-idmr@cs.ucl.ac.uk Thu Jul 26 15:20:34 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05165 for ; Thu, 26 Jul 2001 15:20:33 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 26 Jul 2001 19:34:35 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 26 Jul 2001 19:34:28 +0100 Received: from 47.129.242.157 by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 26 Jul 2001 19:34:27 +0100 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6QIY4918944 for ; Thu, 26 Jul 2001 14:34:04 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Thu, 26 Jul 2001 14:33:58 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PL4DXB05; Thu, 26 Jul 2001 14:33:57 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5MY9A; Thu, 26 Jul 2001 14:33:57 -0400 Message-ID: <3B606288.86353EBF@americasm06.nt.com> Date: Thu, 26 Jul 2001 14:33:45 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Brian Haberman Reply-To: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Border CC: idmr@cs.ucl.ac.uk Subject: Re: Re draft-ietf-idmr-igmp-proxy-01.txt References: <3B603902.F5DB926E@hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit John, Yes, it is targeted for standards track. It will be discussed at the MAGMA meeting in London. Regards, Brian John Border wrote: > > I found this document very interesting because it is a cleaner way (than > what we currently) to solve a problem that we run into frequently. Is it > headed for the standards track? (I don't know because I am not on this > particular mailing.) The working group web page implies that it is but > doesn't explicitly say so... > > John From owner-idmr@cs.ucl.ac.uk Tue Jul 31 11:32:02 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21581 for ; Tue, 31 Jul 2001 11:32:01 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 31 Jul 2001 14:55:20 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 31 Jul 2001 14:55:16 +0100 Received: from mail1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 31 Jul 2001 14:55:15 +0100 Received: from bwilliam-t20.cisco.com (bwilliam-isdn1.cisco.com [171.70.247.82]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA20951; Tue, 31 Jul 2001 06:52:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20010731084734.05401bd8@mail1.cisco.com> X-Sender: bwilliam@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Jul 2001 08:49:41 -0500 To: John Zwiebel , Andrew Adams From: Beau Williamson Subject: Re: draft-ietf-pim-dm-new-v2-04.txt Cc: pim@catarina.usc.edu, jonathan.nicholas@itt.com, wfs@nexthop.com, magma@innovationlabs.net, idmr@cs.ucl.ac.uk In-Reply-To: <3B587D6F.B707EFC1@Procket.com> References: <3B586018.B6ADDC06@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk At 01:50 PM 7/20/2001, John Zwiebel wrote: >While I'm "on a role" (ie bitching), I'd also like to encourage >this group to require the source to ask for permission to send >to the network. Every IETF the same discussion comes up about >how difficult it is to implement a protocol that allows the >source to just dump traffic on to the network and then expect the >routers to handle it. I keep saying "CTS/RTS". Then I'm told >the host vendors will take too long to incorporate such a change in >their OS so "its too hard". Now 5 years later we still have the >same stupid problem with customer's demanding that multicast >be more stable and that no data be lost. That's impossible >as long as the source can just dump traffic on to the net. > I agree with John on this although I don't think it has anything to do with PIM. I'd like to see new MAGMA WG tackle this along with other issues of admission control of both receivers and senders. Beau Williamson From owner-idmr@cs.ucl.ac.uk Tue Jul 31 13:22:22 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01212 for ; Tue, 31 Jul 2001 13:22:21 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 31 Jul 2001 17:35:58 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 31 Jul 2001 17:35:52 +0100 Received: from london.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 31 Jul 2001 17:35:52 +0100 Received: from BRMCLAUG-W2K1.cisco.com (brmclaug-isdn-home.cisco.com [10.49.128.246]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA02062; Tue, 31 Jul 2001 17:31:19 +0100 (BST) Message-Id: <4.3.2.7.2.20010731172225.01e673f0@london.cisco.com> X-Sender: brmclaug@london.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Jul 2001 17:31:34 +0100 To: Beau Williamson From: Bryan Mclaughlin Subject: Re: draft-ietf-pim-dm-new-v2-04.txt Cc: John Zwiebel , Andrew Adams , pim@catarina.usc.edu, jonathan.nicholas@itt.com, wfs@nexthop.com, magma@innovationlabs.net, idmr@cs.ucl.ac.uk In-Reply-To: <4.3.2.7.2.20010731084734.05401bd8@mail1.cisco.com> References: <3B587D6F.B707EFC1@Procket.com> <3B586018.B6ADDC06@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This issue is addressed by Multicast Source Notification of Interest Protocol (MSNIP) for SM protocols, isn't it ? What would need to be added to make it work for DM? Bryan At 08:49 31/07/2001 -0500, Beau Williamson wrote: >At 01:50 PM 7/20/2001, John Zwiebel wrote: > >While I'm "on a role" (ie bitching), I'd also like to encourage > >this group to require the source to ask for permission to send > >to the network. Every IETF the same discussion comes up about > >how difficult it is to implement a protocol that allows the > >source to just dump traffic on to the network and then expect the > >routers to handle it. I keep saying "CTS/RTS". Then I'm told > >the host vendors will take too long to incorporate such a change in > >their OS so "its too hard". Now 5 years later we still have the > >same stupid problem with customer's demanding that multicast > >be more stable and that no data be lost. That's impossible > >as long as the source can just dump traffic on to the net. > > > >I agree with John on this although I don't think it has anything to do >with PIM. I'd like to see new MAGMA WG tackle this along with other >issues of admission control of both receivers and senders. > >Beau Williamson