From owner-idmr@cs.ucl.ac.uk Sun Jul 2 17:35:15 2000 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 RAA10240 for ; Sun, 2 Jul 2000 17:35:14 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sun, 2 Jul 2000 20:02:48 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sun, 2 Jul 2000 20:02:44 +0100 Received: from email-broadcast.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Sun, 2 Jul 2000 20:02:42 +0100 From: grants4u25@usa.net Received: from grants4u25@usa.net by grants4u26@usa.net (8.8.5/8.6.5) with SMTP id GAA05138 for ; Sun, 02 Jul 2000 13:49:36 -0600 (EST) Date: Sun, 02 Jul 00 13:49:36 EST To: grants4u26@usa.net Subject: FREE CASH GRANTS Message-ID: <> Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Dear Consumer > > Every day millions of dollars are given away!!! Our Government > spends billions of tax dollars on government grants. Do you know > that private foundations, trust and corporations are required to give > away a portion of their assets. It does'nt matter, where you live, > your employment status, or if you are broke, retired or living on a > fixed income. There may be a grant for you! > > CASHING IN ON FREE GOVERNMENT GRANTS FOR PERSONAL > NEEDS, BUSINESS, MEDICAL BILLS, EDUCATION, DEBTS AND MORE.... > > How would you like to get $125.000.00 to start your business? You can > use the money to expand, finance equipment, pay salaries, rent and > more. How about $8,000.00 spending money for your personal needs > such as car payments, rent, clothing, credit card debts, home repair, > groceries. Do you need $12,000.00 for education for yourself, or your > children? You can get money for private, secondary and primary school. > There are grants for undergraduate, graduate, professional and foreign > studies and more. > > THE BEST PART IS THAT YOU NEVER HAVE TO PAY IT BACK! > IT IS INTEREST FREE AND NON TAXABLE! NO CREDIT CHECKS, > COSIGNERS, SECURITY DEPOSITS OR COLLATERAL REQUIRED. > There are no strict requirements to meet. If you have a genuine > need, the money can be yours. > > IT'S TIME FOR YOU TO TAKE ADVANTAGE OF THIS COUNTRY'S > BEST KEPT SECRET! > We have made the process easy. We have researched and compiled > a manual that will help you find a grant. > > OUR MANUAL" HOW TO OBTAIN FREE CASH GRANTS" will provide > you with 45 pages of grant sources. We list the foundations name, > address, phone number, contact person and the type of grant they issue. > > QUESTIONS AND ANSWERS > > Q: Is obtaining a cash grant legal? A: It is 100% legal and yours for the asking. The Government wants you to take advantage of their grant > program and our manual will show you how. > > Q: How do I get paid? A: The Government agency will send you an > acceptance letter with your award amount. > > Q: Will bad credit interfere with obtaining a free cash grant? A: NO, > In fact grants are not based on your credit. It is not a loan, even the > unemployed receive grants. > > Q: What is the average grant amount awarded? A: $1,000.00 to > 10,000.00 is average, but it depends on what the grant will be used for. > Businesses that benefit the communities have been awarded $100,000 > to millions in grant money. > > Q: If I obtain your publication manual, am I guaranteed to find a grant? > A: The US Federal Trade Commission warns consumers that no one > can guarantee you a grant, you must apply to the grant offering > foundations, corporations etc.. They will review your request and supply > your grant if your needs meet the requirements of the grant. We do > provide you with a 60 day money back guarantee! This will give you > time to apply for some grants and get a response. > > ACT IN THE NEXT 14 DAYS AND RECEIVE THE > "HOW TO OBTAIN FREE CASH GRANT'S "MANUAL > AND A FREE BONUS, "HOW TO WRITE A WINNING GRANT > PROPOSAL". > > This guide will list the secrets on getting your grant proposal accepted. > RECEIVE ALL THIS FOR THE UNBELIEVABLE LOW PRICE OF > $24.95! ACT NOW!! > > ORDER INFORMATION > > SIMPLY SEND $24.95, CHECK, MONEY ORDER, OR CREDIT CARD > INFORMATION INCLUDE YOUR NAME, ACCOUNT NUMBER, > EXPIRATION DATE, ADDRESS AND PHONE NUMBER. > > TO: QUALITY RESOURSES > 5399 EAST HWY C30-A #242 SEAGROVE BEACH, FL 32459 > This mailing is done by an independent marketing co. > We apologize if this message has reached you in error. > Save the Planet, Save the Trees! Advertise via E mail. > No wasted paper! Delete with one simple keystroke! > Less refuse in our Dumps! This is the new way of > the new millennium! > > To be removed midwest12@dcemail.com From owner-idmr@cs.ucl.ac.uk Tue Jul 4 03:07:55 2000 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 DAA25465 for ; Tue, 4 Jul 2000 03:07:54 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 4 Jul 2000 05:18:10 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 4 Jul 2000 05:18:06 +0100 Received: from cindy.yamato.ibm.co.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 4 Jul 2000 05:18:06 +0100 Received: from kyoto.yamato.ibm.com (kyoto3.yamato.ibm.com [9.68.3.1]) by cindy.yamato.ibm.co.jp (8.9.3/3.7W/GW3.3) with ESMTP id NAA62864 for ; Tue, 4 Jul 2000 13:18:03 +0900 Received: from localhost (ymtlogin1.yamato.ibm.com [9.68.80.207]) by kyoto.yamato.ibm.com (8.8.8/MS2.00) with ESMTP id NAA08952 for ; Tue, 4 Jul 2000 13:18:02 +0900 To: idmr@cs.ucl.ac.uk Subject: igmpv3 query num should be changed? X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000704131802M.asaeda@yamato.ibm.com> Date: Tue, 04 Jul 2000 13:18:02 +0900 (JST) From: Hitoshi Asaeda X-Dispatcher: imput version 980905(IM100) Lines: 42 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi all. I have a question/comment about IGMPv3's query type. Current v3's spec (igmp-v3-04) says; 7.1. Query Version Distinctions The IGMP version of a Membership Query message is determined as follows: IGMPv1 Query: length = 8 octets AND Max Response Time field is zero IGMPv2 Query: length = 8 octets AND Max Response Time field is non-zero IGMPv3 Query: length >= 12 octets Query messages that do not match any of the above conditions (e.g., a Query of length 10 octets) MUST be silently ignored. However, IGMPv2's RFC (RFC2236) says; 2.5. Other fields Note that IGMP messages may be longer than 8 octets, especially future backwards-compatible versions of IGMP. As long as the Type is one that is recognized, an IGMPv2 implementation MUST ignore anything past the first 8 octets while processing the packet. However, the IGMP checksum is always computed over the whole IP payload, not just over the first 8 octets. This means "IGMPv2 query message should not be discarded even if the length of the query message is longer than 8 octets. The tail starting from 8 octets of the message just can be ignored after calculating its checksum". Actually, BSD's kernel implements this way as IGMPv2's query handler. From now on, due to the backward compativility, IGMPv3's query type had better be changed from 0x11 to another unique number. Comments? -- Hitoshi Asaeda From owner-idmr@cs.ucl.ac.uk Tue Jul 4 15:15:17 2000 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 PAA00135 for ; Tue, 4 Jul 2000 15:15:16 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 4 Jul 2000 17:45:58 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 4 Jul 2000 17:45:54 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 4 Jul 2000 17:45:53 +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 BABE44CE05; Tue, 4 Jul 2000 12:45:53 -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 MAA13970; Tue, 4 Jul 2000 12:45:53 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA11234; Tue, 4 Jul 2000 09:45:52 -0700 (PDT) Message-Id: <200007041645.JAA11234@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: asaeda@yamato.ibm.co.jp Subject: Re: igmpv3 query num should be changed? Cc: idmr@cs.ucl.ac.uk Date: Tue, 4 Jul 2000 09:45:51 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk The backwards compatability mechanisms require that IGMPv2 systems recognize IGMPv3 Queries in the same was as IGMPv2 Queries (in the same way that IGMPv2's Queries must be recognized by IGMPv1 hosts as IGMPv1 Queries). Bill From owner-idmr@cs.ucl.ac.uk Tue Jul 4 23:28:37 2000 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 XAA04424 for ; Tue, 4 Jul 2000 23:28:36 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 5 Jul 2000 02:02:23 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Jul 2000 02:02:19 +0100 Received: from cindy.yamato.ibm.co.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 5 Jul 2000 02:02:18 +0100 Received: from kyoto.yamato.ibm.com (kyoto3.yamato.ibm.com [9.68.3.1]) by cindy.yamato.ibm.co.jp (8.9.3/3.7W/GW3.3) with ESMTP id KAA65778; Wed, 5 Jul 2000 10:02:15 +0900 Received: from localhost (ymtlogin1.yamato.ibm.com [9.68.80.207]) by kyoto.yamato.ibm.com (8.8.8/MS2.00) with ESMTP id KAA58174; Wed, 5 Jul 2000 10:02:11 +0900 To: fenner@research.att.com Cc: idmr@cs.ucl.ac.uk Subject: Re: igmpv3 query num should be changed? In-Reply-To: Your message of "Tue, 4 Jul 2000 09:45:51 -0700" <200007041645.JAA11234@windsor.research.att.com> References: <200007041645.JAA11234@windsor.research.att.com> X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000705100211E.asaeda@yamato.ibm.com> Date: Wed, 05 Jul 2000 10:02:11 +0900 (JST) From: Hitoshi Asaeda X-Dispatcher: imput version 980905(IM100) Lines: 13 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit > The backwards compatability mechanisms require that IGMPv2 systems > recognize IGMPv3 Queries in the same was as IGMPv2 Queries (in the > same way that IGMPv2's Queries must be recognized by IGMPv1 hosts > as IGMPv1 Queries). Ok. I should not use the word, "backwards", here. Anyway, you would say "IGMPv3 system may not recognize IGMPv2 Queries. It is enough for IGMPv3 spec to care just about *backwards* compatibility."? Is there any reason not to use unique number for IGMPv3's query? -- Hitoshi Asaeda From owner-idmr@cs.ucl.ac.uk Wed Jul 5 10:56:33 2000 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 KAA07746 for ; Wed, 5 Jul 2000 10:56:31 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 5 Jul 2000 13:18:46 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Jul 2000 13:18:41 +0100 Received: from nscolmar.colmar.uha.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 5 Jul 2000 13:18:41 +0100 Received: from colmar.colmar.uha.fr (colmar.colmar.uha.fr [194.167.107.31]) by nscolmar.colmar.uha.fr (8.9.3/8.9.3) with ESMTP id NAA31781; Wed, 5 Jul 2000 13:44:52 +0200 From: conf@colmar.uha.fr Received: from gtrpc13 (gtrpc13.colmar.uha.fr [192.168.12.51]) by colmar.colmar.uha.fr (8.8.8/8.8.8) with SMTP id OAA25648; Wed, 5 Jul 2000 14:03:43 +0100 (WET DST) Message-Id: <3.0.1.32.20000705150859.009216a0@colmar.colmar.uha.fr> X-Sender: conf@colmar.colmar.uha.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Wed, 05 Jul 2000 15:08:59 +0200 To: conf@colmar.colmar.uha.fr Subject: Call for Papers of ICATM01 Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: quoted-printable Please feel free to circulate this following preliminary program of ICATM01 to interested colleagues (see http://iutsun1.colmar.uha.fr/ICATM01.html for more information).=20 Accept our sincere apologies if you receive multiple copies. ----------------------------------------------------------------------------= ----------- =20
Preliminary Call For Papers =20 Conference on Intelligent Networks, IP over ATM and Quality of Services=20 Joint 4th International Conference on ATM and High Speed Internet (ICATM'01)=20 April 23-25, 2001=20 Olympic Parktel, Seoul, Korea
=20 GENERAL INFORMATION=20 The 2001 IEEE International Conference on ATM (ICATM'01) is sponsored by the IEEE, IEE and WSES. ICATM'01 is organized by academic, research and industrial societies will be held at Olympic Parktel, Seoul, http://metro.seoul.kr , Korea, from Monday April 23, 2001 to Wednesday April 25, 2001 plus Tutorials on Sunday April 22, 2001. The Olympic Park is situated at the city of Seoul where the Olympic game was helid in 1988, about 20 km(14 miles) north-east of KIMPO International Airport. Seoul, the metropolitan captical of Korea located almost in the center of the Korean peninsula, has been the hub of the nation's politics, economy, culture and transportation. Seoul covers a total of about 600km2, with a population of more than 10 million. Just a few steps from many hotels in the downtown is Toksugung Palace, Ch'angdokkung Palace, Piwon, the Secret Garden, and much more historical/cultural sites to visit. Seoul hosts a variety of symphony concerts, operas, and recitals by local and visiting musicians. The Seoul Arts Center in the southern part of Seoul, the Sejong Cultural Center, located on the main thoroughfare in downtown Seoul, the National Theatre in Namsan Park, and the Hoam Art Hall near the City Hall offer a wide range of cultural programs and performances. There are few cities in the world where the ultra-modern and the ancient exist side by side in such perfect harmony. Today, Seoul is a teeming metropolis with many first-class Western-style hotels. English is spoken at many shops, bars, and restaurants. For traveling major cities of Korea; by Air, there are two domestic Airlines: KAL(=3DKorean Air), http://www.koreanair.com and Asiana Airline, http://www.asiana.co.kr . Most of major cities can be reached within an hour by Air.=20 By Rail, there are three type trains: Tong-il (twice per day), Mugunghwa (four times per day) and Saemaul (twice per day). The Saemaul train is the fastest one and takes you major cities within 5 hour 30 minutes time from SEOUL and the Mugunghwa would take about 6-hour time frame to reach at any cities. We do not recommend Tong-il train since it is a slow train which stops at each local areas. Many major cities are all within a day's reach. One can learn more about Seoul in the Website, http://metro.seoul.kr and apersonal prestige, but innate place, That is Seoul, the center of the Korean peninsula. We salute you all.=20 In order to encourage closer interaction between academic and industrial ATM research communities, we solicit both academic research papers and industrial contributions.=20 TOPICS OF SPECIAL INTEREST=20 Topics of interest include, but are not limited to the following:=20 Traffic models=20 LAN Emulation=20 IP over ATM, IPv6 over ATM=20 VLANs=20 High-Speed Routing=20 I-PNNI, NHRP=20 Java, Tina, Corba architectures=20 Interconnection=20 Network Management, performance=20 CTI (Computer Telephony Integration)=20 Multicast ATM and Internet/Intranet IP and ATM over xDSL=20 Security=20 IP and ATM Telephony=20 Practical experiences results=20 User applications=20 Video (Davic, ...)=20 QoS=20 WDM=20 Optical Switching=20 Scheduling & Resource allocation=20 Services over ATM MPOA, IP Switching, MPLS, Tag Switching, Fast IP, Aris ...=20 Wireless ATM (LEO,MEO GEO, from GSM to UMTS and IMT2000 Hyperlan2, ...) These topics can be discussed in term of concepts, state of the art, standards, implementations, performance, security and confidentiality, traffic management, running experiments, QoS (Quality of Service) and applications.=20 INSTRUCTIONS FOR AUTHORS=20 Mail four copies of a full paper which should be no longer than 10 pages or an extended abstract summarizing an original work. All the manuscripts must be written in English. The top of the first page of each paper should include the title of the paper, authors' name, position, address, telephone and fax numbers, e-mail of the author responsible for correspondence and a list of four keywords.=20 Electronic submissions are strongly encouraged. Acceptable formats are PDF, Postscript, RTF, Word 97. Please use A4 paper format when formatting your submission! Authors of accepted papers will later be required to submit a IEEE copyright form, please assure that you have all necessary authorizations in place. Typing instructions for accepted full papers can be downloaded from http://dongshinu.ac.kr/~idec_du.=20 The deadline for submission of all extended abstracts is September 10, 2000 with notification of acceptance by November 10, 2000. Submission of camera-ready paper is by January 10, 2001.=20 Authors of accepted papers will be invited to submit full-length manuscripts for inclusion in the proceedings.=20 All submitted papers should be sent to the following address:=20 For the worldwide:=20 Mike Myung-Ok LEE=20 IDEC=20 Dongshin University=20 252 Daeho-Dong, Naju=20 Chonnam, 520-714 Korea=20 Phone:82(0)613-330-3195 Fax:82(0)613-330-2911 Mobile:82(0)16-612-2925=20 E-mail: mikelee@dongshinu.ac.kr=20 For Europe :=20 Pascal LORENZ=20 University of Haute Alsace=20 IUT - Department GTR=20 34 rue du Grillenbreit=20 68008 Colmar, France=20 Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042=20 E-mail: lorenz@colmar.uha.fr=20 You can learn more in our Web page at http://dongshinu.ac.kr/~idec_du/ICATM01.html for the latest information concerning the conference.=20 Best papers will be forwarded for consideration in a special issue of the journal Telecommunication Systems published by Baltzer Science Publishers.=20 TUTORIALS AND WORKSHOPS=20 Tutorials and workshops provide overviews of current high interest topics. Proposals for half of full day tutorials are due by September 10, 2000.=20 INTERNATIONAL ADVISORY COMMITTEE=20 R. Addie (Australia) - University of Southern Queensland=20 K. Begain (Jordan) - Mu'tah University=20 A. Benslimane (France) - University of Belfort=20 B. Bing (Singapore) - Ngee Ann Polytechnic=20 D. Bonjour (France) - CNET=20 A. Brandwajn (USA) - University of California Santa Cruz=20 J.P. Coudreuse (France) Mitsubishi=20 J. Crowcroft (UK) University College London=20 B. Gavish (USA) - Vanderbilt University=20 J. Halpern (USA) Newbridge=20 Z. Hulicki (Poland) University of Cracow=20 R. Israel (France) - IEEE=20 S. Komandur (USA) - Ascend Communications=20 D. Kouvatsos (UK) - University of Bradford=20 S. Kumar (USA) Ericsson=20 G.S. Kuo (Taiwan) National Central University=20 F. Le Faucheur (France) - Cisco=20 M. Lee (Korea) Dongshin University=20 P. Lorenz (France) - University of Haute Alsace=20 G. Omidyar (USA) - Computer Sciences Corp.=20 J.J. Pansiot (France) - University of Strasbourg=20 M. Potts (Switzerland) - Martel=20 Z. Mammeri (France) - University of Toulouse=20 N. Mastorakis (Greece) - Military Institutions of University Education=20 S. Moyer (USA) - Bellcore=20 R. Muraine (France) - Newbridge=20 G. Pujolle (France) - University of Versailles-Saint-Quentin=20 S. Rao (Switzerland) - Ascom=20 A. Reid (UK) - British Telecom=20 S. Ritzenthaler (France) - Newbridge=20 P. Rolin (France) - ENST Bretagne=20 R. Saracco (Italy) - CSELT=20 G. Swallow (USA) - Cisco=20 H. Tobiet (France) Clemessy=20 V.A. Villagra (Spain) University of Madrid=20 E. Vazquez Gallo (Spain) University of Madrid=20 IMPORTANT DATES=20 Extended Abstract due: September 10, 2000=20 Notification of acceptance: November 10, 2000=20 Deadline for full-length camera-ready manuscript: January 10, 2001=20 From owner-idmr@cs.ucl.ac.uk Thu Jul 6 12:55:05 2000 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 MAA20883 for ; Thu, 6 Jul 2000 12:55:05 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 6 Jul 2000 15:12:46 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 6 Jul 2000 15:12:43 +0100 Received: from p-biset.issy.cnet.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 6 Jul 2000 15:12:43 +0100 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <3JZBH9C6>; Thu, 6 Jul 2000 16:12:45 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D82094F9C@lat3721.lannion.cnet.fr> From: LEVIS Pierre FTRD/DMI/CAE To: idmr@cs.ucl.ac.uk Subject: idmr archive access Date: Thu, 6 Jul 2000 16:11:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi all, I can't access the idmr mailing list archive, I've picked up the following URL from the IETF charter page: http://www.jnx.com/~pusateri/idmr Is there a current known problem with this address ? Pierre --- Pierre LEVIS - FRANCE TELECOM R&D/DMI/SIR 42 rue des Coutures - BP 6243 - 14066 Caen Cedex 4 - France Tel : 02 31 75 91 04 - Fax : 02 31 73 56 26 Mail : pierre.levis@francetelecom.fr From owner-idmr@cs.ucl.ac.uk Fri Jul 7 00:21:14 2000 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 AAA02900 for ; Fri, 7 Jul 2000 00:21:14 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 7 Jul 2000 03:04:50 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 7 Jul 2000 03:04:46 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 7 Jul 2000 03:04:46 +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 4B88B1E008; Thu, 6 Jul 2000 22:04:46 -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 WAA05243; Thu, 6 Jul 2000 22:04:45 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id TAA17622; Thu, 6 Jul 2000 19:04:45 -0700 (PDT) Message-Id: <200007070204.TAA17622@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pierre.levis@rd.francetelecom.fr Subject: Re: idmr archive access Cc: idmr@cs.ucl.ac.uk Date: Thu, 6 Jul 2000 19:04:44 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Yes, those archives went down. If you are interested in archives from less than a year ago, see ftp://ftp.ietf.org/ietf-mail-archive/idmr/ Bill From owner-idmr@cs.ucl.ac.uk Fri Jul 7 14:30:50 2000 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 OAA09038 for ; Fri, 7 Jul 2000 14:30:49 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 7 Jul 2000 17:14:50 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 7 Jul 2000 17:14:46 +0100 Received: from ns2.eur-o-ne.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 7 Jul 2000 17:14:44 +0100 Received: (qmail 4877 invoked by uid 0); 7 Jul 2000 16:08:06 -0000 Date: 7 Jul 2000 16:08:06 -0000 Message-ID: <20000707160806.4876.qmail@ns2.eur-o-ne.net> To: idmr@cs.ucl.ac.uk Subject: Free (public) service authorized by luxbg.Governement / I.L.T NrEUO-SN07-01 from March 28th ,2000: "EUROPEAN WHITE and YELLOW PAGES " From: info@eur-o-ne.com Reply-To: info@eur-o-ne.com X-Mailer: Eur-O-ne Php-Mailer MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit

FIND THE IMPOSSIBLE


Increase the efficiency and performance of your e-mail and that of your friends and business partners.
Subscribe now to the first official Pan-European e-mail directories
Whether in the white or yellow pages or both, subscription is completely without risk and free of charge
Feel free to enter our site for more information
Please click here to enter:

http://www.eur-o-ne.com

http://www.eurowhite.com  http://www.euroyellow.com



COMPLETE - EASY - TARGETED - PRECISE - ESSENTIAL

 From owner-idmr@cs.ucl.ac.uk Mon Jul 10 22:37:25 2000 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 WAA05676 for ; Mon, 10 Jul 2000 22:37:25 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 11 Jul 2000 00:29:03 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 11 Jul 2000 00:28:58 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 11 Jul 2000 00:29:00 +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 F09371E01D for ; Mon, 10 Jul 2000 19:28:59 -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 TAA07564 for ; Mon, 10 Jul 2000 19:28:56 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA19402; Mon, 10 Jul 2000 16:28:55 -0700 (PDT) Message-Id: <200007102328.QAA19402@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idmr@cs.ucl.ac.uk Subject: Please submit agenda items for IDMR in Pittsburgh Date: Mon, 10 Jul 2000 16:28:55 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Anyone have any agenda items for the IDMR meeting in Pittsburgh? Thanks, Bill From owner-idmr@cs.ucl.ac.uk Tue Jul 11 08:31:40 2000 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 IAA27951 for ; Tue, 11 Jul 2000 08:31:40 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 11 Jul 2000 11:32:44 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 11 Jul 2000 11:32:40 +0100 Received: from wodc7-2.corprelay.mail.uu.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 11 Jul 2000 11:32:42 +0100 Received: from neserve0.corp.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQixje10277; Tue, 11 Jul 2000 10:32:42 GMT Received: by neserve0.corp.us.uu.net id QQixje05591; Tue, 11 Jul 2000 06:32:28 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Please submit agenda items for IDMR in Pittsburgh In-Reply-To: <200007102328.QAA19402@windsor.research.att.com> from Bill Fenner at "Jul 10, 2000 04:28:55 pm" To: Bill Fenner Date: Tue, 11 Jul 2000 06:32:28 -0400 (EDT) CC: idmr@cs.ucl.ac.uk X-Mailer: ELM [version 2.4ME+ PL60 (25)] 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 How about a multicast party. _J In the new year, Bill Fenner wrote: > > Anyone have any agenda items for the IDMR meeting in Pittsburgh? > > Thanks, > Bill > From owner-idmr@cs.ucl.ac.uk Wed Jul 12 09:08:08 2000 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 JAA20767 for ; Wed, 12 Jul 2000 09:08:08 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 12 Jul 2000 11:31:48 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Jul 2000 11:31:41 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 12 Jul 2000 11:31:30 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15100; Wed, 12 Jul 2000 06:31:28 -0400 (EDT) Message-Id: <200007121031.GAA15100@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-mib-14.txt Date: Wed, 12 Jul 2000 06:31:28 -0400 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 MIB Author(s) : K. McCloghrie, D. Farinacci, D. Thaler Filename : draft-ietf-idmr-igmp-mib-14.txt Pages : 21 Date : 11-Jul-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-mib-14.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-mib-14.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-mib-14.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: <20000711134940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-igmp-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-igmp-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711134940.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Wed Jul 12 09:09:32 2000 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 JAA20816 for ; Wed, 12 Jul 2000 09:09:30 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 12 Jul 2000 11:31:52 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Jul 2000 11:31:43 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 12 Jul 2000 11:31:34 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15114; Wed, 12 Jul 2000 06:31:33 -0400 (EDT) Message-Id: <200007121031.GAA15114@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-pim-mib-11.txt Date: Wed, 12 Jul 2000 06:31:33 -0400 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 : Protocol Independent Multicast MIB for IPv4 Author(s) : K. McCloghrie, D. Farinacci, D. Thaler, B. Fenner Filename : draft-ietf-idmr-pim-mib-11.txt Pages : 32 Date : 11-Jul-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-pim-mib-11.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-pim-mib-11.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-pim-mib-11.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: <20000711134952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-pim-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-pim-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711134952.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Wed Jul 12 09:09:48 2000 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 JAA20827 for ; Wed, 12 Jul 2000 09:09:47 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 12 Jul 2000 11:31:28 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Jul 2000 11:31:24 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 12 Jul 2000 11:31:25 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15086; Wed, 12 Jul 2000 06:31:24 -0400 (EDT) Message-Id: <200007121031.GAA15086@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-multicast-routmib-14.txt Date: Wed, 12 Jul 2000 06:31:23 -0400 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 : IPv4 Multicast Routing MIB Author(s) : K. McCloghrie, D. Farinacci, D. Thaler Filename : draft-ietf-idmr-multicast-routmib-14.txt Pages : 33 Date : 11-Jul-00 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-multicast-routmib-14.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-multicast-routmib-14.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-multicast-routmib-14.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: <20000711134928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-multicast-routmib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-multicast-routmib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711134928.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Wed Jul 12 21:02:13 2000 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 VAA19488 for ; Wed, 12 Jul 2000 21:02:13 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 12 Jul 2000 23:44:21 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Jul 2000 23:44:17 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 12 Jul 2000 23:44:19 +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 841FB4CE1D for ; Wed, 12 Jul 2000 18:44:18 -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 SAA07011 for ; Wed, 12 Jul 2000 18:44:17 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA20540; Wed, 12 Jul 2000 15:44:14 -0700 (PDT) Message-Id: <200007122244.PAA20540@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idmr@cs.ucl.ac.uk Subject: WG Last Call: IGMP Version 3 to Proposed Standard Date: Wed, 12 Jul 2000 15:44:14 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Dear IDMR WG, This is a 2 week Working Group Last Call for IGMP Version 3, draft-ietf-idmr-igmp-v3-04.txt, to Proposed Standard. Title : Internet Group Management Protocol, Version 3 Author(s) : B. Cain, S. Deering, I. Kouvelas, A. Thyagarajan Filename : draft-ietf-idmr-igmp-v3-04.txt Pages : 44 Date : 05-Jun-00 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. Please comment by Wednesday, July 26, 2000, on the IDMR mailing list or directly to working group chair, . Thanks, Bill From owner-idmr@cs.ucl.ac.uk Thu Jul 13 05:12:35 2000 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 FAA10480 for ; Thu, 13 Jul 2000 05:12:35 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 08:22:16 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 08:22:12 +0100 Received: from c1mailgw3.prontomail.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 08:22:15 +0100 Received: from c1web01 (208.178.29.201) by c1mailgw3.prontomail.com (NPlex 4.5.049) id 3969EAB300058465; Thu, 13 Jul 2000 00:22:08 -0700 X-Version: indya 6.2.3 .2329.0 From: vijayc@indya.com Message-Id: <22E5563C62854D1178230005B823A263@vijayc.indya.com> Date: Thu, 13 Jul 2000 12:59:33 +0530 X-Priority: Normal Content-Type: text/plain; charset=iso-8859-1 To: fenner@research.att.com Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard CC: idmr@cs.ucl.ac.uk X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, IGMPv3 is not capable of network filtering.Will this level of filtering be needed by hosts to say that' I want packets only from net x.y'. If so, can this feature be included in v3 before standardising it. Regards, Vijay Sent by Indya Messaging Service From owner-idmr@cs.ucl.ac.uk Thu Jul 13 05:13:04 2000 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 FAA10497 for ; Thu, 13 Jul 2000 05:13:03 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 08:51:38 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 08:51:32 +0100 Received: from usc.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 08:51:34 +0100 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.72.78]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id AAA21816; Thu, 13 Jul 2000 00:51:34 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id AAA27113; Thu, 13 Jul 2000 00:51:32 -0700 (PDT) Date: Thu, 13 Jul 2000 00:51:32 -0700 (PDT) From: helmy To: fenner@research.att.com cc: idmr@cs.ucl.ac.uk Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard In-Reply-To: <22E5563C62854D1178230005B823A263@vijayc.indya.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi Bill, Does IGMPv3 currently support any interface (perhaps 1 bit, or..) such that a receiver can say 'join to the SPT directly' even if the underlying protocol supports a center (i.e., RP for PIM-SM) ? or anything to that effect? Regards, -Ahmed From owner-idmr@cs.ucl.ac.uk Thu Jul 13 05:15:48 2000 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 FAA10514 for ; Thu, 13 Jul 2000 05:15:47 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 08:09:47 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 08:09:43 +0100 Received: from 202.54.69.9 by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 08:09:43 +0100 Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id MAA16947; Thu, 13 Jul 2000 12:36:34 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma016939; Thu, 13 Jul 00 12:36:05 +0530 Received: from manib ([192.168.162.199]) by bhairavi.wipsys.soft.net (Netscape Messaging Server 3.6) with SMTP id AAA7137 for ; Thu, 13 Jul 2000 12:35:26 +0530 Message-ID: <00db01bfec9a$312832e0$c7a2a8c0@wipsys.soft.net> From: Mani Manoharan Balaraman To: idmr Subject: Standardisation of IGMPv3 Date: Thu, 13 Jul 2000 12:45:57 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed ; boundary="----=_NextPart_000_00D8_01BFECC8.4A9D4B60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00D8_01BFECC8.4A9D4B60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, With regard to standardisation IGMPv3. Currently IGMPv3 does only source filtering. There is no network = filtering/netmask. In future, there may be a need to do this kind of = network filtering by including network mask. Already, there are some = issues in interoperating with v1 and v2. Hence I think it would be = better to include network level filtering also in v3 before = standardisating it. Mani ------=_NextPart_000_00D8_01BFECC8.4A9D4B60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 With regard to standardisation=20 IGMPv3.
 Currently IGMPv3 does only source = filtering.=20 There is no network filtering/netmask. In future, there may be a need to = do this=20 kind of network filtering by including network mask. Already, there are = some=20 issues in interoperating with v1 and v2. Hence I think it would be = better to=20 include network level filtering also in v3 before standardisating=20 it.
 
Mani
------=_NextPart_000_00D8_01BFECC8.4A9D4B60-- From owner-idmr@cs.ucl.ac.uk Thu Jul 13 08:37:31 2000 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 IAA15850 for ; Thu, 13 Jul 2000 08:37:30 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 11:29:02 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 11:28:58 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 11:28:49 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11354; Thu, 13 Jul 2000 06:28:48 -0400 (EDT) Message-Id: <200007131028.GAA11354@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-membership-reports-05.txt,.ps Date: Thu, 13 Jul 2000 06:28:48 -0400 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 : Domain Wide Multicast Group Membership Reports Author(s) : B. Fenner Filename : draft-ietf-idmr-membership-reports-05.txt,.ps Pages : 16 Date : 12-Jul-00 When running a multi-level multicast routing protocol, upper levels need to know about group memberships in lower levels in a protocol- independent fashion. Domain Wide Multicast Group Membership Reports allow this information to be learned in a fashion similar to IGMP[Fenn97] at the domain level. This document is a product of the IDMR 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 author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-membership-reports-05.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-membership-reports-05.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-membership-reports-05.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: <20000712140616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-membership-reports-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-membership-reports-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712140616.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Thu Jul 13 14:17:36 2000 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 OAA03857 for ; Thu, 13 Jul 2000 14:17:35 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 16:38:13 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 16:38:09 +0100 Received: from mail1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 16:38:10 +0100 Received: from bwilliam-8000.cisco.com (rtp-dial-2-25.cisco.com [10.83.96.25]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA06740; Thu, 13 Jul 2000 08:37:04 -0700 (PDT) Message-Id: <4.3.2.7.2.20000713103256.02a7fbf0@sj-email.cisco.com> X-Sender: bwilliam@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Jul 2000 10:35:52 -0700 To: Bill Fenner , Mani Manoharan Balaraman , idmr From: Beau Williamson Subject: Re: Standardisation of IGMPv3 In-Reply-To: <00db01bfec9a$312832e0$c7a2a8c0@wipsys.soft.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1273792==_.ALT" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk --=====================_1273792==_.ALT Content-Type: text/plain; charset="us-ascii" Bill, et al, This point has been made by several others and I think is quite valid. I'd personally prefer that we add the ability to specify a mask before going to Last Call. Beau Williamson At 12:15 AM 7/13/2000, Mani Manoharan Balaraman wrote: >Hi all, > With regard to standardisation IGMPv3. > Currently IGMPv3 does only source filtering. There is no network filtering/netmask. In future, there may be a need to do this kind of network filtering by including network mask. Already, there are some issues in interoperating with v1 and v2. Hence I think it would be better to include network level filtering also in v3 before standardisating it. > >Mani > >Hi all, > With regard to standardisation IGMPv3. > Currently IGMPv3 does only source filtering. There is no network filtering/netmask. In future, there may be a need to do this kind of network filtering by including network mask. Already, there are some issues in interoperating with v1 and v2. Hence I think it would be better to include network level filtering also in v3 before standardisating it. > >Mani --=====================_1273792==_.ALT Content-Type: text/html; charset="us-ascii" Bill, et al,

This point has been made by several others and I think is quite valid.  I'd personally prefer that we add the ability to specify a mask before going to Last Call.

Beau Williamson
At 12:15 AM 7/13/2000, Mani Manoharan Balaraman wrote:
Hi all,
 With regard to standardisation IGMPv3.
 Currently IGMPv3 does only source filtering. There is no network filtering/netmask. In future, there may be a need to do this kind of network filtering by including network mask. Already, there are some issues in interoperating with v1 and v2. Hence I think it would be better to include network level filtering also in v3 before standardisating it.

Mani

Hi all,
 With regard to standardisation IGMPv3.
 Currently IGMPv3 does only source filtering. There is no network filtering/netmask. In future, there may be a need to do this kind of network filtering by including network mask. Already, there are some issues in interoperating with v1 and v2. Hence I think it would be better to include network level filtering also in v3 before standardisating it.
 
Mani
--=====================_1273792==_.ALT-- From owner-idmr@cs.ucl.ac.uk Thu Jul 13 14:17:43 2000 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 OAA03868 for ; Thu, 13 Jul 2000 14:17:42 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 19:14:26 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 19:14:22 +0100 Received: from adsl-63-196-11-252.dsl.snfc21.pacbell.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 19:14:22 +0100 Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1]) by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id LAA20482; Thu, 13 Jul 2000 11:14:03 -0700 (PDT) (envelope-from mjh@hazard.aciri.org) From: Mark Handley X-Organisation: ACIRI To: Bill Fenner cc: Mani Manoharan Balaraman , idmr , Beau Williamson Subject: Re: Standardisation of IGMPv3 Date: Thu, 13 Jul 2000 11:14:03 -0700 Message-ID: <20480.963512043@hazard.aciri.org> Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >This point has been made by several others and I think is quite >valid. I'd personally prefer that we add the ability to specify a >mask before going to Last Call. Bill, I'd like to voice a different viewpoint. I'm unconvinced that adding a mask is a good idea for a number of reasons: - It would complicate the IGMPv3 machinery (which is already pretty complex) because you'd have to resolve mismatched masks. Eg one host specifies "Exclude (128.1.0.0/16, G)" another host specifies "Exclude (128.1.2.0/24, G)". - You also have to cope with nested include and exclude masks. Eg one host specifies "Exclude (128.1.0.0/16, G)" and another host specifies "Include (128.1.2.0/24, G)". For IGMPv3, this is additional complexity. If you want to map this into PIM this would want to map into two Prune *ranges* - you can't implement this with a single mask, so you'd actually need a large number Prune mask entries (Prune(128.1.0.0/23,G) , Prune(128.1.3.0/24,G), Prune(128.1.4.0/22,G), etc). Do (S-mask,G) prune entries actually work in PIM? The packet format allows it.... If the router doesn't try and map (S-mask,G) IGMP exclude messages into (S-mask,G) Prune messages, then the purpose of (S-mask,G) IGMP exclude messages is kind of lost. Anyone spoofing from all the addresses on a subnet will generate a small amount of local-area IGMP exclude traffic which gets mapped into a large amount of wide-area PIM prune traffic. Thus the optimization doesn't seem worthwhile. - It requires the API be extended to allow apps to specify masks. For exclude masks, there doesn't seem to be any practical way the app can use the mask. It's never going to be told by a misbehaving sender what the correct netmask is, and it's increasingly unlikely to be able to guess correctly. - If the IGMPv3 host specifies an include netmask that is too large, how do you implement this in PIM? Do you route an (S-mask,G) Join to the place where the routes diverge, and then have to split the Join to go multiple ways? I guess you'd have an issue if someone specifies "Include 192.1.0.0/16" for example. If the router doesn't try and map (S-mask,G) IGMP include messages into (S-mask,G) Join messages or a large number of (S,G) Join messages, then I don't think (S-mask,G) IGMP include messages serve any purpose whatsoever. The receiver simply won't get the traffic they asked for. I guess you could do a (*,G) Join, and then have the router generate the (S,G,rpt) Prunes for unwanted sources, but the host can just as well do this with the current IGMPv3. In general, I think this raises too many complexities for what seems to me to be too little gain, so that it just doesn't seem worthwhile. It's likely to add significant delay to standardizing and deploying SSM, and that seems to be a bad tradeoff to me. Cheers, Mark From owner-idmr@cs.ucl.ac.uk Thu Jul 13 17:09:43 2000 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 RAA01870 for ; Thu, 13 Jul 2000 17:09:42 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 20:57:34 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 20:57:29 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 20:57:32 +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 777921E02C; Thu, 13 Jul 2000 15:57:30 -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 PAA28783; Thu, 13 Jul 2000 15:57:30 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA29949; Thu, 13 Jul 2000 12:57:26 -0700 (PDT) Message-Id: <200007131957.MAA29949@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: helmy@ceng.usc.edu Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard Cc: idmr@cs.ucl.ac.uk Date: Thu, 13 Jul 2000 12:57:26 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk > Does IGMPv3 currently support any interface (perhaps 1 bit, >or..) such that a receiver can say 'join to the SPT directly' even if the >underlying protocol supports a center (i.e., RP for PIM-SM) ? >or anything to that effect? This is supported only implicitly. Consider a stub network, for simplicity. If a host sends an inclusion report for a single source for a group, and there are no other memberships on the network, the router is free to choose (e.g. via locally configured policy) whether to send a (*,G) or (S,G) join. One of the purposes of IGMP is to seperate the knowledge of the routing protocol from the hosts. If hosts have to know about shared or source trees, that kind of blurs that seperation a little. Do you see a real gain by allowing the host to request vs. allowing the router to decide? Bill From owner-idmr@cs.ucl.ac.uk Thu Jul 13 17:11:47 2000 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 RAA02611 for ; Thu, 13 Jul 2000 17:11:46 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 20:09:59 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 20:09:54 +0100 Received: from pc39138.comtranet.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 20:09:56 +0100 Received: from pc39138.comtranet.com (127.0.0.1) by pc39138.comtranet.com with ESMTP (Eudora Internet Mail Server 2.2.2); Thu, 13 Jul 2000 12:09:49 -0700 Mime-Version: 1.0 X-Sender: maufer@mail.nova.org Message-Id: In-Reply-To: <20480.963512043@hazard.aciri.org> References: <20480.963512043@hazard.aciri.org> Date: Thu, 13 Jul 2000 12:08:18 -0700 To: Mark Handley From: Thomas Maufer Subject: Re: Standardisation of IGMPv3 Cc: Bill Fenner , Mani Manoharan Balaraman , Beau Williamson , idmr Content-Type: text/plain; charset="us-ascii" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Mark-- I'd tend to agree with you. Not only for the reasons that you mentioned, but I can't imagine that it would be very likely that there would be a set of servers offering related content (or temporally correlated abuse) such that grouping them together under a common prefix would be meaningful. So, unless someone can illustrate situations where this would actually be useful (and where *not* having the netmask information would be a real impediment), as well as mechanisms to enable the group-members to learn about the source's local prefix, I think this feature could be safely postponed until IGMPv4. :-) Cheers, Tom At 11:14 -0700 2000-07-13, Mark Handley wrote: > >This point has been made by several others and I think is quite >>valid. I'd personally prefer that we add the ability to specify a >>mask before going to Last Call. > >Bill, > >I'd like to voice a different viewpoint. > >I'm unconvinced that adding a mask is a good idea for a number of >reasons: > > - It would complicate the IGMPv3 machinery (which is already pretty > complex) because you'd have to resolve mismatched masks. Eg one > host specifies "Exclude (128.1.0.0/16, G)" another host specifies > "Exclude (128.1.2.0/24, G)". > > - You also have to cope with nested include and exclude masks. Eg > one host specifies "Exclude (128.1.0.0/16, G)" and another host > specifies "Include (128.1.2.0/24, G)". For IGMPv3, this is additional > complexity. If you want to map this into PIM this would want to map > into two Prune *ranges* - you can't implement this with a single > mask, so you'd actually need a large number Prune mask entries > (Prune(128.1.0.0/23,G) , Prune(128.1.3.0/24,G), Prune(128.1.4.0/22,G), > etc). > > Do (S-mask,G) prune entries actually work in PIM? The packet > format allows it.... > > If the router doesn't try and map (S-mask,G) IGMP exclude messages > into (S-mask,G) Prune messages, then the purpose of (S-mask,G) > IGMP exclude messages is kind of lost. Anyone spoofing from all > the addresses on a subnet will generate a small amount of > local-area IGMP exclude traffic which gets mapped into a large > amount of wide-area PIM prune traffic. Thus the optimization doesn't > seem worthwhile. > > - It requires the API be extended to allow apps to specify masks. > For exclude masks, there doesn't seem to be any practical way the > app can use the mask. It's never going to be told by a misbehaving > sender what the correct netmask is, and it's increasingly unlikely > to be able to guess correctly. > > - If the IGMPv3 host specifies an include netmask that is too large, > how do you implement this in PIM? Do you route an (S-mask,G) Join to > the place where the routes diverge, and then have to split the Join > to go multiple ways? I guess you'd have an issue if someone > specifies "Include 192.1.0.0/16" for example. > > If the router doesn't try and map (S-mask,G) IGMP include messages > into (S-mask,G) Join messages or a large number of (S,G) Join > messages, then I don't think (S-mask,G) IGMP include messages serve > any purpose whatsoever. The receiver simply won't get the traffic > they asked for. > > I guess you could do a (*,G) Join, and then have the router > generate the (S,G,rpt) Prunes for unwanted sources, but the host > can just as well do this with the current IGMPv3. > >In general, I think this raises too many complexities for what seems >to me to be too little gain, so that it just doesn't seem worthwhile. >It's likely to add significant delay to standardizing and deploying >SSM, and that seems to be a bad tradeoff to me. > >Cheers, > Mark From owner-idmr@cs.ucl.ac.uk Thu Jul 13 19:44:40 2000 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 TAA22297 for ; Thu, 13 Jul 2000 19:44:39 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 22:16:25 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 22:16:19 +0100 Received: from ertpg14e1.nortelnetworks.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 22:16:21 +0100 Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Thu, 13 Jul 2000 15:41:55 -0400 Received: from zcard00p.ca.nortel.com ([47.141.0.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3XXBJ65W; Thu, 13 Jul 2000 15:38:37 -0400 Received: from vaio (vaio.ca.nortel.com [47.23.83.92]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N2LHJQ0B; Thu, 13 Jul 2000 15:38:27 -0400 Message-ID: <00d701bfed02$ae0f0280$5c53172f@ca.nortel.com> X-Sybari-Space: 00000000 00000000 00000000 From: Manuel Oliveira To: Mark Handley Cc: idmr , Jon Crowcroft , Christophe Diot Subject: Fw: Standardisation of IGMPv3 Date: Thu, 13 Jul 2000 20:43:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Hi Mark, I could not resist providing a different view on the issues you raised. > - It would complicate the IGMPv3 machinery (which is already pretty > complex) because you'd have to resolve mismatched masks. Eg one > host specifies "Exclude (128.1.0.0/16, G)" another host specifies > "Exclude (128.1.2.0/24, G)". Depends what you consider a mask to be. Currently we have host filtering and address filtering. It has been mentioned time and time again that network filtering would be useful. So we propose that instead of a mask, consider a filter that is used for subcasting purposes. This filter represents the aggregated interest of receivers along a particular route. So in the case above what would happen is the following: i) both hosts would join (128.1.2.0/G) - obs: this also works for shared based groups. ii) host A subscribes to flow 16 iii) host B subscribes to flow 24 The outcome would be: i) if both hosts are on the same subnet then both get flows 16 and 24. So filtering would be done at the host, however this would take place within the IP stack. ii) hosts are on different subnets then each only receives the packets they are interested in. The necessary mechanisms are simple boolean operations and additional state required is negligible. These mechanisms are ortogonal to how the routing structure is constructed and only affect the forwarding process. > - You also have to cope with nested include and exclude masks. Eg > one host specifies "Exclude (128.1.0.0/16, G)" and another host > specifies "Include (128.1.2.0/24, G)". For IGMPv3, this is additional > complexity. If you want to map this into PIM this would want to map > into two Prune *ranges* - you can't implement this with a single > mask, so you'd actually need a large number Prune mask entries > (Prune(128.1.0.0/23,G) , Prune(128.1.3.0/24,G), Prune(128.1.4.0/22,G), > etc). If the filter is aggregated interest then this situation does not occur. > - It requires the API be extended to allow apps to specify masks. > For exclude masks, there doesn't seem to be any practical way the > app can use the mask. It's never going to be told by a misbehaving > sender what the correct netmask is, and it's increasingly unlikely > to be able to guess correctly. Is extending the API so bad? The socket API could be extended to include the two operations, by having two new socket options. This would not break existing applications and would benefit applications such as online games and distributed VR. The overhead for other application types is zero since the filter would be non active, and all packets were forwarded. With regards to exclude, it is all a matter of semantics. You just indicate that you do not want any more traffic from a particular flow. > - If the IGMPv3 host specifies an include netmask that is too large, > how do you implement this in PIM? Do you route an (S-mask,G) Join to > the place where the routes diverge, and then have to split the Join > to go multiple ways? I guess you'd have an issue if someone > specifies "Include 192.1.0.0/16" for example. As mentioned before join/leave is done in the normal fashion. The host then indicates their interest in flows by subscribing to them, thus updating the filter associated to their route. If there is a change to the filter then the router is required to do an update by dissiminating the new filter along the remainder routes. Although minor, existing routing protocols would have to be exteneded to support this. > In general, I think this raises too many complexities for what seems > to me to be too little gain, so that it just doesn't seem worthwhile. > It's likely to add significant delay to standardizing and deploying > SSM, and that seems to be a bad tradeoff to me. Well, we think it is simple and efficient providing a lot of benefit for large scale applications. And it does not negatively impact other application genres. Application that would benefit from this filtering mechanism (top of my head): - layered multicast apps - online games + distributed VR There is a paper (unpublished) describing the idea in more detail. Myself , Jon or Christophe would be happy to provide it to anyone who is interested. Cheers Manuel From owner-idmr@cs.ucl.ac.uk Thu Jul 13 19:44:45 2000 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 TAA22322 for ; Thu, 13 Jul 2000 19:44:44 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 22:23:27 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 22:23:21 +0100 Received: from usc.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 22:23:24 +0100 Received: from ceng.usc.edu (helmy@ceng.usc.edu [128.125.72.78]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA13964; Thu, 13 Jul 2000 14:23:23 -0700 (PDT) Received: from localhost (helmy@localhost) by ceng.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA02089; Thu, 13 Jul 2000 14:23:22 -0700 (PDT) Date: Thu, 13 Jul 2000 14:23:22 -0700 (PDT) From: helmy To: Bill Fenner cc: idmr@cs.ucl.ac.uk Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard In-Reply-To: <200007131957.MAA29949@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 > > Does IGMPv3 currently support any interface (perhaps 1 bit, > >or..) such that a receiver can say 'join to the SPT directly' even if the > >underlying protocol supports a center (i.e., RP for PIM-SM) ? > >or anything to that effect? > > This is supported only implicitly. Consider a stub network, for > simplicity. If a host sends an inclusion report for a single source > for a group, and there are no other memberships on the network, the > router is free to choose (e.g. via locally configured policy) whether > to send a (*,G) or (S,G) join. > > One of the purposes of IGMP is to seperate the knowledge of the routing > protocol from the hosts. If hosts have to know about shared or source > trees, that kind of blurs that seperation a little. Do you see a real > gain by allowing the host to request vs. allowing the router to decide? Bill, I agree with the separation and that the host need not know about mechanistic details of the underlying multicast. But still, leaving the policy up to the router may lead to degradation of performance if the policy does not conform to the requirements of the application joining the group... so, instead of having this 'bit' or field indicate 'SPT' or shared tree [which is multicast routing knowledge], we can have it specify some kind of quality indicator [like low delay, or low overhead, for example]. This would then be translated by the router according to the multicast routing and the quality that can be provided. Currently, applications (or end point protocols) that use multicast, have no control over the quality presented by the underlying multicast (even if the service already exists, such as low delays thru SPT, for example). hope that makes my point clearer, Regards, -Ahmed > > Bill > From owner-idmr@cs.ucl.ac.uk Thu Jul 13 19:48:35 2000 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 TAA23176 for ; Thu, 13 Jul 2000 19:48:34 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 00:12:20 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 00:12:15 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 00:12:17 +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 DF9244CE08; Thu, 13 Jul 2000 19:12:07 -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 TAA07998; Thu, 13 Jul 2000 19:12:07 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA01257; Thu, 13 Jul 2000 16:12:03 -0700 (PDT) Message-Id: <200007132312.QAA01257@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rcoltun@redback.com, oran@cisco.com Subject: Advancement of IGMP Proxying spec Cc: idmr@cs.ucl.ac.uk, ietf-secretariat@ietf.org Date: Thu, 13 Jul 2000 16:12:02 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Dear Rob and Dave, The IDMR Working Group would like to advance the IGMP-based Multicast Forwarding (``IGMP Proxying'') spec, draft-fenner-igmp-proxy-03.{txt,ps} to Proposed Standard. This document was discussed at the Oslo IETF and was accepted as an IDMR WG work item when the charter was updated; the draft was never renamed to reflect its new status. It passed an IDMR Working Group Last Call on November 5, 1999 with no comments from the WG. Thanks, Bill From owner-idmr@cs.ucl.ac.uk Thu Jul 13 19:48:42 2000 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 TAA23207 for ; Thu, 13 Jul 2000 19:48:41 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 22:50:15 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 22:50:09 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 22:50:12 +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 1B2A11E037; Thu, 13 Jul 2000 17:50:10 -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 RAA04221; Thu, 13 Jul 2000 17:50:09 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA00927; Thu, 13 Jul 2000 14:50:05 -0700 (PDT) Message-Id: <200007132150.OAA00927@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rcoltun@redback.com, oran@cisco.com Subject: Advancement of Domain Wide Reports spec Cc: idmr@cs.ucl.ac.uk, ietf-secretariat@ietf.org Date: Thu, 13 Jul 2000 14:50:04 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Dear Rob and Dave, The IDMR Working Group would like to advnace the Domain Wide Reports spec, draft-ietf-idmr-membership-reports-05.{txt,ps} to Proposed Standard. This document passed an IDMR Working Group Last Call on November 5, 1999 with no comments from the WG. Thanks, Bill From owner-idmr@cs.ucl.ac.uk Thu Jul 13 19:48:47 2000 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 TAA23244 for ; Thu, 13 Jul 2000 19:48:46 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 13 Jul 2000 23:12:10 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 2000 23:12:01 +0100 Received: from mzstore02.allegro.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 13 Jul 2000 23:12:02 +0100 Received: from eccmfw6.ford.com (unverified) by mzdy17.allegro.net (Content Technologies SMTPRS 2.0.15) with SMTP id for ; Thu, 13 Jul 2000 18:09:06 -0400 Message-Id: Received: by mailfw6.ford.com id SAA07303 (InterLock SMTP Gateway 4.2 for idmr@cs.ucl.ac.uk); Thu, 13 Jul 2000 18:11:59 -0400 (EDT) Received: by mailfw6.ford.com (Internal Mail Agent-1); Thu, 13 Jul 2000 18:11:59 -0400 (EDT) Received: by mailfw6.ford.com (Internal Mail Agent-0); Thu, 13 Jul 2000 18:11:59 -0400 (EDT) From: "Houdek, Stephen (S.W.)" To: "'Mark Handley'" , Bill Fenner Cc: Mani Manoharan Balaraman , idmr , Beau Williamson Subject: RE: Standardization of IGMPv3 Date: Thu, 13 Jul 2000 18:11:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk A corporate perspective...... Don't wait to perfect it. If it is close and this would cause unnecessary delay, debate and incorporate this functionality via V4. It appears this is "somewhat" controversial and would be subject to a requisite amount of debate. Think Speed........ Stephen W. Houdek shoudek@ford.com (313) 845-4128 (313) 845-2491 -----Original Message----- From: Mark Handley [mailto:mjh@aciri.org] Sent: Thursday, July 13, 2000 2:14 PM To: Bill Fenner Cc: Mani Manoharan Balaraman; idmr; Beau Williamson Subject: Re: Standardisation of IGMPv3 >This point has been made by several others and I think is quite >valid. I'd personally prefer that we add the ability to specify a >mask before going to Last Call. Bill, I'd like to voice a different viewpoint. I'm unconvinced that adding a mask is a good idea for a number of reasons: - It would complicate the IGMPv3 machinery (which is already pretty complex) because you'd have to resolve mismatched masks. Eg one host specifies "Exclude (128.1.0.0/16, G)" another host specifies "Exclude (128.1.2.0/24, G)". - You also have to cope with nested include and exclude masks. Eg one host specifies "Exclude (128.1.0.0/16, G)" and another host specifies "Include (128.1.2.0/24, G)". For IGMPv3, this is additional complexity. If you want to map this into PIM this would want to map into two Prune *ranges* - you can't implement this with a single mask, so you'd actually need a large number Prune mask entries (Prune(128.1.0.0/23,G) , Prune(128.1.3.0/24,G), Prune(128.1.4.0/22,G), etc). Do (S-mask,G) prune entries actually work in PIM? The packet format allows it.... If the router doesn't try and map (S-mask,G) IGMP exclude messages into (S-mask,G) Prune messages, then the purpose of (S-mask,G) IGMP exclude messages is kind of lost. Anyone spoofing from all the addresses on a subnet will generate a small amount of local-area IGMP exclude traffic which gets mapped into a large amount of wide-area PIM prune traffic. Thus the optimization doesn't seem worthwhile. - It requires the API be extended to allow apps to specify masks. For exclude masks, there doesn't seem to be any practical way the app can use the mask. It's never going to be told by a misbehaving sender what the correct netmask is, and it's increasingly unlikely to be able to guess correctly. - If the IGMPv3 host specifies an include netmask that is too large, how do you implement this in PIM? Do you route an (S-mask,G) Join to the place where the routes diverge, and then have to split the Join to go multiple ways? I guess you'd have an issue if someone specifies "Include 192.1.0.0/16" for example. If the router doesn't try and map (S-mask,G) IGMP include messages into (S-mask,G) Join messages or a large number of (S,G) Join messages, then I don't think (S-mask,G) IGMP include messages serve any purpose whatsoever. The receiver simply won't get the traffic they asked for. I guess you could do a (*,G) Join, and then have the router generate the (S,G,rpt) Prunes for unwanted sources, but the host can just as well do this with the current IGMPv3. In general, I think this raises too many complexities for what seems to me to be too little gain, so that it just doesn't seem worthwhile. It's likely to add significant delay to standardizing and deploying SSM, and that seems to be a bad tradeoff to me. Cheers, Mark From owner-idmr@cs.ucl.ac.uk Fri Jul 14 03:39:53 2000 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 DAA23216 for ; Fri, 14 Jul 2000 03:39:52 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 06:58:39 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 06:58:34 +0100 Received: from 208.178.29.198 by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 06:58:36 +0100 Received: from c1web02 (208.178.29.202) by c1mailgw2.prontomail.com (NPlex 4.5.049) id 396E7EC000002E76; Thu, 13 Jul 2000 22:59:08 -0700 X-Version: indya 6.2.3 .2329.0 From: vijayc@indya.com Message-Id: <6558A6CD93954D1178150005B8E28024@vijayc.indya.com> Date: Fri, 14 Jul 2000 11:32:57 +0530 X-Priority: Normal Content-Type: text/plain; charset=iso-8859-1 To: m.oliveira@cs.ucl.ac.uk Subject: Re: Fw: Standardisation of IGMPv3 CC: idmr@cs.ucl.ac.uk X-Mailer: Web Based Pronto Mime-Version: 1.0 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA23216 Hi , I agree with what you say. Also, I think postponing the network level filtering to v4 would introduce more interoparability issues and interoparability would dominate the development effort of IGMPv4. Also, the routing protocols(DVMRP/PIM) have to be tailored to interoperate with v3 and v4 separately. Already they have to different strategies while operating with v1 and v2. Hence, it would be better to incorporate net. filtering in v4 before standardising it. Hi Mark, I could not resist providing a different view on the issues you raised. >  - You also have to cope with nested include and exclude masks.  Eg >    one host specifies "Exclude (128.1.0.0/16, G)" and another host >    specifies "Include (128.1.2.0/24, G)".  For IGMPv3, this is additional >    complexity.  If you want to map this into PIM this would want to map >    into two Prune *ranges* - you can't implement this with a single >    mask, so you'd actually need a large number Prune mask entries >    (Prune(128.1.0.0/23,G) , Prune(128.1.3.0/24,G), Prune(128.1.4.0/22,G), >    etc). If the filter is aggregated interest then this situation does not occur. In the above situation, a simple strategy would be to the exclude for 128.1 could be cancelled in favor of the include because atleast one host is intersted in 128.1.2. Although this is not perfect this situation occurs because of lack of aggregated interest within hosts in a subnet which should be avoided. Regards, Vijay Enter your default signature here Sent by Indya Messaging Service From owner-idmr@cs.ucl.ac.uk Fri Jul 14 03:40:00 2000 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 DAA23251 for ; Fri, 14 Jul 2000 03:40:00 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 06:30:52 +0100 Received: from haig.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 06:30:48 +0100 Received: from c1mailgw1.prontomail.com by haig.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 06:30:51 +0100 Received: from c1web02 (208.178.29.202) by c1mailgw1.prontomail.com (NPlex 4.5.049) id 3969EE5E00072EAA; Thu, 13 Jul 2000 22:29:27 -0700 X-Version: indya 6.2.3 .2329.0 From: vijayc@indya.com Message-Id: <6458A6CD93954D1178150005B8E28024@vijayc.indya.com> Date: Fri, 14 Jul 2000 11:05:02 +0530 X-Priority: Normal Content-Type: text/plain; charset=iso-8859-1 To: tmaufer@acm.org Subject: Re: Re: Standardisation of IGMPv3 CC: idmr@cs.ucl.ac.uk X-Mailer: Web Based Pronto Mime-Version: 1.0 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA23251 So, unless someone can illustrate situations where this would actually be useful (and where *not* having the netmask information would be a real impediment), as well as mechanisms to enable the group-members to learn about the source's local prefix,  I think this feature could be safely postponed until IGMPv4.  :-) The idea of postponing this network filtering to v4 would introduce more interoperability issues. Already we have 3 versions of IGMP. If a fourth version is made just for the sake of network level filtering the iinteroperability issues are likely to dominate the development effort. I think the issue must be resolved once and for all instead of postponing it. > - It would complicate the IGMPv3 machinery (which is already pretty >   complex) because you'd have to resolve mismatched masks.  Eg one >   host specifies "Exclude (128.1.0.0/16, G)" another host specifies >   "Exclude (128.1.2.0/24, G)". >   > - You also have to cope with nested include and exclude masks.  Eg >   one host specifies "Exclude (128.1.0.0/16, G)" and another host >   specifies "Include (128.1.2.0/24, G)".  For IGMPv3, this is additional >   complexity.  If you want to map this into PIM this would want to map >   into two Prune *ranges* - you can't implement this with a single >   mask, so you'd actually need a large number Prune mask entries >   (Prune(128.1.0.0/23,G) , Prune(128.1.3.0/24,G), Prune(128.1.4.0/22,G), >   etc). > Can't such contradicting nested mask be resolved in favor of the 'INCLUDE' mask, ie, since atleast one host is interested in traffic from 128.1 network the exclude for that network can be cancelled in favor of the include. Regards, Vijay Sent by Indya Messaging Service From owner-idmr@cs.ucl.ac.uk Fri Jul 14 07:09:31 2000 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 HAA15548 for ; Fri, 14 Jul 2000 07:09:30 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 11:56:32 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 11:56:26 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 11:56:17 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10608; Fri, 14 Jul 2000 06:56:16 -0400 (EDT) Message-Id: <200007141056.GAA10608@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-mrdisc-04.txt Date: Fri, 14 Jul 2000 06:56:16 -0400 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 : IGMP Multicast Router Discovery Author(s) : S. Biswas, B. Cain, B. Haberman Filename : draft-ietf-idmr-igmp-mrdisc-04.txt Pages : 14 Date : 13-Jul-00 Companies have been proposing IGMP snooping schemes for layer-2 bridging devices. A method for discovering multicast capable routers is necessary for these schemes. An IGMP query message is inadequate for discovering multicast routers as one querier is elected. In order to 'discover' multicast routers, we introduce two new types of IGMP messages: Multicast Router Advertisement and Multicast Router Solicitation. These two messages can be used by any device which listens to IGMP to discovery multicast routers. Multicast Router Solicitation messages may be used by any network device (e.g. layer-2 switch) to solicit discovery messages from multicast routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-mrdisc-04.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-mrdisc-04.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-mrdisc-04.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: <20000713145740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-igmp-mrdisc-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-igmp-mrdisc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145740.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Fri Jul 14 07:09:48 2000 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 HAA15650 for ; Fri, 14 Jul 2000 07:09:46 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 11:56:40 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 11:56:27 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 11:56:22 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10640; Fri, 14 Jul 2000 06:56:21 -0400 (EDT) Message-Id: <200007141056.GAA10640@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-msf-api-01.txt Date: Fri, 14 Jul 2000 06:56:20 -0400 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 : Socket Interface Extensions for Multicast Source Filters Author(s) : D. Thaler, B. Fenner, B. Quinn Filename : draft-ietf-idmr-msf-api-01.txt Pages : 14 Date : 13-Jul-00 IGMPv3 for IPv4 adds the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. It is expected that in the future, the same capability will be available in IPv6 as well. This document specifies new socket options and ioctl commands to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new APIs. These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-msf-api-01.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-msf-api-01.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-msf-api-01.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: <20000713145752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-msf-api-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-msf-api-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145752.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Fri Jul 14 07:10:29 2000 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 HAA15958 for ; Fri, 14 Jul 2000 07:10:28 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 09:56:52 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 09:56:48 +0100 Received: from alexandria.hpo.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 09:56:49 +0100 Received: from jet.es [210.154.109.83] by alexandria.hpo.net with ESMTP (SMTPD32-5.08 EVAL) id A6EC14C0284; Fri, 14 Jul 2000 17:57:16 +0900 Message-ID: <396ED384.198EEB15@jet.es> Date: Fri, 14 Jul 2000 17:47:00 +0900 From: Manolo Sola X-Mailer: Mozilla 4.5 [ja] (Win98; I) X-Accept-Language: ja MIME-Version: 1.0 To: idmr Subject: RE: Standardization of IGMPv3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Some comments not aimed to interfere with the IGMPv3 last call but just to continue with the debate regarding future IGMP versions: what about having 2 more filter-modes, lets say, INCLUDE-PREFIX and EXCLUDE-PREFIX ? For this two filter modes what would appear in source-list[2n] and source-list[2n+1] would be an address/prefix pair. In what respect to the IGMPv3 message format, it would be enough to take a single bit from the reserve field to indicate whether the message contains a list of single sources or a list of address/prefix pairs. Considering that IGMP must be independent of the multicast protocols used to forward multicast traffic from sources to leaf routers, the way PIM, CBT or other multicast protocols at routers use the list of sources or the list of address/prefix pairs provided by IGMP becomes a multicast protocol dependent issue and should not constrain IGMP specification. The simplest IGMP implementation allowing address/prefix pairs can just expand each prefix pair into single 32 bit address lists before doing any further processing. More elaborated implementations can go further. In any case it can make things simpler for those applications that need to include or exclude ranges of source addresses. -- Manolo Sola sola@jet.es From owner-idmr@cs.ucl.ac.uk Fri Jul 14 12:38:46 2000 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 MAA25597 for ; Fri, 14 Jul 2000 12:38:45 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 15:28:38 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 15:28:34 +0100 Received: from mail1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 15:28:36 +0100 Received: from bwilliam-8000.cisco.com (rtp-dial-1-221.cisco.com [10.83.97.221]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA21326; Fri, 14 Jul 2000 07:28:31 -0700 (PDT) Message-Id: <4.3.2.7.2.20000714092124.02ab0630@sj-email.cisco.com> X-Sender: bwilliam@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 09:27:20 -0700 To: Bill Fenner , idmr@cs.ucl.ac.uk From: Beau Williamson Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard In-Reply-To: <200007122244.PAA20540@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Bill, et al, I've seen a great deal of discussion about how the host and the router will make use of IGMPv3 and the impacts on their operation. However, has anyone done much work as to what impact these new mechanisms will have on switches that perform IGMP Snooping in order to constrain multicast flows at Layer 2? I personally have not had the time to give this much thought although it does appear on the surface (at least it does to me) that IGMPv3 will have a *significant* impact on switches that are doing IGMP Snooping. Maybe there are others in the WG that have given thought to this and can comment as to the foreseen impact. Beau From owner-idmr@cs.ucl.ac.uk Fri Jul 14 15:13:03 2000 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 PAA16313 for ; Fri, 14 Jul 2000 15:13:02 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 17:51:36 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 17:51:31 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 17:51:33 +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 BE5B84CE39; Fri, 14 Jul 2000 12:51:30 -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 MAA22052; Fri, 14 Jul 2000 12:51:29 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA17521; Fri, 14 Jul 2000 09:51:25 -0700 (PDT) Message-Id: <200007141651.JAA17521@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bwilliam@cisco.com Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard Cc: idmr@cs.ucl.ac.uk Date: Fri, 14 Jul 2000 09:51:25 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >I personally have not had the time to give this much thought although it >does appear on the surface (at least it does to me) that IGMPv3 will have a >*significant* impact on switches that are doing IGMP Snooping. At a minimum, switches will need to be modified to recognize IGMPv3 reports. This may actually be easier in IGMPv3 since the reports are all sent to the same group address. You can't do IP source filtering at the ethernet layer, so switches can treat both source inclusion and exclusion reports as group joins, and the "include none" as leaves. (Does current IGMP snooping technology do fast leave?) Bill From owner-idmr@cs.ucl.ac.uk Fri Jul 14 15:13:17 2000 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 PAA16408 for ; Fri, 14 Jul 2000 15:13:16 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 19:06:35 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 19:06:30 +0100 Received: from sj-msg-core-1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 19:06:32 +0100 Received: from michaelv-u10.cisco.com (michaelv-u10.cisco.com [10.34.12.132]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA23252; Fri, 14 Jul 2000 11:06:45 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by michaelv-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA03427; Fri, 14 Jul 2000 11:06:32 -0700 (PDT) Message-ID: <396F56A8.7D4C029B@cisco.com> Date: Fri, 14 Jul 2000 11:06:32 -0700 From: Michael Vorburger Organization: CISCO Systems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Beau Williamson CC: Bill Fenner , idmr@cs.ucl.ac.uk, "c6k-mcast-coders@cisco.com" Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard References: <4.3.2.7.2.20000714092124.02ab0630@sj-email.cisco.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 Beau, I am a DE working on CatOS for MMLS and IGMP Snooping under Ramana. We have implemented a sort of "IGMPv3 minimal-support" for IGMP Snooping on Cat5k/6k that will be part of the upcoming CatOS 6.1 ORL sw release. Our approach is documented in http://wwwin-people.cisco.com/rmellach-group/mcast/igmpv3.html This is a very simplistic first approach, later optimisations are to be seen and are proposed in the above document. We are ignoring the source specific portion of v3 reports at this first phase, and able to process joins essentially as if they were v2 joins. The main issue we faced while thinking about this issue are the LEAVES; in order to remove ports for constraining multicast flows at Layer 2 when a host signals disinterest IGMP snooping would have to either keep a complete source list per host/per port/per group, or play more extensive IGMP Querier functionality. It would have been a lot easier for us if the IGMPv3 reports always contained a FULL include or exclude source list, not just partial diffs, but I am assuming it is ways to late to change anything in that respect. I am assuming we will eventually refine this first simplistic IGMPv3 Support in IGMP Snooping for full-fledged support. This first approach is simply to ensure we don't completely break multicast; we understand people were disabling IGMP Snooping (and thus MMLS) to test IGMPv3... ;) Thanks, Michael Beau Williamson wrote: > > Bill, et al, > > I've seen a great deal of discussion about how the host and the router will make use of IGMPv3 and the impacts on their operation. However, has anyone done much work as to what impact these new mechanisms will have on switches that perform IGMP Snooping in order to constrain multicast flows at Layer 2? > > I personally have not had the time to give this much thought although it does appear on the surface (at least it does to me) that IGMPv3 will have a *significant* impact on switches that are doing IGMP Snooping. Maybe there are others in the WG that have given thought to this and can comment as to the foreseen impact. > > Beau -- Thank you, Michael ______________________________________________________________ Michael Vorburger, michaelv@cisco.com | | PERSONAL: http://www.vorburger.ch ||| ||| .|||||. .|||||. 170 West Tasman Dr (Bldg-F2) .:|||||||||:.:|||||||||:. San Jose, CA 95134, USA c i s c o S y s t e m s Tel: (408) 525 3097 Pager: (408) 308 4942 "Empowering the Internet Generation -- Are you ready?" ______________________________________________________________ From owner-idmr@cs.ucl.ac.uk Fri Jul 14 15:13:23 2000 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 PAA16472 for ; Fri, 14 Jul 2000 15:13:22 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 17:38:16 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 17:38:11 +0100 Received: from sj-msg-core-crit.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 17:38:13 +0100 Received: from cisco.com (nchandik-ultra.cisco.com [10.34.12.138]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with ESMTP id JAA00807; Fri, 14 Jul 2000 09:38:09 -0700 (PDT) Message-ID: <396F41F3.6AE54129@cisco.com> Date: Fri, 14 Jul 2000 09:38:11 -0700 From: Naga Chandika Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Beau Williamson CC: Bill Fenner , idmr@cs.ucl.ac.uk Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard References: <4.3.2.7.2.20000714092124.02ab0630@sj-email.cisco.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 Beau, We are already implementing minimal support for IGMPV3 snooping in catalyst switches (hybrid versions) so that IGMP snooping does not break IGMPV3. We will also have full support for IGMPV3 Snooping in the near future. Thanks Naga -- Naga Chandika Cisco Systems, Inc. Ph:(408)527-9579 (w) Beau Williamson wrote: > > Bill, et al, > > I've seen a great deal of discussion about how the host and the router will make use of IGMPv3 and the impacts on their operation. However, has anyone done much work as to what impact these new mechanisms will have on switches that perform IGMP Snooping in order to constrain multicast flows at Layer 2? > > I personally have not had the time to give this much thought although it does appear on the surface (at least it does to me) that IGMPv3 will have a *significant* impact on switches that are doing IGMP Snooping. Maybe there are others in the WG that have given thought to this and can comment as to the foreseen impact. > > Beau From owner-idmr@cs.ucl.ac.uk Fri Jul 14 15:23:38 2000 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 PAA20190 for ; Fri, 14 Jul 2000 15:23:37 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 19:35:22 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 19:35:14 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 19:35:16 +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 0E9281E029 for ; Fri, 14 Jul 2000 14:35:16 -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 OAA27609 for ; Fri, 14 Jul 2000 14:35:11 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA18084; Fri, 14 Jul 2000 11:35:11 -0700 (PDT) Message-Id: <200007141835.LAA18084@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idmr@cs.ucl.ac.uk Subject: WG Last Call: Multicast Router Discovery to Proposed Standard Date: Fri, 14 Jul 2000 11:35:11 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Dear IDMR WG, This is a 2 week Working Group Last Call for IGMP Multicast Router Discovery, draft-ietf-idmr-igmp-mrdisc-04.txt, to Proposed Standard. Title : IGMP Multicast Router Discovery Author(s) : S. Biswas, B. Cain, B. Haberman Filename : draft-ietf-idmr-igmp-mrdisc-04.txt Pages : 14 Date : 13-Jul-00 Companies have been proposing IGMP snooping schemes for layer-2 bridging devices. A method for discovering multicast capable routers is necessary for these schemes. An IGMP query message is inadequate for discovering multicast routers as one querier is elected. In order to 'discover' multicast routers, we introduce two new types of IGMP messages: Multicast Router Advertisement and Multicast Router Solicitation. These two messages can be used by any device which listens to IGMP to discovery multicast routers. Multicast Router Solicitation messages may be used by any network device (e.g. layer-2 switch) to solicit discovery messages from multicast routers. Please comment by Friday, July 28, 2000, on the IDMR mailing list or directly to working group chair, . Thanks, Bill From owner-idmr@cs.ucl.ac.uk Fri Jul 14 18:27:36 2000 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 SAA07146 for ; Fri, 14 Jul 2000 18:27:36 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 21:14:10 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 21:14:05 +0100 Received: from 131.107.152.20 by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 21:14:06 +0100 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id OAA25961; Fri, 14 Jul 2000 14:42:32 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <200007142142.OAA25961@dthaler.microsoft.com> Subject: Re: Standardisation of IGMPv3 In-Reply-To: <20480.963512043@hazard.aciri.org> from Mark Handley at "Jul 13, 2000 11:14: 3 am" To: mjh@aciri.org (Mark Handley) Date: Fri, 14 Jul 2000 14:42:32 -0700 (PDT) Cc: fenner@research.att.com, mani.balaram@wipro.com, idmr@cs.ucl.ac.uk, bwilliam@cisco.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] 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 Mark Handley writes: > >This point has been made by several others and I think is quite > >valid. I'd personally prefer that we add the ability to specify a > >mask before going to Last Call. > > Bill, > > I'd like to voice a different viewpoint. > > I'm unconvinced that adding a mask is a good idea for a number of > reasons: [...] > In general, I think this raises too many complexities for what seems > to me to be too little gain, so that it just doesn't seem worthwhile. > It's likely to add significant delay to standardizing and deploying > SSM, and that seems to be a bad tradeoff to me. I strongly agree with Mark. Adding rules to deal with a mask would severly delay (if not halt all together) both standardization and deployment of IGMPv3, at a time where it's already overdue, and for little (no?) benefit. -Dave From owner-idmr@cs.ucl.ac.uk Fri Jul 14 18:27:45 2000 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 SAA07173 for ; Fri, 14 Jul 2000 18:27:44 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 14 Jul 2000 21:53:50 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 21:53:41 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 14 Jul 2000 21:53:41 +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 57D4B4CE4F for ; Fri, 14 Jul 2000 16:53:41 -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 QAA05608 for ; Fri, 14 Jul 2000 16:53:40 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA19289; Fri, 14 Jul 2000 13:53:36 -0700 (PDT) Message-Id: <200007142053.NAA19289@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idmr@cs.ucl.ac.uk Subject: IDMR web pages updated Date: Fri, 14 Jul 2000 13:53:35 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk I've updated the IDMR document status page, and added a mailing list archive. See http://www.aciri.org/fenner/idmr/ . Bill From owner-idmr@cs.ucl.ac.uk Sun Jul 16 11:24:15 2000 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 LAA04527 for ; Sun, 16 Jul 2000 11:24:14 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sun, 16 Jul 2000 14:09:16 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sun, 16 Jul 2000 14:09:11 +0100 Received: from www22.gmx.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Sun, 16 Jul 2000 14:09:14 +0100 Received: (qmail 23787 invoked by uid 0); 16 Jul 2000 13:09:14 -0000 Date: Sun, 16 Jul 2000 15:09:14 +0200 (MEST) From: Tobias.Busch@gmx.net To: idmr@cs.ucl.ac.uk MIME-Version: 1.0 References: <4.3.2.7.2.20000713103256.02a7fbf0@sj-email.cisco.com> Subject: how do I unsubscribe? X-Priority: 3 (Normal) X-Authenticated-Sender: #0002402602@gmx.net X-Authenticated-IP: [141.28.224.2] Message-ID: <23779.963752954@www22.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit could you please tell me? thx. tobias. -- Sent through GMX FreeMail - http://www.gmx.net From owner-idmr@cs.ucl.ac.uk Sun Jul 16 23:06:03 2000 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 XAA18036 for ; Sun, 16 Jul 2000 23:06:02 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 17 Jul 2000 01:33:15 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Jul 2000 01:33:11 +0100 Received: from net090s.hetnet.nl by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 17 Jul 2000 01:33:15 +0100 Received: from alias ([38.28.75.143]) by hetnet.nl with Microsoft SMTPSVC(5.5.1877.387.38); Mon, 17 Jul 2000 02:33:12 +0200 Message-ID: <001001bfef86$646b1a20$0a00a8c0@alias> From: Wilbert de Graaf To: idmr References: <200007142053.NAA19289@windsor.research.att.com> Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard Date: Sun, 16 Jul 2000 17:31:44 -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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit IDMR, I have two small requests for the IGMPv3 spec: 1) For now I've heard 3 different interpretations about how to report the equivalent of the IGMPv2 leave message in IGMPv3 mode. - act like there was a sollicitation for that group, and send IS_IN {} - send a TO_IN {} or, as is implied by the draft, - send a normal state-change report: if current mode is include a source list change with BLOCK_OLD_SOURCES with the current sourcelist if current mode is exclude, a TO_IN {} 2) I'm not sure anymore if a host has to report groups in the reserved range 224.0.0.x, other than 224.0.0.1 (as specified in rfc1112). If not, could you specify not to report these other groups in the reserved range ? - Wilbert From owner-idmr@cs.ucl.ac.uk Mon Jul 17 02:31:46 2000 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 CAA27317 for ; Mon, 17 Jul 2000 02:31:46 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 17 Jul 2000 05:40:28 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Jul 2000 05:40:24 +0100 Received: from adsl-63-196-11-252.dsl.snfc21.pacbell.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 17 Jul 2000 05:40:28 +0100 Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1]) by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id VAA46184; Sun, 16 Jul 2000 21:40:17 -0700 (PDT) (envelope-from mjh@hazard.aciri.org) From: Mark Handley X-Organisation: ACIRI To: Wilbert de Graaf cc: idmr Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard In-reply-to: Your message of "Sun, 16 Jul 2000 17:31:44 PDT." <001001bfef86$646b1a20$0a00a8c0@alias> Date: Sun, 16 Jul 2000 21:40:17 -0700 Message-ID: <46182.963808817@hazard.aciri.org> Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >2) I'm not sure anymore if a host has to report groups in the reserved range >224.0.0.x, other than 224.0.0.1 (as specified in rfc1112). If not, could you >specify not to report these other groups in the reserved range ? I think the issue here is with IGMP-snooping ethernet switches. Not reporting these groups would require that the host has some other way to signal its membership to the switch. Cheers, Mark From owner-idmr@cs.ucl.ac.uk Mon Jul 17 06:26:53 2000 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 GAA21849 for ; Mon, 17 Jul 2000 06:26:52 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 17 Jul 2000 08:35:15 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Jul 2000 08:35:11 +0100 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Jul 2000 08:35:15 +0100 To: Dave Thaler cc: mjh@aciri.org (Mark Handley), fenner@research.att.com, mani.balaram@wipro.com, idmr@cs.ucl.ac.uk, bwilliam@cisco.com Subject: Re: Standardisation of IGMPv3 In-reply-to: Your message of "Fri, 14 Jul 2000 14:42:32 PDT." <200007142142.OAA25961@dthaler.microsoft.com> Date: Mon, 17 Jul 2000 08:35:14 +0100 Message-ID: <3159.963819314@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk In message <200007142142.OAA25961@dthaler.microsoft.com>, Dave Thaler typed: well the jury appears to be out on what to DO with the masks, but why not leave something there for future experimentation? whatever happend to the old IETF tradition of forwards compatability?:-) so we put in the firleds but leave their USE undefined (actually, sorry, explictily mark them as experimental) that would seem to address all the complaitns about them and all the requests for them. >>Mark Handley writes: >>> >This point has been made by several others and I think is quite >>> >valid. I'd personally prefer that we add the ability to specify a >>> >mask before going to Last Call. >>> >>> Bill, >>> >>> I'd like to voice a different viewpoint. >>> >>> I'm unconvinced that adding a mask is a good idea for a number of >>> reasons: >>[...] >>> In general, I think this raises too many complexities for what seems >>> to me to be too little gain, so that it just doesn't seem worthwhile. >>> It's likely to add significant delay to standardizing and deploying >>> SSM, and that seems to be a bad tradeoff to me. >> >>I strongly agree with Mark. Adding rules to deal with a mask would >>severly delay (if not halt all together) both standardization and >>deployment of IGMPv3, at a time where it's already overdue, >>and for little (no?) benefit. >> >>-Dave cheers jon From owner-idmr@cs.ucl.ac.uk Mon Jul 17 13:51:51 2000 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 NAA23090 for ; Mon, 17 Jul 2000 13:51:51 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 17 Jul 2000 17:05:01 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Jul 2000 17:04:57 +0100 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Jul 2000 17:05:00 +0100 To: Bill Fenner cc: j.crowcroft@cs.ucl.ac.uk, idmr@cs.ucl.ac.uk, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Standardisation of IGMPv3 In-reply-to: Your message of "Mon, 17 Jul 2000 08:25:52 PDT." <200007171525.IAA01192@windsor.research.att.com> Date: Mon, 17 Jul 2000 17:04:56 +0100 Message-ID: <19067.963849896@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk In message <200007171525.IAA01192@windsor.research.att.com>, Bill Fenner typed: >>>whatever happend to the old IETF tradition of forwards >>>compatability?:-) >>There's plenty of space in IGMPv3 packets that's available for future >>expansion. See section 4.1.10 for information about additional data in >>Query messages, 4.2.6&4.2.10 for additional per-group data in Report >>messages (which is the obvious place to put the mask extension), and >>4.2.11 for additional data relating to an entire Report message. Bill ok - sounds fine then...so i guess i'll go back to sleep... cheers jon From owner-idmr@cs.ucl.ac.uk Mon Jul 17 13:52:25 2000 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 NAA23358 for ; Mon, 17 Jul 2000 13:52:24 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 17 Jul 2000 16:25:56 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Jul 2000 16:25:51 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 17 Jul 2000 16:25:55 +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 D8B804CE17; Mon, 17 Jul 2000 11:25:54 -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 LAA26975; Mon, 17 Jul 2000 11:25:53 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA01192; Mon, 17 Jul 2000 08:25:53 -0700 (PDT) Message-Id: <200007171525.IAA01192@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: j.crowcroft@cs.ucl.ac.uk Subject: Re: Standardisation of IGMPv3 Cc: idmr@cs.ucl.ac.uk Date: Mon, 17 Jul 2000 08:25:52 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >whatever happend to the old IETF tradition of forwards >compatability?:-) There's plenty of space in IGMPv3 packets that's available for future expansion. See section 4.1.10 for information about additional data in Query messages, 4.2.6&4.2.10 for additional per-group data in Report messages (which is the obvious place to put the mask extension), and 4.2.11 for additional data relating to an entire Report message. Bill From owner-idmr@cs.ucl.ac.uk Wed Jul 19 16:01:17 2000 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 QAA15279 for ; Wed, 19 Jul 2000 16:01:15 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 19 Jul 2000 18:59:22 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 2000 18:59:18 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 2000 18:59:21 +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 A15621E017 for ; Wed, 19 Jul 2000 13:59:20 -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 NAA10231 for ; Wed, 19 Jul 2000 13:59:20 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA24335; Wed, 19 Jul 2000 10:59:19 -0700 (PDT) Message-Id: <200007191759.KAA24335@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idmr@cs.ucl.ac.uk Subject: Summary of IGMPv3 Last Call discussion so far Date: Wed, 19 Jul 2000 10:59:19 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Dear IDMR, With the IGMPv3 Last Call to Proposed Standard halfway over, I thought I'd summarize what I perceive as the state of the comments. - There should be a bit to request SPT? Better service? My view on this is that the SPT-request is implicit by including a source; it's up to the router policy as to what it does with it. Hosts shouldn't know about trees, so it'd have to be some kind of service metric, and it's very unclear how to represent it effectively. - IGMPv3 should support a source netmask There have been several messages in support of this, and several against. The supporters have given no concrete reasons why these would be useful and worth the cost of adding them. A summary of the arguments for: - Filtering on source networks is useful - Interoperability between IGMPv3 and IGMPv4 (e.g. adding netmasks) is too hard. A summary of the arguments against: - IGMPv3 is already years overdue; adding netmasks would add months, if not years, to its lifetime as an internet-draft as opposed to RFC. - Merging requests for source networks is harder than merging requests for sources - Routing protocols may have extremely complex mappings (e.g. how do you map an exclude for (192/8,G)? Does that become up to 65536 prunes, one for each route in that range? If not, what is the mapping?) - How will IGMPv3 affect IGMP-snooping routers? Summary: switches need to learn about the IGMPv3 membership report; recognizing them may be easier due to the fact that they're all sent to the same group; can't do IP source filtering at the ethernet layer so source-specific IGMPv3 info [shouldn't] add complexity. cisco is implementing IGMPv3 snooping for their switches. - How do you leave a group? There are 3 ways to leave a group; is one preferred? See http://www.aciri.org/~fenner/idmr/html-archive/2000-07/msg00040.html for details. There was no discussion on this point. - Are groups in 224.0.0.[2,255] reported? Yes. From my point of view, the notable discussion issues are: - In what way would source network masks be useful? - A more in-depth analysis of IGMPv3 snooping - Is there a preferred method of leaving a group? (This may relate to snooping, as well) Bill From owner-idmr@cs.ucl.ac.uk Wed Jul 19 16:01:38 2000 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 QAA15462 for ; Wed, 19 Jul 2000 16:01:37 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 19 Jul 2000 19:08:22 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 2000 19:08:18 +0100 Received: from alpo.casc.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 2000 19:08:22 +0100 Received: from sunce ([62.172.151.59]) by alpo.casc.com (8.9.1a/8.9.1) with SMTP id OAA06147 for ; Wed, 19 Jul 2000 14:08:10 -0400 (EDT) Message-ID: <006501bff1ac$29c04a80$3b97ac3e@ukip> From: Mladen Sablic To: idmr Subject: Multicast Traceroute and multicasting responses to response address Date: Wed, 19 Jul 2000 19:07:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I have a question on multicast traceroute implementation. I am confused on how to implement response sourcing when the response address is multicast. In the draft: - http://www.ietf.org/internet-drafts/draft-ietf-idmr-traceroute-ipm-06.txt s.6.5.3 & s.6.5.4. it says that I should find a source address that is known to the mulitcast routing table but if I am the router I am not likely to have any (S,G) enteries with me as a source. Which interface I should send it out towards the source of the query or the receiver as don't know where the client is located? Do I pick a random multicast enabled interface, join the group on it and send? For example in PIM-SM, if a trace reaches the RP and there is no (S,G) route towards the source so the trace has finished. RP's address is not known to the multicast routing table, the client can be located at the source, destination or other managment location and the response address is set to 224.0.1.32 (mtrace.mcast.net). Where does the RP send the response? Mladen From owner-idmr@cs.ucl.ac.uk Wed Jul 19 16:01:50 2000 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 QAA15550 for ; Wed, 19 Jul 2000 16:01:48 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 19 Jul 2000 20:05:14 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 2000 20:04:59 +0100 Received: from sj-msg-core-2.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 2000 20:05:03 +0100 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA14895; Wed, 19 Jul 2000 12:05:16 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA12695; Wed, 19 Jul 2000 12:05:01 -0700 (PDT) Message-Id: <200007191905.MAA12695@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Bill Fenner cc: idmr@cs.ucl.ac.uk Subject: Re: Summary of IGMPv3 Last Call discussion so far In-reply-to: Your message of "Wed, 19 Jul 2000 10:59:19 PDT." <200007191759.KAA24335@windsor.research.att.com> Date: Wed, 19 Jul 2000 12:05:01 -0700 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Bill Fenner writes: > >Dear IDMR, > > With the IGMPv3 Last Call to Proposed Standard halfway over, I thought >I'd summarize what I perceive as the state of the comments. > >- There should be a bit to request SPT? Better service? > > My view on this is that the SPT-request is implicit by including a > source; it's up to the router policy as to what it does with it. > Hosts shouldn't know about trees, so it'd have to be some kind of > service metric, and it's very unclear how to represent it effectively. > >- IGMPv3 should support a source netmask > > There have been several messages in support of this, and several against. > The supporters have given no concrete reasons why these would be useful > and worth the cost of adding them. > > A summary of the arguments for: > - Filtering on source networks is useful > - Interoperability between IGMPv3 and IGMPv4 (e.g. adding netmasks) is > too hard. > > A summary of the arguments against: > - IGMPv3 is already years overdue; adding netmasks would add months, if not > years, to its lifetime as an internet-draft as opposed to RFC. > - Merging requests for source networks is harder than merging requests for > sources > - Routing protocols may have extremely complex mappings (e.g. how do you > map an exclude for (192/8,G)? Does that become up to 65536 prunes, one > for each route in that range? If not, what is the mapping?) > > >- How will IGMPv3 affect IGMP-snooping routers? > > Summary: switches need to learn about the IGMPv3 membership report; > recognizing them may be easier due to the fact that they're all sent > to the same group; can't do IP source filtering at the ethernet layer > so source-specific IGMPv3 info [shouldn't] add complexity. > > cisco is implementing IGMPv3 snooping for their switches. > >- How do you leave a group? > > There are 3 ways to leave a group; is one preferred? See >http://www.aciri.org/~fenner/idmr/html-archive/2000-07/msg00040.html > for details. There was no discussion on this point. > >- Are groups in 224.0.0.[2,255] reported? > > Yes. I believe Paras has some comments on this. > > >From my point of view, the notable discussion issues are: >- In what way would source network masks be useful? >- A more in-depth analysis of IGMPv3 snooping >- Is there a preferred method of leaving a group? (This may relate to > snooping, as well) Leaving a group reverts to INCLUDE mode with an empty source list. This is handled by normal protocol operation by either sending a TO_IN{} report when the host previously was in EXCLUDE mode, or sending a BLOCK for the remaining sources when the host was previously in INCLUDE mode. As far as protocol consistency goes, this is the prefered method for leaving a group. One alternative with some advantages is to send an IS_IN with an empty source list when a host no longer wants to receive any sources in a group. The advantage is that a snooping switch that does not maintain an explicit source list can use this message whereas the BLOCK will not provide any information. thanks Isidor > > > Bill > From owner-idmr@cs.ucl.ac.uk Wed Jul 19 16:02:45 2000 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 QAA15965 for ; Wed, 19 Jul 2000 16:02:43 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 19 Jul 2000 20:03:26 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 2000 20:03:05 +0100 Received: from sj-msg-core-1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 2000 20:03:06 +0100 Received: from paras-ss20.cisco.com (paras-ss20.cisco.com [171.69.65.53]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA13325 for ; Wed, 19 Jul 2000 12:03:17 -0700 (PDT) From: paras@cisco.com Received: (paras@localhost) by paras-ss20.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA22108 for idmr@cs.ucl.ac.uk; Wed, 19 Jul 2000 12:03:03 -0700 (PDT) Message-Id: <200007191903.MAA22108@paras-ss20.cisco.com> Subject: Reporting of 224.0.0.[2,255] groups To: idmr@cs.ucl.ac.uk Date: Wed, 19 Jul 2000 12:03:03 -0700 (PDT) X-Mailer: ELM [version 2.5 PL1] 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 Forwarded message: > From: Bill Fenner > To: idmr@cs.ucl.ac.uk > Subject: Summary of IGMPv3 Last Call discussion so far > Date: Wed, 19 Jul 2000 10:59:19 -0700 > > > Dear IDMR, > > With the IGMPv3 Last Call to Proposed Standard halfway over, I thought > I'd summarize what I perceive as the state of the comments. > > - Are groups in 224.0.0.[2,255] reported? > > Yes. Bill, This is against the common practice of most router implementations. This will break them right away. i.e. if one implementation reports these groups and another doesn't, the switch will immidiately constraint flow to one port and open to another, breaking the protocol that relies on membership to 224.0.0.[2,255] group. Which means, OSPF, BGP can break in addition to PIM, IGMPv3 etc. I suggest that this requires a bit of discussion here, with my humble vote being against it. I understand that reporting these groups will allow switches to constrain their ports. But IMHO, it's ok to let the switches flood all their ports for these groups because there's only control traffic on these groups anyway. Not, any high bandwidth data draffic. $0.02. - Paras. From owner-idmr@cs.ucl.ac.uk Wed Jul 19 16:02:59 2000 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 QAA16066 for ; Wed, 19 Jul 2000 16:02:57 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 19 Jul 2000 18:27:54 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 2000 18:27:49 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 2000 18:27:54 +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 4688D4CE0D; Wed, 19 Jul 2000 13:27:52 -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 NAA08408; Wed, 19 Jul 2000 13:27:51 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA24203; Wed, 19 Jul 2000 10:27:50 -0700 (PDT) Message-Id: <200007191727.KAA24203@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: helmy@ceng.usc.edu Subject: Re: WG Last Call: IGMP Version 3 to Proposed Standard Cc: idmr@cs.ucl.ac.uk Date: Wed, 19 Jul 2000 10:27:50 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk > so, instead of having this 'bit' or field indicate 'SPT' or shared >tree [which is multicast routing knowledge], we can have it specify some >kind of quality indicator [like low delay, or low overhead, for >example]. This would then be translated by the router according to the >multicast routing and the quality that can be provided. Perhaps I'm missing something -- if so, I apologize. But if you give people a knob that says "Worse .. .. .. Better", they are likely to just turn it towards "Better" (especially if there are no disincentives to doing so, e.g. having to pay for it). I'd much rather see all routers just assuming that all hosts want good quality, rather than see mechanism added to the spec which would probably eventually go unused. Bill From owner-idmr@cs.ucl.ac.uk Wed Jul 19 18:59:33 2000 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 SAA19946 for ; Wed, 19 Jul 2000 18:59:32 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 19 Jul 2000 21:15:06 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 2000 21:14:55 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 2000 21:15:00 +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 30A281E03C; Wed, 19 Jul 2000 16:14:59 -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 QAA17362; Wed, 19 Jul 2000 16:14:58 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA25357; Wed, 19 Jul 2000 13:14:58 -0700 (PDT) Message-Id: <200007192014.NAA25357@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: paras@cisco.com Subject: Re: Reporting of 224.0.0.[2,255] groups Cc: idmr@cs.ucl.ac.uk Date: Wed, 19 Jul 2000 13:14:58 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >> - Are groups in 224.0.0.[2,255] reported? >> >> Yes. > >This is against the common practice of most router implementations. >This will break them right away. Since there was never any spec that said not to report these groups, there are presumably currently some implementations that report them and some that don't. Therefore, switches already have to deal with this issue, right? Bill From owner-idmr@cs.ucl.ac.uk Wed Jul 19 18:59:43 2000 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 SAA20013 for ; Wed, 19 Jul 2000 18:59:43 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 19 Jul 2000 21:26:47 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 2000 21:26:41 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 2000 21:26:46 +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 D0FC11E01E; Wed, 19 Jul 2000 16:26:44 -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 QAA17846; Wed, 19 Jul 2000 16:26:44 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA25439; Wed, 19 Jul 2000 13:26:43 -0700 (PDT) Message-Id: <200007192026.NAA25439@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: kouvelas@cisco.com Subject: Re: Leaving a group in IGMPv3 Cc: idmr@cs.ucl.ac.uk Date: Wed, 19 Jul 2000 13:26:43 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Is there any disadvantage to specifying that you always use TO_IN{} (if you were in EXCLUDE) or IS_IN{} (if you were in INCLUDE) as opposed to sending a BLOCK for the remaining sources? As you mention, this would help snooping switches a lot. Bill From owner-idmr@cs.ucl.ac.uk Wed Jul 19 19:00:24 2000 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 TAA20311 for ; Wed, 19 Jul 2000 19:00:24 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 19 Jul 2000 22:47:09 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 2000 22:47:02 +0100 Received: from omega.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 2000 22:47:06 +0100 Received: (from ycai@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA22023; Wed, 19 Jul 2000 14:47:02 -0700 (PDT) Date: Wed, 19 Jul 2000 14:47:02 -0700 (PDT) Message-Id: <200007192147.OAA22023@omega.cisco.com> From: Yiqun Cai To: fenner@research.att.com CC: paras@cisco.com, idmr@cs.ucl.ac.uk In-reply-to: <200007192014.NAA25357@windsor.research.att.com> (message from Bill Fenner on Wed, 19 Jul 2000 13:14:58 -0700) Subject: Re: Reporting of 224.0.0.[2,255] groups Reply-to: ycai@cisco.com Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk > > Since there was never any spec that said not to report these groups, > there are presumably currently some implementations that report them > and some that don't. Therefore, switches already have to deal with > this issue, right? > > Bill > Well, there is one. RIPv2 RFC (rfc2453) says not to report 224.0.0.9. Here is the related text. 4.5 Multicasting In order to reduce unnecessary load on those hosts which are not listening to RIP-2 messages, an IP multicast address will be used for periodic broadcasts. The IP multicast address is 224.0.0.9. Note that IGMP is not needed since these are inter-router messages which are not forwarded. This topic has been on and off the list for quite a while. I think it really helps if implementations of RIP, OSPF or PIM that _do_ send reports for the respectve groups can be made known, so that we know we are trying to solve a real interoperability problem. One way or the other, I am sure the majority of the routers deployed don't send reports for the routing protocols, let alone for 224.0.0.2. The snooping switches pretty much have to flood packets addressed to these groups. Therefore, I would suggest that we keep the current behavior, i.e. not to report 224.0.0.x. -- Yiqun From owner-idmr@cs.ucl.ac.uk Wed Jul 19 19:00:37 2000 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 TAA20422 for ; Wed, 19 Jul 2000 19:00:36 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 19 Jul 2000 23:48:46 +0100 Received: from haig.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 2000 23:48:38 +0100 Received: from sj-msg-core-2.cisco.com by haig.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 2000 23:48:40 +0100 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA20193; Wed, 19 Jul 2000 15:48:50 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA12784; Wed, 19 Jul 2000 15:48:36 -0700 (PDT) Message-Id: <200007192248.PAA12784@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Wilbert de Graaf cc: Isidor Kouvelas , idmr@cs.ucl.ac.uk Subject: Re: Summary of IGMPv3 Last Call discussion so far In-reply-to: Your message of "Wed, 19 Jul 2000 14:56:30 PDT." <3976240E.A9FA3322@hetnet.nl> Date: Wed, 19 Jul 2000 15:48:36 -0700 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Wilbert de Graaf writes: > >Isidor Kouvelas wrote: > >> >- Is there a preferred method of leaving a group? (This may relate to >> > snooping, as well) >> >> Leaving a group reverts to INCLUDE mode with an empty source list. This >> is handled by normal protocol operation by either sending a TO_IN{} >> report when the host previously was in EXCLUDE mode, or sending a BLOCK >> for the remaining sources when the host was previously in INCLUDE mode. >> As far as protocol consistency goes, this is the prefered method for >> leaving a group. >> >> One alternative with some advantages is to send an IS_IN with an empty >> source list when a host no longer wants to receive any sources in a >> group. The advantage is that a snooping switch that does not maintain an >> explicit source list can use this message whereas the BLOCK will not >> provide any information. > >I also think having a single way for a host to report dropping >membership is useful. As far as the host implementation is concerned, having a single way to leave the group is extra code. The behaviour specified in the draft is not a special case. >If it's going to be there, I considered these three alternatives: > >1) send a BLOCK_OLD{0.0.0.0}: block traffic from 'any' which is valid >for both the move from EXC{A} to INC and from INC{A} to INC{} Really dont like this. >2) besides sending the report as specified in the draft, also send a v2 >leave message this either... >3) define a IGMPv3 record to indicate a leave > >Although TO_IN{} seems funny when coming from INC{A}, I do think TO_IN{} >is fine: If you think about INC{} to be defined in the draft ($5.1) as a >special (the non-existent) state. That's exactly the transistion: from >membership either EXC{A} or INC{A} to this special state: INC{}. > >For short: I would vote TO_IN{} TO_IN is a filter-mode change record which has different effects on a router from a IS_IN{} report. I think the IS_IN is safer. I will have to think a bit more about this. thanks I From owner-idmr@cs.ucl.ac.uk Wed Jul 19 19:00:49 2000 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 TAA20525 for ; Wed, 19 Jul 2000 19:00:48 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 19 Jul 2000 22:56:36 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 2000 22:56:30 +0100 Received: from griffin.aciri.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 2000 22:56:34 +0100 Received: from hetnet.nl (localhost.aciri.org [127.0.0.1]) by griffin.aciri.org (8.9.3/8.9.3) with ESMTP id OAA26657; Wed, 19 Jul 2000 14:56:30 -0700 (PDT) (envelope-from wilbertdg@hetnet.nl) Message-ID: <3976240E.A9FA3322@hetnet.nl> Date: Wed, 19 Jul 2000 14:56:30 -0700 From: Wilbert de Graaf X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.0.36 i386) X-Accept-Language: en MIME-Version: 1.0 To: Isidor Kouvelas CC: idmr@cs.ucl.ac.uk Subject: Re: Summary of IGMPv3 Last Call discussion so far References: <200007191905.MAA12695@kouvelas-u10.cisco.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 Isidor Kouvelas wrote: > >- Is there a preferred method of leaving a group? (This may relate to > > snooping, as well) > > Leaving a group reverts to INCLUDE mode with an empty source list. This > is handled by normal protocol operation by either sending a TO_IN{} > report when the host previously was in EXCLUDE mode, or sending a BLOCK > for the remaining sources when the host was previously in INCLUDE mode. > As far as protocol consistency goes, this is the prefered method for > leaving a group. > > One alternative with some advantages is to send an IS_IN with an empty > source list when a host no longer wants to receive any sources in a > group. The advantage is that a snooping switch that does not maintain an > explicit source list can use this message whereas the BLOCK will not > provide any information. I also think having a single way for a host to report dropping membership is useful. If it's going to be there, I considered these three alternatives: 1) send a BLOCK_OLD{0.0.0.0}: block traffic from 'any' which is valid for both the move from EXC{A} to INC and from INC{A} to INC{} 2) besides sending the report as specified in the draft, also send a v2 leave message 3) define a IGMPv3 record to indicate a leave Although TO_IN{} seems funny when coming from INC{A}, I do think TO_IN{} is fine: If you think about INC{} to be defined in the draft ($5.1) as a special (the non-existent) state. That's exactly the transistion: from membership either EXC{A} or INC{A} to this special state: INC{}. For short: I would vote TO_IN{} - Wilbert From owner-idmr@cs.ucl.ac.uk Wed Jul 19 21:40:37 2000 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 VAA16165 for ; Wed, 19 Jul 2000 21:40:37 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 19 Jul 2000 23:56:04 +0100 Received: from haig.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 2000 23:53:29 +0100 Received: from sj-msg-core-1.cisco.com by haig.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 2000 23:53:32 +0100 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA27300; Wed, 19 Jul 2000 15:53:39 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA12803; Wed, 19 Jul 2000 15:53:25 -0700 (PDT) Message-Id: <200007192253.PAA12803@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Bill Fenner cc: kouvelas@cisco.com, idmr@cs.ucl.ac.uk Subject: Re: Leaving a group in IGMPv3 In-reply-to: Your message of "Wed, 19 Jul 2000 13:26:43 PDT." <200007192026.NAA25439@windsor.research.att.com> Date: Wed, 19 Jul 2000 15:53:25 -0700 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Bill Fenner writes: > >Is there any disadvantage to specifying that you always use TO_IN{} (if >you were in EXCLUDE) or IS_IN{} (if you were in INCLUDE) as opposed to >sending a BLOCK for the remaining sources? As you mention, this would >help snooping switches a lot. The difference is that with the BLOCK, the router will send a query to figure out if any other host is interested in the traffic. The IS_IN{} will not have this effect. As a result the router will let the sources time out normally... I From owner-idmr@cs.ucl.ac.uk Thu Jul 20 03:29:13 2000 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 DAA17284 for ; Thu, 20 Jul 2000 03:29:12 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 20 Jul 2000 05:58:36 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jul 2000 05:58:31 +0100 Received: from unisonet.uniso.br by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 20 Jul 2000 05:58:32 +0100 Received: from 206.15.132.42 by uniso.br (SMI-8.6/SMI-SVR4) id BAA09286; Thu, 20 Jul 2000 01:55:13 -0300 From: post77@australiamail.com Message-ID: <000047d65df8$00007948$00004e74@> To: Undisclosed Subject: Win a trip for 2 to the Sydney 2000 Olympics in Australia - Obligation Free! 9149 Date: Mon, 20 Mar 2000 17:19:09 -0800 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: post77@australiamail.com Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Win airfares, 6 nights first class accommodation and tickets to major events at the 2000 Olympics in Sydney this September. Register free for August 10 prize draw by clicking here: http://www.govisitaustralia.com/default1.htm The lucky winners of our July 10 Draw are already packing their bags! See you in Sydney! ================================================================ Note: If you have received this notice in error and do not wish to participate, please accept our apologies and please double click on the below link to be excluded from further communication mailto:exclude77@uole.com?subject=delete ================================================================ Win airfares, 6 nights first class accommodation and tickets to major events at the 2000 Olympics in Sydney this September. Register free for August 10 prize draw by clicking here: http://www.govisitaustralia.com/default1.htm The lucky winners of our July 10 Draw are already packing their bags! See you in Sydney! ================================================================ Note: If you have received this notice in error and do not wish to participate, From owner-idmr@cs.ucl.ac.uk Thu Jul 20 10:53:25 2000 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 KAA22361 for ; Thu, 20 Jul 2000 10:53:20 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 20 Jul 2000 15:40:57 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jul 2000 15:40:51 +0100 Received: from mail1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 20 Jul 2000 15:40:56 +0100 Received: from bwilliam-8000.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 HAA08280; Thu, 20 Jul 2000 07:35:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20000720092822.00b39030@sj-email.cisco.com> X-Sender: bwilliam@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 09:33:59 -0700 To: ycai@cisco.com, fenner@research.att.com From: Beau Williamson Subject: Re: Reporting of 224.0.0.[2,255] groups Cc: paras@cisco.com, idmr@cs.ucl.ac.uk In-Reply-To: <200007192147.OAA22023@omega.cisco.com> References: <200007192014.NAA25357@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk At 02:47 PM 7/19/2000, Yiqun Cai wrote: >> >> Since there was never any spec that said not to report these groups, >> there are presumably currently some implementations that report them >> and some that don't. Therefore, switches already have to deal with >> this issue, right? >> >> Bill >> > >Well, there is one. RIPv2 RFC (rfc2453) says not to report 224.0.0.9. >Here is the related text. > >4.5 Multicasting > > In order to reduce unnecessary load on those hosts which are not > listening to RIP-2 messages, an IP multicast address will be used for > periodic broadcasts. The IP multicast address is 224.0.0.9. Note > that IGMP is not needed since these are inter-router messages which > are not forwarded. > >This topic has been on and off the list for quite a while. I think >it really helps if implementations of RIP, OSPF or PIM that _do_ >send reports for the respectve groups can be made known, so that we >know we are trying to solve a real interoperability problem. > >One way or the other, I am sure the majority of the routers deployed >don't send reports for the routing protocols, let alone for 224.0.0.2. >The snooping switches pretty much have to flood packets addressed to >these groups. Therefore, I would suggest that we keep the current >behavior, i.e. not to report 224.0.0.x. That's the problem that Paras is talking about. The current behavior is not what is documented in the IGMP spec. I too would like to see the spec changed to at least say that hosts MAY report these groups but also include a note that says that switches SHOULD always flood these groups since there is no way to know if that all implementations of OSPF, EIGRP, or protocol-foo, does or does not report. Beau >-- >Yiqun From owner-idmr@cs.ucl.ac.uk Thu Jul 20 11:00:21 2000 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 LAA26513 for ; Thu, 20 Jul 2000 11:00:20 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 20 Jul 2000 13:22:43 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jul 2000 13:22:38 +0100 Received: from c1mailgw3.prontomail.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 20 Jul 2000 13:22:42 +0100 Received: from c1web02 (208.178.29.202) by c1mailgw3.prontomail.com (NPlex 4.5.049) id 3969EAB300104B02 for idmr@cs.ucl.ac.uk; Thu, 20 Jul 2000 05:22:27 -0700 X-Version: indya 6.2.3 .2329.0 From: vijayc@indya.com Message-Id: <7CB25277FDD54D1178850005B8E28024@vijayc.indya.com> Date: Thu, 20 Jul 2000 18:00:21 +0530 X-Priority: Normal Content-Type: text/plain; charset=iso-8859-1 To: idmr@cs.ucl.ac.uk Subject: Use of srcmask in prune/grafts X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, While there is discussion about whether Netmask should be specified in IGMPv3 source filtering, I would like to seek clarification regarding its use in prune/graft messages in Mcast routing protocols(dvmrp/pim). In DVMRPv3(as in draft-ietf-idmr-dvmrp-v3-09.txt) for instance, the multicast delivery tree is established per source.Then when the multicast datagram is forwarded down the tree, if a router finds that it has no members for the GROUP, it sends upstream prune.This prune contains source address and group address of the datagram. But what netmask is to be used in this prune? If there is any change in the upstream/downstream dependency then it will be indicated in the flash route reports and the delivery tree for the (source-netmask) adjusted. Iam unable to comprehend why the netmask field given in the prune/graft messages? . I thought if IGMPv3 uses netmask to filter source then it may be used in the prune.grafts. Now, I think I have misunderstood something. Can anyone explain Regards, Vijay Enter your default signature here Sent by Indya Messaging Service From owner-idmr@cs.ucl.ac.uk Thu Jul 20 14:04:06 2000 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 OAA01611 for ; Thu, 20 Jul 2000 14:04:06 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 20 Jul 2000 18:15:57 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jul 2000 18:15:50 +0100 Received: from sigma.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 20 Jul 2000 18:15:50 +0100 Received: from localhost (jzwiebel@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA19872; Thu, 20 Jul 2000 10:15:39 -0700 (PDT) Message-Id: <200007201715.KAA19872@sigma.cisco.com> To: Bill Fenner cc: vijayc@indya.com, idmr@cs.ucl.ac.uk Subject: Re: Use of srcmask in prune/grafts In-reply-to: Your message of "Thu, 20 Jul 2000 08:38:05 PDT." <200007201538.IAA29778@windsor.research.att.com> Date: Thu, 20 Jul 2000 10:15:38 -0700 From: "John M. Zwiebel" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk ^ ^ PIM has never specified how non-host masks work in joins and prunes. ^ FWIW: A prune for a non-host mask might be useful, but A join sent for a non-host mask doesn't make sense. This was discovered during the first implementations of PIM 6 years ago. Perhaps someone has a 'good idea'? Remember that PIM depends on the unicast routing to make a decision and so you (theoretically) could end up with a join for 0.0.0.0/0 [default]. ------------------------------------------------------------------------------ John Zwiebel Phone: 408-526-5303 Cisco Systems Inc. IP Multicast Group From owner-idmr@cs.ucl.ac.uk Thu Jul 20 14:04:14 2000 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 OAA01716 for ; Thu, 20 Jul 2000 14:04:13 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 20 Jul 2000 16:38:10 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jul 2000 16:38:05 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 20 Jul 2000 16:38:09 +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 473A94CE64; Thu, 20 Jul 2000 11:38:07 -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 LAA03772; Thu, 20 Jul 2000 11:38:06 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA29778; Thu, 20 Jul 2000 08:38:06 -0700 (PDT) Message-Id: <200007201538.IAA29778@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: vijayc@indya.com Subject: Re: Use of srcmask in prune/grafts Cc: idmr@cs.ucl.ac.uk Date: Thu, 20 Jul 2000 08:38:05 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk DVMRPv3 applies prunes to routes; the netmask in a prune is used to ensure that the right route is matched. The netmask is not arbitrary; it must either exactly match a route in routing table or be all-1's (for a source-specific prune). Other masks will be ignored. PIM has never specified how non-host masks work in joins and prunes. Bill From owner-idmr@cs.ucl.ac.uk Thu Jul 20 17:06:14 2000 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 RAA02815 for ; Thu, 20 Jul 2000 17:06:14 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 20 Jul 2000 19:23:58 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jul 2000 19:23:53 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 20 Jul 2000 19:23:51 +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 0EE3E4CE37; Thu, 20 Jul 2000 14:23:50 -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 OAA12384; Thu, 20 Jul 2000 14:23:49 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA01561; Thu, 20 Jul 2000 11:23:48 -0700 (PDT) Message-Id: <200007201823.LAA01561@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jzwiebel@cisco.com Subject: Re: Use of srcmask in prune/grafts Cc: idmr@cs.ucl.ac.uk Date: Thu, 20 Jul 2000 11:23:48 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk I struggled with the semantics of prunes-with-masks when trying to figure out how it should work for DVMRP. In particular, when route aggregation occurs, you have to decide what the semantics of the message are or you end up multicasting the message upstream towards all of the component subnets. I think the best thing to do with a prune with a mask is for the prune to travel towards the source, allowing the mask to get longer if aggregation happened on the way. It instantiates prune state where it travels, which will cause further traffic from sources that fall under other pieces of the aggregate to trigger prunes. This isn't very applicable to PIM-SM, though, since the only prunes we're interested either: - cancel Joins that we've sent, or - are S,G,RPbit prunes that all travel towards the RP so don't have to deal with route aggregation. Do S-prefix, G Joins in PIM-SM make sense in the face of MSDP, where the source domain can tell you exactly what mask makes sense? Obviously the general case doesn't make sense since you have to "multicast" the Join when it's bigger than the individual routes you have (e.g. a Join for 0.0.0.0/0 turns into 75,000 individual Joins upstream?...) (Should this discussion happen on the PIM mailing list?) Bill From owner-idmr@cs.ucl.ac.uk Thu Jul 20 17:06:26 2000 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 RAA02898 for ; Thu, 20 Jul 2000 17:06:26 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 20 Jul 2000 21:31:45 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jul 2000 21:31:40 +0100 Received: from sigma.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 20 Jul 2000 21:31:37 +0100 Received: from localhost (jzwiebel@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA26193; Thu, 20 Jul 2000 13:31:32 -0700 (PDT) Message-Id: <200007202031.NAA26193@sigma.cisco.com> To: Bill Fenner cc: idmr@cs.ucl.ac.uk Subject: Re: Use of srcmask in prune/grafts In-reply-to: Your message of "Thu, 20 Jul 2000 11:23:48 PDT." <200007201823.LAA01561@windsor.research.att.com> Date: Thu, 20 Jul 2000 13:31:32 -0700 From: "John M. Zwiebel" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk ^ ^ Do S-prefix, G Joins in PIM-SM make sense in the face of MSDP, where ^ the source domain can tell you exactly what mask makes sense? Obviously ^ the general case doesn't make sense since you have to "multicast" the ^ Join when it's bigger than the individual routes you have (e.g. a ^ Join for 0.0.0.0/0 turns into 75,000 individual Joins upstream?...) MSDP doesn't help, especially if you consider SSM and IGMPv3 where you may want to receive from one source on a subnet, but not the one right next to it. ^ ^ (Should this discussion happen on the PIM mailing list?) ^ Yes, if I thought there was a chance of something coming out of it, but sparse-mode aggregation just doesn't make sense to me -- although in the "long run" perhaps something will have to happen. AFAIC, that isn't going to be until we discover how multicast really is used in the interdomain environment. (2cents) ------------------------------------------------------------------------------ John Zwiebel Phone: 408-526-5303 Cisco Systems Inc. IP Multicast Group From owner-idmr@cs.ucl.ac.uk Fri Jul 21 03:36:10 2000 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 DAA17439 for ; Fri, 21 Jul 2000 03:36:10 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 21 Jul 2000 06:43:11 +0100 Received: from haig.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 21 Jul 2000 06:43:07 +0100 Received: from suraksha.wipsys.soft.net by haig.cs.ucl.ac.uk with Internet SMTP id ; Fri, 21 Jul 2000 06:43:03 +0100 Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id LAA16952; Fri, 21 Jul 2000 11:06:37 +0530 (IST) Date: Fri, 21 Jul 2000 11:06:37 +0530 (IST) From: vijayc@indya.com Message-Id: <200007210536.LAA16952@suraksha.wipsys.soft.net> Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma016944; Fri, 21 Jul 00 11:06:32 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=------------InterScan_NT_MIME_Boundary Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Apparently-To: idmr-pp --------------InterScan_NT_MIME_Boundary Content-Type: message/rfc822 Received: from indya.com ([192.168.162.30]) by bhairavi.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA68BC; Fri, 21 Jul 2000 11:05:42 +0530 Date: Fri, 21 Jul 2000 11:17:23 +0530 (IST) From: Vijay To: fenner@research.att.com cc: pusateri@juniper.net, mani.balaram@wipro.com, idmr@cs.ucl.ac.uk Subject: Src Mask in dvmrp prune/grafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, With regard to your reply that src mask in dvmrp prune is associate it with the route- Should'nt the prunes in dvmrp be concerned with the source alone. The changes to the delivery tree, which associates to the route, are indicated in the route reports and poison reports itself. A prune merely removes the interface from the downstream list for the particular source(src-network if mask is valid in prune) - group in the forwarding cache. It should not cut off the branch of the per source delivery tree because the downstream may have members interested in some other group but same source. Hence,where is the association between route and prune and hence what is the need of netmask unless IGMP uses it. Please clarify if I have misunderstood. Regards, Vijay --------------InterScan_NT_MIME_Boundary Content-Type: text/plain --------------InterScan_NT_MIME_Boundary-- From owner-idmr@cs.ucl.ac.uk Fri Jul 21 11:39:37 2000 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 LAA02913 for ; Fri, 21 Jul 2000 11:39:29 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 21 Jul 2000 14:40:19 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 21 Jul 2000 14:40:14 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 21 Jul 2000 14:40:12 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12799; Fri, 21 Jul 2000 09:40:09 -0400 (EDT) Message-Id: <200007211340.JAA12799@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-traceroute-ipm-07.txt,.ps Date: Fri, 21 Jul 2000 09:40:09 -0400 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 : A ''traceroute'' facility for IP Multicast. Author(s) : B. Fenner, S. Casner Filename : draft-ietf-idmr-traceroute-ipm-07.txt,.ps Pages : 24 Date : 20-Jul-00 This draft describes the IGMP multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires a special packet type and implementation on the part of routers. This speci- fication describes the required functionality in multicast routers, as well as how management applications can use the new router func- tionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-traceroute-ipm-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idmr-traceroute-ipm-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idmr-traceroute-ipm-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000720141829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-traceroute-ipm-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-traceroute-ipm-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141829.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Fri Jul 21 11:43:17 2000 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 LAA04608 for ; Fri, 21 Jul 2000 11:43:15 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 21 Jul 2000 14:27:58 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 21 Jul 2000 14:27:52 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 21 Jul 2000 14:27:49 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12000; Fri, 21 Jul 2000 09:27:43 -0400 (EDT) Message-Id: <200007211327.JAA12000@ietf.org> To: IETF-Announce:; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: idmr@cs.ucl.ac.uk From: The IESG Subject: Protocol Action: IP Multicast Routing MIB to Proposed Standard Date: Fri, 21 Jul 2000 09:27:43 -0400 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk The IESG has approved publication of the following Internet-Drafts: o IP Multicast Routing MIB as a Proposed Standard. o Internet Group Management Protocol MIB as a Proposed Standard o Protocol Independent Multicast MIB as an Experimental Protocol. These documents are the product of the Inter-Domain Multicast Routing Working Group. The IESG contact person is Rob Coltun. Technical Summary draft-ietf-idmr-igmp-mib defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP), version 1 or version 2. All of this MIB module is applicable to IPv4 multicast routers; a subset is applicable to hosts implementing IGMP. This MIB does not support management of IGMP or equivalent functionality for other address families, such as IPv6. Such management may be supported by other MIBs. draft-ietf-idmr-pim-mib defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol (RFC2362). This MIB module is applicable to IPv4 multicast routers which implement PIM. This MIB does not support management of PIM for other address families, including IPv6. Such management may be supported by other MIBs. draft-ietf-idmr-multicast-routmib defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. Working Group Summary There was no significant dissent from the working group regarding these documents. Protocol Quality These drafts were reviewed by John Flick and Bert Wijnen for the IESG. There are implementations of these MIBs. Note to RFC Editor: The IESG requests the RFC Editor to remove the word experimental from both the abstract and introduction of draft-ietf-idmr-multicast-routmib. From owner-idmr@cs.ucl.ac.uk Sat Jul 22 03:37:14 2000 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 DAA27510 for ; Sat, 22 Jul 2000 03:37:13 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sat, 22 Jul 2000 08:00:47 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 22 Jul 2000 08:00:41 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 22 Jul 2000 08:00:35 +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 090B61E006; Sat, 22 Jul 2000 03:00:35 -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 DAA10054; Sat, 22 Jul 2000 03:00:34 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id AAA13692; Sat, 22 Jul 2000 00:00:33 -0700 (PDT) Message-Id: <200007220700.AAA13692@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: vijayc@indya.com Subject: Re: Re: Use of srcmask in prune/grafts Cc: idmr@cs.ucl.ac.uk Date: Sat, 22 Jul 2000 00:00:33 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >I think it is not necessary to associate the prune with a route. Before IGMPv3, the only reason a prune would occur in DVMRP was because there were no group members at all. Therefore, it makes sense to prune the largest unit possible (i.e. the route associated with the source being pruned). The netmask was introduced in prunes (and grafts) in order to: a) ensure that the prune was being applied to the appropriate route (especially if you have overlapping routes in your routing table) b) allow /32 masks to specify source-specific prunes. Bill From owner-idmr@cs.ucl.ac.uk Sat Jul 22 03:38:01 2000 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 DAA27689 for ; Sat, 22 Jul 2000 03:38:01 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sat, 22 Jul 2000 06:37:34 +0100 Received: from haig.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 22 Jul 2000 06:37:30 +0100 Received: from c1mailgw1.prontomail.com by haig.cs.ucl.ac.uk with Internet SMTP id ; Sat, 22 Jul 2000 06:37:28 +0100 Received: from c1web01 (208.178.29.201) by c1mailgw1.prontomail.com (NPlex 4.5.049) id 3977B62B00007585; Fri, 21 Jul 2000 22:36:31 -0700 X-Version: indya 6.2.3 .2329.0 From: vijayc@indya.com Message-Id: Date: Sat, 22 Jul 2000 11:03:32 +0530 X-Priority: Normal Content-Type: text/plain; charset=iso-8859-1 To: fenner@research.att.com Subject: Re: Re: Use of srcmask in prune/grafts CC: idmr@cs.ucl.ac.uk X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello Sir, You wrote in your earlier mail, DVMRPv3 applies prunes to routes; the netmask in a prune is used to ensure that the right route is matched. There is some mention about this in the draft, but I think it is not necessary to associate the prune with a route. Prune is used to cut off a downstream interface from the forwarding cache.It shouls not be for cutting of a branch of the per source delivery tree. The delivery tree is constructed by exchange of route reports/ poison reports and the route entry can have a list of downstreams for that route,ie, per source-network(src-mask). But forwarding cache is built for multicast packets for every (S,G). If a router finds that there are no group members for (S,G) it can prune(S,G) and thereby the interface can be removed from the list of downstreams for that forwarding cache entry.This way it would'nt affect the per source delivery tree. The per source delivery tree should not be affected because of the prune. It should be affected by the route reports and poison reports. Hence if IGMP does not indicate Masks but only S,G as in IGMPv3 now, why use source masks in DVMRP prune/grafts. If Iam wrong kindly clarify when a route specific prune will be done and how it will help. Regards, Vijay Sent by Indya Messaging Service From owner-idmr@cs.ucl.ac.uk Mon Jul 24 09:14:11 2000 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 JAA22390 for ; Mon, 24 Jul 2000 09:14:10 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 24 Jul 2000 13:07:21 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Jul 2000 13:07:16 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 24 Jul 2000 13:07:11 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05845; Mon, 24 Jul 2000 08:07:10 -0400 (EDT) Message-Id: <200007241207.IAA05845@ietf.org> To: IETF-Announce:; Cc: idmr@cs.ucl.ac.uk From: The IESG SUBJECT: Last Call: IGMP-based Multicast Forwarding ('IGMP Proxying') to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 24 Jul 2000 08:07:09 -0400 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk The IESG has received a request from the Inter-Domain Multicast Routing Working Group to consider IGMP-based Multicast Forwarding ('IGMP Proxying') as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 14, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-fenner-igmp-proxy-03.txt From owner-idmr@cs.ucl.ac.uk Mon Jul 24 09:14:26 2000 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 JAA22439 for ; Mon, 24 Jul 2000 09:14:25 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 24 Jul 2000 12:39:17 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Jul 2000 12:39:13 +0100 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 24 Jul 2000 12:39:11 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28510; Mon, 24 Jul 2000 07:39:10 -0400 (EDT) Message-Id: <200007241139.HAA28510@ietf.org> To: IETF-Announce:; Cc: idmr@cs.ucl.ac.uk From: The IESG SUBJECT: Last Call: IGMP-based Multicast Forwarding ('IGMP Proxying') to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 24 Jul 2000 07:39:10 -0400 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk The IESG has received a request from the Inter-Domain Multicast Routing Working Group to consider IGMP-based Multicast Forwarding ('IGMP Proxying') as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 14, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-fenner-igmp-proxy-03.txt From owner-idmr@cs.ucl.ac.uk Mon Jul 24 09:18:13 2000 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 JAA22941 for ; Mon, 24 Jul 2000 09:18:11 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 24 Jul 2000 11:50:59 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Jul 2000 11:50:53 +0100 Received: from nscolmar.colmar.uha.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 24 Jul 2000 11:50:38 +0100 Received: from colmar.colmar.uha.fr (colmar.colmar.uha.fr [194.167.107.31]) by nscolmar.colmar.uha.fr (8.9.3/8.9.3) with ESMTP id MAA14860; Mon, 24 Jul 2000 12:14:27 +0200 From: conf@colmar.uha.fr Received: from gtrpc13 (gtrpc13.colmar.uha.fr [192.168.12.51]) by colmar.colmar.uha.fr (8.8.8/8.8.8) with SMTP id MAA07691; Mon, 24 Jul 2000 12:46:58 +0100 (WET DST) Message-Id: <3.0.1.32.20000724135255.00936410@colmar.colmar.uha.fr> X-Sender: conf@colmar.colmar.uha.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Mon, 24 Jul 2000 13:52:55 +0200 To: conf@colmar.colmar.uha.fr Subject: Call for papers of ICN'01 & Final program of ECUMN'00 Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: quoted-printable Please feel free to circulate this following : - call for papers of ICN'01 (see 0000,0000,fefehttp://iutsun1.colmar.uha.fr/= ICN01.html ) AND=20 - final program of ECUMN'00 (see= 0000,0000,fefehttp://iutsun1.colmar.uha.fr= /ECUMN2000.html ) to interested colleagues. Accept our sincere apologies if you receive multiple copies. ----------------------------------------------------------------------------= ---
CALL FOR PAPERS=20 IEEE International Conference on Networking=20 ICN'01=20 July 11-13, 2001 - CREF, Colmar, France=20
GENERAL INFORMATION=20 The 2001 International Conference on Networking (ICN'01) is sponsored by= IEEE/Comsoc, IEEE/Computer, by IEE, by SEE and by WSES. ICN'01 is organized= by academic, research and industrial societies will be held at the= Technical Institute, Colmar, part of the University of Haute Alsace,= France, from Wednesday July 11, 2001 to Friday July 13, 2001. The city of= Colmar is ideally situated in the eastern part of France, near the German= and Swiss borders. The city of Colmar has been working on its own= Metropolitan Area Network (MAN) project, called OASICE, including LAN= interconnection, PBX interconnection and interactive video. An exhibition= illustrating these topics will be organized for industrial companies and= development research institutes.=20 In order to encourage closer interaction between academic and industrial ATM= research communities, we solicit both academic research papers and= industrial contributions.=20 TOPICS OF SPECIAL INTEREST=20 Topics of interest include, but are not limited to the following:=20 =20 Communications switching and routing =20 Communications modeling =20 Communications security =20 Computer communications =20 Multimedia and multicast communications =20 Internet environment =20 Network Management and control =20 Quality of Service (IntServ, DiffServ, =85) =20 Wireless Communications (Satellite, WLL, 3G) =20 Voice over IP =20 Java, Tina, Corba architectures Network signaling =20 ATM networks =20 ATM/IP integration =20 Integrated services =20 Traffic engineering =20 Telecommunication networks architectures =20 Performance evaluation, simulation =20 Mobile agents, active and intelligent networks =20 Applications and case studies =20 Protocol design and evaluation =20 MPLS=20 These topics can be discussed in term of concepts, state of the art,= standards, implementations, running experiments and applications.=20 INSTRUCTIONS FOR AUTHORS=20 Mail four papers or E-mail preferably in Word 6 format, or alternately a= postscript version of a 2000-word extended abstract summarizing an original= work. All the manuscripts must be written in English. The top of the first= page of each paper should include the title of the paper, authors' name,= position, address, telephone and fax numbers, e-mail of the author= responsible for correspondence and a list of four keywords. The deadline= for submission of all extended abstracts is December 10, 2000 with= notification of acceptance by February 20, 2001. Submission of camera-ready= paper is by March 30, 2001.=20 Authors of accepted papers will be invited to submit full-length manuscripts= for inclusion in the proceedings with ISBN.=20 All submitted papers should be sent to the following address:=20 Pascal LORENZ=20 University of Haute Alsace=20 IUT - Department GTR=20 34 rue du Grillenbreit=20 68008 Colmar, France=20 Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042=20 E-mail: lorenz@colmar.uha.fr=20 Check our Web page at= 0000,0000,fefehttp://iutsun1.colmar.uha.fr= /ICN01.html for the latest information concerning the= conference.=20 Best papers will be forwarded for consideration in a special issue of a= journal.=20 TUTORIALS AND WORKSHOPS=20 Tutorials and workshops provide overviews of current high interest topics.= Proposals for half of full day tutorials are due by December 10, 2000.=20 INTERNATIONAL ADVISORY COMMITTEE=20 R. Addie (Australia) - University of Southern Queensland=20 K. Begain (Jordan) - Mu'tah University=20 A. Benslimane (France) - University of Belfort-Montbeliard=20 B. Bing (Singapore) - Ngee Ann Polytechnic=20 D. Bonjour (France) - CNET=20 A. Brandwajn (USA) - University of California Santa Cruz=20 J.P. Coudreuse (France) =96 Mitsubishi=20 J. Crowcroft (UK) =96 University College London=20 S. Fdida (France) =96 LIP6=20 B. Gavish (USA) - Vanderbilt University=20 H. Guyennet (France) - University of Franche-Comte=20 J. Halpern (USA) =96 Newbridge=20 Z. Hulicki (Poland) =96 University of Cracow=20 R. Israel (France) - IEEE=20 A. Jajszczyk (Poland) - University of Mining & Metallurgy=20 A. Jamalipour (Australia) - University of Sydney=20 S. Kota (USA) - Lockeed Martin=20 D. Kouvatsos (UK) - University of Bradford=20 S. Kumar (USA) =96 Ericsson=20 G.S. Kuo (Taiwan) =96 National Central University=20 F. Le Faucheur (France) - Cisco=20 M. Lee (Korea) =96 Dongshin University=20 P. Lorenz (France) - University of Haute Alsace=20 H.. Mouftah (Canada) - Queen's University=20 G. Omidyar (USA) - Computer Sciences Corp.=20 J.J. Pansiot (France) - University of Strasbourg=20 M. Potts (Switzerland) - Martel=20 Z. Mammeri (France) - University of Toulouse=20 N. Mastorakis (Greece) - Military Institutions of University Education=20 S. Moyer (USA) - Bellcore=20 R. Muraine (France) - Newbridge=20 G. Pujolle (France) - University of Versailles-Saint-Quentin=20 S. Rao (Switzerland) - Ascom=20 A. Reid (UK) - British Telecom=20 S. Ritzenthaler (France) - Newbridge=20 P. Rolin (France) - ENST Bretagne=20 R. Saracco (Italy) - CSELT=20 G. Swallow (USA) - Cisco=20 H. Tobiet (France) =96 Clemessy=20 M. Trehel (France) =96 University of Franche-Comte=20 V.A. Villagra (Spain) =96 University of Madrid=20 E. Vazquez Gallo (Spain) =96 University of Madrid=20 O. Yang (Canada) - University of Ottawa=20 IMPORTANT DATES=20 Extended Abstract due: December 10, 2000=20 Notification of acceptance: February 20, 2001=20 Deadline for full-length camera-ready manuscript: March 30, 2001=20 ---------------------------------------------------------------------------
1st IEEE European Conference on Universal Multiservice= Networks ECUMN'2000 October 2-4, 2000 - CREF, Colmar, France FINAL PROGRAM
=20 08:30 - 18:30 Conference Registration Monday October 2, 2000 09:00 - 09:20 Opening Address=20 09:20 - 10:30 Tutorial Session 1 Internet Services over Mobile and Wireless Networks: Architectures and= Protocols G. Omidyar, Computer Sciences Corp., USA ; M.J. Montpetit, Teledesic LLC,= USA 10:30 - 11:00 Coffee Break 11:00 - 12:15 Network Architecture and Convergence Chair: S. Ritzenthaler, Newbridge, France MPLS and Next Generation Access Network A. Kankkunen, Integral Access Inc, USA Deutsche Telekom's View on Network Convergence L. Falkenhagen Deutsche Telekom AG, Germany A Functional Architecture for End-to-end Quality-of-Service in a= Multi-domain Network E. Pagani, G.P. Rossi, University of Milano, Italy 12:15 - 13:00 Panel Discussion 1 - Network Evolution and Convergence 13:00 - 14:30 Lunch 14:30 - 16:15 Traffic=20 Chair: M. Villen, Telefonica I+D, Spain The Relevance of the Bufferless Analysis for Traffic Management in= Telecommunication Networks G. Hasslinger, F. Hartleb, Telekom Innovations-GmbH, Germany ; M. Fiedler,= University of Karlskrona/Ronneby, Sweden Mapping of Loss and Delay Between IntServ and DiffServ T. Chahed, G. H=E9buterne, C. Fayet, National Institute of= Telecommunications, France Resource Demand of Aggregated Resource Reservations J. Ehrensberger, Swiss Federal Institute of Technology, Switzerland Characterization of the MPEG-2 Video Traffic Generated by DVD Applications A. Chodorek, Kielce University of Technology, Poland ; R. Chodorek,= University of Mining and Metallurgy, Poland 14:30 - 16:15 Interworking between narrow band and broadband networks Chair: S. Chakraborty, Technical University of Helsinki, Finland Integrating Euro-ISDN with ATM Technology: Interworking Mechanisms and= Services Support L. Mandalos, K. Leonidou, C. Andreopoulos, J. Drakos, S. Koubias, G.= Papadopoulos, University of Patras, Greece Extending the Internet with the Intelligent Network Capabilities B. El Ouahidi, M. Bouhdadi, University of Rabat, Morocco ; D. Bourget, ENST,= France A Suitable Service Discipline for ATM-Ethernet Interconnection J.M. Arco, D. Meziat, B. Alarcos, University of Alcala, Spain Interoperability of ATM-Ethernet Interworking System: Design and Congestion= Control R. Ouni, A. Soudani, S. Nasri, M. Abid, R. Tourki, University of Monastir,= Tinisia ; K. Torki, INPG, France 16:15 - 16:45 Coffee Break 16:45 - 18:30 Routing Chair: P. Chemouil, France Telecom R&D, France Adaptive Routing and Load Balancing of Ephemeral Connections M. Heusse, ENST de Bretagne, France A new Multi-Services Rerouting Algorithm A. Gueroui, University of Versailles, France ; L. Mokdad University of= Dauphine, France ; J. Ben-Othman University of Paris 6, France Extending Mobile IP-v6 with Multicast to Support Mobile Networks in IPv6 T. Ernst, C. Castelluccia, INRIA Rh=F4ne-Alpes, France ; H.Y. Lach, Motorola= Labs, France 16:45 - 18:30 Interworking between IP and ATM Chair: M. Potts, Martel, Switzerland Topology Optimization of IP over ATM L. Frelechou, M. Osborne, R. Haas, IBM Research, Switzerland Resource Reservation with Boomerang via Open Interfaces M. Maliosz, Budapest University of Technology and Economics, Hungary Efficient Translation of Network Performance Parameters for Transport of IP= Packets over Cell-Switched Subnetworks J. Schmitt, M. Karsten, R. Steinmetz, Darmstadt University of Technology,= Germany Design of Adaptive Access Network and Control Protocol H. Nakagawa, I. Kazunari, N. Ohta, NTT Information Sharing Platform= Laboratories, Japan 19:15 Reception - Town Hall Tuesday October 3, 2000 09:00 - 10:45 End to end traffic Control (1) Chair: U. Krieger, Deutsche Telecom, Germany Guaranteed QoS for TCP flows in ATM-based DiffServ Networks T. M=FCller, Dresden University of Technology, Germany Virtual Buffering Strategy for GFR Services in IP/ATM Internetworks S.C. Hu, Ming Shin Institute of Technology, Taiwan ; P.C. Wang, Y.C. Chen,= National Chiao Tung University, Taiwan ; C.T. Chan, Chunghwa Telecom,= Taiwan An Efficient Weight Assignment Process for GPS Servers G. Urvoy, PRISM, France ; G. Hebuterne, Institut National des= T=E9l=E9communications, France Some Aspects of RTP - TCP Coexistence in Universal Multiservice Networks R. Chodorek, University of Mining and Metallurgy, Poland 09:00 - 10:45 Mobile Networks and Mobile Services Chair: G. Omidyar, Computer Sciences Corp, USA Voice Enabled Request and Response for Mobile Devices Supporting WAP= Protocol: the Constraints A. Mohan, Himachal Futuristic Communications, India ; A. Mohan, Indian= Institute of Technology, India IP based enhanced Data Casting Services over Radio Broadcast Networks W. Kellerer, P. Sties, J. Ebersp=E4cher, Munich University of Technology,= Germany Location-Dependant and Value Added Services (VAS) for Mobile Communications P. Lorenz, University of Haute Alsace, France ; H. Tobiet, NMG, France=20 The IP Revolution and Potential gains for ISP/Mobile/Fixed Telephony= Operators in the Liberalization of Telecommunications D. Vergados, D. Drakoulis, E. Vayias, J. Soldatos, N. Mitrou, National= Technical University of Athens, Greece 10:45 - 11:15 Coffee Break 11:15 - 13:00 Multicast Chair: G. Girardi, CSELT, Italy A Scalable Fault Tolerant Approach to Core Election in an Inter-Domain= Multicast Routing Environment M.D.Ech-Cherif El Kettani, ENSIAS, Morocco; Y. Souissi, EMI, Morocco A New Routing Algorithm for Delay-Constrained Dynamic Multicast T. Asaka, NTT Service Integration Laboratories, Japan ; T. Miyoshi, Y.= Tanaka, Waseda University, Japan Remote Time-Alignment of Interactive Services through Efficient Multicast= Algorithms A. Borella, G. Cancellieri, University of Ancona, Italy Key Establishment for IGMP Authentication in IP Multicast T. Hardjono, B. Cain, Nortel Networks, USA 11:15 - 13:00 IP Test-beds Chair: H. Tobiet, NMG, France Real-Time Multimedia Services over Internet A. Benslimane, Technical University of Belfort-Montb=E9liard, France Telephony over IP: Theoretical Modelling and Lab Experiments P. Senesi, P. Ferrabone, G. Gritella, R. Rinaldi, M. Siviero, CSELT, Italy User-domain Multiservice Architecture for Wired and Wireless IP Networks L. Cheng, I. Marsic, The State University of New Jersey, USA A Testbed Environment for the Performance Evaluation of Modular Network= Architectures D. Maggiorini, E. Pagani, G.P. Rossi, University of Milano, Italy 13:00 - 14:30 Lunch 14:30 - 16:15 Modeling Chair: G. H=E9buterne, INT, France Estimation of the Renewal Function by Empiral Data - A Bayesian Approach N.M. Markovitch, Russian Academy of Sciences, Russia ; U.R. Krieger, T-Nova= Deutsche Telekom, Germany Modeling Access Networks for Quality of Service F. Duran, T. Lizambri, S. Wakid, National Institute of Standards and= Technology, USA ; D.R. Vaman, Megaxess, USA Managing Wireless Internet Information of Electronic Advertising E. Rashid, Y. Yoshioka, Hirosaki University, Japan ; Y. Nemoto, T. Nakamura,= Tohoku University, Japan Performance Evaluation of a full Memory Multidestination Protocol for= Satellite Based Reliable Multicast with and without Local Recovery H. Jianhua, K.R. Subramanian, Y. ZongKai, H. Ping, Nanyang Technological= University, Singapore 14:30 - 16:15 Tariffs and Bandwidth Allocation Chair: P. Lorenz, University of Haute Alsace, France INEDAC Project: A Tool to Calculate Interconnection Tariff based on a= Bottom-up Method J.A. Portilla, K.D. Hackbarth, A.E. Garcia, University of Cantabria, Spain ;= R. W=F6hrl, F. Gonzalez, Institut f=FCr Kommunikationsdienste GmbH, Germany Auction Method and its Performance in a Dynamic Bandwidth Allocation Service E. Takahashi, Y. Tanaka, Waseda Universiy, Japan Multivariable Feedforward Plus Feedback Control for Adapting MPEG Video= Streams to Variable Channel Bandwidth H.F. Raynaud, M. Luong, University of Paris Nord, France Robust Topology for Enterprise Networks against Diverse Tariff Structures T. Miyoshi, K. Mouri, Y. Tanaka, Waseda University, Japan ; T. Asaka, NTT= Service Integration Laboratories, Japan 16:15 - 16:45 Coffee Break 16:45 - 18:30 End to end Traffic Control (2) Chair: G. H=E9buterne, INT, France An Architecture of QoS Services for a Core Internet Network over DTM C.J. Barenco, Polytechnic University of Madrid, Spain ; A.A. Salona, J.I.= Moreno, University Carlos III of Madrid, Spain Congestion Avoidance for Unicast and Multicast Traffic A. Dracinschi, S. Fdida, University Pierre et Marie Curie, France MPOA and QoS Support in LIS Internetworking Environments I. Erturk, Kocaeli University, UK ; E. Stipidis, University of Sussex, UK A Method for Increasing Throughput based on Packet Striping F. Jacquet, M. Misson, IUT of Clermont-Ferrand, France 16:45 - 18:30 Advanced Networking Chair: G.V. Morson, Cambridge Network, England A New Network Service Environment using Active Network K. Widoyo, T. Aoki, H. Yasuda, University of Tokyo, Japan Adaptive Applications over Active Networks: Case Study on Layered Multicast L. Yamamoto, G. Leduc, University of Li=E8ge, Belgium Integrated Performance Monitoring of Client/Server Software C. Steigner, J. Wilke, I. Wulff, University of Koblenz-Landau, Germany Who needs Addresses ? V. Guruprasad, IBM, USA 20:00 Gala Dinner - Restaurant Meistermann Wednesday October 4, 2000 09:00 - 10:00 Tutorial Session 2 Chair: P. Rolin, France Telecom R&D, France Active Networks and its Management M. Brunner, NEC Europe Ltd, Germany 10:00- 10:30 Coffee Break 10:30 - 11:45 New Architectures for New Services Chair: A. Gravey, ENST-Bretagne, France A Novel Architecture for Efficient Protocol Processing in High Speed= Communication Environments G. Konstantoulakis, V. Nellas, C. Georgopoulos, T. Orphanoudakis, N. Zervos,= Ellemedia Technologies, Greece ; M. Steck, Hyperstone electronics GmbH,= Germany; D. Verkest, Interuniversity Microelectronics Centre (IMEC),= Belgium; G. Doumenis, D.Reisis, University of Athens, Greece; N. Nikolaou,= J.A. Sanchez, Lucent Technologies, The Netherlands Using T=E9l=E9domotis Interface for a new Multiservice Network applied to= Monitoring the Elderly T. Val, E. Campo, IUT of Blagnac, France ; P. Kauffmann, M. Misson,= University of Clermont II, France ; P.Y. Danet, France T=E9l=E9com R&D,= France Video and Interactive Internet access in a DVB Network R. Jaeger, BetaResearch, Germany 11:45 - 13:00 Panel Discussion 2 - New Architectures for New Services 13:00 - 14:30 Lunch 14:30 Visit of Vialis From owner-idmr@cs.ucl.ac.uk Mon Jul 24 19:22:24 2000 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 TAA23621 for ; Mon, 24 Jul 2000 19:22:24 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 24 Jul 2000 22:27:52 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Jul 2000 22:27:48 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 24 Jul 2000 22:27:46 +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 7EAA24CE0D; Mon, 24 Jul 2000 17:27:44 -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 RAA21832; Mon, 24 Jul 2000 17:27:43 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA02003; Mon, 24 Jul 2000 14:27:42 -0700 (PDT) Message-Id: <200007242127.OAA02003@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: mladen.sablic@lucent.com Subject: Re: Multicast Traceroute and multicasting responses to response address Cc: idmr@cs.ucl.ac.uk Date: Mon, 24 Jul 2000 14:27:42 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >I am confused on how to implement response sourcing >when the response address is multicast. In the draft: - >http://www.ietf.org/internet-drafts/draft-ietf-idmr-traceroute-ipm-06.txt >s.6.5.3 & s.6.5.4. it says that I should find a source address that is >known to the mulitcast routing table but if I am the router I am not >likely to have any (S,G) enteries with me as a source. Thanks for pointing this out. What it *means* is an address known in the topology database used by multicast (e.g. an address that belongs to a prefix that's routed in MBGP). The intent is to maximize the possibility that the response is routable. >Do I pick a random multicast enabled interface, join the group on it >and send? You don't need to join the group. If you can't pick an interface that's routed (either because you don't have one or because you don't know what's routed), picking a random interface is reasonable. Bill From owner-idmr@cs.ucl.ac.uk Mon Jul 24 19:22:57 2000 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 TAA23901 for ; Mon, 24 Jul 2000 19:22:56 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 24 Jul 2000 22:36:17 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Jul 2000 22:36:13 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 24 Jul 2000 22:36:03 +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 3513D1E006; Mon, 24 Jul 2000 17:36:03 -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 RAA22223; Mon, 24 Jul 2000 17:36:02 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA02093; Mon, 24 Jul 2000 14:36:02 -0700 (PDT) Message-Id: <200007242136.OAA02093@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ycai@cisco.com Subject: Re: Reporting of 224.0.0.[2,255] groups Cc: idmr@cs.ucl.ac.uk Date: Mon, 24 Jul 2000 14:36:01 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >I think >it really helps if implementations of RIP, OSPF or PIM that _do_ >send reports for the respectve groups can be made known, so that we >know we are trying to solve a real interoperability problem. Most versions of UNIX do, so any routing daemon running on a UNIX machine will. >One way or the other, I am sure the majority of the routers deployed >don't send reports for the routing protocols, let alone for 224.0.0.2. >The snooping switches pretty much have to flood packets addressed to >these groups. Relying on people not sending reports if you want the traffic flooded leads to a great denial of service attack; do you want me to be able to join IGRP-ROUTERS.MCAST.NET on my host (an unprivileged operation) and suddenly cause IGRP peerings to go down? If you want to avoid this attack, then switches have to be configured to always flood. Therefore, specifying that groups in this range are reported does no harm. Bill From owner-idmr@cs.ucl.ac.uk Tue Jul 25 02:57:32 2000 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 CAA03561 for ; Tue, 25 Jul 2000 02:57:31 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 25 Jul 2000 06:48:22 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Jul 2000 06:48:18 +0100 Received: from suraksha.wipsys.soft.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 25 Jul 2000 06:48:15 +0100 Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id LAA09037; Tue, 25 Jul 2000 11:14:31 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma009031; Tue, 25 Jul 00 11:14:29 +0530 Received: from manib ([192.168.162.199]) by bhairavi.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA85; Tue, 25 Jul 2000 11:13:36 +0530 Message-ID: <000b01bff5fc$c5be25c0$c7a2a8c0@wipsys.soft.net> From: Mani Manoharan Balaraman To: Bill Fenner , vijayc Cc: idmr References: <200007220700.AAA13692@windsor.research.att.com> Subject: Re: Re: Use of srcmask in prune/grafts Date: Tue, 25 Jul 2000 11:24:18 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello I agre with what you say with respect to the Pruning in absence of IGMPv3. However if IGMPv3 is used and if i had to prune a particular source in a network this will not work if the forwarding cache entry is maintained as src net, group ) as mentioned in the dvmrp draft (v3-09) . Presently dvmrp(v3-09) says that forwarding cache is maintained as (src net, group) as per Section 2.5.2 (Adding interfaces with neighbors). Suppose i want to prune a particular source host-group where is this information maintained (forwarding cache has srcnet-group and routing table has srcnet. ) ? I think this is what vijay question is . In PIM there are separate states maintained for (Src host, G), (*. G) and (*, *, RP). But in dvmrpv3, (SrcNet,G) alone is maintained, thus the question asked by Vijay arises. Regards, Mani, IP team, WIPRO global R&D. ----- Original Message ----- From: Bill Fenner To: Cc: Sent: Saturday, July 22, 2000 12:30 PM Subject: Re: Re: Use of srcmask in prune/grafts > > >I think it is not necessary to associate the prune with a route. > > Before IGMPv3, the only reason a prune would occur in DVMRP was because > there were no group members at all. Therefore, it makes sense to prune > the largest unit possible (i.e. the route associated with the source being > pruned). The netmask was introduced in prunes (and grafts) in order to: > > a) ensure that the prune was being applied to the appropriate route > (especially if you have overlapping routes in your routing table) > b) allow /32 masks to specify source-specific prunes. > > Bill > From owner-idmr@cs.ucl.ac.uk Tue Jul 25 03:03:06 2000 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 DAA04970 for ; Tue, 25 Jul 2000 03:03:05 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 25 Jul 2000 05:23:42 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Jul 2000 05:23:37 +0100 Received: from 208.178.29.198 by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 25 Jul 2000 05:23:35 +0100 Received: from c1web02 (208.178.29.202) by c1mailgw2.prontomail.com (NPlex 4.5.049) id 3977B66A000479AD; Mon, 24 Jul 2000 21:23:24 -0700 X-Version: indya 6.2.3 .2329.0 From: vijayc@indya.com Message-Id: <959C4FB82D164D1178850005B8E28024@vijayc.indya.com> Date: Tue, 25 Jul 2000 10:01:22 +0530 X-Priority: Normal Content-Type: text/plain; charset=iso-8859-1 To: fenner@research.att.com Subject: dvmrp prunes CC: idmr@cs.ucl.ac.uk X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello Sir, I would like further clarification in the matter of source/mask in dvmrp prunes. If it is argued that the source addres corresponds to 'source network' and the mask is used to associate with a route then it means that the prune applies to a route rather than a source. Hence even if a host address (not net address) is given in the prune it will prune the route to the source-network. Hence all traffic from the source-network will be pruned. But, if it is desired to prune traffic only from a particular source or set of sources in the network then this strategy will not work. If the forwarding cache maintains host-group(S,G) flow and prune applies to this then it will give the flexibility of pruning a set of sources in the net. Will this method give better flexibility. Please clarify. Regards, Vijay Enter your default signature here Sent by Indya Messaging Service From owner-idmr@cs.ucl.ac.uk Tue Jul 25 15:22:46 2000 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 PAA08298 for ; Tue, 25 Jul 2000 15:22:45 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 25 Jul 2000 18:08:20 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Jul 2000 18:08:16 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 25 Jul 2000 18:08:14 +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 9C10C4CE08; Tue, 25 Jul 2000 13:08:11 -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 NAA09738; Tue, 25 Jul 2000 13:08:11 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA07382; Tue, 25 Jul 2000 10:08:10 -0700 (PDT) Message-Id: <200007251708.KAA07382@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: mani.balaram@wipro.com Subject: Re: Re: Use of srcmask in prune/grafts Cc: vijayc@indya.com, idmr@cs.ucl.ac.uk References: <200007220700.AAA13692@windsor.research.att.com> <000b01bff5fc$c5be25c0$c7a2a8c0@wipsys.soft.net> Date: Tue, 25 Jul 2000 10:08:10 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk The DVMRP spec doesn't specify a specific forwarding cache implementation. Bill From owner-idmr@cs.ucl.ac.uk Tue Jul 25 15:28:53 2000 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 PAA10485 for ; Tue, 25 Jul 2000 15:28:52 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 25 Jul 2000 18:02:57 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Jul 2000 18:02:53 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 25 Jul 2000 18:02:36 +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 384114CE08; Tue, 25 Jul 2000 13:02: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 NAA09381; Tue, 25 Jul 2000 13:02:31 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA07279; Tue, 25 Jul 2000 10:02:31 -0700 (PDT) Message-Id: <200007251702.KAA07279@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: vijayc@indya.com Subject: Re: dvmrp prunes Cc: idmr@cs.ucl.ac.uk Date: Tue, 25 Jul 2000 10:02:30 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >If it is argued that the source addres corresponds to 'source network' >and the mask is used to associate with a route then it means that the >prune applies to a route rather than a source. Yes. That's how DVMRP works. >But, if it is desired to prune traffic only from a particular >source or set of sources in the network then this strategy will not >work. In this case, you use a 0xffffffff netmask to indicate this. The valid values for the netmask field in the DVMRP Prune message are: - The netmask associated with the route to the source, or - 0xffffffff to indicate pruning only this single source. Bill From owner-idmr@cs.ucl.ac.uk Tue Jul 25 19:32:25 2000 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 TAA22378 for ; Tue, 25 Jul 2000 19:32:25 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 25 Jul 2000 22:33:07 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Jul 2000 22:33:03 +0100 Received: from ftpbox.mot.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 25 Jul 2000 22:33:02 +0100 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA09018 for ; Tue, 25 Jul 2000 14:33:00 -0700 (MST)] Received: [from s-il02-e.comm.mot.com (s-il02-e.comm.mot.com [145.1.204.15]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA29358 for ; Tue, 25 Jul 2000 14:33:00 -0700 (MST)] Received: by s-il02-e.comm.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jul 2000 16:32:59 -0500 Message-ID: <01FAF65DEA16D4119B95009027E78F3149D808@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'idmr'" Cc: "'Bill Fenner'" Subject: IGMP Proxy - Upstream interface Date: Tue, 25 Jul 2000 16:32:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi, Quoting from the IGMP Proxy draft (section 3), "A router performing IGMP-based forwarding has a single upstream interface and one or more downstream interfaces.". Is there any downside to having multiple upstream interfaces? If not, why wasn't this considered? If IGMP Proxy is enabled on multiple interfaces, why can't some kind of weighting (which could be configurable) be used to determine on which interface the IGMP messages are forwarded? Often, there are multiple routes to the same destination for redundancy purposes. Allowing this method of configuration would make the use of IGMP proxy feasible in these cases. By restricting the number of upstream interfaces to one, there is a complete loss of connectivity in case of link failures. For interfaces that need to remain simple but redundant, IGMP proxy could prove as a valuable solution if multiple upstream interfaces are allowed. Thanks, Vidya From owner-idmr@cs.ucl.ac.uk Tue Jul 25 19:32:31 2000 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 TAA22407 for ; Tue, 25 Jul 2000 19:32:30 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 25 Jul 2000 22:43:16 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Jul 2000 22:43:12 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 25 Jul 2000 22:43:02 +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 6E3621E011; Tue, 25 Jul 2000 17:43:01 -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 RAA24502; Tue, 25 Jul 2000 17:43:00 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA09869; Tue, 25 Jul 2000 14:42:59 -0700 (PDT) Message-Id: <200007252142.OAA09869@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: cvn065@lmpsil02.comm.mot.com Subject: Re: IGMP Proxy - Upstream interface Cc: idmr@cs.ucl.ac.uk Date: Tue, 25 Jul 2000 14:42:59 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk I considered the following rules to allow "backup" upstream interfaces: - Only be the Querier downstream if you hear a Querier upstream. - If you don't hear a Querier on your primary upstream interface, you may switch to using a "backup" upstream interface if you are not the Querier on that interface. The first rule causes failure information to propogate downwards. The second rule allows failover on failure. However, IGMP proxying is already really susceptible to loops. I was very wary of adding transient behaviors that might end up putting a router downstream of itself (especially since the propogation of failure information takes so long). IGMP proxying already requires careful configuration to prevent loops in the steady state, but it requires even more thought to prevent loops in failure conditions. Bill From owner-idmr@cs.ucl.ac.uk Tue Jul 25 19:34:45 2000 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 TAA22917 for ; Tue, 25 Jul 2000 19:34:44 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 25 Jul 2000 23:12:02 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Jul 2000 23:11:58 +0100 Received: from natint.juniper.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 25 Jul 2000 23:11:56 +0100 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id PAA28445 for ; Tue, 25 Jul 2000 15:11:49 -0700 (PDT) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id PAA90544 for ; Tue, 25 Jul 2000 15:11:41 -0700 (PDT) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200007252211.PAA90544@garnet.juniper.net> To: idmr@cs.ucl.ac.uk Subject: IGMP v3 source-list change records MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <90541.964563101.1@garnet.juniper.net> Date: Tue, 25 Jul 2000 15:11:41 -0700 From: Tom Pusateri Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk The current spec allows source-list change records to be either ALLOW_NEW_SOURCES or BLOCK_OLD_SOURCES. The meaning of these record types vary depending on what was sent previously. This makes it alot more difficult for the router to figure out what to do than it needs to be. In fact, I'm not sure the router can figure it out at all. If host h1 sends MODE_IS_INCLUDE sources a and b for group g and host h2 says MODE_IS_EXCLUDE sources a, then when ALLOW_NEW_SOURCES with include source a is received from h2, how does the router know if it should apply this to the include list or the exclude list? If the router tracks all membership from each host then it can figure it out but even then its not convenient because the router has to figure out what that host did for other sources in the group. Maybe I'm missing something but wouldn't it be much easier if there were two more variants giving us: ALLOW_NEW_INCLUDE_SOURCES ALLOW_NEW_EXCLUDE_SOURCES BLOCK_OLD_INCLUDE_SOURCES BLOCK_OLD_EXCLUDE_SOURCES The host sending this knows what mode it is in so it is quite easy for it to generate the appropriate variant. Thanks, Tom From owner-idmr@cs.ucl.ac.uk Tue Jul 25 22:39:33 2000 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 WAA10863 for ; Tue, 25 Jul 2000 22:39:32 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 02:07:04 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 02:07:00 +0100 Received: from omega.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 02:06:59 +0100 Received: (from ycai@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA28856; Tue, 25 Jul 2000 18:06:57 -0700 (PDT) Date: Tue, 25 Jul 2000 18:06:57 -0700 (PDT) Message-Id: <200007260106.SAA28856@omega.cisco.com> From: Yiqun Cai To: fenner@research.att.com CC: idmr@cs.ucl.ac.uk In-reply-to: <200007260049.RAA10690@windsor.research.att.com> (message from Bill Fenner on Tue, 25 Jul 2000 17:49:22 -0700) Subject: Re: Reporting of 224.0.0.[2,255] groups Reply-to: ycai@cisco.com Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk > > If the routing daemon has joined 224.0.0.2 (e.g. a multicast routing > daemon that wants to do IGMP), then yes. But what if the routing daemon does only OSPF, does it still join 224.0.0.2 because it is a router? It doesn't sound like that. > > >Where could it lead to a DOS attack? > > If a host on a transit LAN joins the IGRP group and suddenly IGRP is > no longer flooded but only goes to that port on the switch, that's > a DOS attack -- it broke routing. Got it. So the switches have to flood. > > >Hence, I would say the switches should always flood packets addressed > >to 224.0.0.[2-255]. Vendors may choose not to do so if they want to > >implement specific optimizations. > > That's fine; the IETF doesn't specify IGMP snooping though so there's > no place to say that, though. > Perhaps IETF should, especially since IGMPv3 is coming out and is going to make IGMP snooping even trickier. > >On the other hand, routers may want to report to 224.0.0.[2-255], but > >it is not required. > > Why not require it? It's much simpler to just require it than to > explain and make people understand the pros and cons of implementing > it, especially when the cons of implementing it are minimal (right?) > Here are the reasons, 1. the switches have to flood regardless of whether the routers send reports or not, not just for dealing with DOS attacks you mentioned but for interoperating with the majority of the installed base. 2. a lot of the existing implementations don't send the reports. 3. there is no harm either way (sending or not-sending reports). IMO, of course. -- Yiqun From owner-idmr@cs.ucl.ac.uk Tue Jul 25 22:39:38 2000 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 WAA10888 for ; Tue, 25 Jul 2000 22:39:38 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 01:40:08 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 01:40:02 +0100 Received: from omega.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 01:39:59 +0100 Received: (from ycai@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA25255; Tue, 25 Jul 2000 17:39:57 -0700 (PDT) Date: Tue, 25 Jul 2000 17:39:57 -0700 (PDT) Message-Id: <200007260039.RAA25255@omega.cisco.com> From: Yiqun Cai To: fenner@research.att.com CC: idmr@cs.ucl.ac.uk In-reply-to: <200007242136.OAA02093@windsor.research.att.com> (message from Bill Fenner on Mon, 24 Jul 2000 14:36:01 -0700) Subject: Re: Reporting of 224.0.0.[2,255] groups Reply-to: ycai@cisco.com Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >> I think >> it really helps if implementations of RIP, OSPF or PIM that _do_ >> send reports for the respectve groups can be made known, so that we >> know we are trying to solve a real interoperability problem. > Most versions of UNIX do, so any routing daemon running on a UNIX machine > will. Do they send reports to 224.0.0.2 too, just curious to know. > > Relying on people not sending reports if you want the traffic flooded > leads to a great denial of service attack; do you want me to be able to > join IGRP-ROUTERS.MCAST.NET on my host (an unprivileged operation) and > suddenly cause IGRP peerings to go down? I didn't quite get the point here. Routers shouldn't (or perhaps I shall say "must not") forward packets addressed to 224.0.0.[2-255]. Where could it lead to a DOS attack? > > If you want to avoid this attack, then switches have to be configured to > always flood. Therefore, specifying that groups in this range are > reported does no harm. > Agreed with you on the second part. Hence, I would say the switches should always flood packets addressed to 224.0.0.[2-255]. Vendors may choose not to do so if they want to implement specific optimizations. On the other hand, routers may want to report to 224.0.0.[2-255], but it is not required. I think we are converging, aren't we? -- Yiqun From owner-idmr@cs.ucl.ac.uk Tue Jul 25 22:40:56 2000 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 WAA11262 for ; Tue, 25 Jul 2000 22:40:55 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 01:49:31 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 01:49:26 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 01:49:25 +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 CBBDD4CE24; Tue, 25 Jul 2000 20:49:24 -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 UAA02460; Tue, 25 Jul 2000 20:49:24 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id RAA10690; Tue, 25 Jul 2000 17:49:23 -0700 (PDT) Message-Id: <200007260049.RAA10690@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ycai@cisco.com Subject: Re: Reporting of 224.0.0.[2,255] groups Cc: idmr@cs.ucl.ac.uk Date: Tue, 25 Jul 2000 17:49:22 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >> Most versions of UNIX do [report these groups using IGMP], so any >> routing daemon running on a UNIX machine will. > >Do they send reports to 224.0.0.2 too, just curious to know. If the routing daemon has joined 224.0.0.2 (e.g. a multicast routing daemon that wants to do IGMP), then yes. >Where could it lead to a DOS attack? If a host on a transit LAN joins the IGRP group and suddenly IGRP is no longer flooded but only goes to that port on the switch, that's a DOS attack -- it broke routing. >Hence, I would say the switches should always flood packets addressed >to 224.0.0.[2-255]. Vendors may choose not to do so if they want to >implement specific optimizations. That's fine; the IETF doesn't specify IGMP snooping though so there's no place to say that, though. >On the other hand, routers may want to report to 224.0.0.[2-255], but >it is not required. Why not require it? It's much simpler to just require it than to explain and make people understand the pros and cons of implementing it, especially when the cons of implementing it are minimal (right?) Bill From owner-idmr@cs.ucl.ac.uk Wed Jul 26 02:05:16 2000 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 CAA24224 for ; Wed, 26 Jul 2000 02:05:16 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 05:18:47 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 05:18:42 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 05:18:40 +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 991F54CE14; Wed, 26 Jul 2000 00:18:39 -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 AAA10478; Wed, 26 Jul 2000 00:18:38 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id VAA11934; Tue, 25 Jul 2000 21:18:38 -0700 (PDT) Message-Id: <200007260418.VAA11934@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: mani.balaram@wipro.com Subject: Re: Re: Use of srcmask in prune/grafts Cc: vijayc@indya.com, idmr@cs.ucl.ac.uk References: <200007220700.AAA13692@windsor.research.att.com> <000b01bff5fc$c5be25c0$c7a2a8c0@wipsys.soft.net> <200007251708.KAA07382@windsor.research.att.com> <006c01bff6b8$e1c0fd80$c7a2a8c0@wipsys.soft.net> Date: Tue, 25 Jul 2000 21:18:37 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk The section you quoted says that initial forwarding is based upon (source network, group) and that normal prunes are based upon (source network, group). It does not specify a (source network, group) forwarding cache. Bill From owner-idmr@cs.ucl.ac.uk Wed Jul 26 02:05:24 2000 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 CAA24415 for ; Wed, 26 Jul 2000 02:05:23 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 05:55:22 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 05:54:58 +0100 Received: from popcorn.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 05:54:57 +0100 Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id VAA13770; Tue, 25 Jul 2000 21:54:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <200007260321.UAA12605@garnet.juniper.net> References: <200007260321.UAA12605@garnet.juniper.net> Date: Tue, 25 Jul 2000 21:56:20 -0700 To: Tom Pusateri From: Steve Deering Subject: Re: IGMP v3 source-list change records Cc: Isidor Kouvelas , idmr@cs.ucl.ac.uk Content-Type: text/plain; charset="us-ascii" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk At 8:21 PM -0700 7/25/00, Tom Pusateri wrote: >The problem I have is with the wording in 4.2.12 under ALLOW_NEW_SOURCES >and BLOCK_NEW_SOURCES. It says "if the change was to an INCLUDE source >list ..." How does the router know if the change was to an INCLUDE >source list or an EXCLUDE source list? Tom, The quoted text tells a host what to put in the packet, based on the host's own mode (which that host, of course, knows). The routers' mode may be different than the host's (e.g., the routers may be in EXCLUDE mode while the host is in INCLUDE mode, because of the desires of other hosts on the same link), and the hosts cannot know what the routers' mode is. Therefore, the hosts send message that just say "turn off these sources" or "turn on these sources", without having to know the state of the routers (and without the routers having to know the state of the individual hosts). Steve From owner-idmr@cs.ucl.ac.uk Wed Jul 26 02:05:32 2000 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 CAA24577 for ; Wed, 26 Jul 2000 02:05:31 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 05:14:43 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 05:14:39 +0100 Received: from suraksha.wipsys.soft.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 05:14:37 +0100 Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id JAA26791; Wed, 26 Jul 2000 09:41:24 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma026775; Wed, 26 Jul 00 09:41:03 +0530 Received: from manib ([192.168.162.199]) by bhairavi.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA3C40; Wed, 26 Jul 2000 09:40:08 +0530 Message-ID: <006c01bff6b8$e1c0fd80$c7a2a8c0@wipsys.soft.net> From: Mani Manoharan Balaraman To: Bill Fenner Cc: vijayc , idmr References: <200007220700.AAA13692@windsor.research.att.com> <000b01bff5fc$c5be25c0$c7a2a8c0@wipsys.soft.net> <200007251708.KAA07382@windsor.research.att.com> Subject: Re: Re: Use of srcmask in prune/grafts Date: Wed, 26 Jul 2000 09:50:50 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello The following section from the dvmrp draft (v3-09) indiccates that the forwarding cache entry should be based on (src net, Group) 2.5.2. Adding Interfaces with Neighbors Initially, all interfaces with downstream dependent neighbors should be included in the downstream interface list when a forwarding cache entry is first created. This allows the downstream routers to be aware of traffic destined for a particular (source network, group) pair. The downstream routers will then have the option to send prunes and subsequent grafts for this (source network, group) pair as requirements change from their respective downstream routers and local group members. Mani From owner-idmr@cs.ucl.ac.uk Wed Jul 26 02:05:40 2000 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 CAA24782 for ; Wed, 26 Jul 2000 02:05:39 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 04:22:16 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 04:22:11 +0100 Received: from natint.juniper.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 04:22:10 +0100 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id UAA15652; Tue, 25 Jul 2000 20:22:08 -0700 (PDT) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id UAA12605; Tue, 25 Jul 2000 20:21:59 -0700 (PDT) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200007260321.UAA12605@garnet.juniper.net> To: Isidor Kouvelas cc: Tom Pusateri , idmr@cs.ucl.ac.uk, pusateri@juniper.net Subject: Re: IGMP v3 source-list change records In-Reply-To: Message from Isidor Kouvelas of "Tue, 25 Jul 2000 20:07:36 PDT." <200007260307.UAA17573@kouvelas-u10.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12598.964581719.1@garnet.juniper.net> Date: Tue, 25 Jul 2000 20:21:59 -0700 From: Tom Pusateri Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk In message <200007260307.UAA17573@kouvelas-u10.cisco.com> you write: > >Tom Pusateri writes: >>The current spec allows source-list change records to be either >>ALLOW_NEW_SOURCES or BLOCK_OLD_SOURCES. The meaning of these >>record types vary depending on what was sent previously. >> >>This makes it alot more difficult for the router to figure out what >>to do than it needs to be. In fact, I'm not sure the router can >>figure it out at all. If host h1 sends MODE_IS_INCLUDE sources a >>and b for group g and host h2 says MODE_IS_EXCLUDE sources a, then >>when ALLOW_NEW_SOURCES with include source a is received from h2, >>how does the router know if it should apply this to the include >>list or the exclude list? > >The router keeps a single list of sources while in EXCLUDE mode. The >distinction is that some of the sources have timers running and are >forwarded while others have stopped timers and are blocked. Sources >not included at all in the list are forwarded. >When the ALLOW record is received, the timer for the reported source >will be updated and it will be forwarded. The router does not need to >know the state the host is in. The problem I have is with the wording in 4.2.12 under ALLOW_NEW_SOURCES and BLOCK_NEW_SOURCES. It says "if the change was to an INCLUDE source list ..." How does the router know if the change was to an INCLUDE source list or an EXCLUDE source list? The host that is sending this may have previously sent a MODE_IS_INCLUDE or it may have previously sent a MODE_IS_EXCLUDE and there is no way to tell at this point unless you track each host. Thanks, Tom From owner-idmr@cs.ucl.ac.uk Wed Jul 26 02:05:46 2000 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 CAA24823 for ; Wed, 26 Jul 2000 02:05:45 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 04:52:45 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 04:52:41 +0100 Received: from natint.juniper.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 04:52:40 +0100 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id UAA17357; Tue, 25 Jul 2000 20:52:39 -0700 (PDT) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id UAA79479; Tue, 25 Jul 2000 20:52:30 -0700 (PDT) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200007260352.UAA79479@garnet.juniper.net> To: Isidor Kouvelas cc: Tom Pusateri , idmr@cs.ucl.ac.uk, pusateri@juniper.net Subject: Re: IGMP v3 source-list change records In-Reply-To: Message from Isidor Kouvelas of "Tue, 25 Jul 2000 20:44:49 PDT." <200007260344.UAA17579@kouvelas-u10.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79476.964583550.1@garnet.juniper.net> Date: Tue, 25 Jul 2000 20:52:30 -0700 From: Tom Pusateri Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk In message <200007260344.UAA17579@kouvelas-u10.cisco.com> you write: >In message <200007260321.UAA12605@garnet.juniper.net>, >Tom Pusateri writes: >>In message <200007260307.UAA17573@kouvelas-u10.cisco.com> you write: >>> >>>Tom Pusateri writes: >>>>The current spec allows source-list change records to be either >>>>ALLOW_NEW_SOURCES or BLOCK_OLD_SOURCES. The meaning of these >>>>record types vary depending on what was sent previously. >>>> >>>>This makes it alot more difficult for the router to figure out what >>>>to do than it needs to be. In fact, I'm not sure the router can >>>>figure it out at all. If host h1 sends MODE_IS_INCLUDE sources a >>>>and b for group g and host h2 says MODE_IS_EXCLUDE sources a, then >>>>when ALLOW_NEW_SOURCES with include source a is received from h2, >>>how does the router know if it should apply this to the include >>>>list or the exclude list? >>> >>>The router keeps a single list of sources while in EXCLUDE mode. The >>>distinction is that some of the sources have timers running and are >>>forwarded while others have stopped timers and are blocked. Sources >>>not included at all in the list are forwarded. >>>When the ALLOW record is received, the timer for the reported source >>>will be updated and it will be forwarded. The router does not need to >>>know the state the host is in. >> >>The problem I have is with the wording in 4.2.12 under ALLOW_NEW_SOURCES >>and BLOCK_NEW_SOURCES. It says "if the change was to an INCLUDE source >>list ..." How does the router know if the change was to an INCLUDE >>source list or an EXCLUDE source list? The host that is sending this >>may have previously sent a MODE_IS_INCLUDE or it may have previously >>sent a MODE_IS_EXCLUDE and there is no way to tell at this point >>unless you track each host. > >The paragraph is refering to the source list in the host. The router >does not need to know what state the host is in when it processes >the report. > >thanks >Isidor We're still not seeing eye to eye. Maybe we can talk about it in Pittsburgh. Tom From owner-idmr@cs.ucl.ac.uk Wed Jul 26 02:05:53 2000 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 CAA24876 for ; Wed, 26 Jul 2000 02:05:53 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 05:38:15 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 05:38:08 +0100 Received: from suraksha.wipsys.soft.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 05:38:04 +0100 Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id KAA28111; Wed, 26 Jul 2000 10:04:34 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma028101; Wed, 26 Jul 00 10:04:13 +0530 Received: from manib ([192.168.162.199]) by bhairavi.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA5092; Wed, 26 Jul 2000 10:03:18 +0530 Message-ID: <000e01bff6bc$1e9614e0$c7a2a8c0@wipsys.soft.net> From: Mani Manoharan Balaraman To: Bill Fenner Cc: idmr References: <200007220700.AAA13692@windsor.research.att.com> <000b01bff5fc$c5be25c0$c7a2a8c0@wipsys.soft.net> <200007251708.KAA07382@windsor.research.att.com> <006c01bff6b8$e1c0fd80$c7a2a8c0@wipsys.soft.net> <200007260418.VAA11934@windsor.research.att.com> Subject: Re: Re: Use of srcmask in prune/grafts Date: Wed, 26 Jul 2000 10:14:01 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello This section also says the forwarding cache entry is created with sourcenetwork-group pair. Is it that initially the forwarding cache will be created with (src net-group) but later modified to (src host-group) ? Thanks Mani ----- Original Message ----- From: Bill Fenner To: Cc: ; Sent: Wednesday, July 26, 2000 9:48 AM Subject: Re: Re: Use of srcmask in prune/grafts > > The section you quoted says that initial forwarding is based upon (source > network, group) and that normal prunes are based upon (source network, > group). It does not specify a (source network, group) forwarding cache. > > Bill From owner-idmr@cs.ucl.ac.uk Wed Jul 26 02:06:10 2000 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 CAA24982 for ; Wed, 26 Jul 2000 02:06:09 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 04:44:57 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 04:44:52 +0100 Received: from sj-msg-core-1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 04:44:51 +0100 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id UAA01841; Tue, 25 Jul 2000 20:45:03 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id UAA17579; Tue, 25 Jul 2000 20:44:49 -0700 (PDT) Message-Id: <200007260344.UAA17579@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Tom Pusateri cc: Isidor Kouvelas , idmr@cs.ucl.ac.uk Subject: Re: IGMP v3 source-list change records In-reply-to: Your message of "Tue, 25 Jul 2000 20:21:59 PDT." <200007260321.UAA12605@garnet.juniper.net> Date: Tue, 25 Jul 2000 20:44:49 -0700 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk In message <200007260321.UAA12605@garnet.juniper.net>, Tom Pusateri writes: >In message <200007260307.UAA17573@kouvelas-u10.cisco.com> you write: >> >>Tom Pusateri writes: >>>The current spec allows source-list change records to be either >>>ALLOW_NEW_SOURCES or BLOCK_OLD_SOURCES. The meaning of these >>>record types vary depending on what was sent previously. >>> >>>This makes it alot more difficult for the router to figure out what >>>to do than it needs to be. In fact, I'm not sure the router can >>>figure it out at all. If host h1 sends MODE_IS_INCLUDE sources a >>>and b for group g and host h2 says MODE_IS_EXCLUDE sources a, then >>>when ALLOW_NEW_SOURCES with include source a is received from h2, >>how does the router know if it should apply this to the include >>>list or the exclude list? >> >>The router keeps a single list of sources while in EXCLUDE mode. The >>distinction is that some of the sources have timers running and are >>forwarded while others have stopped timers and are blocked. Sources >>not included at all in the list are forwarded. >>When the ALLOW record is received, the timer for the reported source >>will be updated and it will be forwarded. The router does not need to >>know the state the host is in. > >The problem I have is with the wording in 4.2.12 under ALLOW_NEW_SOURCES >and BLOCK_NEW_SOURCES. It says "if the change was to an INCLUDE source >list ..." How does the router know if the change was to an INCLUDE >source list or an EXCLUDE source list? The host that is sending this >may have previously sent a MODE_IS_INCLUDE or it may have previously >sent a MODE_IS_EXCLUDE and there is no way to tell at this point >unless you track each host. The paragraph is refering to the source list in the host. The router does not need to know what state the host is in when it processes the report. thanks Isidor From owner-idmr@cs.ucl.ac.uk Wed Jul 26 02:06:18 2000 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 CAA25033 for ; Wed, 26 Jul 2000 02:06:17 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 04:07:43 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 04:07:38 +0100 Received: from sj-msg-core-2.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 04:07:37 +0100 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id UAA12490; Tue, 25 Jul 2000 20:07:52 -0700 (PDT) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id UAA17573; Tue, 25 Jul 2000 20:07:36 -0700 (PDT) Message-Id: <200007260307.UAA17573@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Tom Pusateri cc: idmr@cs.ucl.ac.uk Subject: Re: IGMP v3 source-list change records In-reply-to: Your message of "Tue, 25 Jul 2000 15:11:41 PDT." <200007252211.PAA90544@garnet.juniper.net> Date: Tue, 25 Jul 2000 20:07:36 -0700 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Tom Pusateri writes: >The current spec allows source-list change records to be either >ALLOW_NEW_SOURCES or BLOCK_OLD_SOURCES. The meaning of these >record types vary depending on what was sent previously. > >This makes it alot more difficult for the router to figure out what >to do than it needs to be. In fact, I'm not sure the router can >figure it out at all. If host h1 sends MODE_IS_INCLUDE sources a >and b for group g and host h2 says MODE_IS_EXCLUDE sources a, then >when ALLOW_NEW_SOURCES with include source a is received from h2, >how does the router know if it should apply this to the include >list or the exclude list? The router keeps a single list of sources while in EXCLUDE mode. The distinction is that some of the sources have timers running and are forwarded while others have stopped timers and are blocked. Sources not included at all in the list are forwarded. When the ALLOW record is received, the timer for the reported source will be updated and it will be forwarded. The router does not need to know the state the host is in. In your example above, the source "a" reported in the ALLOW record from h2 would either already exist in the list with a running timer or would not be in the list. This is because host h1 is reporting it in MODE_IS_INCLUDE reports. When the ALLOW record is received by the router, the timer will be updated for source "a" and it will continue to be forwarded. >If the router tracks all membership from each host then it can >figure it out but even then its not convenient because the router >has to figure out what that host did for other sources in the group. The ALLOW and BLOCK records are diff records and should have no effect on any other sources a host has reported in a previous full state record. >Maybe I'm missing something but wouldn't it be much easier if there >were two more variants giving us: > >ALLOW_NEW_INCLUDE_SOURCES >ALLOW_NEW_EXCLUDE_SOURCES >BLOCK_OLD_INCLUDE_SOURCES >BLOCK_OLD_EXCLUDE_SOURCES > >The host sending this knows what mode it is in so it is quite easy >for it to generate the appropriate variant. I am not sure I understand the problem but don't think there is any obvious advantage in doing this. thanks Isidor From owner-idmr@cs.ucl.ac.uk Wed Jul 26 10:01:31 2000 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 KAA15900 for ; Wed, 26 Jul 2000 10:01:30 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 26 Jul 2000 12:46:41 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jul 2000 12:46:38 +0100 Received: from 193.133.64.178 by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 26 Jul 2000 12:46:34 +0100 Received: by exchange01.iirltd.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 12:44:18 +0100 Message-ID: From: Richard Cooper To: Richard Cooper Subject: MPLS Date: Wed, 26 Jul 2000 12:44:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hello, You may remember that I sent you an email a few weeks ago regarding the MPLS conference I was working on. Well, I have now finished and printed the prorgamme and I would like to thank all of you who helped with my research or have agreed to speak. The conference will run the 25th-28th of September in London for full details please see the website www.iir-conferences.com/mpls Many Thanks Sarah Jones Senior Conference Producer, Transmission Events IIR Telecoms & Technology 0044 20 7915 5146 0044 20 7915 5001 From owner-idmr@cs.ucl.ac.uk Wed Jul 26 21:56:56 2000 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 VAA18718 for ; Wed, 26 Jul 2000 21:56:55 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 27 Jul 2000 00:39:03 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 2000 00:38:59 +0100 Received: from natint.juniper.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 2000 00:38:57 +0100 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id QAA21114 for ; Wed, 26 Jul 2000 16:38:56 -0700 (PDT) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id QAA76879 for ; Wed, 26 Jul 2000 16:38:54 -0700 (PDT) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200007262338.QAA76879@garnet.juniper.net> To: idmr@cs.ucl.ac.uk Subject: New version of the DVMRP AS MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <76876.964654734.1@garnet.juniper.net> Date: Wed, 26 Jul 2000 16:38:54 -0700 From: Tom Pusateri Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Here is an updated version of the DVMRP Applicability Statement based on comments from Bill Fenner and Tom Maufer. I'll submit it during the Pittsburgh Meeting so send any comments before the middle of next week. Thanks, Tom T. Pusateri INTERNET DRAFT Juniper Networks draft-ietf-idmr-dvmrp-v3-as-01 July 2000 Expires: January 26, 2001 Distance Vector Multicast Routing Protocol Applicability Statement Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides a framework for the use of Distance Vector Multicast Routing Protocol (DVMRP) Version 3 within a multicast routing domain. It is an interior gateway protocol designed to be used within an autonomous system. Pusateri [Page 1] INTERNET-DRAFT DVMRP Applicability Statement July 2000 1. Intended use DVMRP [Pusa99] can be characterized as a broadcast and prune multicast routing protocol. This means that IP multicast datagrams are forwarded to all possible receivers and then unwanted data traffic is pruned back to the minimum tree necessary to reach all of the current receivers. This provides a data driven mechanism for all last hop routers to learn about all active multicast sources. If the last hop routers have local group members for the multicast group associated with the source, they simply do nothing and the multicast data will continue to arrive. If the last hop routers do not have corresponding group members for the active source, then they send control messages back up the multicast delivery tree toward the source to prune their branch from the tree. The prunes sent upstream toward the source time out and are periodically refreshed to reduce the amount of state that is stored. The periodic broadcast and prune nature of the protocol makes it well suited for use within a multicast domain or autonomous system where bandwidth is plentiful. It is NOT intended for use as an EGP across multicast domains or for interconnecting multicast domains. DVMRP's advantages compared with other multicast routing protocols include: a. Pure source specific multicast distribution trees provide a simple model to deploy and troubleshoot. b. Join latency is minimized since new sources are automatically sent to all receivers. c. DVMRP builds a broadcast tree per source network with the routing updates, so it doesn't have to flood links that are not part of the broadcast tree for a source. d. DVMRP uses its own topology discovery mechanism allowing both faster adaptation to change and a more stable steady state. e. Discovery mechanisms relying on expanding ring searches are fully supported. Of course, these benefits do not come without a cost. The broadcast nature of DVMRP makes it unsuitable for connecting leaf domains via Pusateri [Page 2] INTERNET-DRAFT DVMRP Applicability Statement July 2000 low speed links. Additionally, the cost of keeping prune state for unwanted data can be high depending on the mix of receivers. Additionally, DVMRP operates on the premise that all data will be broadcast throughout the domain and unwanted data will be pruned back toward the source. If a DVMRP domain is connected downstream from an explicit join multicast domain, then without additional mechanism, no data would ever be broadcast into the DVMRP domain from the explicit join domain. For this purpose, Domain Wide Reports [Fenn00] were invented to inform border routers between explicit join domains and broadcast and prune domains about the active group membership within the broadcast and prune domain. 2. Scalability/Applicability A routing protocol need only scale within the limits of its intended use. In this case, DVMRP need only scale within the context of multicast routing domain or autonomous system. There are several factors that limit the scalability of DVMRP. Fortunately, these factors are well understood and by making these explicit within this applicability statement, it should be possible to avoid negative side-effects. Convergence time Since DVMRP uses a distance vector (also called Bellman-Ford after its authors) routing algorithm to distribute source information, its scope is limited by the convergence time required to propagate updated source information across the routing domain. In order to limit the convergence time, DVMRP has imposed a limit on the number of hops across a domain by setting the infinity metric to 32 hops. Count to Infinity All distance vector protocols are susceptible to the well known "count to infinity" problem [Perl92]. However, by requiring the use of split horizon with poison reverse, the chances of encountering this are significantly lowered. 3. State Analysis As stated earlier, DVMRP broadcasts new multicast data to all receivers and then prunes back the unwanted data based on group membership information. To further reduce the amount of broadcasted data, DVMRP builds the broadcast tree by determining the single reverse path from a receiver back to the source and pruning duplicate Pusateri [Page 3] INTERNET-DRAFT DVMRP Applicability Statement July 2000 paths. This truncated broadcast tree is precalculated using poison reverse route updates as each router participates in a designated forwarder election per source network to determine the upstream router. This mechanism prevents duplicate datagrams from arriving on multi- access networks at the expense of more state in the router. DVMRP requires designated forwarder election state to be kept per prefix per interface and prune state to be kept per neighbor per prefix. 4. Control Traffic Analysis Independent of the amount of multicast data being forwarded, DVMRP will always send some control traffic. First, there is a DVMRP probe message sent every 10 seconds per interface for neighbor discovery and keep-alive functions. Additionally, there are periodic route exchanges that advertise source networks and assist in building the multicast delivery trees. These route reports are resent every 60 seconds but are spread out across the report interval to reduce the processing load. The number of route report packets sent is dependent on the number of prefixes being reported. The amount of prune and graft messages sent is a function of the number of active senders and receivers for the data being forwarded. Grafts are only sent to undo the effects of previous prunes. Prunes are sent in response to unwanted multicast data. The lifetime of a prune which is specific to a group and source network is approximately 2 hours. This long lifetime greatly limits the amount of prune control traffic that is sent. Pusateri [Page 4] INTERNET-DRAFT DVMRP Applicability Statement July 2000 5. References [Fenn00] Fenner, W., "Domain Wide Multicast Group Membership Reports", Work in Progress, July 2000. [Perl92] Perlman, R., "Interconnections: Bridges and Routers", Addison-Wesley, 1992, pp. 210-211. [Pusa99] Pusateri, T., "Distance-Vector Multicast Routing Protocol Version 3", Work In Progress, September 1999. 6. Author's Address Thomas Pusateri Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA Phone: (408) 734-7690 EMail: pusateri@juniper.net 7. Acknowledgments The author would like to acknowledge Dave Thaler, Bill Fenner, and Thomas Maufer for their review and comments. Pusateri [Page 5] INTERNET-DRAFT DVMRP Applicability Statement July 2000 8. Full Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Pusateri [Page 6] Table of Contents 1. Intended Use . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Scalability/Applicability . . . . . . . . . . . . . . . . . . 3 3. State Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Control Traffic Analysis . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6 Pusateri [Page i] From owner-idmr@cs.ucl.ac.uk Wed Jul 26 21:57:29 2000 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 VAA18840 for ; Wed, 26 Jul 2000 21:57:29 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 27 Jul 2000 01:46:15 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 2000 01:46:11 +0100 Received: from natint.juniper.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 2000 01:46:10 +0100 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id RAA25760; Wed, 26 Jul 2000 17:46:09 -0700 (PDT) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id RAA82373; Wed, 26 Jul 2000 17:46:07 -0700 (PDT) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200007270046.RAA82373@garnet.juniper.net> To: Steve Deering cc: Tom Pusateri , Isidor Kouvelas , idmr@cs.ucl.ac.uk, pusateri@juniper.net Subject: Re: IGMP v3 source-list change records In-Reply-To: Message from Steve Deering of "Tue, 25 Jul 2000 21:56:20 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82370.964658767.1@garnet.juniper.net> Date: Wed, 26 Jul 2000 17:46:07 -0700 From: Tom Pusateri Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk In message you write: >At 8:21 PM -0700 7/25/00, Tom Pusateri wrote: >>The problem I have is with the wording in 4.2.12 under ALLOW_NEW_SOURCES >>and BLOCK_NEW_SOURCES. It says "if the change was to an INCLUDE source >>list ..." How does the router know if the change was to an INCLUDE >>source list or an EXCLUDE source list? > >Tom, > >The quoted text tells a host what to put in the packet, based on the >host's own mode (which that host, of course, knows). The routers' >mode may be different than the host's (e.g., the routers may be >in EXCLUDE mode while the host is in INCLUDE mode, because of the >desires of other hosts on the same link), and the hosts cannot know >what the routers' mode is. Therefore, the hosts send message that just >say "turn off these sources" or "turn on these sources", without having >to know the state of the routers (and without the routers having to >know the state of the individual hosts). > >Steve Ok, after re-reading it a bunch, I get it now. I'm trying to loosely follow the spec while doing an implementation of keeping explicit state per host on the router and got confused by the wording here. Thanks Isidor & Steve, Tom From owner-idmr@cs.ucl.ac.uk Thu Jul 27 13:20:20 2000 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 NAA07603 for ; Thu, 27 Jul 2000 13:20:20 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 27 Jul 2000 16:11:03 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 2000 16:10:59 +0100 Received: from natint.juniper.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 2000 16:10:58 +0100 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA07187; Thu, 27 Jul 2000 08:10:55 -0700 (PDT) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id IAA27257; Thu, 27 Jul 2000 08:10:52 -0700 (PDT) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200007271510.IAA27257@garnet.juniper.net> To: "Shekhar, Ravi" cc: Tom Pusateri , idmr@cs.ucl.ac.uk, pusateri@juniper.net Subject: Re: New version of the DVMRP AS In-Reply-To: Message from "Shekhar, Ravi" of "Thu, 27 Jul 2000 10:56:26 EDT." <49FF5C6DDBD8D311BBBD009027DE980CBFB07E@uniwest1.redstonecom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27254.964710652.1@garnet.juniper.net> Date: Thu, 27 Jul 2000 08:10:52 -0700 From: Tom Pusateri Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk In message <49FF5C6DDBD8D311BBBD009027DE980CBFB07E@uniwest1.redstonecom.com> yo u write: >Hi Tom, > > >> 3. State Analysis >....... >> >> This mechanism prevents duplicate datagrams from arriving on multi- >> access networks at the expense of more state in the router. DVMRP >> requires designated forwarder election state to be kept per prefix >> per interface and prune state to be kept per neighbor per prefix. > > Should this be "..prune state to be kept per neighbor per (prefix, >group) pair"? > > And with /32 mask prunes this could turn out to be per (source, group) >pair, > but that detail can be found in the DVMRP draft. > > - Ravi Shekhar. Hi Ravi, I'll fix this. Thanks, Tom From owner-idmr@cs.ucl.ac.uk Thu Jul 27 13:20:28 2000 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 NAA07614 for ; Thu, 27 Jul 2000 13:20:27 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 27 Jul 2000 15:56:42 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 2000 15:56:38 +0100 Received: from 199.105.223.130 by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 2000 15:56:29 +0100 Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jul 2000 10:56:27 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980CBFB07E@uniwest1.redstonecom.com> From: "Shekhar, Ravi" To: Tom Pusateri , idmr@cs.ucl.ac.uk Subject: RE: New version of the DVMRP AS Date: Thu, 27 Jul 2000 10:56:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi Tom, > 3. State Analysis ....... > > This mechanism prevents duplicate datagrams from arriving on multi- > access networks at the expense of more state in the router. DVMRP > requires designated forwarder election state to be kept per prefix > per interface and prune state to be kept per neighbor per prefix. Should this be "..prune state to be kept per neighbor per (prefix, group) pair"? And with /32 mask prunes this could turn out to be per (source, group) pair, but that detail can be found in the DVMRP draft. - Ravi Shekhar. From owner-idmr@cs.ucl.ac.uk Sat Jul 29 15:43:46 2000 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 PAA09278 for ; Sat, 29 Jul 2000 15:43:46 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sat, 29 Jul 2000 18:35:32 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 29 Jul 2000 18:35:26 +0100 Received: from max1-3.newyork.corecomm.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 29 Jul 2000 18:35:26 +0100 From: callback123 Subject: From Lorraine,as promised,I can lower your bill Date: Sat, 29 Jul 2000 14:31:47 Message-Id: <891.62688.661449@altavistausa.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Apparently-To: idmr-pp Untitled Document


Today, everyone knows the impact of the Internet.
But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31    Saudi Arabia $.59     Denmark $.04      Sweden $.05

Click Here Now.

If you do not have flash please go to
www.macromedia.com
to download it.

From owner-idmr@cs.ucl.ac.uk Sat Jul 29 18:46:27 2000 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 SAA29810 for ; Sat, 29 Jul 2000 18:46:26 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sat, 29 Jul 2000 22:03:10 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 29 Jul 2000 22:03:06 +0100 Received: from 212.155.146.8 by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 29 Jul 2000 22:03:04 +0100 Received: from smtp.indiatimes.com ([38.27.133.89]) by kweb.k-info.fr (Netscape Mail Server v1.1) with SMTP id AAC24870; Sat, 27 Nov 1999 18:23:15 +0200 Reply-To: bfreesatellite16@indiatimes.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT To: satsystem65@yahoo.com Date: Fri, 03 Mar 2000 21:45:17 -0500 From: bnomorecable16@indiatimes.com Message-Id: Subject: Get a $1000 FREE Satellite TV System!! Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7BIT FREE SATELLITE T.V. SYSTEM Watch over 500 channels of Digital Broadcast quality television on your own FREE satellite television system. These new Digital satellite systems use the new 18 inch satellite dish antenna. For a limited time we'll give you this top of the line Digital Satellite System for FREE! We'll even include Free installation and 3 FREE months of all the movie channels! This is the New Dishplayer 500. It has a built Digital 12 hour recording system so you can throw that old VCR away, built in WEB T.V. and interactive T.V and game systems, on screen graphics, 2 dual LNB's, stereo receiver and infrared remote. Normal cost for all these items is over $900 but we're giving it away for FREE! All you have to do is call us to arrange delivery and order the channels you want to receive. The monthly cost of satellite television is usually much less than cable T.V and satellite television offers over 500 channels of all digital broadcast video quality and CD audio sound. You even get local channels now. Don't miss this offer it's only available while supplies last. For your Free Satellite System call 888-514-6881 24 hours a day.