From owner-idmr@cs.ucl.ac.uk Wed Jan 3 04:19: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 EAA11792 for ; Wed, 3 Jan 2001 04:19:27 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 3 Jan 2001 06:39:26 +0000 Received: from haig.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 3 Jan 2001 06:39:19 +0000 Received: from suraksha.wipsys.soft.net by haig.cs.ucl.ac.uk with Internet SMTP id ; Wed, 3 Jan 2001 06:39:27 +0000 Received: by suraksha.wipro.com (8.8.8+Sun/SMI-SVR4) id MAA27029; Wed, 3 Jan 2001 12:01:43 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma027025; Wed, 3 Jan 01 12:01:23 +0530 Received: from wipro.com ([192.168.162.124]) by bhairavi.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA4E0B for ; Wed, 3 Jan 2001 11:57:00 +0530 Message-ID: <3A52CC15.FC6DCEA0@wipro.com> Date: Wed, 03 Jan 2001 12:22:05 +0530 From: Vijay Anand Chandrasekar Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk Subject: Handling looped back packets Content-Type: multipart/mixed; boundary="------------61F6E95598B9587D287F3893" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. --------------61F6E95598B9587D287F3893 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, Should loop back be enabled on Multicast routers. If so, when we send out a multicast packet, should it be looped back via the loop-back interface. If it is looped back, then looping back forwarded datagrams can cause problems, so at what level should the looped back packet be discarded or how else can it be handled. Thanks in advance Regards, Vijay _______________________________________ PETTRA THAAI THANAI MAGAN MARANTHAALUM, PILLAYAI PERUM THAAI MARANTHAALUM, UTTRA THEGATHAI UYIR MARATHAALUM, NAMASHIVAYAMAE UNNAI NAAN MARAVAEN ________________________________________ --------------61F6E95598B9587D287F3893 Content-Type: text/x-vcard; charset=us-ascii; name="vijay.chand.vcf" Content-Description: Card for Vijayanand C Content-Disposition: attachment; filename="vijay.chand.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:;C.Vijayanand tel;work:2301530 - Ext: 343 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:vijay.chand@wipro.com fn:C.Vijayanand end:vcard --------------61F6E95598B9587D287F3893-- From owner-idmr@cs.ucl.ac.uk Wed Jan 3 06:29:39 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17559 for ; Wed, 3 Jan 2001 06:29:38 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 3 Jan 2001 09:58:52 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 3 Jan 2001 09:58:45 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 3 Jan 2001 09:58:53 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id KAA24521; Wed, 3 Jan 2001 10:57:30 +0100 (MET) Message-ID: <3A52F78A.EE2F1497@irisa.fr> Date: Wed, 03 Jan 2001 10:57:30 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: Vijay Anand Chandrasekar , idmr@cs.ucl.ac.uk Subject: Re: Handling looped back packets References: <3A52CC15.FC6DCEA0@wipro.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit hi, There is a lot of techniques used to disallow loops in multicasting. or example the poison reverse (DVMRP) and the RPF technique. a pacquet which arrive in the non appropriate incoming interface should be discared. Vijay Anand Chandrasekar wrote: > Hi All, > Should loop back be enabled on Multicast routers. If so, when we send > out a multicast packet, should it be looped back via the loop-back > interface. If it is looped back, then looping back forwarded datagrams > can cause problems, so at what level should the looped back packet be > discarded or how else can it be handled. > > Thanks in advance > > Regards, > Vijay > > _______________________________________ > > PETTRA THAAI THANAI MAGAN MARANTHAALUM, > PILLAYAI PERUM THAAI MARANTHAALUM, > UTTRA THEGATHAI UYIR MARATHAALUM, > NAMASHIVAYAMAE UNNAI NAAN MARAVAEN > > ________________________________________ From owner-idmr@cs.ucl.ac.uk Wed Jan 3 06:29:46 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 GAA17581 for ; Wed, 3 Jan 2001 06:29:46 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 3 Jan 2001 10:17:53 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 3 Jan 2001 10:17:42 +0000 Received: from suraksha.wipsys.soft.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 3 Jan 2001 10:17:47 +0000 Received: by suraksha.wipro.com (8.8.8+Sun/SMI-SVR4) id PAA04986; Wed, 3 Jan 2001 15:43:14 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma004977; Wed, 3 Jan 01 15:43:07 +0530 Received: from wipro.com ([192.168.162.124]) by bhairavi.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAAE0C; Wed, 3 Jan 2001 15:38:41 +0530 Message-ID: <3A53000E.2DE7EF8A@wipro.com> Date: Wed, 03 Jan 2001 16:03:50 +0530 From: Vijay Anand Chandrasekar Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "idmr@cs.ucl.ac.uk" CC: aboudani@irisa.fr Subject: Re: Handling looped back packets] 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 , You mean to say the looped back packets must be allowed upto the DVMRP RPF check . SHould'nt it be discarded before that. Regards, Vijay Ali Boudani wrote: > hi, > There is a lot of techniques used to disallow loops in multicasting. > or example the poison reverse (DVMRP) and the RPF technique. > a pacquet which arrive in the non appropriate incoming interface should be > discared. > > Vijay Anand Chandrasekar wrote: > > > Hi All, > > Should loop back be enabled on Multicast routers. If so, when we send > > out a multicast packet, should it be looped back via the loop-back > > interface. If it is looped back, then looping back forwarded datagrams > > can cause problems, so at what level should the looped back packet be > > discarded or how else can it be handled. > > > > Thanks in advance > > > > Regards, > > Vijay > > From owner-idmr@cs.ucl.ac.uk Wed Jan 3 06:29:55 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17592 for ; Wed, 3 Jan 2001 06:29:55 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 3 Jan 2001 11:24:20 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 3 Jan 2001 11:24:13 +0000 Received: from suraksha.wipsys.soft.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 3 Jan 2001 11:24:20 +0000 Received: by suraksha.wipro.com (8.8.8+Sun/SMI-SVR4) id QAA06833; Wed, 3 Jan 2001 16:49:50 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma006827; Wed, 3 Jan 01 16:49:42 +0530 Received: from webmail ([192.168.160.25]) by bhairavi.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA63A1 for ; Wed, 3 Jan 2001 16:45:16 +0530 From: Vinodkumar Parasmal To: idmr@cs.ucl.ac.uk Subject: Enabling ALL MULTICAST X-Mailer: Netscape Messenger Express 3.5.2 [Mozilla/4.7 [en] (Win95; I)] Date: Wed, 3 Jan 2001 16:45:16 +0530 Message-ID: <7744FE875EC.AAA63A1@bhairavi.mail.wipro.com> Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi All, I have a doubt regarding the Ethernet Support for receiving multicast packets destined to any Group.This is used in case Multicast Routing is enabled on that interface.Not all Adapters provide this support.What can be done in such situations ? Thanks in advance Vinod From owner-idmr@cs.ucl.ac.uk Thu Jan 4 05:59:18 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01452 for ; Thu, 4 Jan 2001 05:59:18 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 4 Jan 2001 08:44:24 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 4 Jan 2001 08:44:17 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 4 Jan 2001 08:44:12 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id JAA27855; Thu, 4 Jan 2001 09:44:11 +0100 (MET) Message-ID: <3A5437DB.966C4800@irisa.fr> Date: Thu, 04 Jan 2001 09:44:11 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk, dirk.ooms@alcatel.be, bernard.sales@alcatel.be, wlivens@colt-telecom.be, arup@us.ibm.com, griffoul@ulticom.com, furquan@dnrc.bell-labs.com Subject: mixed L2/L3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I was reading the draft http://www.ietf.org/internet-drafts/draft-ietf-mpls-multicast-04.txt (framework for IP multicast in MPLS) and I didnt understand what is the meaning for this paragraph 4 : Assume LSR A (Figure 8) is an MPLS edge node for the branch towards LSR B and an MPLS root node for the branch towards LSR C. The mixed L2/L3 forwarding allows that the branch towards C is not disturbed by a return to L3 in LSR A. +-------------+ | MPLS cloud | | N | | / \ | | / \ | | / \ | | A N | |/ \ \ | | \ \ | /| \ | B | C | | | +-------------+ Figure 8. Mixed L2/L3 forwarding in node A b) Enables the use of the traffic driven trigger with the Downstream Unsolicited or Upstream on Demand label distribution mode, as explained in section 5.3.1. Can anybody explain it please ?? From owner-idmr@cs.ucl.ac.uk Thu Jan 4 20:18:44 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 UAA19145 for ; Thu, 4 Jan 2001 20:18:44 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 4 Jan 2001 23:39:38 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 4 Jan 2001 23:39:32 +0000 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 4 Jan 2001 23:39:31 +0000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 244564CE0E; Thu, 4 Jan 2001 18:39:29 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA03092; Thu, 4 Jan 2001 18:39:28 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA22132; Thu, 4 Jan 2001 15:39:28 -0800 (PST) Message-Id: <200101042339.PAA22132@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: vinodkumar.paras@wipro.com Subject: Re: Enabling ALL MULTICAST Cc: idmr@cs.ucl.ac.uk Date: Thu, 4 Jan 2001 15:39:27 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >I have a doubt regarding the Ethernet Support for receiving multicast >packets destined to any Group.This is used in case Multicast Routing is >enabled on that interface.Not all Adapters provide this support.What can be >done in such situations ? Use fully promiscuous mode. This results in a performance penalty, since the adapter receives every single packet crossing the wire, but that's simply an incentive not to use adapters that don't support promiscuous multicast. (Are there really network adapters that don't support being promiscuous to multicast?) Bill From owner-idmr@cs.ucl.ac.uk Thu Jan 4 20:23: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 UAA19209 for ; Thu, 4 Jan 2001 20:23:05 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 4 Jan 2001 23:34:26 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 4 Jan 2001 23:34:19 +0000 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 4 Jan 2001 23:34:18 +0000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 19E6A4CE0A; Thu, 4 Jan 2001 18:34:17 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA02968; Thu, 4 Jan 2001 18:34:15 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA22096; Thu, 4 Jan 2001 15:34:15 -0800 (PST) Message-Id: <200101042334.PAA22096@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: vijay.chand@wipro.com Subject: Re: Handling looped back packets Cc: idmr@cs.ucl.ac.uk Date: Thu, 4 Jan 2001 15:34:15 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >Should loop back be enabled on Multicast routers. What does this mean? >If so, when we send >out a multicast packet, should it be looped back via the loop-back >interface. If it is looped back, then looping back forwarded datagrams >can cause problems, so at what level should the looped back packet be >discarded or how else can it be handled. The UNIX multicast router implementation treats packets sent by the system (as opposed to packets forwarded by the system) as though they arrived on the interface on which they were sent. This causes the fact that the system is a router to be transparent to applications being run on the system, i.e. the applications see a multi-homed host with the same interfaces as the router has, and the router sees packets coming in from external systems. There's also the question of whether a datagram sent on a socket gets looped back to other sockets (the IP_MULTICAST_LOOP setsockopt) but that happens completely independent of routing, so I assume that's not the question. Bill From owner-idmr@cs.ucl.ac.uk Fri Jan 5 12:37:42 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17575 for ; Fri, 5 Jan 2001 12:37:41 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 5 Jan 2001 15:41:02 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Jan 2001 15:40:55 +0000 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 5 Jan 2001 15:40:46 +0000 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id QAA25062 for ; Fri, 5 Jan 2001 16:40:46 +0100 (MET) Message-ID: <3A55EB02.3658A641@irisa.fr> Date: Fri, 05 Jan 2001 16:40:50 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk Subject: PIM and MPLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit hello, In the draft "Using PIM to Distribute MPLS Labels for Multicast Routes" In page 4 section 4 we can see the following Suppose an LSR Rd, as the result of receiving, from a downstream neighbor on the shared tree, a Join/Prune message such as described in 3, creates (S,G)RPT-bit state with a non- null output interface list. In this case, it may send a Join/Prune message upstream on the shared tree, containing the group address followed by a prune-list. An element of the prune list will contain the address S and a corresponding label. However, a special bit (the "Label Only" bit, or "L- bit") in the element will be set indicating to the upstream LSR that the source S is not really to be pruned from the shared tree. The result is that the upstream LSR Ru, will still send packets from S to G to Rd, and will label those packets as specified. When Rd receives such packets, it forwards them according to the output interface list of the (S,G)RPT-bit entry. Intuitively, this label represents a route along the shared tree, but only for packets from the specified source. what does that mean ?? how the label represents a route along the shared tree , but only for packets from the specified source. As I know, if there is a prune message and the SPT is established , that mea there is no need to use the shared tree for that source anymore?? why do we need to put this L-bit ?? Thanx From owner-idmr@cs.ucl.ac.uk Fri Jan 5 23:20:31 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 XAA29473 for ; Fri, 5 Jan 2001 23:20:30 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sat, 6 Jan 2001 02:41:51 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 6 Jan 2001 02:41:45 +0000 Received: from omega.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 6 Jan 2001 02:41:43 +0000 Received: (from ycai@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA21403; Fri, 5 Jan 2001 18:41:05 -0800 (PST) Date: Fri, 5 Jan 2001 18:41:05 -0800 (PST) Message-Id: <200101060241.SAA21403@cisco.com> From: Yiqun Cai To: aboudani@irisa.fr CC: idmr@cs.ucl.ac.uk In-reply-to: <3A55EB02.3658A641@irisa.fr> (message from Ali Boudani on Fri, 05 Jan 2001 16:40:50 +0100) Subject: Re: PIM and MPLS Reply-to: ycai@cisco.com Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk > > what does that mean ?? > how the label represents a route along the shared tree , but only for > packets from the specified source. > As I know, if there is a prune message and the SPT is established , that > mea there is no need to use the shared tree for that source anymore?? > why do we need to put this L-bit ?? > Thanx > > Consider the following scenario: 2RP | | R1 | | R2 -------- Ru | | Rd -------- R3 ------ 2SRC Rd has joined the source tree via R3, but R2 stays on the shared tree. Therefore, Ru will have an (S,G,RPT) entry with non-null olist. When using label switching, R1 has to use one label for packets sourced by S and another label for the rest of the packets on the shared tree so that Ru can make the right forwarding decision without seeing the IP header. This is achieved by Ru sending the message as described in the draft. Without the L bit, R1 will not maintain such a state. -- Yiqun From owner-idmr@cs.ucl.ac.uk Wed Jan 10 09:20:30 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17459 for ; Wed, 10 Jan 2001 09:20:29 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 10 Jan 2001 11:45:37 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Jan 2001 11:45:30 +0000 Received: from smtp4.cluster.oleane.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 10 Jan 2001 11:45:29 +0000 Received: from oleane (dyn-1-1-059.Vin.dialup.oleane.fr [195.25.4.59]) by smtp4.cluster.oleane.net with SMTP id f0ABjQF78207 for ; Wed, 10 Jan 2001 12:45:27 +0100 (CET) Message-ID: <027501c07afb$053df3a0$8001a8c0@oleane.com> From: Peter Lewis To: idmr Subject: MPLS World, February 6-9, Paris Date: Wed, 10 Jan 2001 12:46:50 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0272_01C07B03.66A6CE20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0272_01C07B03.66A6CE20 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 MPLS World, February 6-9, Paris.=20 =20 http://www.upperside.fr/congress/congress.htm =20 With the challenges and uncertainties engendered by the development of = the MPLS architecture, the MPLS World Conference is, in essence, an open = platform for debate on the future of telecommunications networks.=20 Looking Farther Ahead=20 MPLS World is preoccupied with future developments, like using MPLS in = the access network and in the LAN. MPLambdaS, MPLS/mobility convergence = are addressed in papers never before given. MPLS is a unique occasion = for participants to unveil their work and expose new ideas.=20 =20 The exhibition =20 Already 20 exhibitors for this very first MPLS exhibition. Upper Side = will fullfill his objectives. Vendors shouldn't miss the opportunity: http://www.upperside.fr/congress/exhi.htm ------=_NextPart_000_0272_01C07B03.66A6CE20 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
MPLS World, February 6-9, Paris.=20
 
http://www.uppersi= de.fr/congress/congress.htm
 
With the=20 challenges and uncertainties engendered by the development of the MPLS=20 architecture, the MPLS World Conference is, in essence, an open platform = for=20 debate on the future of telecommunications networks.=20

Looking=20 Farther Ahead

MPLS World is preoccupied with future = developments,=20 like using MPLS in the access network and in the LAN. MPLambdaS, = MPLS/mobility=20 convergence are addressed in papers never before given. MPLS is a unique = occasion for participants to unveil their work and expose new ideas.=20
 
The=20 exhibition
 
Already 20=20 exhibitors for this very first MPLS exhibition. Upper Side will fullfill = his=20 objectives. Vendors shouldn't miss the opportunity:
http://www.upperside.f= r/congress/exhi.htm
 
 
------=_NextPart_000_0272_01C07B03.66A6CE20-- From owner-idmr@cs.ucl.ac.uk Thu Jan 18 15:57: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 PAA05298 for ; Thu, 18 Jan 2001 15:57:33 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 18 Jan 2001 18:43:03 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 18 Jan 2001 18:42:56 +0000 Received: from add1.multicasttech.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 18 Jan 2001 18:42:56 +0000 Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 720997; Thu, 18 Jan 2001 13:42:51 -0500 Message-ID: <3A67386F.D1D5D23B@21rst-century.com> Date: Thu, 18 Jan 2001 13:39:44 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Magnus Danielson CC: nickless@mcs.anl.gov, owens@nysernet.org, shep@network-services.uoregon.edu, kthomp@MCI.NET, wg-multicast@internet2.edu, mbone@ISI.EDU, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu Subject: Re: MSDP Storm References: <4.3.2.7.2.20010117165333.027da900@localhost> <3A6624D3.3542D5CB@21rst-century.com> <4.3.2.7.2.20010117180104.028047e0@localhost> <20010118174606A.magda@netinsight.se> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Magnus Danielson wrote: > From: Bill Nickless > Subject: Re: MSDP Storm > Date: Wed, 17 Jan 2001 18:11:05 -0600 > > > >BUT, it seems to me that at base this is not a MSDP issue - it is an IGMP > > >issue. Wouldn't it make more sense (although, alas, more work) to rate > > >limit IGMP joins ? > > > > Good question. > > > > I agree with Dave Meyer's comment, that the general problem is a lack of > > rate limiting on routing protocols subject to flooding, including > > MSDP. Should we include IGMP in this list of protocols that should be rate > > limitable? I'm not sure. > > I think you really should do plumbing in both IGMP and MSDP in this case. > If the IGMP plumbing fail (intentionally or unintentionally disabled/broken) > on one box, then you need the plumbing in MSDP anyway. The MSDP saves your > network and whoever is behind that... IGMP plumbing is just the "first wave" > wall. If that falls, the network would fall, that's why MSDP also needs > attention. > > Rate-limiting is just one of many tools. > > This is really why there is a Security section in them RFCs. We really should > consider putting some standard plumbing in there... > > Cheers, > Magnus I would agree. Mischievously, I would point out that there is an IGMP v3 RFC grinding along : AND a MSDP draft grinding along as well : Section 19 of the MSDP draft is typical : --------------------------------- 19. Security Considerations An MSDP implementation MAY use IPsec [RFC1825] or keyed MD5 [RFC1828] to secure control messages. When encapsulating SA data in GRE, security should be relatively similar to security in a normal IPv4 network, as routing using GRE follows the same routing that IPv4 uses natively. Route filtering will remain unchanged. However packet filtering at a firewall requires either that a firewall look inside the GRE packet or that the filtering is done on the GRE tunnel endpoints. In those environments in which this is considered to be a security issue it may be desirable to terminate the tunnel at the firewall. --------------------------------- There is NOTHING in either draft about limiting DOS type attacks. Just to throw out a specific suggestion : wouldn't it make sense to include SHOULDS (at least) about rate limiting - number of joins allowed per second to a SPECIFC (S,G) from a SPECIFC receiver or source (at, say, 1 per second). - number of joins allowed per second (for all (S,G) from a SPECIFIC receiver or source) (at, say, 500 per second, and no more than 1000 in a 10 second period.) - total number of joins to any specific group, or any specific source (i.e., to a (*,G) or a (S,*)) from all attached sources / receivers (at, say, no more than 1000 in a ten second period). And similar numbers for SA setups in MSDP ? This might limit vast multiparty games or videoconferences a little, but would not hinder any SSM type aps I can think of at all. The numbers I gave may be too lenient; I was just trying to get some thinking about this started. -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From owner-idmr@cs.ucl.ac.uk Thu Jan 18 16:00:15 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05346 for ; Thu, 18 Jan 2001 16:00:14 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 18 Jan 2001 20:47:24 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 18 Jan 2001 20:47:18 +0000 Received: from add1.multicasttech.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 18 Jan 2001 20:47:16 +0000 Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 721102; Thu, 18 Jan 2001 15:47:11 -0500 Message-ID: <3A675594.885FDBFA@21rst-century.com> Date: Thu, 18 Jan 2001 15:44:04 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mike Luby CC: Magnus Danielson , nickless@mcs.anl.gov, owens@nysernet.org, shep@network-services.uoregon.edu, kthomp@MCI.NET, wg-multicast@internet2.edu, mbone@ISI.EDU, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu, pim@catarina.usc.edu Subject: Re: MSDP Storm References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mike; Mike Luby wrote: > -- > > > > I like: > > - number of joins allowed per second to a SPECIFC (S,G) from a SPECIFC > receiver or source (at, say, 1 per second). I was thinking of a zombie doing a DOS aimed at its first hop router. I see no reason to sit there and hammer away at your first hop with a join. > > - number of joins allowed per second (for all (S,G) from a SPECIFIC receiver > or source) > (at, say, 500 per second, and no more than 1000 in a 10 second period.) > This, of course, was aimed at a SSM DOS attack. > > ... although I would prefer in the first a fraction of a second (say 0.5) > instead of a full second, and the second is more than liberal (I can't > imagine a specific end user receiver trying to join 500 sessions per second, > but perhaps if this is an intermediate server box receiving multicast this > might make more sense). These restrictions also make sense, since it is the > access router that will have to deal with these, i.e., one box. > > I don't like: > > - total number of joins to any specific group, or any specific source (i.e., > to a (*,G) or a (S,*)) from all attached sources / receivers > (at, say, no more than 1000 in a ten second period). I was really thinking IGMP here, not MSDP - I was thinking of a LAN with one or more zombies on it doing a port scan or something similar. This is what would stop the RAMEN worm attack. I suspect that there will need to be something added to PIM as well - all the PIM v2 revised draft says is ------ 6. Security Considerations All PIM control messages MAY use IPsec [6] to address security concerns. The authentication methods are addressed in a companion document [7]. Keys may be distributed as described in [8]. ------ I see no reason a PIM router should encapulate and pass to the RP 15,000 packets, each on a different group, from one source in a few minutes. I see no reason why the RP should accept them. If a RP was turned into a zombie, I see no reason why other RP's should accept and forward these SA's. > > > Why would you want to put a limit like this, since in particular > (a) This is a global restriction, and limits the scalability of SSM > (b) There is no correlation between this (what I consider artificial > restriction) and the load on any particular box in the network. In > particular, there could be millions of clients joining a group from > different parts of the network, but these joins are being handled by routers > distributed across the entire network. And, the load that joins to a > particular group would be spread across the entire network infrastructure, > and this requirement would be subsumed by the first two restrictions. > Every rate limit (IMHO) has to be PER router. Routers cannot be assumed to know what others are doing. > > What I would like to see is that if there is rate limitation, then it is per > box (the first two restriction you mentioned would be of this type) and not > some artificial global restriction that couldn't be enforced (there is no > point in the network that would feel such a load in SSM, maybe this would > make more sense for ISM with the RP as the global bottleneck) and has no > correlation with overwhelming some particular part of the network. > > Ok, I'm SSM biased, and I'm seeing things colored by that. Maybe a global > limitation would make sense for ISM because of the RP, but there must not be > such a global restriction for SSM, else it defeats the attractiveness of > massive scalability. I did not intend a global limitation. Sorry if I was unclear. > > > Mike -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From owner-idmr@cs.ucl.ac.uk Thu Jan 18 21:02: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 VAA08061 for ; Thu, 18 Jan 2001 21:02:57 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 19 Jan 2001 00:27:41 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 18 Jan 2001 22:07:53 +0000 Received: from mail.webfountain.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 18 Jan 2001 22:07:52 +0000 Received: from leningrad (gate.webfountain.com [63.161.54.3]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id OAA03202; Thu, 18 Jan 2001 14:07:25 -0800 X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad From: Mike Luby To: tme Cc: Magnus Danielson , nickless , owens , shep , kthomp , wg-multicast , mbone , idmr , msdp , pim , Michael Luby Subject: RE: MSDP Storm Date: Thu, 18 Jan 2001 14:09:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3A675594.885FDBFA@21rst-century.com> Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi Marshall, I agree with what you say below, thanks for clarifying. I would only add that once I thought about it a bit more I would be happy if the first requirement, i.e., SPECIFIC receiver trying to join a SPECIFIC (S,G), was rate limited at even once per something like 10 seconds, so your once per second suggested restriction is more than ok. Michael Luby -----Original Message----- From: Marshall Eubanks [mailto:tme@21rst-century.com] Sent: Thursday, January 18, 2001 12:44 PM To: Mike Luby Cc: Magnus Danielson; nickless@mcs.anl.gov; owens@nysernet.org; shep@network-services.uoregon.edu; kthomp@MCI.NET; wg-multicast@internet2.edu; mbone@ISI.EDU; idmr@cs.ucl.ac.uk; msdp@antc.uoregon.edu; pim@catarina.usc.edu Subject: Re: MSDP Storm Hi Mike; Mike Luby wrote: > -- > > > > I like: > > - number of joins allowed per second to a SPECIFC (S,G) from a SPECIFC > receiver or source (at, say, 1 per second). I was thinking of a zombie doing a DOS aimed at its first hop router. I see no reason to sit there and hammer away at your first hop with a join. > > - number of joins allowed per second (for all (S,G) from a SPECIFIC receiver > or source) > (at, say, 500 per second, and no more than 1000 in a 10 second period.) > This, of course, was aimed at a SSM DOS attack. > > ... although I would prefer in the first a fraction of a second (say 0.5) > instead of a full second, and the second is more than liberal (I can't > imagine a specific end user receiver trying to join 500 sessions per second, > but perhaps if this is an intermediate server box receiving multicast this > might make more sense). These restrictions also make sense, since it is the > access router that will have to deal with these, i.e., one box. > > I don't like: > > - total number of joins to any specific group, or any specific source (i.e., > to a (*,G) or a (S,*)) from all attached sources / receivers > (at, say, no more than 1000 in a ten second period). I was really thinking IGMP here, not MSDP - I was thinking of a LAN with one or more zombies on it doing a port scan or something similar. This is what would stop the RAMEN worm attack. I suspect that there will need to be something added to PIM as well - all the PIM v2 revised draft says is ------ 6. Security Considerations All PIM control messages MAY use IPsec [6] to address security concerns. The authentication methods are addressed in a companion document [7]. Keys may be distributed as described in [8]. ------ I see no reason a PIM router should encapulate and pass to the RP 15,000 packets, each on a different group, from one source in a few minutes. I see no reason why the RP should accept them. If a RP was turned into a zombie, I see no reason why other RP's should accept and forward these SA's. > > > Why would you want to put a limit like this, since in particular > (a) This is a global restriction, and limits the scalability of SSM > (b) There is no correlation between this (what I consider artificial > restriction) and the load on any particular box in the network. In > particular, there could be millions of clients joining a group from > different parts of the network, but these joins are being handled by routers > distributed across the entire network. And, the load that joins to a > particular group would be spread across the entire network infrastructure, > and this requirement would be subsumed by the first two restrictions. > Every rate limit (IMHO) has to be PER router. Routers cannot be assumed to know what others are doing. > > What I would like to see is that if there is rate limitation, then it is per > box (the first two restriction you mentioned would be of this type) and not > some artificial global restriction that couldn't be enforced (there is no > point in the network that would feel such a load in SSM, maybe this would > make more sense for ISM with the RP as the global bottleneck) and has no > correlation with overwhelming some particular part of the network. > > Ok, I'm SSM biased, and I'm seeing things colored by that. Maybe a global > limitation would make sense for ISM because of the RP, but there must not be > such a global restriction for SSM, else it defeats the attractiveness of > massive scalability. I did not intend a global limitation. Sorry if I was unclear. > > > Mike -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From owner-idmr@cs.ucl.ac.uk Fri Jan 19 09:03: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 JAA29234 for ; Fri, 19 Jan 2001 09:03:53 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 19 Jan 2001 11:54:56 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jan 2001 11:54:48 +0000 Received: from mail2.netinsight.se by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 19 Jan 2001 11:54:43 +0000 Received: from localhost (unverified [10.100.1.11]) by ernst.netinsight.se (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 19 Jan 2001 12:54:39 +0100 To: tme@21rst-century.com Cc: nickless@mcs.anl.gov, owens@nysernet.org, shep@network-services.uoregon.edu, kthomp@MCI.NET, wg-multicast@internet2.edu, mbone@ISI.EDU, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu Subject: Re: MSDP Storm In-Reply-To: <3A67386F.D1D5D23B@21rst-century.com> References: <4.3.2.7.2.20010117180104.028047e0@localhost> <20010118174606A.magda@netinsight.se> <3A67386F.D1D5D23B@21rst-century.com> X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010119135439P.magda@netinsight.se> Date: Fri, 19 Jan 2001 13:54:39 +0100 From: Magnus Danielson X-Dispatcher: imput version 991025(IM133) Lines: 60 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: MSDP Storm Date: Thu, 18 Jan 2001 13:39:44 -0500 > I would agree. Mischievously, I would point out that there is an IGMP v3 RFC grinding along : > > AND a MSDP draft grinding along as well : > > > Section 19 of the MSDP draft is typical : > --------------------------------- > 19. Security Considerations > > An MSDP implementation MAY use IPsec [RFC1825] or keyed MD5 [RFC1828] > to secure control messages. When encapsulating SA data in GRE, > security should be relatively similar to security in a normal IPv4 > network, as routing using GRE follows the same routing that IPv4 uses > natively. Route filtering will remain unchanged. However packet > filtering at a firewall requires either that a firewall look inside > the GRE packet or that the filtering is done on the GRE tunnel > endpoints. In those environments in which this is considered to be a > security issue it may be desirable to terminate the tunnel at the > firewall. > > --------------------------------- > There is NOTHING in either draft about limiting DOS type attacks. Right, and then the above text is even beyond what I anticipated. My point is partly that this is one of those ugly things which nobody wants to care about but everybody eventually suffers from. The WGs and ID editors didn't caugth on why it has made a requirement to have this chapter. > Just to throw out a specific suggestion : wouldn't it make sense to include SHOULDS (at least) about rate limiting > - number of joins allowed per second to a SPECIFC (S,G) from a SPECIFC receiver or source (at, say, 1 per second). > - number of joins allowed per second (for all (S,G) from a SPECIFIC receiver or source) > (at, say, 500 per second, and no more than 1000 in a 10 second period.) > - total number of joins to any specific group, or any specific source (i.e., to a (*,G) or a (S,*)) from all attached sources / receivers > (at, say, no more than 1000 in a ten second period). > > And similar numbers for SA setups in MSDP ? The actual numbers should never be put into that RFC. If specific numbers are required, then you should have a separate RFC also running as a BCP to detail it and updates can be made according to need. Generic filters and adaptive functions may be directly specified. > This might limit vast multiparty games or videoconferences a little, but would not hinder any SSM type aps I > can think of at all. The numbers I gave may be too lenient; I was just trying to get some thinking about this started. Like allways, picking one single number is allways a tradeoff thing. BTW. In this case of the worm... didn't the scanner try to connect to TCP? I mean, trying to do TCP on _ANY_ multicast address is just bound to be a looser. A simple filter could (and should) block that. Cheers, Magnus From owner-idmr@cs.ucl.ac.uk Fri Jan 19 11:58:15 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02195 for ; Fri, 19 Jan 2001 11:58:14 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 19 Jan 2001 15:30:34 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jan 2001 15:30:27 +0000 Received: from mail2.netinsight.se by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 19 Jan 2001 15:30:26 +0000 Received: from localhost (unverified [10.100.1.11]) by ernst.netinsight.se (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 19 Jan 2001 16:30:18 +0100 To: tme@21rst-century.com Cc: nickless@mcs.anl.gov, owens@nysernet.org, shep@network-services.uoregon.edu, kthomp@MCI.NET, wg-multicast@internet2.edu, mbone@ISI.EDU, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu Subject: Re: MSDP Storm In-Reply-To: <3A685692.FCDF9157@21rst-century.com> References: <3A67386F.D1D5D23B@21rst-century.com> <20010119135439P.magda@netinsight.se> <3A685692.FCDF9157@21rst-century.com> X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010119173018W.magda@netinsight.se> Date: Fri, 19 Jan 2001 17:30:18 +0100 From: Magnus Danielson X-Dispatcher: imput version 991025(IM133) Lines: 31 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: MSDP Storm Date: Fri, 19 Jan 2001 10:00:33 -0500 > Hello Magnus; Dear Marshall, > Magnus Danielson wrote: > > > > From: Marshall Eubanks > > Subject: Re: MSDP Storm > > Date: Thu, 18 Jan 2001 13:39:44 -0500 > > > > > I would agree. Mischievously, I would point out that there is an IGMP v3 RFC grinding along : > > > > > > AND a MSDP draft grinding along as well : > > > > > > > > > > The actual numbers should never be put into that RFC. If specific numbers are > > required, then you should have a separate RFC also running as a BCP to detail > > it and updates can be made according to need. > > Correct, although a mboned BCP might not be a bad idea. IMHO Mboned is the correct IETF WG for such a BCP. I just didn't imply the WG to do the BCP in question. Cheers, Magnus From owner-idmr@cs.ucl.ac.uk Fri Jan 19 11:58:21 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02206 for ; Fri, 19 Jan 2001 11:58:21 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 19 Jan 2001 14:57:33 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jan 2001 14:57:26 +0000 Received: from add1.multicasttech.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 19 Jan 2001 14:57:25 +0000 Received: from [216.8.13.92] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 721456; Fri, 19 Jan 2001 09:57:14 -0500 Message-ID: <3A685692.FCDF9157@21rst-century.com> Date: Fri, 19 Jan 2001 10:00:33 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Danielson CC: nickless@mcs.anl.gov, owens@nysernet.org, shep@network-services.uoregon.edu, kthomp@MCI.NET, wg-multicast@internet2.edu, mbone@ISI.EDU, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu Subject: Re: MSDP Storm References: <4.3.2.7.2.20010117180104.028047e0@localhost> <20010118174606A.magda@netinsight.se> <3A67386F.D1D5D23B@21rst-century.com> <20010119135439P.magda@netinsight.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello Magnus; Magnus Danielson wrote: > > From: Marshall Eubanks > Subject: Re: MSDP Storm > Date: Thu, 18 Jan 2001 13:39:44 -0500 > > > I would agree. Mischievously, I would point out that there is an IGMP v3 RFC grinding along : > > > > AND a MSDP draft grinding along as well : > > > > > > The actual numbers should never be put into that RFC. If specific numbers are > required, then you should have a separate RFC also running as a BCP to detail > it and updates can be made according to need. Correct, although a mboned BCP might not be a bad idea. > > Generic filters and adaptive functions may be directly specified. > > > This might limit vast multiparty games or videoconferences a little, but would not hinder any SSM type aps I > > can think of at all. The numbers I gave may be too lenient; I was just trying to get some thinking about this started. > > Like allways, picking one single number is allways a tradeoff thing. > > BTW. In this case of the worm... didn't the scanner try to connect to TCP? > I mean, trying to do TCP on _ANY_ multicast address is just bound to be a > looser. A simple filter could (and should) block that. > I do not know, but this is a good point. I can see no reason not to filter TCP. > Cheers, > Magnus -- Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From owner-idmr@cs.ucl.ac.uk Fri Jan 19 11:58:27 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02217 for ; Fri, 19 Jan 2001 11:58:26 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 19 Jan 2001 15:59:22 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jan 2001 15:56:25 +0000 Received: from puck.nether.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 19 Jan 2001 15:56:01 +0000 Received: (from jared@localhost) by puck.nether.net (8.11.1/8.9.3) id f0JFtTv03986; Fri, 19 Jan 2001 10:55:29 -0500 (envelope-from jared) Date: Fri, 19 Jan 2001 10:55:29 -0500 From: Jared Mauch To: Marshall Eubanks Cc: Magnus Danielson , nickless@mcs.anl.gov, owens@nysernet.org, shep@network-services.uoregon.edu, kthomp@mci.net, wg-multicast@internet2.edu, mbone@isi.edu, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu Subject: Re: MSDP Storm Message-ID: <20010119105529.J30254@puck.nether.net> References: <3A67386F.D1D5D23B@21rst-century.com> <20010119135439P.magda@netinsight.se> <3A685692.FCDF9157@21rst-century.com> <20010119173018W.magda@netinsight.se> <3A686238.1F5B0E9A@21rst-century.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A686238.1F5B0E9A@21rst-century.com>; from tme@21rst-century.com on Fri, Jan 19, 2001 at 10:50:15AM -0500 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk On Fri, Jan 19, 2001 at 10:50:15AM -0500, Marshall Eubanks wrote: > Dear Magnus; > > Magnus Danielson wrote: > > > > From: Marshall Eubanks > > Subject: Re: MSDP Storm > > Date: Fri, 19 Jan 2001 10:00:33 -0500 > > > > > Hello Magnus; > > > > Dear Marshall, > > > > > Magnus Danielson wrote: > > > > > > > > From: Marshall Eubanks > > > > Subject: Re: MSDP Storm > > > > Date: Thu, 18 Jan 2001 13:39:44 -0500 > > > > > > > > > I would agree. Mischievously, I would point out that there is an IGMP v3 RFC grinding along : > > > > > > > > > > AND a MSDP draft grinding along as well : > > > > > > > > > > > > > > > > > > The actual numbers should never be put into that RFC. If specific numbers are > > > > required, then you should have a separate RFC also running as a BCP to detail > > > > it and updates can be made according to need. > > > > > > Correct, although a mboned BCP might not be a bad idea. > > > > IMHO Mboned is the correct IETF WG for such a BCP. I just didn't imply the WG > > to do the BCP in question. > > > > My guess is that the numbers will be the hard part. It is easy, after > all, to say > > MSDP neighbors SHALL limit the number of Session Announcements flooded out. > > But it is not transparent (to me, at least) what that limit should be. > Most people running a RP with MSDP will want guidance as to what limit > should be > used and/or what limits are reasonable. The same can be said for IGMP > and PIM. Rate-limiting MSDP messages or doing a per-peer SA limit would be good.. Similar to the way we in the operational world can limit the number of prefixes received, we should be able to limit the maximum number of SA's that we receive from a peer. I can determine that currently there are about 1200 SA's so I can limit each of my eMSDP peers to have only 1200 SA's from them to avoid the 12k SA's I was seeing earlier this week from port scans of 227/8 - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | Manager of IP networks built within my own home From owner-idmr@cs.ucl.ac.uk Fri Jan 19 11:58:33 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 LAA02236 for ; Fri, 19 Jan 2001 11:58:31 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 19 Jan 2001 15:36:12 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jan 2001 15:36:08 +0000 Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jan 2001 15:36:07 +0000 To: Magnus Danielson cc: wg-multicast@internet2.edu, mbone@ISI.EDU, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu Subject: Re: MSDP Storm In-reply-to: Your message of "Fri, 19 Jan 2001 17:30:18 +0100." <20010119173018W.magda@netinsight.se> Date: Fri, 19 Jan 2001 15:36:06 +0000 Message-ID: <14312.979918566@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk In message <20010119173018W.magda@netinsight.se>, Magnus Danielson typed: >>IMHO Mboned is the correct IETF WG for such a BCP. I just didn't imply the WG >>to do the BCP in question. non serious: until we get bidir pim and v6 and remove the need for msdp, best common practice, at least according to many (but not all) ISPs, outside of shared media domains (lans, wireless, satellite, pure optical cores), appears to be not to use multicast :-) aside: would be neat if someone wrote an RTSP/IGMP gateway... cheers jon From owner-idmr@cs.ucl.ac.uk Fri Jan 19 11:58:37 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02265 for ; Fri, 19 Jan 2001 11:58:36 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 19 Jan 2001 15:47:25 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jan 2001 15:47:16 +0000 Received: from add1.multicasttech.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 19 Jan 2001 15:47:05 +0000 Received: from [216.8.13.92] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 721476; Fri, 19 Jan 2001 10:46:56 -0500 Message-ID: <3A686238.1F5B0E9A@21rst-century.com> Date: Fri, 19 Jan 2001 10:50:15 -0500 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Danielson CC: nickless@mcs.anl.gov, owens@nysernet.org, shep@network-services.uoregon.edu, kthomp@MCI.NET, wg-multicast@internet2.edu, mbone@ISI.EDU, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu Subject: Re: MSDP Storm References: <3A67386F.D1D5D23B@21rst-century.com> <20010119135439P.magda@netinsight.se> <3A685692.FCDF9157@21rst-century.com> <20010119173018W.magda@netinsight.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Dear Magnus; Magnus Danielson wrote: > > From: Marshall Eubanks > Subject: Re: MSDP Storm > Date: Fri, 19 Jan 2001 10:00:33 -0500 > > > Hello Magnus; > > Dear Marshall, > > > Magnus Danielson wrote: > > > > > > From: Marshall Eubanks > > > Subject: Re: MSDP Storm > > > Date: Thu, 18 Jan 2001 13:39:44 -0500 > > > > > > > I would agree. Mischievously, I would point out that there is an IGMP v3 RFC grinding along : > > > > > > > > AND a MSDP draft grinding along as well : > > > > > > > > > > > > > > The actual numbers should never be put into that RFC. If specific numbers are > > > required, then you should have a separate RFC also running as a BCP to detail > > > it and updates can be made according to need. > > > > Correct, although a mboned BCP might not be a bad idea. > > IMHO Mboned is the correct IETF WG for such a BCP. I just didn't imply the WG > to do the BCP in question. > My guess is that the numbers will be the hard part. It is easy, after all, to say MSDP neighbors SHALL limit the number of Session Announcements flooded out. But it is not transparent (to me, at least) what that limit should be. Most people running a RP with MSDP will want guidance as to what limit should be used and/or what limits are reasonable. The same can be said for IGMP and PIM. > Cheers, > Magnus -- Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From owner-idmr@cs.ucl.ac.uk Fri Jan 19 12:02:29 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 MAA02416 for ; Fri, 19 Jan 2001 12:02:29 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 19 Jan 2001 15:48:09 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jan 2001 15:47:35 +0000 Received: from mail2.netinsight.se by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 19 Jan 2001 15:47:24 +0000 Received: from localhost (unverified [10.100.1.11]) by ernst.netinsight.se (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 19 Jan 2001 16:47:18 +0100 To: J.Crowcroft@cs.ucl.ac.uk Cc: wg-multicast@internet2.edu, mbone@ISI.EDU, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu Subject: Re: MSDP Storm In-Reply-To: <14312.979918566@cs.ucl.ac.uk> References: <20010119173018W.magda@netinsight.se> <14312.979918566@cs.ucl.ac.uk> X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010119174717K.magda@netinsight.se> Date: Fri, 19 Jan 2001 17:47:17 +0100 From: Magnus Danielson X-Dispatcher: imput version 991025(IM133) Lines: 38 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit From: Jon Crowcroft Subject: Re: MSDP Storm Date: Fri, 19 Jan 2001 15:36:06 +0000 Jon, > > In message <20010119173018W.magda@netinsight.se>, Magnus Danielson typed: > > >>IMHO Mboned is the correct IETF WG for such a BCP. I just didn't imply the WG > >>to do the BCP in question. > > non serious: > > until we get bidir pim and v6 and remove the need for msdp, best > common practice, at least according to many (but not all) ISPs, > outside of shared media domains (lans, > wireless, satellite, pure optical cores), appears to be not to use multicast :-) Certainly, certainly... why in the heavens would such a complex system which is potentially hitting on all core routes while having most questionable user implications be deployed? Serious side: If more people knew about it and actually used it, we just might have better a better situation. Dreams, dreams, dreams... > aside: > > would be neat if someone wrote an RTSP/IGMP gateway... Do you volonteer? (Allways ask someone who proposes some work ;) Cheers, Magnus From owner-idmr@cs.ucl.ac.uk Fri Jan 19 12:06:25 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02495 for ; Fri, 19 Jan 2001 12:06:25 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 19 Jan 2001 16:28:01 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jan 2001 16:19:35 +0000 Received: from postoffice.mail.cornell.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 19 Jan 2001 16:19:25 +0000 Received: from Cornell.edu (pgp1-pc.cit.cornell.edu [128.253.64.20]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id LAA29078; Fri, 19 Jan 2001 11:19:21 -0500 (EST) Message-ID: <3A686907.81EEEF1B@Cornell.edu> Date: Fri, 19 Jan 2001 11:19:19 -0500 From: Philip Pishioneri X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: wg-multicast@internet2.edu CC: mbone@isi.edu, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu Subject: Re: MSDP Storm References: <3A67386F.D1D5D23B@21rst-century.com> <20010119135439P.magda@netinsight.se> <3A685692.FCDF9157@21rst-century.com> <20010119173018W.magda@netinsight.se> <3A686238.1F5B0E9A@21rst-century.com> <20010119105529.J30254@puck.nether.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Jared Mauch wrote: > Rate-limiting MSDP messages or doing a per-peer SA limit > would be good.. Similar to the way we in the operational world can limit > the number of prefixes received, we should be able to limit the maximum > number of SA's that we receive from a peer. Since my site is on an edge, we get most MSDP messages from one peer, so that type of limit wouldn't help as much. How about maximums based on AS and/or net/mask? -Phil From owner-idmr@cs.ucl.ac.uk Sat Jan 20 09:19: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 JAA27962 for ; Sat, 20 Jan 2001 09:19:47 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sat, 20 Jan 2001 12:48:56 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 20 Jan 2001 06:59:54 +0000 Received: from a203-167-249-89.reverse.clear.net.nz by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 20 Jan 2001 06:59:54 +0000 Received: by metastasis.f00f.org (Postfix, from userid 1000) id 68685A452; Sat, 20 Jan 2001 19:59:50 +1300 (NZDT) Date: Sat, 20 Jan 2001 19:59:50 +1300 From: Chris Wedgwood To: Jon Crowcroft Cc: Magnus Danielson , wg-multicast@internet2.edu, mbone@ISI.EDU, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu Subject: Re: MSDP Storm Message-ID: <20010120195950.A1038@metastasis.f00f.org> References: <20010119173018W.magda@netinsight.se> <14312.979918566@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14312.979918566@cs.ucl.ac.uk>; from J.Crowcroft@cs.ucl.ac.uk on Fri, Jan 19, 2001 at 03:36:06PM +0000 X-No-Archive: Yes Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk On Fri, Jan 19, 2001 at 03:36:06PM +0000, Jon Crowcroft wrote: would be neat if someone wrote an RTSP/IGMP gateway... CacheFlow have somethuing like this in their media streaming code I think. --cw From owner-idmr@cs.ucl.ac.uk Mon Jan 22 07:07:33 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01936 for ; Mon, 22 Jan 2001 07:07:33 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 22 Jan 2001 10:19:16 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Jan 2001 10:19:11 +0000 Received: from mail2.netinsight.se by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 22 Jan 2001 10:19:08 +0000 Received: from localhost (unverified [10.100.1.11]) by ernst.netinsight.se (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 22 Jan 2001 09:14:05 +0100 To: tme@21rst-century.com Cc: nickless@mcs.anl.gov, owens@nysernet.org, shep@network-services.uoregon.edu, kthomp@MCI.NET, wg-multicast@internet2.edu, mbone@ISI.EDU, idmr@cs.ucl.ac.uk, msdp@antc.uoregon.edu Subject: Re: MSDP Storm In-Reply-To: <3A686238.1F5B0E9A@21rst-century.com> References: <3A685692.FCDF9157@21rst-century.com> <20010119173018W.magda@netinsight.se> <3A686238.1F5B0E9A@21rst-century.com> X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010122101405U.magda@netinsight.se> Date: Mon, 22 Jan 2001 10:14:05 +0100 From: Magnus Danielson X-Dispatcher: imput version 991025(IM133) Lines: 84 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: MSDP Storm Date: Fri, 19 Jan 2001 10:50:15 -0500 > Dear Magnus; Dear Marshall, > Magnus Danielson wrote: > > > > From: Marshall Eubanks > > Subject: Re: MSDP Storm > > Date: Fri, 19 Jan 2001 10:00:33 -0500 > > > > > Hello Magnus; > > > > Dear Marshall, > > > > > Magnus Danielson wrote: > > > > > > > > From: Marshall Eubanks > > > > Subject: Re: MSDP Storm > > > > Date: Thu, 18 Jan 2001 13:39:44 -0500 > > > > > > > > > I would agree. Mischievously, I would point out that there is an IGMP v3 RFC grinding along : > > > > > > > > > > AND a MSDP draft grinding along as well : > > > > > > > > > > > > > > > > > > The actual numbers should never be put into that RFC. If specific numbers are > > > > required, then you should have a separate RFC also running as a BCP to detail > > > > it and updates can be made according to need. > > > > > > Correct, although a mboned BCP might not be a bad idea. > > > > IMHO Mboned is the correct IETF WG for such a BCP. I just didn't imply the WG > > to do the BCP in question. > > > > My guess is that the numbers will be the hard part. It is easy, after > all, to say > > MSDP neighbors SHALL limit the number of Session Announcements flooded out. Right, please note what I said above... "If specific number are required, then you should have a separate RFC also running as a BCP to detail it and updates can be made according to need.", that is IF we find it necessary. Also, since those numbers would be a Best Current Practice, we say that they are open for changes if the best current practice changes. Your wording above is correct for the MSDP ID/RFC regardless weither there are an BCP or not. Further, I rather propose a dynamic method in which you look back at running statistics of say 60 days and only accept say an excess of 10 % over the extrapolated curve. Something like that. The exact details we can work out, but the need to change numbers becomes far less and the method may be better suited to survive time and exponential growth if the statistical analysis and extrapolation is well selected. In addition to this you could have a hard limit as an option, but I think doing something like this limits the excess in relation to what the box should expect to handle as a normal case. > But it is not transparent (to me, at least) what that limit should be. > Most people running a RP with MSDP will want guidance as to what limit > should be > used and/or what limits are reasonable. The same can be said for IGMP > and PIM. Certainly. I dont like hard limits like those, they are very coarse means of control and needs attention to keep handling the normal case. Thus, a too tight limit may hurt your normal buissness and require manual update on a regular basis. Better to find a suitable method of doing this by automatic means if we could do so. We can however consider to standardize filters such as proposed. However, we should be carefull not to bite our fannies or get our squeeker dysfunctional since rate-limiting a single box at IGMP level could work against the intended working if that box happends to be a application gateway or playback server. There are a few notable applications which could generate many legal IGMP joins. Cheers, Magnus From owner-idmr@cs.ucl.ac.uk Mon Jan 22 10:59:59 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07143 for ; Mon, 22 Jan 2001 10:59:58 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 22 Jan 2001 13:54:00 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Jan 2001 12:18:24 +0000 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 22 Jan 2001 12:18:24 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02171; Mon, 22 Jan 2001 07:18:23 -0500 (EST) Message-Id: <200101221218.HAA02171@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: idmr@cs.ucl.ac.uk From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-igmp-v3-06.txt,.ps Date: Mon, 22 Jan 2001 07:18:23 -0500 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : Internet Group Management Protocol, Version 3 Author(s) : B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan Filename : draft-ietf-idmr-igmp-v3-06.txt,.ps Pages : 50 Date : 19-Jan-01 This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for 'source filtering', that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idmr-igmp-v3-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idmr-igmp-v3-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010119110838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-igmp-v3-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-igmp-v3-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010119110838.I-D@ietf.org> --OtherAccess-- --NextPart--