From owner-pim@catarina.usc.edu Thu Jun 1 18:07:28 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 SAA05312 for ; Thu, 1 Jun 2000 18:07:27 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA92498 for pim-list; Thu, 1 Jun 2000 14:56: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 OAA92493 for ; Thu, 1 Jun 2000 14:56:12 -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 OAA20959 for ; Thu, 1 Jun 2000 14:56:11 -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 OAA06714; Thu, 1 Jun 2000 14:51:27 -0700 (PDT) Message-ID: <3936DAE5.A9A610E1@cisco.com> Date: Thu, 01 Jun 2000 14:51:33 -0700 From: John Meylor X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: lwei@redback.com, pusateri@juniper.net, fred@iprg.nokia.com, pim@catarina.usc.edu CC: jmeylor@cisco.com, multicast-coders@cisco.com Subject: Re: PIM hello option DR priority References: <200005252313.QAA06612@malt.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Liming Wei wrote: > 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 Ok, We'd like to propose the following then for resolving this: - First, we support proposal #3 (and we'll move to change our implementation to use 19 for TLV for DR priority.) Note, this will effect deployed implementations using 18 (including ours), but will resolve the deadlock on this and provide a consistant reference for all other implementations moving forward. We propose that it is up to implementation whether to interop with implementations using values other than 19 for DR priority. - Second, since 19 was also described for use by bidir in certain docs (like most recent PIM-SM draft) we would propose that we also standardize now on 22 as PIM Hello TLV option for bidir for all future implementations. - Finally, since any DR priority implementation today is based on expired documentation, and to avoid similiar confusion with other PIM Hello TLV options in the future, we propose that all PIM Hello options be specified in an information draft (we will submit this for next IETF), which can either proceed to RFC or perhaps be incorporated into the next valid PIM-SM/SSM draft, and that any ref to PIM Hello options in other drafts be updated to reflect use of 19 for DR priority and 22 for bidir, or use a reference which reflects these numbers. Anyone see problems with this approach? John From owner-pim@catarina.usc.edu Thu Jun 1 18:55: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 SAA06242 for ; Thu, 1 Jun 2000 18:55:02 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA92865 for pim-list; Thu, 1 Jun 2000 15:49: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] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA92860 for ; Thu, 1 Jun 2000 15:49:03 -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 PAA24988 for ; Thu, 1 Jun 2000 15:49:02 -0700 (PDT) Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 072892AA02; Thu, 1 Jun 2000 15:45:59 -0700 (PDT) Received: (from lwei@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id PAA29477; Thu, 1 Jun 2000 15:45:11 -0700 (PDT) Date: Thu, 1 Jun 2000 15:45:11 -0700 (PDT) Message-Id: <200006012245.PAA29477@malt.redback.com> From: Liming Wei To: jmeylor@cisco.com Cc: pusateri@juniper.net, fred@iprg.nokia.com, pim@catarina.usc.edu, jmeylor@cisco.com, multicast-coders@cisco.com In-reply-to: <3936DAE5.A9A610E1@cisco.com> (message from John Meylor on Thu, 01 Jun 2000 14:51:33 -0700) Subject: Re: PIM hello option DR priority Reply-To: lwei@redback.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > Date: Thu, 01 Jun 2000 14:51:33 -0700 > From: John Meylor > > Liming Wei wrote: > > 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 > > Ok, > We'd like to propose the following then for resolving this: > > - First, we support proposal #3 (and we'll move to change our > implementation to use 19 for TLV for DR priority.) Note, this > will effect deployed implementations using 18 (including ours), > but will resolve the deadlock on this and provide a consistant > reference for all other implementations moving forward. > > We propose that it is up to implementation whether to interop > with implementations using values other than 19 for DR priority. > > - Second, since 19 was also described for use by bidir in certain docs > (like most recent PIM-SM draft) we would propose that we also > standardize now on 22 as PIM Hello TLV option for bidir for all > future implementations. Good. I expect this to be acceptable to most folks. > > - Finally, since any DR priority implementation today is based on > expired documentation, and to avoid similiar confusion with other PIM > Hello TLV options in the future, we propose that all PIM Hello options > be specified in an information draft (we will submit this for next > IETF), which can either proceed to RFC or perhaps be incorporated into > the next valid PIM-SM/SSM draft, and that any ref to PIM Hello options > in other drafts be updated to reflect use of 19 for DR priority > and 22 for bidir, or use a reference which reflects these numbers. I'd suggest to go one step further. I think this should be incorporated into the exsiting spec, and Yiqun should submit the existing PIM-SM spec with this update as an informational RFC (with minimal editorial work). This will be useful after the current spec has expired, and a complete re-written new spec shows up. Comments ? -Liming From owner-pim@catarina.usc.edu Thu Jun 1 19:47: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 TAA07073 for ; Thu, 1 Jun 2000 19:47:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA93326 for pim-list; Thu, 1 Jun 2000 16:40: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 QAA93321 for ; Thu, 1 Jun 2000 16:40:40 -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 QAA26840 for ; Thu, 1 Jun 2000 16:40:39 -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 QAA12882; Thu, 1 Jun 2000 16:36:16 -0700 (PDT) Message-ID: <3936F376.AD4D1D1E@cisco.com> Date: Thu, 01 Jun 2000 16:36:22 -0700 From: John Meylor X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: lwei@redback.com CC: pusateri@juniper.net, fred@iprg.nokia.com, pim@catarina.usc.edu, multicast-coders@cisco.com Subject: Re: PIM hello option DR priority References: <200006012245.PAA29477@malt.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Liming Wei wrote: > > > - Finally, since any DR priority implementation today is based on > > expired documentation, and to avoid similiar confusion with other PIM > > Hello TLV options in the future, we propose that all PIM Hello options > > be specified in an information draft (we will submit this for next > > IETF), which can either proceed to RFC or perhaps be incorporated into > > the next valid PIM-SM/SSM draft, and that any ref to PIM Hello options > > in other drafts be updated to reflect use of 19 for DR priority > > and 22 for bidir, or use a reference which reflects these numbers. > > I'd suggest to go one step further. I think this should be > incorporated into the exsiting spec, and Yiqun should submit the > existing PIM-SM spec with this update as an informational RFC (with > minimal editorial work). This will be useful after the current spec > has expired, and a complete re-written new spec shows up. > > Comments ? I believe at the last IETF the decision was to have Hugh/Bill/Mark others proceed on new PIM-SM draft which includes SSM descriptions as well new re-write of PIM-SM thus addressing some of issues in existing PIM-SM draft. I believe a first draft may be available at next IETF (I'll let aurhors speak on that), but if so, then that might be useful location for listing PIM Hello options. John From owner-pim@catarina.usc.edu Thu Jun 1 23:01: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 XAA11250 for ; Thu, 1 Jun 2000 23:01:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA94208 for pim-list; Thu, 1 Jun 2000 19:55:43 -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 TAA94203 for ; Thu, 1 Jun 2000 19:55:41 -0700 (PDT) Received: from pc39138.comtranet.com (pc39138.comtranet.com [207.88.39.138] (may be forged)) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA01313 for ; Thu, 1 Jun 2000 19:55:41 -0700 (PDT) Received: from pc39138.comtranet.com (127.0.0.1) by pc39138.comtranet.com with ESMTP (Eudora Internet Mail Server 2.2.2); Thu, 1 Jun 2000 19:47:55 -0700 Mime-Version: 1.0 X-Sender: maufer@mail.nova.org Message-Id: In-Reply-To: <3936DAE5.A9A610E1@cisco.com> References: <200005252313.QAA06612@malt.redback.com> <3936DAE5.A9A610E1@cisco.com> Date: Thu, 1 Jun 2000 19:47:39 -0700 To: John Meylor From: Thomas Maufer Subject: Re: PIM hello option DR priority Cc: lwei@redback.com, pusateri@juniper.net, fred@iprg.nokia.com, pim@catarina.usc.edu, jmeylor@cisco.com, multicast-coders@cisco.com Content-Type: text/plain; charset="us-ascii" Sender: owner-pim@catarina.usc.edu Precedence: bulk At 14:51 -0700 2000-06-01, John Meylor wrote: >- Finally, since any DR priority implementation today is based on >expired documentation, and to avoid similiar confusion with other PIM >Hello TLV options in the future, we propose that all PIM Hello options >be specified in an information draft (we will submit this for next >IETF), which can either proceed to RFC or perhaps be incorporated into >the next valid PIM-SM/SSM draft, and that any ref to PIM Hello options >in other drafts be updated to reflect use of 19 for DR priority >and 22 for bidir, or use a reference which reflects these numbers. > >Anyone see problems with this approach? John-- Not a problem, but a document would be perpetually out of date. Why not document all current (agreed- on) values and then pass the info to IANA and let them administer the Hello Option value space? My $0.005, Tom -- Thomas Maufer It's never too late to be |o| what you might have been. |o| PGP Key Fingerprint (DSS): -- George Eliot |o| 0E37 CE46 9D05 63C5 BD8C |o| 1242 5240 843D A36B FEB1 _________________________________________ | From owner-pim@catarina.usc.edu Thu Jun 1 23:12:20 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 XAA11346 for ; Thu, 1 Jun 2000 23:12:19 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id UAA94307 for pim-list; Thu, 1 Jun 2000 20:08: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 UAA94302 for ; Thu, 1 Jun 2000 20:08:18 -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 UAA05843 for ; Thu, 1 Jun 2000 20:08:18 -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 UAA21850; Thu, 1 Jun 2000 20:03:24 -0700 (PDT) Message-ID: <39372402.1D6B2708@cisco.com> Date: Thu, 01 Jun 2000 20:03:30 -0700 From: John Meylor X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Maufer CC: lwei@redback.com, pusateri@juniper.net, fred@iprg.nokia.com, pim@catarina.usc.edu, multicast-coders@cisco.com Subject: Re: PIM hello option DR priority References: <200005252313.QAA06612@malt.redback.com> <3936DAE5.A9A610E1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Maufer wrote: > > At 14:51 -0700 2000-06-01, John Meylor wrote: > >- Finally, since any DR priority implementation today is based on > >expired documentation, and to avoid similiar confusion with other PIM > >Hello TLV options in the future, we propose that all PIM Hello options > >be specified in an information draft (we will submit this for next > >IETF), which can either proceed to RFC or perhaps be incorporated into > >the next valid PIM-SM/SSM draft, and that any ref to PIM Hello options > >in other drafts be updated to reflect use of 19 for DR priority > >and 22 for bidir, or use a reference which reflects these numbers. > > > >Anyone see problems with this approach? > > John-- > > Not a problem, but a document would be perpetually > out of date. Why not document all current (agreed- > on) values and then pass the info to IANA and let > them administer the Hello Option value space? > > My $0.005, yes, I understand this was also proposed during talks about the new PIM-SSM/SM draft, so perhaps the authors have more recent insight on this approach. I think its excellent idea. John From owner-pim@catarina.usc.edu Thu Jun 8 13:44: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 NAA12820 for ; Thu, 8 Jun 2000 13:44:45 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA31700 for pim-list; Thu, 8 Jun 2000 09:47: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] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA31681 for ; Thu, 8 Jun 2000 09:47:14 -0700 (PDT) From: zainprov@swbell.net Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA02291 for ; Thu, 8 Jun 2000 09:47:14 -0700 (PDT) Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00D3BFA52U@mta5.rcsntx.swbell.net> for pim@catarina.usc.edu; Thu, 8 Jun 2000 11:05:49 -0500 (CDT) Date: Thu, 08 Jun 2000 11:05:49 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: pim@catarina.usc.edu Message-id: <0FVU00DJRFDM2U@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson From owner-pim@catarina.usc.edu Thu Jun 8 15:22: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 PAA14841 for ; Thu, 8 Jun 2000 15:22:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA32791 for pim-list; Thu, 8 Jun 2000 12:14: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 MAA32786 for ; Thu, 8 Jun 2000 12:14:49 -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 MAA20131 for ; Thu, 8 Jun 2000 12:14:46 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 09 Jun 2000 00:53:13 +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 AAA20908 for ; Fri, 9 Jun 2000 00:43:45 +0530 Received: by localhost with Microsoft MAPI; Fri, 9 Jun 2000 00:48:24 +0530 Message-Id: <01BFD1AC.6AAD8500.sabaris@future.futsoft.com> From: sabarivel s To: "'pim-implementors'" Subject: doubts regarding Pimsm (CRPs) Date: Fri, 9 Jun 2000 00:48:23 +0530 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BFD1AC.6AB6ACC0" Sender: owner-pim@catarina.usc.edu Precedence: bulk ------ =_NextPart_000_01BFD1AC.6AB6ACC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit hi, i have some doubts regarding the Candidate RPs 1) RFC 2362 section 3.6.1 states that the "C-RPs should send C-RP-Adv messages with the prioirity field set to zero". If so , what is the use of the candidate RP priority ? 2) In the section 3.6.2 it states that "the BSR may override the prefix indicated in a C-RP-Adv unless the priority field is not zero". As per the previous statement if the candidate rps sends the CRP message with priroity field set to zero, where does the above situtation arise ? then what does it mean by overriding the prefix ? 3) in the section 3.6.1 what does the statement " the advertising router may enfore this scope acceptance when receiveing register or join/prune messages " mean ? thanks in advance with regards sabaris ------ =_NextPart_000_01BFD1AC.6AB6ACC0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhgTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYArAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbwAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAAAf8W+6YxtIRnF4AIDVD 616EjQAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAcGltLWltcGxlbWVudG9ycwBTTVRQAHBpbUBj YXRhcmluYS51c2MuZWR1AAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAFQAAAHBpbUBjYXRh cmluYS51c2MuZWR1AAAAAAMAFQwBAAAAAwD+DwYAAAAeAAEwAQAAABMAAAAncGltLWltcGxlbWVu dG9ycycAAAIBCzABAAAAGgAAAFNNVFA6UElNQENBVEFSSU5BLlVTQy5FRFUAAAADAAA5AAAAAAsA QDoBAAAAHgD2XwEAAAARAAAAcGltLWltcGxlbWVudG9ycwAAAAACAfdfAQAAACwAAAC/AAAAtTvC wCx3EBqhvAgAKypWwhUAAAAH/FvumMbSEZxeACA1Q+tehI0AAAMA/V8BAAAAAwD/XwAAAAACAfYP AQAAAAQAAAAAAAACeFwBBIABAB4AAABkb3VidHMgcmVnYXJkaW5nIFBpbXNtIChDUlBzKQBTCgEF gAMADgAAANAHBgAJAAAAMAAXAAUAMgEBIIADAA4AAADQBwYACQAAACQAEwAFACIBAQmAAQAhAAAA MzA0RkQ4MDE5RDNERDQxMUIzRUEwMDYwOTQwQ0Q1QTIAFQcBA5AGAJwFAAAgAAAACwACAAEAAAAL ACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAEAAOQBABjVQftG/AR4AcAABAAAAHgAAAGRv dWJ0cyByZWdhcmRpbmcgUGltc20gKENSUHMpAAAAAgFxAAEAAAAWAAAAAb/RflAkAdhPNj2dEdSz 6gBglAzVogAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAABsAAABzYWJhcmlzQGZ1dHVyZS5m dXRzb2Z0LmNvbQAAAwAGEPT9lHEDAAcQZgIAAB4ACBABAAAAZQAAAEhJLElIQVZFU09NRURPVUJU U1JFR0FSRElOR1RIRUNBTkRJREFURVJQUzEpUkZDMjM2MlNFQ1RJT04zNjFTVEFURVNUSEFUVEhF IkMtUlBTU0hPVUxEU0VOREMtUlAtQURWTUUAAAAAAgEJEAEAAAB7AgAAdwIAAPADAABMWkZ1lruV /gMACgByY3BnMTI1FjIA+Atgbg4QMDMznQH3IAKkA+MCAGNoCsBgc2V0MCAHEwKAfTkKgXVjAFAL Awu1IGiMaSwKogqAICBpEzBgYXZlIHMDcBRAZNkIYGJ0BCAJcGcLEQuA0GcgdGgUQEMAcBVwyGRh dBRAUlAQwBODCRbaMSkT0FJGQyAwMjM2MhRQBZB0aYECICAzLjYuMRRQPwGQFnAEIBXAFmAVsyJD li0WoRRQaAhgbGQYsQcWIBXwGsEtQWR2IPEHgXNhZweRA/AVwBWzEnAFEG9pBRB0eSA+ZgiQG1ET dBExFbBvICJ6BJBvIi4TdUlmeRRRICwc4BoiBAAVs3XZETAgbyAwFcJjFhkdc6Ud0z8W3woyGABJ A6BfFcIYyhigHQAZmyIVwkJUU1IcUGEeAG8UMHLPBRABAB01ARBpeBPgFiFPIhAWcBtgC4AgYRvI dTxubBxxHTcd2SDxbm/XBUAfWhN0QQQgcASQKGb+dhkAIWAZlAeAAjAT4CG+3HJwGvEbkSEEQyKx HGX/HOQdgQNgHege6RNlIKAEkH8UkhnjFEABoCfhFFAdAHX/GbEZAgrABAAUQCN7FcEDoN8gozUj JiEHgAORYifHFYb7KLUjezMYACnBJQ4ZgDhI+yUDLyciNWQcMASQGPAAkP8VkQNgNkAuESeiCfAC EDTxNxXAIPEE8G8uACngY2P+ZQUwAHBB0CCROBEJcEHQfmkUMD+jFTAEAEASBbFq+R2wbi8dgCqg FEAcZz7A7zkTI3830gBwazjBKdEcML9CEjRlHQIVJBbFHJBiNsIvRe8TwR51EfEAS/AAAwAQEAAA AAADABEQAAAAAAMAgBD/////QAAHMCDM4KB80b8BQAAIMCDM4KB80b8BCwAAgAggBgAAAAAAwAAA AAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAIIAYA AAAAAMAAAAAAAABGAAAAAFKFAADzFQAAAwAJgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAAe ABCACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAA4LjA0AAAAAAsAEYAIIAYAAAAAAMAA AAAAAABGAAAAAA6FAAAAAAAAAwASgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADABOACCAG AAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4AFIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAA AQAAAAAAAAAeABWACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAWgAggBgAA AAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAAAQAAAAAAAAADAA00/TcAAAw4 ------ =_NextPart_000_01BFD1AC.6AB6ACC0-- From owner-pim@catarina.usc.edu Thu Jun 8 15:53:31 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 PAA15373 for ; Thu, 8 Jun 2000 15:53:30 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA33041 for pim-list; Thu, 8 Jun 2000 12:44:23 -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 MAA33036 for ; Thu, 8 Jun 2000 12:44:22 -0700 (PDT) Received: from dthaler.microsoft.com ([131.107.152.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA09115 for ; Thu, 8 Jun 2000 12:44:21 -0700 (PDT) Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id OAA18912; Thu, 8 Jun 2000 14:14:00 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <200006082114.OAA18912@dthaler.microsoft.com> Subject: Re: doubts regarding Pimsm (CRPs) In-Reply-To: <01BFD1AC.6AAD8500.sabaris@future.futsoft.com> from sabarivel s at "Jun 9, 2000 0:48:23 am" To: sabaris@future.futsoft.com (sabarivel s) Date: Thu, 8 Jun 2000 14:13:59 -0700 (PDT) Cc: pim@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > i have some doubts regarding the Candidate RPs > > > 1) RFC 2362 section 3.6.1 states that the "C-RPs should send C-RP-Adv > messages with the prioirity field > set to zero". > If so , what is the use of the candidate RP priority ? If prefixes are allocated to domains (e.g. via MASC or GLOP or IPv6 prefix-style addressing), border routers will send C-RP-Advs with non-zero priority for ranges which are reached through them. This is not part of the base PIM-SM spec. Only the required behavior of internal PIM-SM routers, BSRs, etc is discussed. > 2) In the section 3.6.2 it states that "the BSR may override the prefix > indicated in a C-RP-Adv unless the priority field is not zero". > > As per the previous statement if the candidate rps sends the CRP message > with priroity field set to zero, > where does the above situtation arise ? > > then what does it mean by overriding the prefix ? The BSR is always free to override normal C-RP-Advs by say static configuration to apply to whatever subset of groups it wants them to. This should not be a normal situation though. > 3) in the section 3.6.1 what does the statement " the advertising router > may enfore this scope acceptance when receiveing register or join/prune > messages " mean ? I believe it means an RP can drop Registers for groups it didn't claim to be an RP for (in which case a BSR should only be narrowing the range of groups for which a given RP is valid, not arbitrarily changing it). > thanks in advance > with regards > sabaris -Dave From owner-pim@catarina.usc.edu Thu Jun 8 23:11:59 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 XAA22933 for ; Thu, 8 Jun 2000 23:11:59 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id UAA34942 for pim-list; Thu, 8 Jun 2000 20:04: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 UAA34937 for ; Thu, 8 Jun 2000 20:04:17 -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 UAA07636 for ; Thu, 8 Jun 2000 20:04:17 -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 9FC8C1E006; Thu, 8 Jun 2000 23:02:11 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id XAA15457; Thu, 8 Jun 2000 23:02:10 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id UAA13582; Thu, 8 Jun 2000 20:00:28 -0700 (PDT) Message-Id: <200006090300.UAA13582@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: braden@isi.edu Subject: Re: PIM Dense Mode: where is it documented? Cc: pim@catarina.usc.edu, idmr@cs.ucl.ac.uk, jkrey@isi.edu, bart@comglobal.com Reply-To: pim@catarina.usc.edu Date: Thu, 8 Jun 2000 20:00:27 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk Bob, This question probably belongs on the PIM mailing list, to which I've directed replies. PIM-DM has never been submitted for publication as RFC. The Dense Mode spec was submitted for PIM WG Last Call in November 1999; a list of issues were raised on the mailing list but have not yet been addressed. The draft (draft-ietf-pim-v2-dm-03.txt) expired in December 1999. It's not clear if any of the spec authors have any interest in continued work on PIM-DM. Bill From owner-pim@catarina.usc.edu Fri Jun 9 02:30:08 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 CAA06234 for ; Fri, 9 Jun 2000 02:30:06 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id XAA35537 for pim-list; Thu, 8 Jun 2000 23:23:39 -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 XAA35532 for ; Thu, 8 Jun 2000 23:23:38 -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 XAA27208 for ; Thu, 8 Jun 2000 23:23:33 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 09 Jun 2000 12:02:44 +0530 Received: from subraln ([10.0.14.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA30019; Fri, 9 Jun 2000 11:52:16 +0530 Received: by localhost with Microsoft MAPI; Fri, 9 Jun 2000 11:56:57 +0530 Message-Id: <01BFD209.CFF769A0.subraln@future.futsoft.com> From: Subramaniam L N Reply-To: "subraln@future.futsoft.com" To: "'Dave Thaler'" Cc: "'pim@catarina.usc.edu'" Subject: RE: doubts regarding Pimsm (CRPs) Date: Fri, 9 Jun 2000 11:56:56 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-pim@catarina.usc.edu Precedence: bulk -----Original Message----- From: Dave Thaler [SMTP:dthaler@dthaler.microsoft.com] Sent: Friday, 9 June 2000 2:44 AM To: sabarivel s Cc: pim@catarina.usc.edu Subject: Re: doubts regarding Pimsm (CRPs) > i have some doubts regarding the Candidate RPs > > > 1) RFC 2362 section 3.6.1 states that the "C-RPs should send C-RP-Adv > messages with the prioirity field > set to zero". > If so , what is the use of the candidate RP priority ? If prefixes are allocated to domains (e.g. via MASC or GLOP or IPv6 prefix-style addressing), border routers will send C-RP-Advs with non-zero priority for ranges which are reached through them. This is not part of the base PIM-SM spec. Only the required behavior of internal PIM-SM routers, BSRs, etc is discussed. > 2) In the section 3.6.2 it states that "the BSR may override the prefix > indicated in a C-RP-Adv unless the priority field is not zero". > > As per the previous statement if the candidate rps sends the CRP message > with priroity field set to zero, > where does the above situtation arise ? > > then what does it mean by overriding the prefix ? The BSR is always free to override normal C-RP-Advs by say static configuration to apply to whatever subset of groups it wants them to. This should not be a normal situation though. > 3) in the section 3.6.1 what does the statement " the advertising router > may enfore this scope acceptance when receiveing register or join/prune > messages " mean ? I believe it means an RP can drop Registers for groups it didn't claim to be an RP for (in which case a BSR should only be narrowing the range of groups for which a given RP is valid, [Subramaniam L N] Bootstrap Mechanism was introduced to have a consistent view of RP for each group in the domain. If it is so, then how a router could receive a Register Message, without being the RP, for Group in the Register Message? > thanks in advance > with regards > sabaris -Dave From owner-pim@catarina.usc.edu Fri Jun 9 10:37: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 KAA12341 for ; Fri, 9 Jun 2000 10:37:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA37230 for pim-list; Fri, 9 Jun 2000 07:31: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]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA37225 for ; Fri, 9 Jun 2000 07:31:57 -0700 (PDT) Received: from backin5.merit.edu (backin5.merit.edu [198.108.60.28]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA09456 for ; Fri, 9 Jun 2000 07:31:56 -0700 (PDT) Received: from merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by backin5.merit.edu (Postfix) with ESMTP id 250D57E506; Fri, 9 Jun 2000 10:25:56 -0400 (EDT) Message-ID: <3940FE17.A6D66DE1@merit.edu> Date: Fri, 09 Jun 2000 10:24:23 -0400 From: "Andrew L. Adams" X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: pim@catarina.usc.edu Cc: ala@merit.edu Subject: RP holdtimes in BSR messages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all. Can someone explain to me the purpose of the RP-holdtimes that are advertised in BSR messages? My understanding from the latest draft is that they aren't used by anyone. The only routers interested in RP-holdtimes are BSR's, and those holdtimes are read from CRP-Adv messages. For a BSR, if a CRP doesn't send a CRP-Adv message before the RP-holdtime expires, then that CRP is not advertised in the next BSR message....And all other routers are supposed to _replace_ their RP set with the set received in a new BSR message. (As opposed to set/refresh hold-timers for RP's learned from the BSR message.) A description of the holdtime field in the BSR packet doesn't accompany the BSR packet format description in section 4.6. The only mention of it that I can find (relating to the BSR message) is in 3.6.2 The Bootstrap message is subdivided into sets of group-prefix,RP- Count,RP-addresses. For each RP-address, the corresponding Holdtime is included in the "RP-Holdtime" field. Thanks for any help, -Andy From owner-pim@catarina.usc.edu Fri Jun 9 14:46: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 OAA17118 for ; Fri, 9 Jun 2000 14:46:06 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA38294 for pim-list; Fri, 9 Jun 2000 11:33: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]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA38289 for ; Fri, 9 Jun 2000 11:33:44 -0700 (PDT) Received: from nectar.attlabs.att.com (gatemp.attlabs.net [135.197.1.2]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA28075 for ; Fri, 9 Jun 2000 11:33:43 -0700 (PDT) Received: (from fenner@localhost) by nectar.attlabs.att.com (8.9.3/8.9.2) id SAA07126 for pim@catarina.usc.edu; Thu, 8 Jun 2000 18:35:37 -0700 (PDT) (envelope-from fenner) Date: Thu, 8 Jun 2000 18:35:37 -0700 (PDT) From: Bill Fenner Message-Id: <200006090135.SAA07126@nectar.attlabs.att.com> To: pim@catarina.usc.edu Subject: A modest proposal: get rid of (*,*,RP) state Sender: owner-pim@catarina.usc.edu Precedence: bulk Dear PIM'ers, As part of our rewrite of the PIM-SM spec, we would like to get rid of (*,*,RP) state. It was introduced for interoperability with dense-mode protocols in the "upside-down" mode of a dense-mode backbone and PIM-SM stubs. In today's Internet, this mode doesn't exist, and MSDP and Domain-Wide Reports are a much better way to attach a dense-mode stub site. Given this, we'd like to ask the following questions: 1) Does anyone handle receiving and propagating (*,*,RP) joins? 2) Does anyone implement the PMBR functionality that initiates (*,*,RP) joins? 3) Most importantly, does anyone have any objections to eliminating the (*,*,RP) functionality? Thanks, Bill & Mark & Hugh & Isidor From owner-pim@catarina.usc.edu Fri Jun 9 15:47: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 PAA18107 for ; Fri, 9 Jun 2000 15:47:14 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA38978 for pim-list; Fri, 9 Jun 2000 12:39: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 MAA38973 for ; Fri, 9 Jun 2000 12:39:40 -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 MAA19064 for ; Fri, 9 Jun 2000 12:39:39 -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 MAA24877; Fri, 9 Jun 2000 12:37:49 -0700 (PDT) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id MAA21893; Fri, 9 Jun 2000 12:37:48 -0700 (PDT) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200006091937.MAA21893@garnet.juniper.net> To: Bill Fenner cc: pim@catarina.usc.edu, pusateri@juniper.net Subject: Re: A modest proposal: get rid of (*,*,RP) state In-Reply-To: Message from Bill Fenner of "Thu, 08 Jun 2000 18:35:37 PDT." <200006090135.SAA07126@nectar.attlabs.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21890.960579468.1@garnet.juniper.net> Date: Fri, 09 Jun 2000 12:37:48 -0700 From: Tom Pusateri Sender: owner-pim@catarina.usc.edu Precedence: bulk In message <200006090135.SAA07126@nectar.attlabs.att.com> you write: > Given this, we'd like to ask the following questions: >1) Does anyone handle receiving and propagating (*,*,RP) joins? Juniper does not. >2) Does anyone implement the PMBR functionality that initiates > (*,*,RP) joins? Juniper does not. >3) Most importantly, does anyone have any objections to eliminating > the (*,*,RP) functionality? No objections. Thanks, Tom From owner-pim@catarina.usc.edu Fri Jun 9 16:13:23 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 QAA18355 for ; Fri, 9 Jun 2000 16:13:23 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA39220 for pim-list; Fri, 9 Jun 2000 13:00: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] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA39215 for ; Fri, 9 Jun 2000 13:00:08 -0700 (PDT) Received: from mailhost.avici.com ([208.246.215.9]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA00491 for ; Fri, 9 Jun 2000 12:59:46 -0700 (PDT) Received: from avici.com (loke-pc.avici.com [10.1.2.227]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id PAA15841; Fri, 9 Jun 2000 15:55:27 -0400 (EDT) Message-ID: <39414BAE.6256C3B2@avici.com> Date: Fri, 09 Jun 2000 15:55:26 -0400 From: Swee Loke X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "pim@catarina.usc.edu" CC: loke@avici.com Subject: More question on RP Holdtime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Andrew raised a good question. The draft doesn't seem to specify the usage of RP holdtime for non-BSR. In order to allow fragmented BSR message to work properly, I think some sort of holdtime/timeout for the Group/RP set is required. We probably should specify this in the draft. Based on the draft, if an RP is not included in the new BSR message's RP-set, it is concluded (by the non-BSR) not reachable (section 3.6.3). When a router receives the first fragment of a fragmented BSR message, should it time out all the G/RP-sets that are NOT included in the first fragment? The BSR message doesn't indicate if a BSR message is fragmented, so the router doesn't know if this is all, or more fragments are coming. (The fragment tag is only used to identify different BSR messages). If we time out everything that is NOT included in a BSR message, then when a bsr message is fragmented, we are always timing out things too soon - before they have a chance to be refreshed. If we don't timeout everything right away, what should the holdtime be? I guess the RP holdtime can be used here. :-) Thanks, swee From owner-pim@catarina.usc.edu Fri Jun 9 16:41: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 QAA18623 for ; Fri, 9 Jun 2000 16:41:05 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA39582 for pim-list; Fri, 9 Jun 2000 13:34:14 -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 NAA39577 for ; Fri, 9 Jun 2000 13:34:12 -0700 (PDT) Received: from agni.iprg.nokia.com (agni.iprg.nokia.com [205.226.8.100]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA20821 for ; Fri, 9 Jun 2000 13:34:11 -0700 (PDT) Received: from agni.iprg.nokia.com (localhost.iprg.nokia.com [127.0.0.1]) by agni.iprg.nokia.com (8.9.3/8.9.3) with ESMTP id NAA15795; Fri, 9 Jun 2000 13:32:33 -0700 (PDT) (envelope-from ravi@agni.iprg.nokia.com) Message-Id: <200006092032.NAA15795@agni.iprg.nokia.com> To: pim@catarina.usc.edu cc: Bill Fenner Subject: Re: A modest proposal: get rid of (*,*,RP) state In-Reply-To: Your message of "Fri, 09 Jun 2000 12:37:48 PDT." <200006091937.MAA21893@garnet.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15792.960582753.1@agni.iprg.nokia.com> Date: Fri, 09 Jun 2000 13:32:33 -0700 From: Ravi Puvvala Sender: owner-pim@catarina.usc.edu Precedence: bulk | In message <200006090135.SAA07126@nectar.attlabs.att.com> you write: | > Given this, we'd like to ask the following questions: | >1) Does anyone handle receiving and propagating (*,*,RP) joins? We (Nokia) do support this option. | >2) Does anyone implement the PMBR functionality that initiates | > (*,*,RP) joins? We do not currently have this support. | >3) Most importantly, does anyone have any objections to eliminating | > the (*,*,RP) functionality? No problem.. In lieu of DWR and MSDP, I think this is the right thing to do. Ravi From owner-pim@catarina.usc.edu Fri Jun 9 17:13:19 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 RAA18885 for ; Fri, 9 Jun 2000 17:13:18 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA40129 for pim-list; Fri, 9 Jun 2000 14:07:27 -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 OAA40124 for ; Fri, 9 Jun 2000 14:07:26 -0700 (PDT) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA11426 for ; Fri, 9 Jun 2000 14:07:25 -0700 (PDT) Received: from bacardi.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by bacardi.torrentnet.com (8.9.2/8.9.2) with ESMTP id RAA20026; Fri, 9 Jun 2000 17:06:36 -0400 (EDT) Message-Id: <200006092106.RAA20026@bacardi.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bill Fenner cc: pim@catarina.usc.edu Subject: Re: A modest proposal: get rid of (*,*,RP) state In-reply-to: Your message of "Thu, 08 Jun 2000 18:35:37 PDT." <200006090135.SAA07126@nectar.attlabs.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jun 2000 17:06:36 -0400 From: Chirayu Shah Sender: owner-pim@catarina.usc.edu Precedence: bulk > Given this, we'd like to ask the following questions: >1) Does anyone handle receiving and propagating (*,*,RP) joins? Ericsson (Torrent) does not support it. >2) Does anyone implement the PMBR functionality that initiates > (*,*,RP) joins? We do not. >3) Most importantly, does anyone have any objections to eliminating > the (*,*,RP) functionality? No objection from our side. > >Thanks, > Bill & Mark & Hugh & Isidor Chirayu. From owner-pim@catarina.usc.edu Fri Jun 9 17:28: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 RAA19003 for ; Fri, 9 Jun 2000 17:28:50 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA40298 for pim-list; Fri, 9 Jun 2000 14:21: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]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA40293 for ; Fri, 9 Jun 2000 14:21:44 -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 OAA20746 for ; Fri, 9 Jun 2000 14:21:40 -0700 (PDT) Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2000 17:23:02 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C7C4770@uniwest1.redstonecom.com> From: "Shekhar, Ravi" To: Bill Fenner , pim@catarina.usc.edu Subject: RE: A modest proposal: get rid of (*,*,RP) state Date: Fri, 9 Jun 2000 17:22:58 -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 > Dear PIM'ers, > > As part of our rewrite of the PIM-SM spec, we would like to get > rid of (*,*,RP) state. It was introduced for interoperability with > dense-mode protocols in the "upside-down" mode of a dense-mode > backbone and PIM-SM stubs. In today's Internet, this mode doesn't > exist, and MSDP and Domain-Wide Reports are a much better way to > attach a dense-mode stub site. > > Given this, we'd like to ask the following questions: > 1) Does anyone handle receiving and propagating (*,*,RP) joins? > 2) Does anyone implement the PMBR functionality that initiates > (*,*,RP) joins? Yes, we support both of these. > 3) Most importantly, does anyone have any objections to eliminating > the (*,*,RP) functionality? I agree that DWR is a better way. But my only concern is how widely is it being used, especially in the existing dense mode stub areas like enterprises. I know of at least one vendor which has only PIM-DM and does not have support for DWR. All such enterprises would need to add DWR supporting router interfaces on all of their internal LANs to transition to DWR. If I understand it right, the <*, *, RP> mechanism as stated in current PIM draft has its limitations. It allows pruning of only 254 different groups from a given RP after joining a <*, *, RP>. But I doubt if this would be a serious limitation. Are there other good reasons to not include <*, *, RP> in protocol specification? Perhaps implementation of <*, *, RP> can be made optional (detected through hello options). - Ravi Shekhar. > > Thanks, > Bill & Mark & Hugh & Isidor > From owner-pim@catarina.usc.edu Fri Jun 9 17:51:30 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 RAA19238 for ; Fri, 9 Jun 2000 17:51:30 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA40566 for pim-list; Fri, 9 Jun 2000 14:45: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]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA40561 for ; Fri, 9 Jun 2000 14:45:28 -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 OAA07596 for ; Fri, 9 Jun 2000 14:45:27 -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 F3B701E02E; Fri, 9 Jun 2000 17:42:56 -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 RAA04996; Fri, 9 Jun 2000 17:42:56 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA20515; Fri, 9 Jun 2000 14:41:14 -0700 (PDT) Message-Id: <200006092141.OAA20515@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rshekhar@unispheresolutions.com Subject: RE: A modest proposal: get rid of (*,*,RP) state Cc: pim@catarina.usc.edu Date: Fri, 9 Jun 2000 14:41:14 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-pim@catarina.usc.edu Precedence: bulk >> 3) Most importantly, does anyone have any objections to eliminating >> the (*,*,RP) functionality? > >I agree that DWR is a better way. But my only concern is how widely >is it being used, especially in the existing dense mode stub areas >like enterprises. I know of at least one vendor which has only PIM-DM >and does not have support for DWR. All such enterprises would need to >add DWR supporting router interfaces on all of their internal LANs to >transition to DWR. But are these people using (*,*,RP) now? So far, only 2 out of 6 vendors who have replied support (*,*,RP), and you're the only one who has PMBR. (*,*,RP) is not useful for attaching a dense mode stub to the existing infrastructure, since there are no global RP's. It's really most useful for attaching a sparse mode stub to a dense mode backbone. >Are there other good reasons to not include <*, *, RP> in protocol >specification? Simply elimination of unnecessary complexity with no clear gain. (*,*,RP) probably can't be represented in forwarding hardware, since to match (*,*,RP) state you have to hash the G. Bill From owner-pim@catarina.usc.edu Fri Jun 9 18:08:20 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 SAA19472 for ; Fri, 9 Jun 2000 18:08:20 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA40883 for pim-list; Fri, 9 Jun 2000 15:01: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 PAA40878 for ; Fri, 9 Jun 2000 15:01:34 -0700 (PDT) Received: from yagosys.com (mail.yagosys.com [207.135.89.130]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA18541 for ; Fri, 9 Jun 2000 15:01:33 -0700 (PDT) Received: from mangal.yagosys.com by yagosys.com (8.8.8+Sun/SMI-SVR4-Yago) id OAA01958; Fri, 9 Jun 2000 14:56:07 -0700 (PDT) Received: from yagosys.com by mangal.yagosys.com (SMI-8.6/SMI-SVR4) id OAA06497; Fri, 9 Jun 2000 14:57:39 -0700 Message-ID: <39416853.3757467F@yagosys.com> Date: Fri, 09 Jun 2000 14:57:39 -0700 From: Nimesh Ray Organization: Cabletron Systems X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: Bill Fenner , pim@catarina.usc.edu Subject: Re: A modest proposal: get rid of (*,*,RP) state References: <200006092106.RAA20026@bacardi.torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > Given this, we'd like to ask the following questions: > >1) Does anyone handle receiving and propagating (*,*,RP) joins? > Cabletron Systems (Riverstone Networks) does not > > >2) Does anyone implement the PMBR functionality that initiates > > (*,*,RP) joins? > No. > > >3) Most importantly, does anyone have any objections to eliminating > > the (*,*,RP) functionality? > No objection from our side.. Nimesh -- Nimesh Ray email: nimesh@yagosys.com Member of Technical Staff Office: (408) 878-6516 Yago Systems, Inc./Cabletron Systems Fax: (408) 878-6501 From owner-pim@catarina.usc.edu Fri Jun 9 19:07:03 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 TAA19768 for ; Fri, 9 Jun 2000 19:07:01 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA41411 for pim-list; Fri, 9 Jun 2000 15:59: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]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA41406 for ; Fri, 9 Jun 2000 15:59:45 -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 PAA28472 for ; Fri, 9 Jun 2000 15:59:40 -0700 (PDT) Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 13EBA2AA02; Fri, 9 Jun 2000 15:56:40 -0700 (PDT) Received: (from lwei@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id PAA26157; Fri, 9 Jun 2000 15:55:54 -0700 (PDT) Date: Fri, 9 Jun 2000 15:55:54 -0700 (PDT) Message-Id: <200006092255.PAA26157@malt.redback.com> From: Liming Wei To: fenner@research.att.com Cc: rshekhar@unispheresolutions.com, pim@catarina.usc.edu In-reply-to: <200006092141.OAA20515@windsor.research.att.com> (message from Bill Fenner on Fri, 9 Jun 2000 14:41:14 -0700) Subject: Re: A modest proposal: get rid of (*,*,RP) state Reply-To: lwei@redback.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Bill Fenner > Date: Fri, 9 Jun 2000 14:41:14 -0700 > > >> 3) Most importantly, does anyone have any objections to eliminating > >> the (*,*,RP) functionality? > > > >I agree that DWR is a better way. But my only concern is how widely > >is it being used, especially in the existing dense mode stub areas > >like enterprises. I know of at least one vendor which has only PIM-DM > >and does not have support for DWR. All such enterprises would need to > >add DWR supporting router interfaces on all of their internal LANs to > >transition to DWR. > > But are these people using (*,*,RP) now? So far, only 2 out of 6 vendors > who have replied support (*,*,RP), and you're the only one who has PMBR. > (*,*,RP) is not useful for attaching a dense mode stub to the existing > infrastructure, since there are no global RP's. It's really most useful > for attaching a sparse mode stub to a dense mode backbone. > > >Are there other good reasons to not include <*, *, RP> in protocol > >specification? > > Simply elimination of unnecessary complexity with no clear gain. > (*,*,RP) probably can't be represented in forwarding hardware, since to > match (*,*,RP) state you have to hash the G. We need to keep the public documentation of implemented machineries. It is hard to exhaust the deployment scenarios. Plus, one man's poison can be another's delicacy. I'm for a better version of the PIM SM spec, but I'm against deleting the (*,*,RP) mechanism all together. It needs to be documented somewhere in the public place. One way to do it is to put the current SM spec into the RFC repository. If not as a standard track document, it can be an informational RFC reflecting implemented and deployed machineries. As newer implementations come by, they can get obsoleted by lack of reference. -Liming From owner-pim@catarina.usc.edu Fri Jun 9 19:50:43 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 TAA20192 for ; Fri, 9 Jun 2000 19:50:42 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA41797 for pim-list; Fri, 9 Jun 2000 16:45: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 QAA41792 for ; Fri, 9 Jun 2000 16:45:12 -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 QAA26786 for ; Fri, 9 Jun 2000 16:45:11 -0700 (PDT) Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2000 19:46:35 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C918741@uniwest1.redstonecom.com> From: "Shekhar, Ravi" To: Bill Fenner Cc: pim@catarina.usc.edu Subject: RE: A modest proposal: get rid of (*,*,RP) state Date: Fri, 9 Jun 2000 19:46:32 -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 > (*,*,RP) is not useful for attaching a dense mode stub to the existing > infrastructure, since there are no global RP's. It's really As I understand it, <*, *, RP> can be used anytime data originated in a sparse mode domain has to be pushed to a dense mode domain (stub or otherwise). Yes its true that there is no one RP for all groups, but in that case border router will have to generate <*, *, RP> joins to each RP it knows in the SM domain. > (*,*,RP) probably can't be represented in forwarding > hardware, since to > match (*,*,RP) state you have to hash the G. Is <*, *, RP> representation or hashing required in hardware? If one is running AutoRP and has the support for doing best match on destination address (like many people have for the unicast routing), they can push all the learnt group-RP mapping as class D address/mask with iif towards RP and then do a best match on G contained in the data. From here on problem is only as hard as supporting PIMSMs <*, G> in the hardware. - Ravi Shekhar. From owner-pim@catarina.usc.edu Fri Jun 9 20:06:56 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 UAA20299 for ; Fri, 9 Jun 2000 20:06:56 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id RAA41902 for pim-list; Fri, 9 Jun 2000 17:00:26 -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 RAA41897 for ; Fri, 9 Jun 2000 17:00:25 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA05699 for ; Fri, 9 Jun 2000 17:00:24 -0700 (PDT) Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA09741; Fri, 9 Jun 2000 16:54:34 -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 QAA22616; Fri, 9 Jun 2000 16:54:22 -0700 (PDT) Message-Id: <200006092354.QAA22616@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: "Shekhar, Ravi" cc: Bill Fenner , pim@catarina.usc.edu Subject: Re: A modest proposal: get rid of (*,*,RP) state In-reply-to: Your message of "Fri, 09 Jun 2000 19:46:32 EDT." <49FF5C6DDBD8D311BBBD009027DE980C918741@uniwest1.redstonecom.com> Date: Fri, 09 Jun 2000 16:54:22 -0700 From: Isidor Kouvelas Sender: owner-pim@catarina.usc.edu Precedence: bulk "Shekhar, Ravi" writes: >> (*,*,RP) probably can't be represented in forwarding >> hardware, since to >> match (*,*,RP) state you have to hash the G. > > Is <*, *, RP> representation or hashing required in hardware? > If one is running AutoRP and has the support for doing best match on > destination address (like many people have for the unicast routing), they > can push all the learnt group-RP mapping as class D address/mask with > iif towards RP and then do a best match on G contained in the data. From > here on problem is only as hard as supporting PIMSMs <*, G> in the > hardware. This however is not the case for BSR. Each router hashes on a per group bases between the set of possible RPs... Isidor From owner-pim@catarina.usc.edu Fri Jun 9 20:21:16 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 UAA20407 for ; Fri, 9 Jun 2000 20:21:15 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id RAA42116 for pim-list; Fri, 9 Jun 2000 17:14:52 -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 RAA42111 for ; Fri, 9 Jun 2000 17:14:50 -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 RAA13243 for ; Fri, 9 Jun 2000 17:14:29 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id RAA27976; Fri, 9 Jun 2000 17:13:42 -0700 Date: Fri, 9 Jun 2000 17:13:42 -0700 Message-Id: <200006100013.RAA27976@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, rshekhar@unispheresolutions.com, pim@catarina.usc.edu In-reply-to: <200006092255.PAA26157@malt.redback.com> (message from Liming Wei on Fri, 9 Jun 2000 15:55:54 -0700 (PDT)) Subject: Re: A modest proposal: get rid of (*,*,RP) state References: <200006092255.PAA26157@malt.redback.com> Sender: owner-pim@catarina.usc.edu Precedence: bulk >> machineries. As newer implementations come by, they can get obsoleted >> by lack of reference. Furthermore, we don't want people to reinvent (*,*,RP). Dino From owner-pim@catarina.usc.edu Fri Jun 9 21:01:13 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 VAA20820 for ; Fri, 9 Jun 2000 21:01:12 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id RAA42658 for pim-list; Fri, 9 Jun 2000 17:54:19 -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 RAA42653 for ; Fri, 9 Jun 2000 17:54:18 -0700 (PDT) Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA04915 for ; Fri, 9 Jun 2000 17:54:17 -0700 (PDT) Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.9.3/8.9.3) with ESMTP id RAA20387; Fri, 9 Jun 2000 17:53:27 -0700 (PDT) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: lwei@redback.com cc: fenner@research.att.com, rshekhar@unispheresolutions.com, pim@catarina.usc.edu Subject: Re: A modest proposal: get rid of (*,*,RP) state In-reply-to: Your message of "Fri, 09 Jun 2000 15:55:54 PDT." <200006092255.PAA26157@malt.redback.com> Date: Fri, 09 Jun 2000 17:53:27 -0700 Message-ID: <20385.960598407@aardvark.aciri.org> Sender: owner-pim@catarina.usc.edu Precedence: bulk >I'm for a better version of the PIM SM spec, but I'm against deleting >the (*,*,RP) mechanism all together. It needs to be documented >somewhere in the public place. One way to do it is to put the current >SM spec into the RFC repository. If not as a standard track document, >it can be an informational RFC reflecting implemented and deployed >machineries. As newer implementations come by, they can get obsoleted >by lack of reference. If it's going to get obsoleted anyway, it's better to remove it from the ongoing standards track document - it would have to be removed when the document goes to Draft Standard anyway. It's already documented in RFC 2362, so probably doesn't need a separate document unless the (*,*,RP) mechanism has changed significantly since then, which doesn't seem to be the case. - Mark From owner-pim@catarina.usc.edu Fri Jun 9 21:11:48 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 VAA20931 for ; Fri, 9 Jun 2000 21:11:48 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id SAA42739 for pim-list; Fri, 9 Jun 2000 18:06: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 SAA42734 for ; Fri, 9 Jun 2000 18:06:24 -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 SAA08846 for ; Fri, 9 Jun 2000 18:06:23 -0700 (PDT) Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 02EE82AA04; Fri, 9 Jun 2000 18:03:40 -0700 (PDT) Received: (from lwei@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id SAA00467; Fri, 9 Jun 2000 18:02:54 -0700 (PDT) Date: Fri, 9 Jun 2000 18:02:54 -0700 (PDT) Message-Id: <200006100102.SAA00467@malt.redback.com> From: Liming Wei To: mjh@aciri.org Cc: rshekhar@unispheresolutions.com, pim@catarina.usc.edu In-reply-to: <20385.960598407@aardvark.aciri.org> (message from Mark Handley on Fri, 09 Jun 2000 17:53:27 -0700) Subject: Re: A modest proposal: get rid of (*,*,RP) state Reply-To: lwei@redback.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Mark Handley > Date: Fri, 09 Jun 2000 17:53:27 -0700 > > If it's going to get obsoleted anyway, it's better to remove it from > the ongoing standards track document - it would have to be removed > when the document goes to Draft Standard anyway. True. > It's already documented in RFC 2362, so probably doesn't need a > separate document unless the (*,*,RP) mechanism has changed > significantly since then, which doesn't seem to be the case. There have been numerous corrections and changes on other operations that affect it. I am sugggesting this only because I had email exchanges with (*,*,RP) implementors from at least 4 or 5 different companies/organizations in the past. -Liming From owner-pim@catarina.usc.edu Fri Jun 9 21:43:52 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 VAA21609 for ; Fri, 9 Jun 2000 21:43:51 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id SAA43150 for pim-list; Fri, 9 Jun 2000 18:38: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 SAA43145 for ; Fri, 9 Jun 2000 18:38:50 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id SAA18067 for ; Fri, 9 Jun 2000 18:38:51 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id SAA16084 for ; Fri, 9 Jun 2000 18:19:29 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id SAA09269 for ; Fri, 9 Jun 2000 18:19:20 -0700 (PDT) Received: from dutch.nsd.3com.com (dutch.nsd.3com.com [129.213.48.27]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id SAA29008 for ; Fri, 9 Jun 2000 18:19:15 -0700 (PDT) Received: from localhost (venu@localhost) by dutch.nsd.3com.com (8.8.8/8.8.8) with SMTP id SAA04031 for ; Fri, 9 Jun 2000 18:11:22 -0700 (PDT) X-Authentication-Warning: dutch.nsd.3com.com: venu owned process doing -bs Date: Fri, 9 Jun 2000 18:11:22 -0700 (PDT) From: Nair Venugopal X-Sender: venu@dutch.nsd.3com.com Reply-To: Nair Venugopal To: pim@catarina.usc.edu Subject: Re: A modest proposal: get rid of (*,*,RP) state In-Reply-To: <200006090135.SAA07126@nectar.attlabs.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk On Thu, 8 Jun 2000, Bill Fenner wrote: > Dear PIM'ers, > > As part of our rewrite of the PIM-SM spec, we would like to get > rid of (*,*,RP) state. It was introduced for interoperability with > dense-mode protocols in the "upside-down" mode of a dense-mode > backbone and PIM-SM stubs. In today's Internet, this mode doesn't > exist, and MSDP and Domain-Wide Reports are a much better way to > attach a dense-mode stub site. > > Given this, we'd like to ask the following questions: > 1) Does anyone handle receiving and propagating (*,*,RP) joins? The 3Com implementation does not. > 2) Does anyone implement the PMBR functionality that initiates > (*,*,RP) joins? The 3Com implementation does not. > 3) Most importantly, does anyone have any objections to eliminating > the (*,*,RP) functionality? No objections. thanks --Venu -------------------------------------------------------------------- Nair Venugopal --- venu@3com.com --- 3Com WAP Engineering From owner-pim@catarina.usc.edu Fri Jun 9 22:11: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 WAA22354 for ; Fri, 9 Jun 2000 22:11:38 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA43359 for pim-list; Fri, 9 Jun 2000 19:05:17 -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 TAA43354 for ; Fri, 9 Jun 2000 19:05:15 -0700 (PDT) Received: from dthaler.microsoft.com ([131.107.152.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA24452 for ; Fri, 9 Jun 2000 19:05:15 -0700 (PDT) Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id UAA21072; Fri, 9 Jun 2000 20:34:48 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <200006100334.UAA21072@dthaler.microsoft.com> Subject: Re: A modest proposal: get rid of (*,*,RP) state In-Reply-To: <200006092141.OAA20515@windsor.research.att.com> from Bill Fenner at "Jun 9, 2000 2:41:14 pm" To: fenner@research.att.com (Bill Fenner) Date: Fri, 9 Jun 2000 20:34:48 -0700 (PDT) Cc: rshekhar@unispheresolutions.com, pim@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >> 3) Most importantly, does anyone have any objections to eliminating > >> the (*,*,RP) functionality? > > > >I agree that DWR is a better way. But my only concern is how widely > >is it being used, especially in the existing dense mode stub areas > >like enterprises. I know of at least one vendor which has only PIM-DM > >and does not have support for DWR. All such enterprises would need to > >add DWR supporting router interfaces on all of their internal LANs to > >transition to DWR. > > But are these people using (*,*,RP) now? So far, only 2 out of 6 vendors > who have replied support (*,*,RP), and you're the only one who has PMBR. > (*,*,RP) is not useful for attaching a dense mode stub to the existing > infrastructure, since there are no global RP's. It's really most useful > for attaching a sparse mode stub to a dense mode backbone. As a co-author of the BGMP spec, I'd respond (to the chair of the BGMP WG... :) that when PIM-SM is used as the IGP, while the recommended scenario is to have the BR's be RPs, some people have suggested that they would prefer the luxury of having the RPs and BRs be separate (go figure). To allow this, I think you either have to use MSDP internally (with its potential encapsulation problems) or (*,*,RP) from the best exit router back to the RP. Removing (*,*,RP) would have the effect of leaving only two options: MSDP and RP=BR. This is probably acceptable but it's worth knowing. -Dave From owner-pim@catarina.usc.edu Sun Jun 11 18:55: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 SAA10051 for ; Sun, 11 Jun 2000 18:55:11 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA51946 for pim-list; Sun, 11 Jun 2000 15:45:34 -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 PAA51941 for ; Sun, 11 Jun 2000 15:45:32 -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 PAA13780 for ; Sun, 11 Jun 2000 15:45:32 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id PAA27149; Sun, 11 Jun 2000 15:42:37 -0700 Date: Sun, 11 Jun 2000 15:42:37 -0700 Message-Id: <200006112242.PAA27149@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: dthaler@dthaler.microsoft.com CC: fenner@research.att.com, rshekhar@unispheresolutions.com, pim@catarina.usc.edu In-reply-to: <200006100334.UAA21072@dthaler.microsoft.com> (message from Dave Thaler on Fri, 9 Jun 2000 20:34:48 -0700 (PDT)) Subject: Re: A modest proposal: get rid of (*,*,RP) state References: <200006100334.UAA21072@dthaler.microsoft.com> Sender: owner-pim@catarina.usc.edu Precedence: bulk >> To allow this, I think you either have to use MSDP internally (with its >> potential encapsulation problems) or (*,*,RP) from the best exit router >> back to the RP. Removing (*,*,RP) would have the effect of leaving only >> two options: MSDP and RP=BR. This is probably acceptable but it's worth >> knowing. This is not acceptable architecturally. BGMP is suppose to scale inter- domain multicast better than current solutions. Thereby, allowing to not use all the current solutions. Requiring both MSDP and BGMP, plus having to run PIM inside your domain is a maintenance nightmare for the poor network operator. Dino From owner-pim@catarina.usc.edu Mon Jun 12 01:33:00 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 BAA18394 for ; Mon, 12 Jun 2000 01:33:00 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id WAA52826 for pim-list; Sun, 11 Jun 2000 22:25:24 -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 WAA52821 for ; Sun, 11 Jun 2000 22:25:19 -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 WAA04570 for ; Sun, 11 Jun 2000 22:25:15 -0700 (PDT) Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id BC6BB2AA04; Sun, 11 Jun 2000 22:22:09 -0700 (PDT) Received: (from lwei@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id WAA20779; Sun, 11 Jun 2000 22:21:23 -0700 (PDT) Date: Sun, 11 Jun 2000 22:21:23 -0700 (PDT) Message-Id: <200006120521.WAA20779@malt.redback.com> From: Liming Wei To: dino@procket.com Cc: dthaler@dthaler.microsoft.com, fenner@research.att.com, rshekhar@unispheresolutions.com, pim@catarina.usc.edu In-reply-to: <200006112242.PAA27149@dino-pc.procket.com> (message from Dino Farinacci on Sun, 11 Jun 2000 15:42:37 -0700) Subject: Re: A modest proposal: get rid of (*,*,RP) state Reply-To: lwei@redback.com Sender: owner-pim@catarina.usc.edu Precedence: bulk > From: Dino Farinacci > > This is not acceptable architecturally. BGMP is suppose to scale inter- > domain multicast better than current solutions. Thereby, allowing to > not use all the current solutions. Requiring both MSDP and BGMP, plus > having to run PIM inside your domain is a maintenance nightmare for the > poor network operator. To allow BGMP to function without restriction as a commonly accepted long term solution, the new PIM-SM spec should contain (*,*,RP). -Liming From owner-pim@catarina.usc.edu Mon Jun 12 07:13: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 HAA28200 for ; Mon, 12 Jun 2000 07:13:33 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id EAA54119 for pim-list; Mon, 12 Jun 2000 04:05:00 -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 EAA54114; Mon, 12 Jun 2000 04:04:57 -0700 (PDT) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id EAA96606; Mon, 12 Jun 2000 04:04:57 -0700 (PDT) Message-Id: <200006121104.EAA96606@rumi.usc.edu> To: Bill Fenner cc: pim@catarina.usc.edu Subject: Re: A modest proposal: get rid of (*,*,RP) state In-reply-to: Your message of "Thu, 08 Jun 2000 18:35:37 PDT." <200006090135.SAA07126@nectar.attlabs.att.com> Date: Mon, 12 Jun 2000 04:04:57 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-pim@catarina.usc.edu Precedence: bulk > As part of our rewrite of the PIM-SM spec, we would like to get > rid of (*,*,RP) state. It was introduced for interoperability with > dense-mode protocols in the "upside-down" mode of a dense-mode > backbone and PIM-SM stubs. In today's Internet, this mode doesn't > exist, and MSDP and Domain-Wide Reports are a much better way to > attach a dense-mode stub site. > > Given this, we'd like to ask the following questions: > 1) Does anyone handle receiving and propagating (*,*,RP) joins? (For whatever worths mentioning it): pimd implements it, but it was never tested. > 2) Does anyone implement the PMBR functionality that initiates > (*,*,RP) joins? pimd does not. > 3) Most importantly, does anyone have any objections to eliminating > the (*,*,RP) functionality? If we can get away without (*,*,RP) in the long term (i.e. with BGMP in mind, but see my question below), I would prefer (*,*,RP) support to be optional (only if compatibility with PMBR is needed, for example). PIM-SM without (*,*,RP) will simplify significantly the protocol. It is hard for me to believe that in the future someone would want to use (*,*,RP) to "push" the data from all PIM-SM domains to the dense-mode domains, because this simply won't scale. Dense-mode domains should use Domain-Wide Reports instead, and only those domains should "pay" the protocol complexity price (i.e. running one more protocol: DWR) instead the rest of the world. In another email Dave Thaler wrote: === As a co-author of the BGMP spec, I'd respond (to the chair of the BGMP WG... :) that when PIM-SM is used as the IGP, while the recommended scenario is to have the BR's be RPs, some people have suggested that they would prefer the luxury of having the RPs and BRs be separate (go figure). To allow this, I think you either have to use MSDP internally (with its potential encapsulation problems) or (*,*,RP) from the best exit router back to the RP. Removing (*,*,RP) would have the effect of leaving only two options: MSDP and RP=BR. This is probably acceptable but it's worth knowing. === I am probably missing something in the picture, but why do we need (*,*,RP) if the RP is not a border router? To "push" the data from the internal sources over the BGMP trees to the dense-mode domains? (again, Domain-Wide Reports running in the dense-mode domains will eliminate the need for this). A more detailed example here would be helpful :) Pavlin From owner-pim@catarina.usc.edu Mon Jun 12 10:49:13 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 KAA03082 for ; Mon, 12 Jun 2000 10:49:13 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA54816 for pim-list; Mon, 12 Jun 2000 07:42: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 HAA54811 for ; Mon, 12 Jun 2000 07:42:44 -0700 (PDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA03106 for ; Mon, 12 Jun 2000 07:42:44 -0700 (PDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Mon, 12 Jun 2000 10:41:15 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D3BA1C4@packetbdc.packettech.com> From: Billy Ng To: "'Bill Fenner'" , pim@catarina.usc.edu Subject: RE: A modest proposal: get rid of (*,*,RP) state Date: Mon, 12 Jun 2000 09:42:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk > > Given this, we'd like to ask the following questions: > 1) Does anyone handle receiving and propagating (*,*,RP) joins? RiverDelta does not, but I know Nortel/Bay does :). > 2) Does anyone implement the PMBR functionality that initiates > (*,*,RP) joins? RiverDelta does not, but I know Nortel/Bay does :). > 3) Most importantly, does anyone have any objections to eliminating > the (*,*,RP) functionality? > No objections. (don't think Nortel/Bay objects either :). --Billy From owner-pim@catarina.usc.edu Mon Jun 12 10:49: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 KAA03093 for ; Mon, 12 Jun 2000 10:49:15 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA54809 for pim-list; Mon, 12 Jun 2000 07:42:43 -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 HAA54804 for ; Mon, 12 Jun 2000 07:42:42 -0700 (PDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA03081 for ; Mon, 12 Jun 2000 07:42:41 -0700 (PDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Mon, 12 Jun 2000 10:41:09 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D3BA1C4@packetbdc.packettech.com> From: Billy Ng To: "'Bill Fenner'" , pim@catarina.usc.edu Subject: RE: A modest proposal: get rid of (*,*,RP) state Date: Mon, 12 Jun 2000 09:42:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk > > Given this, we'd like to ask the following questions: > 1) Does anyone handle receiving and propagating (*,*,RP) joins? RiverDelta does not, but I know Nortel/Bay does :). > 2) Does anyone implement the PMBR functionality that initiates > (*,*,RP) joins? RiverDelta does not, but I know Nortel/Bay does :). > 3) Most importantly, does anyone have any objections to eliminating > the (*,*,RP) functionality? > No objections. (don't think Nortel/Bay objects either :). --Billy From owner-pim@catarina.usc.edu Mon Jun 12 10:49:52 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 KAA03115 for ; Mon, 12 Jun 2000 10:49:51 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA54827 for pim-list; Mon, 12 Jun 2000 07:43:31 -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 HAA54822 for ; Mon, 12 Jun 2000 07:43:30 -0700 (PDT) Received: from packetbdc.riverdelta.com (packetbdc.packettech.com [198.112.190.11]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA03258 for ; Mon, 12 Jun 2000 07:43:28 -0700 (PDT) Received: by packetbdc.packettech.com with Internet Mail Service (5.5.2448.0) id ; Mon, 12 Jun 2000 10:43:45 -0400 Message-ID: <7F4AC78738EAD2119D86009027626C6D3BA1C4@packetbdc.packettech.com> From: Billy Ng To: "'Bill Fenner'" , pim@catarina.usc.edu Subject: RE: A modest proposal: get rid of (*,*,RP) state Date: Mon, 12 Jun 2000 09:42:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk > > Given this, we'd like to ask the following questions: > 1) Does anyone handle receiving and propagating (*,*,RP) joins? RiverDelta does not, but I know Nortel/Bay does :). > 2) Does anyone implement the PMBR functionality that initiates > (*,*,RP) joins? RiverDelta does not, but I know Nortel/Bay does :). > 3) Most importantly, does anyone have any objections to eliminating > the (*,*,RP) functionality? > No objections. (don't think Nortel/Bay objects either :). --Billy From owner-pim@catarina.usc.edu Mon Jun 12 11:41:21 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 LAA04658 for ; Mon, 12 Jun 2000 11:41:20 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id IAA55604 for pim-list; Mon, 12 Jun 2000 08:35: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] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA55599 for ; Mon, 12 Jun 2000 08:35:21 -0700 (PDT) Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id IAA22305 for ; Mon, 12 Jun 2000 08:35:22 -0700 (PDT) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id IAA02016; Mon, 12 Jun 2000 08:29:42 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id IAA12859; Mon, 12 Jun 2000 08:29:40 -0700 (PDT) Received: from bluebird.engeast (bluebird [192.32.224.91]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id LAA09125; Mon, 12 Jun 2000 11:31:09 -0400 for Received: from localhost by bluebird.engeast (SMI-8.6/SMI-SVR4) id LAA03824; Mon, 12 Jun 2000 11:31:08 -0400 Date: Mon, 12 Jun 2000 11:31:08 -0400 (EDT) From: Yunzhou Li X-Sender: yli@bluebird To: Billy Ng cc: "'Bill Fenner'" , pim@catarina.usc.edu Subject: RE: A modest proposal: get rid of (*,*,RP) state In-Reply-To: <7F4AC78738EAD2119D86009027626C6D3BA1C4@packetbdc.packettech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi there, I have an objection to eliminating the (*,*,RP) functionality: (*,*,RP) state provides interoperability capability to PIM-SM and DVMPR/PIM-DM; (*,*,RP) provides a better scalability to high speed routers. Thanks, -yli On Mon, 12 Jun 2000, Billy Ng wrote: > > > > > Given this, we'd like to ask the following questions: > > 1) Does anyone handle receiving and propagating (*,*,RP) joins? > > RiverDelta does not, but I know Nortel/Bay does :). > > > 2) Does anyone implement the PMBR functionality that initiates > > (*,*,RP) joins? > > RiverDelta does not, but I know Nortel/Bay does :). > > > 3) Most importantly, does anyone have any objections to eliminating > > the (*,*,RP) functionality? > > > > No objections. (don't think Nortel/Bay objects either :). > > --Billy > > From owner-pim@catarina.usc.edu Mon Jun 12 12:20:52 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 MAA05786 for ; Mon, 12 Jun 2000 12:20:52 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA55939 for pim-list; Mon, 12 Jun 2000 09:15:47 -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 JAA55934 for ; Mon, 12 Jun 2000 09:15:46 -0700 (PDT) Received: from dthaler.microsoft.com ([131.107.152.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA14847 for ; Mon, 12 Jun 2000 09:15:47 -0700 (PDT) Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id KAA26700; Mon, 12 Jun 2000 10:45:36 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <200006121745.KAA26700@dthaler.microsoft.com> Subject: Re: A modest proposal: get rid of (*,*,RP) state In-Reply-To: <200006112242.PAA27149@dino-pc.procket.com> from Dino Farinacci at "Jun 11, 2000 3:42:37 pm" To: dino@procket.com (Dino Farinacci) Date: Mon, 12 Jun 2000 10:45:36 -0700 (PDT) Cc: dthaler@dthaler.microsoft.com, fenner@research.att.com, rshekhar@unispheresolutions.com, pim@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >> To allow this, I think you either have to use MSDP internally (with its > >> potential encapsulation problems) or (*,*,RP) from the best exit router > >> back to the RP. Removing (*,*,RP) would have the effect of leaving only > >> two options: MSDP and RP=BR. This is probably acceptable but it's worth > >> knowing. > > This is not acceptable architecturally. BGMP is suppose to scale inter- > domain multicast better than current solutions. Thereby, allowing to > not use all the current solutions. Requiring both MSDP and BGMP, plus > having to run PIM inside your domain is a maintenance nightmare for the > poor network operator. BGMP does not require you to run PIM or MSDP, as you appear to be arguing against. -Dave From owner-pim@catarina.usc.edu Mon Jun 12 12:35: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 MAA06198 for ; Mon, 12 Jun 2000 12:35:09 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA56039 for pim-list; Mon, 12 Jun 2000 09:28:05 -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 JAA56033; Mon, 12 Jun 2000 09:28:04 -0700 (PDT) Received: from dthaler.microsoft.com ([131.107.152.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA21810; Mon, 12 Jun 2000 09:28:04 -0700 (PDT) Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id KAA26781; Mon, 12 Jun 2000 10:57:58 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <200006121757.KAA26781@dthaler.microsoft.com> Subject: Re: A modest proposal: get rid of (*,*,RP) state In-Reply-To: <200006121104.EAA96606@rumi.usc.edu> from Pavlin Ivanov Radoslavov at "Jun 12, 2000 4: 4:57 am" To: pavlin@catarina.usc.edu (Pavlin Ivanov Radoslavov) Date: Mon, 12 Jun 2000 10:57:57 -0700 (PDT) Cc: fenner@research.att.com, pim@catarina.usc.edu, bgmp@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pavlin asks: > I am probably missing something in the picture, but why do we need > (*,*,RP) if the RP is not a border router? > To "push" the data from the internal sources over the BGMP trees to > the dense-mode domains? (again, Domain-Wide Reports running in the > dense-mode domains will eliminate the need for this). > > A more detailed example here would be helpful :) Technically one would only need a bunch of (*,Gprefix,RP) joins per RP but those aren't specified, so a single (*,*,RP) per RP works :) The exit router for Gprefix (i.e. the one towards the root domain for Gprefix) needs to receive all data from the subtree under it for all groups G in Gprefix. If it's the RP for all such groups, there's no problem, all packets travelling uptree automatically get sent to it. If it's not the RP, it needs a way to join to all RPs that serve groups in Gprefix. (And any other Gprefix'es for which it is the best exit router.) DWRs don't help here, since this is a border router needing to set up a path to an internal RP. So to repeat, solutions I'm aware of are: 1) Don't run PIM-SM... run BGMP as the M-IGP (as Dino hinted, I think) 2) Run PIM-SM with RPs=BRs. 3) Run PIM-SM with MSDP for internal peerings only, between RPs & BRs. 4) Run PIM-SM with (*,*,RP) joins from exit BRs to RPs. -Dave From owner-pim@catarina.usc.edu Mon Jun 12 13:58:09 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 NAA07920 for ; Mon, 12 Jun 2000 13:58:08 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA56842 for pim-list; Mon, 12 Jun 2000 10:52:06 -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 KAA56837 for ; Mon, 12 Jun 2000 10:52:05 -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 KAA25311 for ; Mon, 12 Jun 2000 10:52:05 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id KAA09690; Mon, 12 Jun 2000 10:50:32 -0700 Date: Mon, 12 Jun 2000 10:50:32 -0700 Message-Id: <200006121750.KAA09690@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: dthaler@dthaler.microsoft.com CC: dthaler@dthaler.microsoft.com, fenner@research.att.com, rshekhar@unispheresolutions.com, pim@catarina.usc.edu In-reply-to: <200006121745.KAA26700@dthaler.microsoft.com> (message from Dave Thaler on Mon, 12 Jun 2000 10:45:36 -0700 (PDT)) Subject: Re: A modest proposal: get rid of (*,*,RP) state References: <200006121745.KAA26700@dthaler.microsoft.com> Sender: owner-pim@catarina.usc.edu Precedence: bulk >> BGMP does not require you to run PIM or MSDP, as you appear to be arguing >> against. But running an already widely deployed PIM with various strategies fro RP placementt makes it nearly impossible to deploy BGMP. Dino From owner-pim@catarina.usc.edu Mon Jun 12 14:07:13 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 OAA08212 for ; Mon, 12 Jun 2000 14:07:11 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA56934 for pim-list; Mon, 12 Jun 2000 11:00:54 -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 LAA56929 for ; Mon, 12 Jun 2000 11:00:52 -0700 (PDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA02413 for ; Mon, 12 Jun 2000 11:00:53 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12477 for ; Mon, 12 Jun 2000 13:56:34 -0400 (EDT) Received: from fore.com (armenian.dc.fore.com [169.144.136.115]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08128 for ; Mon, 12 Jun 2000 13:56:35 -0400 (EDT) Message-ID: <3943D32B.D4596163@fore.com> Date: Sun, 11 Jun 2000 13:58:03 -0400 From: Ardas Cilingiroglu X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: pim@catarina.usc.edu Subject: Re: A modest proposal: get rid of (*,*,RP) state References: <200006090135.SAA07126@nectar.attlabs.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Fenner wrote: > Dear PIM'ers, > > As part of our rewrite of the PIM-SM spec, we would like to get > rid of (*,*,RP) state. It was introduced for interoperability with > dense-mode protocols in the "upside-down" mode of a dense-mode > backbone and PIM-SM stubs. In today's Internet, this mode doesn't > exist, and MSDP and Domain-Wide Reports are a much better way to > attach a dense-mode stub site. > > Given this, we'd like to ask the following questions: > 1) Does anyone handle receiving and propagating (*,*,RP) joins? Marconi (FORE) does... > > 2) Does anyone implement the PMBR functionality that initiates > (*,*,RP) joins? Marconi does... > > 3) Most importantly, does anyone have any objections to eliminating > the (*,*,RP) functionality? same concerns with other people... > > Thanks, > Bill & Mark & Hugh & Isidor From owner-pim@catarina.usc.edu Mon Jun 12 15:25:13 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 PAA09404 for ; Mon, 12 Jun 2000 15:25:11 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA57652 for pim-list; Mon, 12 Jun 2000 12:20:07 -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 MAA57647 for ; Mon, 12 Jun 2000 12:20:06 -0700 (PDT) Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA27679 for ; Mon, 12 Jun 2000 12:20:02 -0700 (PDT) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id MAA11228; Mon, 12 Jun 2000 12:14:43 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id MAA07921; Mon, 12 Jun 2000 12:14:41 -0700 (PDT) Received: from bluebird.engeast (bluebird [192.32.224.91]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA15603; Mon, 12 Jun 2000 15:16:10 -0400 for Received: from localhost by bluebird.engeast (SMI-8.6/SMI-SVR4) id PAA00517; Mon, 12 Jun 2000 15:16:10 -0400 Date: Mon, 12 Jun 2000 15:16:10 -0400 (EDT) From: Yunzhou Li X-Sender: yli@bluebird Reply-To: Yunzhou Li To: Billy Ng cc: "'Bill Fenner'" , pim@catarina.usc.edu Subject: RE: A modest proposal: get rid of (*,*,RP) state In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi All, I should have explained my point in more detail: A (*,*,RP) state is an aggregation of multiple (*,G/prefix) states, or (*,*) state when the prefix length is 4 or less. Each (*,G/prefix) state again is an aggregation of numerous (*,G) and (S,G) states. With this interpretation, we don't have to do two lookups in the data forwarding plane. I think the new PIM-SM specification probably can reflect this fact. A high speed router may not allow too much intelligence and it may not generate revenue per-flow (S,G) or (*,G). In stead, it may generate revenue per aggregated bandwidth or (*,G/prefix). In particular, we allow a (*,*,RP) generator to create a forwarding policy like "accept all but reject...". This policy in turns can be propagated to all routers from the (*,*,RP) generator all the way to the RP. This is how we can benefit from (*,*,RP). At this point, I would think (*,*,RP) has a good match with BGMP (*,G/prefix) state. Thanks, -yli On Mon, 12 Jun 2000, Yunzhou Li wrote: > Hi there, > > I have an objection to eliminating the (*,*,RP) functionality: > (*,*,RP) state provides interoperability capability to PIM-SM > and DVMPR/PIM-DM; (*,*,RP) provides a better scalability to > high speed routers. > > Thanks, > -yli > > On Mon, 12 Jun 2000, Billy Ng wrote: > > > > > > > > > Given this, we'd like to ask the following questions: > > > 1) Does anyone handle receiving and propagating (*,*,RP) joins? > > > > RiverDelta does not, but I know Nortel/Bay does :). > > > > > 2) Does anyone implement the PMBR functionality that initiates > > > (*,*,RP) joins? > > > > RiverDelta does not, but I know Nortel/Bay does :). > > > > > 3) Most importantly, does anyone have any objections to eliminating > > > the (*,*,RP) functionality? > > > > > > > No objections. (don't think Nortel/Bay objects either :). > > > > --Billy > > > > > > From owner-pim@catarina.usc.edu Mon Jun 12 21:30:36 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 VAA14118 for ; Mon, 12 Jun 2000 21:30:36 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id SAA59440 for pim-list; Mon, 12 Jun 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] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id SAA59435 for ; Mon, 12 Jun 2000 18:19:40 -0700 (PDT) Received: from mailboy.huawei.com.cn ([202.96.135.134]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id SAA05736 for ; Mon, 12 Jun 2000 18:19:37 -0700 (PDT) Received: from sz.huawei.com.cn ([10.110.204.200]) by mailboy.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA21456 for ; Tue, 13 Jun 2000 09:04:09 +0800 Message-ID: <39458A20.8428645B@sz.huawei.com.cn> Date: Tue, 13 Jun 2000 09:10:56 +0800 From: dengqiulin X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: pim@catarina.usc.edu Subject: i wanna get into the pim area! no body! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-pim@catarina.usc.edu Mon Jun 19 08:03:13 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 IAA00879 for ; Mon, 19 Jun 2000 08:03:13 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id EAA91134 for pim-list; Mon, 19 Jun 2000 04:49: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 EAA91129 for ; Mon, 19 Jun 2000 04:49:44 -0700 (PDT) Received: from ferret.cs.fiu.edu (ferret.cs.fiu.edu [131.94.125.231]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id EAA11051 for ; Mon, 19 Jun 2000 04:49:40 -0700 (PDT) Received: from cs.fiu.edu (ferret.cs.fiu.edu [131.94.125.231]) by ferret.cs.fiu.edu (8.9.2/FIU-CS-1.2) with ESMTP id HAA27523 for ; Mon, 19 Jun 2000 07:48:50 -0400 (EDT) Message-Id: <200006191148.HAA27523@ferret.cs.fiu.edu> To: pim@catarina.usc.edu Subject: pimd-2.1.0-alpha28 on solaris 2.6 Date: Mon, 19 Jun 2000 07:48:49 -0400 From: "Eric S. Johnson" Sender: owner-pim@catarina.usc.edu Precedence: bulk Is this supposed to work? pimd-2.1.0-alpha28 on solaris 5.6? netinet/ip_mroute.h on sol5.[67] doesn't define VIFF_REGISTER. Things seem to go down hill from there... Readme says Solaris-5.5.1 and 5.6 are "Supported Platforms". Code seems to not care much about any sunos version >= 5.6. It seems to treat them all the same. Do I need special patches? I didn't see them listed? Don't see anything appropriate from playground.sun.com... Any ideas or help (even if as simple as "give up it won't work" ;) would be appriciated. E From owner-pim@catarina.usc.edu Mon Jun 19 09:22: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 JAA04462 for ; Mon, 19 Jun 2000 09:22:46 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id GAA91551 for pim-list; Mon, 19 Jun 2000 06:10:08 -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 GAA91546; Mon, 19 Jun 2000 06:10:06 -0700 (PDT) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id GAA48872; Mon, 19 Jun 2000 06:10:06 -0700 (PDT) Message-Id: <200006191310.GAA48872@rumi.usc.edu> To: "Eric S. Johnson" cc: pim@catarina.usc.edu Subject: Re: pimd-2.1.0-alpha28 on solaris 2.6 In-reply-to: Your message of "Mon, 19 Jun 2000 07:48:49 EDT." <200006191148.HAA27523@ferret.cs.fiu.edu> Date: Mon, 19 Jun 2000 06:10:06 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-pim@catarina.usc.edu Precedence: bulk > Is this supposed to work? pimd-2.1.0-alpha28 on solaris 5.6? A significant amount of its development was done on Solaris 5.5.1 and 5.6 which had their kernel modified with PIM support, and at that time it was working. However, the necessary PIM kernel patches for 5.5.1 and 5.6 were never released to the public. I thought it was mentioned in the README, but now I see it is not there. :( > netinet/ip_mroute.h on sol5.[67] doesn't define VIFF_REGISTER. > Things seem to go down hill from there... > > Readme says Solaris-5.5.1 and 5.6 are "Supported Platforms". > > Code seems to not care much about any sunos version >= 5.6. It seems to > treat them all the same. Do I need special patches? I didn't see them > listed? Don't see anything appropriate from playground.sun.com... > > Any ideas or help (even if as simple as "give up it won't work" ;) > would be appriciated. Solaris 8 has PIM support in the kernel. However, I haven't tested it, and don't know whether it really works with pimd. If you end up testing it with Solaris 8, please let me know about the result. Regards, Pavlin From owner-pim@catarina.usc.edu Wed Jun 28 07:01: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 HAA18190 for ; Wed, 28 Jun 2000 07:01:34 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id DAA09712 for pim-list; Wed, 28 Jun 2000 03:52: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 DAA09699 for ; Wed, 28 Jun 2000 03:52:04 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA19152 for ; Wed, 28 Jun 2000 03:52:03 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17858; Wed, 28 Jun 2000 06:48:44 -0400 (EDT) Message-Id: <200006281048.GAA17858@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: pim@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hummel-pim-so-00.txt Date: Wed, 28 Jun 2000 06:48:44 -0400 Sender: owner-pim@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Source Only Multicast Author(s) : H. Hummel Filename : draft-hummel-pim-so-00.txt Pages : 10 Date : 27-Jun-00 This draft addresses several aspects of multicast services like IP- based TV but also like n-party conferences. It breaks with traditional concepts: An IP-based TV-broadcast's delivery tree shall be identified by the source address S and a Multicast-ID provided by S. The same shall apply to each from n well correlated point-to(n-1)point delivery trees of a small n-party conference. Consequently, a TV-host may send out more than one program and any user-host may participate in more than one conference. Mapping to a globally unique multicast group address G is not needed, would be complex, and does not work. QoS/Policy-Routing, the degree of state (Layer-3, Layer-3 plus MPLS- label, or no state), and several more aspects need to be respected HOMOGENEOUSLY all over the entire delivery tree. This cannot be provided by reverse path setup while depending on each receiver's guesses. Therefore, the tree (i.e. an initial tree as well as additional branches at a later time) must be established in downstream direction. No RP- and no BSR-routers are required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hummel-pim-so-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hummel-pim-so-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hummel-pim-so-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000627112041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hummel-pim-so-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hummel-pim-so-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000627112041.I-D@ietf.org> --OtherAccess-- --NextPart--