From owner-pim@catarina.usc.edu Tue May 9 05:36:01 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13239 for ; Tue, 9 May 2000 05:36:00 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA66010 for pim-list; Tue, 9 May 2000 02:22:01 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA66005 for ; Tue, 9 May 2000 02:22:00 -0700 (PDT) Received: from rompres.kappa.ro (danutf@linux.rompres.ro [194.102.253.162]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id CAA09522 for ; Tue, 9 May 2000 02:21:55 -0700 (PDT) Received: from localhost (danutf@localhost) by rompres.kappa.ro (8.9.1/8.9.1) with ESMTP id MAA02376 for ; Tue, 9 May 2000 12:39:07 +0300 Date: Tue, 9 May 2000 12:39:07 +0300 (EEST) From: Daniel Firac To: pim@catarina.usc.edu Subject: pimd.conf In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk How should look like the pimd.conf file for a simple multicast router which has to connect 2 LAN's?? That means the router has to forward the multicast trafic from one LAN to the other. I have slackware 7.0 with kernel 2.2.13 and pimd-2.1.0-alpha28. The 'pimd -d' command works, but a simple multicast ping doesn't work. Please help me, Dan Firac From owner-pim@catarina.usc.edu Tue May 9 13:39:50 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26116 for ; Tue, 9 May 2000 13:39:49 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA67757 for pim-list; Tue, 9 May 2000 10:33:01 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA67752 for ; Tue, 9 May 2000 10:33:00 -0700 (PDT) Received: from mc-qout4.whowhere.com (mc-qout4.whowhere.com [209.185.123.18]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id KAA10222 for ; Tue, 9 May 2000 10:32:59 -0700 (PDT) Received: from Unknown/Local ([?.?.?.?]) by my-deja.com; Tue May 9 10:30:13 2000 To: pim@catarina.usc.edu, "Daniel Firac" Date: Tue, 09 May 2000 10:30:13 -0700 From: "Jonathan Day" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: jd9812@my-deja.com X-Mailer: MailCity Service Subject: Re: pimd.conf X-Sender-Ip: 208.53.116.245 Organization: My Deja Email (http://www.my-deja.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm by no means an expert on pimd, but here are a few things to check. They're all ludicrously simple - so much so, that they're easy to forget to do. First, check that the kernel has been configured with multicasting, multicast routing, pim-2 support and packet forwarding enabled. Second, check that /proc/sys/net/ipv4/ip_forward is set to 1. Third, check /etc/pimd.conf to see that both interfaces are defined. (IIRC, it won't even start, if it can't find two interfaces.) Fourth, check that the interfaces are multicast-enabled. Last, but by no means least, if you've got security set up, check that you're not blocking all multicast traffic, by mistake. On Tue, 9 May 2000 12:39:07 Daniel Firac wrote: >How should look like the pimd.conf file for a simple multicast router >which has to connect 2 LAN's?? >That means the router has to forward the multicast trafic from one LAN to >the other. > >I have slackware 7.0 with kernel 2.2.13 and pimd-2.1.0-alpha28. >The 'pimd -d' command works, but a simple multicast ping doesn't work. --== Sent via Deja.com http://www.deja.com/ ==-- Before you buy. From owner-pim@catarina.usc.edu Tue May 9 22:19:07 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04983 for ; Tue, 9 May 2000 22:19:06 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA70178 for pim-list; Tue, 9 May 2000 19:14:00 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id TAA70173 for ; Tue, 9 May 2000 19:14:00 -0700 (PDT) Received: from cindy.yamato.ibm.co.jp (cindy.yamato.ibm.co.jp [203.141.89.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA15601 for ; Tue, 9 May 2000 19:13:59 -0700 (PDT) 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 LAA45284 for ; Wed, 10 May 2000 11:12:06 +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 LAA41134 for ; Wed, 10 May 2000 11:12:18 +0900 To: pim@catarina.usc.edu Subject: Re: pimd.conf In-Reply-To: Your message of "Tue, 09 May 2000 10:30:13 -0700" References: 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: <20000510111218D.asaeda@yamato.ibm.com> Date: Wed, 10 May 2000 11:12:18 +0900 (JST) From: Hitoshi Asaeda X-Dispatcher: imput version 980905(IM100) Lines: 17 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Actually, I couldn't understand original question, though, > Third, check /etc/pimd.conf to see that both interfaces are defined. (IIRC, it won't even start, if it can't find two interfaces.) when you start pimd, pimd does try to look for all multicast available interfaces on the box, except not a loopback interface, not a multicast disabled interface. Only when there is an entry, "phyint if_name disable", in pimd.conf, pimd doesn't use that specified if_name as its iif/oif. The way of this, in pimd.conf, it would be said you don't need to specify the interfaces which you want to use. And, yes, more than two interfaces are prerequisite to make pimd work, as you know. -- Hitoshi Asaeda From owner-pim@catarina.usc.edu Tue May 9 23:49:11 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06921 for ; Tue, 9 May 2000 23:49:10 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id UAA70800 for pim-list; Tue, 9 May 2000 20:44:48 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id UAA70795; Tue, 9 May 2000 20:44:41 -0700 (PDT) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id UAA51750; Tue, 9 May 2000 20:44:58 -0700 (PDT) Message-Id: <200005100344.UAA51750@rumi.usc.edu> To: Daniel Firac cc: pim@catarina.usc.edu Subject: Re: pimd.conf In-reply-to: Your message of "Tue, 09 May 2000 12:39:07 +0300." Date: Tue, 09 May 2000 20:44:58 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-pim@catarina.usc.edu Precedence: bulk (In addition to the information by Jonathan and Asaeda-san) > How should look like the pimd.conf file for a simple multicast router > which has to connect 2 LAN's?? The default pimd.conf that comes with the distribution should do the job. > That means the router has to forward the multicast trafic from one LAN to > the other. > > I have slackware 7.0 with kernel 2.2.13 and pimd-2.1.0-alpha28. > The 'pimd -d' command works, but a simple multicast ping doesn't work. As a simple check, start mrouted instead. If multicast ping doesn't work, then there is something with that machine configuration. For example, I just found that on recent FreeBSD, I need "sysctl -w net.inet.icmp.bmcastecho=1" to enable mcast ping responses (disabled by default), so you may need something similar on Linux. A better tool to test if a mcast router is running is "mrinfo" and it should work for pimd as well. Regards, Pavlin > > Please help me, > Dan Firac From owner-pim@catarina.usc.edu Wed May 10 07:07:29 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22119 for ; Wed, 10 May 2000 07:07:29 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id DAA72447 for pim-list; Wed, 10 May 2000 03:58:44 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id DAA72440; Wed, 10 May 2000 03:58:42 -0700 (PDT) Received: from rompres.kappa.ro (danutf@linux.rompres.ro [194.102.253.162]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA15703; Wed, 10 May 2000 03:58:38 -0700 (PDT) Received: from localhost (danutf@localhost) by rompres.kappa.ro (8.9.1/8.9.1) with ESMTP id OAA05944; Wed, 10 May 2000 14:19:31 +0300 Date: Wed, 10 May 2000 14:19:31 +0300 (EEST) From: Daniel Firac To: Pavlin Ivanov Radoslavov cc: pim@catarina.usc.edu Subject: pimd.conf In-Reply-To: <200005100344.UAA51750@rumi.usc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk I had a firewall which blocked all multicast forwardings. Now it's working fine. Both mping and my multicast application. Thank you for the support, Dan Firac. From owner-pim@catarina.usc.edu Fri May 12 06:17:37 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00089 for ; Fri, 12 May 2000 06:17:36 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id DAA85008 for pim-list; Fri, 12 May 2000 03:05:22 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id DAA85003 for ; Fri, 12 May 2000 03:05:20 -0700 (PDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA26529 for ; Fri, 12 May 2000 03:05:18 -0700 (PDT) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA04729 for ; Fri, 12 May 2000 11:59:03 +0200 (MET DST) Received: from mchh201e.demchh201e.icn.siemens.de ([218.1.68.104]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA01659 for ; Fri, 12 May 2000 11:56:56 +0200 (MET DST) Received: by MCHH201E with Internet Mail Service (5.5.2448.0) id ; Fri, 12 May 2000 12:01:43 +0200 Message-ID: From: Hummel Heinrich To: pim@catarina.usc.edu Subject: PIM-SO: Set RP = S's DR Date: Fri, 12 May 2000 12:01:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk Hello, Relates to PIM-SO (single source only): If the rendez-vous point RP is set to the DR of source S, then I think, we should get the right results: the shared tree is actually the shortest path tree; no tree-switching, no Register; no Register-Stop,... Am I right or wrong ? Heinrich Hummel Siemens AG heinrich.hummel@icn.siemens.de From owner-pim@catarina.usc.edu Thu May 18 17:35:35 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13422 for ; Thu, 18 May 2000 17:35:33 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA16993 for pim-list; Thu, 18 May 2000 14:25:16 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA16988 for ; Thu, 18 May 2000 14:25:14 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA17502 for ; Thu, 18 May 2000 14:25:11 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA27840 for ; Thu, 18 May 2000 14:24:09 -0700 (MST)] Received: [from il02exi01.comm.mot.com (il02exi01.comm.mot.com [145.1.204.40]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA18639 for ; Thu, 18 May 2000 14:24:09 -0700 (MST)] Received: by il02exi01.comm.mot.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 16:24:09 -0500 Message-ID: <0F762B016151D2118F8900805FA795AF0216CE45@s-il02-n.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'idmr'" , "'pim'" Subject: IGMP Proxy and PIM-SM Date: Thu, 18 May 2000 16:24:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, I have a question on the interaction of IGMP Proxy and PIM-SM. IGMP proxy is meant to extend the tentacles of the host one hop away from the multicast routing domain. It seems like it is really meant only for receivers, when we take PIM-SM behavior into account. PIM-SM source DRs apparently do not encapsulate packets that do not originate from the local subnet to the RP. This means, if I have a router A running IGMP proxy connected to a router B that is running PIM-SM and is connected to a bunch of other routers running PIM-SM also, I can only hang multicast receivers off router A. Consider the following scenario: Host A ----- Router A (IGMP Proxy) ----- Router B (PIM-SM; non-RP) ----- Router C (PIM-SM; RP) ----- Downstreams running PIM-SM Assume Router A is connected to Router B through a LAN. Also, assume the host A is on a different LAN. Assume WAN connectivity between Routers B and C. Now, if Host A was a receiver, everything works fine. If host A were to send multicast UDP packets, then, the source address of the packets that hit Router B will belong to a subnet different from its local subnet. It seems from various implementations that Router B will not encapsulate these packets to the RP and instead drop it, since the source address check fails for PIM-SM. Are there any negatives for why Router B must not just encapsulate these packets to the RP? In a very restricted network, where I don't worry about security, what could be the disadvantages of doing this? I am not sure if this was just not considered in the IGMP proxy model or was just left open. Any comments would be of great help. Thanks, Vidya From owner-pim@catarina.usc.edu Thu May 18 18:42:39 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13908 for ; Thu, 18 May 2000 18:42:37 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA17483 for pim-list; Thu, 18 May 2000 15:34:42 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA17478 for ; Thu, 18 May 2000 15:34:41 -0700 (PDT) Received: from mail.routerware.com (mail.routerware.com [204.31.186.3]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA10436 for ; Thu, 18 May 2000 15:34:38 -0700 (PDT) Received: by NEWMAN with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 15:36:24 -0700 Message-ID: <4F48C7B31A8BD311B1D20090279C34B2309BB2@clavin> From: Chris Hall To: "'pim@catarina.usc.edu'" Subject: protocol analyzer for multicasting Date: Thu, 18 May 2000 15:40:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi All- Can anyone point me at a protocol analyzer that can handle PIM-SMv2? Thanks a lot for any help! Chris Hall From owner-pim@catarina.usc.edu Thu May 18 19:03:47 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14171 for ; Thu, 18 May 2000 19:03:46 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA17663 for pim-list; Thu, 18 May 2000 15:57:35 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA17658 for ; Thu, 18 May 2000 15:57:33 -0700 (PDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA28251 for ; Thu, 18 May 2000 15:57:32 -0700 (PDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id PAA21219; Thu, 18 May 2000 15:54:21 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 15:54:21 -0700 Message-ID: From: Muruhari Amarnath To: "'Chris Hall'" , "'pim@catarina.usc.edu'" Subject: RE: protocol analyzer for multicasting Date: Thu, 18 May 2000 15:54:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi Chris, The Shomiti Surveyor 3.0 SW supports the following IP Multicast decodes. DVMRP IGMP MOSPF PIM-DM PIM-SM RSVP Thanks, Amar Pluris, Inc -----Original Message----- From: Chris Hall [mailto:Chris.Hall@windriver.com] Sent: Thursday, May 18, 2000 3:41 PM To: 'pim@catarina.usc.edu' Subject: protocol analyzer for multicasting Hi All- Can anyone point me at a protocol analyzer that can handle PIM-SMv2? Thanks a lot for any help! Chris Hall From owner-pim@catarina.usc.edu Thu May 18 19:22:53 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14370 for ; Thu, 18 May 2000 19:22:51 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA17904 for pim-list; Thu, 18 May 2000 16:17:34 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA17899 for ; Thu, 18 May 2000 16:17:34 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA11336 for ; Thu, 18 May 2000 16:17:32 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id A6E901E005; Thu, 18 May 2000 19:15: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 TAA01511; Thu, 18 May 2000 19:15:31 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA25088; Thu, 18 May 2000 16:14:06 -0700 (PDT) Message-Id: <200005182314.QAA25088@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: chris.hall@windriver.com Subject: Re: protocol analyzer for multicasting Cc: pim@catarina.usc.edu Date: Thu, 18 May 2000 16:14:05 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk tcpdump 3.5 has a pretty complete PIMv2 decoder. See http://www.tcpdump.org/ Bill From owner-pim@catarina.usc.edu Thu May 18 19:28:57 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14418 for ; Thu, 18 May 2000 19:28:55 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA17973 for pim-list; Thu, 18 May 2000 16:22:59 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA17968 for ; Thu, 18 May 2000 16:22:58 -0700 (PDT) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA14852 for ; Thu, 18 May 2000 16:22:57 -0700 (PDT) Received: from localhost (jzwiebel@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA04847; Thu, 18 May 2000 16:19:01 -0700 (PDT) Message-Id: <200005182319.QAA04847@sigma.cisco.com> To: Narayanan Vidya-CVN065 cc: "'idmr'" , "'pim'" Subject: Re: IGMP Proxy and PIM-SM In-reply-to: Your message of "Thu, 18 May 2000 16:24:07 CDT." <0F762B016151D2118F8900805FA795AF0216CE45@s-il02-n.comm.mot.com> Date: Thu, 18 May 2000 16:19:01 -0700 From: "John M. Zwiebel" Sender: owner-pim@catarina.usc.edu Precedence: bulk On the "are there any negatives" question only: Imagine a PIM domain running only dense-mode but with hundreds of sources. Also, there have been problems with some failure topologies resulting in duplicate register packets arriving at the RP from different first-hop routers. It is better to specifically have to configure an interface to register for sources that are not directly connected. FWIW, IOS can do this. ^ Hi, ^ I have a question on the interaction of IGMP Proxy and PIM-SM. IGMP proxy is ^ meant to extend the tentacles of the host one hop away from the multicast ^ routing domain. It seems like it is really meant only for receivers, when we ^ take PIM-SM behavior into account. PIM-SM source DRs apparently do not ^ encapsulate packets that do not originate from the local subnet to the RP. ^ This means, if I have a router A running IGMP proxy connected to a router B ^ that is running PIM-SM and is connected to a bunch of other routers running ^ PIM-SM also, I can only hang multicast receivers off router A. Consider the ^ following scenario: ^ ^ Host A ----- Router A (IGMP Proxy) ----- Router B (PIM-SM; non-RP) ----- ^ Router C (PIM-SM; RP) ----- Downstreams running PIM-SM ^ ^ Assume Router A is connected to Router B through a LAN. Also, assume the ^ host A is on a different LAN. Assume WAN connectivity between Routers B and ^ C. Now, if Host A was a receiver, everything works fine. If host A were to ^ send multicast UDP packets, then, the source address of the packets that hit ^ Router B will belong to a subnet different from its local subnet. It seems ^ from various implementations that Router B will not encapsulate these ^ packets to the RP and instead drop it, since the source address check fails ^ for PIM-SM. ^ ^ Are there any negatives for why Router B must not just encapsulate these ^ packets to the RP? In a very restricted network, where I don't worry about ^ security, what could be the disadvantages of doing this? I am not sure if ^ this was just not considered in the IGMP proxy model or was just left open. ^ ^ Any comments would be of great help. ^ ^ Thanks, ^ Vidya ^ ------------------------------------------------------------------------------ John Zwiebel Phone: 408-526-5303 Cisco Systems Inc. IP Multicast Group From owner-pim@catarina.usc.edu Wed May 24 13:39:14 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09804 for ; Wed, 24 May 2000 13:39:12 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA50119 for pim-list; Wed, 24 May 2000 10:27:08 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA50114 for ; Wed, 24 May 2000 10:27:07 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id KAA03759 for ; Wed, 24 May 2000 10:27:07 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 May 2000 10:17:51 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Wed, 24 May 2000 10:25:17 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC5A4.1E771AB6" Subject: draft-ietf-idmr-pim-mib-10.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4368.4 Date: Wed, 24 May 2000 10:18:46 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690D7ABCC5@SIT.platinum.corp.microsoft.com> Thread-Topic: draft-ietf-idmr-pim-mib-10.txt Thread-Index: Ab/FpOJIDyCGhf4pS8ajwYlIja3nLA== From: "Mohit Talwar" To: "pim (E-mail)" X-OriginalArrivalTime: 24 May 2000 17:25:17.0720 (UTC) FILETIME=[0795D980:01BFC5A5] Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFC5A4.1E771AB6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi all, pimNeighborTable is indexed by pimNeighborAddress. but can we not have a case where a router has the=20 same neighbor ip address on two different interfaces? in which case it can be uniquely indexed only by the tuple (pimInterfaceIfIndex, pimNeighborAddress). this situation could arise, for example, when the=20 router peers with another over a LAN 'and' through an unnumbered point to point tunnel. if the neighbor's router id is its LAN interface address, it would advertise the same ip address on both interfaces. or is this too far fetched? thanx, mohit. ------_=_NextPart_001_01BFC5A4.1E771AB6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-idmr-pim-mib-10.txt

hi all,

pimNeighborTable is indexed by = pimNeighborAddress.

but can we not have a case where a router has the =
same neighbor ip address on two different = interfaces?
in which case it can be uniquely indexed only = by
the tuple (pimInterfaceIfIndex, = pimNeighborAddress).

this situation could arise, for example, when the =
router peers with another over a LAN 'and' = through
an unnumbered point to point tunnel.  if the = neighbor's
router id is its LAN interface address, it would = advertise
the same ip address on both interfaces.

or is this too far fetched?

thanx,
mohit.

------_=_NextPart_001_01BFC5A4.1E771AB6-- From owner-pim@catarina.usc.edu Thu May 25 05:42:58 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02473 for ; Thu, 25 May 2000 05:42:57 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA53414 for pim-list; Thu, 25 May 2000 02:35:25 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA53409 for ; Thu, 25 May 2000 02:35:24 -0700 (PDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id CAA29935 for ; Thu, 25 May 2000 02:35:23 -0700 (PDT) Received: from ascend.com ([62.172.151.84]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id FAA03251 for ; Thu, 25 May 2000 05:31:34 -0400 (EDT) Message-ID: <392CF2D0.C5386148@ascend.com> Date: Thu, 25 May 2000 10:30:56 +0100 From: Jitu Patel Organization: Ascend Communications X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: pim@catarina.usc.edu Subject: How's this supposed to work ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have the following PIM Sparse mode configuration: Source (S) | | Pim Router (A) - DR | LAN---------------------------------------------------------------------LAN | | Pim Router(B) RP (for group G) | | Receiver (R) When the receiver R starts, B sends a (*,G) join to the RP. When the RP gets the join, it creates a (*,G) with the LAN as the oif. The source starts sending and router A sends a register to the RP which then forwards the data via the (*,G) route. Now the RP initiates switch over to an SPT and creates an (S,G) entry and copies the oifs from the (*,G)) entry and removes the IIF from the oif list ending up with a null oif list on the (S,G) since the IIF is the same as the oif. The RP sends a prune towards S and A prunes off the LAN from its (S,G) entry. So data never actually gets forwarded to the receiver. What am I am missing in this scenario ? I can't find anything in the spec that covers this particular case. Jitu From owner-pim@catarina.usc.edu Thu May 25 11:01:11 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10589 for ; Thu, 25 May 2000 11:01:10 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA54240 for pim-list; Thu, 25 May 2000 07:51:22 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA54235 for ; Thu, 25 May 2000 07:51:21 -0700 (PDT) Received: from uniwest1.redstonecom.com ([199.105.223.130]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA12082 for ; Thu, 25 May 2000 07:51:20 -0700 (PDT) Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 May 2000 10:52:21 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C7C3B76@uniwest1.redstonecom.com> From: "Shekhar, Ravi" To: Jitu Patel , pim@catarina.usc.edu Subject: RE: How's this supposed to work ? Date: Thu, 25 May 2000 10:52:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFC658.D4A100EA" Sender: owner-pim@catarina.usc.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFC658.D4A100EA Content-Type: text/plain; charset="iso-8859-1" Hi Jitu, This problem has already been discussed on the mailing list couple of times earlier. Please take a look at the attachment. - Ravi Shekhar. > -----Original Message----- > From: Jitu Patel [mailto:Jitu.Patel@ascend.com] > Sent: Thursday, May 25, 2000 5:31 AM > To: pim@catarina.usc.edu > Subject: How's this supposed to work ? > > > Hi, > > I have the following PIM Sparse mode configuration: > > > Source (S) > | > | > Pim Router (A) - DR > | > > LAN----------------------------------------------------------- > ----------LAN > > > | | > Pim Router(B) RP (for > group G) > | > | > Receiver (R) > > When the receiver R starts, B sends a (*,G) join to the RP. > When the RP gets the join, it creates a (*,G) with the LAN as the oif. > > The source starts sending and router A sends a register to > the RP which > then forwards the data via the (*,G) route. > > Now the RP initiates switch over to an SPT and creates an (S,G) entry > and copies the oifs from the (*,G)) entry and removes the IIF from the > oif list ending up with a null oif list on the (S,G) since the IIF is > the same as the oif. The RP sends a prune towards S and A > prunes off the > LAN from its (S,G) entry. So data never actually gets forwarded to the > receiver. > > What am I am missing in this scenario ? I can't find anything in the > spec that covers this particular case. > > Jitu > ------_=_NextPart_000_01BFC658.D4A100EA Content-Type: message/rfc822 Content-Description: RE: Sparse mode From: "Shekhar, Ravi" To: Desikan Saravanan , 'pim_ml' Subject: RE: Sparse mode Date: Fri, 4 Feb 2000 20:00:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BFC658.D4A100EA" ------_=_NextPart_002_01BFC658.D4A100EA Content-Type: text/plain; charset="iso-8859-1" Hi Des, Assuming [after reading the complete mail], that you meant new member to be only connected to C and similarly the sender to be connected only to B (tabs make them look as if they are attached to two routers)... New member at C will cause C to send <*, G> join to RP. This will result in RP adding oif to both its <*, G> and . In this case it so happens that the oif for is same as its iif. But RP should still generate SG-SPT joins for it. This scenario of having iif same as oif (and no other oif) is not covered in the spec and has been raised earlier (see attachment). Hope that helps. - Ravi Shekhar. > Hi > > I have a question about the SM behavior. > > Conside the following topology. > > Sender > | > Receiver --- A -------- B -------- C -------- RP > | | > ------------------------------------ > > At first A sends (*,g) join to RP and RP sends decapsulated > packets to A. > RP first decides to join SPT and sends join upstream. > So C has only an (s,g) entry. > > After sometime, A decides to join SPT and does. > Since A joins SPT, A then sends (s,g) rpt prune to RP. > so, RP prunes the interface towards A from its (s,g) entry. > so, its (s,g) has no outgoing interfaces and it now sends (s,g) prune > upstream. > > C has now an (s, g) entry with one interface in pruned list > and no interface > in outgoing interface list. > As no data packets come from B to C because of (s, g) prune, > C's (s,g) entry timer will not refreshed by anything and > eventually goes > off. > > I was wondering is it a correct behaviour for C? > If so, how come a new member joins from another interface to > C gets the data > packets? > ie. > Sender new member > | | > Receiver --- A -------- B -------- C -------- RP > | | > ------------------------------------ > > I would appreciate your help in understanding the protocol behaviour. > > Thanks > Des > ------_=_NextPart_002_01BFC658.D4A100EA Content-Type: message/rfc822 Content-Description: RE: PIM Working Group last call for draft-ietf-pim-v2-sm-01.txt From: "Shekhar, Ravi" To: lwei@siara.com, pim@catarina.usc.edu Subject: RE: PIM Working Group last call for draft-ietf-pim-v2-sm-01.txt Date: Wed, 1 Dec 1999 12:36:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Liming, I am still curious to know how the following scenario is covered by the draft. Regards. - Ravi Shekhar. > > I was considering the following scenario: > > > > <*,G>-> > > r---R1----R2------|I > > |----RP > > s---R3---R4-------| > > <- ??? > > > > > > r is the recvr, s is the sender. > > RP decides to switch to shortest path. > > Will R4 be able to detect and switch to SPT without > > RP sending a join to it? > > No. The RP has to decide if it needs to switch to the SPT. In that case, RP here has an entry with iif as I and oif list as "null" (only oif I is also iif so its not included in the list). It will _not_ generate join as per section 3.2.1 Sending Join/Prune Messages Periodic Join/Prune Messages: point 2.3 "3 The oif list in the (S,G) entry is not null." which requires it to be "not null". Is it covered somewhere else/in some other form in the draft? Thanks. - Ravi Shekhar. > > Folks, > > This is a PIM Working Group last call for the PIM sparse mode draft, > submitted as . This last call expires > by Jan 1 2000. Please post comments on this mailing list. > > Thanks, > -Liming Wei & Tom Pusateri > ------_=_NextPart_002_01BFC658.D4A100EA-- ------_=_NextPart_000_01BFC658.D4A100EA-- From owner-pim@catarina.usc.edu Thu May 25 14:07:34 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16547 for ; Thu, 25 May 2000 14:07:34 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA54976 for pim-list; Thu, 25 May 2000 10:51:52 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA54971 for ; Thu, 25 May 2000 10:51:51 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA02421 for ; Thu, 25 May 2000 10:51:51 -0700 (PDT) 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 KAA03023; Thu, 25 May 2000 10:47:37 -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 KAA10396; Thu, 25 May 2000 10:47:27 -0700 (PDT) Message-Id: <200005251747.KAA10396@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: Jitu Patel cc: pim@catarina.usc.edu Subject: Re: How's this supposed to work ? Date: Thu, 25 May 2000 10:47:27 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk This is also covered in: http://www.aciri.org/fenner/mcast/pim/sm/27.html thanks Isidor Jitu Patel writes: >Hi, > >I have the following PIM Sparse mode configuration: > > > Source (S) > | > | > Pim Router (A) - DR > | > LAN---------------------------------------------------------------------LAN > > >| | > Pim Router(B) RP (for >group G) > | > | > Receiver (R) > >When the receiver R starts, B sends a (*,G) join to the RP. >When the RP gets the join, it creates a (*,G) with the LAN as the oif. > >The source starts sending and router A sends a register to the RP which >then forwards the data via the (*,G) route. > >Now the RP initiates switch over to an SPT and creates an (S,G) entry >and copies the oifs from the (*,G)) entry and removes the IIF from the >oif list ending up with a null oif list on the (S,G) since the IIF is >the same as the oif. The RP sends a prune towards S and A prunes off the >LAN from its (S,G) entry. So data never actually gets forwarded to the >receiver. > >What am I am missing in this scenario ? I can't find anything in the >spec that covers this particular case. > > Jitu > > From owner-pim@catarina.usc.edu Thu May 25 14:16:29 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16864 for ; Thu, 25 May 2000 14:16:28 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA55064 for pim-list; Thu, 25 May 2000 11:06:12 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA55059 for ; Thu, 25 May 2000 11:06:10 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA12033 for ; Thu, 25 May 2000 11:06:10 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA25349; Thu, 25 May 2000 11:04:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA01710; Thu, 25 May 2000 11:04:38 -0700 X-Virus-Scanned: Thu, 25 May 2000 11:04:38 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (vienna.iprg.nokia.com [205.226.11.35]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma000517; Thu, 25 May 00 11:04:01 -0700 Received: from vienna.iprg.nokia.com (localhost [127.0.0.1]) by vienna.iprg.nokia.com (8.8.8/8.6.12) with ESMTP id LAA03514; Thu, 25 May 2000 11:04:01 -0700 (PDT) Message-Id: <200005251804.LAA03514@vienna.iprg.nokia.com> To: pim@catarina.usc.edu Cc: fred@iprg.nokia.com Subject: PIM hello option DR priority MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3511.959277841.1@vienna.iprg.nokia.com> Date: Thu, 25 May 2000 11:04:01 -0700 From: Fred Bauer Sender: owner-pim@catarina.usc.edu Precedence: bulk At Interop in Las Vegas this year I noticed that Junipers running JunOS release 4.0 were sending PIM hello option 19 with a length of 4 (Invalid Bidirectional PIM capable option). Presumably what the coder was trying to do was specify DR priority, but was following the older spec, draft-ietf-idmr-pimv2-dr-priority-00.txt. Has anyone else seen similar behavior on this or other manufacturers' routers? By the way, if anyone from Juniper is listening, I imagine that you'd like to fix this. Fred From owner-pim@catarina.usc.edu Thu May 25 15:37:04 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18854 for ; Thu, 25 May 2000 15:37:04 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA56093 for pim-list; Thu, 25 May 2000 12:29:04 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA56088 for ; Thu, 25 May 2000 12:29:03 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA21387 for ; Thu, 25 May 2000 12:29:02 -0700 (PDT) Received: from garnet.juniper.net (garnet.juniper.net [208.197.169.237]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA28893; Thu, 25 May 2000 12:27:17 -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 MAA02617; Thu, 25 May 2000 12:27:17 -0700 (PDT) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200005251927.MAA02617@garnet.juniper.net> To: Fred Bauer cc: pim@catarina.usc.edu, pusateri@juniper.net Subject: Re: PIM hello option DR priority In-Reply-To: Message from Fred Bauer of "Thu, 25 May 2000 11:04:01 PDT." <200005251804.LAA03514@vienna.iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2613.959282837.1@garnet.juniper.net> Date: Thu, 25 May 2000 12:27:17 -0700 From: Tom Pusateri Sender: owner-pim@catarina.usc.edu Precedence: bulk In message <200005251804.LAA03514@vienna.iprg.nokia.com> you write: >At Interop in Las Vegas this year I noticed that Junipers running >JunOS release 4.0 were sending PIM hello option 19 with a length >of 4 (Invalid Bidirectional PIM capable option). Presumably what >the coder was trying to do was specify DR priority, but was following >the older spec, draft-ietf-idmr-pimv2-dr-priority-00.txt. Has anyone >else seen similar behavior on this or other manufacturers' routers? > >By the way, if anyone from Juniper is listening, I imagine that >you'd like to fix this. > >Fred Actually, that code has been in there since the DR priority draft came out and is the same in all JUNOS releases shipping for the past few years. So was the DR priority draft wrong because the option was already used or did the option get re-assigned? Thanks, Tom From owner-pim@catarina.usc.edu Thu May 25 16:11:46 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19732 for ; Thu, 25 May 2000 16:11:44 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA56370 for pim-list; Thu, 25 May 2000 13:03:02 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA56365 for ; Thu, 25 May 2000 13:03:01 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA15417 for ; Thu, 25 May 2000 13:03:01 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA08285; Thu, 25 May 2000 13:01:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id NAA29142; Thu, 25 May 2000 13:01:30 -0700 X-Virus-Scanned: Thu, 25 May 2000 13:01:30 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (vienna.iprg.nokia.com [205.226.11.35]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma028346; Thu, 25 May 00 13:01:09 -0700 Received: from vienna.iprg.nokia.com (localhost [127.0.0.1]) by vienna.iprg.nokia.com (8.8.8/8.6.12) with ESMTP id NAA03738; Thu, 25 May 2000 13:01:09 -0700 (PDT) Message-Id: <200005252001.NAA03738@vienna.iprg.nokia.com> To: Tom Pusateri cc: Fred Bauer , pim@catarina.usc.edu Subject: Re: PIM hello option DR priority In-reply-to: Message from Tom Pusateri of "Thu, 25 May 2000 12:27:17 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3735.959284869.1@vienna.iprg.nokia.com> Date: Thu, 25 May 2000 13:01:09 -0700 From: Fred Bauer Sender: owner-pim@catarina.usc.edu Precedence: bulk Tom, OK, that's what I thought. The new SM draft, draft-ietf-pim-v2-sm-01.txt, rearranged the indicies. 18 is DR priority and 19 is Bidirectional PIM capable. Cheers, Fred >In message <200005251804.LAA03514@vienna.iprg.nokia.com> you write: >>At Interop in Las Vegas this year I noticed that Junipers running >>JunOS release 4.0 were sending PIM hello option 19 with a length >>of 4 (Invalid Bidirectional PIM capable option). Presumably what >>the coder was trying to do was specify DR priority, but was following >>the older spec, draft-ietf-idmr-pimv2-dr-priority-00.txt. Has anyone >>else seen similar behavior on this or other manufacturers' routers? >> >>By the way, if anyone from Juniper is listening, I imagine that >>you'd like to fix this. >> >>Fred > >Actually, that code has been in there since the DR priority draft came >out and is the same in all JUNOS releases shipping for the past few >years. > >So was the DR priority draft wrong because the option was already >used or did the option get re-assigned? > >Thanks, >Tom From owner-pim@catarina.usc.edu Thu May 25 17:12:34 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20795 for ; Thu, 25 May 2000 17:12:33 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA56920 for pim-list; Thu, 25 May 2000 14:01:58 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA56915 for ; Thu, 25 May 2000 14:01:57 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA19431 for ; Thu, 25 May 2000 14:01:56 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id A868C1E01E; Thu, 25 May 2000 16:22:05 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA03489; Thu, 25 May 2000 16:22:05 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA09672; Thu, 25 May 2000 13:20:33 -0700 (PDT) Message-Id: <200005252020.NAA09672@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pusateri@juniper.net Subject: Re: PIM hello option DR priority Cc: fred@iprg.nokia.com, pim@catarina.usc.edu Date: Thu, 25 May 2000 13:20:33 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk The PIM Hello option ID space got renumbered. It's very unclear who chose to do this and why, and what consideration was given to compatibility issues. rfc 2117 6/1997 n/a draft-ietf-idmr-pimv2-dr-priority-00.txt: 3/1998 DR-prio: 19 rfc 2362 6/1998 n/a draft-farinacci-bidir-pim-01.txt:* 5/1999 bidir: 19 draft-ietf-pim-v2-dm-03.txt: 6/1999 n/a draft-ietf-pim-v2-sm-00.txt: 10/1999 DR-prio: 18 draft-ietf-pim-v2-sm-01.txt: 11/1999 DR-prio: 18 I don't know what fix to propose; it'd be nice if we could standardize on 19 since otherwise early adopters get screwed, but obviously then there are compatibility issues with more recent implementations. Sigh. Bill * - ironically, draft-farinacci-bidir-pim-01.txt contains a reference to draft-ietf-idmr-pimv2-dr-priority-00.txt From owner-pim@catarina.usc.edu Thu May 25 19:25:05 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22539 for ; Thu, 25 May 2000 19:25:03 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA57646 for pim-list; Thu, 25 May 2000 16:18:35 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA57641 for ; Thu, 25 May 2000 16:18:26 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA19554 for ; Thu, 25 May 2000 16:18:18 -0700 (PDT) Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 827F22AA03; Thu, 25 May 2000 16:14:30 -0700 (PDT) Received: (from lwei@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id QAA06612; Thu, 25 May 2000 16:13:43 -0700 (PDT) Date: Thu, 25 May 2000 16:13:43 -0700 (PDT) Message-Id: <200005252313.QAA06612@malt.redback.com> From: Liming Wei To: pusateri@juniper.net Cc: fred@iprg.nokia.com, pim@catarina.usc.edu, pusateri@juniper.net In-reply-to: <200005251927.MAA02617@garnet.juniper.net> (message from Tom Pusateri on Thu, 25 May 2000 12:27:17 -0700) Subject: Re: PIM hello option DR priority Reply-To: lwei@redback.com Sender: owner-pim@catarina.usc.edu Precedence: bulk Sigh, this was due to the code assignment conflict with other options. It was discovered only later when the drafts were consolidated. I thought I was the only coder who implemented the DR priority option at that time, and it would only involve myself if I changed it.. It was an oversight that this was not included in the "significant changes" section of the later PIM-SM draft, since we were only doing diffs against a previous RFC, not against the previous Internet-Drafts... It could have been worse, but the positive side of this is that the DR election mechanism is robust enough to not cause havoc. If not all neighbors are DR-priority capable, they will drop down to the old address-comparison-only mode, and DR-priority will become active again when the "non-capable" neighbors all disappear. It is hard to guess how much deployment has been done with the DR election priority option and the Bi-dir option. I can think of the following few options to move forward: 1) Deprecate both values of 19 and 18 as valid Hello options. Assign new values to both DR-prio and Bi-Dir options. Everyone needs to switch; 2) Keep the current PIM-SM option value assignment, and let those who implemented draft-ietf-idmr-pimv2-dr-priority-00.txt change their code; 3) Deprecate the current Bi-Dir option code 19, making it the DR priority election priority code again. Make code 18 an invalid option, and reassign a new code for Bi-Dir option This probably is acceptable if Bi-dir PIM is not widely deployed yet. But I will understand if people don't want to say so here. Comments ? -Liming > Date: Thu, 25 May 2000 12:27:17 -0700 > From: Tom Pusateri > > In message <200005251804.LAA03514@vienna.iprg.nokia.com> you write: > >At Interop in Las Vegas this year I noticed that Junipers running > >JunOS release 4.0 were sending PIM hello option 19 with a length > >of 4 (Invalid Bidirectional PIM capable option). Presumably what > >the coder was trying to do was specify DR priority, but was following > >the older spec, draft-ietf-idmr-pimv2-dr-priority-00.txt. Has anyone > >else seen similar behavior on this or other manufacturers' routers? > > > >By the way, if anyone from Juniper is listening, I imagine that > >you'd like to fix this. > > > >Fred > > Actually, that code has been in there since the DR priority draft came > out and is the same in all JUNOS releases shipping for the past few > years. > > So was the DR priority draft wrong because the option was already > used or did the option get re-assigned? > > Thanks, > Tom > From owner-pim@catarina.usc.edu Thu May 25 19:55:33 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23070 for ; Thu, 25 May 2000 19:55:33 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA57886 for pim-list; Thu, 25 May 2000 16:50:51 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA57878 for ; Thu, 25 May 2000 16:50:50 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA08579 for ; Thu, 25 May 2000 16:50:49 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA04190; Thu, 25 May 2000 16:49:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id QAA31848; Thu, 25 May 2000 16:49:17 -0700 X-Virus-Scanned: Thu, 25 May 2000 16:49:17 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (vienna.iprg.nokia.com [205.226.11.35]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma031638; Thu, 25 May 00 16:49:10 -0700 Received: from vienna.iprg.nokia.com (localhost [127.0.0.1]) by vienna.iprg.nokia.com (8.8.8/8.6.12) with ESMTP id QAA04435; Thu, 25 May 2000 16:49:11 -0700 (PDT) Message-Id: <200005252349.QAA04435@vienna.iprg.nokia.com> To: lwei@redback.com cc: pusateri@juniper.net, fred@iprg.nokia.com, pim@catarina.usc.edu Subject: Re: PIM hello option DR priority In-reply-to: Message from Liming Wei of "Thu, 25 May 2000 16:13:43 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4432.959298551.1@vienna.iprg.nokia.com> Date: Thu, 25 May 2000 16:49:11 -0700 From: Fred Bauer Sender: owner-pim@catarina.usc.edu Precedence: bulk Liming, My 2 cents worth is that option 3 makes the most sense given that routers out there already honor DR-priority = 19. I am guessing that bidir is not yet widely established, so the impact will be minimal. Fred >Sigh, this was due to the code assignment conflict with other options. >It was discovered only later when the drafts were consolidated. I >thought I was the only coder who implemented the DR priority option at >that time, and it would only involve myself if I changed it.. > >It was an oversight that this was not included in the "significant >changes" section of the later PIM-SM draft, since we were only doing >diffs against a previous RFC, not against the previous >Internet-Drafts... > >It could have been worse, but the positive side of this is that the DR >election mechanism is robust enough to not cause havoc. If not all >neighbors are DR-priority capable, they will drop down to the old >address-comparison-only mode, and DR-priority will become active again >when the "non-capable" neighbors all disappear. > >It is hard to guess how much deployment has been done with >the DR election priority option and the Bi-dir option. I can >think of the following few options to move forward: > > 1) Deprecate both values of 19 and 18 as valid Hello options. > Assign new values to both DR-prio and Bi-Dir options. Everyone > needs to switch; > > 2) Keep the current PIM-SM option value assignment, and let those > who implemented draft-ietf-idmr-pimv2-dr-priority-00.txt > change their code; > > 3) Deprecate the current Bi-Dir option code 19, making it the > DR priority election priority code again. Make code 18 an > invalid option, and reassign a new code for Bi-Dir option > > This probably is acceptable if Bi-dir PIM is not widely > deployed yet. But I will understand if people don't want to > say so here. > > Comments ? > >-Liming > > >> Date: Thu, 25 May 2000 12:27:17 -0700 >> From: Tom Pusateri >> >> In message <200005251804.LAA03514@vienna.iprg.nokia.com> you write: >> >At Interop in Las Vegas this year I noticed that Junipers running >> >JunOS release 4.0 were sending PIM hello option 19 with a length >> >of 4 (Invalid Bidirectional PIM capable option). Presumably what >> >the coder was trying to do was specify DR priority, but was following >> >the older spec, draft-ietf-idmr-pimv2-dr-priority-00.txt. Has anyone >> >else seen similar behavior on this or other manufacturers' routers? >> > >> >By the way, if anyone from Juniper is listening, I imagine that >> >you'd like to fix this. >> > >> >Fred >> >> Actually, that code has been in there since the DR priority draft came >> out and is the same in all JUNOS releases shipping for the past few >> years. >> >> So was the DR priority draft wrong because the option was already >> used or did the option get re-assigned? >> >> Thanks, >> Tom >> > From owner-pim@catarina.usc.edu Thu May 25 20:49:39 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23616 for ; Thu, 25 May 2000 20:49:38 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id RAA58314 for pim-list; Thu, 25 May 2000 17:43:20 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id RAA58304 for ; Thu, 25 May 2000 17:43:19 -0700 (PDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA07036 for ; Thu, 25 May 2000 17:43:18 -0700 (PDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 25 May 2000 17:38:04 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D7353A71B@SOL> From: Desikan Saravanan To: "'Fred Bauer'" , lwei@redback.com Cc: pusateri@juniper.net, pim@catarina.usc.edu Subject: RE: PIM hello option DR priority Date: Thu, 25 May 2000 17:38:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk I Agree with Fred. Option 3 is the best among all. Des -----Original Message----- From: Fred Bauer [mailto:fred@iprg.nokia.com] Sent: Thursday, May 25, 2000 4:49 PM To: lwei@redback.com Cc: pusateri@juniper.net; fred@iprg.nokia.com; pim@catarina.usc.edu Subject: Re: PIM hello option DR priority Liming, My 2 cents worth is that option 3 makes the most sense given that routers out there already honor DR-priority = 19. I am guessing that bidir is not yet widely established, so the impact will be minimal. Fred >Sigh, this was due to the code assignment conflict with other options. >It was discovered only later when the drafts were consolidated. I >thought I was the only coder who implemented the DR priority option at >that time, and it would only involve myself if I changed it.. > >It was an oversight that this was not included in the "significant >changes" section of the later PIM-SM draft, since we were only doing >diffs against a previous RFC, not against the previous >Internet-Drafts... > >It could have been worse, but the positive side of this is that the DR >election mechanism is robust enough to not cause havoc. If not all >neighbors are DR-priority capable, they will drop down to the old >address-comparison-only mode, and DR-priority will become active again >when the "non-capable" neighbors all disappear. > >It is hard to guess how much deployment has been done with >the DR election priority option and the Bi-dir option. I can >think of the following few options to move forward: > > 1) Deprecate both values of 19 and 18 as valid Hello options. > Assign new values to both DR-prio and Bi-Dir options. Everyone > needs to switch; > > 2) Keep the current PIM-SM option value assignment, and let those > who implemented draft-ietf-idmr-pimv2-dr-priority-00.txt > change their code; > > 3) Deprecate the current Bi-Dir option code 19, making it the > DR priority election priority code again. Make code 18 an > invalid option, and reassign a new code for Bi-Dir option > > This probably is acceptable if Bi-dir PIM is not widely > deployed yet. But I will understand if people don't want to > say so here. > > Comments ? > >-Liming > > >> Date: Thu, 25 May 2000 12:27:17 -0700 >> From: Tom Pusateri >> >> In message <200005251804.LAA03514@vienna.iprg.nokia.com> you write: >> >At Interop in Las Vegas this year I noticed that Junipers running >> >JunOS release 4.0 were sending PIM hello option 19 with a length >> >of 4 (Invalid Bidirectional PIM capable option). Presumably what >> >the coder was trying to do was specify DR priority, but was following >> >the older spec, draft-ietf-idmr-pimv2-dr-priority-00.txt. Has anyone >> >else seen similar behavior on this or other manufacturers' routers? >> > >> >By the way, if anyone from Juniper is listening, I imagine that >> >you'd like to fix this. >> > >> >Fred >> >> Actually, that code has been in there since the DR priority draft came >> out and is the same in all JUNOS releases shipping for the past few >> years. >> >> So was the DR priority draft wrong because the option was already >> used or did the option get re-assigned? >> >> Thanks, >> Tom >> > From owner-pim@catarina.usc.edu Fri May 26 11:04:45 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17247 for ; Fri, 26 May 2000 11:04:45 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA60897 for pim-list; Fri, 26 May 2000 07:54:29 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA60892 for ; Fri, 26 May 2000 07:54:27 -0700 (PDT) Received: from uniwest1.redstonecom.com ([199.105.223.130]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA11481 for ; Fri, 26 May 2000 07:54:27 -0700 (PDT) Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 May 2000 10:55:29 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C7C3C66@uniwest1.redstonecom.com> From: "Shekhar, Ravi" To: lwei@redback.com, pusateri@juniper.net Cc: fred@iprg.nokia.com, pim@catarina.usc.edu Subject: RE: PIM hello option DR priority Date: Fri, 26 May 2000 10:55:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk > 1) Deprecate both values of 19 and 18 as valid Hello options. > Assign new values to both DR-prio and Bi-Dir options. Everyone > needs to switch; > > 2) Keep the current PIM-SM option value assignment, and let those > who implemented draft-ietf-idmr-pimv2-dr-priority-00.txt > change their code; > > 3) Deprecate the current Bi-Dir option code 19, making it the > DR priority election priority code again. Make code 18 an > invalid option, and reassign a new code for Bi-Dir option Additionally, it might be worth pointing out that the new implementations can still interoperate with existing implementations by looking at the option-length field. Its 4 for DR-priority and 0 for Bidirectional PIM. - Ravi Shekhar. From owner-pim@catarina.usc.edu Fri May 26 13:46:50 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21281 for ; Fri, 26 May 2000 13:46:49 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA61728 for pim-list; Fri, 26 May 2000 10:35:57 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA61723 for ; Fri, 26 May 2000 10:35:56 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA06451 for ; Fri, 26 May 2000 10:35:56 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA15534; Fri, 26 May 2000 10:32:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA28932; Fri, 26 May 2000 10:32:49 -0700 X-Virus-Scanned: Fri, 26 May 2000 10:32:49 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (vienna.iprg.nokia.com [205.226.11.35]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma028112; Fri, 26 May 00 10:32:27 -0700 Received: from vienna.iprg.nokia.com (localhost [127.0.0.1]) by vienna.iprg.nokia.com (8.8.8/8.6.12) with ESMTP id KAA06027; Fri, 26 May 2000 10:32:27 -0700 (PDT) Message-Id: <200005261732.KAA06027@vienna.iprg.nokia.com> To: "Shekhar, Ravi" cc: lwei@redback.com, pusateri@juniper.net, fred@iprg.nokia.com, pim@catarina.usc.edu Subject: Re: PIM hello option DR priority In-reply-to: Message from "Shekhar, Ravi" of "Fri, 26 May 2000 10:55:29 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6024.959362347.1@vienna.iprg.nokia.com> Date: Fri, 26 May 2000 10:32:27 -0700 From: Fred Bauer Sender: owner-pim@catarina.usc.edu Precedence: bulk >Additionally, it might be worth pointing out that the new implementations >can still interoperate with existing implementations by looking at the >option-length field. Its 4 for DR-priority and 0 for Bidirectional PIM. Ravi's pointed out the obvious workaround since the (option,length) pair gives enough information to comply with the old and new indicies for DR priority. option length interpretation ------------------------------------------------------------------------ 18 0 invalid 18 4 DR priority 19 0 Bidir 19 4 DR priority This is what we've done for now until the spec is clarified. Thanks, Fred From owner-pim@catarina.usc.edu Fri May 26 14:22:32 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22314 for ; Fri, 26 May 2000 14:22:30 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA61970 for pim-list; Fri, 26 May 2000 11:13:49 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA61965 for ; Fri, 26 May 2000 11:13:48 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA01049 for ; Fri, 26 May 2000 11:13:47 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 2EF5E4CE2A; Fri, 26 May 2000 13:33:47 -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 NAA19060; Fri, 26 May 2000 13:33:23 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA15936; Fri, 26 May 2000 10:31:51 -0700 (PDT) Message-Id: <200005261731.KAA15936@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: lwei@redback.com Subject: Re: PIM hello option DR priority Cc: pim@catarina.usc.edu Date: Fri, 26 May 2000 10:31:51 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk >Sigh, this was due to the code assignment conflict with other options. >It was discovered only later when the drafts were consolidated. I'm just confused why the one that was published earlier (DR priority) was the one that got renumbered. I think the trend is towards Liming's option #3, which I agree with. Someone mentioned that you can tell the difference by using the length of the option; presumably this would only be for backwards compatibility. BTW, now that we've opened this can of worms, why are 2-16 reserved? What's 17 used for? Bill From owner-pim@catarina.usc.edu Fri May 26 15:27:46 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23404 for ; Fri, 26 May 2000 15:27:45 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA62500 for pim-list; Fri, 26 May 2000 12:19:35 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA62495 for ; Fri, 26 May 2000 12:19:34 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA11670 for ; Fri, 26 May 2000 12:19:35 -0700 (PDT) Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id B38AF2AA09; Fri, 26 May 2000 12:16:29 -0700 (PDT) Received: (from lwei@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id MAA18792; Fri, 26 May 2000 12:15:42 -0700 (PDT) Date: Fri, 26 May 2000 12:15:42 -0700 (PDT) Message-Id: <200005261915.MAA18792@malt.redback.com> From: Liming Wei To: fenner@research.att.com Cc: pim@catarina.usc.edu In-reply-to: <200005261731.KAA15936@windsor.research.att.com> (message from Bill Fenner on Fri, 26 May 2000 10:31:51 -0700) Subject: Re: PIM hello option DR priority Reply-To: lwei@redback.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Bill Fenner > Date: Fri, 26 May 2000 10:31:51 -0700 > > >Sigh, this was due to the code assignment conflict with other options. > >It was discovered only later when the drafts were consolidated. > > I'm just confused why the one that was published earlier (DR priority) > was the one that got renumbered. > > I think the trend is towards Liming's option #3, which I agree with. > Someone mentioned that you can tell the difference by using the length > of the option; presumably this would only be for backwards compatibility. Ok, folks please give us some time. I figure it might be easier for people to get agreement in private, sometimes. I'll report back on the result. If there are other people affected, please either a message here, or contact me and Tom directly. > > BTW, now that we've opened this can of worms, why are 2-16 reserved? > What's 17 used for? I need to go back and find out why. Thanks, -Liming From owner-pim@catarina.usc.edu Fri May 26 21:24:33 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29109 for ; Fri, 26 May 2000 21:24:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id SAA63803 for pim-list; Fri, 26 May 2000 18:15:50 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id SAA63798 for ; Fri, 26 May 2000 18:15:49 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id SAA20738 for ; Fri, 26 May 2000 18:15:49 -0700 (PDT) Received: (from ycai@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA06516; Fri, 26 May 2000 18:11:55 -0700 (PDT) Date: Fri, 26 May 2000 18:11:55 -0700 (PDT) Message-Id: <200005270111.SAA06516@omega.cisco.com> From: Yiqun Cai To: lwei@redback.com CC: fenner@research.att.com, pim@catarina.usc.edu In-reply-to: <200005261915.MAA18792@malt.redback.com> (message from Liming Wei on Fri, 26 May 2000 12:15:42 -0700 (PDT)) Subject: Re: PIM hello option DR priority Reply-to: ycai@cisco.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > What's 17 used for? It is being used for Multicast TAG switching. -- Yiqun From owner-pim@catarina.usc.edu Fri May 26 21:27:45 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29129 for ; Fri, 26 May 2000 21:27:44 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id SAA63817 for pim-list; Fri, 26 May 2000 18:19:41 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id SAA63812 for ; Fri, 26 May 2000 18:19:40 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id SAA21951 for ; Fri, 26 May 2000 18:19:40 -0700 (PDT) Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id D91A42AA09; Fri, 26 May 2000 18:16:39 -0700 (PDT) Received: (from lwei@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id SAA28754; Fri, 26 May 2000 18:15:51 -0700 (PDT) Date: Fri, 26 May 2000 18:15:51 -0700 (PDT) Message-Id: <200005270115.SAA28754@malt.redback.com> From: Liming Wei To: ycai@cisco.com Cc: fenner@research.att.com, pim@catarina.usc.edu In-reply-to: <200005270111.SAA06516@omega.cisco.com> (message from Yiqun Cai on Fri, 26 May 2000 18:11:55 -0700 (PDT)) Subject: Re: PIM hello option DR priority Reply-To: lwei@redback.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > Date: Fri, 26 May 2000 18:11:55 -0700 (PDT) > From: Yiqun Cai > > > What's 17 used for? > > It is being used for Multicast TAG switching. It was removed from the spec because it was a vendor specific thing. Now I think it needs to go back in the spec, with or without a reference spec for multicast tag switching. -Liming From owner-pim@catarina.usc.edu Sat May 27 02:26:38 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14912 for ; Sat, 27 May 2000 02:26:37 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id XAA64769 for pim-list; Fri, 26 May 2000 23:19:38 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id XAA64764 for ; Fri, 26 May 2000 23:19:36 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id XAA05308 for ; Fri, 26 May 2000 23:19:33 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Sat, 27 May 2000 11:58:42 +0530 Received: from sabaris.future.futsoft.com (rosario.future.futsoft.com [10.0.2.1]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA08295 for ; Sat, 27 May 2000 11:34:09 +0530 Received: by localhost with Microsoft MAPI; Sat, 27 May 2000 11:41:21 +0530 Message-Id: <01BFC7D0.7AB572E0.sabaris@future.futsoft.com> From: sabarivel s To: "'pim-implementors'" Subject: null register message Date: Sat, 27 May 2000 11:41:19 +0530 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BFC7D0.7B329220" Sender: owner-pim@catarina.usc.edu Precedence: bulk ------ =_NextPart_000_01BFC7D0.7B329220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit hi, in which case null register message should be sent ? I could not visualise the actual use of the null register message In response to the null register message what action is to be taken . RFC (2362) states the what action to be taken when register message with null bit cleared is received. But doesn't say what action is to be taken when null register message is received. If i am wrong correct me. thanks and regards sabaris ------ =_NextPart_000_01BFC7D0.7B329220 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhYGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYArAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbwAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAAAf8W+6YxtIRnF4AIDVD 616EjQAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAcGltLWltcGxlbWVudG9ycwBTTVRQAHBpbUBj YXRhcmluYS51c2MuZWR1AAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAFQAAAHBpbUBjYXRh cmluYS51c2MuZWR1AAAAAAMAFQwBAAAAAwD+DwYAAAAeAAEwAQAAABMAAAAncGltLWltcGxlbWVu dG9ycycAAAIBCzABAAAAGgAAAFNNVFA6UElNQENBVEFSSU5BLlVTQy5FRFUAAAADAAA5AAAAAAsA QDoBAAAAHgD2XwEAAAARAAAAcGltLWltcGxlbWVudG9ycwAAAAACAfdfAQAAACwAAAC/AAAAtTvC wCx3EBqhvAgAKypWwhUAAAAH/FvumMbSEZxeACA1Q+tehI0AAAMA/V8BAAAAAwD/XwAAAAACAfYP AQAAAAQAAAAAAAACeFwBBIABABYAAABudWxsIHJlZ2lzdGVyIG1lc3NhZ2UARQgBBYADAA4AAADQ BwUAGwALACkAEwAGAEQBASCAAwAOAAAA0AcFABsACwAnADgABgBnAQEJgAEAIQAAADE0MzYyQjBC QjczM0Q0MTFCM0VBMDA2MDk0MENENUEyAPoGAQOQBgCkBAAAIAAAAAsAAgABAAAACwAjAAAAAAAD ACYAAAAAAAsAKQAAAAAAAwA2AAAAAABAADkAoF2kX6LHvwEeAHAAAQAAABYAAABudWxsIHJlZ2lz dGVyIG1lc3NhZ2UAAAACAXEAAQAAABYAAAABv8eiX5MLKzYgM7cR1LPqAGCUDNWiAAAeAB4MAQAA AAUAAABTTVRQAAAAAB4AHwwBAAAAGwAAAHNhYmFyaXNAZnV0dXJlLmZ1dHNvZnQuY29tAAADAAYQ pgi82QMABxBbAQAAHgAIEAEAAABlAAAASEksSU5XSElDSENBU0VOVUxMUkVHSVNURVJNRVNTQUdF U0hPVUxEQkVTRU5UP0lDT1VMRE5PVFZJU1VBTElTRVRIRUFDVFVBTFVTRU9GVEhFTlVMTFJFR0lT VEVSTUVTU0FHRQAAAAACAQkQAQAAAIoBAACGAQAAbAIAAExaRnXcM52YAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzOdAfcgAqQD4wIAY2gKwGBzZXQwIAcTAoB9OQqBdWMAUAsDC7UgaNxpLAqiCoQKgCAU MwuAjCB3E0AQ8CBjYREwsCBudWwDIAlwZwQAinQEkCAHgXNhZxVQhHNoCGBsZCBiFrFjCfAFQD8g SRUQFvNu6m8FQHYEAHUHQAQAFVAsdGgVUADQdBjRIHV5FUFvZhkzFX8WghN+SbMDoAlwc3ACIBkS bxpf2xY4FMBhBUAZgWkCIBSALwQgHbEXQQGQawnwIC4BB/BGQyAoMjM2/DIpFsABkBYQIFEZUR+K vyB6FMAhAR53JQYfB2kZQM0eFGImIBUQbGUKwAmAwyAyCXBjZWl2CYAhMCRCdQVAZG8HkG4n+wVA FoB5H38jjh4fFnQneusb/xpAaRlwbRSwA2APIP0X8XInoQVAB4AtaxN0GUD9AHBrBCAAcBcgK6EL ERDAexODFoBiCsAEABN0EfEAATOwAAADABAQAAAAAAMAERAAAAAAAwCAEP////9AAAcwAAUSbqHH vwFAAAgwoOE9LqLHvwELAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAA AMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAPMVAAADAAmA CCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAB4AEIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAAB AAAABQAAADguMDQAAAAACwARgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADABKACCAGAAAA AADAAAAAAAAARgAAAAARhQAAAAAAAAMAE4AIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAU gAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AFYAIIAYAAAAAAMAAAAAAAABG AAAAADeFAAABAAAAAQAAAAAAAAAeABaACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAA AAAAHgA9AAEAAAABAAAAAAAAAAMADTT9NwAAx+M= ------ =_NextPart_000_01BFC7D0.7B329220-- From owner-pim@catarina.usc.edu Sat May 27 15:35:46 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20742 for ; Sat, 27 May 2000 15:35:45 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA69645 for pim-list; Sat, 27 May 2000 12:24:02 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA69640 for ; Sat, 27 May 2000 12:24:01 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA11840 for ; Sat, 27 May 2000 12:24:00 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA12727; Sat, 27 May 2000 12:22:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id MAA27312; Sat, 27 May 2000 12:22:28 -0700 X-Virus-Scanned: Sat, 27 May 2000 12:22:28 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (bahadur.iprg.nokia.com [205.226.11.43]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma027167; Sat, 27 May 00 12:22:21 -0700 Received: from localhost (bahadur@localhost) by bahadur.iprg.nokia.com (8.8.8/8.6.12) with SMTP id MAA12860; Sat, 27 May 2000 12:22:23 -0700 (PDT) X-Authentication-Warning: bahadur.iprg.nokia.com: bahadur owned process doing -bs Date: Sat, 27 May 2000 12:22:23 -0700 (PDT) From: Rahul Bahadur Reply-To: Rahul Bahadur To: sabarivel s cc: "'pim-implementors'" , bahadur@iprg.nokia.com Subject: Re: null register message In-Reply-To: <01BFC7D0.7AB572E0.sabaris@future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Sabaris, The null Register message is intended to provide a mechanism to help avoid a situation where the RP is overwhelmed with data due to expiration of the Register-Suppression-Timer at the DR(s). The Register-Suppression-Timer should have been started on receipt of a Register-Stop message from the RP for that group; the RP would have sent the Register-Stop in the event of a NULL oif list. If there is data to be sent, and, the Register-Suppression- Timer is running, a null Register message is sent [Probe-Time] seconds (default 5) before the expiration of Register-Suppression- Timer. If the RP still does not have an oif for the group it will send a Register-Stop to help restart the timer. For more information on this I would suggest sections 3.3.1 and 3.3.2 of draft-ietf-pim-v2-sm-01.txt (11/99). Regards, Rahul On Sat, 27 May 2000, sabarivel s wrote: > hi, > > in which case null register message should be sent ? I could not > visualise the actual use of the null register message > > In response to the null register message what action is to be taken . > RFC (2362) states the what action to be taken when register message > with null bit cleared is received. But doesn't say what action is to be > taken when null register message is received. > > If i am wrong correct me. > > > thanks and regards > sabaris From owner-pim@catarina.usc.edu Sat May 27 22:32:22 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24572 for ; Sat, 27 May 2000 22:32:22 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA70937 for pim-list; Sat, 27 May 2000 19:25:45 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id TAA70932 for ; Sat, 27 May 2000 19:25:44 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA11438 for ; Sat, 27 May 2000 19:25:44 -0700 (PDT) Received: from garnet.juniper.net (garnet.juniper.net [208.197.169.237]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA12548; Sat, 27 May 2000 19:24:29 -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 TAA00105; Sat, 27 May 2000 19:24:28 -0700 (PDT) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200005280224.TAA00105@garnet.juniper.net> To: lwei@redback.com cc: pusateri@juniper.net, fred@iprg.nokia.com, pim@catarina.usc.edu, pusateri@juniper.net Subject: Re: PIM hello option DR priority In-Reply-To: Message from Liming Wei of "Thu, 25 May 2000 16:13:43 PDT." <200005252313.QAA06612@malt.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <102.959480668.1@garnet.juniper.net> Date: Sat, 27 May 2000 19:24:28 -0700 From: Tom Pusateri Sender: owner-pim@catarina.usc.edu Precedence: bulk My vote is for #3 since it is deployed. Tom In message <200005252313.QAA06612@malt.redback.com> you write: >Sigh, this was due to the code assignment conflict with other options. >It was discovered only later when the drafts were consolidated. I >thought I was the only coder who implemented the DR priority option at >that time, and it would only involve myself if I changed it.. > >It was an oversight that this was not included in the "significant >changes" section of the later PIM-SM draft, since we were only doing >diffs against a previous RFC, not against the previous >Internet-Drafts... > >It could have been worse, but the positive side of this is that the DR >election mechanism is robust enough to not cause havoc. If not all >neighbors are DR-priority capable, they will drop down to the old >address-comparison-only mode, and DR-priority will become active again >when the "non-capable" neighbors all disappear. > >It is hard to guess how much deployment has been done with >the DR election priority option and the Bi-dir option. I can >think of the following few options to move forward: > > 1) Deprecate both values of 19 and 18 as valid Hello options. > Assign new values to both DR-prio and Bi-Dir options. Everyone > needs to switch; > > 2) Keep the current PIM-SM option value assignment, and let those > who implemented draft-ietf-idmr-pimv2-dr-priority-00.txt > change their code; > > 3) Deprecate the current Bi-Dir option code 19, making it the > DR priority election priority code again. Make code 18 an > invalid option, and reassign a new code for Bi-Dir option > > This probably is acceptable if Bi-dir PIM is not widely > deployed yet. But I will understand if people don't want to > say so here. > > Comments ? > >-Liming > > >> Date: Thu, 25 May 2000 12:27:17 -0700 >> From: Tom Pusateri >> >> In message <200005251804.LAA03514@vienna.iprg.nokia.com> you write: >> >At Interop in Las Vegas this year I noticed that Junipers running >> >JunOS release 4.0 were sending PIM hello option 19 with a length >> >of 4 (Invalid Bidirectional PIM capable option). Presumably what >> >the coder was trying to do was specify DR priority, but was following >> >the older spec, draft-ietf-idmr-pimv2-dr-priority-00.txt. Has anyone >> >else seen similar behavior on this or other manufacturers' routers? >> > >> >By the way, if anyone from Juniper is listening, I imagine that >> >you'd like to fix this. >> > >> >Fred >> >> Actually, that code has been in there since the DR priority draft came >> out and is the same in all JUNOS releases shipping for the past few >> years. >> >> So was the DR priority draft wrong because the option was already >> used or did the option get re-assigned? >> >> Thanks, >> Tom >> From owner-pim@catarina.usc.edu Tue May 30 14:46:29 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06848 for ; Tue, 30 May 2000 14:46:29 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA79544 for pim-list; Tue, 30 May 2000 11:32:35 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA79539 for ; Tue, 30 May 2000 11:32:34 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA05349 for ; Tue, 30 May 2000 11:32:32 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA06349; Tue, 30 May 2000 11:26:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA13277; Tue, 30 May 2000 11:26:56 -0700 X-Virus-Scanned: Tue, 30 May 2000 11:26:56 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (agni.iprg.nokia.com [205.226.8.100]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma010734; Tue, 30 May 00 11:25:57 -0700 Received: from agni.iprg.nokia.com (localhost [127.0.0.1]) by agni.iprg.nokia.com (8.8.8/8.6.12) with ESMTP id LAA17303; Tue, 30 May 2000 11:25:59 -0700 (PDT) Message-Id: <200005301825.LAA17303@agni.iprg.nokia.com> To: pim@catarina.usc.edu cc: rglr@iol.unh.edu, ravi@iprg.nokia.com Subject: PIM Bake-off/Interoperability Testing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17300.959711159.1@agni.iprg.nokia.com> Date: Tue, 30 May 2000 11:25:59 -0700 From: Ravi Puvvala Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi All, I think there are sufficient new implementations for both PIM dense mode and sparse mode now. It might be benificiary to all to have a PIM bake-off/interoperability event. University of New Hampshire has organized a couple of these events in the past. I pinged Ray LaRocca at UNH. He said UNH will be interested in hosting this event. If there is sufficient interest we could have one in the next couple of months. Comments??? Ravi From owner-pim@catarina.usc.edu Tue May 30 16:11:34 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09358 for ; Tue, 30 May 2000 16:11:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA80140 for pim-list; Tue, 30 May 2000 13:01:45 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA80135 for ; Tue, 30 May 2000 13:01:41 -0700 (PDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA04556 for ; Tue, 30 May 2000 13:01:37 -0700 (PDT) Received: from cisco.com (dhcp-171-69-127-182.cisco.com [171.69.127.182]) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA03803; Tue, 30 May 2000 12:57:09 -0700 (PDT) Message-ID: <39342C12.3196E44E@cisco.com> Date: Tue, 30 May 2000 14:01:06 -0700 From: John Meylor X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred Bauer CC: lwei@redback.com, pusateri@juniper.net, pim@catarina.usc.edu Subject: Re: PIM hello option DR priority References: <200005252349.QAA04435@vienna.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Fred Bauer wrote: > > Liming, > > My 2 cents worth is that option 3 makes the most sense given that > routers out there already honor DR-priority = 19. actually our implementation is using DR-priority = 18, and we have fairly significant deployment using this. I am guessing > that bidir is not yet widely established, so the impact will be > minimal. probably true, I don't think the issue would be with bidir, but rather with existing DR priority deployment. John > > Fred > > >Sigh, this was due to the code assignment conflict with other options. > >It was discovered only later when the drafts were consolidated. I > >thought I was the only coder who implemented the DR priority option at > >that time, and it would only involve myself if I changed it.. > > > >It was an oversight that this was not included in the "significant > >changes" section of the later PIM-SM draft, since we were only doing > >diffs against a previous RFC, not against the previous > >Internet-Drafts... > > > >It could have been worse, but the positive side of this is that the DR > >election mechanism is robust enough to not cause havoc. If not all > >neighbors are DR-priority capable, they will drop down to the old > >address-comparison-only mode, and DR-priority will become active again > >when the "non-capable" neighbors all disappear. > > > >It is hard to guess how much deployment has been done with > >the DR election priority option and the Bi-dir option. I can > >think of the following few options to move forward: > > > > 1) Deprecate both values of 19 and 18 as valid Hello options. > > Assign new values to both DR-prio and Bi-Dir options. Everyone > > needs to switch; > > > > 2) Keep the current PIM-SM option value assignment, and let those > > who implemented draft-ietf-idmr-pimv2-dr-priority-00.txt > > change their code; > > > > 3) Deprecate the current Bi-Dir option code 19, making it the > > DR priority election priority code again. Make code 18 an > > invalid option, and reassign a new code for Bi-Dir option > > > > This probably is acceptable if Bi-dir PIM is not widely > > deployed yet. But I will understand if people don't want to > > say so here. > > > > Comments ? > > > >-Liming > > > > > >> Date: Thu, 25 May 2000 12:27:17 -0700 > >> From: Tom Pusateri > >> > >> In message <200005251804.LAA03514@vienna.iprg.nokia.com> you write: > >> >At Interop in Las Vegas this year I noticed that Junipers running > >> >JunOS release 4.0 were sending PIM hello option 19 with a length > >> >of 4 (Invalid Bidirectional PIM capable option). Presumably what > >> >the coder was trying to do was specify DR priority, but was following > >> >the older spec, draft-ietf-idmr-pimv2-dr-priority-00.txt. Has anyone > >> >else seen similar behavior on this or other manufacturers' routers? > >> > > >> >By the way, if anyone from Juniper is listening, I imagine that > >> >you'd like to fix this. > >> > > >> >Fred > >> > >> Actually, that code has been in there since the DR priority draft came > >> out and is the same in all JUNOS releases shipping for the past few > >> years. > >> > >> So was the DR priority draft wrong because the option was already > >> used or did the option get re-assigned? > >> > >> Thanks, > >> Tom > >> > > From owner-pim@catarina.usc.edu Tue May 30 17:38:15 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11062 for ; Tue, 30 May 2000 17:38:14 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA80688 for pim-list; Tue, 30 May 2000 14:27:33 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA80683 for ; Tue, 30 May 2000 14:27:32 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA02185 for ; Tue, 30 May 2000 14:27:31 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id F3C721E04F; Tue, 30 May 2000 17:24: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 RAA13189; Tue, 30 May 2000 17:24:44 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA11842; Tue, 30 May 2000 14:23:09 -0700 (PDT) Message-Id: <200005302123.OAA11842@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jmeylor@cisco.com Subject: Re: PIM hello option DR priority Cc: pim@catarina.usc.edu References: <200005252349.QAA04435@vienna.iprg.nokia.com> <39342C12.3196E44E@cisco.com> Date: Tue, 30 May 2000 14:23:08 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk I'm still interested in recreating the timeline. draft-ietf-idmr-pimv2-dr-priority-00.txt was published in March of 1998, with 2 cisco Systems authors, and specified option #19. When did IOS change to 18, and why? Also, anyone with bidir implementations, how will your implementation treat an option #19 with length 4? Bill From owner-pim@catarina.usc.edu Tue May 30 17:57:47 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11398 for ; Tue, 30 May 2000 17:57:47 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA80838 for pim-list; Tue, 30 May 2000 14:49:59 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA80833 for ; Tue, 30 May 2000 14:49:58 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA17260 for ; Tue, 30 May 2000 14:49:58 -0700 (PDT) Received: (from ycai@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA07020; Tue, 30 May 2000 14:44:51 -0700 (PDT) Date: Tue, 30 May 2000 14:44:51 -0700 (PDT) Message-Id: <200005302144.OAA07020@omega.cisco.com> From: Yiqun Cai To: fenner@research.att.com CC: jmeylor@cisco.com, pim@catarina.usc.edu In-reply-to: <200005302123.OAA11842@windsor.research.att.com> (message from Bill Fenner on Tue, 30 May 2000 14:23:08 -0700) Subject: Re: PIM hello option DR priority Reply-to: ycai@cisco.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > > Also, anyone with bidir implementations, how will your implementation > treat an option #19 with length 4? skip the 4 bytes and move on to the next TLV. -- Yiqun From owner-pim@catarina.usc.edu Tue May 30 18:57:34 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12513 for ; Tue, 30 May 2000 18:57:33 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA81379 for pim-list; Tue, 30 May 2000 15:50:09 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA81374 for ; Tue, 30 May 2000 15:50:08 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA25025 for ; Tue, 30 May 2000 15:50:04 -0700 (PDT) Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 055F62AA18; Tue, 30 May 2000 15:46:58 -0700 (PDT) Received: (from lwei@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id PAA17757; Tue, 30 May 2000 15:46:11 -0700 (PDT) Date: Tue, 30 May 2000 15:46:11 -0700 (PDT) Message-Id: <200005302246.PAA17757@malt.redback.com> From: Liming Wei To: fenner@research.att.com Cc: jmeylor@cisco.com, pim@catarina.usc.edu In-reply-to: <200005302123.OAA11842@windsor.research.att.com> (message from Bill Fenner on Tue, 30 May 2000 14:23:08 -0700) Subject: Re: PIM hello option DR priority Reply-To: lwei@redback.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Bill Fenner > > I'm still interested in recreating the timeline. > draft-ietf-idmr-pimv2-dr-priority-00.txt was published in March of 1998, > with 2 cisco Systems authors, and specified option #19. When did IOS > change to 18, and why? Ok ok. I'm not sure what to say, other than an apology (probably useless). The code in 12.0T was actually Dino's code, while I edited the draft. It must have been that the bi-dir code and dr priority code were in the same place. When we came to consolidate the values, I took them from the code, instead of from the expired drafts. I was not aware of any non-cisco implementations, until a couple of weeks back. (so much for a lesson for a draft editor.) I won't go into more details in history, but would like to see a resolution soon. Ravi/Fred's interop logic can be used as a short term solution, and we better come to a clean solution considering all factors. > Also, anyone with bidir implementations, how will your implementation > treat an option #19 with length 4? -Liming From owner-pim@catarina.usc.edu Tue May 30 19:40:07 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13151 for ; Tue, 30 May 2000 19:40:07 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA81631 for pim-list; Tue, 30 May 2000 16:33:18 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA81626 for ; Tue, 30 May 2000 16:33:17 -0700 (PDT) Received: from dino-pc.procket.com (flowpoint.procket.com [205.253.146.41]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA20016 for ; Tue, 30 May 2000 16:33:17 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id QAA30588; Tue, 30 May 2000 16:31:12 -0700 Date: Tue, 30 May 2000 16:31:12 -0700 Message-Id: <200005302331.QAA30588@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: lwei@redback.com CC: fenner@research.att.com, jmeylor@cisco.com, pim@catarina.usc.edu In-reply-to: <200005302246.PAA17757@malt.redback.com> (message from Liming Wei on Tue, 30 May 2000 15:46:11 -0700 (PDT)) Subject: Re: PIM hello option DR priority References: <200005302246.PAA17757@malt.redback.com> Sender: owner-pim@catarina.usc.edu Precedence: bulk >> Ok ok. I'm not sure what to say, other than an apology (probably >> useless). The code in 12.0T was actually Dino's code, while I edited >> the draft. It must have been that the bi-dir code and dr priority code All that I recall is that the DR option ID was created first and the Bidir ID, when implemented was a less mature draft. The original DR option ID was set to 19. I wondered why 18 was skipped and not assigned to any draft. I asked Liming, and he said he didn't know. So he said he would change the draft to make the DR option 18, so I picked 19 for Bidir and the implementation reflected this. When I originally did the Bidir code, I did the DR option code in the "same" feature release. So the code was self consistent but had the opportunity to be uninteroperable. I think we tried to get the ID updated before anyone else would have implemented the DR option. Tom probably snatch the 19 for the DR option before Liming had a chance to publish the new ID. Hence the problem. Dino From owner-pim@catarina.usc.edu Tue May 30 20:22:40 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13690 for ; Tue, 30 May 2000 20:22:39 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id RAA81959 for pim-list; Tue, 30 May 2000 17:14:00 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id RAA81954 for ; Tue, 30 May 2000 17:13:59 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA12160 for ; Tue, 30 May 2000 17:13:59 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id DEAB01E048; Tue, 30 May 2000 20:11:26 -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 UAA22757; Tue, 30 May 2000 20:11:26 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id RAA13694; Tue, 30 May 2000 17:09:50 -0700 (PDT) Message-Id: <200005310009.RAA13694@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dino@procket.com Subject: Re: PIM hello option DR priority Cc: pim@catarina.usc.edu References: <200005302246.PAA17757@malt.redback.com> <200005302331.QAA30588@dino-pc.procket.com> Date: Tue, 30 May 2000 17:09:50 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk It feels to me like people are missing the fact that the value of 19 for DR-Priority was published for 19 months. That is a pretty large window for people to implement. (The first spec renumbering it to 18 was only published 7 months ago.) Bill From owner-pim@catarina.usc.edu Tue May 30 23:04:44 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16877 for ; Tue, 30 May 2000 23:04:43 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA82660 for pim-list; Tue, 30 May 2000 19:57:11 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id TAA82655 for ; Tue, 30 May 2000 19:57:10 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA24981 for ; Tue, 30 May 2000 19:57:10 -0700 (PDT) Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 682A72AA04; Tue, 30 May 2000 19:54:09 -0700 (PDT) Received: (from lwei@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id TAA22658; Tue, 30 May 2000 19:53:22 -0700 (PDT) Date: Tue, 30 May 2000 19:53:22 -0700 (PDT) Message-Id: <200005310253.TAA22658@malt.redback.com> From: Liming Wei To: fenner@research.att.com Cc: dino@procket.com, pim@catarina.usc.edu In-reply-to: <200005310009.RAA13694@windsor.research.att.com> (message from Bill Fenner on Tue, 30 May 2000 17:09:50 -0700) Subject: Re: PIM hello option DR priority Reply-To: lwei@redback.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Bill Fenner > Cc: pim@catarina.usc.edu > > It feels to me like people are missing the fact that the value of > 19 for DR-Priority was published for 19 months. That is a pretty > large window for people to implement. (The first spec renumbering > it to 18 was only published 7 months ago.) Hmmm, Bill, have you bought the wrong stock at the wrong time :-) ? How does repeating this help the current situation ? The updated PIM-SM draft was posted on the WG mailing list a couple of times way before it was sent into the repository. The DR priority draft expired a long time ago. The first time the updated PIM-SM draft was posted on the PIM WG list could be early 1999 (or even late 98). Plus, all IDs have the following disclaimer (Tom, this is only to remind Bill): 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. I assume the above only applies to non-expired drafts. Again, if we were aware of ANY implementations outside of cisco... -Liming From owner-pim@catarina.usc.edu Wed May 31 02:17:54 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00709 for ; Wed, 31 May 2000 02:17:54 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id XAA83410 for pim-list; Tue, 30 May 2000 23:10:59 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id XAA83405 for ; Tue, 30 May 2000 23:10:58 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id XAA06207 for ; Tue, 30 May 2000 23:10:41 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 0539D4CE2C; Wed, 31 May 2000 02:08:55 -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 CAA12424; Wed, 31 May 2000 02:08:54 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id XAA15608; Tue, 30 May 2000 23:07:20 -0700 (PDT) Message-Id: <200005310607.XAA15608@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: lwei@redback.com Subject: Re: PIM hello option DR priority Cc: pim@catarina.usc.edu Date: Tue, 30 May 2000 23:07:19 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk Let's step back a little and see if we have rough consensus on Liming's original option #3: 3) Deprecate the current Bi-Dir option code 19, making it the DR priority election priority code again. Make code 18 an invalid option, and reassign a new code for Bi-Dir option From the discussion on the mailing list so far, it's my opinion that there's rough consensus on this so the rest of the discussion is irrelevant. Bill From owner-pim@catarina.usc.edu Wed May 31 02:34:12 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00837 for ; Wed, 31 May 2000 02:34:12 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id XAA83588 for pim-list; Tue, 30 May 2000 23:27:18 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id XAA83583 for ; Tue, 30 May 2000 23:27:17 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id XAA11899 for ; Tue, 30 May 2000 23:27:17 -0700 (PDT) Received: (from ycai@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA00785; Tue, 30 May 2000 23:23:23 -0700 (PDT) Date: Tue, 30 May 2000 23:23:23 -0700 (PDT) Message-Id: <200005310623.XAA00785@omega.cisco.com> From: Yiqun Cai To: fenner@research.att.com CC: lwei@redback.com, pim@catarina.usc.edu In-reply-to: <200005310607.XAA15608@windsor.research.att.com> (message from Bill Fenner on Tue, 30 May 2000 23:07:19 -0700) Subject: Re: PIM hello option DR priority Reply-to: ycai@cisco.com Sender: owner-pim@catarina.usc.edu Precedence: bulk Bill, I disagree. This option doesn't address all the backward interop issues. The discussion is still open, IMO. > > > Let's step back a little and see if we have rough consensus on Liming's > original option #3: > > 3) Deprecate the current Bi-Dir option code 19, making it the > DR priority election priority code again. Make code 18 an > invalid option, and reassign a new code for Bi-Dir option > > From the discussion on the mailing list so far, it's my opinion that > there's rough consensus on this so the rest of the discussion is > irrelevant. > > Bill > > -- Yiqun From owner-pim@catarina.usc.edu Wed May 31 03:00:58 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00989 for ; Wed, 31 May 2000 03:00:56 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id XAA83885 for pim-list; Tue, 30 May 2000 23:55:08 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id XAA83880 for ; Tue, 30 May 2000 23:55:06 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id XAA14418 for ; Tue, 30 May 2000 23:55:06 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 4DA044CE71; Wed, 31 May 2000 02:53:05 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id CAA14840; Wed, 31 May 2000 02:53:04 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id XAA16040; Tue, 30 May 2000 23:51:28 -0700 (PDT) Message-Id: <200005310651.XAA16040@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ycai@cisco.com Subject: Re: PIM hello option DR priority Cc: pim@catarina.usc.edu Date: Tue, 30 May 2000 23:51:28 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk >I disagree. This option doesn't address all the backward interop >issues. The discussion is still open, IMO. What are the options, as you see it? Liming's message listed: 1) Deprecate both values of 19 and 18 as valid Hello options. Assign new values to both DR-prio and Bi-Dir options. Everyone needs to switch; 2) Keep the current PIM-SM option value assignment, and let those who implemented draft-ietf-idmr-pimv2-dr-priority-00.txt change their code; 3) Deprecate the current Bi-Dir option code 19, making it the DR priority election priority code again. Make code 18 an invalid option, and reassign a new code for Bi-Dir option #1 maximizes the pain for everyone, so seems like a bad idea (but perhaps the most fair). #2 is the best for cisco, and for anyone who implemented the DR-priority option after October 1999. However, since the value of #19 was the most recent value published for the DR-Priority option from March 1998 thru October 1999, it hardly seems fair to those who implemented from the best resource available to them. (The argument that the I-D was expired is, IMHO, bogus; what are people who want to implement the DR priority option *supposed* to do except use the latest information available, whether it's an expired I-D or not? Also, the assertion that the PIM-SM spec with the changed DR-Priority option assignment was posted on the PIM mailing list is not backed by the mailing list archives.) #3 is the best for people who implemented from the DR priority draft. Do you see any other options? Bill From owner-pim@catarina.usc.edu Wed May 31 12:20:10 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15427 for ; Wed, 31 May 2000 12:20:08 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA86019 for pim-list; Wed, 31 May 2000 09:11:13 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA86014 for ; Wed, 31 May 2000 09:11:12 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA28948 for ; Wed, 31 May 2000 09:11:12 -0700 (PDT) Received: (from ycai@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA08605; Wed, 31 May 2000 09:07:18 -0700 (PDT) Date: Wed, 31 May 2000 09:07:18 -0700 (PDT) Message-Id: <200005311607.JAA08605@omega.cisco.com> From: Yiqun Cai To: fenner@research.att.com CC: pim@catarina.usc.edu In-reply-to: <200005310651.XAA16040@windsor.research.att.com> (message from Bill Fenner on Tue, 30 May 2000 23:51:28 -0700) Subject: Re: PIM hello option DR priority Reply-to: ycai@cisco.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > > What are the options, as you see it? Liming's message listed: > > 1) Deprecate both values of 19 and 18 as valid Hello options. > Assign new values to both DR-prio and Bi-Dir options. Everyone > needs to switch; > > 2) Keep the current PIM-SM option value assignment, and let those > who implemented draft-ietf-idmr-pimv2-dr-priority-00.txt > change their code; > > 3) Deprecate the current Bi-Dir option code 19, making it the > DR priority election priority code again. Make code 18 an > invalid option, and reassign a new code for Bi-Dir option > > > #1 maximizes the pain for everyone, so seems like a bad idea (but perhaps > the most fair). > > #2 is the best for cisco, and for anyone who implemented the DR-priority > option after October 1999. However, since the value of #19 was the most > recent value published for the DR-Priority option from March 1998 thru > October 1999, it hardly seems fair to those who implemented from the best > resource available to them. (The argument that the I-D was expired is, > IMHO, bogus; what are people who want to implement the DR priority option > *supposed* to do except use the latest information available, whether > it's an expired I-D or not? Also, the assertion that the PIM-SM spec > with the changed DR-Priority option assignment was posted on the PIM > mailing list is not backed by the mailing list archives.) > > #3 is the best for people who implemented from the DR priority draft. > > Do you see any other options? > No, I don't see any other options. In the meantime, I don't think this is going to be an easy or painless transition, so I want to take some time to really understand all the ramfication. I hope we don't rush into any decision. To me, which option to take is not just based on the pain to the implementors. We must also consider the backward compatibility issues. After all, we implement a protocol so that people can use. BTW, in my view, #2 is at least as good as #3. -- Yiqun