From mailman-bounces@ietf.org Thu Jul 1 06:50:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13719 for ; Thu, 1 Jul 2004 06:50:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfxek-00019z-92 for pim-archive@lists.ietf.org; Thu, 01 Jul 2004 05:14:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: pim-archive@ietf.org X-No-Archive: yes Message-ID: Date: Thu, 01 Jul 2004 05:03:27 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org 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, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for pim-archive@lists.ietf.org: List Password // URL ---- -------- pim@ietf.org urahne https://www1.ietf.org/mailman/options/pim/pim-archive%40lists.ietf.org From pim-bounces@ietf.org Fri Jul 2 11:35:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13432 for ; Fri, 2 Jul 2004 11:35:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPl7-0004oY-CM; Fri, 02 Jul 2004 11:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPPy-0004UV-QT for pim@megatron.ietf.org; Fri, 02 Jul 2004 10:53:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10200 for ; Fri, 2 Jul 2004 10:53:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgPPx-0005Va-W5 for pim@ietf.org; Fri, 02 Jul 2004 10:53:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPOv-0005B7-00 for pim@ietf.org; Fri, 02 Jul 2004 10:52:30 -0400 Received: from [203.197.138.222] (helo=mail1.future.futsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BgPO0-0004XT-00 for pim@ietf.org; Fri, 02 Jul 2004 10:51:33 -0400 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail1.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Fri, 2 Jul 2004 20:19:57 +0530 Received: from girishkg (girishkg.future.futsoft.com [10.6.4.88]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i62EoKZ24947 for ; Fri, 2 Jul 2004 20:20:20 +0530 From: "girishkg" To: Date: Fri, 2 Jul 2004 20:21:27 +0530 Message-ID: <00a901c46044$0e704d60$5804060a@future.futsoft.com> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200406180543.i5I5hf5q011254@dino-pc.procket.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [pim] Doubt reg. BSR X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: girishkg@future.futsoft.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, I have few queries reg. BSR draft-03 - 1. According to BSR draft, at start-up, the BS Timer is initialised to BS Timeout value (~130sec). Is there any specific reason for choosing this large value. I feel this value can be reduced to a small value. 2. In the BSR draft, it is not mentioned that Unicast non-preferred BSM should be accepted by a Candidate-BSR in the P-BSR state, if no previous BSM has been received for a particular scope zone. This will help in learning RP-SET. Please let me know if i am missing something or this has been already discussed in the mailing list. Regards, Girish *************************************************************************** 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. *************************************************************************** _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jul 5 08:10:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22706 for ; Mon, 5 Jul 2004 08:10:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhRzu-0004eI-Ev; Mon, 05 Jul 2004 07:50:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhRsx-0004BD-V9 for pim@megatron.ietf.org; Mon, 05 Jul 2004 07:43:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21961 for ; Mon, 5 Jul 2004 07:43:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhRss-0007jb-Ew for pim@ietf.org; Mon, 05 Jul 2004 07:43:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhRsB-0007RH-00 for pim@ietf.org; Mon, 05 Jul 2004 07:42:59 -0400 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1BhRrD-00074x-00 for pim@ietf.org; Mon, 05 Jul 2004 07:41:59 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i65BbfDW004289; Mon, 5 Jul 2004 13:37:42 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i65BbeVN005412; Mon, 5 Jul 2004 13:37:40 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 5 Jul 2004 13:37:40 +0200 From: Stig Venaas To: girishkg Subject: Re: [pim] Doubt reg. BSR Message-ID: <20040705113740.GA5380@sverresborg.uninett.no> References: <200406180543.i5I5hf5q011254@dino-pc.procket.com> <00a901c46044$0e704d60$5804060a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a901c46044$0e704d60$5804060a@future.futsoft.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Hi On Fri, Jul 02, 2004 at 08:21:27PM +0530, girishkg wrote: > Hello, > > I have few queries reg. BSR draft-03 - > > 1. According to BSR draft, at start-up, the BS Timer is initialised to BS > Timeout value (~130sec). Is there any specific reason for choosing this > large value. I feel this value can be reduced to a small value. I don't know the history behind this. I believe it's good to wait for existing BSR information first, so that it can compare with its own priority. Which means at least a bit longer than 60s (the default BS period). When a router is booted the routing might also be a bit unstable (e.g. new routes being learnt, routing tables updated etc). Thus it might be possible that a BSM is lost, e.g. RPF check fails. If this is a likely problem it might be good to wait a bit longer than 120s (2 * BS period). It's also convenient perhaps to reuse the BS timeout value. Do you believe it's a problem that it takes 130s from the first c-BSR is booted/configured until it starts? If there already is an elected BSR, then I see no problem with it. I suppose someone that knows the background might be able to give you a better answer. > 2. In the BSR draft, it is not mentioned that Unicast non-preferred BSM > should be accepted by a Candidate-BSR in the P-BSR state, if no previous BSM > has been received for a particular scope zone. This will help in learning > RP-SET. I'm not sure I understand. Are you suggesting that a pending BSR could learn the RP-set this way rather than waiting for C-RP advs? It's a possible optimization, but at least in my mind, it breaks the model a bit. We plan to add text saying that an empty BSM must not delete the current RP-set. A new BSR would first send an empty BSM, and by the time it sends the next BSM, it has hopefully received C-RP advs from all the C-RPs. Currently the default periods for BSMs and C-RP advs are both 60s. So it might be possible to send two BSMs and just missing an C-RP adv. I see two possible solutions to that. One is making the C-RP adv period shorter. The other would be to have C-RPs send C-RP adv immediately (or with small random delay) when a new BSR is elected. With the changes above the new BSR should have complete RP information by the time it sends the second BSM, and the routers shouldn't lose any RP information during the switchover. > Please let me know if i am missing something or this has been already > discussed in the mailing list. These are just my opinions. Stig _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jul 9 16:55:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29586 for ; Fri, 9 Jul 2004 16:55:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj1h8-0002HQ-RG; Fri, 09 Jul 2004 16:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj0Oe-0002og-2W for pim@megatron.ietf.org; Fri, 09 Jul 2004 14:46:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19096 for ; Fri, 9 Jul 2004 14:46:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj0OX-0002Oi-RU for pim@ietf.org; Fri, 09 Jul 2004 14:46:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj0NW-000235-00 for pim@ietf.org; Fri, 09 Jul 2004 14:45:46 -0400 Received: from web12906.mail.yahoo.com ([216.136.174.73]) by ietf-mx with smtp (Exim 4.12) id 1Bj0MT-0001hU-00 for pim@ietf.org; Fri, 09 Jul 2004 14:44:41 -0400 Message-ID: <20040709184441.55016.qmail@web12906.mail.yahoo.com> Received: from [64.47.48.10] by web12906.mail.yahoo.com via HTTP; Fri, 09 Jul 2004 11:44:41 PDT Date: Fri, 9 Jul 2004 11:44:41 -0700 (PDT) From: Venugopal Hemige To: pim@ietf.org MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,HTML_MESSAGE,SUB_HELLO autolearn=no version=2.60 Subject: [pim] Hello HoldTime and Assert questions X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1595501735==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --===============1595501735== Content-Type: multipart/alternative; boundary="0-1136661132-1089398681=:55004" --0-1136661132-1089398681=:55004 Content-Type: text/plain; charset=us-ascii I have noticed a couple of issues with the spec and need some clarification: 1. Hello HoldTime: In section 4.3.2, neighbor.timeout is defined to be Hello_HoldTime whenever it is present in the received hello, or Default_Hello_Holdtime if the Hello message does not contain the Holdtime option. In section 4.10.2 (last para of this section), it says that "Holdtime option MUST be implemented". It is a bit confusing to interpret from this what the receiving router should do. Section 4.10.2 leads me to believe that the receiving router should not form an adjacency if the option is not present. Section 4.3.2 says the opposite. What is the expected behavior here? 2. Assert cancel received on RPF-interface. If there were an assert situation on the RPF-interface, the interface will be in assert-loser state. Could-Assert would be FALSE on the RPF-interface. So our interface metric to the source will be infinite-metric. If an assert cancel is received from the assert-winner, per the current definition of inferior/preferred/acceptable metrics, it will be treated as an acceptable metric. So the RPF-interface would remain in assert-loser state and retain the wrong upstream neighbor as RPF-neighbor, while infact it should have transitioned to assert-no-info. I think "inferior metric" should be defined to as a metric lower than my metric OR infinite-metric. That should take care of it. Comments? Regards, -Venu --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! --0-1136661132-1089398681=:55004 Content-Type: text/html; charset=us-ascii
 
I have noticed a couple of issues with the spec and need some clarification:
 
1. Hello HoldTime:
 
In section 4.3.2, neighbor.timeout is defined to be Hello_HoldTime whenever it is present in the received hello, or Default_Hello_Holdtime if the Hello message does not contain the Holdtime option.
 
In section 4.10.2 (last para of this section), it says that "Holdtime option MUST be implemented".
 
It is a bit confusing to interpret from this what the receiving router should do. Section 4.10.2 leads me to believe that the receiving router should not form an adjacency if the option is not present. Section 4.3.2 says the opposite. What is the expected behavior here?
 
2. Assert cancel received on RPF-interface.
 
If there were an assert situation on the RPF-interface, the interface will be in assert-loser state. Could-Assert would be FALSE on the RPF-interface. So our interface metric to the source will be infinite-metric. If an assert cancel is received from the assert-winner, per the current definition of inferior/preferred/acceptable metrics, it will be treated as an acceptable metric. So the RPF-interface would remain in assert-loser state and retain the wrong upstream neighbor as RPF-neighbor, while infact it should have transitioned to assert-no-info.
 
I think "inferior metric" should be defined to as a metric lower than my metric OR infinite-metric. That should take care of it. Comments?
 
Regards,
-Venu

Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages! --0-1136661132-1089398681=:55004-- --===============1595501735== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============1595501735==-- From pim-bounces@ietf.org Fri Jul 16 01:59:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22682 for ; Fri, 16 Jul 2004 01:59:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlLfL-0003v8-BM; Fri, 16 Jul 2004 01:53:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlLdP-0003is-Ey for pim@megatron.ietf.org; Fri, 16 Jul 2004 01:51:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22429 for ; Fri, 16 Jul 2004 01:51:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlLdM-0005to-RP for pim@ietf.org; Fri, 16 Jul 2004 01:51:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlLcb-0005Zs-00 for pim@ietf.org; Fri, 16 Jul 2004 01:51:02 -0400 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BlLbu-0004rf-00 for pim@ietf.org; Fri, 16 Jul 2004 01:50:19 -0400 Received: from huawei.com (huawei.com [172.17.1.61]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I0X0038UK8H2H@mta2.huawei.com> for pim@ietf.org; Fri, 16 Jul 2004 13:50:42 +0800 (CST) Received: from huawei.com ([172.17.1.58]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I0X00AN2K8HJ8@mta2.huawei.com> for pim@ietf.org; Fri, 16 Jul 2004 13:50:41 +0800 (CST) Received: from [10.18.1.7] by maila.huawei.com (mshttpd); Thu, 15 Jul 2004 22:43:34 -0700 Date: Thu, 15 Jul 2004 22:43:34 -0700 From: PrashantJhingran 70625 To: pim@ietf.org Message-id: <5258851a0f.51a0f52588@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.7 (built Jun 26 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-imss-version: 2.5 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Cc: prashantj@huawei.com Subject: [pim] Ambiguity in BSR 03 draft. X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi All, The BSR draft, 03 version contains the following ambiguity: Section 3 [page 17] of the draft says the following about the BSMs: --BSMs are forwarded out of all the interfaces with PIM-SM neighbors(INCLUDING the interface it is received on) This section also gives an example in which resending of the BSMs from the receiving interface would be beneficial/required. While, Section 3.3 "Forwarding Bootstrap Messages" of the draft says the following about the BSMs: -- Forward BSMs out of everymulticast capable interfaces which are PIM-SM neibors (EXCLUDING the one over which the message was received). I guess, the authours are trying to push the contents of section 3 [page17] and hence the section 3.3 requires correction. regards, Prashant _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jul 16 02:23:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07502 for ; Fri, 16 Jul 2004 02:23:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlM46-0004um-HQ; Fri, 16 Jul 2004 02:19:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlLyZ-0002dG-Pg for pim@megatron.ietf.org; Fri, 16 Jul 2004 02:13:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03840 for ; Fri, 16 Jul 2004 02:13:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlLyX-0005EW-5n for pim@ietf.org; Fri, 16 Jul 2004 02:13:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlLxZ-0004ty-00 for pim@ietf.org; Fri, 16 Jul 2004 02:12:42 -0400 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1BlLwR-0004HA-00 for pim@ietf.org; Fri, 16 Jul 2004 02:11:31 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i6G6AQDW009342; Fri, 16 Jul 2004 08:10:26 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i6G6AJY8010798; Fri, 16 Jul 2004 08:10:19 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 16 Jul 2004 08:10:19 +0200 From: Stig Venaas To: PrashantJhingran 70625 Subject: Re: [pim] Ambiguity in BSR 03 draft. Message-ID: <20040716061019.GA10786@sverresborg.uninett.no> References: <5258851a0f.51a0f52588@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5258851a0f.51a0f52588@huawei.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org On Thu, Jul 15, 2004 at 10:43:34PM -0700, PrashantJhingran 70625 wrote: > Hi All, > > The BSR draft, 03 version contains the following ambiguity: > > Section 3 [page 17] of the draft says the following about the BSMs: > > --BSMs are forwarded out of all the interfaces with PIM-SM neighbors(INCLUDING the interface it is received on) > This section also gives an example in which resending of the BSMs from the receiving interface would be beneficial/required. > > While, > > Section 3.3 "Forwarding Bootstrap Messages" of the draft says the following about the BSMs: > > -- Forward BSMs out of everymulticast capable interfaces which are PIM-SM neibors (EXCLUDING the one over which the message was received). > > > I guess, the authours are trying to push the contents of section 3 [page17] and hence the section 3.3 requires correction. Yes, this is fixed in the soon to appear version 4. Thanks, Stig _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jul 19 02:12:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14369 for ; Mon, 19 Jul 2004 02:12:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmRLe-00022C-Ao; Mon, 19 Jul 2004 02:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmRHW-0000RG-Ob for pim@megatron.ietf.org; Mon, 19 Jul 2004 02:05:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07537 for ; Mon, 19 Jul 2004 02:05:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmRHU-0007UA-Le for pim@ietf.org; Mon, 19 Jul 2004 02:05:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmRGY-0007H5-00 for pim@ietf.org; Mon, 19 Jul 2004 02:04:47 -0400 Received: from [12.106.35.5] (helo=mango.attlabs.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BmRFt-0006rj-00 for pim@ietf.org; Mon, 19 Jul 2004 02:04:05 -0400 Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id i6J63ICl014072 for ; Sun, 18 Jul 2004 23:03:18 -0700 (PDT) (envelope-from fenner@mango.attlabs.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id i6J63ITV014070 for pim@ietf.org; Sun, 18 Jul 2004 23:03:18 -0700 (PDT) (envelope-from fenner) Date: Sun, 18 Jul 2004 23:03:18 -0700 (PDT) From: Bill Fenner Message-Id: <200407190603.i6J63ITV014070@mango.attlabs.att.com> To: pim@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [pim] Changes from -09 to -10 in PIM-SM spec X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Folks, Here is the list of changes to the PIM spec between -09 and -10. These were mostly made in response to messages on the mailing list and in response to Last Call comments. There are change bars in both the text and postscript versions (the postscript ones are more accurate). I think there are still some security-related issues pending; Hugh said that he would follow up on the list. Bill Definitions: - Slight clarification of DR description Protocol Overview: - Mention that shared tree might have undesirable latency as well as undesirable bandwidth overhead - Clarify that the point-to-point links being covered are transit links. - Add automatic (e.g., embedded-RP) discovery to how routers learn address of RP. Protocol Specification: - Moved PMBR description to Appendix. General Purpose State: - Modified "Gen ID" to "GenID" (*,G) State: - Added AssertWinner and AssertWinnerMetric to descriptions (S,G) State: - Added AssertWinner and AssertWinnerMetric to descriptions - Changed "SPT bit" to "SPTbit" - Added PMBR state at RP State Summarization Macros: - Remove "link-local" from definition of primary IP address definition - Typo fix: "start machine" -> "state machine" Data Packet Forwarding Rules: - Changed "SPT bit" to "SPTbit" - Added "and iif == RPF_interface(S)" to conditional in "On receipt of data from S to G on interface iif" pseudocode Last-hop switchover to the SPT: - Added a note that starting the KAT accomplishes the switch Setting and Clearing the (S,G) SPTbit: - Add "I_Am_Assert_Loser(S,G,iif)" to the conditional for setting the SPTbit to prevent black holes (from James Lingard and others) - Changed "SPT bit" to "SPTbit" Designated Routers (DR) and Hello Messages: - Clarified that DR functionality happens on every link Sending Hello Messages: - Turned "PIM-Hello" into "PIM Hello" Reducing Prune Propagation Delay: - Renamed "LAN delay" to "Propagation Delay" - Renamed "Propagation_Delay" to "Effective_Propagation_Delay" - Allowed Effective_Propagation_Delay to use this router's value of Propagation_Delay(I) - Renamed "Override Delay" to "Override Interval" - Renamed "Override_Interval" to "Effective_Override_Interval" - Allowed Effective_Override_Interval to use this router's value of Override_Interval(I) Sending Register Messages from the DR: - Changed "Path-MTU" to "Path MTU" - Clarified that the header sizes should be considered when fragmenting - Use the ICMPv6 "Packet too Big" term instead of the v4 "Fragmentation Required" - Clarified that the TTL is decremented before entering the register tunnel when forwarding. Receiving Register Messages at the RP: - Clarify that a packet not actually sent to one of my addresses may be a spoofing attempt so should be dropped. - Added PMBR functionality - Fixed swapped timer values when sentRegisterStop == TRUE - Clarified the decapsulate and forward with a note - Clarified that the TTL is decremented when leaving the register tunnel when forwarding. Receiving (*,*,RP), (*,G) and (S,G) Join/Prune Messages: - State machine: don't cancel Prune-Pending timer when entering a state in which it's insignificant - Clarify that accepting a zero source address on a p2p link is for backwards compatibility Receiving (S,G,rpt) Join/Prune Messages: - Replaced "n/a" and "error" entries from state machine tables with "-" like other state machines. Sending (*,G)/(S,G) Join/Prune Messages: - Clarify that an interface entering or leaving immediate_olist is not the only reason that JoinDesired(*,G)/(S,G) may change values. PIM Assert Messages: - Spell out AH for IPsec - "Receive Preferred Assert with RPTbit clear and AssTrDes (S,G,I)" becomes "Receive Acceptable Assert ..." (S,G) Assert Message State Machine: - Only set the SPTbit if UpstreamJPState(S,G) is true to prevent black holes (from James Lingard and others). (*,G) Assert Message State Machine: - Clarify that when there is no source address in an Assert, there is no (S,G) Assert State Machine - "Receive Preferred Assert with RPTbit set and AssTrDes (*,G,I)" becomes "Receive Acceptable Assert ..." AssertCancel Messages: - AssertCancel(*,G) gets a source of zero, not RP(G) Assert State Macros: - Changed "SPT bit" to "SPTbit" PIM Multicast Border Router Behavior: - Moved to Appendix A PIM Bootstrap and RP Discovery: - Don't say that PMBRs are always the border, since that's not how things ended up getting deployed. - Define Embedded-RP - Don't MUST that RP addresses be reachable, since that's an operational concern, the protocol/implementation can't verify it. Source-Specific Multicast: - Specify current IPv6 SSM range PIM Packet Formats: - Move checksum padding out of IPv6 section where it accidentally ended up. - Clarify that the Register message length is 8. - Add destination address to the list of things that must be checked Hello Message Format: - Renamed LAN Delay field to Propagation_Delay - Describe Propagation_Delay and Override_Interval more completely. - Require the "Address List" option for IPv6 Register Message Format: - Replace "null registers" with "Null-Registers" Group Set Source List Rules: - Fix so that Join(S,G,rpt)/Prune(S,G) is ? and Prune(S,G,rpt)/Prune(S,G) is yes. Assert Message Format: - Changed "SPT bit" to "SPTbit" Timer Values: - Changed "LAN_delay_default" to "Propagation_delay_default" - Changed Propagation_Delay(I) and Override_Interval(I) to Effective_* - Added requirement that Register_Probe_Time be less than half of Register_Suppression_Time PIM Address Family: - Clarify that values 128-250 are PIM-specific. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Mon Jul 19 18:27:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23307 for ; Mon, 19 Jul 2004 18:27:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmeNI-0004bc-O5; Mon, 19 Jul 2004 16:04:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmeEJ-0001wu-VG; Mon, 19 Jul 2004 15:55:20 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19446; Mon, 19 Jul 2004 15:55:17 -0400 (EDT) Message-Id: <200407191955.PAA19446@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 19 Jul 2004 15:55:17 -0400 Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-sm-bsr-04.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Bootstrap Router (BSR) Mechanism for PIM Author(s) : B. Fenner Filename : draft-ietf-pim-sm-bsr-04.txt Pages : 37 Date : 2004-7-19 This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast protocol) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-bsr-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-sm-bsr-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-sm-bsr-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-19152713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-sm-bsr-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-sm-bsr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152713.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Tue Jul 20 01:20:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04412 for ; Tue, 20 Jul 2004 01:20:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmmy0-0004VK-Ht; Tue, 20 Jul 2004 01:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmmr9-0002h1-OM for pim@megatron.ietf.org; Tue, 20 Jul 2004 01:07:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03458 for ; Tue, 20 Jul 2004 01:07:58 -0400 (EDT) Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmmr7-0001sP-Jv for pim@ietf.org; Tue, 20 Jul 2004 01:08:04 -0400 Received: from huawei.com (huawei.com [172.17.1.61]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I140043IWYHC4@mta2.huawei.com> for pim@ietf.org; Tue, 20 Jul 2004 13:08:41 +0800 (CST) Received: from huawei.com ([172.17.1.58]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1400HWPWYGSG@mta2.huawei.com> for pim@ietf.org; Tue, 20 Jul 2004 13:08:41 +0800 (CST) Received: from [10.18.1.7] by maila.huawei.com (mshttpd); Mon, 19 Jul 2004 22:01:31 -0700 Date: Mon, 19 Jul 2004 22:01:31 -0700 From: PrashantJhingran 70625 Subject: Re: [pim] Changes from -09 to -10 in PIM-SM spec To: Bill Fenner Message-id: <397ff33d37.33d37397ff@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.7 (built Jun 26 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-imss-version: 2.5 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: 7BIT Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi, I would like to make a small comment on 09 draft although I am a bit late for the same. ---Section 4.10 "Pim Packet Formats" says that the .... Graft messages are sent (in PIM-DM protocol) as multicast packets with destination address as All Pim Routers address. The Graft messages in various situations (as described in the PIM-DM 05 draft) are sent as Unicast packets with the destination address as the Upstream Router's address, hence this part may also be updated. kind regards, Prashant ----- Original Message ----- From: Bill Fenner Date: Sunday, July 18, 2004 11:03 pm Subject: [pim] Changes from -09 to -10 in PIM-SM spec > Folks, > > Here is the list of changes to the PIM spec between -09 and -10. > These were mostly made in response to messages on the mailing list > and in response to Last Call comments. There are change bars in > both the text and postscript versions (the postscript ones are more > accurate). > > I think there are still some security-related issues pending; > Hugh said that he would follow up on the list. > > Bill > > Definitions: > - Slight clarification of DR description > > Protocol Overview: > - Mention that shared tree might have undesirable latency as well as > undesirable bandwidth overhead > - Clarify that the point-to-point links being covered are transit > links.- Add automatic (e.g., embedded-RP) discovery to how routers > learn address of RP. > > Protocol Specification: > - Moved PMBR description to Appendix. > > General Purpose State: > - Modified "Gen ID" to "GenID" > > (*,G) State: > - Added AssertWinner and AssertWinnerMetric to descriptions > > (S,G) State: > - Added AssertWinner and AssertWinnerMetric to descriptions > - Changed "SPT bit" to "SPTbit" > - Added PMBR state at RP > > State Summarization Macros: > - Remove "link-local" from definition of primary IP address definition > - Typo fix: "start machine" -> "state machine" > > Data Packet Forwarding Rules: > - Changed "SPT bit" to "SPTbit" > - Added "and iif == RPF_interface(S)" to conditional in > "On receipt of data from S to G on interface iif" pseudocode > > Last-hop switchover to the SPT: > - Added a note that starting the KAT accomplishes the switch > > Setting and Clearing the (S,G) SPTbit: > - Add "I_Am_Assert_Loser(S,G,iif)" to the conditional for setting the > SPTbit to prevent black holes (from James Lingard and others) > - Changed "SPT bit" to "SPTbit" > > Designated Routers (DR) and Hello Messages: > - Clarified that DR functionality happens on every link > > Sending Hello Messages: > - Turned "PIM-Hello" into "PIM Hello" > > Reducing Prune Propagation Delay: > - Renamed "LAN delay" to "Propagation Delay" > - Renamed "Propagation_Delay" to "Effective_Propagation_Delay" > - Allowed Effective_Propagation_Delay to use this router's value of > Propagation_Delay(I) > - Renamed "Override Delay" to "Override Interval" > - Renamed "Override_Interval" to "Effective_Override_Interval" > - Allowed Effective_Override_Interval to use this router's value of > Override_Interval(I) > > Sending Register Messages from the DR: > - Changed "Path-MTU" to "Path MTU" > - Clarified that the header sizes should be considered when > fragmenting- Use the ICMPv6 "Packet too Big" term instead of the > v4 "Fragmentation > Required" > - Clarified that the TTL is decremented before entering the register > tunnel when forwarding. > > Receiving Register Messages at the RP: > - Clarify that a packet not actually sent to one of my addresses > may be > a spoofing attempt so should be dropped. > - Added PMBR functionality > - Fixed swapped timer values when sentRegisterStop == TRUE > - Clarified the decapsulate and forward with a note > - Clarified that the TTL is decremented when leaving the register > tunnel when forwarding. > > Receiving (*,*,RP), (*,G) and (S,G) Join/Prune Messages: > - State machine: don't cancel Prune-Pending timer when entering a > state in which it's insignificant > - Clarify that accepting a zero source address on a p2p link is for > backwards compatibility > > Receiving (S,G,rpt) Join/Prune Messages: > - Replaced "n/a" and "error" entries from state machine tables > with "-" > like other state machines. > > Sending (*,G)/(S,G) Join/Prune Messages: > - Clarify that an interface entering or leaving immediate_olist is > not the only reason that JoinDesired(*,G)/(S,G) may change values. > > PIM Assert Messages: > - Spell out AH for IPsec > - "Receive Preferred Assert with RPTbit clear and AssTrDes (S,G,I)" > becomes "Receive Acceptable Assert ..." > > (S,G) Assert Message State Machine: > - Only set the SPTbit if UpstreamJPState(S,G) is true to prevent > black holes (from James Lingard and others). > > (*,G) Assert Message State Machine: > - Clarify that when there is no source address in an Assert, > there is no (S,G) Assert State Machine > - "Receive Preferred Assert with RPTbit set and AssTrDes (*,G,I)" > becomes "Receive Acceptable Assert ..." > > AssertCancel Messages: > - AssertCancel(*,G) gets a source of zero, not RP(G) > > Assert State Macros: > - Changed "SPT bit" to "SPTbit" > > PIM Multicast Border Router Behavior: > - Moved to Appendix A > > PIM Bootstrap and RP Discovery: > - Don't say that PMBRs are always the border, since that's not how > things ended up getting deployed. > - Define Embedded-RP > - Don't MUST that RP addresses be reachable, since that's an > operational concern, the protocol/implementation can't verify it. > > Source-Specific Multicast: > - Specify current IPv6 SSM range > > PIM Packet Formats: > - Move checksum padding out of IPv6 section where it accidentally > ended up. > - Clarify that the Register message length is 8. > - Add destination address to the list of things that must be checked > > Hello Message Format: > - Renamed LAN Delay field to Propagation_Delay > - Describe Propagation_Delay and Override_Interval more completely. > - Require the "Address List" option for IPv6 > > Register Message Format: > - Replace "null registers" with "Null-Registers" > > Group Set Source List Rules: > - Fix so that Join(S,G,rpt)/Prune(S,G) is ? and > Prune(S,G,rpt)/Prune(S,G) is yes. > > Assert Message Format: > - Changed "SPT bit" to "SPTbit" > > Timer Values: > - Changed "LAN_delay_default" to "Propagation_delay_default" > - Changed Propagation_Delay(I) and Override_Interval(I) to > Effective_* > - Added requirement that Register_Probe_Time be less than half > of Register_Suppression_Time > > PIM Address Family: > - Clarify that values 128-250 are PIM-specific. > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jul 20 15:12:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17274 for ; Tue, 20 Jul 2004 15:12:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmzln-0004PX-Ka; Tue, 20 Jul 2004 14:55:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmzi2-00031d-0f for pim@megatron.ietf.org; Tue, 20 Jul 2004 14:51:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15130 for ; Tue, 20 Jul 2004 14:51:24 -0400 (EDT) Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmziD-00055I-No for pim@ietf.org; Tue, 20 Jul 2004 14:51:38 -0400 Received: from hadron ([130.59.4.84] helo=hadron.switch.ch.switch.ch) by central.switch.ch with esmtp (Exim 3.20 #1) id 1BmzhV-00026o-00 for pim@ietf.org; Tue, 20 Jul 2004 20:50:53 +0200 From: Alexander Gall MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16637.27021.416924.556984@hadron.switch.ch> Date: Tue, 20 Jul 2004 20:50:53 +0200 To: pim@ietf.org X-Mailer: VM 7.18 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Subject: [pim] draft-ietf-pim-sm-bsr-04.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello all A new version of the BSR draft is now available. Nidhi Bhaskar, Stig Venaas and myself have taken over from the previous authors. Here is a short summary of the changes from -03 to -04. - Made spec PIM generic That is, for RP-based PIM protocols (PIM-SM, Bi-dir PIM) New title etc Removed text about selection of a particular RP for a group range (must be covered in the spec of the routing protocol) - Added section on Bi-dir PIM and defined Bi-dir bit for group ranges This is more or less what was in Bi-dir spec a few revs ago - Using holdtime for maintaining RP-set at all routers (not just BSR) Timer per group-to-RP mapping Group-to-RP mappings are removed only when holdtime expires Holdtime of 0 means remove immediately Need to regularly receive BSMs to keep mappings in RP-set Trying to make sure RP info doesn't disappear when electing new BSR All routers keeping copy of last BSM (not just DRs) When BS Timer expires, refresh Holdtime once, then remove BSM copy. - Holdtime is used differently at BSR Timer per candidate group-to-RP mapping May receive different mappings in different C-RP-Adv - Some attempts at clarification, some text rewritten, some new terminology - Fixed misc typos Quite a large number of issues with the previous version have been raised on the list in the past months. Many of them have not yet been addressed in -04. Here are some explanations for the choices we've made. We have decided that the entire scoping issue is too involved (and probably controversial) to be addressed in this version of the draft. All scoping-related text has been left unchanged (which might make the document inconsistent in that respect). We will post the issues and possible solutions we came up with to the list. I'll also present them in San Diego. We are considering whether the scoping part can be moved to a separate draft. While working on the other issues, we realized that a clarification of how routers manage their RP-sets was needed. The previous spec (RFC2362) made it quite clear that the holdtime was only used at the BSR, even though it is included in bootstrap messages. The new spec up to -03 was a bit unclear in this respect, which is reflected in the fact that some of the existing implementations use the holdtime only at the BSR while others use it at non-BSR routers as well. We have chosen to clarify that the holdtime must be used by all routers to time out their group-to-RP mapping information. This is the major change in -04. We would like to see if this approach is accepted by the WG before checking in detail how the issues raised before apply to it. Some of the drawbacks we identified in the previous (2362) spec: - State at routers can only be removed explicitely through BSMs - Routers may lose part of their RP-set during election of a new BSR - Difficult to detect a withdrawn group-range in some cases, BSR needs to synthesize BSMs with RP count zero To overcome this, we have introduced the group-to-RP mapping as the basic unit of information distributed by BSR (the definition of the mapping has been extended from the one in -03). Each mapping is managed independently at the BSR and within the RP-set held by a non-BSR router. In particular, all state is now allowed to expire. The BSR is essentially viewed as a "proxy" for C-RP-Advs and does not need to perform any special action on behalf of the C-RPs. We have added a new mechanism to make the system more resilient against the fail-over between C-BSRs. This is done by refreshing the RP-set with the last received BSM when the BS Timer expires, which should prevent the RP-set from expiring during election of the new BSR, at least with reasonable values for the timers involved. -- Alex _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Jul 20 21:28:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21611 for ; Tue, 20 Jul 2004 21:28:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn2GI-0002FP-EG; Tue, 20 Jul 2004 17:34:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn15y-0008KN-UM; Tue, 20 Jul 2004 16:20:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25717; Tue, 20 Jul 2004 16:20:12 -0400 (EDT) Message-Id: <200407202020.QAA25717@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 20 Jul 2004 16:20:12 -0400 Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-sm-v2-new-10.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised) Author(s) : B. Fenner, et al. Filename : draft-ietf-pim-sm-v2-new-10.txt,.ps Pages : 148 Date : 2004-7-20 This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-sm-v2-new-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-sm-v2-new-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20160256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-sm-v2-new-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-sm-v2-new-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20160256.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Thu Jul 22 18:22:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18742 for ; Thu, 22 Jul 2004 18:22:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnjp4-0001i7-J5; Thu, 22 Jul 2004 16:05:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnjYc-0002Hd-43; Thu, 22 Jul 2004 15:48:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21049; Thu, 22 Jul 2004 15:48:44 -0400 (EDT) Message-Id: <200407221948.PAA21049@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 22 Jul 2004 15:48:43 -0400 Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-bidir-07.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Bi-directional Protocol Independent Multicast (BIDIR-PIM) Author(s) : M. Handley, et al. Filename : draft-ietf-pim-bidir-07.txt,.ps Pages : 45 Date : 2004-7-22 This document discusses Bi-directional PIM, a variant of PIM Sparse-Mode [9] that builds bi-directional shared trees connecting multicast sources and receivers. Bi-directional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides a default route to the RP thus eliminating the requirement for data-driven protocol events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-bidir-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-bidir-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-bidir-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-22145649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-bidir-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-bidir-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145649.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Thu Jul 22 19:24:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28671 for ; Thu, 22 Jul 2004 19:24:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnmcd-0002kO-NW; Thu, 22 Jul 2004 19:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnlGT-0004Gf-HF for pim@megatron.ietf.org; Thu, 22 Jul 2004 17:38:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09304 for ; Thu, 22 Jul 2004 17:38:06 -0400 (EDT) Received: from web12906.mail.yahoo.com ([216.136.174.73]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BnlH6-00058e-LA for pim@ietf.org; Thu, 22 Jul 2004 17:38:49 -0400 Message-ID: <20040722213807.10423.qmail@web12906.mail.yahoo.com> Received: from [64.47.48.10] by web12906.mail.yahoo.com via HTTP; Thu, 22 Jul 2004 14:38:07 PDT Date: Thu, 22 Jul 2004 14:38:07 -0700 (PDT) From: Venugopal Hemige To: pim@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [pim] Assert Issue resulting in assert-loser forwarding onto LAN X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1637870779==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --===============1637870779== Content-Type: multipart/alternative; boundary="0-802247455-1090532287=:9431" --0-802247455-1090532287=:9431 Content-Type: text/plain; charset=us-ascii I noticed an issue with the draft that results in the assert-loser forwarding traffic onto the LAN. Here is the scenario with respect to the router that is misbehaving: 1. Consider interface I on a router A. There is a local (*,G) receiver on I. RPF_Interface(RP(G)) is also I. 2. After a SPT switchover, an (S,G) entry is also created on router A. SPT bit is set once traffic starts flowing down the source-specific tree. 3. Because of another router B on the LAN that is also forwarding traffic onto the LAN, there is an (S,G) assert election between A and B on the LAN. As a result, A becomes assert loser and B becomes assert winner. 4. A is now expected to not forward traffic coming down the SPT onto interface I, but it does. And here is why: Considering only the sets relevant to this scenario: inherited_olist(S,G,rpt) = pim_include(*,G) (-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) ) We would expect lost_assert(S,G,rpt) to include interface I in the set. But since it is RPF_Interface(RP(G)), it does not get included in this set. I think the bug is in the definition of lost_assert(S,G,rpt,I). The correct definition should be: bool lost_assert(S,G,rpt,I) { if ( ( RPF_interface(RP(G)) == I AND SPTbit(S,G) == FALSE ) OR ( RPF_interface(S) == I AND SPTbit(S,G) == TRUE ) ) { return FALSE } else { return ( AssertWinner(S,G,I) != NULL AND AssertWinner(S,G,I) != me ) } } If SPTbit is already set for the (S,G), then RPF_Interface(RP(G)) should just be treated as another (S,G) OIF and we should return TRUE if AssertWinner(S,G,I) is not me. Am I missing something? Regards, -Venu --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! --0-802247455-1090532287=:9431 Content-Type: text/html; charset=us-ascii

I noticed an issue with the draft that results in the assert-loser forwarding traffic onto the LAN. Here is the scenario with respect to the router that is misbehaving:

1. Consider interface I on a router A.

    There is a local (*,G) receiver on I.

    RPF_Interface(RP(G)) is also I.

2. After a SPT switchover, an (S,G) entry is also created on router A.

    SPT bit is set once traffic starts flowing down the source-specific tree.

3. Because of another router B on the LAN that is also forwarding traffic onto the LAN, there is an (S,G) assert election between A and B on the LAN.

    As a result, A becomes assert loser and B becomes assert winner.

4. A is now expected to not forward traffic coming down the SPT onto interface I, but it does. And here is why:

Considering only the sets relevant to this scenario:

inherited_olist(S,G,rpt) = pim_include(*,G) (-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )

We would expect lost_assert(S,G,rpt) to include interface I in the set. But since it is RPF_Interface(RP(G)), it does not get included in this set.

I think the bug is in the definition of lost_assert(S,G,rpt,I). The correct definition should be:

bool lost_assert(S,G,rpt,I) {
    if ( ( RPF_interface(RP(G)) == I  AND SPTbit(S,G) == FALSE ) OR
         ( RPF_interface(S) == I AND SPTbit(S,G) == TRUE ) ) {
       return FALSE
    } else {
       return ( AssertWinner(S,G,I) != NULL AND
                AssertWinner(S,G,I) != me )
    }
  }

If SPTbit is already set for the (S,G), then RPF_Interface(RP(G)) should just be treated as another (S,G) OIF and we should return TRUE if AssertWinner(S,G,I) is not me.

Am I missing something?

Regards,

-Venu

 

Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages! --0-802247455-1090532287=:9431-- --===============1637870779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============1637870779==-- From pim-bounces@ietf.org Mon Jul 26 03:53:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07173 for ; Mon, 26 Jul 2004 03:53:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp0Fs-0001h1-65; Mon, 26 Jul 2004 03:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp0FO-0001aL-U4 for pim@megatron.ietf.org; Mon, 26 Jul 2004 03:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07118 for ; Mon, 26 Jul 2004 03:50:08 -0400 (EDT) Received: from v2.gawab.com ([204.97.230.42] helo=gawab.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bp0Gh-0001UP-PO for pim@ietf.org; Mon, 26 Jul 2004 03:51:35 -0400 Received: (qmail 30926 invoked by uid 1004); 26 Jul 2004 07:50:08 -0000 Message-ID: <20040726075008.30924.qmail@gawab.com> Received: from 213.212.245.135 by webmail.gawab.com with HTTP; Mon, 26 Jul 2004 07:50:07 GMT From: "nada taha" To: pim@ietf.org Date: Mon, 26 Jul 2004 07:50:07 GMT Mime-Version: 1.0 X-Originating-IP: [213.212.245.135] X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [pim] i need ur help X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1927775786==" Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org --===============1927775786== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Dear group.........I'm a computer engineering.........i need your help in two things:
 
1- I need a PIM -SM implemention(C++ source code) can be used in NS2.
2- Is the ctrmcast protocol in NS a pim_sm.
 
              I'm waiting ur reply
 
                                     Yours........Nada
--------------------------------------------------------------------------------
Get your free 15 Mb POP3 email @alexandria.cc
--===============1927775786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============1927775786==-- From pim-bounces@ietf.org Mon Jul 26 18:04:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13724 for ; Mon, 26 Jul 2004 18:04:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpDSY-0003wF-2I; Mon, 26 Jul 2004 17:56:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpDKe-00027I-AB for pim@megatron.ietf.org; Mon, 26 Jul 2004 17:48:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12429 for ; Mon, 26 Jul 2004 17:48:25 -0400 (EDT) Received: from possum.icir.org ([192.150.187.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpDM6-0000RR-Qk for pim@ietf.org; Mon, 26 Jul 2004 17:50:00 -0400 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i6QLmPW5012177; Mon, 26 Jul 2004 14:48:25 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200407262148.i6QLmPW5012177@possum.icir.org> To: Dino Farinacci Subject: Re: [pim] I-D ACTION:draft-farinacci-pim-pop-count-00.txt In-Reply-To: Message from Dino Farinacci of "Tue, 18 May 2004 16:58:25 PDT." <200405182358.i4INwPhN022305@dino-pc.procket.com> Date: Mon, 26 Jul 2004 14:48:25 -0700 From: Pavlin Radoslavov X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org [Note: a reply to a very old email] > Folks, please comment. > > Dino At the very high level I think it is a very good idea of having a mechanism for multicast tree accounting, etc. Implementation/design-wise I have few comments: * Have you looked into related work such as the following paper: "Tracetree: A Scalable Mechanism to Discover Multicast Tree Topologies in the Internet" by Kamil Sarac and Kevin Almeroth: http://www.nmsl.cs.ucsb.edu/publications.html It has a number of interesting ideas including a mechanism to deal with incremental deployment, it is not protocol-specific, etc. * We need to deal with incremental deployment, otherwise there is no initiative to even start deploying this new scheme. E.g., ideas from the above paper can be helpful in this aspect. * In your proposal you overload the Join messages with accounting information. The advantage of doing that is that you save some network bandwidth and processing cycles, but the result solution becomes a bit too complicated and lacks flexibility. For example, if someone wants to define a new counter, adding such counter to the fixed message format is impossible without redefining the whole format again. I would rather see those two functionalities separated: the tree management (i.e., the Join/Prune messages), and the tree accounting. By that I mean using a new type control message (for accounting purpose only) which is designed to have extensible format, etc. Then, each counter for example, can be added as an option to the message. * Currently, it appears that the mechanism is PIM-SM specific. Rather than redefining the mechanism for PIM-DM, etc, I'd prefer to have a protocol-independent mechanism. After all, it appears that the only major thing that currently ties the mechanism to PIM-SM is the message format overloading of the PIM-SM Join messages. * Some of the fields are probably not large enough. E.g., max. value of 255 for "Node Count" is one that comes to mind. Another example is the link speed where everything below 1Mbps becomes 0. If we are to consider the last-mile multicast, then we need better granularity. Thanks, Pavlin > > ------------------------------------------------------------------------------- > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Population Count Extensions to PIM > Author(s) : D. Farinacci, G. Shepherd > Filename : draft-farinacci-pim-pop-count-00.txt > Pages : 8 > Date : 2004-5-18 > > Performing an approximation in some form of multicast distribution > tree accounting proves to be useful for billing and debugging. The > Population Count extensions to PIM, documented in this draft, > provide an efficient method to achieve this. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farinacci-pim-pop-count-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with th > ------------------------------------------------------------------------------- > > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jul 30 11:24:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14307 for ; Fri, 30 Jul 2004 11:24:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqZBd-0003Kr-P4; Fri, 30 Jul 2004 11:20:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqYyY-00075I-0V for pim@megatron.ietf.org; Fri, 30 Jul 2004 11:07:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13605 for ; Fri, 30 Jul 2004 11:07:11 -0400 (EDT) Received: from [216.37.114.8] (helo=lxmail.xebeo.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BqZ0m-00015V-Vo for pim@ietf.org; Fri, 30 Jul 2004 11:09:34 -0400 Received: (qmail 29890 invoked by uid 404); 30 Jul 2004 15:06:39 -0000 Received: from manish.gupta@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.023353 secs); 30 Jul 2004 15:06:39 -0000 Received: from bianco.nj.us.utstar.com (HELO utstar.com) (172.16.36.187) by lxmail.xebeo.com with SMTP; 30 Jul 2004 15:06:39 -0000 Message-ID: <410A63F1.8050801@utstar.com> Date: Fri, 30 Jul 2004 11:06:25 -0400 From: "Manish Gupta (BBS)" Organization: Broadband Switching Group User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030324 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pim@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Subject: [pim] Can RP skip sending Register-Stop messages? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello I have a pim-sm question specific to the following topology. I will appreciate if somebody could clarify my doubts about the workings of the pim-sm protocol. Topology: -#1-- [ box-RP ] --#2---- | | | | [Box-Rcvr]-----#3------[Box-Sndr] | | | | (R) (S) TimeLine (skipping many steps): 0. (R) starts up 1. [Rcvr] sends (*,G) Joins to [RP] RP creates an (*,G) entry. 2. (S) starts 3. [Sndr] sends packet from (S) to [RP] wrapped in Register packet. 4. On receiving Register Packet, [RP] tries to switch-over to SPT. To do this, [RP] sends a SG_Join to [Sndr]. 5. On receiving JSG_Join from SG [Sndr] can setup the forwarding path to RP. Question: Does [RP] still needs to send a Register-Stop to [Sndr]? On [Sndr] if there is an SG path pointing to RP, why does it need to receive an explicit Register-Stop message from [RP]? It can forward the SG packet natively based on the SG_Join it has received. NO? Much thanks in advance. manish ps: please let me know if this is not the right place to post such questions. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jul 30 11:50:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15466 for ; Fri, 30 Jul 2004 11:50:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqZcN-0006OL-RX; Fri, 30 Jul 2004 11:48:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqZVp-0003Ch-Ff for pim@megatron.ietf.org; Fri, 30 Jul 2004 11:41:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15055 for ; Fri, 30 Jul 2004 11:41:34 -0400 (EDT) Received: from mail-dark.research.att.com ([192.20.225.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqZY4-0001aM-Py for pim@ietf.org; Fri, 30 Jul 2004 11:43:58 -0400 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-dark.research.att.com (Postfix) with ESMTP id 6E59BE8041; Fri, 30 Jul 2004 11:41:05 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id 558191974D8; Fri, 30 Jul 2004 11:38:54 -0400 (EDT) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i6UFf4E09524; Fri, 30 Jul 2004 08:41:04 -0700 (PDT) Message-Id: <200407301541.i6UFf4E09524@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: manish.gupta@utstar.com Subject: Re: [pim] Can RP skip sending Register-Stop messages? Date: Fri, 30 Jul 2004 08:41:02 -0700 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Manish, In general, the DR that is Registering can't know if the (S,G) Join is from the RP or from some other system that has switched over to the shortest-path tree. The topology that you show in which it can tell is so rare that it's not worth optimizing for. Bill _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jul 30 12:24:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17096 for ; Fri, 30 Jul 2004 12:24:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqZv8-0004fF-51; Fri, 30 Jul 2004 12:07:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqZmp-0001cr-D9 for pim@megatron.ietf.org; Fri, 30 Jul 2004 11:59:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15912 for ; Fri, 30 Jul 2004 11:59:08 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqZp4-0001p9-J8 for pim@ietf.org; Fri, 30 Jul 2004 12:01:31 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 928292D4828; Fri, 30 Jul 2004 11:58:38 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 68056-01-47; Fri, 30 Jul 2004 11:58:37 -0400 (EDT) Received: from nexthop.com (ctbrown.nexthop.com [65.247.36.75]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8E67F2D4815; Fri, 30 Jul 2004 11:58:37 -0400 (EDT) From: Christopher Thomas Brown Subject: Re: [pim] Can RP skip sending Register-Stop messages? To: "Manish Gupta (BBS)" In-Reply-To: Your message of "Fri, 30 Jul 2004 11:06:25 EDT." <410A63F1.8050801@utstar.com> Date: Fri, 30 Jul 2004 11:57:34 -0400 Message-Id: <20040730155837.8E67F2D4815@aa-mx1.nexthop.com> X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Comments at bottom. On Fri, 30 Jul 2004 11:06:25 EDT "Manish Gupta (BBS)" wrote: > > >Hello > > I have a pim-sm question specific to the following topology. I will > appreciate if somebody could clarify my doubts about the workings > of the pim-sm protocol. > > Topology: > > -#1-- [ box-RP ] --#2---- > | | > | | > [Box-Rcvr]-----#3------[Box-Sndr] > | | > | | > (R) (S) > > > TimeLine (skipping many steps): > > 0. (R) starts up > > 1. [Rcvr] sends (*,G) Joins to [RP] > > RP creates an (*,G) entry. > > 2. (S) starts > > 3. [Sndr] sends packet from (S) to [RP] wrapped in Register packet. > > 4. On receiving Register Packet, [RP] tries to switch-over to > SPT. To do this, [RP] sends a SG_Join to [Sndr]. > > 5. On receiving JSG_Join from SG [Sndr] can setup the forwarding > path to RP. > > Question: > Does [RP] still needs to send a Register-Stop to [Sndr]? Yes. > On [Sndr] if there is an SG path pointing to RP, why does it need > to receive an explicit Register-Stop message from [RP]? > It can forward the SG packet natively based on the SG_Join it > has received. NO? It needs the register stop message to stop forwarding the data out the register tunnel. The scenario you present is an edge case that the finite state machines do not optimize, that is the RP is adjacent to the first hop router so that the first hop could tell that the RP was joined to the SPT. However, imagine a slightly more complex scenario with an additional router between the first hop and the RP. -#1-- [ box-RP ] --#2----[Box-Middle]-----(R2) | | #4 #5 | | [Box-Rcvr]-----#3------[Box-Sndr] | | | | (R) (S) Now let's posit that the RP does not switch to the SPT and that [box-middle] does switch. If [box-sndr] does not keep sending register packets then [box-rcvr] and thus R does not receive data. The PIM spec tries to keep things as simple as possible for what is a complex protocol. Edge case optimizations like this are typically avoided. Chris _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jul 30 12:31:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17536 for ; Fri, 30 Jul 2004 12:31:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqaB7-0003hb-8z; Fri, 30 Jul 2004 12:24:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bqa3u-0000oE-2u for pim@megatron.ietf.org; Fri, 30 Jul 2004 12:16:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16744 for ; Fri, 30 Jul 2004 12:16:47 -0400 (EDT) Received: from [216.37.114.8] (helo=lxmail.xebeo.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bqa69-000239-Dd for pim@ietf.org; Fri, 30 Jul 2004 12:19:10 -0400 Received: (qmail 7805 invoked by uid 404); 30 Jul 2004 16:16:11 -0000 Received: from manish.gupta@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.024329 secs); 30 Jul 2004 16:16:11 -0000 Received: from bianco.nj.us.utstar.com (HELO utstar.com) (172.16.36.187) by lxmail.xebeo.com with SMTP; 30 Jul 2004 16:16:11 -0000 Message-ID: <410A743C.6070409@utstar.com> Date: Fri, 30 Jul 2004 12:15:56 -0400 From: "Manish Gupta (BBS)" Organization: Broadband Switching Group User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030324 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christopher Thomas Brown Subject: Re: [pim] Can RP skip sending Register-Stop messages? References: <20040730155837.8E67F2D4815@aa-mx1.nexthop.com> In-Reply-To: <20040730155837.8E67F2D4815@aa-mx1.nexthop.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Content-Transfer-Encoding: 7bit Thanks for clarifying this. regards manish Christopher Thomas Brown wrote: >Comments at bottom. > >On Fri, 30 Jul 2004 11:06:25 EDT >"Manish Gupta (BBS)" wrote: > > >>Hello >> >> I have a pim-sm question specific to the following topology. I will >> appreciate if somebody could clarify my doubts about the workings >> of the pim-sm protocol. >> >> Topology: >> >> -#1-- [ box-RP ] --#2---- >> | | >> | | >> [Box-Rcvr]-----#3------[Box-Sndr] >> | | >> | | >> (R) (S) >> >> >> TimeLine (skipping many steps): >> >> 0. (R) starts up >> >> 1. [Rcvr] sends (*,G) Joins to [RP] >> >> RP creates an (*,G) entry. >> >> 2. (S) starts >> >> 3. [Sndr] sends packet from (S) to [RP] wrapped in Register packet. >> >> 4. On receiving Register Packet, [RP] tries to switch-over to >> SPT. To do this, [RP] sends a SG_Join to [Sndr]. >> >> 5. On receiving JSG_Join from SG [Sndr] can setup the forwarding >> path to RP. >> >> Question: >> Does [RP] still needs to send a Register-Stop to [Sndr]? >> >> > >Yes. > > > >> On [Sndr] if there is an SG path pointing to RP, why does it need >> to receive an explicit Register-Stop message from [RP]? >> It can forward the SG packet natively based on the SG_Join it >> has received. NO? >> >> > >It needs the register stop message to stop forwarding the data out >the register tunnel. The scenario you present is an edge case that >the finite state machines do not optimize, that is the RP is adjacent >to the first hop router so that the first hop could tell that the RP >was joined to the SPT. However, imagine a slightly more complex scenario >with an additional router between the first hop and the RP. > > > -#1-- [ box-RP ] --#2----[Box-Middle]-----(R2) > | | #4 #5 > | | > [Box-Rcvr]-----#3------[Box-Sndr] > | | > | | > (R) (S) > >Now let's posit that the RP does not switch to the SPT and that >[box-middle] does switch. If [box-sndr] does not keep sending >register packets then [box-rcvr] and thus R does not receive data. > >The PIM spec tries to keep things as simple as possible for what >is a complex protocol. Edge case optimizations like this are >typically avoided. > >Chris > > _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Fri Jul 30 22:54:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18022 for ; Fri, 30 Jul 2004 22:54:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bqjy7-00023k-7r; Fri, 30 Jul 2004 22:51:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqjuV-0001Hs-J9 for pim@megatron.ietf.org; Fri, 30 Jul 2004 22:47:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17736 for ; Fri, 30 Jul 2004 22:47:45 -0400 (EDT) Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bqjwq-0001W6-CH for pim@ietf.org; Fri, 30 Jul 2004 22:50:14 -0400 Received: from huawei8tthy486 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I1P00CP83OVY9@mta0.huawei.com> for pim@ietf.org; Sat, 31 Jul 2004 10:46:08 +0800 (CST) Date: Sat, 31 Jul 2004 10:46:56 +0800 From: Prashant Jhingran Subject: RE: [pim] Can RP skip sending Register-Stop messages? In-reply-to: <410A63F1.8050801@utstar.com> To: "'Manish Gupta (BBS)'" , pim@ietf.org Message-id: <000501c476a8$a4e96900$30226e0a@huawei8tthy486> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7BIT X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pim-bounces@ietf.org Errors-To: pim-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Maneesh, Just to sum up what others have commented. Register-Stop is an indication from RP to SDR that RP no longer wants register packets from SDR for that particular S,G (S can be a wild card as well). Now the reasons can be: a) RP is not interested in S,G coz no receivers fro this G b) RP has started receiving S,G packets via SPT. Regards, Prashant -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of Manish Gupta (BBS) Sent: Friday, July 30, 2004 11:06 PM To: pim@ietf.org Subject: [pim] Can RP skip sending Register-Stop messages? Hello I have a pim-sm question specific to the following topology. I will appreciate if somebody could clarify my doubts about the workings of the pim-sm protocol. Topology: -#1-- [ box-RP ] --#2---- | | | | [Box-Rcvr]-----#3------[Box-Sndr] | | | | (R) (S) TimeLine (skipping many steps): 0. (R) starts up 1. [Rcvr] sends (*,G) Joins to [RP] RP creates an (*,G) entry. 2. (S) starts 3. [Sndr] sends packet from (S) to [RP] wrapped in Register packet. 4. On receiving Register Packet, [RP] tries to switch-over to SPT. To do this, [RP] sends a SG_Join to [Sndr]. 5. On receiving JSG_Join from SG [Sndr] can setup the forwarding path to RP. Question: Does [RP] still needs to send a Register-Stop to [Sndr]? On [Sndr] if there is an SG path pointing to RP, why does it need to receive an explicit Register-Stop message from [RP]? It can forward the SG packet natively based on the SG_Join it has received. NO? Much thanks in advance. manish ps: please let me know if this is not the right place to post such questions. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim