From 558-mailing-list-admin@catarina.usc.edu Thu May 1 08:10:13 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06363 for ; Thu, 1 May 2003 08:10:13 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h41CCaX94477 for ; Thu, 1 May 2003 05:12:36 -0700 (PDT) (envelope-from 558-mailing-list-admin@catarina.usc.edu) Date: Thu, 01 May 2003 05:12:36 -0700 Message-ID: <20030501121236.90265.69359.Mailman@catarina.usc.edu> Subject: catarina.usc.edu mailing list memberships reminder From: mailman-owner@catarina.usc.edu To: pim-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: 558-mailing-list-admin@catarina.usc.edu Errors-To: 558-mailing-list-admin@catarina.usc.edu X-BeenThere: 558-mailing-list@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk This is a reminder, sent out once a month, about your catarina.usc.edu mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, pim-request@catarina.usc.edu) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@catarina.usc.edu. Thanks! Passwords for pim-archive@lists.ietf.org: List Password // URL ---- -------- pim@catarina.usc.edu kimoit http://catarina.usc.edu/mailman/options/pim/pim-archive%40lists.ietf.org From pim-admin@catarina.usc.edu Sat May 3 12:46:53 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02957 for ; Sat, 3 May 2003 12:46:52 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h43GftX54580; Sat, 3 May 2003 09:41:55 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h43GbtX54499 for ; Sat, 3 May 2003 09:37:55 -0700 (PDT) (envelope-from eckert@cisco.com) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h43GbnXp025029 for ; Sat, 3 May 2003 09:37:49 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA16112 for pim@catarina.usc.edu; Sat, 3 May 2003 09:37:48 -0700 (PDT) From: Toerless Eckert To: pim@catarina.usc.edu Message-ID: <20030503163748.GY5680@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [pim] reaction to pim-sm register messages ? Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 3 May 2003 09:37:48 -0700 How should a system receiving a (maybe whole bunch of) pim-sm register messages react ? Conditions may include that the system does not run PIM at all, or that the group is in a different mode (PIM-DM, Bidir). Would this behavior have to change depending on wether the system supports PIM-SM at all ? Eg: If the system does NOT supports PIM-SM at all (but maybe PIM-DM or Bidir-PIM), would an ICMP protocol unreachable be appropriate ? Would an IGMP port unreachable ever be appropriate (eg: if we do support PIM-SM, but the group is not PIM-SM nor SSM ?). To me there's a definition gap between the case of a router who doesn't know what PIM is (sends protocol unreachable) and the case of the group being PIM-SM/SSM on the router and the router not being the RP (sends register stop). Are different modes of PIM actually different protocols (at least not as far as IP is concerned, right ?) ? Shouldn't there be at least some common definition of PIM behavior applicable to whoever wants to add modes or whatever it's called ? The particular case about receiving unicast PIM messages you can't handle looks like such a case. rfc2563: "A destination node SHOULD send a Destination Unreachable message with Code 4 in response to a packet for which the transport protocol (e.g., UDP) has no listener, if that transport protocol has no alternative means to inform the sender." - So, what's the transport protocol here ? PIM ? PIM-DM ? Bidir-PIM ? Do they have an alternative ? Is it register stop ? Cheers Toerless _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat May 3 22:21:08 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12894 for ; Sat, 3 May 2003 22:21:07 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h442JSX63832; Sat, 3 May 2003 19:19:28 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from mail.iscas.ac.cn ([159.226.5.56]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h442GsX63787 for ; Sat, 3 May 2003 19:16:54 -0700 (PDT) (envelope-from hongfei@isdn.iscas.ac.cn) Message-Id: <200305040216.h442GsX63787@catarina.usc.edu> Received: (qmail 31877 invoked by uid 104); 4 May 2003 02:16:01 -0000 Received: from hongfei@isdn.iscas.ac.cn by mail.iscas.ac.cn by uid 0 with qmail-scanner-1.14 (hbedv: 6.15.0.1. hbedv: operating system: Linux (glibc). hbedv: product version: 2.0.4. hbedv: engine version: 6.15.0.1. hbedv: packlib version: 2.0.0.8 (supports 19 formats). hbedv: vdf version: 6.15.0.7 (66928 recognized forms). hbedv: . hbedv: product: AntiVir Workstation. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir MailGate. hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. hbedv: . hbedv: product: AntiVir (command line scanner). hbedv: key file: hbedv.key. hbedv: registered user: irene, 123. hbedv: serial number: 1001020203. hbedv: key expires: 31 May 2003. hbedv: run mode: PRIVATE. Clear:. Processed in 0.263011 secs); 04 May 2003 02:16:01 -0000 Received: from unknown (HELO ftpftp) (hongfei@159.226.5.123) by mail.iscas.ac.cn with SMTP; 4 May 2003 02:16:01 -0000 From: "Hongfei" Reply-To: hongfei@isdn.iscas.ac.cn To: "pim@catarina.usc.edu" Organization: Institute of Software CAS X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" X-Qmail-Scanner-Message-ID: <105201456150131872@mail.iscas.ac.cn> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h442GsX63787 Subject: [pim] Re: reaction to pim-sm register messages ? Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 4 May 2003 10:16:40 +0800 Content-Transfer-Encoding: 8bit pim-request,hello£¡ To your question, I think the router processing the pim-sm register message must be a pim-sm RP router. So the register message can only be processed at the RP router, there is no confiction with other protocol. ¡¡¡¡ ======= 2003-05-03 you have written£º======= >Today's Topics: > > 1. reaction to pim-sm register messages ? (Toerless Eckert) > >--__--__-- > >Message: 1 >Date: Sat, 3 May 2003 09:37:48 -0700 >From: Toerless Eckert >To: pim@catarina.usc.edu >Subject: [pim] reaction to pim-sm register messages ? > >How should a system receiving a (maybe whole bunch of) pim-sm register >messages react ? Conditions may include that the system does not >run PIM at all, or that the group is in a different mode (PIM-DM, Bidir). >Would this behavior have to change depending on wether the system >supports PIM-SM at all ? Eg: If the system does NOT supports PIM-SM >at all (but maybe PIM-DM or Bidir-PIM), would an ICMP protocol unreachable >be appropriate ? Would an IGMP port unreachable ever be appropriate (eg: >if we do support PIM-SM, but the group is not PIM-SM nor SSM ?). > >To me there's a definition gap between the case of a router who doesn't >know what PIM is (sends protocol unreachable) and the case of the >group being PIM-SM/SSM on the router and the router not being the RP >(sends register stop). > >Are different modes of PIM actually different protocols (at least not >as far as IP is concerned, right ?) ? Shouldn't there be at least some >common definition of PIM behavior applicable to whoever wants to add >modes or whatever it's called ? The particular case about receiving >unicast PIM messages you can't handle looks like such a case. > >rfc2563: "A destination node SHOULD send a Destination Unreachable >message with Code 4 in response to a packet for which the transport protocol >(e.g., UDP) has no listener, if that transport protocol has no alternative >means to inform the sender." - So, what's the transport protocol here ? >PIM ? PIM-DM ? Bidir-PIM ? Do they have an alternative ? Is it register >stop ? > >Cheers > Toerless > > >--__--__-- > >_______________________________________________ >pim mailing list >pim@catarina.usc.edu >http://catarina.usc.edu/mailman/listinfo/pim > > >End of pim Digest = = = = = = = = = = = = = = = = = = = = yours Hongfei hongfei@isdn.iscas.ac.cn 2003-05-04 _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 7 20:09:10 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24771 for ; Wed, 7 May 2003 20:09:08 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4807ZX60785; Wed, 7 May 2003 17:07:36 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from bosvwl02.infosys.com (bosvwl02.inf.com [216.52.49.36]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h47EO1X50262 for ; Wed, 7 May 2003 07:24:02 -0700 (PDT) (envelope-from bharat_joshi@infosys.com) Received: from 192.168.200.82 by bosvwl02.infosys.com (InterScan E-Mail VirusWall NT); Wed, 07 May 2003 10:25:53 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 7 May 2003 19:54:43 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 7 May 2003 19:54:42 +0530 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Message-ID: <56E2573C375A414191118970BDE06A150ABE5EA6@kecmsg06.ad.infosys.com> Thread-Topic: PIM BSR Draft Thread-Index: AcMUkSbWuHDy8tD4RMmsIEOjM0Tviw== From: "bharat_joshi" To: X-OriginalArrivalTime: 07 May 2003 14:24:42.0819 (UTC) FILETIME=[66C9A930:01C314A4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h47EO1X50262 Subject: [pim] PIM BSR Draft Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 May 2003 19:54:43 +0530 Content-Transfer-Encoding: 8bit Hi, I was going through the C-BSR draft. Can somebody explain what will happen when a new Router comes up and can be the preferred BSR in the PIM domain? The draft mention that a router will be in pending state after start-up and start BS timer to BS timeout value. Lets say that the DR on the network, pass on the BSM to this new router. Lets assume that this new router is having higher priority and so should be elected as a BSR. Now the state-machine shows that when in pending state and a non-preferred BSM is received ..don't do anything. Now when the BS timer will expire, this new router will think that he has become the new elected BSR but he doesn't have any information about the C-RPs till now as C-RPs would be unicasting their info to the old BSR. Either there is something wrong here or I am not able to understand it properly. Can somebody help me in understanding this?? TIA, Best Regards, Bharat ============================== Infosys Technologies Ltd. Bangalore, India _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 7 20:40:13 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25384 for ; Wed, 7 May 2003 20:40:12 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h480dXX61403; Wed, 7 May 2003 17:39:33 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from gateway.ipinfusion.com (mail.ipinfusion.com [65.223.109.2]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h480bkX61367 for ; Wed, 7 May 2003 17:37:46 -0700 (PDT) (envelope-from rishabh@ipinfusion.com) Received: from rishabh (dhcp143.ipinfusion.com [10.10.0.143] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id h480bNi15283; Wed, 7 May 2003 17:37:23 -0700 Content-Type: text/plain; charset="windows-1252" From: Rishabh Parekh Organization: IP Infusion To: "bharat_joshi" Subject: Re: [pim] PIM BSR Draft User-Agent: KMail/1.4.3 References: <56E2573C375A414191118970BDE06A150ABE5EA6@kecmsg06.ad.infosys.com> In-Reply-To: <56E2573C375A414191118970BDE06A150ABE5EA6@kecmsg06.ad.infosys.com> Cc: MIME-Version: 1.0 Message-Id: <200305071737.09074.rishabh@ipinfusion.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h480bkX61367 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 May 2003 17:37:09 -0700 Content-Transfer-Encoding: 8bit Bharat, When a new router comes up and it becomes an Elected-BSR from a Pending-BSR, it originates a BootStrap message. This BS message is received at the Candidate-RPs (and other ordinary non-CRP non-CBSR PIM routers) and they appoint the new router as the BSR. The C-RPs then advertise thier C-RP messages to the newly elected BSR which builds and distributes the RP set information in subsequent BS messages. I hope this helps to clarify your doubts, Rishabh. On Wednesday 07 May 2003 07:24 am, bharat_joshi wrote: > Hi, > > I was going through the C-BSR draft. > > Can somebody explain what will happen when a new Router comes up and can be > the preferred BSR in the PIM domain? > > The draft mention that a router will be in pending state after start-up and > start BS timer to BS timeout value. > > Lets say that the DR on the network, pass on the BSM to this new router. > > Lets assume that this new router is having higher priority and so should be > elected as a BSR. > > Now the state-machine shows that when in pending state and a non-preferred > BSM is received ..don't do anything. > > Now when the BS timer will expire, this new router will think that he has > become the new elected BSR but he doesn't have any information about the > C-RPs till now as C-RPs would be unicasting their info to the old BSR. > > Either there is something wrong here or I am not able to understand it > properly. > > Can somebody help me in understanding this?? > > TIA, > > Best Regards, > Bharat > > ============================== > Infosys Technologies Ltd. > Bangalore, India > > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu May 8 21:13:04 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18583 for ; Thu, 8 May 2003 21:13:04 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h491BJX88102; Thu, 8 May 2003 18:11:19 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from bosvwl01.infosys.com (bosvwl01.infosys.com [216.52.49.35]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h484mFX65933 for ; Wed, 7 May 2003 21:48:15 -0700 (PDT) (envelope-from bharat_joshi@infosys.com) Received: from 192.168.200.82 by bosvwl01.infosys.com (InterScan E-Mail VirusWall NT); Thu, 08 May 2003 00:48:59 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 May 2003 10:18:28 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 May 2003 10:18:27 +0530 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [pim] PIM BSR Draft Message-ID: <56E2573C375A414191118970BDE06A150ABE5EA8@kecmsg06.ad.infosys.com> Thread-Topic: [pim] PIM BSR Draft Thread-Index: AcMU+jGJHJyn8/xgQeCrsfPCtu5KawAIdbwB From: "bharat_joshi" To: "Rishabh Parekh" Cc: X-OriginalArrivalTime: 08 May 2003 04:48:27.0403 (UTC) FILETIME=[10A59DB0:01C3151D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h484mFX65933 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 May 2003 10:18:27 +0530 Content-Transfer-Encoding: 8bit Hi Rishabh, I think I got your point here and I agree to it. But I think when this new router sends a BSM after getting elected, he will send an empty BSM to all PIM routers (because this new router doesn't have any information about the C-RPs) and all these routers will discard the old RP-Set and try to store the new RP set which is right now not there. It means there won't be any information in the RP-Set. now when C-RPs send their details to this new BSR and and this new BSR create a RP-Set and send it to all PIM routers. During all these activities every router in this domain will not have the group-rp set information. This is what is my worry. will it be this way or not?? If it is this way than is it been taken care of? Thanks, Bharat -----Original Message----- From: Rishabh Parekh [mailto:rishabh@ipinfusion.com] Sent: Thu 5/8/2003 6:07 AM To: bharat_joshi Cc: pim@catarina.usc.edu Subject: Re: [pim] PIM BSR Draft Bharat, When a new router comes up and it becomes an Elected-BSR from a Pending-BSR, it originates a BootStrap message. This BS message is received at the Candidate-RPs (and other ordinary non-CRP non-CBSR PIM routers) and they appoint the new router as the BSR. The C-RPs then advertise thier C-RP messages to the newly elected BSR which builds and distributes the RP set information in subsequent BS messages. I hope this helps to clarify your doubts, Rishabh. On Wednesday 07 May 2003 07:24 am, bharat_joshi wrote: > Hi, > > I was going through the C-BSR draft. > > Can somebody explain what will happen when a new Router comes up and can be > the preferred BSR in the PIM domain? > > The draft mention that a router will be in pending state after start-up and > start BS timer to BS timeout value. > > Lets say that the DR on the network, pass on the BSM to this new router. > > Lets assume that this new router is having higher priority and so should be > elected as a BSR. > > Now the state-machine shows that when in pending state and a non-preferred > BSM is received ..don't do anything. > > Now when the BS timer will expire, this new router will think that he has > become the new elected BSR but he doesn't have any information about the > C-RPs till now as C-RPs would be unicasting their info to the old BSR. > > Either there is something wrong here or I am not able to understand it > properly. > > Can somebody help me in understanding this?? > > TIA, > > Best Regards, > Bharat > > ============================== > Infosys Technologies Ltd. > Bangalore, India > > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Fri May 9 00:01:42 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22016 for ; Fri, 9 May 2003 00:01:41 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h493xeX91104; Thu, 8 May 2003 20:59:40 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from vulture.icir.org (adsl-67-117-79-130.dsl.sntc01.pacbell.net [67.117.79.130]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h493vFX91060 for ; Thu, 8 May 2003 20:57:15 -0700 (PDT) (envelope-from mjh@vulture.icir.org) Received: from vulture.icir.org (localhost [127.0.0.1]) by vulture.icir.org (8.12.8p1/8.12.3) with ESMTP id h493vDin051368; Thu, 8 May 2003 20:57:13 -0700 (PDT) (envelope-from mjh@vulture.icir.org) From: Mark Handley X-Organisation: ICIR To: "bharat_joshi" cc: "Rishabh Parekh" , pim@catarina.usc.edu Subject: Re: [pim] PIM BSR Draft In-reply-to: Your message of "Thu, 08 May 2003 10:18:27 +0530." <56E2573C375A414191118970BDE06A150ABE5EA8@kecmsg06.ad.infosys.com> Message-ID: <51367.1052452633@vulture.icir.org> Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 08 May 2003 20:57:13 -0700 >But I think when this new router sends a BSM after getting elected, he will se >nd an empty BSM to all PIM routers (because this new router doesn't have any i >nformation about the C-RPs) and all these routers will discard the old RP-Set >and try to store the new RP set which is right now not there. It means there w >on't be any information in the RP-Set. > >now when C-RPs send their details to this new BSR and and this new BSR create >a RP-Set and send it to all PIM routers. During all these activities every rou >ter in this domain will not have the group-rp set information. This is what is > my worry. The current spec is sadly lacking in detail here, although if you read between the lines it is possible to devine the intent from the sections on semantic fragmentation. Here's the gist of what I propose to be added to the spec: 1. When the BSR times out, and no alternative BSR is elected, routers continue to use their cached RP Set, even though it has timed out. 2. When a router receives an *empty* BSM from a new BSR that wins the election, it continues to use the cached RP Set. This would be the case anyway for any group ranges not listed in the empty BSM. 3. When a router receives a non-empty BSM from a new BSM that wins the election, it will switch to using the new RP set. However, this is not necessarily an instantaneous switch. The old BSM may have listed multiple group-ranges, each of which was spread across multiple semantically-fragmented BSM packets. So, a router continues to use the old RP Set information for each group range until either that group range has timed out, or it has received all the BSM packets for that group range (as indicated by the RP count information in the RP Set) from the new BSR. 4. A well-designed BSM implementation will issue an empty BSM to participate in BSR election. On winning, it will receive C-RP advertisements. If the new BSM has the old RP set, it should not issue a new BSM until it has heard from all the RPs in the old RP set, or a short time interval (say three seconds) has elapsed without receiving new RPs to include in the set, whichever comes first. It should wait a maximum of (say) 30 seconds - if new RPs are still arriving, it should issue the BSM anyway. To remove group-ranges that are no longer in the RP set from the previous RP, it should include those obsolete group-ranges in the BSM with no RPs listed. If the new BSM does not have the old RP set, it should not issue a new BSM until a short time (say three seconds) has elapsed without receiving new RPs to include in the set, whichever comes first. It should wait a maximum of (say) 30 seconds - if new RPs are still arriving, it should issue the BSM anyway. The motivation is to try hard to avoid RP set churn, which not being susceptable to a DoS attack or waiting an excessive amount of time. Does this sound reasonable? The intent was that we trust the old information until we're explicitly told otherwise, or it has timed out after a longish interval. A change of BSM without a change of RP set should not (under normal circumstances) cause any transient change in RP set. Cheers, Mark _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Fri May 9 02:38:00 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06748 for ; Fri, 9 May 2003 02:38:00 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h496aBX93896; Thu, 8 May 2003 23:36:14 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h496XSX93839 for ; Thu, 8 May 2003 23:33:28 -0700 (PDT) (envelope-from prashantj@future.futsoft.com) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 09 May 2003 10:37:23 +0530 Received: from prashantj (prashantj.future.futsoft.com [10.4.5.41]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h494tisI031467; Fri, 9 May 2003 10:25:45 +0530 Reply-To: From: "Prashant Jhingran" To: "'bharat_joshi'" , "'Rishabh Parekh'" Cc: Subject: RE: [pim] PIM BSR Draft Message-Id: <000401c315e7$72b689e0$2905040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MS-TNEF-Correlator: 0000000045BADF0C9A09D5118BCD00D0096F9277E4F11902 Importance: Normal In-Reply-To: <56E2573C375A414191118970BDE06A150ABE5EA8@kecmsg06.ad.infosys.com> Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C31615.8C6EC5E0" Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 May 2003 10:27:09 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C31615.8C6EC5E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit The discussion seems to be interesting. Well definitely it will be as you described. Candidate BSRs are present mainly for backup purposes while the CRPs may solve the dual purpose of load sharing as well as backup RP. Now in order to prevent this black hole although for a short period of time you may come up with an implementation specific solution like storing the new BSR address and at the same time not loosing the CRP information for a short timer interval, lets say 125 secs (60 sec for new BSR mesg + 60 sec for CRP Adv time + 5 sec for propagation delay). This may lead to a faster convergence and I think black hole may also be prevented. However the authors may come up with a standard solution. Regards, Prashant -----Original Message----- From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of bharat_joshi Sent: Thursday, May 08, 2003 10:18 AM To: Rishabh Parekh Cc: pim@catarina.usc.edu Subject: RE: [pim] PIM BSR Draft Hi Rishabh, I think I got your point here and I agree to it. But I think when this new router sends a BSM after getting elected, he will send an empty BSM to all PIM routers (because this new router doesn't have any information about the C-RPs) and all these routers will discard the old RP-Set and try to store the new RP set which is right now not there. It means there won't be any information in the RP-Set. now when C-RPs send their details to this new BSR and and this new BSR create a RP-Set and send it to all PIM routers. During all these activities every router in this domain will not have the group-rp set information. This is what is my worry. will it be this way or not?? If it is this way than is it been taken care of? Thanks, Bharat -----Original Message----- From: Rishabh Parekh [mailto:rishabh@ipinfusion.com] Sent: Thu 5/8/2003 6:07 AM To: bharat_joshi Cc: pim@catarina.usc.edu Subject: Re: [pim] PIM BSR Draft Bharat, When a new router comes up and it becomes an Elected-BSR from a Pending-BSR, it originates a BootStrap message. This BS message is received at the Candidate-RPs (and other ordinary non-CRP non-CBSR PIM routers) and they appoint the new router as the BSR. The C-RPs then advertise thier C-RP messages to the newly elected BSR which builds and distributes the RP set information in subsequent BS messages. I hope this helps to clarify your doubts, Rishabh. On Wednesday 07 May 2003 07:24 am, bharat_joshi wrote: > Hi, > > I was going through the C-BSR draft. > > Can somebody explain what will happen when a new Router comes up and can be > the preferred BSR in the PIM domain? > > The draft mention that a router will be in pending state after start-up and > start BS timer to BS timeout value. > > Lets say that the DR on the network, pass on the BSM to this new router. > > Lets assume that this new router is having higher priority and so should be > elected as a BSR. > > Now the state-machine shows that when in pending state and a non-preferred > BSM is received ..don't do anything. > > Now when the BS timer will expire, this new router will think that he has > become the new elected BSR but he doesn't have any information about the > C-RPs till now as C-RPs would be unicasting their info to the old BSR. > > Either there is something wrong here or I am not able to understand it > properly. > > Can somebody help me in understanding this?? > > TIA, > > Best Regards, > Bharat > > ============================== > Infosys Technologies Ltd. > Bangalore, India > > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0005_01C31615.8C6EC5E0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgoEAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBQAJAAoAGwAAAAUAEgEB A5AGACANAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAUAAAAW3BpbV0gUElNIEJTUiBEcmFmdAACAXEAAQAAABYAAAABwxXncf+KKuqH ggMR14vXANAJb5J3AAACAR0MAQAAACIAAABTTVRQOlBSQVNIQU5USkBGVVRVUkUuRlVUU09GVC5D T00AAAALAAEOAAAAAEAABg4Adpds5xXDAQIBCg4BAAAAGAAAAAAAAABFut8MmgnVEYvNANAJb5J3 woAAAAMAFA4BAAAACwAfDgEAAAACAQkQAQAAADAJAAAsCQAA0BEAAExaRnVhzniZAwAKAHJjcGcx MjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAG wxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFDzCwkBZDM2FlALpgrjCoAgVGhlIGQEAGN1 lQQQaQIgIBQQZW0EIPB0byBiHXALgA6wGCAEc3QLgGcuIFdlLmwDIAEBC4BpDrBseV8e8AVAA/Af 8R7RYQQgeW8IYCARBPIe0GQfsBz0QxMAcB2QZGEOsCBCU+5SBCAKwB1wcB9BCfAFQF8AwAuAIKEC EAXAYgDQa8x1cCQgCHBwbxQQBCAsd2gDEB1wdB1hQ1KuUAQgAMAgsHMG8HYmpAxkdQdAJcYgb2Yg eRewYWQeMBPhH4EhcnefH+IhgSVlJxAihk5vB+D/C4Ao8AsgEoEeoSQxJ8AkgZ8mwAQAHsALYCWA IGgG8E0hYWwmwAhgZ2glE2H/KXEXwSQgBnEEcCjyH3AHgP8hoydSBaAwUSWhA/AmwCFw/wOgB3AL UB5gJHEjYB4DL5AuYwaQDeAngnUyo2xpvmsdcB9gBbApwibCbgfR8yOhIXBkZB9BI9EjICFwmy0i NEFhMFEwM25vBUD/F7AmEDSmJwEe8SUhAMAyo68u2jAyBcAfA3YHQCwpIL8UIAQgNtAgsA4hHjFj BCB+KBwxPAElEzUmB4Ep4CvGIDxpOHJBZHYwJD3g1zvjJRMkMG8KsGcylAEA+QtgeSkfsB1QLWEn UiaQdylRHqEvEGYhgB8hMPFuaSfAcmcJ8GMhYTYxSf0tMm4t0C2ZJ1IHQCeQHsLvLMUiYRz0HPRI K9As4Sxx/R1hYTOwL0EnNDEMNFEjEWcLETN3RqVSZUCQCyBz8iwc9FByIYAT4AIwRrpqLU2CTwUQ ZwuAKFFNWzXhQIBlTYMc9EYDYTorJCAHcC0pUG0LgEBjkyNgKaJhLh3QYy4JgM0h0FsksS5QbzpP 71D3TF1PC5AdA0JlE+BsNSkQTykQYhPhI2Bfav8mECZwHPQGYAIwT8AdUAhwKnMjUHk7EE0nYTA4 EzsQAdAwMzuwMDox+jgQwE0c9VHwB/AEABPgSVTgIFAj8WtoIqVjx0/DUq9VpXViagWQVjFUUkVP wFtSEV1ZYEl6TTVTRExQAYBGukcVad9Y5kvVHPREJkQgZzeBIbH9QCFvHwEt4B8xQ9VAgAnR9x6S IHBGq0IzsEQXJmAJ8P8tNDUiA2AzsBKBJGFLsC8B/yOgXWBd4RKBQ4ACQCnCH+D/XFEJgDsQHWEh A2ZyMcIeYP8FMCCwZvJCYh/xXUJmBDwxnx7QUIAd0CaiZZxkbweQ9G4nYhFhJ8EAcCCxOMnXAaBm ESa0LScRKTYUH/H/JsEo0Wr2IQMdkkoyJsIG8DspYCcQLQZgBUA2InRy/yCwHqE0YiakNSI4gRQR JlLvE9Ae8AQgTeFoBUA3cAfg7zdyJsEYIB+wSSSRQiAGMf92cyDwAiBtUSFSbe0sASbCf3KURqt1 8mUjb3NpFCbBaf9s4RQgUbEeg2V3NWNpQ3Hy/315BQBCICNxLxBymWkjINH1ak9zH7BECHEp0nA3 AND9H3B2IHAIkAQgR6IgsGYF/3ljLWFtACSyIPQ3cm2DJsLzCcAIYHAtJfB0szi5QWW/LWEmYDZh QaIgsHfQcnNQ30arIQMg0R7RLUN3J2E84vk3gD8/X+spECDRLWGLt98mwDHSiOF4EmVCYTQwA6Bf ccEo4oy7HVAAcGtLxkL/VPNeH01/To9PkgyCWO1Rh/sFEFkTQAUgOLEd0ErCMQEeXVWpleNWYT+Q Lzgv4VeDNjowN1gqleNU799aIpXjWn9bj5XkZVzPXd77khRL1VdlMi8QZckxAgQgXyWhNiKLU6Rk A5FFaCQt9zViA1IvAVBmgR+BpoI7EH8c9CDRNIGUEg6wZrM3wHT6U3NAYSWwB4GUokFlI6D/qgZ1 UwWQfGAnwDZHIq17o/4oNiI3gGIxLCKUIXNRN3D8bi04cq9TNWJquW/EJsH/ILAc9KngYdQ05mYF IYEmwv8joUFib1Umsm6xPwAEkB9w/2vUEoFvchzlqhV9BTUDIKHnaBU1U3UEYnUDEGaiNjH/HZFz QCJAZiGzpHSVqBV4vPZzXCAUEHEKUCSBqviCQJ9f7C3wL5AtNB1gbHAeg/5jC2AGgSCwYYNtAFwg O1DfS9VY9UarU8AfwWQ1IFaiH1cwmxBXAleDmwA6MjT9IXBtOxCcOiDwA2AOsJXQ2R0DPiBfMEvV PsamRCD/jAAEIGFANKRmAS6hbzQ1Yv81wF3hRqXHtyMBJ4EHgAbg+mS4MXgLU4kkIQMT4LIw/2VB ZSOjlAgApB+P8QOgHtD3xqYmwiQxZgSQGCE1U3ll/6DihYSMtce3HVNd0j2BAjD/HgKOoXLhZfYh BiwBzZGnct9J0n+yZ0NJ4QAgLaTExqb/18Oq4jo0HqHZZW7yOuEKUN3Kfkw7RtTzJsJENYDUw/U1 AnSJ4Ws7EAqwBBHddd9qBWV92y87Qt6BdTby3MT/ZZy/om2QKcImcC6gEoEkMP8eAAUQadGAc3OR LnFyYdAI/7hWIYFm0rQgx10rwjaT1xLeLQDBRFE0QS3wd3dSzOL/ZTLWXzYjr0PQ58amZvKrqvwu Lm0AbUJtAHhSREIfoH/n33sls8Q6JSEDzEF8cGV/OxBlfiEDRETU8x1hE+Bz/8ampWQ017hauoFo km0Pbh//JrLK97SkhgQH4CGBe5R30P/l5DFAAwBQgB9jfDU4srd293JS55/HAEUxkUfEJAEtYf/L su/DxjLkEmJCBbFiwacA/zdyDKAmkh6w/TAVgUnjIMH/xqZAQhWQIKDKf8uKv9I9gT8r8gQINKS6 MIym00hJQf/HTlRAH2CgMUuK7cGSKce3nj0OXw8qx8c4wXN5ZrB6VDwQaDdwF7CUEKkhTP50Rpbt wUyQDCAXsfMRELDtHZBhx1zGpl8VLxY/Fwr/BNcyACSiNBAp0TQQH2AYGQeeD8amdcB0cDovL81Q ji9Roumgbi8ZUjiy/i9SEZJ/XmsXDyF/F0+yAH8YnyN2Gk+TNBvfHO8d/n0BKfAeAEIQAQAAAEMA AAA8NTZFMjU3M0MzNzVBNDE0MTkxMTE4OTcwQkRFMDZBMTUwQUJFNUVBOEBrZWNtc2cwNi5hZC5p bmZvc3lzLmNvbT4AAAMACVkBAAAACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKA CCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMACIAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAA AAAAAwAtgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAD9xAQAeAC6ACCAGAAAAAADAAAAAAAAARgAA AABUhQAAAQAAAAQAAAA5LjAACwAvgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAALADOACCAG AAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMANIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAA AwA2gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAACAfgPAQAAABAAAABFut8MmgnVEYvNANAJ b5J3AgH6DwEAAAAQAAAARbrfDJoJ1RGLzQDQCW+SdwIB+w8BAAAASwAAAAAAAAA4obsQBeUQGqG7 CAArKlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAARDpcbWFpbFxwcmFzaGFudGou cHN0AAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDA0NUJBREYwQzlBMDlENTEx OEJDRDAwRDAwOTZGOTI3N0U0RjExOTAyAAAAAAMABhBy4F+cAwAHEFsLAAADABAQAAAAAAMAERAA AAAAHgAIEAEAAABlAAAAVEhFRElTQ1VTU0lPTlNFRU1TVE9CRUlOVEVSRVNUSU5HV0VMTERFRklO SVRFTFlJVFdJTExCRUFTWU9VREVTQ1JJQkVEQ0FORElEQVRFQlNSU0FSRVBSRVNFTlRNQUlOTFlG TwAAAAAdKg== ------=_NextPart_000_0005_01C31615.8C6EC5E0-- _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat May 10 06:28:56 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28104 for ; Sat, 10 May 2003 06:28:55 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4AAQfX24437; Sat, 10 May 2003 03:26:42 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from bosvwl02.infosys.com (bosvwl02.infy.com [216.52.49.36]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4AAMEX24352 for ; Sat, 10 May 2003 03:22:14 -0700 (PDT) (envelope-from bharat_joshi@infosys.com) Received: from 192.168.200.82 by bosvwl02.infosys.com (InterScan E-Mail VirusWall NT); Sat, 10 May 2003 06:23:59 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 10 May 2003 15:52:42 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 10 May 2003 15:52:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [pim] PIM BSR Draft Message-ID: <56E2573C375A414191118970BDE06A150ABE5EB8@kecmsg06.ad.infosys.com> Thread-Topic: [pim] PIM BSR Draft Thread-Index: AcMV38T3qSuUOJDORZysnxyPB3OBwgAQIuz6AC9slVk= From: "bharat_joshi" To: "Mark Handley" Cc: X-OriginalArrivalTime: 10 May 2003 10:22:42.0144 (UTC) FILETIME=[1707BE00:01C316DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4AAMEX24352 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 May 2003 15:52:41 +0530 Content-Transfer-Encoding: 8bit >But I think when this new router sends a BSM after getting elected, he will se >nd an empty BSM to all PIM routers (because this new router doesn't have any i >nformation about the C-RPs) and all these routers will discard the old RP-Set >and try to store the new RP set which is right now not there. It means there w >on't be any information in the RP-Set. > >now when C-RPs send their details to this new BSR and and this new BSR create >a RP-Set and send it to all PIM routers. During all these activities every rou >ter in this domain will not have the group-rp set information. This is what is > my worry. The current spec is sadly lacking in detail here, although if you read between the lines it is possible to devine the intent from the sections on semantic fragmentation. Here's the gist of what I propose to be added to the spec: 1. When the BSR times out, and no alternative BSR is elected, routers continue to use their cached RP Set, even though it has timed out. 2. When a router receives an *empty* BSM from a new BSR that wins the election, it continues to use the cached RP Set. This would be the case anyway for any group ranges not listed in the empty BSM. 3. When a router receives a non-empty BSM from a new BSM that wins the election, it will switch to using the new RP set. However, this is not necessarily an instantaneous switch. The old BSM may have listed multiple group-ranges, each of which was spread across multiple semantically-fragmented BSM packets. So, a router continues to use the old RP Set information for each group range until either that group range has timed out, or it has received all the BSM packets for that group range (as indicated by the RP count information in the RP Set) from the new BSR. 4. A well-designed BSM implementation will issue an empty BSM to participate in BSR election. On winning, it will receive C-RP advertisements. If the new BSM has the old RP set, it should not issue a new BSM until it has heard from all the RPs in the old RP set, or a short time interval (say three seconds) has elapsed without receiving new RPs to include in the set, whichever comes first. It should wait a maximum of (say) 30 seconds - if new RPs are still arriving, it should issue the BSM anyway. To remove group-ranges that are no longer in the RP set from the previous RP, it should include those obsolete group-ranges in the BSM with no RPs listed. If the new BSM does not have the old RP set, it should not issue a new BSM until a short time (say three seconds) has elapsed without receiving new RPs to include in the set, whichever comes first. It should wait a maximum of (say) 30 seconds - if new RPs are still arriving, it should issue the BSM anyway. The motivation is to try hard to avoid RP set churn, which not being susceptable to a DoS attack or waiting an excessive amount of time. Does this sound reasonable? The intent was that we trust the old information until we're explicitly told otherwise, or it has timed out after a longish interval. A change of BSM without a change of RP set should not (under normal circumstances) cause any transient change in RP set. Cheers, Mark >>>>>>>>>>>>>>>>>>>>>>>> Hi Mark, I agree with you on almost all the points you have listed above. But I think we can avoid a downtime using the following method: As per the draft, when a new PIM router comes UP, he start sending hello messages. The DR on the LAN will send a Hello message as well as a copy of the Last BSM to this new router. If this router is configured to be a C-BSR, it will compare himself with this BSM, if this new router wins than he can use the same RP set which he has just recieved from the Neighbor and start sending BSM messages with this RP set. This way there won't be any down time and every router/switch will have the same RP set. I think this will not create any problem as RP set will not change till a C-RP himself change it. And when this new BSM will reach to C-RPs, they can findout that this is now the elected BSR and so they will start sending their C-RP adv to this new BSR. In case of point to point link also, the same can be achieved. Another issue here is: When A router is a Candidate BSR, We don't have a event "Received Non_preferred BSM from a new C-BSR" With my proposed solution this can also be taken care of. otherwise, when we receive such BSM, we can simply discard it. Next question could be about the DOS attack in my proposed solution. Now if any router forges a BSM message and send it to the new router, still only this router will get affected. Lets say this new router think he is the elected BSR now and start sending BSMs but no other router will accept him as preferred BSR and drop this new BSM and the elected BSR will originate the BSM as per the state table. Does it make sense?? If somebody think this is not a good idea,please let me know the details. Thanks for your time, Bharat _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat May 10 16:02:18 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07640 for ; Sat, 10 May 2003 16:02:17 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4AK07X36748; Sat, 10 May 2003 13:00:07 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from gateway.ipinfusion.com (mail.ipinfusion.com [65.223.109.2]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4AJvKX36673 for ; Sat, 10 May 2003 12:57:20 -0700 (PDT) (envelope-from rogerlin@ipinfusion.com) Received: from ipinfusion.com (rogerlin.ipinfusion.com [10.10.0.91] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id h4AJupi29654 for ; Sat, 10 May 2003 12:56:51 -0700 Message-ID: <3EBD5859.339BA0FF@ipinfusion.com> From: Roger Lin Organization: IP Infusion Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pim@catarina.usc.edu Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Subject: [pim] A neophyte's confusion Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 May 2003 12:51:53 -0700 Content-Transfer-Encoding: 7bit Hi, I am beginner to routing/multicasting, so please don't shoot me before I have the chance to air my confusion, and hopefully someone will answer my questions regarding PIM-SM even if they don't make much sense. (1). There seems to be a disconnect between DR election policy (based on dr_election_priority and higher ipaddr) and underlying unicast selection of nexthop router: MRIB.next_hop(S), based on routing metric. Let's ignore dr_election_priority since it is an override tool for administrators to play favoritism, but that still leaves ipaddr to face metric. The winner at the ipaddr game is not necessarily better at the metrics, so we end up with the possibility that the DR may not be the MRIB.next_hop(S). This means that if there are both local membership and downstream join state on interface I, then both the DR and the winner of MRIB.next_hop(S) will try to forward data on I, and they will have to fight it out using assert mechanism, which was really designed for dealing with inconsistent MRIB entries and RPT/SPT conflict. If MRIB.next_hop were used instead of ipaddress of routers in DR election, we could cut down some unnecessary use of asserts; why is MRIB.next_hop not used? (2). The PIM-SM draft never mentions that multicast source S not be more than single-homed (meaning connected only to a single multicast-capable interface); If they are allowed to connect to more than one, then there will be more than one DRs doing register/encapsulation to RP, and since RPs don't make sure that all register pkts from S come from the same DR, they will forward more than one copies of data pkts down the RP trees. Is it a given that multicast sources be single-homed? Best Regards, Roger Lin _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat May 10 17:49:26 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09067 for ; Sat, 10 May 2003 17:49:26 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4ALmhX38623; Sat, 10 May 2003 14:48:44 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from dmz2.procket.com (dmz2.procket.com [65.174.124.37]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4ALkxX38587 for ; Sat, 10 May 2003 14:46:59 -0700 (PDT) (envelope-from John.Zwiebel@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id B58C93442A; Sat, 10 May 2003 14:01:12 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4ALkoYB027598; Sat, 10 May 2003 14:46:50 -0700 (PDT) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 10 May 2003 14:46:50 -0700 Subject: Re: [pim] A neophyte's confusion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: pim@catarina.usc.edu To: Roger Lin From: John Zwiebel In-Reply-To: <3EBD5859.339BA0FF@ipinfusion.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 10 May 2003 21:46:50.0241 (UTC) FILETIME=[A99A4710:01C3173D] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 May 2003 14:45:01 -0700 Content-Transfer-Encoding: 7bit On Saturday, May 10, 2003, at 12:51 PM, Roger Lin wrote: > > (1). There seems to be a disconnect between DR election policy (based > on dr_election_priority > and higher ipaddr) and underlying unicast selection of nexthop > router: A PIM DR has nothing to do with unicast metrics. Its just a way of selecting a single router on a lan to be the system that makes the decisions for that LAN. The DR isn't necessarily responsible for forwarding packets on to a LAN. It won't if the unicast metrics have the DR join toward the source through the interface it was elected DR on. If there is a case where there are two routers forwarding, then yes an assert happens. In the scenerio you describe It would be rare for a down stream router to select a next hop that wasn't the DR since most often then the DR would also select the same router as its next-hop. Not always. And why complicate selection of the DR to save a couple of asserts? > > This means that if there are both local membership and downstream > join > state on interface I, > then both the DR and the winner of MRIB.next_hop(S) will try to > forward data on I, and > they will have to fight it out using assert mechanism, which was > really > designed for dealing with inconsistent MRIB entries and RPT/SPT > conflict. > > If MRIB.next_hop were used instead of ipaddress of routers in DR > election, we could > cut down some unnecessary use of asserts; why is MRIB.next_hop not > used? > > > (2). The PIM-SM draft never mentions that multicast source S not be > more than single-homed > (meaning connected only to a single multicast-capable interface); If > they are allowed to connect > to more than one, then there will be more than one DRs doing > register/encapsulation to RP, > and since RPs don't make sure that all register pkts from S come from > the same DR, they will > forward more than one copies of data pkts down the RP trees. > > Is it a given that multicast sources be single-homed? The source doesn't have to be single-homed, but when was the last time a multi-homed source used the same IP address on more than one interface? That would cause unicast routing problems as well wouldn't it? _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat May 10 18:50:32 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10766 for ; Sat, 10 May 2003 18:50:32 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4AMmbX39676; Sat, 10 May 2003 15:48:37 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from gateway.ipinfusion.com (mail.ipinfusion.com [65.223.109.2]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4AMklX39635 for ; Sat, 10 May 2003 15:46:47 -0700 (PDT) (envelope-from rogerlin@ipinfusion.com) Received: from ipinfusion.com (rogerlin.ipinfusion.com [10.10.0.91] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id h4AMkCi31207; Sat, 10 May 2003 15:46:12 -0700 Message-ID: <3EBD800B.690AD72E@ipinfusion.com> From: Roger Lin Organization: IP Infusion Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Zwiebel CC: pim@catarina.usc.edu Subject: Re: [pim] A neophyte's confusion References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 May 2003 15:41:15 -0700 Content-Transfer-Encoding: 7bit John, Thanks for the rapid response. With regard to item (2), I was refering to multiple interfaces on the source host, each with its own IPAddress. On item (1), the DR on a downstream interface will decide to forward if there are local membership on the particular interface, regardless whether a downstream router (which regards the interface as upstream) decide to do join(*,G) or join(S,G) to another router on the interface, since the DR's include(*,G) or include(S,G) macro will become true on the interface, which will cause its inherited_olist on the interface to go true, too, forcing it to become a forwarder onto the interface for G. I am simply saying that it seems to be so natual for DR to use unicast routing metric toward S to decide the DR instead of their respective IPAddress. Best regards, Roger Lin John Zwiebel wrote: > On Saturday, May 10, 2003, at 12:51 PM, Roger Lin wrote: > > > > > (1). There seems to be a disconnect between DR election policy (based > > on dr_election_priority > > and higher ipaddr) and underlying unicast selection of nexthop > > router: > > A PIM DR has nothing to do with unicast metrics. Its just a way of > selecting a single router on a lan to be the system that makes > the decisions for that LAN. > > The DR isn't necessarily responsible for forwarding packets on > to a LAN. It won't if the unicast metrics have the DR join toward > the source through the interface it was elected DR on. > > If there is a case where there are two routers forwarding, then > yes an assert happens. > > In the scenerio you describe > It would be rare for a down stream router to select a next hop > that wasn't the DR since most often then the DR would also > select the same router as its next-hop. Not always. > > And why complicate selection of the DR to save a couple of asserts? > > > > > This means that if there are both local membership and downstream > > join > > state on interface I, > > then both the DR and the winner of MRIB.next_hop(S) will try to > > forward data on I, and > > they will have to fight it out using assert mechanism, which was > > really > > designed for dealing with inconsistent MRIB entries and RPT/SPT > > conflict. > > > > If MRIB.next_hop were used instead of ipaddress of routers in DR > > election, we could > > cut down some unnecessary use of asserts; why is MRIB.next_hop not > > used? > > > > > > (2). The PIM-SM draft never mentions that multicast source S not be > > more than single-homed > > (meaning connected only to a single multicast-capable interface); If > > they are allowed to connect > > to more than one, then there will be more than one DRs doing > > register/encapsulation to RP, > > and since RPs don't make sure that all register pkts from S come from > > the same DR, they will > > forward more than one copies of data pkts down the RP trees. > > > > Is it a given that multicast sources be single-homed? > > The source doesn't have to be single-homed, but when was the > last time a multi-homed source used the same IP address on > more than one interface? > > That would cause unicast routing problems as well wouldn't it? > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat May 10 19:09:16 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10940 for ; Sat, 10 May 2003 19:09:15 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4AN8bX40123; Sat, 10 May 2003 16:08:37 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4AN6ZX40083 for ; Sat, 10 May 2003 16:06:35 -0700 (PDT) (envelope-from John.Zwiebel@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 4568A23C32; Sat, 10 May 2003 15:55:01 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4AN6TYB000511; Sat, 10 May 2003 16:06:29 -0700 (PDT) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 10 May 2003 16:06:29 -0700 Subject: Re: [pim] A neophyte's confusion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: pim@catarina.usc.edu To: Roger Lin From: John Zwiebel In-Reply-To: <3EBD800B.690AD72E@ipinfusion.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 10 May 2003 23:06:29.0207 (UTC) FILETIME=[CA169E70:01C31748] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 May 2003 16:04:40 -0700 Content-Transfer-Encoding: 7bit On Saturday, May 10, 2003, at 03:41 PM, Roger Lin wrote:\ > I am simply saying that it seems to be so natual for DR to use unicast > routing metric > toward S to decide the DR instead of their respective IPAddress. > After the DR is selected it does use the unicast metric to send joins toward the source. You don't want to have to select a different DR for every source. My point was, how do you determine the next-hop is you don't have a source? You might say, select the DR based on the metrics toward the RP, but then what if there are multiple RPs? PIM DR selection is similar to the OSPF DR selection. It most often doesn't matter which router is selected as the DR just as long as someone is. Your challenge is to provide a topology where it matters and then to show that this topology happens often enough that it is important to change the way DRs have been selected for over 10 years. And then you have to show that its important enough that as we deprecate ASM and move toward SSM and bi-dir that the change is going to bare fruit. I think you can see you are up against an awful lot of inertia. _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 12 14:10:11 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26123 for ; Mon, 12 May 2003 14:10:09 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4CI9XX86471; Mon, 12 May 2003 11:09:33 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from gateway.ipinfusion.com (mail.ipinfusion.com [65.223.109.2]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4CI5oX86396 for ; Mon, 12 May 2003 11:05:50 -0700 (PDT) (envelope-from rogerlin@ipinfusion.com) Received: from ipinfusion.com (rogerlin.ipinfusion.com [10.10.0.91] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id h4CI5Hi06645; Mon, 12 May 2003 11:05:17 -0700 Message-ID: <3EBFE132.A5339013@ipinfusion.com> From: Roger Lin Organization: IP Infusion Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Zwiebel CC: pim@catarina.usc.edu Subject: Re: [pim] A neophyte's confusion References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 May 2003 11:00:18 -0700 Content-Transfer-Encoding: 7bit I also realized after replying to you Saturday that since PIM's DR selection is per interface, not per (source, interface) as in the case of Default Forwarder selection in DVMRP, it is simply not correct to use MRIB.next_hop to do selection. Any thoughts on my question about multuple DR(SUBNET_OF(S))? Best regards, Roger John Zwiebel wrote: > On Saturday, May 10, 2003, at 03:41 PM, Roger Lin wrote:\ > > > I am simply saying that it seems to be so natual for DR to use unicast > > routing metric > > toward S to decide the DR instead of their respective IPAddress. > > > After the DR is selected it does use the unicast metric to send joins > toward the source. You don't want to have to select a different > DR for every source. > > My point was, how do you determine the next-hop is you don't have > a source? You might say, select the DR based on the metrics toward > the RP, but then what if there are multiple RPs? > > PIM DR selection is similar to the OSPF DR selection. It most often > doesn't matter which router is selected as the DR just as long as > someone is. > > Your challenge is to provide a topology where it matters and then > to show that this topology happens often enough that it is important > to change the way DRs have been selected for over 10 years. And > then you have to show that its important enough that as we deprecate > ASM and move toward SSM and bi-dir that the change is going to > bare fruit. > > I think you can see you are up against an awful lot of inertia. > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 12 14:12:50 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26228 for ; Mon, 12 May 2003 14:12:49 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4CIDJX86571; Mon, 12 May 2003 11:13:19 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from dmz2.procket.com (dmz2.procket.com [65.174.124.37]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4CIB4X86502 for ; Mon, 12 May 2003 11:11:04 -0700 (PDT) (envelope-from John.Zwiebel@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 56D083443F; Mon, 12 May 2003 10:25:22 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4CIAwYB028771; Mon, 12 May 2003 11:10:58 -0700 (PDT) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 May 2003 11:10:58 -0700 Subject: Re: [pim] A neophyte's confusion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: John Zwiebel , pim@catarina.usc.edu To: Roger Lin From: John Zwiebel In-Reply-To: <3EBFE132.A5339013@ipinfusion.com> Message-Id: <16080409-84A5-11D7-BC9B-00039307689E@procket.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 12 May 2003 18:10:58.0177 (UTC) FILETIME=[D665A710:01C318B1] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 May 2003 11:11:00 -0700 Content-Transfer-Encoding: 7bit On Monday, May 12, 2003, at 11:00 AM, Roger Lin wrote: > > > Any thoughts on my question about multuple DR(SUBNET_OF(S))? > > If its the question about multiple DRs registering for the same source, you already answered it. A multihomed source uses a different IP address for every interface. PIM uses (S,G) to determine the source. If a source is sending the same content using different IP addresses, there's no way for PIM (or for that matter any IP based multicast routing protocol) to determine that the content is the same thing. In any case, there is no reason to source multiple streams of the same thing. That's what multicast is all about. _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 12 20:11:38 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09582 for ; Mon, 12 May 2003 20:11:37 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4D096X92976; Mon, 12 May 2003 17:09:07 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from bosvwl01.infosys.com (bosvwl01.infosys.com [216.52.49.35]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h49D7QX01477 for ; Fri, 9 May 2003 06:07:26 -0700 (PDT) (envelope-from bharat_joshi@infosys.com) Received: from 192.168.200.81 by bosvwl01.infosys.com (InterScan E-Mail VirusWall NT); Fri, 09 May 2003 09:08:01 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 9 May 2003 18:37:37 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 9 May 2003 18:37:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [pim] PIM BSR Draft Message-ID: <56E2573C375A414191118970BDE06A150ABE5EB4@kecmsg06.ad.infosys.com> Thread-Topic: [pim] PIM BSR Draft Thread-Index: AcMV38T3qSuUOJDORZysnxyPB3OBwgAQIuz6 From: "bharat_joshi" To: "Mark Handley" Cc: "Rishabh Parekh" , X-OriginalArrivalTime: 09 May 2003 13:07:37.0689 (UTC) FILETIME=[F6D25490:01C3162B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h49D7QX01477 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 May 2003 18:37:37 +0530 Content-Transfer-Encoding: 8bit >But I think when this new router sends a BSM after getting elected, he will se >nd an empty BSM to all PIM routers (because this new router doesn't have any i >nformation about the C-RPs) and all these routers will discard the old RP-Set >and try to store the new RP set which is right now not there. It means there w >on't be any information in the RP-Set. > >now when C-RPs send their details to this new BSR and and this new BSR create >a RP-Set and send it to all PIM routers. During all these activities every rou >ter in this domain will not have the group-rp set information. This is what is > my worry. The current spec is sadly lacking in detail here, although if you read between the lines it is possible to devine the intent from the sections on semantic fragmentation. Here's the gist of what I propose to be added to the spec: 1. When the BSR times out, and no alternative BSR is elected, routers continue to use their cached RP Set, even though it has timed out. 2. When a router receives an *empty* BSM from a new BSR that wins the election, it continues to use the cached RP Set. This would be the case anyway for any group ranges not listed in the empty BSM. 3. When a router receives a non-empty BSM from a new BSM that wins the election, it will switch to using the new RP set. However, this is not necessarily an instantaneous switch. The old BSM may have listed multiple group-ranges, each of which was spread across multiple semantically-fragmented BSM packets. So, a router continues to use the old RP Set information for each group range until either that group range has timed out, or it has received all the BSM packets for that group range (as indicated by the RP count information in the RP Set) from the new BSR. 4. A well-designed BSM implementation will issue an empty BSM to participate in BSR election. On winning, it will receive C-RP advertisements. If the new BSM has the old RP set, it should not issue a new BSM until it has heard from all the RPs in the old RP set, or a short time interval (say three seconds) has elapsed without receiving new RPs to include in the set, whichever comes first. It should wait a maximum of (say) 30 seconds - if new RPs are still arriving, it should issue the BSM anyway. To remove group-ranges that are no longer in the RP set from the previous RP, it should include those obsolete group-ranges in the BSM with no RPs listed. If the new BSM does not have the old RP set, it should not issue a new BSM until a short time (say three seconds) has elapsed without receiving new RPs to include in the set, whichever comes first. It should wait a maximum of (say) 30 seconds - if new RPs are still arriving, it should issue the BSM anyway. The motivation is to try hard to avoid RP set churn, which not being susceptable to a DoS attack or waiting an excessive amount of time. Does this sound reasonable? The intent was that we trust the old information until we're explicitly told otherwise, or it has timed out after a longish interval. A change of BSM without a change of RP set should not (under normal circumstances) cause any transient change in RP set. Cheers, Mark >>>>>> Hi Mark, I agree with you on almost all the points you have listed above. But I think we can avoid a downtime using the following method: As per the draft, when a new PIM router comes UP, he start sending hello messages. The DR on the LAN will send a Hello message as well as a copy of the Last BSM to this new router. If this router is configured to be a C-BSR, it will compare himself with this BSM, if this new router wins than he can use the same RP set which he has just recieved from the Neighbor and start sending BSM messages with this RP set. This way there won't be any down time and every router/switch will have the same RP set. I think this will not create any problem as RP set will not change till a C-RP himself change it. And when this new BSM will reach to C-RPs, they can findout that this is now the elected BSR and so they will start sending their C-RP adv to this new BSR. In case of point to point link also, the same can be achieved. Another issue here is: When A router is a Candidate BSR, We don't have a event "Received Non_preferred BSM from a new C-BSR" With my proposed solution this can also be taken care of. otherwise, when we receive such BSM, we can simply discard it. Next question could be about the DOS attack in my proposed solution. Now if any router forges a BSM message and send it to the new router, still only this router will get affected. Lets say this new router think he is the elected BSR now and start sending BSMs but no other router will accept him as preferred BSR and drop this new BSM and the elected BSR will originate the BSM as per the state table. Does it make sense?? If somebody think this is not a good idea,please let me know the details. Thanks for your time, Bharat _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 12 20:30:16 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09873 for ; Mon, 12 May 2003 20:30:15 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4D0LNX93241; Mon, 12 May 2003 17:21:23 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from motgate6.mot.com ([144.189.100.106]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4D0J2X93180 for ; Mon, 12 May 2003 17:19:02 -0700 (PDT) (envelope-from Chris.Cormier@motorola.com) Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h4D0J1V9016999 for ; Mon, 12 May 2003 17:19:01 -0700 (MST) Received: from il06exm06.corp.mot.com (il06exm06.corp.mot.com [10.0.111.6]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h4D0IxH4031898 for ; Mon, 12 May 2003 19:19:00 -0500 Received: by il06exm06.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 12 May 2003 19:18:58 -0500 Message-ID: From: Cormier Chris-ACC125 To: pim@catarina.usc.edu Subject: RE: [pim] PIM BSR Draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 May 2003 19:18:56 -0500 Also, not to be picky, but for a convenience, can you represent the correct number of bits in the BS message format table: Right now, this table makes it appear as though the encoded fields (encoded-unicast and encoded-group format)are only 32 bits. This is misleading as sometimes people trust these tables. After all, we do have a bit count at the top of the table. Thanks, -chris 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Tag | Hash Mask len | BSR-priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSR Address (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address 1 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Count 1 | Frag RP Cnt 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address 1 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1 Holdtime | RP1 Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address 2 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2 Holdtime | RP2 Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address m (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPm Holdtime | RPm Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address 2 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address n (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Count n | Frag RP Cnt n | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address 1 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP1 Holdtime | RP1 Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Address 2 (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP2 Holdtime | RP2 Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Tue May 13 15:04:54 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24985 for ; Tue, 13 May 2003 15:04:53 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4DIuEX13399; Tue, 13 May 2003 11:56:14 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from gateway.ipinfusion.com (mail.ipinfusion.com [65.223.109.2]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4DIoxX13288 for ; Tue, 13 May 2003 11:50:59 -0700 (PDT) (envelope-from rishabh@ipinfusion.com) Received: from rparekh (dhcp143.ipinfusion.com [10.10.0.143] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id h4DIoPN13862 for ; Tue, 13 May 2003 11:50:25 -0700 Content-Type: text/plain; charset="us-ascii" From: Rishabh Parekh Organization: IP Infusion To: pim@catarina.usc.edu User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200305130130.37560.rishabh@ipinfusion.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4DIoxX13288 Subject: [pim] Slight contradiction about forwarding BSM in the BSR draft Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 May 2003 01:30:37 -0700 Content-Transfer-Encoding: 8bit There seems to be a slight contradiction about forwarding BSMs in the draft-ietf-pim-sm-bsr-03.txt The "Forward BSM" action of Section 3 on page 17 states the following, A bootstrap message that passes the Bootstrap Message Processing Checks is forwarded out of all interfaces with PIM neighbors (including the interface it is received on), except where this would cause the BSM to cross an admin-scope boundary for the scope zone indicated in the message. On the other hand, in Section 3.3 on page 20, there is the following statement When a BS message is forwarded, it is forwarded out of every multicast- capable interface which has PIM neighbors (excluding the one over which the message was received). As discussed in the last IETF meeting, the first description of forwarding BSM is correct and the mistake in Section 3.3 seems to be an oversight of the authors. I hope that it is corrected in the next version of the draft, Rishabh Parekh. _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Tue May 13 15:09:53 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25540 for ; Tue, 13 May 2003 15:09:51 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4DIxaX13498; Tue, 13 May 2003 11:59:36 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from gateway.ipinfusion.com (mail.ipinfusion.com [65.223.109.2]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4DIoxX13290 for ; Tue, 13 May 2003 11:50:59 -0700 (PDT) (envelope-from rishabh@ipinfusion.com) Received: from rparekh (dhcp143.ipinfusion.com [10.10.0.143] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id h4DIoPN13865 for ; Tue, 13 May 2003 11:50:25 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Rishabh Parekh Organization: IP Infusion To: pim@catarina.usc.edu User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200305130130.37560.rishabh@ipinfusion.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4DIoxX13290 Subject: [pim] Slight contradiction about forwarding BSM in the BSR draft Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 May 2003 11:50:10 -0700 Content-Transfer-Encoding: 8bit There seems to be a slight contradiction about forwarding BSMs in the draft-ietf-pim-sm-bsr-03.txt The "Forward BSM" action of Section 3 on page 17 states the following, A bootstrap message that passes the Bootstrap Message Processing Checks is forwarded out of all interfaces with PIM neighbors (including the interface it is received on), except where this would cause the BSM to cross an admin-scope boundary for the scope zone indicated in the message. On the other hand, in Section 3.3 on page 20, there is the following statement When a BS message is forwarded, it is forwarded out of every multicast- capable interface which has PIM neighbors (excluding the one over which the message was received). As discussed in the last IETF meeting, the first description of forwarding BSM is correct and the mistake in Section 3.3 seems to be an oversight of the authors. I hope that it is corrected in the next version of the draft, Rishabh Parekh. _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Tue May 13 15:24:42 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26538 for ; Tue, 13 May 2003 15:24:41 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4DJLTX13993; Tue, 13 May 2003 12:21:29 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4DJIbX13918 for ; Tue, 13 May 2003 12:18:37 -0700 (PDT) (envelope-from Chris.Cormier@motorola.com) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h4DJIZ41024959 for ; Tue, 13 May 2003 12:18:36 -0700 (MST) Received: from il06exm05.corp.mot.com (il06exm05.corp.mot.com [10.0.111.5]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h4DJIZQx032398 for ; Tue, 13 May 2003 14:18:35 -0500 Received: by il06exm05.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 13 May 2003 14:18:34 -0500 Message-ID: From: Cormier Chris-ACC125 To: "'Rishabh Parekh'" , pim@catarina.usc.edu Subject: RE: [pim] Slight contradiction about forwarding BSM in the BSR dr aft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 May 2003 14:18:33 -0500 I believe that the consensus in San Francisco was that it would be optional to forward the message out on the same interface as received. We determined that many network topologies may be able to avoid the RPF divergence issue. If we can determine that there will not be an issue, we should be able to administratively turn this OPTION off. Should be "MAY", not "MUST". -chris -----Original Message----- From: Rishabh Parekh [mailto:rishabh@ipinfusion.com] Sent: Tuesday, May 13, 2003 11:50 AM To: pim@catarina.usc.edu Subject: [pim] Slight contradiction about forwarding BSM in the BSR draft There seems to be a slight contradiction about forwarding BSMs in the draft-ietf-pim-sm-bsr-03.txt The "Forward BSM" action of Section 3 on page 17 states the following, A bootstrap message that passes the Bootstrap Message Processing Checks is forwarded out of all interfaces with PIM neighbors (including the interface it is received on), except where this would cause the BSM to cross an admin-scope boundary for the scope zone indicated in the message. On the other hand, in Section 3.3 on page 20, there is the following statement When a BS message is forwarded, it is forwarded out of every multicast- capable interface which has PIM neighbors (excluding the one over which the message was received). As discussed in the last IETF meeting, the first description of forwarding BSM is correct and the mistake in Section 3.3 seems to be an oversight of the authors. I hope that it is corrected in the next version of the draft, Rishabh Parekh. _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Tue May 13 16:35:50 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28360 for ; Tue, 13 May 2003 16:35:49 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4DKZ1X15311; Tue, 13 May 2003 13:35:02 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from gateway.ipinfusion.com (mail.ipinfusion.com [65.223.109.2]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4DKV4X15233 for ; Tue, 13 May 2003 13:31:05 -0700 (PDT) (envelope-from rishabh@ipinfusion.com) Received: from rparekh (dhcp143.ipinfusion.com [10.10.0.143] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id h4DKUHN19219; Tue, 13 May 2003 13:30:17 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Rishabh Parekh Organization: IP Infusion To: Cormier Chris-ACC125 Subject: Re: [pim] Slight contradiction about forwarding BSM in the BSR dr aft User-Agent: KMail/1.4.3 References: In-Reply-To: Cc: pim@catarina.usc.edu MIME-Version: 1.0 Message-Id: <200305131330.02401.rishabh@ipinfusion.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4DKV4X15233 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 May 2003 13:30:02 -0700 Content-Transfer-Encoding: 8bit Chris, I was just pointing out that the 2 sections seem to be out of sync. The "Forward BSM" action of Section 3 says that the BSM message should be forwarded back on the receiving interface while Section 3.3 says that the BSM message should not be forwarded back on the receiving interface. Regards, Rishabh Parekh. On Tuesday 13 May 2003 12:18 pm, Cormier Chris-ACC125 wrote: > I believe that the consensus in San Francisco was that it would be optional > to forward the message out on the same interface as received. We determined > that many network topologies may be able to avoid the RPF divergence issue. > If we can determine that there will not be an issue, we should be able to > administratively turn this OPTION off. Should be "MAY", not "MUST". > -chris > > -----Original Message----- > From: Rishabh Parekh [mailto:rishabh@ipinfusion.com] > Sent: Tuesday, May 13, 2003 11:50 AM > To: pim@catarina.usc.edu > Subject: [pim] Slight contradiction about forwarding BSM in the BSR > draft > > > There seems to be a slight contradiction about forwarding BSMs in the > draft-ietf-pim-sm-bsr-03.txt > > The "Forward BSM" action of Section 3 on page 17 states the following, > A bootstrap message that passes the Bootstrap Message > Processing Checks is forwarded out of all interfaces with PIM > neighbors (including the interface it is received on), except > where this would cause the BSM to cross an admin-scope > boundary for the scope zone indicated in the message. > > On the other hand, in Section 3.3 on page 20, there is the following > statement > When a BS message is forwarded, it is forwarded out of every multicast- > capable interface which has PIM neighbors (excluding the one over which > the message was received). > > As discussed in the last IETF meeting, the first description of forwarding > BSM > is correct and the mistake in Section 3.3 seems to be an oversight of the > authors. > > I hope that it is corrected in the next version of the draft, > Rishabh Parekh. > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Tue May 13 16:42:00 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28486 for ; Tue, 13 May 2003 16:42:00 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4DKeNX15450; Tue, 13 May 2003 13:40:23 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from aardvark.icir.org (aardvark.icir.org [192.150.187.20]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4DKbfX15383 for ; Tue, 13 May 2003 13:37:41 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) Received: from aardvark.icir.org (localhost [127.0.0.1]) by aardvark.icir.org (8.12.8p1/8.12.3) with ESMTP id h4DKbfZt090234; Tue, 13 May 2003 13:37:41 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ICIR To: Rishabh Parekh cc: Cormier Chris-ACC125 , pim@catarina.usc.edu Subject: Re: [pim] Slight contradiction about forwarding BSM in the BSR dr aft In-reply-to: Your message of "Tue, 13 May 2003 13:30:02 PDT." <200305131330.02401.rishabh@ipinfusion.com> Message-ID: <90233.1052858261@aardvark.icir.org> Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 May 2003 13:37:41 -0700 >I was just pointing out that the 2 sections seem to be out of sync. The >"Forward BSM" action of Section 3 says that the BSM message should be >forwarded back on the receiving interface while Section 3.3 says that the BSM >message should not be forwarded back on the receiving interface. Thanks for pointing this out - I'll fix it. - Mark _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Tue May 13 21:56:10 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06952 for ; Tue, 13 May 2003 21:56:09 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4E1qnX21518; Tue, 13 May 2003 18:52:49 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from hzvscan1.utstar.com.cn ([61.175.193.131]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4E1oGX21465 for ; Tue, 13 May 2003 18:50:17 -0700 (PDT) (envelope-from yxzhang@utstar.com) Received: from hzmail4.cn.utstar.com (hzvscan1 [127.0.0.1]) by hzvscan1.utstar.com.cn (8.11.6/8.11.6) with SMTP id h4E1mXp31681; Wed, 14 May 2003 09:48:33 +0800 Received: from hzmail1.cn.utstar.com ([172.18.9.35]) by hzmail4.cn.utstar.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 14 May 2003 09:49:56 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C319BB.1F1AE624" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <9733CD15FD6A2C418132CE83BCDB16F673705A@hzmail1.cn.utstar.com> Thread-Topic: a question about BSR (In MIB) Thread-Index: AcMZux4v0bnQrkLPS3mNAN0OY6J3wQ== From: "Zhang Yanxing" To: Cc: X-OriginalArrivalTime: 14 May 2003 01:49:56.0962 (UTC) FILETIME=[1F348420:01C319BB] Subject: [pim] a question about BSR (In MIB) Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 May 2003 09:49:56 +0800 This is a multi-part message in MIME format. ------_=_NextPart_001_01C319BB.1F1AE624 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Now I am reading the PIM MIB(rfc2934), I have a question about the = pimInterfaceTable. In this table, there is one entry ,named as pimInterfaceCBSRPreference, = I am not very clear about how to use it. It is to be the BSR-Priority in the BSR message, if it is = -1, it dont one c-BSR interface. I think if the router likes to be a C-BSR, it will send the BSR message = to all the PIM enabled interfaces with the same priority instead of different priority per interface. Another question is if the entry value is -1, does the interface still = foward the BSR message ?Thanks ------_=_NextPart_001_01C319BB.1F1AE624 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable a question about BSR (In MIB)

Now I am reading the PIM MIB(rfc2934), = I have a question about the pimInterfaceTable.
In this table, there is one entry = ,named as pimInterfaceCBSRPreference, I am not very clear about = how
to use it.  It is  to be the = BSR-Priority in the BSR message, if it is -1, it dont one c-BSR = interface.
I think if the router likes to be a = C-BSR, it will send the BSR message to all the PIM enabled interfaces = with the same priority

instead of different priority per = interface.
Another question is if the entry value = is -1, does the interface still  foward the BSR message = ?Thanks

------_=_NextPart_001_01C319BB.1F1AE624-- _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu May 15 18:37:02 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26451 for ; Thu, 15 May 2003 18:37:01 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4FLwBX69431; Thu, 15 May 2003 14:58:11 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from exchange.timetra.com (host-64-47-48-7.masergy.com [64.47.48.7] (may be forged)) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4FLrkX69357 for ; Thu, 15 May 2003 14:53:46 -0700 (PDT) (envelope-from sboddapati@timetra.com) Received: from SURESHPC ([192.168.1.23] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 15 May 2003 14:53:41 -0700 Reply-To: From: "Suresh Boddapati" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 15 May 2003 21:53:41.0237 (UTC) FILETIME=[72A40A50:01C31B2C] Subject: [pim] Questions Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 May 2003 14:53:52 -0700 Content-Transfer-Encoding: 7bit Hi, 1) In section 4.10.5.1 (Group Set Source List Rules). In the subsection for Wildcard Group Set, the definition states: "The wildcard group set is represented by the entire multicast range - the beginning of the multicast address range in the group address field and the prefix length of the multicast address range in the mask length field of the Multicast Group Address, e.g. 224.0.0.0/4 for IPV4......" Is this always 224.0.0.0/4 and no other value? If so, should it not say "i.e. 224.0.0.0/4" and not "e.g. 224.0.0.0/4"? The latter suggests other possible values for the same family. 2) In the same section, the table that specifies the rules for valid combinations of Joins and Prunes says that when the combination is invalid, the combination MUST not be generated by the router. It does not say anything about what a receiver should do upon receiving such a combination. Are we to assume that this should follow the "be liberal in what you accept" behavior i.e. if you receive a (*,G) Join and a (*, G) prune in the same message, you just go about processing them as usual (obviously, it would not cause any harm to do so). 3) Also, the draft says that "in a Join/Prune message, all the Multicast Group Addresses, Joined Source Addresses and Pruned Source addresses MUST be of the same address family. It is NOT PERMITTED to mix IPV4 and IPV6 addresses within the same message." If a router receives such a message, should the whole message be discarded? It is probably good to specify this behavior to ensure consistent operation. Thanks. Suresh _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu May 15 21:56:40 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29390 for ; Thu, 15 May 2003 21:56:38 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4G1stX73901; Thu, 15 May 2003 18:54:55 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from pfwhqs1.ncr.disa.mil (mtahqs3.ncr.disa.mil [164.117.144.157]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4FC6kX58943 for ; Thu, 15 May 2003 05:06:46 -0700 (PDT) (envelope-from liguorir@ftm.disa.mil) Received: from mtahqs3.ncr.disa.mil by pfwhqs1.ncr.disa.mil via smtpd (for catarina.usc.edu [204.57.0.1]) with SMTP; 15 May 2003 11:57:24 UT Received: by mtahqs3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id ; Thu, 15 May 2003 08:11:12 -0400 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02FAE244@emshqs1.ncr.disa.mil> From: "Liguori, Ralph" To: "'pim@catarina.usc.edu'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [pim] RE: PIM-SM, RFC 2362 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 May 2003 08:03:41 -0400 Can you assist in identifying any modifications that allow PIM to span inter-domain wide-area networks. Also, is there an alternate multicast protocol that will that span inter-domain wide-area networks ? Thank you, Ralph Liguori Networks Division (IN11) DISA Interoperability Directorate Fort Monmouth, NJ 07703 732-427-6888 Fax: 732-427-6798 DSN: 987-XXXX -----Original Message----- From: ahmed helmy [mailto:helmy@usc.edu] Sent: Wednesday, May 14, 2003 5:58 PM To: Liguori, Ralph Subject: Re: PIM-SM, RFC 2362 Hi, PIM-SM was basically designed for intra-domain networks. Recently there has been several modifications and suggestions for protocols that 'glue' several PIM-SM domains together, that span inter-domain wide-area networks. I have stopped working on PIM-SM spec several years ago, but you can contact the active pim group at pim@catarina.usc.edu Regards, -Ahmed ------- Ahmed Helmy Assistant Professor of Computer Networks Department of Electrical Engineering University of Southern California http://ceng.usc.edu/~helmy ----- Original Message ----- From: "Liguori, Ralph" Date: Wednesday, May 14, 2003 3:15 pm Subject: PIM-SM, RFC 2362 > Mr. Helmy, does PIM-SM allow routers to efficiently route multicast groups > that span both intra- and inter-domain wide-area networks ? > Thanks, > Ralph Liguori > Networks Division (IN11) > DISA Interoperability Directorate > Fort Monmouth, NJ 07703 > 732-427-6888 Fax: 732-427-6798 > DSN: 987-XXXX > > _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Fri May 16 00:08:19 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01037 for ; Fri, 16 May 2003 00:08:19 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4G3grX75846; Thu, 15 May 2003 20:42:53 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4G3eQX75794 for ; Thu, 15 May 2003 20:40:26 -0700 (PDT) (envelope-from tme@multicasttech.com) Received: from [68.100.8.94] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1687301; Thu, 15 May 2003 23:40:17 -0400 Subject: Re: [pim] RE: PIM-SM, RFC 2362 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'pim@catarina.usc.edu'" To: "Liguori, Ralph" From: Marshall Eubanks In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D02FAE244@emshqs1.ncr.disa.mil> Message-Id: <4C3AEBDE-874E-11D7-8EA5-00039315D3CC@multicasttech.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 May 2003 23:27:18 -0400 Content-Transfer-Encoding: 7bit Depends on what you want to do : A PIM domain can be pretty wide (it can include more than one autonomous system, for example - CANARIE does this) or PIM joins can cross domain boundaries (this is how interdomain multicast is done). However, all inter (PIM) domain joins are (S,G) joins (there are no interdomain (*,G) joins) so - In ASM you need a means of source discovery - presently done by MSDP - In SSM all joins are (S,G) anyway, so nothing need be done. If you want to do true interdomain multicast, you will also need to run MBGP. On Thursday, May 15, 2003, at 08:03 AM, Liguori, Ralph wrote: > Can you assist in identifying any modifications that allow PIM to span > inter-domain wide-area networks. Also, is there an alternate multicast > protocol that will that span inter-domain wide-area networks ? > Thank you, > Ralph Liguori > Networks Division (IN11) > DISA Interoperability Directorate > Fort Monmouth, NJ 07703 > 732-427-6888 Fax: 732-427-6798 > DSN: 987-XXXX > > > -----Original Message----- > From: ahmed helmy [mailto:helmy@usc.edu] > Sent: Wednesday, May 14, 2003 5:58 PM > To: Liguori, Ralph > Subject: Re: PIM-SM, RFC 2362 > > > Hi, > > PIM-SM was basically designed for intra-domain networks. > Recently there has been several modifications and suggestions for > protocols > that 'glue' several PIM-SM domains together, that span inter-domain > wide-area networks. > > I have stopped working on PIM-SM spec several years ago, but you can > contact > the active pim group at pim@catarina.usc.edu > > Regards, > -Ahmed > ------- > > Ahmed Helmy > Assistant Professor of Computer Networks > Department of Electrical Engineering > University of Southern California > http://ceng.usc.edu/~helmy > > ----- Original Message ----- > From: "Liguori, Ralph" > Date: Wednesday, May 14, 2003 3:15 pm > Subject: PIM-SM, RFC 2362 > >> Mr. Helmy, does PIM-SM allow routers to efficiently route multicast >> groups >> that span both intra- and inter-domain wide-area networks ? >> Thanks, >> Ralph Liguori >> Networks Division (IN11) >> DISA Interoperability Directorate >> Fort Monmouth, NJ 07703 >> 732-427-6888 Fax: 732-427-6798 >> DSN: 987-XXXX >> >> > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim > Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 19 05:03:28 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12710 for ; Mon, 19 May 2003 05:03:27 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4J91hX60496; Mon, 19 May 2003 02:01:43 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from hzvscan1.utstar.com.cn ([61.175.193.131]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4J8vhX60392 for ; Mon, 19 May 2003 01:57:44 -0700 (PDT) (envelope-from yxzhang@utstar.com) Received: from hzmail3.cn.utstar.com (hzvscan1 [127.0.0.1]) by hzvscan1.utstar.com.cn (8.11.6/8.11.6) with SMTP id h4J8u3709227 for ; Mon, 19 May 2003 16:56:03 +0800 Received: from hzmail1.cn.utstar.com ([172.18.9.35]) by hzmail3.cn.utstar.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 May 2003 16:57:33 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <9733CD15FD6A2C418132CE83BCDB16F6794E56@hzmail1.cn.utstar.com> Thread-Topic: about the keep alive timer Thread-Index: AcMd5LCeBrWBI1GwTYOGy4ZuGbEJ/Q== From: "Zhang Yanxing" To: X-OriginalArrivalTime: 19 May 2003 08:57:33.0803 (UTC) FILETIME=[AFF083B0:01C31DE4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4J8vhX60392 Subject: [pim] about the keep alive timer Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 May 2003 16:57:32 +0800 Content-Transfer-Encoding: 8bit about the keep alive timer I noted that in the specification, the (S,G) entry should have the keep alive timer, I am not very clear what's main function.I think the join timer expiry or all the joined interfaces are pruned, the entry can be deleted. I think the first hop router (DR) with directly connected source and the RP , which keep the tiemr, may be have some sense. Can anyone clarify for me ? Thanks _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 19 09:50:30 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20833 for ; Mon, 19 May 2003 09:50:29 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4JDmoX66070; Mon, 19 May 2003 06:48:51 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from relay4.alcatel.be (alc245.alcatel.be [195.207.101.245]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4JDkIX66017 for ; Mon, 19 May 2003 06:46:18 -0700 (PDT) (envelope-from viorel.peca@alcatel.be) Received: from bemail02.net.alcatel.be (bemail02.net.alcatel.be [138.203.146.50]) by relay4.alcatel.be (8.12.9/8.12.9) with ESMTP id h4JDqX4h019511 for ; Mon, 19 May 2003 15:52:53 +0200 Received: from alcatel.be ([138.203.193.36]) by bemail02.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003051915453535:5401 ; Mon, 19 May 2003 15:45:35 +0200 Message-ID: <3EC8DFE9.EAEE0D3B@alcatel.be> From: viorel peca X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: "pim@catarina.usc.edu" X-MIMETrack: Itemize by SMTP Server on BEMAIL02/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/19/2003 15:45:35, Serialize by Router on BEMAIL02/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/19/2003 15:45:57, Serialize complete at 05/19/2003 15:45:57 Content-Type: multipart/mixed; boundary="------------4868D2BF27BB547DA2EB3079" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [pim] RP behaviour on a LAN Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 May 2003 15:45:14 +0200 This is a multi-part message in MIME format. --------------4868D2BF27BB547DA2EB3079 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Please consider the following configuration: On a LAN there are RP, S-DR and IR. RP | ------------------------------------ | | ^ S-DR IR | (*,G) Join | | | Source Reciever The receiver behind the IR Sends a *,G join. Then the source start sending, S-DR sends registers and RP sends S,G join and register stop. Mcast traffic flows natively on LAN. In RP mcast routing table has an entry for *.G with no iif (Null) and 1 oif and an S,G entry with one iif (the same as oif of *,G of course ) and no oif. From now on consider 2 scenarios: 1) there is a ddr behind IR, who has to send S,G joins to trigger the spt switch over. 2) there is no S,G join to trigger the spt switch over. What RP should do: send S,G prune towards source because the oif=iif or not? Best Regards, Viorel Peca --------------4868D2BF27BB547DA2EB3079 Content-Type: text/x-vcard; charset=us-ascii; name="viorel.peca.vcf" Content-Description: Card for viorel peca Content-Disposition: attachment; filename="viorel.peca.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Peca;Viorel tel;cell:+32.(0)486.911436 tel;fax:+32.(0)3.240 9960 tel;work:+32.(0)3.240 8549 x-mozilla-html:FALSE url:www.alcatel.be org:
Data Core
Business Unit
JX26 System Integration Tests
;
Broadband Network Division
adr:;;FRANCIS WELLESPLEIN 1;Antwerpen;Belgium;B-2018;Belgium version:2.1 email;internet:viorel.peca@alcatel.be title:
fn:
Viorel Peca
System integration engineer
end:vcard --------------4868D2BF27BB547DA2EB3079-- _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 19 11:05:08 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23833 for ; Mon, 19 May 2003 11:05:06 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4JEpcX67275; Mon, 19 May 2003 07:51:38 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4JEnsX67227 for ; Mon, 19 May 2003 07:49:54 -0700 (PDT) (envelope-from John.Zwiebel@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id C41A323C39; Mon, 19 May 2003 07:38:02 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4JEnmYB027451; Mon, 19 May 2003 07:49:48 -0700 (PDT) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 May 2003 07:49:48 -0700 Subject: Re: [pim] about the keep alive timer Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Zhang Yanxing" From: John Zwiebel In-Reply-To: <9733CD15FD6A2C418132CE83BCDB16F6794E56@hzmail1.cn.utstar.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 19 May 2003 14:49:48.0409 (UTC) FILETIME=[E5257690:01C31E15] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 May 2003 07:47:47 -0700 Content-Transfer-Encoding: 7bit On Monday, May 19, 2003, at 01:57 AM, Zhang Yanxing wrote: > about the keep alive timer > > I noted that in the specification, the (S,G) entry > should have the keep alive timer, I am not very clear > what's main function.I think the join timer expiry > or all the joined interfaces are pruned, the entry > can be deleted. I think the > first hop router (DR) with directly connected source > and the RP , which keep the tiemr, may be have some > sense. Can anyone clarify for me ? Thanks Except for the last-hop router, you are correct that the join/prune messages can be used to keep state alive on the shortest-path. And yes, the DR and the RP are the other places this is required. FWIW: quite often when trying to debug a network configuration problem, monitoring the (S,G) keepalive timer is very helpful. > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 19 13:50:29 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28469 for ; Mon, 19 May 2003 13:50:27 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4JHmpX70517; Mon, 19 May 2003 10:48:51 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from dmz2.procket.com (dmz2.procket.com [65.174.124.37]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4JHklX70466 for ; Mon, 19 May 2003 10:46:47 -0700 (PDT) (envelope-from John.Zwiebel@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id CFBA334437; Mon, 19 May 2003 10:01:16 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4JHkeYB003628; Mon, 19 May 2003 10:46:41 -0700 (PDT) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 May 2003 10:46:40 -0700 Subject: Re: [pim] RP behaviour on a LAN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: John Zwiebel , "pim@catarina.usc.edu" To: viorel peca From: John Zwiebel In-Reply-To: <3EC8DFE9.EAEE0D3B@alcatel.be> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 19 May 2003 17:46:40.0890 (UTC) FILETIME=[9AAD8DA0:01C31E2E] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 May 2003 10:46:39 -0700 Content-Transfer-Encoding: 7bit On Monday, May 19, 2003, at 06:45 AM, viorel peca wrote: > Hi, > > Please consider the following configuration: > On a LAN there are RP, S-DR and IR. > > RP > | > ------------------------------------ > | | ^ > S-DR IR | (*,G) Join > | | | > Source Reciever > > The receiver behind the IR Sends a *,G join. Then the source start > sending, S-DR sends registers and RP sends S,G join and register stop. > Mcast traffic flows natively on LAN. In RP mcast routing table has an > entry for *.G with no iif (Null) and 1 oif and an S,G entry with one > iif > (the same as oif of *,G of course ) and no oif. An implementation may choose to say that the (*,G) has a NULL IIF, but that may cause problems for you. Even the RP has to choose which interface is the RP address -- which would be the IIF. You have a classic "turn-around" router case here. As long as the RP is getting (*,G) joins without an (S,G,RP-bit) prune, it needs to continue sending (S,G) joins toward the source. Whether you realize this with the X-flag (as cisco does) or by placing the IIF in the OIF list, is up to the implementor. > From now on consider 2 scenarios: > 1) there is a ddr behind IR, who has to send S,G joins to trigger the > spt switch over. > > 2) there is no S,G join to trigger the spt switch over. > > > What RP should do: send S,G prune towards source because the oif=iif or > not? > > > Best Regards, > > Viorel Peca > > > > _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 19 17:34:40 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06587 for ; Mon, 19 May 2003 17:34:39 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4JLPwX74635; Mon, 19 May 2003 14:25:58 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4JLNdX74575 for ; Mon, 19 May 2003 14:23:39 -0700 (PDT) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h4JLNXu61384 for ; Mon, 19 May 2003 14:23:33 -0700 (PDT) (envelope-from pusateri@juniper.net) Message-Id: <200305192123.h4JLNXu61384@merlot.juniper.net> To: pim@catarina.usc.edu MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23155.1053379413.1@juniper.net> From: Tom Pusateri Subject: [pim] null register dummy ip header Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 May 2003 14:23:33 -0700 If you're on the I2 multicast mailing list, you've no doubt noticed a thread on the null register dummy IP header. It seems that it is under specified in all versions of the PIM sparse mode spec and so we should update the latest spec to clearly specify which fields are filled in. The current language is: For (S,G) null Registers, the Multicast data packet portion contains only a dummy header with S as the source address, G as the destination address, and a data length of zero. What isn't specified is whether the rest of the IP header fields should be filled in. Juniper has only ever zero'ed the whold IP header, and filled in the group and source addresses. Others seem to fill in the IP version, header length, and checksum. Since there is no other checksum over the group and source address, it makes sense to use this checksum, though, we will have problems with interoperability if we require it now. As Dino pointed out, filling in the IP version allows V6 registers inside V4 encapsulations as vice versa. So it sounds like we need to beef up this section of the draft. Thanks, Tom _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 19 17:59:34 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07189 for ; Mon, 19 May 2003 17:59:33 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4JLvSX75286; Mon, 19 May 2003 14:57:28 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from aardvark.icir.org (aardvark.icir.org [192.150.187.20]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4JLtXX75248 for ; Mon, 19 May 2003 14:55:33 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) Received: from aardvark.icir.org (localhost [127.0.0.1]) by aardvark.icir.org (8.12.8p1/8.12.3) with ESMTP id h4JLtWZt064727; Mon, 19 May 2003 14:55:32 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ICIR To: Tom Pusateri cc: pim@catarina.usc.edu Subject: Re: [pim] null register dummy ip header In-reply-to: Your message of "Mon, 19 May 2003 14:23:33 PDT." <200305192123.h4JLNXu61384@merlot.juniper.net> Message-ID: <64726.1053381331@aardvark.icir.org> Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 May 2003 14:55:31 -0700 >If you're on the I2 multicast mailing list, you've no doubt noticed >a thread on the null register dummy IP header. It seems that it >is under specified in all versions of the PIM sparse mode spec >and so we should update the latest spec to clearly specify which >fields are filled in. > >The current language is: > > For (S,G) null Registers, the Multicast data packet portion > contains only a dummy header with S as the source address, G as > the destination address, and a data length of zero. > >What isn't specified is whether the rest of the IP header fields >should be filled in. > >Juniper has only ever zero'ed the whold IP header, and filled in >the group and source addresses. > >Others seem to fill in the IP version, header length, and checksum. > >Since there is no other checksum over the group and source address, >it makes sense to use this checksum, though, we will have problems >with interoperability if we require it now. > >As Dino pointed out, filling in the IP version allows V6 registers >inside V4 encapsulations as vice versa. > >So it sounds like we need to beef up this section of the draft. How about we suggest (in addition to the existing text): With IPv4, with respect to the fields in the dummy header, an implementation SHOULD fill in the checksum field. Framentation offset MUST be zero. If the checksum field is filled in with a non-zero value, the IP version, header length and total length fields MUST be filled in. If the header length field is filled in, it MUST have a value of 5, indicating no IP options are present. If total length is filled in, it MUST have a value of 20. If the Header Checksum field is non-zero, the recipient SHOULD check the checksum and discard null registers that have a bad checksum. If the Header Checksum field is zero, the recipient MUST NOT check the checksum. And something similar with IPv6. What do we specify for the Protocol field? Cheers, Mark _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 19 22:05:46 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13015 for ; Mon, 19 May 2003 22:05:46 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4K255X79891; Mon, 19 May 2003 19:05:05 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4K22YX79826 for ; Mon, 19 May 2003 19:02:34 -0700 (PDT) (envelope-from pusateri@juniper.net) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h4K22Su80005; Mon, 19 May 2003 19:02:28 -0700 (PDT) (envelope-from pusateri@juniper.net) Message-Id: <200305200202.h4K22Su80005@merlot.juniper.net> To: Mark Handley cc: Tom Pusateri , pim@catarina.usc.edu, pusateri@juniper.net Subject: Re: [pim] null register dummy ip header In-Reply-To: Message from Mark Handley of "Mon, 19 May 2003 14:55:31 PDT." <64726.1053381331@aardvark.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28779.1053396148.1@juniper.net> From: Tom Pusateri Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 May 2003 19:02:28 -0700 In message <64726.1053381331@aardvark.icir.org> you write: > >>If you're on the I2 multicast mailing list, you've no doubt noticed >>a thread on the null register dummy IP header. It seems that it >>is under specified in all versions of the PIM sparse mode spec >>and so we should update the latest spec to clearly specify which >>fields are filled in. >> >>The current language is: >> >> For (S,G) null Registers, the Multicast data packet portion >> contains only a dummy header with S as the source address, G as >> the destination address, and a data length of zero. >> >>What isn't specified is whether the rest of the IP header fields >>should be filled in. >> >>Juniper has only ever zero'ed the whold IP header, and filled in >>the group and source addresses. >> >>Others seem to fill in the IP version, header length, and checksum. >> >>Since there is no other checksum over the group and source address, >>it makes sense to use this checksum, though, we will have problems >>with interoperability if we require it now. >> >>As Dino pointed out, filling in the IP version allows V6 registers >>inside V4 encapsulations as vice versa. >> >>So it sounds like we need to beef up this section of the draft. > > >How about we suggest (in addition to the existing text): > >With IPv4, with respect to the fields in the dummy header, an >implementation SHOULD fill in the checksum field. Framentation offset >MUST be zero. If the checksum field is filled in with a non-zero >value, the IP version, header length and total length fields MUST be >filled in. If the header length field is filled in, it MUST have a >value of 5, indicating no IP options are present. If total length is >filled in, it MUST have a value of 20. If the Header Checksum field >is non-zero, the recipient SHOULD check the checksum and discard null >registers that have a bad checksum. If the Header Checksum field is >zero, the recipient MUST NOT check the checksum. > >And something similar with IPv6. > > >What do we specify for the Protocol field? > >Cheers, > Mark Sounds good so far. I received a question about TTL too. We should specify that. I suggest similar language like "If the IP TTL is filled in, it MUST be 1." As far as protocol number, I think 0 is appropriate. Thanks, Tom _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon May 19 23:11:14 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14073 for ; Mon, 19 May 2003 23:11:14 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4K3AfX81177; Mon, 19 May 2003 20:10:41 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from vulture.icir.org (adsl-67-117-79-130.dsl.sntc01.pacbell.net [67.117.79.130]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4K386X81127 for ; Mon, 19 May 2003 20:08:06 -0700 (PDT) (envelope-from mjh@vulture.icir.org) Received: from vulture.icir.org (localhost [127.0.0.1]) by vulture.icir.org (8.12.8p1/8.12.3) with ESMTP id h4K385in066869; Mon, 19 May 2003 20:08:05 -0700 (PDT) (envelope-from mjh@vulture.icir.org) From: Mark Handley X-Organisation: ICIR To: Tom Pusateri cc: pim@catarina.usc.edu Subject: Re: [pim] null register dummy ip header In-reply-to: Your message of "Mon, 19 May 2003 19:02:28 PDT." <200305200202.h4K22Su80005@merlot.juniper.net> Message-ID: <66868.1053400085@vulture.icir.org> Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 May 2003 20:08:05 -0700 >Sounds good so far. I received a question about TTL too. We should >specify that. I suggest similar language like "If the IP TTL is filled in, >it MUST be 1." The reason I didn't specify this was that so long as it's covered by the checksum, it doesn't matter what value it has. The other fields mattered because they all had secondary effects. Similarly it doesn't matter what value the diffserv or ECN bits have. So a MUST for this seems too strong to me. >As far as protocol number, I think 0 is appropriate. Hmm, for IPv6, protocol 0 is a hop-by-hop option. So probably better to avoid this for IPv4 too. How about 103 (PIM)? Cheers, Mark _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Tue May 20 00:02:50 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15117 for ; Tue, 20 May 2003 00:02:49 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4K42PX82231; Mon, 19 May 2003 21:02:25 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4K40GX82177 for ; Mon, 19 May 2003 21:00:16 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [3ffe:501:4819:2000:a82a:596e:28d8:b072]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C18A915252; Tue, 20 May 2003 13:00:10 +0900 (JST) Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mark Handley Cc: Tom Pusateri , pim@catarina.usc.edu Subject: Re: [pim] null register dummy ip header In-Reply-To: <64726.1053381331@aardvark.icir.org> References: <200305192123.h4JLNXu61384@merlot.juniper.net> <64726.1053381331@aardvark.icir.org> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 May 2003 13:00:05 +0900 >>>>> On Mon, 19 May 2003 14:55:31 -0700, >>>>> Mark Handley said: > And something similar with IPv6. Hmm, but IPv6 does not have a checksum field in its base header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (from Section 3 of RFC 2460) So, if we really need to care about this for IPv6, we may have to either: - add a (dummy) PIM header after the inner IPv6 header, and put the checksum for the inner headers there. - reuse a different field of the inner basic IPv6 header (e.g. the payload length field) for this specific checksum. - (there may be other options) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Tue May 20 22:49:09 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09231 for ; Tue, 20 May 2003 22:49:07 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4L2e8X06851; Tue, 20 May 2003 19:40:08 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from hzvscan1.utstar.com.cn ([61.175.193.131]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4L2aWX06762 for ; Tue, 20 May 2003 19:36:37 -0700 (PDT) (envelope-from yxzhang@utstar.com) Received: from hzmail4.cn.utstar.com (hzvscan1 [127.0.0.1]) by hzvscan1.utstar.com.cn (8.11.6/8.11.6) with SMTP id h4L2YoL11734 for ; Wed, 21 May 2003 10:34:51 +0800 Received: from hzmail1.cn.utstar.com ([172.18.9.35]) by hzmail4.cn.utstar.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 10:36:25 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <9733CD15FD6A2C418132CE83BCDB16F67C2889@hzmail1.cn.utstar.com> Thread-Topic: about the (*,G),(S,G) entry creation and deletion Thread-Index: AcMfQcQGBEVFB6c/ToGVJBvLSUGc+A== From: "Zhang Yanxing" To: X-OriginalArrivalTime: 21 May 2003 02:36:25.0976 (UTC) FILETIME=[C67A8780:01C31F41] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4L2aWX06762 Subject: [pim] about the (*,G),(S,G) entry creation and deletion Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 May 2003 10:36:25 +0800 Content-Transfer-Encoding: 8bit I think it maybe one implementation problem, I want to speak out my thought to see if it is correct. Multicast Route entry is created when some interfaces receive the (*,G) or (S,G) join message. When all the joined before interfaces recieve prune message(after the prune override interval) or the join timer expires, the entry will be deleted. This mechanism shows the difference between the DM and SM. But at the DR with the directly connected senders and the RP, I think the (S,G) entry creation is something like the DM, it is built by the traffic driven. Another point is that does the specification imply that if (S,G) exist, the (*,G) should exist too? Welcome comments, Thanks. _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 21 02:48:37 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09876 for ; Wed, 21 May 2003 02:48:35 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4L6jDX11187; Tue, 20 May 2003 23:45:13 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4L6gKX11123 for ; Tue, 20 May 2003 23:42:20 -0700 (PDT) (envelope-from sarveshwarb@netplane.com) Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h4L6gJos003479 for ; Tue, 20 May 2003 23:42:19 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h4L4b39g020911 for ; Tue, 20 May 2003 23:37:03 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 May 2003 02:42:02 -0400 Message-ID: From: "Bandi, Sarveshwar" To: "'Zhang Yanxing'" , pim@catarina.usc.edu Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="GB2312" Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 May 2003 02:43:41 -0400 One comment, I dont think the spec says explicitly that a (*,G) should exist when (S,G) exists. If someone were to have only SSM routes in a network, having (*,G) routes would not make any sense. I think creation of (*,G) route when (S,G) routes are created is an implementation issue. We have an implementation where (*,G) routes created as and when needed. Would love to hear others comments on this Regards, Sarvesh -----Original Message----- From: Zhang Yanxing [mailto:yxzhang@utstar.com] Sent: Wednesday, May 21, 2003 8:06 AM To: pim@catarina.usc.edu Subject: [pim] about the (*,G),(S,G) entry creation and deletion I think it maybe one implementation problem, I want to speak out my thought to see if it is correct. Multicast Route entry is created when some interfaces receive the (*,G) or (S,G) join message. When all the joined before interfaces recieve prune message(after the prune override interval) or the join timer expires, the entry will be deleted. This mechanism shows the difference between the DM and SM. But at the DR with the directly connected senders and the RP, I think the (S,G) entry creation is something like the DM, it is built by the traffic driven. Another point is that does the specification imply that if (S,G) exist, the (*,G) should exist too? Welcome comments, Thanks. _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 21 03:27:30 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10905 for ; Wed, 21 May 2003 03:27:29 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4L7JTX11841; Wed, 21 May 2003 00:19:29 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4L7HlX11799 for ; Wed, 21 May 2003 00:17:47 -0700 (PDT) (envelope-from prashantj@future.futsoft.com) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 21 May 2003 12:48:16 +0530 Received: from prashantj (prashantj.future.futsoft.com [10.4.5.41]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h4L75EAo006777; Wed, 21 May 2003 12:35:15 +0530 Reply-To: From: "Prashant Jhingran" To: "'Zhang Yanxing'" , Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion Message-Id: <000201c31f67$6cc8d720$2905040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MS-TNEF-Correlator: 0000000045BADF0C9A09D5118BCD00D0096F927744352302 Importance: Normal In-Reply-To: <9733CD15FD6A2C418132CE83BCDB16F67C2889@hzmail1.cn.utstar.com> Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C31F95.8691DC00" Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 May 2003 12:35:54 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C31F95.8691DC00 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi, --*,G is definitely not a must for SG entry. If a DDR receives a Source specific IGMP (v3) report then it forms a SG tree and this may happen for both SSM and non-SSM group range. --At RP the creation of SG entry is influenced by presence of Receivers for the group. If no receivers then RP is supposed to send a Register stop and no need for SG state creation. --At SDR however it is data driven unless a source specific SG tree is formed by a DDR before source starts pumping data packets. would like to have some comments on this. regards, Prashant -----Original Message----- From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Zhang Yanxing Sent: Wednesday, May 21, 2003 8:06 AM To: pim@catarina.usc.edu Subject: [pim] about the (*,G),(S,G) entry creation and deletion I think it maybe one implementation problem, I want to speak out my thought to see if it is correct. Multicast Route entry is created when some interfaces receive the (*,G) or (S,G) join message. When all the joined before interfaces recieve prune message(after the prune override interval) or the join timer expires, the entry will be deleted. This mechanism shows the difference between the DM and SM. But at the DR with the directly connected senders and the RP, I think the (S,G) entry creation is something like the DM, it is built by the traffic driven. Another point is that does the specification imply that if (S,G) exist, the (*,G) should exist too? Welcome comments, Thanks. _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0003_01C31F95.8691DC00 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjcHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBQAVAAwAIwAAAAMAJgEB A5AGACAJAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA4AAAAW3BpbV0gYWJvdXQgdGhlICgqLEcpLChTLEcpIGVudHJ5IGNyZWF0aW9u IGFuZCBkZWxldGlvbgACAXEAAQAAABYAAAABwx9na3nKLRXWi2wR14vXANAJb5J3AAACAR0MAQAA ACIAAABTTVRQOlBSQVNIQU5USkBGVVRVUkUuRlVUU09GVC5DT00AAAALAAEOAAAAAEAABg4Adi9L Zx/DAQIBCg4BAAAAGAAAAAAAAABFut8MmgnVEYvNANAJb5J3woAAAAMAFA4BAAAACwAfDgEAAAAC AQkQAQAAAA8FAAALBQAAGggAAExaRnXu1ZNqAwAKAHJjcGc5MzbxA0N0ZXgFQQEDAfcKgIsCpAPk Uwdwc3VuAoBvD+MAUARWEMsyAuMCAGPCaArAc2V0MgYABsPNESUzBEYTZzAgCFUHsi8CgBEzCO8J 9zsXzzI19jURIgxgYwBQCwkBZA4wwxYAC6YgSGksCqIKgEAtLSosRyAEACALAQELgGkOoGx5IG6C bwVAYSBtdXMFQBsCEAXAUx1wCfB0cnkmLgrjCoBJZh6hRESEUiAX0GNlaXYHkY0esFMIYSEQIHNw BZADBpAN4CBJR01QIFAodjMpIOFwF3Eg/HRoCfAdgB8DEOAhch1w5x+wCeAeoG5kI6EdkQDA+x5Q E5BwIiADoB8iBuAjsJkGAFNNJSMecG4tJwIbCcAIYHAg4ABwZ2UuaxzUHNZBBUBSItAjsSAhBQBl YXRpAiAgb68gcB9mHYILgGYKQW4hEPUlUGIeUHAX0BPALCEqwv8H8CEEE7AfEyoCKAMf4CBh/x5w IOYt4SOzKdEdkRDwJiD+bxPAJVEvQCzRJVAesC1w3mcEAA6gBcAe8G8oQCdE/x5gCeAlUB8lHvAq cCooKL/DBgAgwWhvd2UtwSPy9x2SKnAesGQFECFAA6ARAPZsB5AhYnMhvSS2HZEkMvssRCCUYgEQ BbAh8SG1AZBDACAEIHB1bXALgGdTNwQKsGNrE9BzNNt35QhgbCVQbGk9YDEyE5D/IUA4UQeAKjAD cAeAAjAEIK8qoSVyNNsX0GcLEXMcxXpQKGBzE5ACMDTsQ+FPuwUQMgBuB0AF0DgBYSiQa0PjHNRG A2E6LJAHcC3IYWRtC4BAYzchBRAlRIAuHuBjLgmAdSBuWwDAAxAxQDpGT0dXXVJPA6BCZROQbCBw T60gcFpC4TzAWQBweDyhbxzUBmACMEYgVwmAMzBzmTcQeSwF0CXRMjFNEAEB0DAzIDg6MDboIEFN HNRUSFBGMkkPsUvFdWJqBZBMUVtIcXZdHqAG4HUjkyLgHVEp+CwoU1JhKyUqRyUyAQC/N/AqgjTq HNQtUFXSSSVi/G5rI/IlwTsQQHE5wTyA7zfwQCIqdCygbwJgV8BNEN1WMHdC8TEzIiBhVpBRws5t HlAjsAhgZ2hZVDmyryBwNrQFoSDxdDTVTT6Q/yqARuAe8QgAUdAh8Cs3KkO9LEF3I8I/owuAMjFm ANA/B5Eg9VH4KsAFwFKkIGrebwuAHsBE1B/mVyPCB0D/AyAqAmHyLEI7JF+MCJA/cc8soBEAIfBi RShhAYAWcXsqAmYUby3BBRABAF90dv8HQGEyHNRjxiOgB3EFwA6w/zyQLLFNECoCKzQD8GORVxH3 VDMJgB/gVCWDBZBC4QQAvm0iADYxL+MdsAaQZgSQuyzjOxB0NlAj0SoCRCck7UvFTTTVVdNCUdEq cG+EfyDQA/Am0W4kXCIeQQWgbv8zMFEALEExci3SJTQh8CnQ/1jiVlRSA1K/KqEwgj+xVlI/PMAc 1D7Ub6NNEDa0YnX/SCEsYioCH7Bm8CJiN2Rwyv5BHnEjwAXAI2BfgR2CI7D5ccFkbweRKgIiFncV V5H/WlJxwVthdiVLgB7wawRg9M9twT6SgFMxMW8/VXlMgL5sP/E/2E0QbNAAcGs9lv5fhR+GL4b6 HNRIcSWxAxB/PKI+0B7wiAdPTxzUWsB00HA6Ly9G7i9IAgOBZi+JIivBby9IcRzUfQGOkAAeAEIQ AQAAAD8AAAA8OTczM0NEMTVGRDZBMkM0MTgxMzJDRTgzQkNEQjE2RjY3QzI4ODlAaHptYWlsMS5j bi51dHN0YXIuY29tPgAAAwAJWQEAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMA AoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAIgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUA AAAAAAADAC2ACCAGAAAAAADAAAAAAAAARgAAAABShQAAP3EBAB4ALoAIIAYAAAAAAMAAAAAAAABG AAAAAFSFAAABAAAABAAAADkuMAALAC+ACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAsAM4AI IAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwA0gAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAA AAADADaACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAIB+A8BAAAAEAAAAEW63wyaCdURi80A 0AlvkncCAfoPAQAAABAAAABFut8MmgnVEYvNANAJb5J3AgH7DwEAAABLAAAAAAAAADihuxAF5RAa obsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABEOlxtYWlsXHByYXNoYW50 ai5wc3QAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDQ1QkFERjBDOUEwOUQ1 MTE4QkNEMDBEMDA5NkY5Mjc3NDQzNTIzMDIAAAAAAwAGEBpYSV0DAAcQDQUAAAMAEBAAAAAAAwAR EAAAAAAeAAgQAQAAAGUAAABISSwtLSosR0lTREVGSU5JVEVMWU5PVEFNVVNURk9SU0dFTlRSWUlG QUREUlJFQ0VJVkVTQVNPVVJDRVNQRUNJRklDSUdNUChWMylSRVBPUlRUSEVOSVRGT1JNU0FTR1RS RUVBAAAAAF11 ------=_NextPart_000_0003_01C31F95.8691DC00-- _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 21 03:57:50 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11417 for ; Wed, 21 May 2003 03:57:49 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4L7qdX12486; Wed, 21 May 2003 00:52:39 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from bosvwl01.infosys.com (bosvwl01.infosys.com [216.52.49.35]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4L7o3X12427 for ; Wed, 21 May 2003 00:50:04 -0700 (PDT) (envelope-from bharat_joshi@infosys.com) Received: from 192.168.200.82 by bosvwl01.infosys.com (InterScan E-Mail VirusWall NT); Wed, 21 May 2003 03:49:33 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 13:19:09 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 13:19:09 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion Message-ID: <56E2573C375A414191118970BDE06A150ABE5EEA@kecmsg06.ad.infosys.com> Thread-Topic: [pim] about the (*,G),(S,G) entry creation and deletion Thread-Index: AcMfauwb+6IsjB8PQTmfzKkKtzQazwAAb9jF From: "bharat_joshi" To: "Bandi, Sarveshwar" , X-OriginalArrivalTime: 21 May 2003 07:49:09.0453 (UTC) FILETIME=[7661E7D0:01C31F6D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4L7o3X12427 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 May 2003 13:19:08 +0530 Content-Transfer-Encoding: 8bit Hi, *,G state will be there when IGMP hosts have not been updated to IGMPv3 and the desginated rotuers doesn't support IGMPv3. Lets say we have IGMPv2 on a LAN, the DR will always generate a *,G join/prune for a IGMP join/leave message. S,G state will come in picture when DR start switch to SPT but in this case you will need to maintain *,G and S,G both becuase the router will never come to know that the hosts connected to LAN wants packet from which all sources. If hosts are running IGMPV3 than a *,G entry may not be created. Thanks, Bharat -----Original Message----- From: Bandi, Sarveshwar [mailto:sarveshwarb@netplane.com] Sent: Wed 5/21/2003 12:13 PM To: 'Zhang Yanxing'; pim@catarina.usc.edu Cc: Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion One comment, I dont think the spec says explicitly that a (*,G) should exist when (S,G) exists. If someone were to have only SSM routes in a network, having (*,G) routes would not make any sense. I think creation of (*,G) route when (S,G) routes are created is an implementation issue. We have an implementation where (*,G) routes created as and when needed. Would love to hear others comments on this Regards, Sarvesh -----Original Message----- From: Zhang Yanxing [mailto:yxzhang@utstar.com] Sent: Wednesday, May 21, 2003 8:06 AM To: pim@catarina.usc.edu Subject: [pim] about the (*,G),(S,G) entry creation and deletion I think it maybe one implementation problem, I want to speak out my thought to see if it is correct. Multicast Route entry is created when some interfaces receive the (*,G) or (S,G) join message. When all the joined before interfaces recieve prune message(after the prune override interval) or the join timer expires, the entry will be deleted. This mechanism shows the difference between the DM and SM. But at the DR with the directly connected senders and the RP, I think the (S,G) entry creation is something like the DM, it is built by the traffic driven. Another point is that does the specification imply that if (S,G) exist, the (*,G) should exist too? Welcome comments, Thanks. _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 21 04:09:16 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11602 for ; Wed, 21 May 2003 04:09:15 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4L86PX12800; Wed, 21 May 2003 01:06:25 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from hzvscan1.utstar.com.cn ([61.175.193.131]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4L84gX12755 for ; Wed, 21 May 2003 01:04:43 -0700 (PDT) (envelope-from yxzhang@utstar.com) Received: from hzmail3.cn.utstar.com (hzvscan1 [127.0.0.1]) by hzvscan1.utstar.com.cn (8.11.6/8.11.6) with SMTP id h4L82YN22158; Wed, 21 May 2003 16:02:38 +0800 Received: from hzmail1.cn.utstar.com ([172.18.9.35]) by hzmail3.cn.utstar.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 16:04:07 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <9733CD15FD6A2C418132CE83BCDB16F67EFCEC@hzmail1.cn.utstar.com> Thread-Topic: [pim] about the (*,G),(S,G) entry creation and deletion Thread-Index: AcMfZ2t5yi0V1otsEdeL1wDQCW+SdwABvuQg From: "Zhang Yanxing" To: , X-OriginalArrivalTime: 21 May 2003 08:04:07.0513 (UTC) FILETIME=[8DAAFC90:01C31F6F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4L84gX12755 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 May 2003 16:04:10 +0800 Content-Transfer-Encoding: 8bit -----Original Message----- From: Prashant Jhingran [mailto:prashantj@future.futsoft.com] Sent: 2003Äê5ÔÂ21ÈÕ 15:06 To: Zhang Yanxing; pim@catarina.usc.edu Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion Hi, --*,G is definitely not a must for SG entry. If a DDR receives a Source specific IGMP (v3) report then it forms a SG tree and this may happen for both SSM and non-SSM group range. --At RP the creation of SG entry is influenced by presence of Receivers for the group. If no receivers then RP is supposed to send a Register stop and no need for SG state creation. The (S,G) entry is not created when no receivers on the RP tree for the group, but druing the register_suppression time, if a reciever emerge on the RP tree for the group, The RP may wait at most the register_suppression to create the the (S,G) and send the (S,G) join towards the source. --At SDR however it is data driven unless a source specific SG tree is formed by a DDR before source starts pumping data packets. would like to have some comments on this. regards, Prashant -----Original Message----- From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Zhang Yanxing Sent: Wednesday, May 21, 2003 8:06 AM To: pim@catarina.usc.edu Subject: [pim] about the (*,G),(S,G) entry creation and deletion I think it maybe one implementation problem, I want to speak out my thought to see if it is correct. Multicast Route entry is created when some interfaces receive the (*,G) or (S,G) join message. When all the joined before interfaces recieve prune message(after the prune override interval) or the join timer expires, the entry will be deleted. This mechanism shows the difference between the DM and SM. But at the DR with the directly connected senders and the RP, I think the (S,G) entry creation is something like the DM, it is built by the traffic driven. Another point is that does the specification imply that if (S,G) exist, the (*,G) should exist too? Welcome comments, Thanks. _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 21 05:10:21 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12558 for ; Wed, 21 May 2003 05:10:20 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4L90lX13882; Wed, 21 May 2003 02:00:47 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from web8201.mail.in.yahoo.com (web8201.mail.in.yahoo.com [203.199.70.114]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4L8wkX13821 for ; Wed, 21 May 2003 01:58:46 -0700 (PDT) (envelope-from jaganbabu_pim@yahoo.co.in) Message-ID: <20030521085839.58668.qmail@web8201.mail.in.yahoo.com> Received: from [129.188.33.221] by web8201.mail.in.yahoo.com via HTTP; Wed, 21 May 2003 09:58:39 BST From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?= Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion To: pim@catarina.usc.edu Cc: prashantj@future.futsoft.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1871294350-1053507519=:58353" Content-Transfer-Encoding: 8bit Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 May 2003 09:58:39 +0100 (BST) --0-1871294350-1053507519=:58353 Content-Type: multipart/alternative; boundary="0-1744311238-1053507519=:58353" --0-1744311238-1053507519=:58353 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi guys, We had a same kind of discussion some time back, I think it would be clear if you read the below thread, with the topology. Thanx, Jags Note: forwarded message attached. Catch all the cricket action. Download Yahoo! Score tracker --0-1744311238-1053507519=:58353 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi guys,
  We had a same kind of discussion some time back, I think it would be clear if you read the below thread, with the topology.
Thanx,
Jags

Note: forwarded message attached.

Catch all the cricket action. Download Yahoo! Score tracker --0-1744311238-1053507519=:58353-- --0-1871294350-1053507519=:58353 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit X-Apparently-To: jaganbabu_pim@yahoo.co.in via web8201.mail.in.yahoo.com; 19 Dec 2002 14:37:13 +0500 (IST) X-Track: 1: 100 Return-Path: Received: from catarina.usc.edu (204.57.0.1) by mta103.mail.in.yahoo.com with SMTP; 19 Dec 2002 14:37:11 +0500 (IST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id gBJ8l1D04612; Thu, 19 Dec 2002 00:47:02 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from web8204.mail.in.yahoo.com (web8204.mail.in.yahoo.com [203.199.70.124]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id gBJ8k4D04600 for ; Thu, 19 Dec 2002 00:46:04 -0800 (PST) (envelope-from jaganbabu_pim@yahoo.co.in) Received: from [12.27.183.253] by web8204.mail.in.yahoo.com via HTTP; Thu, 19 Dec 2002 08:50:47 GMT From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?= Subject: RE: [pim] doubt regard RP absence in the network To: umac@future.futsoft.com, "'john nowa'" Cc: pim@catarina.usc.edu In-Reply-To: <001201c2a722$7d313a20$1906140a@future.futsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1429828762-1040287847=:46093" Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Dec 2002 08:50:47 +0000 (GMT) Content-Length: 5565 --0-1429828762-1040287847=:46093 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Uma, I think, you need to read my topology properly, where i have mensioned about IGMPV3 and not IGMPV2. If you spend some time to read the topology properly, you might not be having such a doubts (IGMPV3/V2). Regards, Jags Uma C wrote:Hello John & Jags I also agreed upon what Jags has mentioned in his topology. >>> 3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this. >>> (S,G) - oiflist=2 >>> [Uma C] Yes, multicast packets should flow on interface 2. I agree with this. Pl confirm only this -* Received IGMPv2 Join, created a (*,G) entry. * Switched to SPT, hence (S,G) entry is created. (*, G) and (S, G) entry holds the same oif. * Packets are flowing through SPT.* Now when the RP information is not present. (*,G) entry is deleted. Will the (S,G) entry exists ? Would the data packets flow ?. Note:- In all this discussion I was only referring to receivers joining through IGMPv2 Join. In the case of IGMPv3 Join ie., source specific Join I agree that packets will be flowing irrespective of RP informations present or not. Hope this time I have expressed my thoughts clearly. Thanks & RegardsC.Uma -----Original Message----- From: john nowa [mailto:john_nowa@yahoo.co.in] Sent: Wednesday, December 18, 2002 9:09 PM To: Rajamanickam jaganbabu; umac@future.futsoft.com Cc: pim@catarina.usc.edu Subject: RE: [pim] doubt regard RP absence in the network hello umaaa, I guess, whatever jags referring is correct. According to his topology, we can still forward the multicast packet for (S,G). John Rajamanickam jaganbabu wrote: Hi uma, Whatever I have mentioned below was only with respect to SM domain (I haven't mentioned SSM case, which is altogether a different story). I don't understand why you need to delete even (S,G) if you don't have (*,G), draft doesn't say that. But according to the draft, we need to remove only inherited outlist from (S,G) entry, but in our case we have immediate outgoing list in (S,G) which is not a part of inherited list (if the (S,G) immediate outlist and inherited outlist are same then only we should remove (S,G) entry from your multicast forwarding table), so there is no point and we should not delete (S,G) entry from the multicast routing table even if (*,G) entry is deleted. I hope u understand the logic. Regards, Jags Uma C wrote: Hello Jags Pl find my response inlined with the tag . RegardsC.Uma -----Original Message----- From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu Sent: Wednesday, December 18, 2002 2:44 PM To: umac@future.futsoft.com Cc: pim@catarina.usc.edu Subject: RE: [pim] doubt regard RP absence in the network Hi uma, 1. Even in normal SM case, multicast forwarding is possible even if we don't have RP information. [Uma C] I guess not. In the example you had given includes SSM also. ========= 2. When we are deleting (*,G) entry, it is not mandatory to remove all the (S,G) entry from the multicast forwarder unless and until all the outgoing interface list is null. [Uma C] I agree with you. And in the SM case there cannot be a situation when (*,G) is deleted but (S,G) still remains. ================== I have explained how it can happen using the following topology (fig. as an attachment). Explanation: 1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then the PIM forwarding table at R1 look like (*,G) - oiflist=1 2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the PIM forwarding table at R1 looks like (S,G) - oiflist=1,2 (*,G) - oiflist=1 In the above forwarding table while adding (S,G) entry, the inherited outgoing list will be 1 and the immediate outgoing list will be 2, so consolidating the outgoing interface for (S,G) will 1 and 2 3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this. (S,G) - oiflist=2 [Uma C] Yes, multicast packets should flow on interface 2. I agree with this. But the discussion started with whether multicast packets can be forwarded in PIM-SM domain only (This is want Rajesh asked for) when RP information is not present. In this case do not execute the step 2, so the (*,G) and (S,G) will hold the same oif, and hence both of these entries get deleted. So the multicast packets stop flowing. ================ So even in SM. it is not necessary to remove all the (S,G) entries if you remove (*,G) entry from the multicast forwarding table. [Uma C] I guess not in the SM domain (which doesnot include SSM). I apreciate the interest you had taken to explain the situation with a topology. Thanks Jags. ================= Regards, Jags Uma C wrote: Hello Jags I guess in the case of IGMPv3, we do not create any (*,G) entry as the Group range for SSM is different. And as you said we can still forward the packets whether there is RP information or not. But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G) entry holds the oif of the (*,G), if the RP information is not present - * (*,G) will be deleted and oif learnt from (*,G) will be deleted from (S,G) also, irrespective of whether local receivers present or not. * When the RP information is learnt again, (*,G) entry would be re-created if the receivers are still present. Do you still think if RP information is not present (in the case of SM only), multicast packets would flow ? Thanks & Regards C.Uma -----Original Message----- From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in] Sent: Wednesday, December 18, 2002 11:16 AM To: umac@future.futsoft.com Cc: smiley_raj@excite.com; pim@catarina.usc.edu Subject: RE: [pim] doubt regard RP absence in the network Hi Uma, If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table. So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S". Thanx, Jags Uma C wrote: Hello Jags When there is no RP information - 1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ? 2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted. I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets. I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case. Pl correct me if I am in wrong in my understanding. Thanks & Regards C.Uma -----Original Message----- From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu Sent: Tuesday, December 17, 2002 8:38 PM To: smiley_raj@excite.com; pim@catarina.usc.edu Subject: Re: [pim] doubt regard RP absence in the network Hi rajesh, If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded. I hope the above information will help you, if i have understood your question correctly. Regards, Jags "smiley_raj@excite.com" wrote: Hi, I have the following doubt, If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him. thanks in advance rajesh, Join Excite! - The most personalized portal on the Web! Catch all the cricket action. Download Yahoo! Score tracker Catch all the cricket action. Download Yahoo! Score tracker Catch all the cricket action. Download Yahoo! Score tracker Catch all the cricket action. Download Yahoo! Score tracker Catch all the cricket action. Download Yahoo! Score tracker Catch all the cricket action. Download Yahoo! Score tracker --0-1429828762-1040287847=:46093 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi Uma,

   I think, you need to read my topology properly, where i have mensioned about IGMPV3 and not IGMPV2. If you spend some time to read the topology properly, you might not be having such a doubts (IGMPV3/V2).

Regards,

Jags

 Uma C <umac@future.futsoft.com> wrote:

Hello John & Jags
 
I also agreed upon what Jags has mentioned in his topology.

>>> 3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.

>>> (S,G) - oiflist=2
>>> [Uma C]  Yes, multicast packets should flow on interface 2. I agree with this. 

 
Pl confirm only this -
* Received IGMPv2 Join, created a (*,G) entry.
* Switched to SPT, hence (S,G) entry is created. (*, G) and (S, G) entry holds the same oif.
* Packets are flowing through SPT.
* Now when the RP information is not present. (*,G) entry is deleted.
 
Will the (S,G) entry exists ? Would the data packets flow ?.
 
Note:- In all this discussion I was only referring to receivers joining through IGMPv2 Join. In the case of IGMPv3 Join ie., source specific Join I agree that packets will be flowing irrespective of RP informations present or not.
 
Hope this time I have expressed my thoughts clearly.
 
Thanks & Regards
C.Uma
 
-----Original Message-----
From: john nowa [mailto:john_nowa@yahoo.co.in]
Sent: Wednesday, December 18, 2002 9:09 PM
To: Rajamanickam jaganbabu; umac@future.futsoft.com
Cc: pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network

hello umaaa,

       I guess, whatever jags referring is correct. According to his topology, we can still forward the multicast packet for (S,G).

John

 Rajamanickam jaganbabu <jaganbabu_pim@yahoo.co.in> wrote:

Hi uma,

Whatever I have mentioned below was only with respect to SM domain (I haven't mentioned SSM case, which is altogether a different story). I don't understand why you need to delete even (S,G) if you don't have (*,G), draft doesn't say that. But according to the draft, we need to remove only inherited outlist from (S,G) entry, but in our case we have immediate outgoing list in (S,G) which is not a part of inherited list (if the (S,G) immediate outlist and inherited outlist are same then only we should remove (S,G) entry from your multicast forwarding table), so there is no point and we should not delete (S,G) entry from the multicast routing table even if (*,G) entry is deleted.

I hope u understand the logic.

Regards,

Jags

 Uma C <umac@future.futsoft.com> wrote:

Hello Jags
 
Pl find my response inlined with the tag <UMA>.
 
Regards
C.Uma
 
-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Wednesday, December 18, 2002 2:44 PM
To: umac@future.futsoft.com
Cc: pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network

Hi uma,

1. Even in normal SM case, multicast forwarding is possible even if we don't have RP information.
[Uma C] I guess not. In the example you had given includes SSM also. 

=========

2. When we are deleting (*,G) entry, it is not mandatory to remove all the (S,G) entry from the multicast forwarder unless and until all the outgoing interface list is null.
[Uma C] I agree with you. And in the SM case there cannot be a situation when (*,G) is deleted but (S,G) still remains.

==================

I have explained how it can happen using the following topology (fig. as an attachment).

Explanation:

1. If Rec_1 sends an (*,G) IGMP join to the PIM router "R1", then the PIM forwarding table at R1 look like

(*,G) - oiflist=1

2. After some time, if Rec_2 send (src,G,1) IGMPV3 join, then the PIM forwarding table at R1 looks like

(S,G) - oiflist=1,2

(*,G) - oiflist=1

In the above forwarding table while adding (S,G) entry, the inherited outgoing list will be 1 and the immediate outgoing list will be 2, so consolidating the outgoing interface for (S,G) will 1 and 2

3, In case, if RP goes off, then R1 has to remove the (*,G) entry from the forwarding table and remove the inherited outgoing list, so after the (*,G) removal, the multicast forwarder looks like this.

(S,G) - oiflist=2
[Uma C]  Yes, multicast packets should flow on interface 2. I agree with this. But the discussion started with whether multicast packets can be forwarded in PIM-SM domain only (This is want Rajesh asked for) when RP information is not present. In this case do not execute the step 2, so the (*,G) and (S,G) will hold the same oif, and hence both of these entries get deleted. So the multicast packets stop flowing.

================

So even in SM. it is not necessary to remove all the (S,G) entries if you remove (*,G) entry from the multicast forwarding table.
[Uma C] I guess not in the SM domain (which doesnot include SSM). I apreciate the interest you had taken to explain the situation with a topology. Thanks Jags.

=================

Regards,

Jags

Uma C <umac@future.futsoft.com> wrote:

Hello Jags

I guess in the case of IGMPv3, we do not create any (*,G) entry as the Group range for SSM is different. And as you said we can still forward the packets whether there is RP information or not.

But in the case of SM only, where (*,G) and (S,G) entry exists and (S,G) entry holds the oif of the (*,G), if the RP information is not present -

* (*,G) will be deleted and oif learnt from (*,G) will be deleted from (S,G) also, irrespective of whether local receivers present or not.

* When the RP information is learnt again, (*,G) entry would be re-created if the receivers are still present.

Do you still think if RP information is not present (in the case of SM only), multicast packets would flow ?

Thanks & Regards

C.Uma

-----Original Message-----
From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in]
Sent: Wednesday, December 18, 2002 11:16 AM
To: umac@future.futsoft.com
Cc: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: RE: [pim] doubt regard RP absence in the network

Hi Uma,

If there is an IGMPV3 request from the receiver, asking for (S,G,I) join to a particular source, then we will be having an (S,G) entry, which will be the super set of (*,G) outgoing list. If we lost (*,G) information, then it will affect (S,G) inherited outgoing list but there is a possible case where we can have immediate outgoing list exist for (S,G) (which is not in inherited outgoing list), so at this point even we delete (*,G) entry from our multicast forwarding table still (S,G) entry will be existing in the multicast forwarding table.

So my conclusion is, in the above case even if we lost our RP information, still we can forward the multicast packet using (S,G) information for a source "S".

Thanx,

Jags

Uma C <umac@future.futsoft.com> wrote:

Hello Jags

When there is no RP information -

1. (*,G) entry would surely get deleted. Outgoing interface in that (*,G) and (S,G) also gets deleted. So how are the packets still flowing ?

2. If the (*,G) entry alone gets deleted because of the RP information not present and when the receiver leave the group, will the (S,G) entry get deleted ?. If yes how ? On what basis will this (S,G) entry get deleted.

I guess the entries at SPT built routers would get deleted only when source of the multicast packet stops sending packets.

I feel that, when the (*,G) entry gets deleted, (S,G) entry also would be deleted and there want be a case in which multicast packets will be flowing. Well I haven't thought about SSM case.

Pl correct me if I am in wrong in my understanding.

Thanks & Regards

C.Uma

-----Original Message-----
From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Rajamanickam jaganbabu
Sent: Tuesday, December 17, 2002 8:38 PM
To: smiley_raj@excite.com; pim@catarina.usc.edu
Subject: Re: [pim] doubt regard RP absence in the network

Hi rajesh,

If the receiver and the source has the Source Path Tree established (i.e if we have (S,G) entry in the Multicast forwarding table), then irrespective of the RP information availability, the multicast packet will be forwarded.

I hope the above information will help you, if i have understood your question correctly.

Regards,

Jags

"smiley_raj@excite.com" <smiley_raj@excite.com> wrote:

Hi,
I have the following doubt,

If there is no RP in the network or all the RPs expire in the network. Can there be packet forwarding activity in a PIM-SM (only) domain. In clear my doubt is can the receivers switched over to the packet forwarding via SPT still continue to receive the data packets even if there is not RP information with him.
thanks in advance
rajesh,


 

Join Excite! - <http://www.excite.com/>
The most personalized portal on the Web!

Catch all the cricket action. Download Yahoo! Score tracker <http://in.sports.yahoo.com/cricket/tracker.html>

Catch all the cricket action. Download Yahoo! Score tracker <http://in.sports.yahoo.com/cricket/tracker.html>

Catch all the cricket action. Download Yahoo! Score tracker

Catch all the cricket action. Download Yahoo! Score tracker

Catch all the cricket action. Download Yahoo! Score tracker

Catch all the cricket action. Download Yahoo! Score tracker --0-1429828762-1040287847=:46093-- _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim --0-1871294350-1053507519=:58353-- _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 21 10:27:54 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23307 for ; Wed, 21 May 2003 10:27:53 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4LEOMX20272; Wed, 21 May 2003 07:24:22 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from aibo.runbox.com (cujo.runbox.com [193.71.199.138]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4LELfX20216 for ; Wed, 21 May 2003 07:21:41 -0700 (PDT) (envelope-from shankarv@runbox.com) Received: from [10.9.9.15] (helo=odie.runbox.com) by lufsen.runbox.com with esmtp (Exim 4.14) id 19IUTL-0000Lv-UM for pim@catarina.usc.edu; Wed, 21 May 2003 16:21:39 +0200 Received: from mail by odie.runbox.com with local (Exim 4.14) id 19IUTB-0005hy-L8 for pim@catarina.usc.edu; Wed, 21 May 2003 16:21:29 +0200 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline MIME-Version: 1.0 From: "Shankar Vasudevan" Reply-To: shankarv@runbox.com To: pim@catarina.usc.edu X-Sender: 197044 X-Mailer: RMM Message-Id: X-Sender: unknown Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4LELfX20216 Subject: [pim] IGMPv3 and RFC 2715 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 May 2003 14:21:29 GMT Content-Transfer-Encoding: 8bit Hi *, RFC 2715 specifies how a IGMP-only component interops with other multicast routing protocols. This covers IGMPv2 only. Is there a similar specification which extends the same interop rules to IGMPv3 ? I am more interested in the behaviour of a router which has the PIM-SM on some links and IGMPv3 on other links, and when a (S,G) exclude is received and how this is reflected in the PIM-SM protocol. Is there any implementation which has IGMPv3 (S,G) exclude messages triggering PIM-SM (S,G,rpt) prunes ? Best Regards, shankar _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 21 10:32:58 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23454 for ; Wed, 21 May 2003 10:32:58 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4LEQOX20343; Wed, 21 May 2003 07:26:24 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from aibo.runbox.com (cujo.runbox.com [193.71.199.138]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4LEOAX20265 for ; Wed, 21 May 2003 07:24:10 -0700 (PDT) (envelope-from shankarv@runbox.com) Received: from [10.9.9.15] (helo=odie.runbox.com) by lufsen.runbox.com with esmtp (Exim 4.14) id 19IUVk-0000Yn-OT for pim@catarina.usc.edu; Wed, 21 May 2003 16:24:08 +0200 Received: from mail by odie.runbox.com with local (Exim 4.14) id 19IUVJ-0005sy-I8 for pim@catarina.usc.edu; Wed, 21 May 2003 16:23:41 +0200 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline MIME-Version: 1.0 From: "Shankar Vasudevan" Reply-To: shankarv@runbox.com To: pim@catarina.usc.edu X-Sender: 197044 X-Mailer: RMM Message-Id: X-Sender: unknown Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4LEOAX20265 Subject: [pim] searching the archive. Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 May 2003 14:23:41 GMT Content-Transfer-Encoding: 8bit Hi *, I see that there is huge amount of information in the archives. Is there a search tool available for the archive ? If this is there, then we could avoid possible redundant questions ? Best Regards, shankar _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 21 13:01:00 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28156 for ; Wed, 21 May 2003 13:01:00 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4LGvgX23010; Wed, 21 May 2003 09:57:42 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from dmz2.procket.com (dmz2.procket.com [65.174.124.37]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4LGtOX22965 for ; Wed, 21 May 2003 09:55:24 -0700 (PDT) (envelope-from John.Zwiebel@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id E980F34449; Wed, 21 May 2003 09:09:51 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4LGtDYB013012; Wed, 21 May 2003 09:55:14 -0700 (PDT) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 09:55:13 -0700 Subject: Re: [pim] about the (*,G),(S,G) entry creation and deletion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Bandi, Sarveshwar" , To: "bharat_joshi" From: John Zwiebel In-Reply-To: <56E2573C375A414191118970BDE06A150ABE5EEA@kecmsg06.ad.infosys.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 21 May 2003 16:55:13.0844 (UTC) FILETIME=[BF7B3740:01C31FB9] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 May 2003 09:53:26 -0700 Content-Transfer-Encoding: 7bit There seems to be some confusion... Please listen to me when I tell you "ASM is dead" Long live SSM Long Live Bidir. My point here is, much of the discussion on this list is about nitty details on how to implement the PIM-SM draft. This is, of course, necessary to be able to interoperate with legacy multicast deployments and to allow users the opportunity to see how SSM and Bidir might benefit them. HOWEVER, you need a "good enough" ASM implementation and you should be concentrating on developing a superior SSM and Bidir implementation. (Of course, if you don't want to go that route, that's fine with me, we'll be happy to sell into that market.) After 10 years of looking at this stuff, here are some points to consider. -- For ASM: When an RP receives a PIM register, it -should- create (S,G) state whether or not there are receivers. Receivers may join after the source has started to send and you don't want to have to wait for 60 seconds for the first packet to come down the shared tree. -- The shared-path and the shortest-path are two different entities. In ASM the -only- reason for the shared-path is to deliver the first data packet to the receiver so the last-hop can join to the shortest-path. BEFORE, you all say, "but what about staying on the shared-path", yes it is possible to do this, but let's be very clear, if you elect to stay on the shared-path it is impractical to switch to the shortest-path when/if the data rate of a particular source rises above a given threshold. Yes, some implementations do this. But it -does-not- work. Therefore, if you are going to stay on the shared-path, the spt-threshold -must- be set to infinity. And if you are going to do that, why aren't you using bidir. -- If you think of the shared-path and shortest-path as separate entities, it becomes easier to figure out what's suppose to happen when they intersect. There are -tons- of things that the spec does not specify. For example: if you are a transient router, and you haven't received a PIM (S,G) join, but you do see multicast traffic on a non-RPF interface what are you suppose to do? From the specs perspective: nothing. From a practical perspective though, doing nothing may be very, very costly depending on the size of the data pipe (ie is it a 10gig interface with 9gig of multicast traffic -- of which every multicast packet must be examined by the router to determine whether or not the router is suppose to deal with it.) (SSM and bidir reduce these problems considerably) -- WRT SSM, the only router that requires anything different from ASM SPT code is the last-hop. The last-hop needs to be informed of the source in some way so it can join to the shortest-path. Whether it is IGMPv3 or data delivered down the ASM shared-tree or Cisco's URD, or whatever new receiver-to-router protocol you might want to implement, once the router knows the (S,G) it triggers a join toward the source and the forwarding path is brought up. BEFORE you say "what about the keepalive timer", remember users don't care as long as the data is getting received. Yes, in SSM the receipt of a PIM (S,G) join is suppose to update the keepalive timer and this does not happen with ASM. This is a very minor difference that isn't going to be noticed if data is being forwarded down the SPT. -- The biggest mistake we made in developing PIM was to believe that it was impossible to change the multicast model. It is silly to think that we will ever be able to develop fast enough routers that the network will ever be reliable enough to "just handle" delivery of the first packet data packet to every receiver in the internet. Some sort of "request-to-send/cleared-to-send" mechanism is required. Right now that mechanism defaults to, "go ahead and send, if I (the receiver) miss something I won't care" because most multicast is audio/video. Something better is required if we are going to be able to deliver file transfer via multicast. (PGM not withstanding.) It appears to me that this RTS/CTS mechanism is probably application specific, or is at least, a layer-4 problem. -- PIM-SM is extremely complicated because of the switch between the shared-path and the SPT. It is non-deterministic because one never knows where these two paths will diverge or intersect with one another. Assert processing is extremely difficult to do without incurring huge CPU costs -- unless you are talking about a very low-end router. If your product is such a router, you may think that you don't care about the problems of the high-end vendors. But the high-end -must- move away from ASM. If you (the low-end) don't move the same way, multicast will spend another 10 years not realizing its potential. -- SSM is simple to understand and implement. Routes can be set up prior to the first data packet being sent. It interoperates "almost perfectly" with the deployed ASM routers. I encourage you all to make whatever noise is required to get the internet community to move in that direction. Windows supports IGMPv3. That alone "should be" a large enough installed base to move applications in that direction. (I don't suppose there are any application developers on this list ). -- Bidir is simple to understand and implement. It is presently limited to inside of an enterprise, but it isn't clear that a many-to-many application that spans the internet with thousands of participants is a realistic possibility right now. -- Neither Bidir nor SSM require BGMP. BGMP isn't going to go anywhere. -- Interdomain ASM requires MSDP (or BGMP). No one has figured out how to make MSDP work yet. It barely works "good enough". IMHO, it is one of the major stumbling blocks to multicast deployment. So, I'd like to encourage you to "move on". Your ASM pim is probably "good enough" now. If it isn't, well, you are implementing yesterday's technology. Its kind of like deciding that you need a really good X.25 implementation in your router now. (or ATM ;-) 2cents On Wednesday, May 21, 2003, at 12:49 AM, bharat_joshi wrote: > Hi, > > *,G state will be there when IGMP hosts have not been updated to IGMPv3 > and the desginated rotuers doesn't support IGMPv3. > > Lets say we have IGMPv2 on a LAN, the DR will always generate a *,G > join/prune for a IGMP join/leave message. > > S,G state will come in picture when DR start switch to SPT but in this > case you will need to maintain *,G and S,G both becuase the router will > never come to know that the hosts connected to LAN wants packet from > which all sources. > > If hosts are running IGMPV3 than a *,G entry may not be created. > > Thanks, > Bharat > > > > -----Original Message----- > From: Bandi, Sarveshwar [mailto:sarveshwarb@netplane.com] > Sent: Wed 5/21/2003 12:13 PM > To: 'Zhang Yanxing'; pim@catarina.usc.edu > Cc: > Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion > > One comment, I dont think the spec says explicitly that a (*,G) should > exist > when (S,G) exists. If someone were to have only SSM routes in a > network, > having (*,G) routes would not make any sense. I think creation of (*,G) > route when (S,G) routes are created is an implementation issue. We > have an > implementation where (*,G) routes created as and when needed. > > Would love to hear others comments on this > > Regards, > Sarvesh > > -----Original Message----- > From: Zhang Yanxing [mailto:yxzhang@utstar.com] > Sent: Wednesday, May 21, 2003 8:06 AM > To: pim@catarina.usc.edu > Subject: [pim] about the (*,G),(S,G) entry creation and deletion > > > I think it maybe one implementation problem, I want to speak out > my > thought to see if it is correct. > Multicast Route entry is created when some interfaces receive the > (*,G) or > (S,G) join message. > When all the joined before interfaces recieve prune message(after the > prune > override interval) or > the join timer expires, the entry will be deleted. This mechanism > shows the > difference between the DM and > SM. > But at the DR with the directly connected senders and the RP, I > think > the (S,G) entry creation is something > like the DM, it is built by the traffic driven. > Another point is that does the specification imply that if (S,G) > exist, > the (*,G) should exist too? > Welcome comments, Thanks. > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim > > > > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 21 13:16:42 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28806 for ; Wed, 21 May 2003 13:16:41 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4LHASX23364; Wed, 21 May 2003 10:10:28 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4LH8nX23304 for ; Wed, 21 May 2003 10:08:49 -0700 (PDT) (envelope-from John.Zwiebel@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8AC4A23C2C; Wed, 21 May 2003 09:56:53 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4LH8hYB013977; Wed, 21 May 2003 10:08:43 -0700 (PDT) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 10:08:43 -0700 Subject: Re: [pim] IGMPv3 and RFC 2715 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: pim@catarina.usc.edu To: shankarv@runbox.com From: John Zwiebel In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 21 May 2003 17:08:43.0682 (UTC) FILETIME=[A22EB020:01C31FBB] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 May 2003 10:06:56 -0700 Content-Transfer-Encoding: 7bit On Wednesday, May 21, 2003, at 07:21 AM, Shankar Vasudevan wrote: > Hi *, > > RFC 2715 specifies how a IGMP-only component interops with other > multicast routing protocols. This covers IGMPv2 only. Is there a > similar specification which extends the same interop rules to IGMPv3 ? > > I am more interested in the behaviour of a router which has the > PIM-SM on some links and IGMPv3 on other links, and when a (S,G) > exclude is received and how this is reflected in the PIM-SM protocol. > > Is there any implementation which has IGMPv3 (S,G) exclude messages > triggering PIM-SM (S,G,rpt) prunes ? > IGMPv3 is used with SSM. RP-bit prunes are part of ASM. It would be "better" to convince your customer that they want to move to SSM than to try to integrate IGMPv3 (S,G) include/exclude messages into ASM. (I'll admit I don't see why runbox would be interested in ASM). _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu May 22 00:41:50 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18462 for ; Thu, 22 May 2003 00:41:49 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4M4cPX36062; Wed, 21 May 2003 21:38:26 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from bosvwl02.infosys.com (bosvwl02.inf.com [216.52.49.36]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4M4YuX35983 for ; Wed, 21 May 2003 21:34:56 -0700 (PDT) (envelope-from bharat_joshi@infosys.com) Received: from 192.168.200.81 by bosvwl02.infosys.com (InterScan E-Mail VirusWall NT); Thu, 22 May 2003 00:36:37 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 10:04:12 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 10:04:12 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [pim] IGMPv3 and RFC 2715 Message-ID: <56E2573C375A414191118970BDE06A150ABE5EF3@kecmsg06.ad.infosys.com> Thread-Topic: [pim] IGMPv3 and RFC 2715 Thread-Index: AcMfwsPFMZszBiNiTnmNKkZOt9hz9gAWBerL From: "bharat_joshi" To: "John Zwiebel" , Cc: X-OriginalArrivalTime: 22 May 2003 04:34:12.0438 (UTC) FILETIME=[64D4CF60:01C3201B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4M4YuX35983 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 May 2003 10:04:12 +0530 Content-Transfer-Encoding: 8bit On Wednesday, May 21, 2003, at 07:21 AM, Shankar Vasudevan wrote: > Hi *, > > RFC 2715 specifies how a IGMP-only component interops with other > multicast routing protocols. This covers IGMPv2 only. Is there a > similar specification which extends the same interop rules to IGMPv3 ? > > I am more interested in the behaviour of a router which has the > PIM-SM on some links and IGMPv3 on other links, and when a (S,G) > exclude is received and how this is reflected in the PIM-SM protocol. > > Is there any implementation which has IGMPv3 (S,G) exclude messages > triggering PIM-SM (S,G,rpt) prunes ? > IGMPv3 is used with SSM. RP-bit prunes are part of ASM. It would be "better" to convince your customer that they want to move to SSM than to try to integrate IGMPv3 (S,G) include/exclude messages into ASM. (I'll admit I don't see why runbox would be interested in ASM). ----------------- Hi, I think if your PIM router is connected to a LAN which understand IGMPv3 and is a DR on that LAN than if Router receives a IGMPv3 exclude report for lets say source "s" than he will need to send a (*,G) join and (S,G,Rpt) prune message. I think a implementation has to support this. If the router is not running PIM on the LAN interface where it hear a IGMPv3 join than it can not take any action because the DR on that LAN is suppose to take care of the IGMP hosts. Thanks, Bharat _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu May 22 03:25:03 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03287 for ; Thu, 22 May 2003 03:25:02 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4M7KgX38976; Thu, 22 May 2003 00:20:42 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from aibo.runbox.com (cujo.runbox.com [193.71.199.138]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4M7IdX38926 for ; Thu, 22 May 2003 00:18:39 -0700 (PDT) (envelope-from shankarv@runbox.com) Received: from [10.9.9.15] (helo=odie.runbox.com) by lufsen.runbox.com with esmtp (Exim 4.14) id 19IkLS-0007de-53; Thu, 22 May 2003 09:18:34 +0200 Received: from mail by odie.runbox.com with local (Exim 4.14) id 19IkLB-0000Vx-EZ; Thu, 22 May 2003 09:18:17 +0200 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline MIME-Version: 1.0 From: "Shankar Vasudevan" Reply-To: shankarv@runbox.com To: bharat_joshi@infosys.com Cc: jzwiebel@procket.com, pim@catarina.usc.edu Subject: Re: [pim] IGMPv3 and RFC 2715 X-Sender: 197044 X-Mailer: RMM Message-Id: X-Sender: unknown Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4M7IdX38926 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 May 2003 07:18:17 GMT Content-Transfer-Encoding: 8bit Hi Bharat, There is no need for PIM to be running on the LAN. Here is where RFC 2715 comes in to picture. How else will the IGMP protocol by itself bring down traffic to the LAN ? it has to speak to some multicast routing protocol right ? Best Regards, shankar > On Wednesday, May 21, 2003, at 07:21 AM, Shankar Vasudevan wrote: > > > Hi *, > > > > RFC 2715 specifies how a IGMP-only component interops with other > > multicast routing protocols. This covers IGMPv2 only. Is there a > > similar specification which extends the same interop rules to IGMPv3 ? > > > > I am more interested in the behaviour of a router which has the > > PIM-SM on some links and IGMPv3 on other links, and when a (S,G) > > exclude is received and how this is reflected in the PIM-SM protocol. > > > > Is there any implementation which has IGMPv3 (S,G) exclude messages > > triggering PIM-SM (S,G,rpt) prunes ? > > > > IGMPv3 is used with SSM. RP-bit prunes are part of ASM. > It would be "better" to convince your customer that they want to move > to SSM than > to try to integrate IGMPv3 (S,G) include/exclude messages into ASM. > (I'll admit I don't see why runbox would be interested in ASM). > > ----------------- > > Hi, > > I think if your PIM router is connected to a LAN which understand IGMPv3 and is a DR on that LAN than if Router receives a IGMPv3 exclude report for lets say source "s" than he will need to send a (*,G) join and (S,G,Rpt) prune message. > > I think a implementation has to support this. > > If the router is not running PIM on the LAN interface where it hear a IGMPv3 join than it can not take any action because the DR on that LAN is suppose to take care of the IGMP hosts. > > Thanks, > Bharat > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim > > > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim > _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu May 22 03:52:54 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03900 for ; Thu, 22 May 2003 03:52:54 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4M7ndX39533; Thu, 22 May 2003 00:49:39 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from bosvwl01.infosys.com (bosvwl01.itlinfosys.com [216.52.49.35]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4M7lLX39480 for ; Thu, 22 May 2003 00:47:21 -0700 (PDT) (envelope-from bharat_joshi@infosys.com) Received: from 192.168.200.82 by bosvwl01.infosys.com (InterScan E-Mail VirusWall NT); Thu, 22 May 2003 03:47:45 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 13:17:11 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 13:17:11 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [pim] IGMPv3 and RFC 2715 Message-ID: <56E2573C375A414191118970BDE06A150ABE5EF5@kecmsg06.ad.infosys.com> Thread-Topic: [pim] IGMPv3 and RFC 2715 Thread-Index: AcMgM5tLSI/rjLpYTgyKBlfjQUsyNwAAgggw From: "bharat_joshi" To: Cc: , X-OriginalArrivalTime: 22 May 2003 07:47:11.0254 (UTC) FILETIME=[5A57EB60:01C32036] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4M7lLX39480 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 May 2003 13:16:21 +0530 Content-Transfer-Encoding: 8bit Hi Shankar, I think we both agree that when PIM is running on the LAN interface, it will take care of the IGMPv3 exclude message by sending a (*,G) and ( S,G,Rpt ) join message towards RP. Now if you are not running PIM on this interface or you are running some other multicast routing protocol lets say DVMRP. This router will become the PIM domain border router and now will act as a PMBR. Now for this kind of scenarios, section 4.7 in PIM draft defines the behaviour of a PMBR. HTH, Bharat -----Original Message----- From: Shankar Vasudevan [mailto:shankarv@runbox.com] Sent: Thu 5/22/2003 12:48 PM To: bharat_joshi Cc: jzwiebel@procket.com; pim@catarina.usc.edu Subject: Re: [pim] IGMPv3 and RFC 2715 Hi Bharat, There is no need for PIM to be running on the LAN. Here is where RFC 2715 comes in to picture. How else will the IGMP protocol by itself bring down traffic to the LAN ? it has to speak to some multicast routing protocol right ? Best Regards, shankar > On Wednesday, May 21, 2003, at 07:21 AM, Shankar Vasudevan wrote: > > > Hi *, > > > > RFC 2715 specifies how a IGMP-only component interops with other > > multicast routing protocols. This covers IGMPv2 only. Is there a > > similar specification which extends the same interop rules to IGMPv3 ? > > > > I am more interested in the behaviour of a router which has the > > PIM-SM on some links and IGMPv3 on other links, and when a (S,G) > > exclude is received and how this is reflected in the PIM-SM protocol. > > > > Is there any implementation which has IGMPv3 (S,G) exclude messages > > triggering PIM-SM (S,G,rpt) prunes ? > > > > IGMPv3 is used with SSM. RP-bit prunes are part of ASM. > It would be "better" to convince your customer that they want to move > to SSM than > to try to integrate IGMPv3 (S,G) include/exclude messages into ASM. > (I'll admit I don't see why runbox would be interested in ASM). > > ----------------- > > Hi, > > I think if your PIM router is connected to a LAN which understand IGMPv3 and is a DR on that LAN than if Router receives a IGMPv3 exclude report for lets say source "s" than he will need to send a (*,G) join and (S,G,Rpt) prune message. > > I think a implementation has to support this. > > If the router is not running PIM on the LAN interface where it hear a IGMPv3 join than it can not take any action because the DR on that LAN is suppose to take care of the IGMP hosts. > > Thanks, > Bharat > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim > > > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim > _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu May 22 07:12:55 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08600 for ; Thu, 22 May 2003 07:12:55 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4MB9vX43765; Thu, 22 May 2003 04:09:57 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from web8205.mail.in.yahoo.com (web8205.mail.in.yahoo.com [203.199.70.126]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4MB7OX43709 for ; Thu, 22 May 2003 04:07:24 -0700 (PDT) (envelope-from jaganbabu_pim@yahoo.co.in) Message-ID: <20030522110716.60436.qmail@web8205.mail.in.yahoo.com> Received: from [129.188.33.221] by web8205.mail.in.yahoo.com via HTTP; Thu, 22 May 2003 12:07:16 BST From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?= Subject: Re: [pim] null register dummy ip header To: Mark Handley Cc: pim@catarina.usc.edu In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2014931155-1053601636=:58044" Content-Transfer-Encoding: 8bit Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 May 2003 12:07:16 +0100 (BST) --0-2014931155-1053601636=:58044 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi guys, I have a funny doubt, In the Null register message, instead of sending a dummy ip header why don't we send a direct group address (group format) and source address (unicast format). I hope if we do in the above manner, we won't have the problems and debates of setting the different values in the IP headers. It would be great if anybody could tell me why we can't do as the above which I have mentioned. Sorry for the delay Thanx, Jags JINMEI Tatuya / $B?@L@C#:H(B wrote: >>>>> On Mon, 19 May 2003 14:55:31 -0700, >>>>> Mark Handley said: > And something similar with IPv6. Hmm, but IPv6 does not have a checksum field in its base header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (from Section 3 of RFC 2460) So, if we really need to care about this for IPv6, we may have to either: - add a (dummy) PIM header after the inner IPv6 header, and put the checksum for the inner headers there. - reuse a different field of the inner basic IPv6 header (e.g. the payload length field) for this specific checksum. - (there may be other options) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim Catch all the cricket action. Download Yahoo! Score tracker --0-2014931155-1053601636=:58044 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi guys,

I have a funny doubt, In the Null register message, instead of sending a dummy ip header why don't we send a direct group address (group format) and source address (unicast format).

I hope if we do in the above manner, we won't have the problems and debates of setting the different values in the IP headers.

It would be great if anybody could tell me why we can't do as the above which I have mentioned.

  Sorry for the delay

Thanx,

Jags

JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp> wrote:
>>>>> On Mon, 19 May 2003 14:55:31 -0700,
>>>>> Mark Handley said:

> And something similar with IPv6.

Hmm, but IPv6 does not have a checksum field in its base header:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(from Section 3 of RFC 2460)

So, if we really need to care about this for IPv6, we may ! have to
either:

- add a (dummy) PIM header after the inner IPv6 header, and put the
checksum for the inner headers there.
- reuse a different field of the inner basic IPv6 header (e.g. the
payload length field) for this specific checksum.
- (there may be other options)

JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim

Catch all the cricket action. Download Yahoo! Score tracker --0-2014931155-1053601636=:58044-- _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu May 22 11:16:12 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18134 for ; Thu, 22 May 2003 11:16:12 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4MFD0X48135; Thu, 22 May 2003 08:13:00 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4MFAmX48091 for ; Thu, 22 May 2003 08:10:48 -0700 (PDT) (envelope-from sarveshwarb@netplane.com) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h4MFAlXN025932 for ; Thu, 22 May 2003 08:10:47 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h4MFAgQx021579 for ; Thu, 22 May 2003 10:10:42 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 May 2003 11:10:26 -0400 Message-ID: From: "Bandi, Sarveshwar" To: "'John Zwiebel'" , bharat_joshi Cc: "Bandi, Sarveshwar" , pim@catarina.usc.edu Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 May 2003 11:12:04 -0400 Hi John, I have heard this opinion of yours already, Just one observation about your comment... -------------------------------------- " Assert processing is extremely difficult to do without incurring huge CPU costs -- unless you are talking about a very low-end router. If your product is such a router, you may think that you don't care about the problems of the high-end vendors. But the high-end -must- move away from ASM. If you (the low-end) don't move the same way, multicast will spend another 10 years not realizing its potential." ------------------------------------- Assert mechanism is used to detect duplication of data on both the SPT and RPT as well. Even if you do (S,G) join you still can have duplication of data. And the assert operations would be equally costly both on the RPT or SPT. If not for the assert mechanism, one would need to come up with some way of solving (if possible) this problem. And probably that solution could be applied to RPT as well. Sarvesh -----Original Message----- From: John Zwiebel [mailto:jzwiebel@procket.com] Sent: Wednesday, May 21, 2003 10:23 PM To: bharat_joshi Cc: Bandi, Sarveshwar; pim@catarina.usc.edu Subject: Re: [pim] about the (*,G),(S,G) entry creation and deletion There seems to be some confusion... Please listen to me when I tell you "ASM is dead" Long live SSM Long Live Bidir. My point here is, much of the discussion on this list is about nitty details on how to implement the PIM-SM draft. This is, of course, necessary to be able to interoperate with legacy multicast deployments and to allow users the opportunity to see how SSM and Bidir might benefit them. HOWEVER, you need a "good enough" ASM implementation and you should be concentrating on developing a superior SSM and Bidir implementation. (Of course, if you don't want to go that route, that's fine with me, we'll be happy to sell into that market.) After 10 years of looking at this stuff, here are some points to consider. -- For ASM: When an RP receives a PIM register, it -should- create (S,G) state whether or not there are receivers. Receivers may join after the source has started to send and you don't want to have to wait for 60 seconds for the first packet to come down the shared tree. -- The shared-path and the shortest-path are two different entities. In ASM the -only- reason for the shared-path is to deliver the first data packet to the receiver so the last-hop can join to the shortest-path. BEFORE, you all say, "but what about staying on the shared-path", yes it is possible to do this, but let's be very clear, if you elect to stay on the shared-path it is impractical to switch to the shortest-path when/if the data rate of a particular source rises above a given threshold. Yes, some implementations do this. But it -does-not- work. Therefore, if you are going to stay on the shared-path, the spt-threshold -must- be set to infinity. And if you are going to do that, why aren't you using bidir. -- If you think of the shared-path and shortest-path as separate entities, it becomes easier to figure out what's suppose to happen when they intersect. There are -tons- of things that the spec does not specify. For example: if you are a transient router, and you haven't received a PIM (S,G) join, but you do see multicast traffic on a non-RPF interface what are you suppose to do? From the specs perspective: nothing. From a practical perspective though, doing nothing may be very, very costly depending on the size of the data pipe (ie is it a 10gig interface with 9gig of multicast traffic -- of which every multicast packet must be examined by the router to determine whether or not the router is suppose to deal with it.) (SSM and bidir reduce these problems considerably) -- WRT SSM, the only router that requires anything different from ASM SPT code is the last-hop. The last-hop needs to be informed of the source in some way so it can join to the shortest-path. Whether it is IGMPv3 or data delivered down the ASM shared-tree or Cisco's URD, or whatever new receiver-to-router protocol you might want to implement, once the router knows the (S,G) it triggers a join toward the source and the forwarding path is brought up. BEFORE you say "what about the keepalive timer", remember users don't care as long as the data is getting received. Yes, in SSM the receipt of a PIM (S,G) join is suppose to update the keepalive timer and this does not happen with ASM. This is a very minor difference that isn't going to be noticed if data is being forwarded down the SPT. -- The biggest mistake we made in developing PIM was to believe that it was impossible to change the multicast model. It is silly to think that we will ever be able to develop fast enough routers that the network will ever be reliable enough to "just handle" delivery of the first packet data packet to every receiver in the internet. Some sort of "request-to-send/cleared-to-send" mechanism is required. Right now that mechanism defaults to, "go ahead and send, if I (the receiver) miss something I won't care" because most multicast is audio/video. Something better is required if we are going to be able to deliver file transfer via multicast. (PGM not withstanding.) It appears to me that this RTS/CTS mechanism is probably application specific, or is at least, a layer-4 problem. -- PIM-SM is extremely complicated because of the switch between the shared-path and the SPT. It is non-deterministic because one never knows where these two paths will diverge or intersect with one another. Assert processing is extremely difficult to do without incurring huge CPU costs -- unless you are talking about a very low-end router. If your product is such a router, you may think that you don't care about the problems of the high-end vendors. But the high-end -must- move away from ASM. If you (the low-end) don't move the same way, multicast will spend another 10 years not realizing its potential. -- SSM is simple to understand and implement. Routes can be set up prior to the first data packet being sent. It interoperates "almost perfectly" with the deployed ASM routers. I encourage you all to make whatever noise is required to get the internet community to move in that direction. Windows supports IGMPv3. That alone "should be" a large enough installed base to move applications in that direction. (I don't suppose there are any application developers on this list ). -- Bidir is simple to understand and implement. It is presently limited to inside of an enterprise, but it isn't clear that a many-to-many application that spans the internet with thousands of participants is a realistic possibility right now. -- Neither Bidir nor SSM require BGMP. BGMP isn't going to go anywhere. -- Interdomain ASM requires MSDP (or BGMP). No one has figured out how to make MSDP work yet. It barely works "good enough". IMHO, it is one of the major stumbling blocks to multicast deployment. So, I'd like to encourage you to "move on". Your ASM pim is probably "good enough" now. If it isn't, well, you are implementing yesterday's technology. Its kind of like deciding that you need a really good X.25 implementation in your router now. (or ATM ;-) 2cents On Wednesday, May 21, 2003, at 12:49 AM, bharat_joshi wrote: > Hi, > > *,G state will be there when IGMP hosts have not been updated to IGMPv3 > and the desginated rotuers doesn't support IGMPv3. > > Lets say we have IGMPv2 on a LAN, the DR will always generate a *,G > join/prune for a IGMP join/leave message. > > S,G state will come in picture when DR start switch to SPT but in this > case you will need to maintain *,G and S,G both becuase the router will > never come to know that the hosts connected to LAN wants packet from > which all sources. > > If hosts are running IGMPV3 than a *,G entry may not be created. > > Thanks, > Bharat > > > > -----Original Message----- > From: Bandi, Sarveshwar [mailto:sarveshwarb@netplane.com] > Sent: Wed 5/21/2003 12:13 PM > To: 'Zhang Yanxing'; pim@catarina.usc.edu > Cc: > Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion > > One comment, I dont think the spec says explicitly that a (*,G) should > exist > when (S,G) exists. If someone were to have only SSM routes in a > network, > having (*,G) routes would not make any sense. I think creation of (*,G) > route when (S,G) routes are created is an implementation issue. We > have an > implementation where (*,G) routes created as and when needed. > > Would love to hear others comments on this > > Regards, > Sarvesh > > -----Original Message----- > From: Zhang Yanxing [mailto:yxzhang@utstar.com] > Sent: Wednesday, May 21, 2003 8:06 AM > To: pim@catarina.usc.edu > Subject: [pim] about the (*,G),(S,G) entry creation and deletion > > > I think it maybe one implementation problem, I want to speak out > my > thought to see if it is correct. > Multicast Route entry is created when some interfaces receive the > (*,G) or > (S,G) join message. > When all the joined before interfaces recieve prune message(after the > prune > override interval) or > the join timer expires, the entry will be deleted. This mechanism > shows the > difference between the DM and > SM. > But at the DR with the directly connected senders and the RP, I > think > the (S,G) entry creation is something > like the DM, it is built by the traffic driven. > Another point is that does the specification imply that if (S,G) > exist, > the (*,G) should exist too? > Welcome comments, Thanks. > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim > > > > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu May 22 14:54:11 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24632 for ; Thu, 22 May 2003 14:54:09 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4MIooX52089; Thu, 22 May 2003 11:50:50 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4MImdX52038 for ; Thu, 22 May 2003 11:48:39 -0700 (PDT) (envelope-from John.Zwiebel@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 5CF6A23C33; Thu, 22 May 2003 11:36:37 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4MImRYB011466; Thu, 22 May 2003 11:48:28 -0700 (PDT) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 11:48:27 -0700 Subject: Re: [pim] about the (*,G),(S,G) entry creation and deletion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: John Zwiebel , bharat_joshi , pim@catarina.usc.edu To: "Bandi, Sarveshwar" From: John Zwiebel In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 22 May 2003 18:48:27.0779 (UTC) FILETIME=[BB652D30:01C32092] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 May 2003 11:48:28 -0700 Content-Transfer-Encoding: 7bit On Thursday, May 22, 2003, at 08:12 AM, Bandi, Sarveshwar wrote: > > Assert mechanism is used to detect duplication of data on both the SPT > and > RPT as well. Even if you do (S,G) join you still can have duplication > of > data. And the assert operations would be equally costly both on the > RPT or > SPT. > If not for the assert mechanism, one would need to come up with some > way of > > solving (if possible) this problem. And probably that solution could be > applied to RPT as well. > I never meant to indicate any differently, nor do I think I said "don't implement an assert mechanism". I said it was very expensive to do in high-end routers. Where is it that most asserts happen? Two places: 1) on LANs that use non-congruent routing where downstream routers choose different upstream forwarders. Not much one can do about this, and yes the assert mechanism is required here. OTOH, one might suggest to network architects that this is not a "good thing" and it should be avoided so they don't have to worry about asserts. 2) when the SPT and the RPT cross on a LAN. I'd suggest that this situation is 90% of the asserts that happen in the "real world". And the situation is even worse than one might think because the spec also states that when a downstream router switches from the RPT to the SPT it is suppose to send a prune to the RPT. But, if there is more than one downstream router, they may not all switch to the SPT at the same time. The net result is a flurry of join-override messages followed by prune messages and then also asserts. Everything eventually gets fixed and it all works, but "is this any way to run a railroad"? The "assert problem" isn't just duplicate traffic, but also includes how to handle mpackets just seen on an interface. What about non-RPF traffic that the router is suppose to just ignore. How do you drop those packets fast enough? We're talking Gigabits worth of multicast traffic. Setting up the forwarding path in advance with SSM and bidir -- avoiding all the problems inherent in ASM, is an excellent start toward eliminating many of these problems. (OTOH, it may be like Ipsilon's TAG switching and technology may soon overcome this problem. But it hasn't happened yet, and I don't see it happening.) Now, rather than argue how best to implement ASM -- especially how IGMPv3 is suppose to interoperate with ASM, I'd rather have a discussion on what ASM buys you that SSM and bidir don't. I think the current PIM-SM draft does an excellent job of attempting to describe how the protocol should work. Yet, there continues to be numerous of comments on its deficiencies. And there continues to be problems with deployment of PIM in the internet. Doesn't this point to a systemic problem that needs to be solved? Doesn't this indicate that ASM is just "too hard"? Shouldn't we concentrate on simplifying multicast routing? I'd love to hear your experience in PIM deployment. Where is your implementation running? What are the results? Am I naive to think that there are only 3 router vendors? (I don't mean to insult anyone, but I am trying to bring some perspective to this -- Oh, and I confess that saying "3" is including Procket so I hope you are all getting a big laugh.) My desire is for interdomain multicast, that means the internet, that means large ISPs like ATT, Sprint, UUnet etc. Who do they get their routers from? Here's your opportunity to try to sell me (and perhaps others -- please don't think I'm trying to say anything like "if you don't sell me it ain't going no-where".) I want to know the -specific- customer requirement that says we have to have ASM. In all the mailing-lists I've been on, I've heard of only one. And that one seems to be more about the fact that the current application works "good enough" in the environment it is currently deployed in. I haven't heard a single customer or application developer say, "ASM is the only way I'll ever use multicast." Nor have I heard anyone say, "I will use IGMPv3 to deny specific sources while listening to the rest of the group." Yes, one -can- do that, but why? How does that encourage multicast content delivery from any source in the world to any receiver in the world. In other words, one sender to potentially millions of receivers. Let's consider how audio/video is delivered now over the internet. Its all unicast. Where's the incentive to go to multicast? So, please provide me with examples of how you expect to deploy multicast. How are you going to use it. Who is going to use it. What is the content. Who are the receivers. How do you envision the traffic getting across the internet. Without answers to these questions, it may be that multicast will be no more than a niche. And if that's the market you are going after, great. _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu May 22 16:12:55 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27857 for ; Thu, 22 May 2003 16:12:55 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4MK7DX53609; Thu, 22 May 2003 13:07:13 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4MK1PX53495 for ; Thu, 22 May 2003 13:01:25 -0700 (PDT) (envelope-from nickless@mcs.anl.gov) Received: from newtwinkle.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h4MK1Ct86526; Thu, 22 May 2003 15:01:12 -0500 Message-Id: <5.1.1.6.2.20030522140205.0286c018@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: John Zwiebel From: Bill Nickless Subject: [pim] ASM Applications [Was: about the (*,G),(S,G) entry creation and deletion] Cc: pim@catarina.usc.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 May 2003 15:01:08 -0500 -----BEGIN PGP SIGNED MESSAGE----- At 11:48 AM 5/22/2003 -0700, John Zwiebel wrote: >The "assert problem" isn't just duplicate traffic, but also includes how to >handle mpackets just seen on an interface. What about non-RPF traffic that >the router is suppose to just ignore. How do you drop those packets fast >enough? We're talking Gigabits worth of multicast traffic. You get the underlying Layer 2 infrastructure to not forward you traffic that doesn't belong to you. IEEE 802.1 bridges do that just fine, happily running at line rate with parallel 10 Gigabit Ethernet links. Oh sorry, I forgot. Except for IP multicast, because IP multicast packets are put into IEEE 802 frames with the MAC multicast bit set. I guess that engineering decision made in 1989 for Metcalfe-style single-wire Ethernets is good enough for today's IEEE 802 networks. >Setting up the forwarding path in advance with SSM and bidir -- avoiding >all the problems inherent in ASM, is an excellent start toward eliminating >many of these problems. How about these prophetic words from Deering & Cheriton in 1985 (RFC 966), referring to the decision to make Host Groups open? The sender need not be a member of the destination group. We refer to such a group as open, in contrast to a closed group where only members are allowed to send to the group. We chose to provide open groups because they are more flexible and more consistent as an extension of conventional unicast models (even though they may harder to implement). Yup, I agree. Allowing unknown senders to transmit to the destination group has turned out to be a little hard to implement in the Internet. I think we refer to this as the "bursty source" problem. SSM is a sneaky way to get around the Deering/Cheriton Host Group model definition, and the problem referenced in the above quote. The receiver-driven (S,G) joins explicitly define (to the network) the membership of the group--specifically, the identity of the only permitted source. In other words, SSM creates closed host groups, identified by (S,G), where S is the only permitted sender. >Now, rather than argue how best to implement ASM -- especially how IGMPv3 >is suppose to interoperate with ASM, I'd rather have a discussion on what >ASM buys you that SSM and bidir don't. Existence. Access Grid 2.0 Release Candidate 1 is now available. There are over 200 Access Grid nodes in the research and education community, worldwide. It's open source and free (as in beer). Go download it and try it on your Linux or Windows XP box for yourself: http://www-unix.mcs.anl.gov/fl/research/accessgrid/software/2.0-rc1/index.html Access Grid 2.0 already has a notion of "venues" and "venue servers" that keep track of all the participants in a collaboration. There's a whole Globus-based authentication environment with X.509 certificates and everything. So why doesn't AG 2.0 support SSM? Because SSM requires IGMPv3. IGMPv3 snooping puts *massive* requirements on a site's IEEE 802.1 bridges. MLD snooping is even worse. If I were an IEEE 802.1 bridge manufacturer, competing on price, I would be insane to implement a whole IPv4/IGMP stack (and later an IPv6/MLD stack) just to constrain IP multicast flooding. If I were in charge of an institutional network that still uses the same IEEE 802.1 bridges for IP traffic that used to be used for IPX and Apple Ethertalk, I would push back *VERY* hard when someone wanted me to forklift-upgrade all of my IEEE 802.1 bridges to support IGMP/MLD snooping. SSM is easy (trivial!) in today's IEEE 802.1-free IP network cores. SSM is horrifically hard in today's IEEE 802.1-based edge networks. Oh, and bidir? It's probably not possible to define a general bidir RP <--> group mapping in today's Internet. There are too many interconnected networks, and they simply don't follow any hierarchy that can do (for example) provider-based group address delegation. >I haven't heard a single customer or application developer say, "ASM is the >only way I'll ever use multicast." The people down the hall who develop the Access Grid software routinely say something very close to that: "ASM is the only multicast out there." Every six months or so they ask me about SSM, I explain what's out there, and they go back to programming to the ASM model. Or even worse, developing their own application-level overlay multicast forwarding infrastructure. (They want the network to trans-code high bandwidth video to something lower for sites that don't have fat pipes. I try to tell them that they should use different SSM group addresses at the source for differently-encoded video streams, but it's a tough argument to make in the context of how hard it is to do IGMPv3 end-to-end.) >So, please provide me with examples of how you expect to deploy multicast. >How are you going to use it. Who is going to use it. What is the content. >Who are the receivers. How do you envision the traffic getting across the >internet. Without answers to these questions, it may be that multicast will >be no more than a niche. And if that's the market you are going after, great. The first thing we have to do is make IP Multicast run on today's IEEE 802 networks as well as it did on 1989's 10Base5 networks. Not tomorrow's IEEE 802 networks with IGMP/MLD snooping, but today's IEEE 802 networks. The second thing we may have to do is figure out a business model for the service providers to reap some financial reward for managing the extra complexity and state of multicast forwarding. Perhaps this is related to the problem of big unicast routing tables that we hear so much about. Today's ISP business model is to charge for the bandwidth but give away the state management (routing table entries) for free. As any first year economics student will tell you, a commodity that incurs zero cost will be abused. (See a recent NANOG thread for more discussion on this.) === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQCVAwUBPs0sh6wgm7ipJDXBAQHZsQP8C2V76TXBLE6HQeAVP35G+6ufTH94+1jl hbROp6o5Xu+WHSKXS7WQzePBcEtG5M2cIP+vVKkEUGS/6NNlAfmlgLWlcHrPVlDq 8vUXjQjhRE43JgGHW+Vc3z5jQB04TJKvYqgPmVWY/hE4dktU/y4ORBCBltjOVIzH EK8Du0ArGAo= =tfUM -----END PGP SIGNATURE----- _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 28 04:03:39 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20351 for ; Wed, 28 May 2003 04:03:37 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4S7thX12164; Wed, 28 May 2003 00:55:43 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from rediffmail.com (webmail29.rediffmail.com [203.199.83.39] (may be forged)) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4S7pZX12076 for ; Wed, 28 May 2003 00:51:35 -0700 (PDT) (envelope-from multicast_pim@rediffmail.com) Received: (qmail 28993 invoked by uid 510); 28 May 2003 07:51:30 -0000 Message-ID: <20030528075130.28992.qmail@webmail29.rediffmail.com> Received: from unknown (61.107.96.100) by rediffmail.com via HTTP; 28 may 2003 07:51:29 -0000 MIME-Version: 1.0 From: "Ganapath" Reply-To: "Ganapath" To: pim@catarina.usc.edu Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [pim] Longest prefix match!!! Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: 28 May 2003 07:51:30 -0000 Hi, It's all related to longest(highest) prefix match. We would like to know if there is a difference between 224.0.0.0/4 and 224.0.0.0/16 when we have the group 224.0.0.1(just an example) When we consdier the prefix values given by these two group ranges it comes out to be, Group range Group addr Mask addr Prefix value 1. 224.0.0.0/4 => 224.0.0.0 AND 240.0.0.0 => 224 2. 224.0.0.0/16 => 224.0.0.0 AND 255.255.0.0 => 224 Which one should we choose when we have the group 224.0.0.1?? One point is, since both the prefixes are offering the scope for 4 and 8 bits, and we don't have bits set after 4 bits and before 8 bits in 224.0.0.1. So any prefix should be fine in this case. Of course things will be different when we have 224.1.0.0/16 and 224.0.0.0/4 and have to select one of these two prefixes for a group address 224.1.0.0. comments please, Regards, Ganapath Corecess Inc ___________________________________________________ Get email that means BUSINESS! me @ mycompany.com. Just Rs.1499/year. To start, click http://www.rediffmailpro.com _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 28 08:21:18 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27277 for ; Wed, 28 May 2003 08:21:17 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4SCI3X18113; Wed, 28 May 2003 05:18:03 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from bosvwl02.infosys.com (bosvwl02.infy.com [216.52.49.36]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4SCFTX18047 for ; Wed, 28 May 2003 05:15:29 -0700 (PDT) (envelope-from bharat_joshi@infosys.com) Received: from 192.168.200.83 by bosvwl02.infosys.com (InterScan E-Mail VirusWall NT); Wed, 28 May 2003 08:17:12 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS03.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 28 May 2003 17:44:46 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 28 May 2003 17:44:46 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [pim] Longest prefix match!!! Message-ID: <56E2573C375A414191118970BDE06A150ABE5F15@kecmsg06.ad.infosys.com> Thread-Topic: [pim] Longest prefix match!!! Thread-Index: AcMk9YZxjWZbpU/0SGWUzDyRs5G1SgAHLpfq From: "bharat_joshi" To: "Ganapath" , X-OriginalArrivalTime: 28 May 2003 12:14:46.0093 (UTC) FILETIME=[BA406FD0:01C32512] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4SCFTX18047 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 17:44:45 +0530 Content-Transfer-Encoding: 8bit Hi, I think a PIM-SM implementation must give warning when a admin configure the group-range with this kind of mask. AFAIK, 224.0.0.0/16 is not a valid combination so it should never be used. Thanks, Bharat -----Original Message----- From: Ganapath [mailto:multicast_pim@rediffmail.com] Sent: Wed 5/28/2003 1:21 PM To: pim@catarina.usc.edu Cc: Subject: [pim] Longest prefix match!!! Hi, It's all related to longest(highest) prefix match. We would like to know if there is a difference between 224.0.0.0/4 and 224.0.0.0/16 when we have the group 224.0.0.1(just an example) When we consdier the prefix values given by these two group ranges it comes out to be, Group range Group addr Mask addr Prefix value 1. 224.0.0.0/4 => 224.0.0.0 AND 240.0.0.0 => 224 2. 224.0.0.0/16 => 224.0.0.0 AND 255.255.0.0 => 224 Which one should we choose when we have the group 224.0.0.1?? One point is, since both the prefixes are offering the scope for 4 and 8 bits, and we don't have bits set after 4 bits and before 8 bits in 224.0.0.1. So any prefix should be fine in this case. Of course things will be different when we have 224.1.0.0/16 and 224.0.0.0/4 and have to select one of these two prefixes for a group address 224.1.0.0. comments please, Regards, Ganapath Corecess Inc ___________________________________________________ Get email that means BUSINESS! me @ mycompany.com. Just Rs.1499/year. To start, click http://www.rediffmailpro.com _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 28 10:39:43 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06534 for ; Wed, 28 May 2003 10:39:42 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4SEXDX20796; Wed, 28 May 2003 07:33:13 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4SEUXX20735 for ; Wed, 28 May 2003 07:30:33 -0700 (PDT) (envelope-from John.Zwiebel@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id AC92A23C4E; Wed, 28 May 2003 07:18:24 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h4SEURYB027202; Wed, 28 May 2003 07:30:27 -0700 (PDT) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 28 May 2003 07:30:27 -0700 Subject: Re: [pim] Longest prefix match!!! Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: pim@catarina.usc.edu To: "Ganapath" From: John Zwiebel In-Reply-To: <20030528075130.28992.qmail@webmail29.rediffmail.com> Message-Id: <9FFA47EC-9118-11D7-8062-0003936A6062@procket.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 28 May 2003 14:30:27.0747 (UTC) FILETIME=[AF0E3F30:01C32525] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 07:28:17 -0700 Content-Transfer-Encoding: 7bit FWIW, you should probably match on 224.0.0.0/24 since this is reserved for link-local addresses. On Wednesday, May 28, 2003, at 12:51 AM, Ganapath wrote: > Hi, > > It's all related to longest(highest) prefix match. We would like to > know if there is a difference between 224.0.0.0/4 and 224.0.0.0/16 > when we have the group 224.0.0.1(just an example) > > When we consdier the prefix values given by these two group ranges > it comes out to be, > > Group range Group addr Mask addr Prefix value > 1. 224.0.0.0/4 => 224.0.0.0 AND 240.0.0.0 => 224 > 2. 224.0.0.0/16 => 224.0.0.0 AND 255.255.0.0 => 224 > > Which one should we choose when we have the group 224.0.0.1?? > One point is, since both the prefixes are offering the scope for 4 and > 8 bits, and we don't have bits set after 4 bits and before 8 bits in > 224.0.0.1. > > So any prefix should be fine in this case. > > Of course things will be different when we have 224.1.0.0/16 and > 224.0.0.0/4 and have to select one of these two prefixes for a group > address 224.1.0.0. > > comments please, > > Regards, > Ganapath > Corecess Inc > > > ___________________________________________________ > Get email that means BUSINESS! me @ mycompany.com. > Just Rs.1499/year. > To start, click http://www.rediffmailpro.com > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 28 12:05:22 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10158 for ; Wed, 28 May 2003 12:05:21 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4SG1xX22722; Wed, 28 May 2003 09:01:59 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from web8203.mail.in.yahoo.com (web8203.mail.in.yahoo.com [203.199.70.117]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4SFxeX22661 for ; Wed, 28 May 2003 08:59:40 -0700 (PDT) (envelope-from jaganbabu_pim@yahoo.co.in) Message-ID: <20030528155933.83947.qmail@web8203.mail.in.yahoo.com> Received: from [136.182.2.221] by web8203.mail.in.yahoo.com via HTTP; Wed, 28 May 2003 16:59:33 BST From: =?iso-8859-1?q?Rajamanickam=20jaganbabu?= Subject: RE: [pim] Longest prefix match!!! To: bharat_joshi , Ganapath , pim@catarina.usc.edu In-Reply-To: <56E2573C375A414191118970BDE06A150ABE5F15@kecmsg06.ad.infosys.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-29504891-1054137573=:81790" Content-Transfer-Encoding: 8bit Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 16:59:33 +0100 (BST) --0-29504891-1054137573=:81790 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, We can have both 224.0.0.0/4 and 224.0.0.0/16 in the group-range table, both are very valid combination. It is the best to chose the longest prefix match (i.e) 224.0.0.0/16. For Example, If you have both both the routes in your group-range table and if you are receiving a group address 224.0.12.2, then according to the match prefix we should be getting 224.0.0./16 as a output. At the same time if we get 224.1.12.2, then the best match would be 224.0.0.0/4, so both the above routes mentioned are very valid route entries. Thanx, Jags bharat_joshi wrote: Hi, I think a PIM-SM implementation must give warning when a admin configure the group-range with this kind of mask. AFAIK, 224.0.0.0/16 is not a valid combination so it should never be used. Thanks, Bharat -----Original Message----- From: Ganapath [mailto:multicast_pim@rediffmail.com] Sent: Wed 5/28/2003 1:21 PM To: pim@catarina.usc.edu Cc: Subject: [pim] Longest prefix match!!! Hi, It's all related to longest(highest) prefix match. We would like to know if there is a difference between 224.0.0.0/4 and 224.0.0.0/16 when we have the group 224.0.0.1(just an example) When we consdier the prefix values given by these two group ranges it comes out to be, Group range Group addr Mask addr Prefix value 1. 224.0.0.0/4 => 224.0.0.0 AND 240.0.0.0 => 224 2. 224.0.0.0/16 => 224.0.0.0 AND 255.255.0.0 => 224 Which one should we choose when we have the group 224.0.0.1?? One point is, since both the prefixes are offering the scope for 4 and 8 bits, and we don't have bits set after 4 bits and before 8 bits in 224.0.0.1. So any prefix should be fine in this case. Of course things will be different when we have 224.1.0.0/16 and 224.0.0.0/4 and have to select one of these two prefixes for a group address 224.1.0.0. comments please, Regards, Ganapath Corecess Inc ___________________________________________________ Get email that means BUSINESS! me @ mycompany.com. Just Rs.1499/year. To start, click http://www.rediffmailpro.com _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim Catch all the cricket action. Download Yahoo! Score tracker --0-29504891-1054137573=:81790 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi,
   We can have both 224.0.0.0/4 and 224.0.0.0/16 in the group-range table, both are very valid combination. It is the best to chose the longest prefix match (i.e) 224.0.0.0/16.
  
For Example,
       If you have both both the routes in your group-range table and if you are receiving a group address 224.0.12.2, then according to the match prefix we should be getting 224.0.0./16 as a output. At the same time if we get 224.1.12.2, then the best match would be 224.0.0.0/4, so both the above routes mentioned are very valid route entries.
 
Thanx,
Jags


bharat_joshi <bharat_joshi@infosys.com> wrote:
Hi,

I think a PIM-SM implementation must give warning
when a admin configure the group-range with this
kind of mask.

AFAIK, 224.0.0.0/16 is not a valid combination so
it should never be used.


Thanks,
Bharat


-----Original Message-----
From: Ganapath [mailto:multicast_pim@rediffmail.com]
Sent: Wed 5/28/2003 1:21 PM
To: pim@catarina.usc.edu
Cc:
Subject: [pim] Longest prefix match!!!

Hi,

It's all related to longest(highest) prefix match. We would like
to know if there is a difference between 224.0.0.0/4 and
224.0.0.0/16 when we have the group 224.0.0.1(just an example)

When we consdier the prefix values given by these two group
ranges
it comes out to be,

Group range Group addr Mask addr Prefix
value
1. 224.0.0.0/4 => 224.0.0.0 AND 240.0.0.0 => 224
2. 224.0.0.0/16 => 22! 4.0.0.0 AND 255.255.0.0 => 224

Which one should we choose when we have the group 224.0.0.1??
One point is, since both the prefixes are offering the scope for 4
and 8 bits, and we don't have bits set after 4 bits and before 8
bits in 224.0.0.1.

So any prefix should be fine in this case.

Of course things will be different when we have 224.1.0.0/16 and
224.0.0.0/4 and have to select one of these two prefixes for a
group address 224.1.0.0.

comments please,

Regards,
Ganapath
Corecess Inc


___________________________________________________
Get email that means BUSINESS! me @ mycompany.com.
Just Rs.1499/year.
To start, click http://www.rediffmailpro.com

_______________________________________________
pim mailing list
pim@catarina.usc.edu
http://catarina.usc.edu/mailman/listinfo/pim



_______________________________________________
pim mailing list
pim@catarina.usc.! edu
http://catarina.usc.edu/mailman/listinfo/pim

Catch all the cricket action. Download Yahoo! Score tracker --0-29504891-1054137573=:81790-- _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 28 12:12:36 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10484 for ; Wed, 28 May 2003 12:12:36 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4SG7KX22879; Wed, 28 May 2003 09:07:20 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from bosvwl02.infosys.com (bosvwl02.infy.com [216.52.49.36]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4SG5fX22828 for ; Wed, 28 May 2003 09:05:42 -0700 (PDT) (envelope-from bharat_joshi@infosys.com) Received: from 192.168.200.83 by bosvwl02.infosys.com (InterScan E-Mail VirusWall NT); Wed, 28 May 2003 12:07:27 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS03.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 28 May 2003 21:35:30 +0530 Received: from kecmsg06.ad.infosys.com ([192.168.200.75]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 28 May 2003 21:35:30 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [pim] Longest prefix match!!! Message-ID: <56E2573C375A414191118970BDE06A150ABE5F16@kecmsg06.ad.infosys.com> Thread-Topic: [pim] Longest prefix match!!! Thread-Index: AcMlMlYMGdv3TvrDQYOvUV8xvffnBgAAGibC From: "bharat_joshi" To: "Rajamanickam jaganbabu" , Cc: X-OriginalArrivalTime: 28 May 2003 16:05:30.0187 (UTC) FILETIME=[F5F989B0:01C32532] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id h4SG5fX22828 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 21:35:29 +0530 Content-Transfer-Encoding: 8bit Hi, I am sorry that I made a wrong assumption before replying. Yeah!!! both are very valid configuration and it will always look for longest match. Thanks, Bharat -----Original Message----- From: Rajamanickam jaganbabu [mailto:jaganbabu_pim@yahoo.co.in] Sent: Wed 5/28/2003 9:29 PM To: bharat_joshi; Ganapath; pim@catarina.usc.edu Cc: Subject: RE: [pim] Longest prefix match!!! Hi, We can have both 224.0.0.0/4 and 224.0.0.0/16 in the group-range table, both are very valid combination. It is the best to chose the longest prefix match (i.e) 224.0.0.0/16. For Example, If you have both both the routes in your group-range table and if you are receiving a group address 224.0.12.2, then according to the match prefix we should be getting 224.0.0./16 as a output. At the same time if we get 224.1.12.2, then the best match would be 224.0.0.0/4, so both the above routes mentioned are very valid route entries. Thanx, Jags bharat_joshi wrote: Hi, I think a PIM-SM implementation must give warning when a admin configure the group-range with this kind of mask. AFAIK, 224.0.0.0/16 is not a valid combination so it should never be used. Thanks, Bharat -----Original Message----- From: Ganapath [mailto:multicast_pim@rediffmail.com] Sent: Wed 5/28/2003 1:21 PM To: pim@catarina.usc.edu Cc: Subject: [pim] Longest prefix match!!! Hi, It's all related to longest(highest) prefix match. We would like to know if there is a difference between 224.0.0.0/4 and 224.0.0.0/16 when we have the group 224.0.0.1(just an example) When we consdier the prefix values given by these two group ranges it comes out to be, Group range Group addr Mask addr Prefix value 1. 224.0.0.0/4 => 224.0.0.0 AND 240.0.0.0 => 224 2. 224.0.0.0/16 => 224.0.0.0 AND 255.255.0.0 => 224 Which one should we choose when we have the group 224.0.0.1?? One point is, since both the prefixes are offering the scope for 4 and 8 bits, and we don't have bits set after 4 bits and before 8 bits in 224.0.0.1. So any prefix should be fine in this case. Of course things will be different when we have 224.1.0.0/16 and 224.0.0.0/4 and have to select one of these two prefixes for a group address 224.1.0.0. comments please, Regards, Ganapath Corecess Inc ___________________________________________________ Get email that means BUSINESS! me @ mycompany.com. Just Rs.1499/year. To start, click http://www.rediffmailpro.com _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim Catch all the cricket action. Download Yahoo! Score tracker _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed May 28 18:13:25 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27148 for ; Wed, 28 May 2003 18:13:25 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4SM7EX29912; Wed, 28 May 2003 15:07:14 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from web80108.mail.yahoo.com (web80108.mail.yahoo.com [66.163.169.81]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4SM4CX29821 for ; Wed, 28 May 2003 15:04:13 -0700 (PDT) (envelope-from mreddy@pacbell.net) Message-ID: <20030528220412.43843.qmail@web80108.mail.yahoo.com> Received: from [64.47.48.10] by web80108.mail.yahoo.com via HTTP; Wed, 28 May 2003 15:04:12 PDT From: Madhu Reddy To: pim@catarina.usc.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [pim] Query regarding Upstream (*,G) state machine Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 May 2003 15:04:12 -0700 (PDT) In Joined State, there are two events specified in the table : "RPF'(*,G) changes" and "RPF'(*,G) changes due to Assert". What is the difference between the two? In the description, there is description only for one of these events and the description for event "RPF'(*,G) changes" actually matches that of the event "RPF'(*,G) changes due to Assert". Any help is appreciated. Thanks. Madhu _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Fri May 30 11:32:45 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13330 for ; Fri, 30 May 2003 11:32:44 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4UFT4X71113; Fri, 30 May 2003 08:29:04 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from web80106.mail.yahoo.com (web80106.mail.yahoo.com [66.163.169.79]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id h4UFODX71033 for ; Fri, 30 May 2003 08:24:13 -0700 (PDT) (envelope-from mreddy@pacbell.net) Message-ID: <20030530152412.8818.qmail@web80106.mail.yahoo.com> Received: from [64.160.53.247] by web80106.mail.yahoo.com via HTTP; Fri, 30 May 2003 08:24:12 PDT From: Madhu Reddy Subject: Fwd: [pim] Query regarding Upstream (*,G) state machine To: pim@catarina.usc.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 May 2003 08:24:12 -0700 (PDT) Trying again as I did not get an answer. Thanks. Madhu > > In Joined State, there are two events specified in > the > table : "RPF'(*,G) changes" and "RPF'(*,G) changes > due > to Assert". What is the difference between the two? > In the description, there is description only for > one > of these events and the description for event > "RPF'(*,G) changes" actually matches that of the > event > > "RPF'(*,G) changes due to Assert". Any help is > appreciated. Thanks. > > Madhu > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Fri May 30 15:00:17 2003 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21786 for ; Fri, 30 May 2003 15:00:15 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4UIurX74513; Fri, 30 May 2003 11:56:53 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from possum.icir.org (possum.icir.org [192.150.187.67]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id h4UIsnX74471 for ; Fri, 30 May 2003 11:54:49 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.8p1/8.12.3) with ESMTP id h4UIsniS002957; Fri, 30 May 2003 11:54:49 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200305301854.h4UIsniS002957@possum.icir.org> To: Madhu Reddy cc: pim@catarina.usc.edu Subject: Re: Fwd: [pim] Query regarding Upstream (*,G) state machine In-Reply-To: Message from Madhu Reddy of "Fri, 30 May 2003 08:24:12 PDT." <20030530152412.8818.qmail@web80106.mail.yahoo.com> From: Pavlin Radoslavov Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 May 2003 11:54:49 -0700 > Trying again as I did not get an answer. Thanks. I think that the I-D needs to be corrected here (actually, someting ago I had already marked my copy of the draft re. exactly same thing, which I should bring to the attention of one of the authors sometime very soon :) I believe the correction should be like: * Remove "RPF'(*,G) changes due to Assert" from the table * Replace "RPF'(*,G) changes" with something like "RPF'(*,G)) changes for a reason other than MRIB.next_hop(RP(G)) changes". * Do the same replacing as above in the paragraph that later describes this action (page 49 in the 07 PS version). * Remove "due to an Assert(*,G)( on the RPF_interface(RP(G))." from the first sentence in the above paragraph and replace it with something similar as above. Regards, Pavlin > > Madhu > > > > > In Joined State, there are two events specified in > > the > > table : "RPF'(*,G) changes" and "RPF'(*,G) changes > > due > > to Assert". What is the difference between the two? > > In the description, there is description only for > > one > > of these events and the description for event > > "RPF'(*,G) changes" actually matches that of the > > event > > > > "RPF'(*,G) changes due to Assert". Any help is > > appreciated. Thanks. > > > > Madhu > > _______________________________________________ > > pim mailing list > > pim@catarina.usc.edu > > http://catarina.usc.edu/mailman/listinfo/pim > > _______________________________________________ > pim mailing list > pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim