From pim-admin@ietf.org Thu Apr 1 01:07:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06548 for ; Thu, 1 Apr 2004 01:07:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8vLx-0001As-2N; Thu, 01 Apr 2004 01:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8vL9-00019V-F3 for pim@optimus.ietf.org; Thu, 01 Apr 2004 01:06:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06486 for ; Thu, 1 Apr 2004 01:06:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8vL6-00042j-00 for pim@ietf.org; Thu, 01 Apr 2004 01:06:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8vKX-0003vs-00 for pim@ietf.org; Thu, 01 Apr 2004 01:05:34 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8vJL-0003ma-00 for pim@ietf.org; Thu, 01 Apr 2004 01:04:19 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2004 22:11:33 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3163mn2013745 for ; Wed, 31 Mar 2004 22:03:49 -0800 (PST) Received: from irp-view6.cisco.com (irp-view6.cisco.com [171.70.65.143]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARR05459; Wed, 31 Mar 2004 22:03:47 -0800 (PST) Date: Wed, 31 Mar 2004 22:03:47 -0800 (PST) From: Mike McBride To: pim@ietf.org Subject: [pim] draft status url Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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=none autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Tom and I are using the following site to track pim wg drafts: http://www.employees.org/~mmcbride/pimwg/draft_status It will be kept current. Please ping us with additional details you may want to see. And please feel free to offer assistance to draft authors on open issues. thanks, mike _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Thu Apr 1 01:09:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06637 for ; Thu, 1 Apr 2004 01:09:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8vNp-0001aR-9G for pim-archive@odin.ietf.org; Thu, 01 Apr 2004 01:08:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3168vq7006095 for pim-archive@odin.ietf.org; Thu, 1 Apr 2004 01:08:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8vNo-0001aD-S0 for pim-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 01:08:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06606 for ; Thu, 1 Apr 2004 01:08:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8vNl-0004GP-00 for pim-web-archive@ietf.org; Thu, 01 Apr 2004 01:08:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8vMw-0004CO-00 for pim-web-archive@ietf.org; Thu, 01 Apr 2004 01:08:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8vMF-00048C-00 for pim-web-archive@ietf.org; Thu, 01 Apr 2004 01:07:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8vLx-0001As-2N; Thu, 01 Apr 2004 01:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8vL9-00019V-F3 for pim@optimus.ietf.org; Thu, 01 Apr 2004 01:06:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06486 for ; Thu, 1 Apr 2004 01:06:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8vL6-00042j-00 for pim@ietf.org; Thu, 01 Apr 2004 01:06:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8vKX-0003vs-00 for pim@ietf.org; Thu, 01 Apr 2004 01:05:34 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8vJL-0003ma-00 for pim@ietf.org; Thu, 01 Apr 2004 01:04:19 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2004 22:11:33 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3163mn2013745 for ; Wed, 31 Mar 2004 22:03:49 -0800 (PST) Received: from irp-view6.cisco.com (irp-view6.cisco.com [171.70.65.143]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARR05459; Wed, 31 Mar 2004 22:03:47 -0800 (PST) Date: Wed, 31 Mar 2004 22:03:47 -0800 (PST) From: Mike McBride To: pim@ietf.org Subject: [pim] draft status url Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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=none autolearn=no version=2.60 Tom and I are using the following site to track pim wg drafts: http://www.employees.org/~mmcbride/pimwg/draft_status It will be kept current. Please ping us with additional details you may want to see. And please feel free to offer assistance to draft authors on open issues. thanks, mike _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From mailman-admin@ietf.org Thu Apr 1 18:11:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07308 for ; Thu, 1 Apr 2004 18:11:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99P4-0004W4-US for pim-archive@lists.ietf.org; Thu, 01 Apr 2004 16:07:10 -0500 Date: Thu, 01 Apr 2004 11:19:00 -0500 Message-ID: <20040401161900.11029.73374.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: pim-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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, pim-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 All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.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-admin@ietf.org Fri Apr 2 03:20:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28515 for ; Fri, 2 Apr 2004 03:20:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9EC8-0008IL-Ai; Thu, 01 Apr 2004 21:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9CRC-0007yi-Gl for pim@optimus.ietf.org; Thu, 01 Apr 2004 19:21:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13343 for ; Thu, 1 Apr 2004 19:21:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9CRA-00015Z-00 for pim@ietf.org; Thu, 01 Apr 2004 19:21:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9CQE-0000wE-00 for pim@ietf.org; Thu, 01 Apr 2004 19:20:35 -0500 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1B9CPc-0000qP-00 for pim@ietf.org; Thu, 01 Apr 2004 19:19:56 -0500 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i320Jur6006697 for ; Thu, 1 Apr 2004 16:19:56 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200404020019.i320Jur6006697@possum.icir.org> To: pim@ietf.org Date: Thu, 01 Apr 2004 16:19:56 -0800 From: Pavlin Radoslavov 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=none autolearn=no version=2.60 Subject: [pim] More draft-ietf-pim-sm-v2-new-09.txt comments Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Below I am including few more comments regarding the PIM-SM spec. First I include few emails to the ML (items 1--3) from other folks that had raised some issues in the past. Some of those issues are probably related. The rest of the items are just editorial stuff. Pavlin =================================================================== 1) [An old email from "James Huang" 11 Apr 2002]: After more thoughts on the issue that I raised in my previous emails, I still believe there is a problem with the (S,G) assert state-machine. The problem is as follows: Suppose initially the state-machine is in the NoInfo state and AssertTrackingDesired(S,G,I)== TRUE. When it receives a prefered (S,G) assert message with RPT clear from intf I, it will transition to the AssertLoser state. Additionally, if (I == RPF_intf(S)), it will set SPTbit(S,G) to 1. Now if JoinDesired(S,G) is FALSE, we have created a bad (S,G) state where SPTbit(S,G) is set to 1 while JoinDesired(S,G) is FALSE. This bad state can prevent this router from forwarding future (S,G) traffic (see sec 4.2 Data Forwarding Rules). I think the fix is to set SPTbit(S,G) to 1 only if (I == RPF_intf(S) && JoinDesired(S,G) == TRUE). =================================================================== 2) [An old email from "James Huang" 17 Apr 2002]: [Note: this probably is same issue as (1) above] In the current pim-sm draft, AssertTrackingDesired(S,G,I) includes the following clause: (RPF_interface(RP)==I AND JoinDesired(*,G)==TRUE AND SPTbit(S,G)==FALSE) Can someone tell me why it is necessary for a router with (*,G) state only to track (S,G) asserts in its RPF_intf(RP(G))? Consider the following scenario: S --------------- RP | | | | R1 R2 | | | | ----------------------------------- | | | | R3 R4 ^ ^ | | | | igmp(S,G) join igmp(*,G) join Suppose we have the following condition before the (S,G) traffic starts: At R3, RPF'(S)=R1, JoinDesired(S,G) == TRUE, KLA(S,G) not running, and SPTbit(S,G) == 0 At R4, RPF'(RP(G))=R2, JoinDesired(*,G) == TRUE, and no (S,G) state. When R1 observes (S,G) traffic forwarded by R2 to the LAN, it will sends a (S,G) assert with RPT bit clear. When R4 receives the (S,G) assert, it will create the (S,G) state and move its (S,G) assert state-machine for the interface from the NoInfo state to the AssertLoser state because AssertTrackingDesired(S,G) is TRUE due to the clause above. Furthermore, it will set SPTbit(S,G) to 1 because the assert message is received from RPF_intf(S). Now at R4, JoinDesired(S,G) == FALSE (UpstreamJPState(S,G) != Joined) while SPTbit(S,G) == 1. This will create a black-hole and cause R4 to drop all (S,G) traffic it receives. =================================================================== 3) [A recent email from Christopher Thomas Brown 26 Mar 2004] I was looking at a situation where an s,g assert is received on the upstream interface towards the RP and there is downstream *,g state. I think there is a missing action in Actions A6. AssertTrackingDesired(S,G,I) would be true in this situation due to the last OR condition: RPF_Interface(RP(G) == I) AND JoinDesired(*,G) == TRUE AND SPTbit(S,G) == FALSE So in the NoInfo state this situation would fall under the event: Received preferred assert with RPT bit clear AND AssertTrackingDesired(S,G,I) == TRUE In the NoInfo state for this event we would perform actions A6. Actions A6 are the following: Store assert winner and its metric Set assert timer If RPF_Interface(S) == I set SPTbit(S,G) to TRUE. For this last action it seems like it we would also want to start the keepalive timer. Without the Keepalive timer running JoinDesired(S,G) is not TRUE. For a reminder JoinDesired(S,G) is immediate_olist(S,G) != NULL OR (KeepAliveTimer(S,G) is running AND inherited_olist(S,G) != NULL) In the situation the immediate_olist(S,G) is NULL so only if the KeepAliveTimer(S,G) is running will JoinDesired(S,G) be TRUE. It seems like from the intent of the actions that we are supposed to be on the SPT. Am I missing something or should starting the KeepAliveTimer(S,G) be added to the part of the action for IF RPF_Interface(S) == I? =================================================================== 4) Section 4.6.2 (*,G) Assert Message State Machine Why the source address in the PIM Assert message is checked whether it is not zero? Shouldn't the check be stricter: e.g, whether it is a valid unicast address? =================================================================== 5) Section 4.3.4: "The primary IP address of a neighbor is the link-local address that it uses as the source of its PIM Hello messages. Note that..." SPEC: if the IPv6 Hello source address is not a link-local address, then what should the recepient do? =================================================================== 6) Section 4.12. Timer Value The text below is out-of-sync with packet_arrives_on_rp_tunnel(): "However at the RP, the keepalive period must be at least the Register_Suppression_Time or the RP may time out the (S,G) state before the next Null-Register arrives. Thus the KAT(S,G) is set to -max(Keepalive_Period, RP_Keepalive_Period). +max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is sent." The reason for the inconsistency is because inside packet_arrives_on_rp_tunnel() sometimes the timer is unconditionally set to Keepalive_Period when a Register-Stop is sent. =================================================================== 7) Everywhere Suggestion: Change "Upstream Join" to "Upstream-Join" (for timers). Similarly, change "Upstream Override" to "Upstream-Override" ?? =================================================================== 8) Inside Section 4.10.3: "null register" -> "Null-Register" =================================================================== 9) In Section 4.10 paragraph "Checksum" replace "the length of the PIM header" with "8", because "PIM header" could be ambiguous (e.g., is it 4 or 8). Also, what about the IPv6 pseudo-header source and destination address. Are they set to the PIM control message source and destination address as well? =================================================================== 10) Section 4.6.1 (S,G) Assert Message State Machine Why part of the "In I Am Assert Loser (L) State" table is listed first? Shoudn't it be moved a bit down together with the rest of the "Loser State" table. =================================================================== 11) Maybe replace "See Join(*,*,RP) to MRIB.next_hop(RP)" with "See Join(*,*,RP) to NBR(RPF_interface(RP), MRIB.next_hop(RP))" Similar change needed for "See Prune(*,*,RP) to MRIB.next_hop(RP)". =================================================================== 12) Maybe change "MRIB.next_hop(RP) GenID changes" to "NBR(RPF_interface(RP), MRIB.next_hop(RP) GenID changes" ?? =================================================================== _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Apr 2 10:23:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13615 for ; Fri, 2 Apr 2004 10:23:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9N91-0002hQ-O1 for pim-archive@odin.ietf.org; Fri, 02 Apr 2004 06:47:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32BlVHU010377 for pim-archive@odin.ietf.org; Fri, 2 Apr 2004 06:47:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Jvx-00020X-8U for pim-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 03:21:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28570 for ; Fri, 2 Apr 2004 03:21:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Jvv-00015A-00 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 03:21:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9JvD-0000yF-00 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 03:21:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9JuU-0000pn-00 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 03:20:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9EC8-0008IL-Ai; Thu, 01 Apr 2004 21:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9CRC-0007yi-Gl for pim@optimus.ietf.org; Thu, 01 Apr 2004 19:21:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13343 for ; Thu, 1 Apr 2004 19:21:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9CRA-00015Z-00 for pim@ietf.org; Thu, 01 Apr 2004 19:21:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9CQE-0000wE-00 for pim@ietf.org; Thu, 01 Apr 2004 19:20:35 -0500 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1B9CPc-0000qP-00 for pim@ietf.org; Thu, 01 Apr 2004 19:19:56 -0500 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i320Jur6006697 for ; Thu, 1 Apr 2004 16:19:56 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200404020019.i320Jur6006697@possum.icir.org> To: pim@ietf.org Date: Thu, 01 Apr 2004 16:19:56 -0800 From: Pavlin Radoslavov Subject: [pim] More draft-ietf-pim-sm-v2-new-09.txt comments Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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=none autolearn=no version=2.60 Below I am including few more comments regarding the PIM-SM spec. First I include few emails to the ML (items 1--3) from other folks that had raised some issues in the past. Some of those issues are probably related. The rest of the items are just editorial stuff. Pavlin =================================================================== 1) [An old email from "James Huang" 11 Apr 2002]: After more thoughts on the issue that I raised in my previous emails, I still believe there is a problem with the (S,G) assert state-machine. The problem is as follows: Suppose initially the state-machine is in the NoInfo state and AssertTrackingDesired(S,G,I)== TRUE. When it receives a prefered (S,G) assert message with RPT clear from intf I, it will transition to the AssertLoser state. Additionally, if (I == RPF_intf(S)), it will set SPTbit(S,G) to 1. Now if JoinDesired(S,G) is FALSE, we have created a bad (S,G) state where SPTbit(S,G) is set to 1 while JoinDesired(S,G) is FALSE. This bad state can prevent this router from forwarding future (S,G) traffic (see sec 4.2 Data Forwarding Rules). I think the fix is to set SPTbit(S,G) to 1 only if (I == RPF_intf(S) && JoinDesired(S,G) == TRUE). =================================================================== 2) [An old email from "James Huang" 17 Apr 2002]: [Note: this probably is same issue as (1) above] In the current pim-sm draft, AssertTrackingDesired(S,G,I) includes the following clause: (RPF_interface(RP)==I AND JoinDesired(*,G)==TRUE AND SPTbit(S,G)==FALSE) Can someone tell me why it is necessary for a router with (*,G) state only to track (S,G) asserts in its RPF_intf(RP(G))? Consider the following scenario: S --------------- RP | | | | R1 R2 | | | | ----------------------------------- | | | | R3 R4 ^ ^ | | | | igmp(S,G) join igmp(*,G) join Suppose we have the following condition before the (S,G) traffic starts: At R3, RPF'(S)=R1, JoinDesired(S,G) == TRUE, KLA(S,G) not running, and SPTbit(S,G) == 0 At R4, RPF'(RP(G))=R2, JoinDesired(*,G) == TRUE, and no (S,G) state. When R1 observes (S,G) traffic forwarded by R2 to the LAN, it will sends a (S,G) assert with RPT bit clear. When R4 receives the (S,G) assert, it will create the (S,G) state and move its (S,G) assert state-machine for the interface from the NoInfo state to the AssertLoser state because AssertTrackingDesired(S,G) is TRUE due to the clause above. Furthermore, it will set SPTbit(S,G) to 1 because the assert message is received from RPF_intf(S). Now at R4, JoinDesired(S,G) == FALSE (UpstreamJPState(S,G) != Joined) while SPTbit(S,G) == 1. This will create a black-hole and cause R4 to drop all (S,G) traffic it receives. =================================================================== 3) [A recent email from Christopher Thomas Brown 26 Mar 2004] I was looking at a situation where an s,g assert is received on the upstream interface towards the RP and there is downstream *,g state. I think there is a missing action in Actions A6. AssertTrackingDesired(S,G,I) would be true in this situation due to the last OR condition: RPF_Interface(RP(G) == I) AND JoinDesired(*,G) == TRUE AND SPTbit(S,G) == FALSE So in the NoInfo state this situation would fall under the event: Received preferred assert with RPT bit clear AND AssertTrackingDesired(S,G,I) == TRUE In the NoInfo state for this event we would perform actions A6. Actions A6 are the following: Store assert winner and its metric Set assert timer If RPF_Interface(S) == I set SPTbit(S,G) to TRUE. For this last action it seems like it we would also want to start the keepalive timer. Without the Keepalive timer running JoinDesired(S,G) is not TRUE. For a reminder JoinDesired(S,G) is immediate_olist(S,G) != NULL OR (KeepAliveTimer(S,G) is running AND inherited_olist(S,G) != NULL) In the situation the immediate_olist(S,G) is NULL so only if the KeepAliveTimer(S,G) is running will JoinDesired(S,G) be TRUE. It seems like from the intent of the actions that we are supposed to be on the SPT. Am I missing something or should starting the KeepAliveTimer(S,G) be added to the part of the action for IF RPF_Interface(S) == I? =================================================================== 4) Section 4.6.2 (*,G) Assert Message State Machine Why the source address in the PIM Assert message is checked whether it is not zero? Shouldn't the check be stricter: e.g, whether it is a valid unicast address? =================================================================== 5) Section 4.3.4: "The primary IP address of a neighbor is the link-local address that it uses as the source of its PIM Hello messages. Note that..." SPEC: if the IPv6 Hello source address is not a link-local address, then what should the recepient do? =================================================================== 6) Section 4.12. Timer Value The text below is out-of-sync with packet_arrives_on_rp_tunnel(): "However at the RP, the keepalive period must be at least the Register_Suppression_Time or the RP may time out the (S,G) state before the next Null-Register arrives. Thus the KAT(S,G) is set to -max(Keepalive_Period, RP_Keepalive_Period). +max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop is sent." The reason for the inconsistency is because inside packet_arrives_on_rp_tunnel() sometimes the timer is unconditionally set to Keepalive_Period when a Register-Stop is sent. =================================================================== 7) Everywhere Suggestion: Change "Upstream Join" to "Upstream-Join" (for timers). Similarly, change "Upstream Override" to "Upstream-Override" ?? =================================================================== 8) Inside Section 4.10.3: "null register" -> "Null-Register" =================================================================== 9) In Section 4.10 paragraph "Checksum" replace "the length of the PIM header" with "8", because "PIM header" could be ambiguous (e.g., is it 4 or 8). Also, what about the IPv6 pseudo-header source and destination address. Are they set to the PIM control message source and destination address as well? =================================================================== 10) Section 4.6.1 (S,G) Assert Message State Machine Why part of the "In I Am Assert Loser (L) State" table is listed first? Shoudn't it be moved a bit down together with the rest of the "Loser State" table. =================================================================== 11) Maybe replace "See Join(*,*,RP) to MRIB.next_hop(RP)" with "See Join(*,*,RP) to NBR(RPF_interface(RP), MRIB.next_hop(RP))" Similar change needed for "See Prune(*,*,RP) to MRIB.next_hop(RP)". =================================================================== 12) Maybe change "MRIB.next_hop(RP) GenID changes" to "NBR(RPF_interface(RP), MRIB.next_hop(RP) GenID changes" ?? =================================================================== _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Apr 2 14:43:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24405 for ; Fri, 2 Apr 2004 14:43:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9RzU-0005Wk-SF; Fri, 02 Apr 2004 11:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9P7p-0000V0-3o for pim@optimus.ietf.org; Fri, 02 Apr 2004 08:54:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09139 for ; Fri, 2 Apr 2004 08:54:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9P7m-0001yd-00 for pim@ietf.org; Fri, 02 Apr 2004 08:54:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9P6z-0001s8-00 for pim@ietf.org; Fri, 02 Apr 2004 08:53:35 -0500 Received: from nn4.excitenetwork.com ([207.159.120.58] helo=xprdmailfe15.nwk.excite.com) by ietf-mx with esmtp (Exim 4.12) id 1B9P63-0001kz-00 for pim@ietf.org; Fri, 02 Apr 2004 08:52:35 -0500 Received: by xprdmailfe15.nwk.excite.com (Postfix, from userid 110) id 646EBB6D6; Fri, 2 Apr 2004 08:52:03 -0500 (EST) To: pim@ietf.org Received: from [219.98.50.166] by xprdmailfe15.nwk.excite.com via HTTP; Fri, 02 Apr 2004 08:52:03 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = 6e2dc33f034c00985b8b5821e46094ce Reply-To: aruts@excite.com From: "" MIME-Version: 1.0 X-Sender: aruts@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20040402135203.646EBB6D6@xprdmailfe15.nwk.excite.com> Date: Fri, 2 Apr 2004 08:52:03 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,LINES_OF_YELLING, LINES_OF_YELLING_2,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [pim] Hash function for RP selection Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I would like to have a clarfication regarding RP selection. For example if I have the following RP SET list: 239.1.1.0/24 10.10.1.3 (PRIORITY = 5) 10.10.1.2 (PRIORITY = 4) 10.10.1.1 (PRIORITY = 3) 239.1.0.0/16 10.10.1.2 (PRIORITY = 10) 10.10.1.3 (PRIORITY = 10) For the group 239.1.1.1 the longest match would be 239.1.1.0 and for group 239.1.2.1 it would match 239.1.0.0. According to rfc 2362: From the RPs with the highest priority (i.e. lowest `Priority' value), the candidate with the highest resulting value is then chosen as the RP for that group, and its identity and hash value are stored with the entry created. Now for 239.1.1.1 10.10.1.1 should be selected as RP simply because it has the lowest priority, so the rfc statement doesn`t make sense to me. We have found an RP with the lowest priority so why is the second step required.I thought hash value is required only if priorities are same (to resolve the tie). To summarize: From the C-RP set list of the corresponding group prefix choose the C-RP with lowest Priority. If priority is same compute hash value and the RP is chosen based on the highest hash value. If both priority and hash values are equal, the C-RP with highest IP address becomes the RP. Please let me know if I am missing something. Thanks, Arut _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Apr 2 16:44:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03302 for ; Fri, 2 Apr 2004 16:44:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WSU-0001kW-Hz for pim-archive@odin.ietf.org; Fri, 02 Apr 2004 16:44:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LiEk4006725 for pim-archive@odin.ietf.org; Fri, 2 Apr 2004 16:44:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UaU-0000fH-JL for pim-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 14:44:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24455 for ; Fri, 2 Apr 2004 14:44:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9UaR-0003ks-00 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 14:44:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9UZR-0003bO-00 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 14:43:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9UYm-0003Sw-00 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 14:42:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9RzU-0005Wk-SF; Fri, 02 Apr 2004 11:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9P7p-0000V0-3o for pim@optimus.ietf.org; Fri, 02 Apr 2004 08:54:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09139 for ; Fri, 2 Apr 2004 08:54:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9P7m-0001yd-00 for pim@ietf.org; Fri, 02 Apr 2004 08:54:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9P6z-0001s8-00 for pim@ietf.org; Fri, 02 Apr 2004 08:53:35 -0500 Received: from nn4.excitenetwork.com ([207.159.120.58] helo=xprdmailfe15.nwk.excite.com) by ietf-mx with esmtp (Exim 4.12) id 1B9P63-0001kz-00 for pim@ietf.org; Fri, 02 Apr 2004 08:52:35 -0500 Received: by xprdmailfe15.nwk.excite.com (Postfix, from userid 110) id 646EBB6D6; Fri, 2 Apr 2004 08:52:03 -0500 (EST) To: pim@ietf.org Received: from [219.98.50.166] by xprdmailfe15.nwk.excite.com via HTTP; Fri, 02 Apr 2004 08:52:03 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = 6e2dc33f034c00985b8b5821e46094ce Reply-To: aruts@excite.com From: "" MIME-Version: 1.0 X-Sender: aruts@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20040402135203.646EBB6D6@xprdmailfe15.nwk.excite.com> Date: Fri, 2 Apr 2004 08:52:03 -0500 (EST) Content-Transfer-Encoding: 7bit Subject: [pim] Hash function for RP selection Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,LINES_OF_YELLING, LINES_OF_YELLING_2,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I would like to have a clarfication regarding RP selection. For example if I have the following RP SET list: 239.1.1.0/24 10.10.1.3 (PRIORITY = 5) 10.10.1.2 (PRIORITY = 4) 10.10.1.1 (PRIORITY = 3) 239.1.0.0/16 10.10.1.2 (PRIORITY = 10) 10.10.1.3 (PRIORITY = 10) For the group 239.1.1.1 the longest match would be 239.1.1.0 and for group 239.1.2.1 it would match 239.1.0.0. According to rfc 2362: From the RPs with the highest priority (i.e. lowest `Priority' value), the candidate with the highest resulting value is then chosen as the RP for that group, and its identity and hash value are stored with the entry created. Now for 239.1.1.1 10.10.1.1 should be selected as RP simply because it has the lowest priority, so the rfc statement doesn`t make sense to me. We have found an RP with the lowest priority so why is the second step required.I thought hash value is required only if priorities are same (to resolve the tie). To summarize: From the C-RP set list of the corresponding group prefix choose the C-RP with lowest Priority. If priority is same compute hash value and the RP is chosen based on the highest hash value. If both priority and hash values are equal, the C-RP with highest IP address becomes the RP. Please let me know if I am missing something. Thanks, Arut _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Apr 2 16:46:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03513 for ; Fri, 2 Apr 2004 16:46:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WTN-0002g3-Ua; Fri, 02 Apr 2004 16:45:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Usd-0005jK-Be for pim@optimus.ietf.org; Fri, 02 Apr 2004 15:03:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25352 for ; Fri, 2 Apr 2004 15:03:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Usa-0006T9-00 for pim@ietf.org; Fri, 02 Apr 2004 15:03:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Urg-0006MO-00 for pim@ietf.org; Fri, 02 Apr 2004 15:02:09 -0500 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1B9Uqn-0006F7-00 for pim@ietf.org; Fri, 02 Apr 2004 15:01:13 -0500 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i32K19r6022310; Fri, 2 Apr 2004 12:01:11 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200404022001.i32K19r6022310@possum.icir.org> To: aruts@excite.com cc: pim@ietf.org Subject: Re: [pim] Hash function for RP selection In-Reply-To: Message from "" of "Fri, 02 Apr 2004 08:52:03 EST." <20040402135203.646EBB6D6@xprdmailfe15.nwk.excite.com> Date: Fri, 02 Apr 2004 12:01:09 -0800 From: Pavlin Radoslavov 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=none autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , > I would like to have a clarfication regarding RP selection. > > For example if I have the following RP SET list: > > 239.1.1.0/24 > 10.10.1.3 (PRIORITY = 5) > 10.10.1.2 (PRIORITY = 4) > 10.10.1.1 (PRIORITY = 3) > > > 239.1.0.0/16 > 10.10.1.2 (PRIORITY = 10) > 10.10.1.3 (PRIORITY = 10) > > For the group 239.1.1.1 the longest match would be 239.1.1.0 > and for group 239.1.2.1 it would match 239.1.0.0. > > According to rfc 2362: > > From the RPs with the highest priority (i.e. lowest > `Priority' value), the candidate with the highest resulting > value is then chosen as the RP for that group, and its identity > and hash value are stored with the entry created. > > Now for 239.1.1.1 10.10.1.1 should be selected as RP simply because > it has the lowest priority, so the rfc statement doesn`t make sense > to me. We have found an RP with the lowest priority so why is the > second step required.I thought hash value is required only if > priorities are same (to resolve the tie). > > To summarize: > > From the C-RP set list of the corresponding group prefix > choose the C-RP with lowest Priority. > > If priority is same compute hash value and the RP is chosen based > on the highest hash value. > > If both priority and hash values are equal, the C-RP with highest > IP address becomes the RP. > > Please let me know if I am missing something. > > Thanks, > Arut Please read Section 4.8.1. "Group-to-RP Mapping" in the lastest I-D draft-ietf-pim-sm-v2-new-09.txt It explains the process in more details. Also, please pay attention to the "Implementation note" at the end of that section. Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Apr 2 16:59:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04948 for ; Fri, 2 Apr 2004 16:59:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WgQ-0001bG-D7 for pim-archive@odin.ietf.org; Fri, 02 Apr 2004 16:58:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LwcUI006151 for pim-archive@odin.ietf.org; Fri, 2 Apr 2004 16:58:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WgQ-0001b3-7h for pim-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:58:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04781 for ; Fri, 2 Apr 2004 16:58:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WgO-0002pW-00 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 16:58:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wcf-0001zK-00 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 16:54:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaM-0001Ld-02 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:23 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WUH-0007qh-ND for pim-web-archive@ietf.org; Fri, 02 Apr 2004 16:46:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WTJ-0002dV-3C; Fri, 02 Apr 2004 16:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Uhz-00016F-St for pim@optimus.ietf.org; Fri, 02 Apr 2004 14:52:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24947 for ; Fri, 2 Apr 2004 14:52:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Uhx-000530-00 for pim@ietf.org; Fri, 02 Apr 2004 14:52:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Ugy-0004sA-00 for pim@ietf.org; Fri, 02 Apr 2004 14:51:05 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ug1-0004Z6-00 for pim@ietf.org; Fri, 02 Apr 2004 14:50:05 -0500 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 i32JnWSa017324; Fri, 2 Apr 2004 21:49:32 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i32JnWPg005473; Fri, 2 Apr 2004 21:49:32 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 2 Apr 2004 21:49:32 +0200 From: Stig Venaas To: aruts@excite.com Cc: pim@ietf.org Subject: Re: [pim] Hash function for RP selection Message-ID: <20040402194932.GA5464@sverresborg.uninett.no> References: <20040402135203.646EBB6D6@xprdmailfe15.nwk.excite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040402135203.646EBB6D6@xprdmailfe15.nwk.excite.com> User-Agent: Mutt/1.4.1i Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 On Fri, Apr 02, 2004 at 08:52:03AM -0500, aruts@excite.com wrote: > > Hi all, > > I would like to have a clarfication regarding RP selection. > > For example if I have the following RP SET list: > > 239.1.1.0/24 > 10.10.1.3 (PRIORITY = 5) > 10.10.1.2 (PRIORITY = 4) > 10.10.1.1 (PRIORITY = 3) > > > 239.1.0.0/16 > 10.10.1.2 (PRIORITY = 10) > 10.10.1.3 (PRIORITY = 10) > > For the group 239.1.1.1 the longest match would be 239.1.1.0 > and for group 239.1.2.1 it would match 239.1.0.0. > > According to rfc 2362: > > From the RPs with the highest priority (i.e. lowest > `Priority' value), the candidate with the highest resulting > value is then chosen as the RP for that group, and its identity > and hash value are stored with the entry created. > > Now for 239.1.1.1 10.10.1.1 should be selected as RP simply because > it has the lowest priority, so the rfc statement doesn`t make sense > to me. We have found an RP with the lowest priority so why is the > second step required.I thought hash value is required only if > priorities are same (to resolve the tie). The second step is to pick one of the RPs with highest priority, i.e. if there are several RPs with highest (they all have the same and highest) priority, you use the hash function and use the one with highest resulting value. Note that it says "resulting value". It's the result from the hash function, not the priority value. Stig _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Apr 2 16:59:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05032 for ; Fri, 2 Apr 2004 16:59:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WgY-0001dk-Ci for pim-archive@odin.ietf.org; Fri, 02 Apr 2004 16:58:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32LwkEL006298 for pim-archive@odin.ietf.org; Fri, 2 Apr 2004 16:58:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WgY-0001dT-7k for pim-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:58:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04826 for ; Fri, 2 Apr 2004 16:58:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9WgW-0002r6-00 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 16:58:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Wcm-00020h-00 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 16:54:53 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WaN-0001S5-00 for pim-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:23 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WUH-0007qg-JG for pim-web-archive@ietf.org; Fri, 02 Apr 2004 16:46:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WTN-0002g3-Ua; Fri, 02 Apr 2004 16:45:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Usd-0005jK-Be for pim@optimus.ietf.org; Fri, 02 Apr 2004 15:03:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25352 for ; Fri, 2 Apr 2004 15:03:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Usa-0006T9-00 for pim@ietf.org; Fri, 02 Apr 2004 15:03:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Urg-0006MO-00 for pim@ietf.org; Fri, 02 Apr 2004 15:02:09 -0500 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1B9Uqn-0006F7-00 for pim@ietf.org; Fri, 02 Apr 2004 15:01:13 -0500 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i32K19r6022310; Fri, 2 Apr 2004 12:01:11 -0800 (PST) (envelope-from pavlin@possum.icir.org) Message-Id: <200404022001.i32K19r6022310@possum.icir.org> To: aruts@excite.com cc: pim@ietf.org Subject: Re: [pim] Hash function for RP selection In-Reply-To: Message from "" of "Fri, 02 Apr 2004 08:52:03 EST." <20040402135203.646EBB6D6@xprdmailfe15.nwk.excite.com> Date: Fri, 02 Apr 2004 12:01:09 -0800 From: Pavlin Radoslavov Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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=none autolearn=no version=2.60 > I would like to have a clarfication regarding RP selection. > > For example if I have the following RP SET list: > > 239.1.1.0/24 > 10.10.1.3 (PRIORITY = 5) > 10.10.1.2 (PRIORITY = 4) > 10.10.1.1 (PRIORITY = 3) > > > 239.1.0.0/16 > 10.10.1.2 (PRIORITY = 10) > 10.10.1.3 (PRIORITY = 10) > > For the group 239.1.1.1 the longest match would be 239.1.1.0 > and for group 239.1.2.1 it would match 239.1.0.0. > > According to rfc 2362: > > From the RPs with the highest priority (i.e. lowest > `Priority' value), the candidate with the highest resulting > value is then chosen as the RP for that group, and its identity > and hash value are stored with the entry created. > > Now for 239.1.1.1 10.10.1.1 should be selected as RP simply because > it has the lowest priority, so the rfc statement doesn`t make sense > to me. We have found an RP with the lowest priority so why is the > second step required.I thought hash value is required only if > priorities are same (to resolve the tie). > > To summarize: > > From the C-RP set list of the corresponding group prefix > choose the C-RP with lowest Priority. > > If priority is same compute hash value and the RP is chosen based > on the highest hash value. > > If both priority and hash values are equal, the C-RP with highest > IP address becomes the RP. > > Please let me know if I am missing something. > > Thanks, > Arut Please read Section 4.8.1. "Group-to-RP Mapping" in the lastest I-D draft-ietf-pim-sm-v2-new-09.txt It explains the process in more details. Also, please pay attention to the "Implementation note" at the end of that section. Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Apr 2 17:34:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03514 for ; Fri, 2 Apr 2004 16:46:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WTJ-0002dV-3C; Fri, 02 Apr 2004 16:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Uhz-00016F-St for pim@optimus.ietf.org; Fri, 02 Apr 2004 14:52:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24947 for ; Fri, 2 Apr 2004 14:52:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Uhx-000530-00 for pim@ietf.org; Fri, 02 Apr 2004 14:52:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Ugy-0004sA-00 for pim@ietf.org; Fri, 02 Apr 2004 14:51:05 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ug1-0004Z6-00 for pim@ietf.org; Fri, 02 Apr 2004 14:50:05 -0500 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 i32JnWSa017324; Fri, 2 Apr 2004 21:49:32 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i32JnWPg005473; Fri, 2 Apr 2004 21:49:32 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 2 Apr 2004 21:49:32 +0200 From: Stig Venaas To: aruts@excite.com Cc: pim@ietf.org Subject: Re: [pim] Hash function for RP selection Message-ID: <20040402194932.GA5464@sverresborg.uninett.no> References: <20040402135203.646EBB6D6@xprdmailfe15.nwk.excite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040402135203.646EBB6D6@xprdmailfe15.nwk.excite.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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , On Fri, Apr 02, 2004 at 08:52:03AM -0500, aruts@excite.com wrote: > > Hi all, > > I would like to have a clarfication regarding RP selection. > > For example if I have the following RP SET list: > > 239.1.1.0/24 > 10.10.1.3 (PRIORITY = 5) > 10.10.1.2 (PRIORITY = 4) > 10.10.1.1 (PRIORITY = 3) > > > 239.1.0.0/16 > 10.10.1.2 (PRIORITY = 10) > 10.10.1.3 (PRIORITY = 10) > > For the group 239.1.1.1 the longest match would be 239.1.1.0 > and for group 239.1.2.1 it would match 239.1.0.0. > > According to rfc 2362: > > From the RPs with the highest priority (i.e. lowest > `Priority' value), the candidate with the highest resulting > value is then chosen as the RP for that group, and its identity > and hash value are stored with the entry created. > > Now for 239.1.1.1 10.10.1.1 should be selected as RP simply because > it has the lowest priority, so the rfc statement doesn`t make sense > to me. We have found an RP with the lowest priority so why is the > second step required.I thought hash value is required only if > priorities are same (to resolve the tie). The second step is to pick one of the RPs with highest priority, i.e. if there are several RPs with highest (they all have the same and highest) priority, you use the hash function and use the one with highest resulting value. Note that it says "resulting value". It's the result from the hash function, not the priority value. Stig _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Tue Apr 6 21:21:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19648 for ; Tue, 6 Apr 2004 21:21:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1iY-0008Er-3r; Tue, 06 Apr 2004 21:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1hc-0007yy-2f for pim@optimus.ietf.org; Tue, 06 Apr 2004 21:18:04 -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 VAA19413 for ; Tue, 6 Apr 2004 21:18:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB1hZ-0007FE-00 for pim@ietf.org; Tue, 06 Apr 2004 21:18:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB0cg-0000sH-00 for pim@ietf.org; Tue, 06 Apr 2004 20:08:56 -0400 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1BAzy3-0002AF-00 for pim@ietf.org; Tue, 06 Apr 2004 19:26:56 -0400 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i36NQrr6084075; Tue, 6 Apr 2004 16:26:53 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200404062326.i36NQrr6084075@possum.icir.org> To: Pekka Savola cc: pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: Message from Pekka Savola of "Sat, 20 Mar 2004 17:37:56 +0200." Date: Tue, 06 Apr 2004 16:26:53 -0700 From: Pavlin Radoslavov 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=none autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , [Note: a reply to a 2 weeks old email] I will reply only to Issue 2 below. I will leave other folks to reply re. Issue 1. > Hi, > > (I read through the pim spec, and I'll be writing up my comments in a > couple of days .. but there's one biggest issue which I wanted to > raise immediately..) > > Section 4.7 defines the behaviour of PIM-SM router which is > interfacing a different multicast routing protocol, referring to RFC > 2715. > > Issue 1: the whole point may be moot because RFC 2715 is > Informational, and this is aimed aa Standards Track; there can be no > normative reference to it. > > Possible resolution: decrease the weight of RFC 2715 in this document, > and move RFC 2715 off to informative references. > > Issue 2: the wildcard receiver requirement (see below) is completely > unrealistic, could be an enermous DoS component, and is completely > inpractical -- not to mention failing to work with mechanisms like > SSM, Embedded-RP or Bidir-PIM (?) -- where a random edge router does > not know about all the groups in a domain. Imagine a case where you > could associate with a PIM-SM router, and act as a wildcard receiver. > Instand multicast DoS as the PIM-SM router would have to join to every > source in the Internet!!!! > > Suggestion: discuss this requirement. My feeling is that it should be > deprecated (with caveats, and describing its limitations) or removed > completely. The (*,*,RP) Join is generated only by the border routers for the RPs within their own domain. In other words, the (*,*,RP) Join is not carried across domains. Hence, you cannot use it for inter-domain DoS attacks. Within a domain, the assumption is that you trust your own routers for the (*,*,RP) Join generation (among all other stuff), hence it can't be used for intra-domain DoS attack either. Pavlin > ============ > 4.7.2. Sources Internal to the PIM-SM Domain > > A PMBR needs to ensure that traffic from sources inside the PIM-SM > domain reaches receivers outside the domain. Using terminology from RFC > 2715, there are two possible scenarios for this: > > o Another component of the PMBR is a wildcard receiver. In this case > the PIM-SM component of the PMBR must ensure that traffic from all > internal sources reaches the PMBR until it is informed otherwise. > > o No other component of the PMBR is a wildcard receiver. In this case > the PMBR will receive explicit information as to which groups or > (source,group) pairs the external domains wish to receive. > > In the former case, the PMBR will need to send a Join(*,*,RP) to all the > RPs in the PIM-SM domain. This will cause all traffic in the domain to > reach the PMBR. The PMBR may then act as if it were a DR with directly > connected receivers, and trigger the transition to a shortest path tree > (see Section 4.2.1). > > In the latter case, the PMBR will not need to send Join(*,*,RP) > messages. However the PMBR will still need to act as a DR with directly > connected receivers on behalf of the external receivers in terms of > ========= > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Apr 6 23:35:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00455 for ; Tue, 6 Apr 2004 23:35:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB3q7-00086D-IB for pim-archive@odin.ietf.org; Tue, 06 Apr 2004 23:34:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i373YxAo031134 for pim-archive@odin.ietf.org; Tue, 6 Apr 2004 23:34:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB3q7-000865-9M for pim-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 23:34:59 -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 XAA00295 for ; Tue, 6 Apr 2004 23:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB3q5-00062v-00 for pim-web-archive@ietf.org; Tue, 06 Apr 2004 23:34:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB2ZO-00074i-00 for pim-web-archive@ietf.org; Tue, 06 Apr 2004 22:13:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB1yl-00013y-01 for pim-web-archive@ietf.org; Tue, 06 Apr 2004 21:35:47 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB1kD-0006ii-By for pim-web-archive@ietf.org; Tue, 06 Apr 2004 21:20:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1iY-0008Er-3r; Tue, 06 Apr 2004 21:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1hc-0007yy-2f for pim@optimus.ietf.org; Tue, 06 Apr 2004 21:18:04 -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 VAA19413 for ; Tue, 6 Apr 2004 21:18:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB1hZ-0007FE-00 for pim@ietf.org; Tue, 06 Apr 2004 21:18:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB0cg-0000sH-00 for pim@ietf.org; Tue, 06 Apr 2004 20:08:56 -0400 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1BAzy3-0002AF-00 for pim@ietf.org; Tue, 06 Apr 2004 19:26:56 -0400 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i36NQrr6084075; Tue, 6 Apr 2004 16:26:53 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200404062326.i36NQrr6084075@possum.icir.org> To: Pekka Savola cc: pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: Message from Pekka Savola of "Sat, 20 Mar 2004 17:37:56 +0200." Date: Tue, 06 Apr 2004 16:26:53 -0700 From: Pavlin Radoslavov Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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=none autolearn=no version=2.60 [Note: a reply to a 2 weeks old email] I will reply only to Issue 2 below. I will leave other folks to reply re. Issue 1. > Hi, > > (I read through the pim spec, and I'll be writing up my comments in a > couple of days .. but there's one biggest issue which I wanted to > raise immediately..) > > Section 4.7 defines the behaviour of PIM-SM router which is > interfacing a different multicast routing protocol, referring to RFC > 2715. > > Issue 1: the whole point may be moot because RFC 2715 is > Informational, and this is aimed aa Standards Track; there can be no > normative reference to it. > > Possible resolution: decrease the weight of RFC 2715 in this document, > and move RFC 2715 off to informative references. > > Issue 2: the wildcard receiver requirement (see below) is completely > unrealistic, could be an enermous DoS component, and is completely > inpractical -- not to mention failing to work with mechanisms like > SSM, Embedded-RP or Bidir-PIM (?) -- where a random edge router does > not know about all the groups in a domain. Imagine a case where you > could associate with a PIM-SM router, and act as a wildcard receiver. > Instand multicast DoS as the PIM-SM router would have to join to every > source in the Internet!!!! > > Suggestion: discuss this requirement. My feeling is that it should be > deprecated (with caveats, and describing its limitations) or removed > completely. The (*,*,RP) Join is generated only by the border routers for the RPs within their own domain. In other words, the (*,*,RP) Join is not carried across domains. Hence, you cannot use it for inter-domain DoS attacks. Within a domain, the assumption is that you trust your own routers for the (*,*,RP) Join generation (among all other stuff), hence it can't be used for intra-domain DoS attack either. Pavlin > ============ > 4.7.2. Sources Internal to the PIM-SM Domain > > A PMBR needs to ensure that traffic from sources inside the PIM-SM > domain reaches receivers outside the domain. Using terminology from RFC > 2715, there are two possible scenarios for this: > > o Another component of the PMBR is a wildcard receiver. In this case > the PIM-SM component of the PMBR must ensure that traffic from all > internal sources reaches the PMBR until it is informed otherwise. > > o No other component of the PMBR is a wildcard receiver. In this case > the PMBR will receive explicit information as to which groups or > (source,group) pairs the external domains wish to receive. > > In the former case, the PMBR will need to send a Join(*,*,RP) to all the > RPs in the PIM-SM domain. This will cause all traffic in the domain to > reach the PMBR. The PMBR may then act as if it were a DR with directly > connected receivers, and trigger the transition to a shortest path tree > (see Section 4.2.1). > > In the latter case, the PMBR will not need to send Join(*,*,RP) > messages. However the PMBR will still need to act as a DR with directly > connected receivers on behalf of the external receivers in terms of > ========= > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > 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-admin@ietf.org Wed Apr 7 04:37:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25706 for ; Wed, 7 Apr 2004 04:37:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8YQ-0005BF-S4; Wed, 07 Apr 2004 04:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8Xp-00057W-Pd for pim@optimus.ietf.org; Wed, 07 Apr 2004 04:36:25 -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 EAA25401 for ; Wed, 7 Apr 2004 04:36:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB8Xm-0002NZ-00 for pim@ietf.org; Wed, 07 Apr 2004 04:36:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB7I3-00020V-00 for pim@ietf.org; Wed, 07 Apr 2004 03:16:04 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB6KP-00014H-00 for pim@ietf.org; Wed, 07 Apr 2004 02:14:25 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i376Djh01516; Wed, 7 Apr 2004 09:13:48 +0300 Date: Wed, 7 Apr 2004 09:13:45 +0300 (EEST) From: Pekka Savola To: Pavlin Radoslavov cc: pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: <200404062326.i36NQrr6084075@possum.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , On Tue, 6 Apr 2004, Pavlin Radoslavov wrote: > > Issue 2: the wildcard receiver requirement (see below) is completely > > unrealistic, could be an enermous DoS component, and is completely > > inpractical -- not to mention failing to work with mechanisms like > > SSM, Embedded-RP or Bidir-PIM (?) -- where a random edge router does > > not know about all the groups in a domain. Imagine a case where you > > could associate with a PIM-SM router, and act as a wildcard receiver. > > Instand multicast DoS as the PIM-SM router would have to join to every > > source in the Internet!!!! > > > > Suggestion: discuss this requirement. My feeling is that it should be > > deprecated (with caveats, and describing its limitations) or removed > > completely. > > > The (*,*,RP) Join is generated only by the border routers for the > RPs within their own domain. In other words, the (*,*,RP) Join is > not carried across domains. Hence, you cannot use it for > inter-domain DoS attacks. > > Within a domain, the assumption is that you trust your own routers > for the (*,*,RP) Join generation (among all other stuff), hence it > can't be used for intra-domain DoS attack either. How about SSM where you don't have any RPs and no (similar) multicast domain? The wildcard receiver argument applies equally to that as well, AFAICS. What about embedded-RP (or maybe also bidir-PIM, not sure), where the multicast domain practically includes all of the Internet? (with multicast domain I refer to the area for which the group is active on under one RP or no RP at all (SSM).) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Apr 7 07:06:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07921 for ; Wed, 7 Apr 2004 07:06:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAt5-0007i1-HO for pim-archive@odin.ietf.org; Wed, 07 Apr 2004 07:06:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37B6VxG029630 for pim-archive@odin.ietf.org; Wed, 7 Apr 2004 07:06:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAt5-0007hn-6u for pim-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 07:06:31 -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 HAA07794 for ; Wed, 7 Apr 2004 07:06:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBAt0-0003p9-00 for pim-web-archive@ietf.org; Wed, 07 Apr 2004 07:06:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB9ZH-00033Y-00 for pim-web-archive@ietf.org; Wed, 07 Apr 2004 05:42:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB8Ym-0002YN-00 for pim-web-archive@ietf.org; Wed, 07 Apr 2004 04:37:24 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB8Yo-00046d-Cq for pim-web-archive@ietf.org; Wed, 07 Apr 2004 04:37:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8YQ-0005BF-S4; Wed, 07 Apr 2004 04:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB8Xp-00057W-Pd for pim@optimus.ietf.org; Wed, 07 Apr 2004 04:36:25 -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 EAA25401 for ; Wed, 7 Apr 2004 04:36:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB8Xm-0002NZ-00 for pim@ietf.org; Wed, 07 Apr 2004 04:36:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB7I3-00020V-00 for pim@ietf.org; Wed, 07 Apr 2004 03:16:04 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB6KP-00014H-00 for pim@ietf.org; Wed, 07 Apr 2004 02:14:25 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i376Djh01516; Wed, 7 Apr 2004 09:13:48 +0300 Date: Wed, 7 Apr 2004 09:13:45 +0300 (EEST) From: Pekka Savola To: Pavlin Radoslavov cc: pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: <200404062326.i36NQrr6084075@possum.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 On Tue, 6 Apr 2004, Pavlin Radoslavov wrote: > > Issue 2: the wildcard receiver requirement (see below) is completely > > unrealistic, could be an enermous DoS component, and is completely > > inpractical -- not to mention failing to work with mechanisms like > > SSM, Embedded-RP or Bidir-PIM (?) -- where a random edge router does > > not know about all the groups in a domain. Imagine a case where you > > could associate with a PIM-SM router, and act as a wildcard receiver. > > Instand multicast DoS as the PIM-SM router would have to join to every > > source in the Internet!!!! > > > > Suggestion: discuss this requirement. My feeling is that it should be > > deprecated (with caveats, and describing its limitations) or removed > > completely. > > > The (*,*,RP) Join is generated only by the border routers for the > RPs within their own domain. In other words, the (*,*,RP) Join is > not carried across domains. Hence, you cannot use it for > inter-domain DoS attacks. > > Within a domain, the assumption is that you trust your own routers > for the (*,*,RP) Join generation (among all other stuff), hence it > can't be used for intra-domain DoS attack either. How about SSM where you don't have any RPs and no (similar) multicast domain? The wildcard receiver argument applies equally to that as well, AFAICS. What about embedded-RP (or maybe also bidir-PIM, not sure), where the multicast domain practically includes all of the Internet? (with multicast domain I refer to the area for which the group is active on under one RP or no RP at all (SSM).) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Apr 7 07:19:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10189 for ; Wed, 7 Apr 2004 07:19:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBB5B-0003n2-12; Wed, 07 Apr 2004 07:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBB4G-0003cE-Q5 for pim@optimus.ietf.org; Wed, 07 Apr 2004 07:18:04 -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 HAA09897 for ; Wed, 7 Apr 2004 07:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBB4G-0005b5-00 for pim@ietf.org; Wed, 07 Apr 2004 07:18:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB9wz-0005zV-00 for pim@ietf.org; Wed, 07 Apr 2004 06:06:30 -0400 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1BB90L-0006T1-00 for pim@ietf.org; Wed, 07 Apr 2004 05:05:53 -0400 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i3795sr6088388; Wed, 7 Apr 2004 02:05:54 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200404070905.i3795sr6088388@possum.icir.org> To: Pekka Savola cc: Pavlin Radoslavov , pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: Message from Pekka Savola of "Wed, 07 Apr 2004 09:13:45 +0300." Date: Wed, 07 Apr 2004 02:05:54 -0700 From: Pavlin Radoslavov 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=none autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , > On Tue, 6 Apr 2004, Pavlin Radoslavov wrote: > > > Issue 2: the wildcard receiver requirement (see below) is completely > > > unrealistic, could be an enermous DoS component, and is completely > > > inpractical -- not to mention failing to work with mechanisms like > > > SSM, Embedded-RP or Bidir-PIM (?) -- where a random edge router does > > > not know about all the groups in a domain. Imagine a case where you > > > could associate with a PIM-SM router, and act as a wildcard receiver. > > > Instand multicast DoS as the PIM-SM router would have to join to every > > > source in the Internet!!!! > > > > > > Suggestion: discuss this requirement. My feeling is that it should be > > > deprecated (with caveats, and describing its limitations) or removed > > > completely. > > > > > > The (*,*,RP) Join is generated only by the border routers for the > > RPs within their own domain. In other words, the (*,*,RP) Join is > > not carried across domains. Hence, you cannot use it for > > inter-domain DoS attacks. > > > > Within a domain, the assumption is that you trust your own routers > > for the (*,*,RP) Join generation (among all other stuff), hence it > > can't be used for intra-domain DoS attack either. > > How about SSM where you don't have any RPs and no (similar) multicast > domain? The wildcard receiver argument applies equally to that as > well, AFAICS. The (*,*,RP) Joins don't apply for the SSM multicast address range simply because the RPs exclude that address range. > What about embedded-RP (or maybe also bidir-PIM, not sure), where the > multicast domain practically includes all of the Internet? > > (with multicast domain I refer to the area for which the group is > active on under one RP or no RP at all (SSM).) Still, the (*,*,RP) Joins don't cross domain boundaries (and here by domain I mean entities as AS). They are used by the border routers of a domain only to pull-out the data traffic from within that domain when that traffic doesn't know how to reach other domains on its own. Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Apr 7 09:49:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22477 for ; Wed, 7 Apr 2004 09:49:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDQ5-0007Ce-OQ for pim-archive@odin.ietf.org; Wed, 07 Apr 2004 09:48:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37DmjaD027689 for pim-archive@odin.ietf.org; Wed, 7 Apr 2004 09:48:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDQ5-0007CW-Gx for pim-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 09:48:45 -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 JAA22363 for ; Wed, 7 Apr 2004 09:48:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBDQ3-0006Ud-00 for pim-web-archive@ietf.org; Wed, 07 Apr 2004 09:48:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBCLL-00072E-00 for pim-web-archive@ietf.org; Wed, 07 Apr 2004 08:39:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBBIO-00078M-00 for pim-web-archive@ietf.org; Wed, 07 Apr 2004 07:32:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBB5B-0003n2-12; Wed, 07 Apr 2004 07:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBB4G-0003cE-Q5 for pim@optimus.ietf.org; Wed, 07 Apr 2004 07:18:04 -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 HAA09897 for ; Wed, 7 Apr 2004 07:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBB4G-0005b5-00 for pim@ietf.org; Wed, 07 Apr 2004 07:18:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB9wz-0005zV-00 for pim@ietf.org; Wed, 07 Apr 2004 06:06:30 -0400 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1BB90L-0006T1-00 for pim@ietf.org; Wed, 07 Apr 2004 05:05:53 -0400 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i3795sr6088388; Wed, 7 Apr 2004 02:05:54 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200404070905.i3795sr6088388@possum.icir.org> To: Pekka Savola cc: Pavlin Radoslavov , pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: Message from Pekka Savola of "Wed, 07 Apr 2004 09:13:45 +0300." Date: Wed, 07 Apr 2004 02:05:54 -0700 From: Pavlin Radoslavov Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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=none autolearn=no version=2.60 > On Tue, 6 Apr 2004, Pavlin Radoslavov wrote: > > > Issue 2: the wildcard receiver requirement (see below) is completely > > > unrealistic, could be an enermous DoS component, and is completely > > > inpractical -- not to mention failing to work with mechanisms like > > > SSM, Embedded-RP or Bidir-PIM (?) -- where a random edge router does > > > not know about all the groups in a domain. Imagine a case where you > > > could associate with a PIM-SM router, and act as a wildcard receiver. > > > Instand multicast DoS as the PIM-SM router would have to join to every > > > source in the Internet!!!! > > > > > > Suggestion: discuss this requirement. My feeling is that it should be > > > deprecated (with caveats, and describing its limitations) or removed > > > completely. > > > > > > The (*,*,RP) Join is generated only by the border routers for the > > RPs within their own domain. In other words, the (*,*,RP) Join is > > not carried across domains. Hence, you cannot use it for > > inter-domain DoS attacks. > > > > Within a domain, the assumption is that you trust your own routers > > for the (*,*,RP) Join generation (among all other stuff), hence it > > can't be used for intra-domain DoS attack either. > > How about SSM where you don't have any RPs and no (similar) multicast > domain? The wildcard receiver argument applies equally to that as > well, AFAICS. The (*,*,RP) Joins don't apply for the SSM multicast address range simply because the RPs exclude that address range. > What about embedded-RP (or maybe also bidir-PIM, not sure), where the > multicast domain practically includes all of the Internet? > > (with multicast domain I refer to the area for which the group is > active on under one RP or no RP at all (SSM).) Still, the (*,*,RP) Joins don't cross domain boundaries (and here by domain I mean entities as AS). They are used by the border routers of a domain only to pull-out the data traffic from within that domain when that traffic doesn't know how to reach other domains on its own. Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Thu Apr 8 20:26:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15265 for ; Thu, 8 Apr 2004 20:26:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjq2-00032n-NV; Thu, 08 Apr 2004 20:25:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBj0B-0005xX-8T for pim@optimus.ietf.org; Thu, 08 Apr 2004 19:32:07 -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 TAA08880 for ; Thu, 8 Apr 2004 19:32:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBj09-00051B-00 for pim@ietf.org; Thu, 08 Apr 2004 19:32:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhsW-0004bz-00 for pim@ietf.org; Thu, 08 Apr 2004 18:20:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfr6-0003F6-00 for pim@ietf.org; Thu, 08 Apr 2004 16:10:32 -0400 Received: from netcore.fi ([193.94.160.1]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBeuv-0000Mq-WF for pim@ietf.org; Thu, 08 Apr 2004 15:10:26 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i38JA9j04354; Thu, 8 Apr 2004 22:10:10 +0300 Date: Thu, 8 Apr 2004 22:10:09 +0300 (EEST) From: Pekka Savola To: Pavlin Radoslavov cc: pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: <200404070905.i3795sr6088388@possum.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , On Wed, 7 Apr 2004, Pavlin Radoslavov wrote: > > How about SSM where you don't have any RPs and no (similar) multicast > > domain? The wildcard receiver argument applies equally to that as > > well, AFAICS. > > The (*,*,RP) Joins don't apply for the SSM multicast address range > simply because the RPs exclude that address range. You miss the point. Are you saying that PIM-SSM does not need to interoperate with other multicast routing protocols, as described in section 4.7? This is orhogonal to whether (*,*,RP) is relevant or not in SSM, as that is just a specification detail. I'm interested in more high-level issues. > > What about embedded-RP (or maybe also bidir-PIM, not sure), where the > > multicast domain practically includes all of the Internet? > > > > (with multicast domain I refer to the area for which the group is > > active on under one RP or no RP at all (SSM).) > > Still, the (*,*,RP) Joins don't cross domain boundaries (and here by > domain I mean entities as AS). Do you mean that such a join would be blocked at the border of the PIM domain (AFAIK not -- one only blocks BSR messages?), for example if the routers along the path were manually configured to use out-of-domain RP? > They are used by the border routers of a domain only to pull-out the > data traffic from within that domain when that traffic doesn't know > how to reach other domains on its own. The problem here is that "domain" is sufficiently ill-defined concept to make this "Wildcard receiver" feasible. What is a domain when you want to "wildcard receive" all PIM-SSM sessions in the domain? How is that done? For that matter, what is the domain when you use embedded-RP where the you practically have only one domain per group? Equally impossible considitions to satisfy. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Thu Apr 8 21:06:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18541 for ; Thu, 8 Apr 2004 21:06:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkT4-0001XI-8b for pim-archive@odin.ietf.org; Thu, 08 Apr 2004 21:06:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39162w3005887 for pim-archive@odin.ietf.org; Thu, 8 Apr 2004 21:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkT3-0001VD-Ih for pim-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:06:02 -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 VAA18455 for ; Thu, 8 Apr 2004 21:05:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkT0-00000t-00 for pim-web-archive@ietf.org; Thu, 08 Apr 2004 21:05:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkDh-0005Rq-00 for pim-web-archive@ietf.org; Thu, 08 Apr 2004 20:50:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBjqd-0002hL-00 for pim-web-archive@ietf.org; Thu, 08 Apr 2004 20:26:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjq2-00032n-NV; Thu, 08 Apr 2004 20:25:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBj0B-0005xX-8T for pim@optimus.ietf.org; Thu, 08 Apr 2004 19:32:07 -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 TAA08880 for ; Thu, 8 Apr 2004 19:32:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBj09-00051B-00 for pim@ietf.org; Thu, 08 Apr 2004 19:32:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhsW-0004bz-00 for pim@ietf.org; Thu, 08 Apr 2004 18:20:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfr6-0003F6-00 for pim@ietf.org; Thu, 08 Apr 2004 16:10:32 -0400 Received: from netcore.fi ([193.94.160.1]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBeuv-0000Mq-WF for pim@ietf.org; Thu, 08 Apr 2004 15:10:26 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i38JA9j04354; Thu, 8 Apr 2004 22:10:10 +0300 Date: Thu, 8 Apr 2004 22:10:09 +0300 (EEST) From: Pekka Savola To: Pavlin Radoslavov cc: pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: <200404070905.i3795sr6088388@possum.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 On Wed, 7 Apr 2004, Pavlin Radoslavov wrote: > > How about SSM where you don't have any RPs and no (similar) multicast > > domain? The wildcard receiver argument applies equally to that as > > well, AFAICS. > > The (*,*,RP) Joins don't apply for the SSM multicast address range > simply because the RPs exclude that address range. You miss the point. Are you saying that PIM-SSM does not need to interoperate with other multicast routing protocols, as described in section 4.7? This is orhogonal to whether (*,*,RP) is relevant or not in SSM, as that is just a specification detail. I'm interested in more high-level issues. > > What about embedded-RP (or maybe also bidir-PIM, not sure), where the > > multicast domain practically includes all of the Internet? > > > > (with multicast domain I refer to the area for which the group is > > active on under one RP or no RP at all (SSM).) > > Still, the (*,*,RP) Joins don't cross domain boundaries (and here by > domain I mean entities as AS). Do you mean that such a join would be blocked at the border of the PIM domain (AFAIK not -- one only blocks BSR messages?), for example if the routers along the path were manually configured to use out-of-domain RP? > They are used by the border routers of a domain only to pull-out the > data traffic from within that domain when that traffic doesn't know > how to reach other domains on its own. The problem here is that "domain" is sufficiently ill-defined concept to make this "Wildcard receiver" feasible. What is a domain when you want to "wildcard receive" all PIM-SSM sessions in the domain? How is that done? For that matter, what is the domain when you use embedded-RP where the you practically have only one domain per group? Equally impossible considitions to satisfy. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Apr 9 03:25:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15992 for ; Fri, 9 Apr 2004 03:25:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBqNq-0002dp-CN; Fri, 09 Apr 2004 03:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBqNQ-0002co-Hj for pim@optimus.ietf.org; Fri, 09 Apr 2004 03:24:36 -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 DAA15960 for ; Fri, 9 Apr 2004 03:24:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBqNN-0002E3-00 for pim@ietf.org; Fri, 09 Apr 2004 03:24:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBqJg-00023r-00 for pim@ietf.org; Fri, 09 Apr 2004 03:20:44 -0400 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1BBqGb-0001rd-00 for pim@ietf.org; Fri, 09 Apr 2004 03:17:33 -0400 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i397HLr6008816; Fri, 9 Apr 2004 00:17:21 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200404090717.i397HLr6008816@possum.icir.org> To: Pekka Savola cc: Pavlin Radoslavov , pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: Message from Pekka Savola of "Thu, 08 Apr 2004 22:10:09 +0300." Date: Fri, 09 Apr 2004 00:17:21 -0700 From: Pavlin Radoslavov 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=none autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , > On Wed, 7 Apr 2004, Pavlin Radoslavov wrote: > > > How about SSM where you don't have any RPs and no (similar) multicast > > > domain? The wildcard receiver argument applies equally to that as > > > well, AFAICS. > > > > The (*,*,RP) Joins don't apply for the SSM multicast address range > > simply because the RPs exclude that address range. > > You miss the point. > > Are you saying that PIM-SSM does not need to interoperate with other > multicast routing protocols, as described in section 4.7? Yes. > This is orhogonal to whether (*,*,RP) is relevant or not in SSM, as > that is just a specification detail. I'm interested in more > high-level issues. > > > > What about embedded-RP (or maybe also bidir-PIM, not sure), where the > > > multicast domain practically includes all of the Internet? > > > > > > (with multicast domain I refer to the area for which the group is > > > active on under one RP or no RP at all (SSM).) > > > > Still, the (*,*,RP) Joins don't cross domain boundaries (and here by > > domain I mean entities as AS). > > Do you mean that such a join would be blocked at the border of the PIM > domain (AFAIK not -- one only blocks BSR messages?), for example if > the routers along the path were manually configured to use > out-of-domain RP? Yes, I think that any external (*,*,RP) messages should be blocked at the border of the PIM domain. However, if you are exposing your internal RPs to routers outside of your domain then you have to make the administrative decision whether this means expanding the boundaries of your PIM domain. > > They are used by the border routers of a domain only to pull-out the > > data traffic from within that domain when that traffic doesn't know > > how to reach other domains on its own. > > The problem here is that "domain" is sufficiently ill-defined concept > to make this "Wildcard receiver" feasible. > > What is a domain when you want to "wildcard receive" all PIM-SSM > sessions in the domain? How is that done? For that matter, what is > the domain when you use embedded-RP where the you practically have > only one domain per group? Equally impossible considitions to > satisfy. You cannot use (*,*,RP) to receive the PIM-SSM sessions in the domain. The (*,*,RP) messages can be used only for ASM. In case of embedded-RP where you assume that the whole network is one single PIM-SM domain you don't need (*,*,RP). You need (*,*,RP) only when you are interconnecting a PIM-SM domain with other domains. Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Apr 9 03:31:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16160 for ; Fri, 9 Apr 2004 03:31:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBqTM-00032c-OU for pim-archive@odin.ietf.org; Fri, 09 Apr 2004 03:30:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i397UiUl011691 for pim-archive@odin.ietf.org; Fri, 9 Apr 2004 03:30:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBqTM-00032U-HI for pim-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 03:30: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 DAA16126 for ; Fri, 9 Apr 2004 03:30:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBqTK-0002kY-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 03:30:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBqRy-0002cu-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 03:29:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBqRJ-0002WZ-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 03:28:37 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBqO7-0003xb-Po for pim-web-archive@ietf.org; Fri, 09 Apr 2004 03:25:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBqNq-0002dp-CN; Fri, 09 Apr 2004 03:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBqNQ-0002co-Hj for pim@optimus.ietf.org; Fri, 09 Apr 2004 03:24:36 -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 DAA15960 for ; Fri, 9 Apr 2004 03:24:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBqNN-0002E3-00 for pim@ietf.org; Fri, 09 Apr 2004 03:24:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBqJg-00023r-00 for pim@ietf.org; Fri, 09 Apr 2004 03:20:44 -0400 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1BBqGb-0001rd-00 for pim@ietf.org; Fri, 09 Apr 2004 03:17:33 -0400 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i397HLr6008816; Fri, 9 Apr 2004 00:17:21 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200404090717.i397HLr6008816@possum.icir.org> To: Pekka Savola cc: Pavlin Radoslavov , pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: Message from Pekka Savola of "Thu, 08 Apr 2004 22:10:09 +0300." Date: Fri, 09 Apr 2004 00:17:21 -0700 From: Pavlin Radoslavov Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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=none autolearn=no version=2.60 > On Wed, 7 Apr 2004, Pavlin Radoslavov wrote: > > > How about SSM where you don't have any RPs and no (similar) multicast > > > domain? The wildcard receiver argument applies equally to that as > > > well, AFAICS. > > > > The (*,*,RP) Joins don't apply for the SSM multicast address range > > simply because the RPs exclude that address range. > > You miss the point. > > Are you saying that PIM-SSM does not need to interoperate with other > multicast routing protocols, as described in section 4.7? Yes. > This is orhogonal to whether (*,*,RP) is relevant or not in SSM, as > that is just a specification detail. I'm interested in more > high-level issues. > > > > What about embedded-RP (or maybe also bidir-PIM, not sure), where the > > > multicast domain practically includes all of the Internet? > > > > > > (with multicast domain I refer to the area for which the group is > > > active on under one RP or no RP at all (SSM).) > > > > Still, the (*,*,RP) Joins don't cross domain boundaries (and here by > > domain I mean entities as AS). > > Do you mean that such a join would be blocked at the border of the PIM > domain (AFAIK not -- one only blocks BSR messages?), for example if > the routers along the path were manually configured to use > out-of-domain RP? Yes, I think that any external (*,*,RP) messages should be blocked at the border of the PIM domain. However, if you are exposing your internal RPs to routers outside of your domain then you have to make the administrative decision whether this means expanding the boundaries of your PIM domain. > > They are used by the border routers of a domain only to pull-out the > > data traffic from within that domain when that traffic doesn't know > > how to reach other domains on its own. > > The problem here is that "domain" is sufficiently ill-defined concept > to make this "Wildcard receiver" feasible. > > What is a domain when you want to "wildcard receive" all PIM-SSM > sessions in the domain? How is that done? For that matter, what is > the domain when you use embedded-RP where the you practically have > only one domain per group? Equally impossible considitions to > satisfy. You cannot use (*,*,RP) to receive the PIM-SSM sessions in the domain. The (*,*,RP) messages can be used only for ASM. In case of embedded-RP where you assume that the whole network is one single PIM-SM domain you don't need (*,*,RP). You need (*,*,RP) only when you are interconnecting a PIM-SM domain with other domains. Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Apr 9 09:18:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26461 for ; Fri, 9 Apr 2004 09:18:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBvtR-0003Ln-VC; Fri, 09 Apr 2004 09:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBvtF-0003I8-0x for pim@optimus.ietf.org; Fri, 09 Apr 2004 09:17:49 -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 JAA26402 for ; Fri, 9 Apr 2004 09:17:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBvtC-0004Nb-00 for pim@ietf.org; Fri, 09 Apr 2004 09:17:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBvpA-0003yD-00 for pim@ietf.org; Fri, 09 Apr 2004 09:13:37 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBvfA-0003O0-00 for pim@ietf.org; Fri, 09 Apr 2004 09:03:16 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i39D2al19598; Fri, 9 Apr 2004 16:02:36 +0300 Date: Fri, 9 Apr 2004 16:02:36 +0300 (EEST) From: Pekka Savola To: Pavlin Radoslavov cc: pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: <200404090717.i397HLr6008816@possum.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , On Fri, 9 Apr 2004, Pavlin Radoslavov wrote: > > On Wed, 7 Apr 2004, Pavlin Radoslavov wrote: > > > > How about SSM where you don't have any RPs and no (similar) multicast > > > > domain? The wildcard receiver argument applies equally to that as > > > > well, AFAICS. > > > > > > The (*,*,RP) Joins don't apply for the SSM multicast address range > > > simply because the RPs exclude that address range. > > > > You miss the point. > > > > Are you saying that PIM-SSM does not need to interoperate with other > > multicast routing protocols [...] ? > > Yes. That is not apparent from section 4.7 or RFC2715, so if people agree with this, we'd *at least* need an applicability statement in sectin 4.7 stating that PIM is not interoperable in certain scenarios. > > > > What about embedded-RP (or maybe also bidir-PIM, not sure), where the > > > > multicast domain practically includes all of the Internet? > > > > > > > > (with multicast domain I refer to the area for which the group is > > > > active on under one RP or no RP at all (SSM).) > > > > > > Still, the (*,*,RP) Joins don't cross domain boundaries (and here by > > > domain I mean entities as AS). > > > > Do you mean that such a join would be blocked at the border of the PIM > > domain (AFAIK not -- one only blocks BSR messages?), for example if > > the routers along the path were manually configured to use > > out-of-domain RP? > > Yes, I think that any external (*,*,RP) messages should be blocked > at the border of the PIM domain. However, if you are exposing your > internal RPs to routers outside of your domain then you have to make > the administrative decision whether this means expanding the > boundaries of your PIM domain. Is this statement on what you believe should be done, or what is being done? I've heard of no implementations blocking these messages. It would be painful, and it is not even specified in the specification AFAICS. > > > They are used by the border routers of a domain only to pull-out the > > > data traffic from within that domain when that traffic doesn't know > > > how to reach other domains on its own. > > > > The problem here is that "domain" is sufficiently ill-defined concept > > to make this "Wildcard receiver" feasible. > > > > What is a domain when you want to "wildcard receive" all PIM-SSM > > sessions in the domain? How is that done? For that matter, what is > > the domain when you use embedded-RP where the you practically have > > only one domain per group? Equally impossible considitions to > > satisfy. > > You cannot use (*,*,RP) to receive the PIM-SSM sessions in the > domain. The (*,*,RP) messages can be used only for ASM. That much is obvious, of course. But the rules do not say that. They give an impression that interoperability is always possible, with all protocols if you follow the rules. That's what I'm arguing against; I'm saying that the rules only work with traditional PIM-SM+MSDP. They don't work with SSM. They don't work with Embedded-RP. They don't work (AFAICS) with Bidir-PIM. So is it really useful to have such rules here in the first place? Or, if it is useful, we have to add a lot more "truth in advertising" so that the readers wouldn't be let to believe the interoperability, as described in section 4.7 would be actually possible except in the traditional scenario. > In case of embedded-RP where you assume that the whole network is > one single PIM-SM domain you don't need (*,*,RP). Were you listening or are you weaseling with words :)? From 4.7.2: o Another component of the PMBR is a wildcard receiver. In this case the PIM-SM component of the PMBR must ensure that traffic from all internal sources reaches the PMBR until it is informed otherwise. .. there is no way to ensure that because you do not know about the internal sources, as there is no central intra-domain RP to keep track of all the sources. > You need (*,*,RP) only when you are interconnecting a PIM-SM domain > with other domains. I don't want to discuss whether you need (*,*,RP) or not. I want to discuss whether it is possible (or feasible, if possible) for PMBR to know about all the "internal sources" (whatever that might mean e.g. with SSM, embedded-RP or bidir). That is a must, but it's seems to be clearly impossible. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Apr 9 09:28:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26812 for ; Fri, 9 Apr 2004 09:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBw37-0003zn-0C for pim-archive@odin.ietf.org; Fri, 09 Apr 2004 09:28:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39DS0vi015359 for pim-archive@odin.ietf.org; Fri, 9 Apr 2004 09:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBw36-0003zc-Ri for pim-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 09:28:00 -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 JAA26786 for ; Fri, 9 Apr 2004 09:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBw34-00054Z-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 09:27:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBvxX-0004mx-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 09:22:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBvte-0004Pa-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 09:18:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBvtR-0003Ln-VC; Fri, 09 Apr 2004 09:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBvtF-0003I8-0x for pim@optimus.ietf.org; Fri, 09 Apr 2004 09:17:49 -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 JAA26402 for ; Fri, 9 Apr 2004 09:17:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBvtC-0004Nb-00 for pim@ietf.org; Fri, 09 Apr 2004 09:17:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBvpA-0003yD-00 for pim@ietf.org; Fri, 09 Apr 2004 09:13:37 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBvfA-0003O0-00 for pim@ietf.org; Fri, 09 Apr 2004 09:03:16 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i39D2al19598; Fri, 9 Apr 2004 16:02:36 +0300 Date: Fri, 9 Apr 2004 16:02:36 +0300 (EEST) From: Pekka Savola To: Pavlin Radoslavov cc: pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: <200404090717.i397HLr6008816@possum.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 On Fri, 9 Apr 2004, Pavlin Radoslavov wrote: > > On Wed, 7 Apr 2004, Pavlin Radoslavov wrote: > > > > How about SSM where you don't have any RPs and no (similar) multicast > > > > domain? The wildcard receiver argument applies equally to that as > > > > well, AFAICS. > > > > > > The (*,*,RP) Joins don't apply for the SSM multicast address range > > > simply because the RPs exclude that address range. > > > > You miss the point. > > > > Are you saying that PIM-SSM does not need to interoperate with other > > multicast routing protocols [...] ? > > Yes. That is not apparent from section 4.7 or RFC2715, so if people agree with this, we'd *at least* need an applicability statement in sectin 4.7 stating that PIM is not interoperable in certain scenarios. > > > > What about embedded-RP (or maybe also bidir-PIM, not sure), where the > > > > multicast domain practically includes all of the Internet? > > > > > > > > (with multicast domain I refer to the area for which the group is > > > > active on under one RP or no RP at all (SSM).) > > > > > > Still, the (*,*,RP) Joins don't cross domain boundaries (and here by > > > domain I mean entities as AS). > > > > Do you mean that such a join would be blocked at the border of the PIM > > domain (AFAIK not -- one only blocks BSR messages?), for example if > > the routers along the path were manually configured to use > > out-of-domain RP? > > Yes, I think that any external (*,*,RP) messages should be blocked > at the border of the PIM domain. However, if you are exposing your > internal RPs to routers outside of your domain then you have to make > the administrative decision whether this means expanding the > boundaries of your PIM domain. Is this statement on what you believe should be done, or what is being done? I've heard of no implementations blocking these messages. It would be painful, and it is not even specified in the specification AFAICS. > > > They are used by the border routers of a domain only to pull-out the > > > data traffic from within that domain when that traffic doesn't know > > > how to reach other domains on its own. > > > > The problem here is that "domain" is sufficiently ill-defined concept > > to make this "Wildcard receiver" feasible. > > > > What is a domain when you want to "wildcard receive" all PIM-SSM > > sessions in the domain? How is that done? For that matter, what is > > the domain when you use embedded-RP where the you practically have > > only one domain per group? Equally impossible considitions to > > satisfy. > > You cannot use (*,*,RP) to receive the PIM-SSM sessions in the > domain. The (*,*,RP) messages can be used only for ASM. That much is obvious, of course. But the rules do not say that. They give an impression that interoperability is always possible, with all protocols if you follow the rules. That's what I'm arguing against; I'm saying that the rules only work with traditional PIM-SM+MSDP. They don't work with SSM. They don't work with Embedded-RP. They don't work (AFAICS) with Bidir-PIM. So is it really useful to have such rules here in the first place? Or, if it is useful, we have to add a lot more "truth in advertising" so that the readers wouldn't be let to believe the interoperability, as described in section 4.7 would be actually possible except in the traditional scenario. > In case of embedded-RP where you assume that the whole network is > one single PIM-SM domain you don't need (*,*,RP). Were you listening or are you weaseling with words :)? From 4.7.2: o Another component of the PMBR is a wildcard receiver. In this case the PIM-SM component of the PMBR must ensure that traffic from all internal sources reaches the PMBR until it is informed otherwise. .. there is no way to ensure that because you do not know about the internal sources, as there is no central intra-domain RP to keep track of all the sources. > You need (*,*,RP) only when you are interconnecting a PIM-SM domain > with other domains. I don't want to discuss whether you need (*,*,RP) or not. I want to discuss whether it is possible (or feasible, if possible) for PMBR to know about all the "internal sources" (whatever that might mean e.g. with SSM, embedded-RP or bidir). That is a must, but it's seems to be clearly impossible. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Apr 9 12:35:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06452 for ; Fri, 9 Apr 2004 12:35:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByy5-0007Ou-Hc; Fri, 09 Apr 2004 12:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByxD-0007HZ-MZ for pim@optimus.ietf.org; Fri, 09 Apr 2004 12:34:07 -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 MAA06331 for ; Fri, 9 Apr 2004 12:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByxB-0006I9-00 for pim@ietf.org; Fri, 09 Apr 2004 12:34:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBytL-0005wZ-00 for pim@ietf.org; Fri, 09 Apr 2004 12:30:09 -0400 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1BByrK-0005ZE-00 for pim@ietf.org; Fri, 09 Apr 2004 12:28:02 -0400 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i39IXvAw082913; Fri, 9 Apr 2004 11:34:20 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i39GQXd1014604; Fri, 9 Apr 2004 09:26:33 -0700 (PDT) Received: from [10.1.4.232] ([10.1.4.232]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Apr 2004 09:26:32 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Pavlin Radoslavov , pim@ietf.org From: John Zwiebel Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues Date: Fri, 9 Apr 2004 09:26:31 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 09 Apr 2004 16:26:32.0958 (UTC) FILETIME=[6B97D9E0:01C41E4F] 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Apr 9, 2004, at 6:02 AM, Pekka Savola wrote: > > I don't want to discuss whether you need (*,*,RP) or not. I want to > discuss whether it is possible (or feasible, if possible) for PMBR to > know about all the "internal sources" (whatever that might mean e.g. > with SSM, embedded-RP or bidir). That is a must, but it's seems to be > clearly impossible. > 2cents: When PIM was first developed, the "denseness" or "sparseness" was allocated to a router interface. It didn't take too long to figure out that this created all kinds of interoperability problems. So, "denseness" and "sparseness" became allocated to a group and that was for everywhere the group was to be transmitted to. When SSM came along, the group range 232/8 was allocated for it so there would be no problems with interfering with dense or sparse. Now, dense is atrophying and hopefully pim-sm will. By extension (and I confess there is probably no document that specifically says this) the idea that the group uses a certain type of forwarding behavior and that behavior is applicable everywhere is still in force. So, I would not think that anything in the pim-sm spec has anything to do with any other forwarding mode. It is applicable to sparse-mode only. ie, "all internal sources" is applicable to sparse-mode only. I believe this is the general understanding of the folks who work on this. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Apr 9 12:41:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06955 for ; Fri, 9 Apr 2004 12:41:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBz4I-0008N5-Jz for pim-archive@odin.ietf.org; Fri, 09 Apr 2004 12:41:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39GfQ6E032175 for pim-archive@odin.ietf.org; Fri, 9 Apr 2004 12:41:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBz4I-0008Ms-FS for pim-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 12:41:26 -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 MAA06889 for ; Fri, 9 Apr 2004 12:41:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBz4G-00079s-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 12:41:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBz14-0006oU-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 12:38:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BByyJ-0006SD-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 12:35:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByy5-0007Ou-Hc; Fri, 09 Apr 2004 12:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByxD-0007HZ-MZ for pim@optimus.ietf.org; Fri, 09 Apr 2004 12:34:07 -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 MAA06331 for ; Fri, 9 Apr 2004 12:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByxB-0006I9-00 for pim@ietf.org; Fri, 09 Apr 2004 12:34:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBytL-0005wZ-00 for pim@ietf.org; Fri, 09 Apr 2004 12:30:09 -0400 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1BByrK-0005ZE-00 for pim@ietf.org; Fri, 09 Apr 2004 12:28:02 -0400 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i39IXvAw082913; Fri, 9 Apr 2004 11:34:20 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i39GQXd1014604; Fri, 9 Apr 2004 09:26:33 -0700 (PDT) Received: from [10.1.4.232] ([10.1.4.232]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Apr 2004 09:26:32 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Pavlin Radoslavov , pim@ietf.org From: John Zwiebel Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues Date: Fri, 9 Apr 2004 09:26:31 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 09 Apr 2004 16:26:32.0958 (UTC) FILETIME=[6B97D9E0:01C41E4F] Content-Transfer-Encoding: 7bit Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 Content-Transfer-Encoding: 7bit On Apr 9, 2004, at 6:02 AM, Pekka Savola wrote: > > I don't want to discuss whether you need (*,*,RP) or not. I want to > discuss whether it is possible (or feasible, if possible) for PMBR to > know about all the "internal sources" (whatever that might mean e.g. > with SSM, embedded-RP or bidir). That is a must, but it's seems to be > clearly impossible. > 2cents: When PIM was first developed, the "denseness" or "sparseness" was allocated to a router interface. It didn't take too long to figure out that this created all kinds of interoperability problems. So, "denseness" and "sparseness" became allocated to a group and that was for everywhere the group was to be transmitted to. When SSM came along, the group range 232/8 was allocated for it so there would be no problems with interfering with dense or sparse. Now, dense is atrophying and hopefully pim-sm will. By extension (and I confess there is probably no document that specifically says this) the idea that the group uses a certain type of forwarding behavior and that behavior is applicable everywhere is still in force. So, I would not think that anything in the pim-sm spec has anything to do with any other forwarding mode. It is applicable to sparse-mode only. ie, "all internal sources" is applicable to sparse-mode only. I believe this is the general understanding of the folks who work on this. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Apr 9 14:22:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10852 for ; Fri, 9 Apr 2004 14:22:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0dd-0002MF-Le; Fri, 09 Apr 2004 14:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0dL-0002Go-0m for pim@optimus.ietf.org; Fri, 09 Apr 2004 14:21:43 -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 OAA10821 for ; Fri, 9 Apr 2004 14:21:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC0dH-0001vP-00 for pim@ietf.org; Fri, 09 Apr 2004 14:21:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC0c8-0001nl-00 for pim@ietf.org; Fri, 09 Apr 2004 14:20:29 -0400 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1BC0aP-0001aS-00 for pim@ietf.org; Fri, 09 Apr 2004 14:18:41 -0400 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i39IIYr6014120; Fri, 9 Apr 2004 11:18:34 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200404091818.i39IIYr6014120@possum.icir.org> To: Pekka Savola cc: Pavlin Radoslavov , pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: Message from Pekka Savola of "Fri, 09 Apr 2004 16:02:36 +0300." Date: Fri, 09 Apr 2004 11:18:34 -0700 From: Pavlin Radoslavov 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=none autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , > > > Do you mean that such a join would be blocked at the border of the PIM > > > domain (AFAIK not -- one only blocks BSR messages?), for example if > > > the routers along the path were manually configured to use > > > out-of-domain RP? > > > > Yes, I think that any external (*,*,RP) messages should be blocked > > at the border of the PIM domain. However, if you are exposing your > > internal RPs to routers outside of your domain then you have to make > > the administrative decision whether this means expanding the > > boundaries of your PIM domain. > > Is this statement on what you believe should be done, or what is being > done? > > I've heard of no implementations blocking these messages. It would be > painful, and it is not even specified in the specification AFAICS. If it is not in the spec then maybe it should. There is nothing difficult about not accepting at the border routers the external (*,*,RP) Join/Prune messages that arrive on specific interfaces. > > You cannot use (*,*,RP) to receive the PIM-SSM sessions in the > > domain. The (*,*,RP) messages can be used only for ASM. > > That much is obvious, of course. But the rules do not say that. They > give an impression that interoperability is always possible, with all > protocols if you follow the rules. > > That's what I'm arguing against; I'm saying that the rules only work > with traditional PIM-SM+MSDP. They don't work with SSM. They don't > work with Embedded-RP. They don't work (AFAICS) with Bidir-PIM. The rules do work with Bidir-PIM. In case of SSM, if you need inter-operability between two explicit-joins protocols that support (S,G) Joins, then you don't need (*,*,RP) because inter-operability is trivial. If you try to inter-operate between, say, PIM-SM and PIM-DM for SSM, then the simple answer is you can't. You need additional mechanism to achieve that and this mechanism doesn't need to be specified in the PIM-SM spec. In case of Embedded-RP if you explicitly (or implicitly) configure your border routers with the limited set of embedded-RP router addresses within your domain, then you can still use (*,*,RP). Otherwise, I'd say that Embedded-RP doesn't work with the (*,*,RP) mechanism, not the other way around :) Remember that the (*,*,RP) rules were written long time ago when there was no SSM, Bidir-PIM or Embedded-RP. The rules are there to take advantage of them when you need so. > So is it really useful to have such rules here in the first place? Yes. > Or, if it is useful, we have to add a lot more "truth in advertising" > so that the readers wouldn't be let to believe the interoperability, > as described in section 4.7 would be actually possible except in the > traditional scenario. > > > In case of embedded-RP where you assume that the whole network is > > one single PIM-SM domain you don't need (*,*,RP). > > Were you listening or are you weaseling with words :)? From 4.7.2: > > o Another component of the PMBR is a wildcard receiver. In this case > the PIM-SM component of the PMBR must ensure that traffic from all > internal sources reaches the PMBR until it is informed otherwise. > > .. there is no way to ensure that because you do not know about the > internal sources, as there is no central intra-domain RP to keep track > of all the sources. > > > You need (*,*,RP) only when you are interconnecting a PIM-SM domain > > with other domains. > > I don't want to discuss whether you need (*,*,RP) or not. I want to > discuss whether it is possible (or feasible, if possible) for PMBR to > know about all the "internal sources" (whatever that might mean e.g. > with SSM, embedded-RP or bidir). That is a must, but it's seems to be > clearly impossible. If you think that the wording "all internal sources" is what makes the text confusing, then the answer is yes, you cannot use (*,*,RP) to get the traffic from "all internal sources". You cannot get the traffic from SSM sources, and you cannot get the traffic from ASM sources when the RP is outside of the PMBR's domain (in the latter the PMBR in the remote domain with the RP will take care of that source). In that case, the spec just needs to clarify this particular statement. Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Apr 9 14:24:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11043 for ; Fri, 9 Apr 2004 14:24:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0fc-0002mt-Ip for pim-archive@odin.ietf.org; Fri, 09 Apr 2004 14:24:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39IO4dJ010711 for pim-archive@odin.ietf.org; Fri, 9 Apr 2004 14:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0fc-0002mg-El for pim-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 14:24:04 -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 OAA10975 for ; Fri, 9 Apr 2004 14:24:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC0fZ-0002A6-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 14:24:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC0eJ-00022y-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 14:22:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC0dm-0001wQ-00 for pim-web-archive@ietf.org; Fri, 09 Apr 2004 14:22:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0dd-0002MF-Le; Fri, 09 Apr 2004 14:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC0dL-0002Go-0m for pim@optimus.ietf.org; Fri, 09 Apr 2004 14:21:43 -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 OAA10821 for ; Fri, 9 Apr 2004 14:21:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC0dH-0001vP-00 for pim@ietf.org; Fri, 09 Apr 2004 14:21:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC0c8-0001nl-00 for pim@ietf.org; Fri, 09 Apr 2004 14:20:29 -0400 Received: from possum.icir.org ([192.150.187.67]) by ietf-mx with esmtp (Exim 4.12) id 1BC0aP-0001aS-00 for pim@ietf.org; Fri, 09 Apr 2004 14:18:41 -0400 Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i39IIYr6014120; Fri, 9 Apr 2004 11:18:34 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200404091818.i39IIYr6014120@possum.icir.org> To: Pekka Savola cc: Pavlin Radoslavov , pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: Message from Pekka Savola of "Fri, 09 Apr 2004 16:02:36 +0300." Date: Fri, 09 Apr 2004 11:18:34 -0700 From: Pavlin Radoslavov Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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=none autolearn=no version=2.60 > > > Do you mean that such a join would be blocked at the border of the PIM > > > domain (AFAIK not -- one only blocks BSR messages?), for example if > > > the routers along the path were manually configured to use > > > out-of-domain RP? > > > > Yes, I think that any external (*,*,RP) messages should be blocked > > at the border of the PIM domain. However, if you are exposing your > > internal RPs to routers outside of your domain then you have to make > > the administrative decision whether this means expanding the > > boundaries of your PIM domain. > > Is this statement on what you believe should be done, or what is being > done? > > I've heard of no implementations blocking these messages. It would be > painful, and it is not even specified in the specification AFAICS. If it is not in the spec then maybe it should. There is nothing difficult about not accepting at the border routers the external (*,*,RP) Join/Prune messages that arrive on specific interfaces. > > You cannot use (*,*,RP) to receive the PIM-SSM sessions in the > > domain. The (*,*,RP) messages can be used only for ASM. > > That much is obvious, of course. But the rules do not say that. They > give an impression that interoperability is always possible, with all > protocols if you follow the rules. > > That's what I'm arguing against; I'm saying that the rules only work > with traditional PIM-SM+MSDP. They don't work with SSM. They don't > work with Embedded-RP. They don't work (AFAICS) with Bidir-PIM. The rules do work with Bidir-PIM. In case of SSM, if you need inter-operability between two explicit-joins protocols that support (S,G) Joins, then you don't need (*,*,RP) because inter-operability is trivial. If you try to inter-operate between, say, PIM-SM and PIM-DM for SSM, then the simple answer is you can't. You need additional mechanism to achieve that and this mechanism doesn't need to be specified in the PIM-SM spec. In case of Embedded-RP if you explicitly (or implicitly) configure your border routers with the limited set of embedded-RP router addresses within your domain, then you can still use (*,*,RP). Otherwise, I'd say that Embedded-RP doesn't work with the (*,*,RP) mechanism, not the other way around :) Remember that the (*,*,RP) rules were written long time ago when there was no SSM, Bidir-PIM or Embedded-RP. The rules are there to take advantage of them when you need so. > So is it really useful to have such rules here in the first place? Yes. > Or, if it is useful, we have to add a lot more "truth in advertising" > so that the readers wouldn't be let to believe the interoperability, > as described in section 4.7 would be actually possible except in the > traditional scenario. > > > In case of embedded-RP where you assume that the whole network is > > one single PIM-SM domain you don't need (*,*,RP). > > Were you listening or are you weaseling with words :)? From 4.7.2: > > o Another component of the PMBR is a wildcard receiver. In this case > the PIM-SM component of the PMBR must ensure that traffic from all > internal sources reaches the PMBR until it is informed otherwise. > > .. there is no way to ensure that because you do not know about the > internal sources, as there is no central intra-domain RP to keep track > of all the sources. > > > You need (*,*,RP) only when you are interconnecting a PIM-SM domain > > with other domains. > > I don't want to discuss whether you need (*,*,RP) or not. I want to > discuss whether it is possible (or feasible, if possible) for PMBR to > know about all the "internal sources" (whatever that might mean e.g. > with SSM, embedded-RP or bidir). That is a must, but it's seems to be > clearly impossible. If you think that the wording "all internal sources" is what makes the text confusing, then the answer is yes, you cannot use (*,*,RP) to get the traffic from "all internal sources". You cannot get the traffic from SSM sources, and you cannot get the traffic from ASM sources when the RP is outside of the PMBR's domain (in the latter the PMBR in the remote domain with the RP will take care of that source). In that case, the spec just needs to clarify this particular statement. Pavlin _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Apr 14 03:07:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05270 for ; Wed, 14 Apr 2004 03:07:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDePJ-0007aY-ER; Wed, 14 Apr 2004 03:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDeFu-0005sl-58 for pim@optimus.ietf.org; Wed, 14 Apr 2004 02:52:18 -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 CAA04695 for ; Wed, 14 Apr 2004 02:52:14 -0400 (EDT) From: pusateri@juniper.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDeFq-0001Jh-00 for pim@ietf.org; Wed, 14 Apr 2004 02:52:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDeEs-0001CZ-00 for pim@ietf.org; Wed, 14 Apr 2004 02:51:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDeDw-00015U-00 for pim@ietf.org; Wed, 14 Apr 2004 02:50:16 -0400 Received: from tlv-diup-32-211.inter.net.il ([213.8.32.211] helo=ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDeCH-0005Ut-Kq for pim@ietf.org; Wed, 14 Apr 2004 02:48:33 -0400 To: pim@ietf.org Date: Tue, 7 Jan 2003 21:49:10 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA80.6B015D10" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.5 required=5.0 tests=DATE_IN_PAST_96_XX,HTML_40_50, HTML_MESSAGE,HTML_RELAYING_FRAME,MICROSOFT_EXECUTABLE, MIME_SUSPECT_NAME,MISSING_MIMEOLE,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [pim] Mail Delivery (failure pim@ietf.org) Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01C0CA80.6B015D10" ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the message will not displayed automatically,
follow the link to read the delivered message.

Received message is available at:
www.ietf.org/inbox/pim/read.php?sessionid-17811
 
------=_NextPart_001_001C_01C0CA80.6B015D10-- ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Filename: message.scr, Content-Type: audio/x-wav] The attachment file in the message has been removed by eManager. ------=_NextPart_000_001B_01C0CA80.6B015D10-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Apr 16 13:03:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22019 for ; Fri, 16 Apr 2004 13:03:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWgA-0000D2-6w; Fri, 16 Apr 2004 12:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWT4-0003GX-Mo for pim@optimus.ietf.org; Fri, 16 Apr 2004 12:45:30 -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 MAA20571 for ; Fri, 16 Apr 2004 12:45:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEWT2-0002wi-Ue for pim@ietf.org; Fri, 16 Apr 2004 12:45:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWSC-0002rZ-00 for pim@ietf.org; Fri, 16 Apr 2004 12:44:37 -0400 Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BEWRC-0002gI-00 for pim@ietf.org; Fri, 16 Apr 2004 12:43:34 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <20KS4M12>; Fri, 16 Apr 2004 17:42:57 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803580FBE@baker.datcon.co.uk> From: James Lingard To: "'pim@ietf.org'" Date: Fri, 16 Apr 2004 17:42:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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=none autolearn=no version=2.60 Subject: [pim] Comments on Section 4.8 of draft-ietf-pim-sm-v2-new-09.txt Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Hi, I have the following comments on section 4.8 (PIM Bootstrap and RP Discovery) of the latest PIM-SM draft. These are mainly questions about ambiguous statements within the draft, with some suggested clarifications. Please feel free to ask me for clarification if any of these points are unclear. Thanks, James. ========================================================================== * Throughout section 4.8 The phrase "group-to-RP mapping" is used with two separate meanings: - As a description of the process of mapping from a group to an RP address (e.g. in the title of section 4.8.1). - As the data structure that contains a group range and a candididate RP (e.g. in the phrase "A PIM router must support the static configuration of group-to-RP mappings." (This is also referred to as a "group-range-to-RP mapping" in other places within the section). This is slightly confusing. I suggest changing all uses with the latter meaning to "group-range-to-RP mapping". ========================================================================== * Section 4.8.1 >> Using one of the mechanisms described above [...] This wording seems to imply that - a single mechanism must be used - this mechanism must be one of the three described above. Is this intended? How about replacing this with something along the lines of "Using one or a combination of the mechanisms described above, or some alternative mechanism not described here" ========================================================================== * Section 4.8.1 If there is a combination of mappings configured statically and learned via BSR, should the algorithm be applied to all mappings learned from either mechanism, or should one mechanism be preferred over the other? Note that this relates to a discussion about statically configured RPs currently taking place on the pim-mib mailing list. ========================================================================== * Section 4.8.1 >> Each mapping may also have an associated priority. ^^^ How does the algorithm work if a group-to-RP-mapping *doesn't* have an associated priority? Should this read: "Each mapping also has an associated priority."? ========================================================================== * Section 4.8.2 >> The protocol requires that all routers hash to the same RP within a >> domain (except for transients). This should say something like: "The protocol requires that all routers hash to the same RP within a domain or admin scope zone (except for transients)." ========================================================================== * Section 4.8.2 >> Value(G,M,C(i))= >> (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31 In the middle clause "(1103515245 * (G&M)+12345)", which operator is supposed to take precedence, the '*' or the '+'? Standard precedence rules would say the '*', but the spacing suggests that the intention is for the '+'. Either way, should add brackets to avoid ambiguity. ========================================================================== * Section 4.8.2 Is the hash-mask REQUIRED to be a contiguous sequence of most-significant 1 bits? If not, the description of the purpose of the hash-mask (namely "The hash-mask allows a small number of consecutive groups to always hash to the same RP.") is not strictly accurate. ========================================================================== * Section 4.8.2 Why is the "digest" mechanism for an IPv6 RP address's C(i) value in the hash algorithm "recommended" not mandated? Since a common digest algorithm is necessary for interoperability, I would have thought a single algorithm should be mandated unless there's a very good reason not to do so. -- James Lingard Data Connection Ltd (DCL) http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Apr 16 13:14:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22592 for ; Fri, 16 Apr 2004 13:14:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWsx-00044o-RD for pim-archive@odin.ietf.org; Fri, 16 Apr 2004 13:12:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GHCFTD015670 for pim-archive@odin.ietf.org; Fri, 16 Apr 2004 13:12:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWlI-0001uW-SO for pim-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 13:04:20 -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 NAA22079 for ; Fri, 16 Apr 2004 13:04:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEWlH-0004YX-0b for pim-web-archive@ietf.org; Fri, 16 Apr 2004 13:04:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWkG-0004V1-00 for pim-web-archive@ietf.org; Fri, 16 Apr 2004 13:03:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEWjZ-0004Ql-00 for pim-web-archive@ietf.org; Fri, 16 Apr 2004 13:02:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWgA-0000D2-6w; Fri, 16 Apr 2004 12:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWT4-0003GX-Mo for pim@optimus.ietf.org; Fri, 16 Apr 2004 12:45:30 -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 MAA20571 for ; Fri, 16 Apr 2004 12:45:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEWT2-0002wi-Ue for pim@ietf.org; Fri, 16 Apr 2004 12:45:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWSC-0002rZ-00 for pim@ietf.org; Fri, 16 Apr 2004 12:44:37 -0400 Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BEWRC-0002gI-00 for pim@ietf.org; Fri, 16 Apr 2004 12:43:34 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <20KS4M12>; Fri, 16 Apr 2004 17:42:57 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803580FBE@baker.datcon.co.uk> From: James Lingard To: "'pim@ietf.org'" Date: Fri, 16 Apr 2004 17:42:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [pim] Comments on Section 4.8 of draft-ietf-pim-sm-v2-new-09.txt Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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=none autolearn=no version=2.60 Hi, I have the following comments on section 4.8 (PIM Bootstrap and RP Discovery) of the latest PIM-SM draft. These are mainly questions about ambiguous statements within the draft, with some suggested clarifications. Please feel free to ask me for clarification if any of these points are unclear. Thanks, James. ========================================================================== * Throughout section 4.8 The phrase "group-to-RP mapping" is used with two separate meanings: - As a description of the process of mapping from a group to an RP address (e.g. in the title of section 4.8.1). - As the data structure that contains a group range and a candididate RP (e.g. in the phrase "A PIM router must support the static configuration of group-to-RP mappings." (This is also referred to as a "group-range-to-RP mapping" in other places within the section). This is slightly confusing. I suggest changing all uses with the latter meaning to "group-range-to-RP mapping". ========================================================================== * Section 4.8.1 >> Using one of the mechanisms described above [...] This wording seems to imply that - a single mechanism must be used - this mechanism must be one of the three described above. Is this intended? How about replacing this with something along the lines of "Using one or a combination of the mechanisms described above, or some alternative mechanism not described here" ========================================================================== * Section 4.8.1 If there is a combination of mappings configured statically and learned via BSR, should the algorithm be applied to all mappings learned from either mechanism, or should one mechanism be preferred over the other? Note that this relates to a discussion about statically configured RPs currently taking place on the pim-mib mailing list. ========================================================================== * Section 4.8.1 >> Each mapping may also have an associated priority. ^^^ How does the algorithm work if a group-to-RP-mapping *doesn't* have an associated priority? Should this read: "Each mapping also has an associated priority."? ========================================================================== * Section 4.8.2 >> The protocol requires that all routers hash to the same RP within a >> domain (except for transients). This should say something like: "The protocol requires that all routers hash to the same RP within a domain or admin scope zone (except for transients)." ========================================================================== * Section 4.8.2 >> Value(G,M,C(i))= >> (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31 In the middle clause "(1103515245 * (G&M)+12345)", which operator is supposed to take precedence, the '*' or the '+'? Standard precedence rules would say the '*', but the spacing suggests that the intention is for the '+'. Either way, should add brackets to avoid ambiguity. ========================================================================== * Section 4.8.2 Is the hash-mask REQUIRED to be a contiguous sequence of most-significant 1 bits? If not, the description of the purpose of the hash-mask (namely "The hash-mask allows a small number of consecutive groups to always hash to the same RP.") is not strictly accurate. ========================================================================== * Section 4.8.2 Why is the "digest" mechanism for an IPv6 RP address's C(i) value in the hash algorithm "recommended" not mandated? Since a common digest algorithm is necessary for interoperability, I would have thought a single algorithm should be mandated unless there's a very good reason not to do so. -- James Lingard Data Connection Ltd (DCL) http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Sat Apr 17 04:32:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27183 for ; Sat, 17 Apr 2004 04:32:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEl7g-0006xz-03; Sat, 17 Apr 2004 04:24:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEkWD-0005WC-Sb for pim@optimus.ietf.org; Sat, 17 Apr 2004 03:45:42 -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 DAA25758 for ; Sat, 17 Apr 2004 03:45:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEkWB-00078W-Ei for pim@ietf.org; Sat, 17 Apr 2004 03:45:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEkVC-00073g-00 for pim@ietf.org; Sat, 17 Apr 2004 03:44:38 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEkUH-0006wM-00 for pim@ietf.org; Sat, 17 Apr 2004 03:43:41 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3H7gl319845; Sat, 17 Apr 2004 10:42:47 +0300 Date: Sat, 17 Apr 2004 10:42:47 +0300 (EEST) From: Pekka Savola To: John Zwiebel cc: Pavlin Radoslavov , Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , On Fri, 9 Apr 2004, John Zwiebel wrote: > So, I would not think that anything in the pim-sm spec has anything to > do with any other forwarding mode. It is applicable to sparse-mode > only. The spec describes SSM, which by some definition is not "sparse-mode"? (not sure where you draw the line..) > ie, "all internal sources" is applicable to sparse-mode only. I believe > this is the general understanding of the folks who work on this. (.. but if you include it in sparse-mode, it's not applicable to "all internal sources") The problem is IMHO that the document makes an unstated (and flawed) assumption that PIM-SM would make work precisely the same way that in a domain (in the autonomous system sense) you could somehow know all the internal sources. Model like embedded RP has shown that this is not true. (I think the same would apply to bidir when used with embedded RP as well.) So, I'm not sure how applicable that section is in the first place, or whether major clarifications would be sufficient. Impossible to say without considering the clarifications... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Sat Apr 17 04:39:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27878 for ; Sat, 17 Apr 2004 04:39:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BElHC-0001jP-Ju for pim-archive@odin.ietf.org; Sat, 17 Apr 2004 04:34:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H8YEcY006656 for pim-archive@odin.ietf.org; Sat, 17 Apr 2004 04:34:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BElGr-0001Px-4k for pim-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 04:33:53 -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 EAA27327 for ; Sat, 17 Apr 2004 04:33: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 1BElGo-0003dw-AO for pim-web-archive@ietf.org; Sat, 17 Apr 2004 04:33:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BElFr-0003TQ-00 for pim-web-archive@ietf.org; Sat, 17 Apr 2004 04:32:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BElEw-0003KD-00 for pim-web-archive@ietf.org; Sat, 17 Apr 2004 04:31:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEl7g-0006xz-03; Sat, 17 Apr 2004 04:24:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEkWD-0005WC-Sb for pim@optimus.ietf.org; Sat, 17 Apr 2004 03:45:42 -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 DAA25758 for ; Sat, 17 Apr 2004 03:45:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEkWB-00078W-Ei for pim@ietf.org; Sat, 17 Apr 2004 03:45:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEkVC-00073g-00 for pim@ietf.org; Sat, 17 Apr 2004 03:44:38 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEkUH-0006wM-00 for pim@ietf.org; Sat, 17 Apr 2004 03:43:41 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3H7gl319845; Sat, 17 Apr 2004 10:42:47 +0300 Date: Sat, 17 Apr 2004 10:42:47 +0300 (EEST) From: Pekka Savola To: John Zwiebel cc: Pavlin Radoslavov , Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 On Fri, 9 Apr 2004, John Zwiebel wrote: > So, I would not think that anything in the pim-sm spec has anything to > do with any other forwarding mode. It is applicable to sparse-mode > only. The spec describes SSM, which by some definition is not "sparse-mode"? (not sure where you draw the line..) > ie, "all internal sources" is applicable to sparse-mode only. I believe > this is the general understanding of the folks who work on this. (.. but if you include it in sparse-mode, it's not applicable to "all internal sources") The problem is IMHO that the document makes an unstated (and flawed) assumption that PIM-SM would make work precisely the same way that in a domain (in the autonomous system sense) you could somehow know all the internal sources. Model like embedded RP has shown that this is not true. (I think the same would apply to bidir when used with embedded RP as well.) So, I'm not sure how applicable that section is in the first place, or whether major clarifications would be sufficient. Impossible to say without considering the clarifications... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Sat Apr 17 04:48:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28228 for ; Sat, 17 Apr 2004 04:48:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BElNu-0003mi-1x; Sat, 17 Apr 2004 04:41:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BElJq-0002CY-2j for pim@optimus.ietf.org; Sat, 17 Apr 2004 04:36:58 -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 EAA27757 for ; Sat, 17 Apr 2004 04:36:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BElJn-0004H5-3a for pim@ietf.org; Sat, 17 Apr 2004 04:36:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BElJ4-00047l-00 for pim@ietf.org; Sat, 17 Apr 2004 04:36:10 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BElI2-0003mg-00 for pim@ietf.org; Sat, 17 Apr 2004 04:35:06 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3H8YbN20398; Sat, 17 Apr 2004 11:34:37 +0300 Date: Sat, 17 Apr 2004 11:34:37 +0300 (EEST) From: Pekka Savola To: pim@ietf.org cc: dmm@1-4-5.net, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: 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] I-D ACTION:draft-ietf-mboned-mroutesec-00.txt (fwd) Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , FYI, The mboned charter indicates that this should be shipped of to IESG this month, so now would be a good time to comment on this. In particular, there's a lot of new text on some suggested rate-limiting mechanisms. Take a look. Thanks! ---------- Forwarded message ---------- Date: Fri, 16 Apr 2004 15:37:10 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: mboned@lists.uoregon.edu Subject: I-D ACTION:draft-ietf-mboned-mroutesec-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MBONE Deployment Working Group of the IETF. Title : PIM-SM Multicast Routing Security Issues and Enhancements Author(s) : P. Savola, et al. Filename : draft-ietf-mboned-mroutesec-00.txt Pages : 20 Date : 2004-4-16 This memo describes security threats for the larger (intra-domain, or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any Source Multicast (ASM) model, Source-Specific Multicast (SSM) model, and the ASM model enhanced by the Embedded-RP group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations to mitigate the identified threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mboned-mroutesec-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 the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mboned-mroutesec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mboned-mroutesec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Sat Apr 17 04:50:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28321 for ; Sat, 17 Apr 2004 04:50:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BElW7-00064n-7D for pim-archive@odin.ietf.org; Sat, 17 Apr 2004 04:49:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H8ndwl023352 for pim-archive@odin.ietf.org; Sat, 17 Apr 2004 04:49:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BElVG-0005oK-18 for pim-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 04:48: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 EAA28257 for ; Sat, 17 Apr 2004 04:48: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 1BElVD-0005Su-5c for pim-web-archive@ietf.org; Sat, 17 Apr 2004 04:48:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BElUO-0005OM-00 for pim-web-archive@ietf.org; Sat, 17 Apr 2004 04:47:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BElU3-0005Iz-00 for pim-web-archive@ietf.org; Sat, 17 Apr 2004 04:47:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BElNu-0003mi-1x; Sat, 17 Apr 2004 04:41:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BElJq-0002CY-2j for pim@optimus.ietf.org; Sat, 17 Apr 2004 04:36:58 -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 EAA27757 for ; Sat, 17 Apr 2004 04:36:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BElJn-0004H5-3a for pim@ietf.org; Sat, 17 Apr 2004 04:36:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BElJ4-00047l-00 for pim@ietf.org; Sat, 17 Apr 2004 04:36:10 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BElI2-0003mg-00 for pim@ietf.org; Sat, 17 Apr 2004 04:35:06 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3H8YbN20398; Sat, 17 Apr 2004 11:34:37 +0300 Date: Sat, 17 Apr 2004 11:34:37 +0300 (EEST) From: Pekka Savola To: pim@ietf.org cc: dmm@1-4-5.net, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Subject: [pim] I-D ACTION:draft-ietf-mboned-mroutesec-00.txt (fwd) Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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 FYI, The mboned charter indicates that this should be shipped of to IESG this month, so now would be a good time to comment on this. In particular, there's a lot of new text on some suggested rate-limiting mechanisms. Take a look. Thanks! ---------- Forwarded message ---------- Date: Fri, 16 Apr 2004 15:37:10 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: mboned@lists.uoregon.edu Subject: I-D ACTION:draft-ietf-mboned-mroutesec-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MBONE Deployment Working Group of the IETF. Title : PIM-SM Multicast Routing Security Issues and Enhancements Author(s) : P. Savola, et al. Filename : draft-ietf-mboned-mroutesec-00.txt Pages : 20 Date : 2004-4-16 This memo describes security threats for the larger (intra-domain, or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any Source Multicast (ASM) model, Source-Specific Multicast (SSM) model, and the ASM model enhanced by the Embedded-RP group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations to mitigate the identified threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mboned-mroutesec-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 the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mboned-mroutesec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mboned-mroutesec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Tue Apr 20 00:15:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05154 for ; Tue, 20 Apr 2004 00:15:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmWK-0005ze-6G; Tue, 20 Apr 2004 00:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmRK-0004hO-JV for pim@optimus.ietf.org; Tue, 20 Apr 2004 00:00:54 -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 AAA04521 for ; Tue, 20 Apr 2004 00:00:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFmRI-0003w4-9Q for pim@ietf.org; Tue, 20 Apr 2004 00:00:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmQO-0003gP-00 for pim@ietf.org; Mon, 19 Apr 2004 23:59:58 -0400 Received: from bay16-dav56.bay16.hotmail.com ([65.54.186.236] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BFmPs-0003Pm-00 for pim@ietf.org; Mon, 19 Apr 2004 23:59:24 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 19 Apr 2004 20:58:55 -0700 Received: from 209.197.136.118 by bay16-dav56.bay16.hotmail.com with DAV; Tue, 20 Apr 2004 03:58:55 +0000 X-Originating-IP: [209.197.136.118] X-Originating-Email: [rajibullah@hotmail.com] X-Sender: rajibullah@hotmail.com From: "Rajib" To: Date: Mon, 19 Apr 2004 23:57:58 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C4266A.240C9610" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 20 Apr 2004 03:58:55.0287 (UTC) FILETIME=[CCE1B470:01C4268B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [pim] Abt : PIM DM periodic nature Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C4266A.240C9610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I will be very happy if someone spare some time and give me some = suggestions on the following issue. As per PIM DM-=20 Prune state has a finite lifetime. When that lifetime expires, data = will again be forwarded down the previously pruned branch. In order to minimize repeated flooding of packets and subsequent pruning = associated with a particular (S,G) pair, PIM-DM uses a state=20 refresh message. This message is sent by the router(s) directly = connected to the source and is propagated throughout the network. When received by a router on its RPF interface, the state refresh message = causes an existing prune state to be refreshed. 1. My question is what was reason of giving finite lifetime to Prune ?=20 2. In the version 2 it was overcome by the state refresh message. It = seems that version1 was wrong and version 2 corrects it without making = any major change in the protocol. Why not any major change like the = following ways- What I am proposing- 1. There will be no periodic timer enable in any router except for the = router directly connected to the source. I mean, when a router gets any = data from it's directly connected source (not from any other router) = only then it will enable a timer for that particualar (S,G). 2. When a particular (S,G) state is created in all routers after = arriving multicast data. This (S,G) state for a particular source and = group will not timeout and hence will not be deleted unless the router = gets and proposed "Multicast session end" message from the router = directly connected to the sender. 3. Pruned branches will never timeout. These pruned branches will only = become active "Dense" when they get grafts.While the multicast session = is in process. 4. When there is no (S,G) data (data for particular source and group) = from the source to directly connected router, for more than a particular = time (say 6 minutes) then this router will assume that the source has = finished or discontinued the session and the router will flood the = proposed "Multicast session end" message for particular (S,G) through = out the network and all those particular (S,G) states in differnet = routers will be deleted. These make the protocol- 1. Very simple. 2.Makes the protocol suitable for both dense and sparse mode. 3. No unnecessary timers in routers. 4. No periodic flooding. 5.No concern regarding prune or any other thing time out.=20 I know my proposal goes far away from PIM DM. But it is PIM DM based. Is = it ok to use ?=20 I will be very happy if you please let me know is there any problem with = my proposal.=20 Rajib Bashir ------=_NextPart_000_0008_01C4266A.240C9610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I will be=20 very happy if someone spare some time and give me some suggestions = on the=20 following issue.

 

 

As per=20 PIM DM-

 

Prune state has a = finite=20 lifetime.  When that lifetime expires, data will again be forwarded = down=20 the previously pruned branch.

 

In order to minimize = repeated=20 flooding of packets and subsequent pruning associated with a particular = (S,G)=20 pair, PIM-DM uses a state
refresh message.  This message is = sent by the=20 router(s) directly  connected to the source and is propagated = throughout=20 the network.  When
received by a router on its RPF interface, = the state=20 refresh message causes an existing prune state to be refreshed.

 

1. My question is = what was=20 reason of  giving finite lifetime to Prune ?

2. In the version 2 it was = overcome=20 by the state refresh message. It seems that version1 was wrong and = version 2=20 corrects it without making any major change in the protocol. Why not any = major=20 change like the following ways-

 

What I am = proposing-

 

1. There will be no = periodic timer=20 enable in any router except for the router directly connected to the = source. I=20 mean, when a router gets any data from it's directly connected =  source=20 (not from any other router) only then it will enable a timer for = that=20 particualar (S,G).

 

2.  When a=20 particular (S,G) state is created in all routers after arriving = multicast=20 data. This (S,G) state for a particular source and group will not = timeout and=20 hence will not be deleted unless the router gets and proposed "Multicast = session=20 end" message from the router directly connected to the = sender.

 

3. Pruned branches will = never=20 timeout. These pruned branches will only become active "Dense" when they = get=20 grafts.While the multicast session is in process.

 

4. When there is no (S,G) = data (data=20 for particular source and group) from the source to directly connected=20 router, for more than a particular time (say 6  minutes) = then=20 this router will assume that the source has finished or = discontinued the=20 session and the router will flood the proposed = "Multicast session=20 end" message for particular (S,G) through out the network and all = those=20 particular (S,G) states in differnet routers will be = deleted.

 

 

These make the = protocol-

 

1. Very = simple.

2.Makes the protocol = suitable for=20 both dense and sparse mode.

3. No unnecessary = timers in=20 routers.

4. No periodic = flooding.

5.No concern=20 regarding prune or any other thing time out. 

 

I know my=20 proposal goes far away from PIM DM. But it is PIM DM based. Is it ok to = use ?=20

 

 

I will be very happy if = you please=20 let me know is there any problem with my proposal.

 

Rajib=20 Bashir

------=_NextPart_000_0008_01C4266A.240C9610-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Tue Apr 20 00:29:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05873 for ; Tue, 20 Apr 2004 00:29:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmjH-0000nD-QZ for pim-archive@odin.ietf.org; Tue, 20 Apr 2004 00:19:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K4JRFv003046 for pim-archive@odin.ietf.org; Tue, 20 Apr 2004 00:19:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmgg-0008HM-WC for pim-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 00:16:47 -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 AAA05202 for ; Tue, 20 Apr 2004 00:16:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFmge-00007I-Fc for pim-web-archive@ietf.org; Tue, 20 Apr 2004 00:16:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmff-0007ex-00 for pim-web-archive@ietf.org; Tue, 20 Apr 2004 00:15:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFmf9-0007QN-00 for pim-web-archive@ietf.org; Tue, 20 Apr 2004 00:15:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmWK-0005ze-6G; Tue, 20 Apr 2004 00:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmRK-0004hO-JV for pim@optimus.ietf.org; Tue, 20 Apr 2004 00:00:54 -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 AAA04521 for ; Tue, 20 Apr 2004 00:00:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFmRI-0003w4-9Q for pim@ietf.org; Tue, 20 Apr 2004 00:00:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmQO-0003gP-00 for pim@ietf.org; Mon, 19 Apr 2004 23:59:58 -0400 Received: from bay16-dav56.bay16.hotmail.com ([65.54.186.236] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BFmPs-0003Pm-00 for pim@ietf.org; Mon, 19 Apr 2004 23:59:24 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 19 Apr 2004 20:58:55 -0700 Received: from 209.197.136.118 by bay16-dav56.bay16.hotmail.com with DAV; Tue, 20 Apr 2004 03:58:55 +0000 X-Originating-IP: [209.197.136.118] X-Originating-Email: [rajibullah@hotmail.com] X-Sender: rajibullah@hotmail.com From: "Rajib" To: Date: Mon, 19 Apr 2004 23:57:58 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C4266A.240C9610" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 20 Apr 2004 03:58:55.0287 (UTC) FILETIME=[CCE1B470:01C4268B] Subject: [pim] Abt : PIM DM periodic nature Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C4266A.240C9610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I will be very happy if someone spare some time and give me some = suggestions on the following issue. As per PIM DM-=20 Prune state has a finite lifetime. When that lifetime expires, data = will again be forwarded down the previously pruned branch. In order to minimize repeated flooding of packets and subsequent pruning = associated with a particular (S,G) pair, PIM-DM uses a state=20 refresh message. This message is sent by the router(s) directly = connected to the source and is propagated throughout the network. When received by a router on its RPF interface, the state refresh message = causes an existing prune state to be refreshed. 1. My question is what was reason of giving finite lifetime to Prune ?=20 2. In the version 2 it was overcome by the state refresh message. It = seems that version1 was wrong and version 2 corrects it without making = any major change in the protocol. Why not any major change like the = following ways- What I am proposing- 1. There will be no periodic timer enable in any router except for the = router directly connected to the source. I mean, when a router gets any = data from it's directly connected source (not from any other router) = only then it will enable a timer for that particualar (S,G). 2. When a particular (S,G) state is created in all routers after = arriving multicast data. This (S,G) state for a particular source and = group will not timeout and hence will not be deleted unless the router = gets and proposed "Multicast session end" message from the router = directly connected to the sender. 3. Pruned branches will never timeout. These pruned branches will only = become active "Dense" when they get grafts.While the multicast session = is in process. 4. When there is no (S,G) data (data for particular source and group) = from the source to directly connected router, for more than a particular = time (say 6 minutes) then this router will assume that the source has = finished or discontinued the session and the router will flood the = proposed "Multicast session end" message for particular (S,G) through = out the network and all those particular (S,G) states in differnet = routers will be deleted. These make the protocol- 1. Very simple. 2.Makes the protocol suitable for both dense and sparse mode. 3. No unnecessary timers in routers. 4. No periodic flooding. 5.No concern regarding prune or any other thing time out.=20 I know my proposal goes far away from PIM DM. But it is PIM DM based. Is = it ok to use ?=20 I will be very happy if you please let me know is there any problem with = my proposal.=20 Rajib Bashir ------=_NextPart_000_0008_01C4266A.240C9610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I will be=20 very happy if someone spare some time and give me some suggestions = on the=20 following issue.

 

 

As per=20 PIM DM-

 

Prune state has a = finite=20 lifetime.  When that lifetime expires, data will again be forwarded = down=20 the previously pruned branch.

 

In order to minimize = repeated=20 flooding of packets and subsequent pruning associated with a particular = (S,G)=20 pair, PIM-DM uses a state
refresh message.  This message is = sent by the=20 router(s) directly  connected to the source and is propagated = throughout=20 the network.  When
received by a router on its RPF interface, = the state=20 refresh message causes an existing prune state to be refreshed.

 

1. My question is = what was=20 reason of  giving finite lifetime to Prune ?

2. In the version 2 it was = overcome=20 by the state refresh message. It seems that version1 was wrong and = version 2=20 corrects it without making any major change in the protocol. Why not any = major=20 change like the following ways-

 

What I am = proposing-

 

1. There will be no = periodic timer=20 enable in any router except for the router directly connected to the = source. I=20 mean, when a router gets any data from it's directly connected =  source=20 (not from any other router) only then it will enable a timer for = that=20 particualar (S,G).

 

2.  When a=20 particular (S,G) state is created in all routers after arriving = multicast=20 data. This (S,G) state for a particular source and group will not = timeout and=20 hence will not be deleted unless the router gets and proposed "Multicast = session=20 end" message from the router directly connected to the = sender.

 

3. Pruned branches will = never=20 timeout. These pruned branches will only become active "Dense" when they = get=20 grafts.While the multicast session is in process.

 

4. When there is no (S,G) = data (data=20 for particular source and group) from the source to directly connected=20 router, for more than a particular time (say 6  minutes) = then=20 this router will assume that the source has finished or = discontinued the=20 session and the router will flood the proposed = "Multicast session=20 end" message for particular (S,G) through out the network and all = those=20 particular (S,G) states in differnet routers will be = deleted.

 

 

These make the = protocol-

 

1. Very = simple.

2.Makes the protocol = suitable for=20 both dense and sparse mode.

3. No unnecessary = timers in=20 routers.

4. No periodic = flooding.

5.No concern=20 regarding prune or any other thing time out. 

 

I know my=20 proposal goes far away from PIM DM. But it is PIM DM based. Is it ok to = use ?=20

 

 

I will be very happy if = you please=20 let me know is there any problem with my proposal.

 

Rajib=20 Bashir

------=_NextPart_000_0008_01C4266A.240C9610-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Tue Apr 20 10:08:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19663 for ; Tue, 20 Apr 2004 10:08:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvmA-0006rv-PK; Tue, 20 Apr 2004 09:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvcT-00012s-9Z for pim@optimus.ietf.org; Tue, 20 Apr 2004 09:49:01 -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 JAA17826 for ; Tue, 20 Apr 2004 09:48:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFvcR-0005Dv-BK for pim@ietf.org; Tue, 20 Apr 2004 09:48:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvbS-0004x9-00 for pim@ietf.org; Tue, 20 Apr 2004 09:48:00 -0400 Received: from gate11.itt.com ([151.190.254.106] helo=fwetgfw1r.itt.com) by ietf-mx with esmtp (Exim 4.12) id 1BFvaS-0004Xc-00 for pim@ietf.org; Tue, 20 Apr 2004 09:46:56 -0400 Received: from no.name.available by fwetgfw1r.itt.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Tue, 20 Apr 2004 08:46:56 -0500 Received: from njbridge.avionics.de.ittind.com ([151.190.100.204]) by fwdcmail5.fwdc.de.ittind.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 Apr 2004 08:46:28 -0500 Received: from ACDNJMAILSRV02.acd.de.ittind.com ([151.190.3.218]) by njbridge.avionics.de.ittind.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 09:46:26 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C426DD.DFF590E5" Subject: RE: [pim] Abt : PIM DM periodic nature X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 20 Apr 2004 09:46:26 -0400 Message-ID: <2CA4524FA012F14BAE5D896D492B38681019EA@ACDNJMAILSRV02.acd.de.ittind.com> Thread-Topic: [pim] Abt : PIM DM periodic nature Thread-Index: AcQmjhq1zwV4FsqTSledJjTsdrQKXwASr7+g From: "Nicholas, Jonathan" To: "Rajib" , X-OriginalArrivalTime: 20 Apr 2004 13:46:26.0637 (UTC) FILETIME=[E052D7D0:01C426DD] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C426DD.DFF590E5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =0D One problem with your proposal is it assumes reliable links. =0D =0D Suppose on a link a router sends a Prune(S,G) upstream and another router= wishes to retain membership in (S,G) on that link. If the responding= Join(S,G) is not received by the upstream router and the upstream router's= subsequent Prune(S,G) message is lost, there is no recovery. Other= failure scenarios can be conceived with similar consequences. =0D Beyond that, we really want to retain interoperability with existing= implementations, which isn't really compatible with your proposal. =0D Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communications Division -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Rajib Sent: Monday, April 19, 2004 11:58 PM To: pim@ietf.org Subject: [pim] Abt : PIM DM periodic nature Hi, =0D I will be very happy if someone spare some time and give me some= suggestions on the following issue. =0D =0D As per PIM DM-=0D =0D Prune state has a finite lifetime. When that lifetime expires, data will= again be forwarded down the previously pruned branch. =0D In order to minimize repeated flooding of packets and subsequent pruning= associated with a particular (S,G) pair, PIM-DM uses a state=0D refresh message. This message is sent by the router(s) directly connected= to the source and is propagated throughout the network. When received by a router on its RPF interface, the state refresh message causes= an existing prune state to be refreshed. =0D 1. My question is what was reason of giving finite lifetime to Prune ?=0D 2. In the version 2 it was overcome by the state refresh message. It seems= that version1 was wrong and version 2 corrects it without making any major= change in the protocol. Why not any major change like the following ways- =0D What I am proposing- =0D 1. There will be no periodic timer enable in any router except for the= router directly connected to the source. I mean, when a router gets any= data from it's directly connected source (not from any other router) only= then it will enable a timer for that particualar (S,G). =0D 2. When a particular (S,G) state is created in all routers after arriving= multicast data. This (S,G) state for a particular source and group will= not timeout and hence will not be deleted unless the router gets and= proposed "Multicast session end" message from the router directly= connected to the sender. =0D 3. Pruned branches will never timeout. These pruned branches will only= become active "Dense" when they get grafts.While the multicast session is= in process. =0D 4. When there is no (S,G) data (data for particular source and group) from= the source to directly connected router, for more than a particular time= (say 6 minutes) then this router will assume that the source has finished= or discontinued the session and the router will flood the proposed= "Multicast session end" message for particular (S,G) through out the= network and all those particular (S,G) states in differnet routers will be= deleted. =0D =0D These make the protocol- =0D 1. Very simple. 2.Makes the protocol suitable for both dense and sparse mode. 3. No unnecessary timers in routers. 4. No periodic flooding. 5.No concern regarding prune or any other thing time out.=0D =0D I know my proposal goes far away from PIM DM. But it is PIM DM based. Is it= ok to use ?=0D =0D =0D I will be very happy if you please let me know is there any problem with my= proposal.=0D =0D Rajib Bashir ************************************ This email and any files transmitted with it are proprietary and intended= solely for the use of the individual or entity to whom they are addressed.= If you have received this email in error please notify the sender. Please note that any views or opinions= presented in this email are solely those of the author and do not= necessarily represent those of ITT Industries, Inc. The recipient should check this email and any attachments for the presence= of viruses. ITT Industries accepts no liability for any damage caused by= any virus transmitted by this email. ************************************ ------_=_NextPart_001_01C426DD.DFF590E5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
One problem with your proposal is it= assumes=0D reliable links. 
 
Suppose on a link a router sends a Prune(S,G)= upstream=0D and another router wishes to retain membership in (S,G) on that link. = If=0D the responding Join(S,G) is not received by the upstream router and the= upstream=0D router's subsequent Prune(S,G) message is lost, there is no recovery. = =0D Other failure scenarios can be conceived with similar=0D consequences.
 
Beyond=0D that, we really want to retain interoperability with existing=0D implementations, which isn't really compatible with your=0D proposal.
 
Jonathan Nicholas
Network Systems Engineer
ITT=0D Aerospace/Communications Division
-----Original Message-----
From: pim-admin@ietf.org=0D [mailto:pim-admin@ietf.org]On Behalf Of Rajib
Sent:= Monday,=0D April 19, 2004 11:58 PM
To: pim@ietf.org
Subject:= [pim]=0D Abt : PIM DM periodic nature

Hi,

 

I will=0D be very happy if someone spare some time and give me some= suggestions on=0D the following issue.

 

 

As per=0D PIM DM-

 

Prune state has a= finite=0D lifetime.  When that lifetime expires, data will again be forwarded= down=0D the previously pruned branch.

 

In order to minimize= repeated=0D flooding of packets and subsequent pruning associated with a particular= (S,G)=0D pair, PIM-DM uses a state
refresh message.  This message is sent= by=0D the router(s) directly  connected to the source and is propagated=0D throughout the network.  When
received by a router on its RPF=0D interface, the state refresh message causes an existing prune state to be= =0D refreshed.

 

1. My question is= what was=0D reason of  giving finite lifetime to Prune ?

2. In the version 2 it was= =0D overcome by the state refresh message. It seems that version1 was wrong= and=0D version 2 corrects it without making any major change in the protocol.= Why not=0D any major change like the following ways-

 

What I am= proposing-

 

1. There will be no= periodic timer=0D enable in any router except for the router directly connected to the= source. I=0D mean, when a router gets any data from it's directly connected=0D  source (not from any other router) only then it will enable a= timer=0D for that particualar (S,G).

 

2.  When a=0D particular (S,G) state is created in all routers after arriving= multicast=0D data. This (S,G) state for a particular source and group will not timeout= and=0D hence will not be deleted unless the router gets and proposed "Multicast= =0D session end" message from the router directly connected to the=0D sender.

 

3. Pruned branches will= never=0D timeout. These pruned branches will only become active "Dense" when they= get=0D grafts.While the multicast session is in process.

 

4. When there is no (S,G)= data=0D (data for particular source and group) from the source to directly= connected=0D router, for more than a particular time (say 6  minutes)= then=0D this router will assume that the source has finished or discontinued= the=0D session and the router will flood the proposed=0D "Multicast session end" message for particular (S,G) through= out the=0D network and all those particular (S,G) states in differnet= routers will=0D be deleted.

 

 

These make the=0D protocol-

 

1. Very= simple.

2.Makes the protocol= suitable for=0D both dense and sparse mode.

3. No unnecessary= timers in=0D routers.

4. No periodic=0D flooding.

5.No concern=0D regarding prune or any other thing time out. 

 

I know=0D my proposal goes far away from PIM DM. But it is PIM DM based. Is it ok= to use=0D ?

 

 

I will be very happy if you= please=0D let me know is there any problem with my proposal.

 

Rajib=0D Bashir

************************************
This email and any files= transmitted with it are proprietary and intended solely for the use of the= individual or entity to whom they are addressed. If you have received this= email
in error please notify the sender. Please note that any views or= opinions presented in this email are solely those of the author and do not= necessarily represent those of ITT Industries, Inc.
The recipient= should check this email and any attachments for the presence of viruses.= ITT Industries accepts no liability for any damage caused by any virus= transmitted by= this
email.
************************************
------_=_NextPart_001_01C426DD.DFF590E5-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Tue Apr 20 10:17:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21034 for ; Tue, 20 Apr 2004 10:17:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFw1q-0000Td-91 for pim-archive@odin.ietf.org; Tue, 20 Apr 2004 10:15:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KEFEq2001833 for pim-archive@odin.ietf.org; Tue, 20 Apr 2004 10:15:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvvy-0004sM-Qq for pim-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 10:09:10 -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 KAA19775 for ; Tue, 20 Apr 2004 10:09:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFvvw-0003TL-Nc for pim-web-archive@ietf.org; Tue, 20 Apr 2004 10:09:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvv5-0003DG-00 for pim-web-archive@ietf.org; Tue, 20 Apr 2004 10:08:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFvuY-0002ww-00 for pim-web-archive@ietf.org; Tue, 20 Apr 2004 10:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvmA-0006rv-PK; Tue, 20 Apr 2004 09:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFvcT-00012s-9Z for pim@optimus.ietf.org; Tue, 20 Apr 2004 09:49:01 -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 JAA17826 for ; Tue, 20 Apr 2004 09:48:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFvcR-0005Dv-BK for pim@ietf.org; Tue, 20 Apr 2004 09:48:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFvbS-0004x9-00 for pim@ietf.org; Tue, 20 Apr 2004 09:48:00 -0400 Received: from gate11.itt.com ([151.190.254.106] helo=fwetgfw1r.itt.com) by ietf-mx with esmtp (Exim 4.12) id 1BFvaS-0004Xc-00 for pim@ietf.org; Tue, 20 Apr 2004 09:46:56 -0400 Received: from no.name.available by fwetgfw1r.itt.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Tue, 20 Apr 2004 08:46:56 -0500 Received: from njbridge.avionics.de.ittind.com ([151.190.100.204]) by fwdcmail5.fwdc.de.ittind.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 20 Apr 2004 08:46:28 -0500 Received: from ACDNJMAILSRV02.acd.de.ittind.com ([151.190.3.218]) by njbridge.avionics.de.ittind.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 09:46:26 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C426DD.DFF590E5" Subject: RE: [pim] Abt : PIM DM periodic nature X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 20 Apr 2004 09:46:26 -0400 Message-ID: <2CA4524FA012F14BAE5D896D492B38681019EA@ACDNJMAILSRV02.acd.de.ittind.com> Thread-Topic: [pim] Abt : PIM DM periodic nature Thread-Index: AcQmjhq1zwV4FsqTSledJjTsdrQKXwASr7+g From: "Nicholas, Jonathan" To: "Rajib" , X-OriginalArrivalTime: 20 Apr 2004 13:46:26.0637 (UTC) FILETIME=[E052D7D0:01C426DD] Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C426DD.DFF590E5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =0D One problem with your proposal is it assumes reliable links. =0D =0D Suppose on a link a router sends a Prune(S,G) upstream and another router= wishes to retain membership in (S,G) on that link. If the responding= Join(S,G) is not received by the upstream router and the upstream router's= subsequent Prune(S,G) message is lost, there is no recovery. Other= failure scenarios can be conceived with similar consequences. =0D Beyond that, we really want to retain interoperability with existing= implementations, which isn't really compatible with your proposal. =0D Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communications Division -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Rajib Sent: Monday, April 19, 2004 11:58 PM To: pim@ietf.org Subject: [pim] Abt : PIM DM periodic nature Hi, =0D I will be very happy if someone spare some time and give me some= suggestions on the following issue. =0D =0D As per PIM DM-=0D =0D Prune state has a finite lifetime. When that lifetime expires, data will= again be forwarded down the previously pruned branch. =0D In order to minimize repeated flooding of packets and subsequent pruning= associated with a particular (S,G) pair, PIM-DM uses a state=0D refresh message. This message is sent by the router(s) directly connected= to the source and is propagated throughout the network. When received by a router on its RPF interface, the state refresh message causes= an existing prune state to be refreshed. =0D 1. My question is what was reason of giving finite lifetime to Prune ?=0D 2. In the version 2 it was overcome by the state refresh message. It seems= that version1 was wrong and version 2 corrects it without making any major= change in the protocol. Why not any major change like the following ways- =0D What I am proposing- =0D 1. There will be no periodic timer enable in any router except for the= router directly connected to the source. I mean, when a router gets any= data from it's directly connected source (not from any other router) only= then it will enable a timer for that particualar (S,G). =0D 2. When a particular (S,G) state is created in all routers after arriving= multicast data. This (S,G) state for a particular source and group will= not timeout and hence will not be deleted unless the router gets and= proposed "Multicast session end" message from the router directly= connected to the sender. =0D 3. Pruned branches will never timeout. These pruned branches will only= become active "Dense" when they get grafts.While the multicast session is= in process. =0D 4. When there is no (S,G) data (data for particular source and group) from= the source to directly connected router, for more than a particular time= (say 6 minutes) then this router will assume that the source has finished= or discontinued the session and the router will flood the proposed= "Multicast session end" message for particular (S,G) through out the= network and all those particular (S,G) states in differnet routers will be= deleted. =0D =0D These make the protocol- =0D 1. Very simple. 2.Makes the protocol suitable for both dense and sparse mode. 3. No unnecessary timers in routers. 4. No periodic flooding. 5.No concern regarding prune or any other thing time out.=0D =0D I know my proposal goes far away from PIM DM. But it is PIM DM based. Is it= ok to use ?=0D =0D =0D I will be very happy if you please let me know is there any problem with my= proposal.=0D =0D Rajib Bashir ************************************ This email and any files transmitted with it are proprietary and intended= solely for the use of the individual or entity to whom they are addressed.= If you have received this email in error please notify the sender. Please note that any views or opinions= presented in this email are solely those of the author and do not= necessarily represent those of ITT Industries, Inc. The recipient should check this email and any attachments for the presence= of viruses. ITT Industries accepts no liability for any damage caused by= any virus transmitted by this email. ************************************ ------_=_NextPart_001_01C426DD.DFF590E5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
One problem with your proposal is it= assumes=0D reliable links. 
 
Suppose on a link a router sends a Prune(S,G)= upstream=0D and another router wishes to retain membership in (S,G) on that link. = If=0D the responding Join(S,G) is not received by the upstream router and the= upstream=0D router's subsequent Prune(S,G) message is lost, there is no recovery. = =0D Other failure scenarios can be conceived with similar=0D consequences.
 
Beyond=0D that, we really want to retain interoperability with existing=0D implementations, which isn't really compatible with your=0D proposal.
 
Jonathan Nicholas
Network Systems Engineer
ITT=0D Aerospace/Communications Division
-----Original Message-----
From: pim-admin@ietf.org=0D [mailto:pim-admin@ietf.org]On Behalf Of Rajib
Sent:= Monday,=0D April 19, 2004 11:58 PM
To: pim@ietf.org
Subject:= [pim]=0D Abt : PIM DM periodic nature

Hi,

 

I will=0D be very happy if someone spare some time and give me some= suggestions on=0D the following issue.

 

 

As per=0D PIM DM-

 

Prune state has a= finite=0D lifetime.  When that lifetime expires, data will again be forwarded= down=0D the previously pruned branch.

 

In order to minimize= repeated=0D flooding of packets and subsequent pruning associated with a particular= (S,G)=0D pair, PIM-DM uses a state
refresh message.  This message is sent= by=0D the router(s) directly  connected to the source and is propagated=0D throughout the network.  When
received by a router on its RPF=0D interface, the state refresh message causes an existing prune state to be= =0D refreshed.

 

1. My question is= what was=0D reason of  giving finite lifetime to Prune ?

2. In the version 2 it was= =0D overcome by the state refresh message. It seems that version1 was wrong= and=0D version 2 corrects it without making any major change in the protocol.= Why not=0D any major change like the following ways-

 

What I am= proposing-

 

1. There will be no= periodic timer=0D enable in any router except for the router directly connected to the= source. I=0D mean, when a router gets any data from it's directly connected=0D  source (not from any other router) only then it will enable a= timer=0D for that particualar (S,G).

 

2.  When a=0D particular (S,G) state is created in all routers after arriving= multicast=0D data. This (S,G) state for a particular source and group will not timeout= and=0D hence will not be deleted unless the router gets and proposed "Multicast= =0D session end" message from the router directly connected to the=0D sender.

 

3. Pruned branches will= never=0D timeout. These pruned branches will only become active "Dense" when they= get=0D grafts.While the multicast session is in process.

 

4. When there is no (S,G)= data=0D (data for particular source and group) from the source to directly= connected=0D router, for more than a particular time (say 6  minutes)= then=0D this router will assume that the source has finished or discontinued= the=0D session and the router will flood the proposed=0D "Multicast session end" message for particular (S,G) through= out the=0D network and all those particular (S,G) states in differnet= routers will=0D be deleted.

 

 

These make the=0D protocol-

 

1. Very= simple.

2.Makes the protocol= suitable for=0D both dense and sparse mode.

3. No unnecessary= timers in=0D routers.

4. No periodic=0D flooding.

5.No concern=0D regarding prune or any other thing time out. 

 

I know=0D my proposal goes far away from PIM DM. But it is PIM DM based. Is it ok= to use=0D ?

 

 

I will be very happy if you= please=0D let me know is there any problem with my proposal.

 

Rajib=0D Bashir

************************************
This email and any files= transmitted with it are proprietary and intended solely for the use of the= individual or entity to whom they are addressed. If you have received this= email
in error please notify the sender. Please note that any views or= opinions presented in this email are solely those of the author and do not= necessarily represent those of ITT Industries, Inc.
The recipient= should check this email and any attachments for the presence of viruses.= ITT Industries accepts no liability for any damage caused by any virus= transmitted by= this
email.
************************************
------_=_NextPart_001_01C426DD.DFF590E5-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Tue Apr 20 17:58:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29823 for ; Tue, 20 Apr 2004 17:58:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2qd-0001Fo-Gu; Tue, 20 Apr 2004 17:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1hA-0001Ly-WA for pim@optimus.ietf.org; Tue, 20 Apr 2004 16:18:17 -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 QAA20408 for ; Tue, 20 Apr 2004 16:18:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1h9-0007iO-AD for pim@ietf.org; Tue, 20 Apr 2004 16:18:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1gG-0007ep-00 for pim@ietf.org; Tue, 20 Apr 2004 16:17:21 -0400 Received: from bay16-dav55.bay16.hotmail.com ([65.54.186.235] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BG1fL-0007UW-00 for pim@ietf.org; Tue, 20 Apr 2004 16:16:23 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Apr 2004 13:15:53 -0700 Received: from 209.197.137.136 by bay16-dav55.bay16.hotmail.com with DAV; Tue, 20 Apr 2004 20:15:52 +0000 X-Originating-IP: [209.197.137.136] X-Originating-Email: [rajibullah@hotmail.com] X-Sender: rajibullah@hotmail.com From: "Rajib" To: "Nicholas, Jonathan" Cc: References: <2CA4524FA012F14BAE5D896D492B38681019EA@ACDNJMAILSRV02.acd.de.ittind.com> Subject: Re: [pim] Abt : PIM DM periodic nature Date: Tue, 20 Apr 2004 16:15:33 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C426F2.B521F860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 20 Apr 2004 20:15:53.0216 (UTC) FILETIME=[47E3D800:01C42714] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,EXCUSE_16,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C426F2.B521F860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nicholas, Thanks a lot for your suggestion. But I am not very clear about what you = have mentioned. May be I have misinterpreted. So, can you please = describe me the problem with a diagram or any other way?=20 Yes, I am considering reliable links as it is only at the early stage. = But can you please also suggest me any recovery for the problem you = mentioned. Can I implement acknowledge messages for every Prune and = Graft to overcome this problem? Rajib Graduate student Concordia University, Canada =20 ----- Original Message -----=20 From: Nicholas, Jonathan=20 To: Rajib ; pim@ietf.org=20 Sent: Tuesday, April 20, 2004 9:46 AM Subject: RE: [pim] Abt : PIM DM periodic nature Hello, One problem with your proposal is it assumes reliable links. =20 Suppose on a link a router sends a Prune(S,G) upstream and another = router wishes to retain membership in (S,G) on that link. If the = responding Join(S,G) is not received by the upstream router and the = upstream router's subsequent Prune(S,G) message is lost, there is no = recovery. Other failure scenarios can be conceived with similar = consequences. Beyond that, we really want to retain interoperability with existing = implementations, which isn't really compatible with your proposal. Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communications Division -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of = Rajib Sent: Monday, April 19, 2004 11:58 PM To: pim@ietf.org Subject: [pim] Abt : PIM DM periodic nature Hi, I will be very happy if someone spare some time and give me some = suggestions on the following issue. As per PIM DM-=20 Prune state has a finite lifetime. When that lifetime expires, data = will again be forwarded down the previously pruned branch. In order to minimize repeated flooding of packets and subsequent = pruning associated with a particular (S,G) pair, PIM-DM uses a state=20 refresh message. This message is sent by the router(s) directly = connected to the source and is propagated throughout the network. When received by a router on its RPF interface, the state refresh message = causes an existing prune state to be refreshed. 1. My question is what was reason of giving finite lifetime to = Prune ?=20 2. In the version 2 it was overcome by the state refresh message. It = seems that version1 was wrong and version 2 corrects it without making = any major change in the protocol. Why not any major change like the = following ways- What I am proposing- 1. There will be no periodic timer enable in any router except for = the router directly connected to the source. I mean, when a router gets = any data from it's directly connected source (not from any other = router) only then it will enable a timer for that particualar (S,G). 2. When a particular (S,G) state is created in all routers after = arriving multicast data. This (S,G) state for a particular source and = group will not timeout and hence will not be deleted unless the router = gets and proposed "Multicast session end" message from the router = directly connected to the sender. 3. Pruned branches will never timeout. These pruned branches will = only become active "Dense" when they get grafts.While the multicast = session is in process. 4. When there is no (S,G) data (data for particular source and = group) from the source to directly connected router, for more than a = particular time (say 6 minutes) then this router will assume that the = source has finished or discontinued the session and the router will = flood the proposed "Multicast session end" message for particular (S,G) = through out the network and all those particular (S,G) states in = differnet routers will be deleted. These make the protocol- 1. Very simple. 2.Makes the protocol suitable for both dense and sparse mode. 3. No unnecessary timers in routers. 4. No periodic flooding. 5.No concern regarding prune or any other thing time out.=20 I know my proposal goes far away from PIM DM. But it is PIM DM = based. Is it ok to use ?=20 I will be very happy if you please let me know is there any problem = with my proposal.=20 Rajib Bashir ************************************ This email and any files transmitted with it are proprietary and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the sender. Please note that any views or = opinions presented in this email are solely those of the author and do = not necessarily represent those of ITT Industries, Inc. The recipient should check this email and any attachments for = the presence of viruses. ITT Industries accepts no liability for any = damage caused by any virus transmitted by this email. ************************************ =20 ------=_NextPart_000_001A_01C426F2.B521F860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Nicholas,

 

Thanks a lot for your = suggestion.=20 But I am not very clear about what you have mentioned. May be I have=20 misinterpreted. So, can you please describe me the problem with a = diagram=20 or any other way? 

 

Yes, I am considering = reliable links=20 as it is only at the early stage. But can you please also suggest = me any=20 recovery for the problem you mentioned. Can I implement acknowledge = messages for=20 every Prune and Graft to overcome this problem?

 

Rajib

Graduate = student

Concordia=20 University,=20 Canada

 

 
----- Original Message -----
From:=20 Nicholas, Jonathan =
Sent: Tuesday, April 20, 2004 = 9:46=20 AM
Subject: RE: [pim] Abt : PIM DM = periodic=20 nature

Hello,
 
One problem with your proposal is it = assumes=20 reliable links. 
 
Suppose on a link a router sends a = Prune(S,G)=20 upstream and another router wishes to retain membership in (S,G) on = that=20 link.  If the responding Join(S,G) is not received by the = upstream router=20 and the upstream router's subsequent Prune(S,G) message is lost, there = is no=20 recovery.  Other failure scenarios can be conceived with similar=20 consequences.
 
Beyond that, we really want to = retain=20 interoperability with existing implementations, which isn't really = compatible=20 with your proposal.
 
Jonathan Nicholas
Network Systems = Engineer
ITT=20 Aerospace/Communications Division
-----Original Message-----
From: = pim-admin@ietf.org=20 [mailto:pim-admin@ietf.org]On Behalf Of Rajib
Sent: = Monday,=20 April 19, 2004 11:58 PM
To: = pim@ietf.org
Subject: [pim]=20 Abt : PIM DM periodic nature

Hi,

 

I=20 will be very happy if someone spare some time and give me some=20 suggestions on the following issue.

 

 

As=20 per PIM DM-

 

Prune state has a = finite=20 lifetime.  When that lifetime expires, data will again be = forwarded=20 down the previously pruned branch.

 

In order to = minimize repeated=20 flooding of packets and subsequent pruning associated with a = particular=20 (S,G) pair, PIM-DM uses a state
refresh message.  This = message is=20 sent by the router(s) directly  connected to the source and is=20 propagated throughout the network.  When
received by a = router on its=20 RPF interface, the state refresh message causes an existing prune = state to=20 be refreshed.

 

1. My question is = what was=20 reason of  giving finite lifetime to Prune ?

2. In the version 2 it = was=20 overcome by the state refresh message. It seems that version1 was = wrong and=20 version 2 corrects it without making any major change in the = protocol. Why=20 not any major change like the following ways-

 

What I am = proposing-

 

1. There will be no = periodic=20 timer enable in any router except for the router directly connected = to the=20 source. I mean, when a router gets any data from it's directly=20 connected  source (not from any other router) only then it = will=20 enable a timer for that particualar (S,G).

 

2.  When a=20 particular (S,G) state is created in all routers after arriving = multicast data. This (S,G) state for a particular source and group = will not=20 timeout and hence will not be deleted unless the router gets and = proposed=20 "Multicast session end" message from the router directly connected = to the=20 sender.

 

3. Pruned branches = will never=20 timeout. These pruned branches will only become active "Dense" when = they get=20 grafts.While the multicast session is in process.

 

4. When there is no = (S,G) data=20 (data for particular source and group) from the source to directly = connected=20 router, for more than a particular time (say 6 =  minutes) then=20 this router will assume that the source has finished or = discontinued=20 the session and the router will flood the proposed=20 "Multicast session end" message for particular (S,G) = through out=20 the network and all those particular (S,G) states in differnet=20 routers will be deleted.

 

 

These make the=20 protocol-

 

1. Very = simple.

2.Makes the protocol = suitable=20 for both dense and sparse mode.

3. No unnecessary = timers in=20 routers.

4. No periodic=20 flooding.

5.No concern=20 regarding prune or any other thing time = out. 

 

I=20 know my proposal goes far away from PIM DM. But it is PIM DM based. = Is it ok=20 to use ?

 

 

I will be very happy = if you=20 please let me know is there any problem with my proposal. =

 

Rajib=20 Bashir

************************************
This = email and any=20 files transmitted with it are proprietary and intended solely = for the=20 use of the individual or entity to whom they are addressed. If = you have=20 received this email
in error please notify the sender. Please = note=20 that any views or opinions presented in this email are solely = those of=20 the author and do not necessarily represent those of ITT = Industries,=20 Inc.
The recipient should check this email and any = attachments for=20 the presence of viruses. ITT Industries accepts no liability for = any=20 damage caused by any virus transmitted by=20 = this
email.
************************************
------=_NextPart_000_001A_01C426F2.B521F860-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Tue Apr 20 18:15:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02250 for ; Tue, 20 Apr 2004 18:15:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Jc-0001AG-Sn; Tue, 20 Apr 2004 18:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2wm-0004Cc-AA for pim@optimus.ietf.org; Tue, 20 Apr 2004 17:38:28 -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 RAA27838 for ; Tue, 20 Apr 2004 17:38:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG2wj-0001rX-SY for pim@ietf.org; Tue, 20 Apr 2004 17:38:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2vu-0001mi-00 for pim@ietf.org; Tue, 20 Apr 2004 17:37:35 -0400 Received: from bay16-dav45.bay16.hotmail.com ([65.54.186.225] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BG2vL-0001hI-00 for pim@ietf.org; Tue, 20 Apr 2004 17:36:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Apr 2004 14:36:29 -0700 Received: from 209.197.137.136 by bay16-dav45.bay16.hotmail.com with DAV; Tue, 20 Apr 2004 21:36:29 +0000 X-Originating-IP: [209.197.137.136] X-Originating-Email: [rajibullah@hotmail.com] X-Sender: rajibullah@hotmail.com From: "Rajib" To: References: <2CA4524FA012F14BAE5D896D492B38681019EA@ACDNJMAILSRV02.acd.de.ittind.com> Subject: Re: [pim] Abt : PIM DM periodic nature Date: Tue, 20 Apr 2004 17:36:19 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C426FD.FD47A990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 20 Apr 2004 21:36:29.0296 (UTC) FILETIME=[8A6B1700:01C4271F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,EXCUSE_16,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C426FD.FD47A990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nicholas, Thanks a lot for your suggestion. But I am not very clear about what you = have mentioned. May be I have misinterpreted. So, can you please = describe me the problem with a diagram or any other way?=20 Yes, I am considering reliable links as it is only at the early stage. = But can you please also suggest me any recovery for the problem you = mentioned. Can I implement acknowledge messages for every Prune and = Graft to overcome these problems? Rajib Graduate student Concordia University, Canada ----- Original Message -----=20 From: Nicholas, Jonathan=20 To: Rajib ; pim@ietf.org=20 Sent: Tuesday, April 20, 2004 9:46 AM Subject: RE: [pim] Abt : PIM DM periodic nature Hello, One problem with your proposal is it assumes reliable links. =20 Suppose on a link a router sends a Prune(S,G) upstream and another = router wishes to retain membership in (S,G) on that link. If the = responding Join(S,G) is not received by the upstream router and the = upstream router's subsequent Prune(S,G) message is lost, there is no = recovery. Other failure scenarios can be conceived with similar = consequences. Beyond that, we really want to retain interoperability with existing = implementations, which isn't really compatible with your proposal. Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communications Division -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of = Rajib Sent: Monday, April 19, 2004 11:58 PM To: pim@ietf.org Subject: [pim] Abt : PIM DM periodic nature Hi, I will be very happy if someone spare some time and give me some = suggestions on the following issue. As per PIM DM-=20 Prune state has a finite lifetime. When that lifetime expires, data = will again be forwarded down the previously pruned branch. In order to minimize repeated flooding of packets and subsequent = pruning associated with a particular (S,G) pair, PIM-DM uses a state=20 refresh message. This message is sent by the router(s) directly = connected to the source and is propagated throughout the network. When received by a router on its RPF interface, the state refresh message = causes an existing prune state to be refreshed. 1. My question is what was reason of giving finite lifetime to = Prune ?=20 2. In the version 2 it was overcome by the state refresh message. It = seems that version1 was wrong and version 2 corrects it without making = any major change in the protocol. Why not any major change like the = following ways- What I am proposing- 1. There will be no periodic timer enable in any router except for = the router directly connected to the source. I mean, when a router gets = any data from it's directly connected source (not from any other = router) only then it will enable a timer for that particualar (S,G). 2. When a particular (S,G) state is created in all routers after = arriving multicast data. This (S,G) state for a particular source and = group will not timeout and hence will not be deleted unless the router = gets and proposed "Multicast session end" message from the router = directly connected to the sender. 3. Pruned branches will never timeout. These pruned branches will = only become active "Dense" when they get grafts.While the multicast = session is in process. 4. When there is no (S,G) data (data for particular source and = group) from the source to directly connected router, for more than a = particular time (say 6 minutes) then this router will assume that the = source has finished or discontinued the session and the router will = flood the proposed "Multicast session end" message for particular (S,G) = through out the network and all those particular (S,G) states in = differnet routers will be deleted. These make the protocol- 1. Very simple. 2.Makes the protocol suitable for both dense and sparse mode. 3. No unnecessary timers in routers. 4. No periodic flooding. 5.No concern regarding prune or any other thing time out.=20 I know my proposal goes far away from PIM DM. But it is PIM DM = based. Is it ok to use ?=20 I will be very happy if you please let me know is there any problem = with my proposal.=20 Rajib Bashir ************************************ This email and any files transmitted with it are proprietary and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the sender. Please note that any views or = opinions presented in this email are solely those of the author and do = not necessarily represent those of ITT Industries, Inc. The recipient should check this email and any attachments for = the presence of viruses. ITT Industries accepts no liability for any = damage caused by any virus transmitted by this email. ************************************ =20 ------=_NextPart_000_0024_01C426FD.FD47A990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Nicholas,

 

Thanks a lot for your = suggestion.=20 But I am not very clear about what you have mentioned. May be I have=20 misinterpreted. So, can you please describe me the problem with a = diagram=20 or any other way? 

 

Yes, I am considering = reliable links=20 as it is only at the early stage. But can you please also suggest = me any=20 recovery for the problem you mentioned. Can I implement acknowledge = messages for=20 every Prune and Graft to overcome these problems?

 

Rajib

Graduate = student

Concordia=20 University,=20 Canada

 
 
 
 
----- Original Message -----
From:=20 Nicholas, Jonathan =
Sent: Tuesday, April 20, 2004 = 9:46=20 AM
Subject: RE: [pim] Abt : PIM DM = periodic=20 nature

Hello,
 
One problem with your proposal is it = assumes=20 reliable links. 
 
Suppose on a link a router sends a = Prune(S,G)=20 upstream and another router wishes to retain membership in (S,G) on = that=20 link.  If the responding Join(S,G) is not received by the = upstream router=20 and the upstream router's subsequent Prune(S,G) message is lost, there = is no=20 recovery.  Other failure scenarios can be conceived with similar=20 consequences.
 
Beyond that, we really want to = retain=20 interoperability with existing implementations, which isn't really = compatible=20 with your proposal.
 
Jonathan Nicholas
Network Systems = Engineer
ITT=20 Aerospace/Communications Division
-----Original Message-----
From: = pim-admin@ietf.org=20 [mailto:pim-admin@ietf.org]On Behalf Of Rajib
Sent: = Monday,=20 April 19, 2004 11:58 PM
To: = pim@ietf.org
Subject: [pim]=20 Abt : PIM DM periodic nature

Hi,

 

I=20 will be very happy if someone spare some time and give me some=20 suggestions on the following issue.

 

 

As=20 per PIM DM-

 

Prune state has a = finite=20 lifetime.  When that lifetime expires, data will again be = forwarded=20 down the previously pruned branch.

 

In order to = minimize repeated=20 flooding of packets and subsequent pruning associated with a = particular=20 (S,G) pair, PIM-DM uses a state
refresh message.  This = message is=20 sent by the router(s) directly  connected to the source and is=20 propagated throughout the network.  When
received by a = router on its=20 RPF interface, the state refresh message causes an existing prune = state to=20 be refreshed.

 

1. My question is = what was=20 reason of  giving finite lifetime to Prune ?

2. In the version 2 it = was=20 overcome by the state refresh message. It seems that version1 was = wrong and=20 version 2 corrects it without making any major change in the = protocol. Why=20 not any major change like the following ways-

 

What I am = proposing-

 

1. There will be no = periodic=20 timer enable in any router except for the router directly connected = to the=20 source. I mean, when a router gets any data from it's directly=20 connected  source (not from any other router) only then it = will=20 enable a timer for that particualar (S,G).

 

2.  When a=20 particular (S,G) state is created in all routers after arriving = multicast data. This (S,G) state for a particular source and group = will not=20 timeout and hence will not be deleted unless the router gets and = proposed=20 "Multicast session end" message from the router directly connected = to the=20 sender.

 

3. Pruned branches = will never=20 timeout. These pruned branches will only become active "Dense" when = they get=20 grafts.While the multicast session is in process.

 

4. When there is no = (S,G) data=20 (data for particular source and group) from the source to directly = connected=20 router, for more than a particular time (say 6 =  minutes) then=20 this router will assume that the source has finished or = discontinued=20 the session and the router will flood the proposed=20 "Multicast session end" message for particular (S,G) = through out=20 the network and all those particular (S,G) states in differnet=20 routers will be deleted.

 

 

These make the=20 protocol-

 

1. Very = simple.

2.Makes the protocol = suitable=20 for both dense and sparse mode.

3. No unnecessary = timers in=20 routers.

4. No periodic=20 flooding.

5.No concern=20 regarding prune or any other thing time = out. 

 

I=20 know my proposal goes far away from PIM DM. But it is PIM DM based. = Is it ok=20 to use ?

 

 

I will be very happy = if you=20 please let me know is there any problem with my proposal. =

 

Rajib=20 Bashir

************************************
This = email and any=20 files transmitted with it are proprietary and intended solely = for the=20 use of the individual or entity to whom they are addressed. If = you have=20 received this email
in error please notify the sender. Please = note=20 that any views or opinions presented in this email are solely = those of=20 the author and do not necessarily represent those of ITT = Industries,=20 Inc.
The recipient should check this email and any = attachments for=20 the presence of viruses. ITT Industries accepts no liability for = any=20 damage caused by any virus transmitted by=20 = this
email.
************************************
------=_NextPart_000_0024_01C426FD.FD47A990-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Tue Apr 20 18:22:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03313 for ; Tue, 20 Apr 2004 18:22:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Vo-00057N-R2 for pim-archive@odin.ietf.org; Tue, 20 Apr 2004 18:14:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KMEeQA019668 for pim-archive@odin.ietf.org; Tue, 20 Apr 2004 18:14:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Gy-0006Su-9V for pim-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 17:59:20 -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 RAA29860 for ; Tue, 20 Apr 2004 17:59:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG3Gv-0004H8-LO for pim-web-archive@ietf.org; Tue, 20 Apr 2004 17:59:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG3G0-0004Dk-00 for pim-web-archive@ietf.org; Tue, 20 Apr 2004 17:58:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG3FT-0004AW-00 for pim-web-archive@ietf.org; Tue, 20 Apr 2004 17:57:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2qd-0001Fo-Gu; Tue, 20 Apr 2004 17:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1hA-0001Ly-WA for pim@optimus.ietf.org; Tue, 20 Apr 2004 16:18:17 -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 QAA20408 for ; Tue, 20 Apr 2004 16:18:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1h9-0007iO-AD for pim@ietf.org; Tue, 20 Apr 2004 16:18:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1gG-0007ep-00 for pim@ietf.org; Tue, 20 Apr 2004 16:17:21 -0400 Received: from bay16-dav55.bay16.hotmail.com ([65.54.186.235] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BG1fL-0007UW-00 for pim@ietf.org; Tue, 20 Apr 2004 16:16:23 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Apr 2004 13:15:53 -0700 Received: from 209.197.137.136 by bay16-dav55.bay16.hotmail.com with DAV; Tue, 20 Apr 2004 20:15:52 +0000 X-Originating-IP: [209.197.137.136] X-Originating-Email: [rajibullah@hotmail.com] X-Sender: rajibullah@hotmail.com From: "Rajib" To: "Nicholas, Jonathan" Cc: References: <2CA4524FA012F14BAE5D896D492B38681019EA@ACDNJMAILSRV02.acd.de.ittind.com> Subject: Re: [pim] Abt : PIM DM periodic nature Date: Tue, 20 Apr 2004 16:15:33 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C426F2.B521F860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 20 Apr 2004 20:15:53.0216 (UTC) FILETIME=[47E3D800:01C42714] Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,EXCUSE_16,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C426F2.B521F860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nicholas, Thanks a lot for your suggestion. But I am not very clear about what you = have mentioned. May be I have misinterpreted. So, can you please = describe me the problem with a diagram or any other way?=20 Yes, I am considering reliable links as it is only at the early stage. = But can you please also suggest me any recovery for the problem you = mentioned. Can I implement acknowledge messages for every Prune and = Graft to overcome this problem? Rajib Graduate student Concordia University, Canada =20 ----- Original Message -----=20 From: Nicholas, Jonathan=20 To: Rajib ; pim@ietf.org=20 Sent: Tuesday, April 20, 2004 9:46 AM Subject: RE: [pim] Abt : PIM DM periodic nature Hello, One problem with your proposal is it assumes reliable links. =20 Suppose on a link a router sends a Prune(S,G) upstream and another = router wishes to retain membership in (S,G) on that link. If the = responding Join(S,G) is not received by the upstream router and the = upstream router's subsequent Prune(S,G) message is lost, there is no = recovery. Other failure scenarios can be conceived with similar = consequences. Beyond that, we really want to retain interoperability with existing = implementations, which isn't really compatible with your proposal. Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communications Division -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of = Rajib Sent: Monday, April 19, 2004 11:58 PM To: pim@ietf.org Subject: [pim] Abt : PIM DM periodic nature Hi, I will be very happy if someone spare some time and give me some = suggestions on the following issue. As per PIM DM-=20 Prune state has a finite lifetime. When that lifetime expires, data = will again be forwarded down the previously pruned branch. In order to minimize repeated flooding of packets and subsequent = pruning associated with a particular (S,G) pair, PIM-DM uses a state=20 refresh message. This message is sent by the router(s) directly = connected to the source and is propagated throughout the network. When received by a router on its RPF interface, the state refresh message = causes an existing prune state to be refreshed. 1. My question is what was reason of giving finite lifetime to = Prune ?=20 2. In the version 2 it was overcome by the state refresh message. It = seems that version1 was wrong and version 2 corrects it without making = any major change in the protocol. Why not any major change like the = following ways- What I am proposing- 1. There will be no periodic timer enable in any router except for = the router directly connected to the source. I mean, when a router gets = any data from it's directly connected source (not from any other = router) only then it will enable a timer for that particualar (S,G). 2. When a particular (S,G) state is created in all routers after = arriving multicast data. This (S,G) state for a particular source and = group will not timeout and hence will not be deleted unless the router = gets and proposed "Multicast session end" message from the router = directly connected to the sender. 3. Pruned branches will never timeout. These pruned branches will = only become active "Dense" when they get grafts.While the multicast = session is in process. 4. When there is no (S,G) data (data for particular source and = group) from the source to directly connected router, for more than a = particular time (say 6 minutes) then this router will assume that the = source has finished or discontinued the session and the router will = flood the proposed "Multicast session end" message for particular (S,G) = through out the network and all those particular (S,G) states in = differnet routers will be deleted. These make the protocol- 1. Very simple. 2.Makes the protocol suitable for both dense and sparse mode. 3. No unnecessary timers in routers. 4. No periodic flooding. 5.No concern regarding prune or any other thing time out.=20 I know my proposal goes far away from PIM DM. But it is PIM DM = based. Is it ok to use ?=20 I will be very happy if you please let me know is there any problem = with my proposal.=20 Rajib Bashir ************************************ This email and any files transmitted with it are proprietary and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the sender. Please note that any views or = opinions presented in this email are solely those of the author and do = not necessarily represent those of ITT Industries, Inc. The recipient should check this email and any attachments for = the presence of viruses. ITT Industries accepts no liability for any = damage caused by any virus transmitted by this email. ************************************ =20 ------=_NextPart_000_001A_01C426F2.B521F860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Nicholas,

 

Thanks a lot for your = suggestion.=20 But I am not very clear about what you have mentioned. May be I have=20 misinterpreted. So, can you please describe me the problem with a = diagram=20 or any other way? 

 

Yes, I am considering = reliable links=20 as it is only at the early stage. But can you please also suggest = me any=20 recovery for the problem you mentioned. Can I implement acknowledge = messages for=20 every Prune and Graft to overcome this problem?

 

Rajib

Graduate = student

Concordia=20 University,=20 Canada

 

 
----- Original Message -----
From:=20 Nicholas, Jonathan =
Sent: Tuesday, April 20, 2004 = 9:46=20 AM
Subject: RE: [pim] Abt : PIM DM = periodic=20 nature

Hello,
 
One problem with your proposal is it = assumes=20 reliable links. 
 
Suppose on a link a router sends a = Prune(S,G)=20 upstream and another router wishes to retain membership in (S,G) on = that=20 link.  If the responding Join(S,G) is not received by the = upstream router=20 and the upstream router's subsequent Prune(S,G) message is lost, there = is no=20 recovery.  Other failure scenarios can be conceived with similar=20 consequences.
 
Beyond that, we really want to = retain=20 interoperability with existing implementations, which isn't really = compatible=20 with your proposal.
 
Jonathan Nicholas
Network Systems = Engineer
ITT=20 Aerospace/Communications Division
-----Original Message-----
From: = pim-admin@ietf.org=20 [mailto:pim-admin@ietf.org]On Behalf Of Rajib
Sent: = Monday,=20 April 19, 2004 11:58 PM
To: = pim@ietf.org
Subject: [pim]=20 Abt : PIM DM periodic nature

Hi,

 

I=20 will be very happy if someone spare some time and give me some=20 suggestions on the following issue.

 

 

As=20 per PIM DM-

 

Prune state has a = finite=20 lifetime.  When that lifetime expires, data will again be = forwarded=20 down the previously pruned branch.

 

In order to = minimize repeated=20 flooding of packets and subsequent pruning associated with a = particular=20 (S,G) pair, PIM-DM uses a state
refresh message.  This = message is=20 sent by the router(s) directly  connected to the source and is=20 propagated throughout the network.  When
received by a = router on its=20 RPF interface, the state refresh message causes an existing prune = state to=20 be refreshed.

 

1. My question is = what was=20 reason of  giving finite lifetime to Prune ?

2. In the version 2 it = was=20 overcome by the state refresh message. It seems that version1 was = wrong and=20 version 2 corrects it without making any major change in the = protocol. Why=20 not any major change like the following ways-

 

What I am = proposing-

 

1. There will be no = periodic=20 timer enable in any router except for the router directly connected = to the=20 source. I mean, when a router gets any data from it's directly=20 connected  source (not from any other router) only then it = will=20 enable a timer for that particualar (S,G).

 

2.  When a=20 particular (S,G) state is created in all routers after arriving = multicast data. This (S,G) state for a particular source and group = will not=20 timeout and hence will not be deleted unless the router gets and = proposed=20 "Multicast session end" message from the router directly connected = to the=20 sender.

 

3. Pruned branches = will never=20 timeout. These pruned branches will only become active "Dense" when = they get=20 grafts.While the multicast session is in process.

 

4. When there is no = (S,G) data=20 (data for particular source and group) from the source to directly = connected=20 router, for more than a particular time (say 6 =  minutes) then=20 this router will assume that the source has finished or = discontinued=20 the session and the router will flood the proposed=20 "Multicast session end" message for particular (S,G) = through out=20 the network and all those particular (S,G) states in differnet=20 routers will be deleted.

 

 

These make the=20 protocol-

 

1. Very = simple.

2.Makes the protocol = suitable=20 for both dense and sparse mode.

3. No unnecessary = timers in=20 routers.

4. No periodic=20 flooding.

5.No concern=20 regarding prune or any other thing time = out. 

 

I=20 know my proposal goes far away from PIM DM. But it is PIM DM based. = Is it ok=20 to use ?

 

 

I will be very happy = if you=20 please let me know is there any problem with my proposal. =

 

Rajib=20 Bashir

************************************
This = email and any=20 files transmitted with it are proprietary and intended solely = for the=20 use of the individual or entity to whom they are addressed. If = you have=20 received this email
in error please notify the sender. Please = note=20 that any views or opinions presented in this email are solely = those of=20 the author and do not necessarily represent those of ITT = Industries,=20 Inc.
The recipient should check this email and any = attachments for=20 the presence of viruses. ITT Industries accepts no liability for = any=20 damage caused by any virus transmitted by=20 = this
email.
************************************
------=_NextPart_000_001A_01C426F2.B521F860-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Tue Apr 20 18:40:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04462 for ; Tue, 20 Apr 2004 18:40:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3k4-000735-N3 for pim-archive@odin.ietf.org; Tue, 20 Apr 2004 18:29:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KMTO3l027067 for pim-archive@odin.ietf.org; Tue, 20 Apr 2004 18:29:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Za-0000gz-PB for pim-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 18:18: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 SAA02835 for ; Tue, 20 Apr 2004 18:18:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG3ZX-0006lD-PE for pim-web-archive@ietf.org; Tue, 20 Apr 2004 18:18:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG3YE-0006W3-00 for pim-web-archive@ietf.org; Tue, 20 Apr 2004 18:17:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG3WX-0006E0-00 for pim-web-archive@ietf.org; Tue, 20 Apr 2004 18:15:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Jc-0001AG-Sn; Tue, 20 Apr 2004 18:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2wm-0004Cc-AA for pim@optimus.ietf.org; Tue, 20 Apr 2004 17:38:28 -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 RAA27838 for ; Tue, 20 Apr 2004 17:38:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG2wj-0001rX-SY for pim@ietf.org; Tue, 20 Apr 2004 17:38:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2vu-0001mi-00 for pim@ietf.org; Tue, 20 Apr 2004 17:37:35 -0400 Received: from bay16-dav45.bay16.hotmail.com ([65.54.186.225] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BG2vL-0001hI-00 for pim@ietf.org; Tue, 20 Apr 2004 17:36:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Apr 2004 14:36:29 -0700 Received: from 209.197.137.136 by bay16-dav45.bay16.hotmail.com with DAV; Tue, 20 Apr 2004 21:36:29 +0000 X-Originating-IP: [209.197.137.136] X-Originating-Email: [rajibullah@hotmail.com] X-Sender: rajibullah@hotmail.com From: "Rajib" To: References: <2CA4524FA012F14BAE5D896D492B38681019EA@ACDNJMAILSRV02.acd.de.ittind.com> Subject: Re: [pim] Abt : PIM DM periodic nature Date: Tue, 20 Apr 2004 17:36:19 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C426FD.FD47A990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 20 Apr 2004 21:36:29.0296 (UTC) FILETIME=[8A6B1700:01C4271F] Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,EXCUSE_16,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C426FD.FD47A990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nicholas, Thanks a lot for your suggestion. But I am not very clear about what you = have mentioned. May be I have misinterpreted. So, can you please = describe me the problem with a diagram or any other way?=20 Yes, I am considering reliable links as it is only at the early stage. = But can you please also suggest me any recovery for the problem you = mentioned. Can I implement acknowledge messages for every Prune and = Graft to overcome these problems? Rajib Graduate student Concordia University, Canada ----- Original Message -----=20 From: Nicholas, Jonathan=20 To: Rajib ; pim@ietf.org=20 Sent: Tuesday, April 20, 2004 9:46 AM Subject: RE: [pim] Abt : PIM DM periodic nature Hello, One problem with your proposal is it assumes reliable links. =20 Suppose on a link a router sends a Prune(S,G) upstream and another = router wishes to retain membership in (S,G) on that link. If the = responding Join(S,G) is not received by the upstream router and the = upstream router's subsequent Prune(S,G) message is lost, there is no = recovery. Other failure scenarios can be conceived with similar = consequences. Beyond that, we really want to retain interoperability with existing = implementations, which isn't really compatible with your proposal. Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communications Division -----Original Message----- From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of = Rajib Sent: Monday, April 19, 2004 11:58 PM To: pim@ietf.org Subject: [pim] Abt : PIM DM periodic nature Hi, I will be very happy if someone spare some time and give me some = suggestions on the following issue. As per PIM DM-=20 Prune state has a finite lifetime. When that lifetime expires, data = will again be forwarded down the previously pruned branch. In order to minimize repeated flooding of packets and subsequent = pruning associated with a particular (S,G) pair, PIM-DM uses a state=20 refresh message. This message is sent by the router(s) directly = connected to the source and is propagated throughout the network. When received by a router on its RPF interface, the state refresh message = causes an existing prune state to be refreshed. 1. My question is what was reason of giving finite lifetime to = Prune ?=20 2. In the version 2 it was overcome by the state refresh message. It = seems that version1 was wrong and version 2 corrects it without making = any major change in the protocol. Why not any major change like the = following ways- What I am proposing- 1. There will be no periodic timer enable in any router except for = the router directly connected to the source. I mean, when a router gets = any data from it's directly connected source (not from any other = router) only then it will enable a timer for that particualar (S,G). 2. When a particular (S,G) state is created in all routers after = arriving multicast data. This (S,G) state for a particular source and = group will not timeout and hence will not be deleted unless the router = gets and proposed "Multicast session end" message from the router = directly connected to the sender. 3. Pruned branches will never timeout. These pruned branches will = only become active "Dense" when they get grafts.While the multicast = session is in process. 4. When there is no (S,G) data (data for particular source and = group) from the source to directly connected router, for more than a = particular time (say 6 minutes) then this router will assume that the = source has finished or discontinued the session and the router will = flood the proposed "Multicast session end" message for particular (S,G) = through out the network and all those particular (S,G) states in = differnet routers will be deleted. These make the protocol- 1. Very simple. 2.Makes the protocol suitable for both dense and sparse mode. 3. No unnecessary timers in routers. 4. No periodic flooding. 5.No concern regarding prune or any other thing time out.=20 I know my proposal goes far away from PIM DM. But it is PIM DM = based. Is it ok to use ?=20 I will be very happy if you please let me know is there any problem = with my proposal.=20 Rajib Bashir ************************************ This email and any files transmitted with it are proprietary and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the sender. Please note that any views or = opinions presented in this email are solely those of the author and do = not necessarily represent those of ITT Industries, Inc. The recipient should check this email and any attachments for = the presence of viruses. ITT Industries accepts no liability for any = damage caused by any virus transmitted by this email. ************************************ =20 ------=_NextPart_000_0024_01C426FD.FD47A990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Nicholas,

 

Thanks a lot for your = suggestion.=20 But I am not very clear about what you have mentioned. May be I have=20 misinterpreted. So, can you please describe me the problem with a = diagram=20 or any other way? 

 

Yes, I am considering = reliable links=20 as it is only at the early stage. But can you please also suggest = me any=20 recovery for the problem you mentioned. Can I implement acknowledge = messages for=20 every Prune and Graft to overcome these problems?

 

Rajib

Graduate = student

Concordia=20 University,=20 Canada

 
 
 
 
----- Original Message -----
From:=20 Nicholas, Jonathan =
Sent: Tuesday, April 20, 2004 = 9:46=20 AM
Subject: RE: [pim] Abt : PIM DM = periodic=20 nature

Hello,
 
One problem with your proposal is it = assumes=20 reliable links. 
 
Suppose on a link a router sends a = Prune(S,G)=20 upstream and another router wishes to retain membership in (S,G) on = that=20 link.  If the responding Join(S,G) is not received by the = upstream router=20 and the upstream router's subsequent Prune(S,G) message is lost, there = is no=20 recovery.  Other failure scenarios can be conceived with similar=20 consequences.
 
Beyond that, we really want to = retain=20 interoperability with existing implementations, which isn't really = compatible=20 with your proposal.
 
Jonathan Nicholas
Network Systems = Engineer
ITT=20 Aerospace/Communications Division
-----Original Message-----
From: = pim-admin@ietf.org=20 [mailto:pim-admin@ietf.org]On Behalf Of Rajib
Sent: = Monday,=20 April 19, 2004 11:58 PM
To: = pim@ietf.org
Subject: [pim]=20 Abt : PIM DM periodic nature

Hi,

 

I=20 will be very happy if someone spare some time and give me some=20 suggestions on the following issue.

 

 

As=20 per PIM DM-

 

Prune state has a = finite=20 lifetime.  When that lifetime expires, data will again be = forwarded=20 down the previously pruned branch.

 

In order to = minimize repeated=20 flooding of packets and subsequent pruning associated with a = particular=20 (S,G) pair, PIM-DM uses a state
refresh message.  This = message is=20 sent by the router(s) directly  connected to the source and is=20 propagated throughout the network.  When
received by a = router on its=20 RPF interface, the state refresh message causes an existing prune = state to=20 be refreshed.

 

1. My question is = what was=20 reason of  giving finite lifetime to Prune ?

2. In the version 2 it = was=20 overcome by the state refresh message. It seems that version1 was = wrong and=20 version 2 corrects it without making any major change in the = protocol. Why=20 not any major change like the following ways-

 

What I am = proposing-

 

1. There will be no = periodic=20 timer enable in any router except for the router directly connected = to the=20 source. I mean, when a router gets any data from it's directly=20 connected  source (not from any other router) only then it = will=20 enable a timer for that particualar (S,G).

 

2.  When a=20 particular (S,G) state is created in all routers after arriving = multicast data. This (S,G) state for a particular source and group = will not=20 timeout and hence will not be deleted unless the router gets and = proposed=20 "Multicast session end" message from the router directly connected = to the=20 sender.

 

3. Pruned branches = will never=20 timeout. These pruned branches will only become active "Dense" when = they get=20 grafts.While the multicast session is in process.

 

4. When there is no = (S,G) data=20 (data for particular source and group) from the source to directly = connected=20 router, for more than a particular time (say 6 =  minutes) then=20 this router will assume that the source has finished or = discontinued=20 the session and the router will flood the proposed=20 "Multicast session end" message for particular (S,G) = through out=20 the network and all those particular (S,G) states in differnet=20 routers will be deleted.

 

 

These make the=20 protocol-

 

1. Very = simple.

2.Makes the protocol = suitable=20 for both dense and sparse mode.

3. No unnecessary = timers in=20 routers.

4. No periodic=20 flooding.

5.No concern=20 regarding prune or any other thing time = out. 

 

I=20 know my proposal goes far away from PIM DM. But it is PIM DM based. = Is it ok=20 to use ?

 

 

I will be very happy = if you=20 please let me know is there any problem with my proposal. =

 

Rajib=20 Bashir

************************************
This = email and any=20 files transmitted with it are proprietary and intended solely = for the=20 use of the individual or entity to whom they are addressed. If = you have=20 received this email
in error please notify the sender. Please = note=20 that any views or opinions presented in this email are solely = those of=20 the author and do not necessarily represent those of ITT = Industries,=20 Inc.
The recipient should check this email and any = attachments for=20 the presence of viruses. ITT Industries accepts no liability for = any=20 damage caused by any virus transmitted by=20 = this
email.
************************************
------=_NextPart_000_0024_01C426FD.FD47A990-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Tue Apr 20 19:08:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05859 for ; Tue, 20 Apr 2004 19:08:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4Cj-0004So-GR; Tue, 20 Apr 2004 18:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3sh-0002u4-5H for pim@optimus.ietf.org; Tue, 20 Apr 2004 18:38:19 -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 SAA04373 for ; Tue, 20 Apr 2004 18:38:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG3se-0000k2-6J for pim@ietf.org; Tue, 20 Apr 2004 18:38:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG3rj-0000h4-00 for pim@ietf.org; Tue, 20 Apr 2004 18:37:20 -0400 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1BG3qx-0000a7-00 for pim@ietf.org; Tue, 20 Apr 2004 18:36:31 -0400 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i3L0hLAw008803; Tue, 20 Apr 2004 17:43:21 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i3KMZkd1022255; Tue, 20 Apr 2004 15:35:46 -0700 (PDT) Received: from [10.1.4.230] ([10.1.4.230]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 15:35:46 -0700 In-Reply-To: References: <2CA4524FA012F14BAE5D896D492B38681019EA@ACDNJMAILSRV02.acd.de.ittind.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <100E8865-931B-11D8-BD02-00039307689E@procket.com> Content-Transfer-Encoding: quoted-printable Cc: "Nicholas, Jonathan" , , John Zwiebel From: John Zwiebel Subject: Re: [pim] Abt : PIM DM periodic nature Date: Tue, 20 Apr 2004 15:35:45 -0700 To: "Rajib" X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 20 Apr 2004 22:35:46.0050 (UTC) FILETIME=[D268AE20:01C42727] 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: quoted-printable Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Apr 20, 2004, at 1:15 PM, Rajib wrote: > Hi Nicholas, > > =A0 > > Thanks a lot for your suggestion. But I am not very clear about what=20= > you have mentioned. May be I have misinterpreted. So, can you please=20= > describe me the problem with a diagram or=A0any other way?=A0 > > =A0 > > Yes, I am considering reliable links as it is only at the early stage.=20= > But can you please also suggest me=A0any recovery for the problem you=20= > mentioned. Can I implement acknowledge messages for every=A0Prune=20 > and=A0Graft to overcome this problem? > Raib: You can do what you want, but consider that you have not included a=20 proposal for unreliable links so no one else is going to implement your=20 suggestion until you do. FWIW: many people have spent a lot of time with state-refresh and=20 dense-mode and even so, there are many PIM implementations which do not support=20 dense-mode at all. And of those that do, it isn't clear that it is in wide general use. So, then there is a subset of those few systems that do support dense-mode which support state-refresh. (ie, not everyone does) My point is that you are proposing interoperability problems and/or configuration problems. saying that version 1 was 'wrong' would be incorrect, it was an implementation choice. State-Refresh appeared to offer benefits but AFAIK, was never widely deployed so that those apparent benefits could be studied. version 1 worked and was "good enough" for a while. Likewise, PIM-SM (ASM) is "good enough", but after it was widely deployed, many problems started showing up in the interdomain space,=20 which is why we have defined SSM and Bi-Dir PIM. One can't say that PIM-SM was "wrong". WRT point 1: what happens when the first-hop router fails? No "session terminated" message will be sent so (S,G) state will never be timed out in the downstream routers. If you want to overcome this with a timer, then what is the advantage of your proposal. WRT point 3: How does the host signal the last-hop which specific (S,G) it is interested in listening to? If the host already knows the (S,G) and it sends an IGMPv3 host report, what is the advantage of having pruned state in the last-hop since this sounds a lot like SSM to me. WRT point 4: How do you reliably signal the session end message all the way down the tree? The upstream routers would have to get an ack back from each of the downstream routers, ie every PIM neighbor. How do you decide which upstream router will send the 'session terminate' message on a LAN that has determined the forwarder via the assert process? Is it OK that 5 upstream routers send such a message? Does the downstream router have to receive a "terminate" from every upstream or is any upstream router "good enough"? WRT making the protocol suitable for both sparse-mode and dense-mode, I don't think so. Sparse-mode wants to instantiate state in only those routers where it is required. Dense-mode creates state in every router in the domain. in the case of the Internet, that could mean every router in the world. Dense-mode with state refresh already deals with the periodic flood-and-prune problem that was in the original Dense-mode spec. The fact that you may be able to save a few timers on each router isn't that much of a save. 2cents > =A0 > > Rajib > > Graduate student > > Concordia University, Canada > > =A0 > =A0 > ----- Original Message ----- > From: Nicholas, Jonathan > To: Rajib ; pim@ietf.org > Sent: Tuesday, April 20, 2004 9:46 AM > Subject: RE: [pim] Abt : PIM DM periodic nature > > Hello, > =A0 > One=A0problem with your proposal is it assumes reliable links.=A0 > =A0 > Suppose on a link a router sends a Prune(S,G) upstream and another=20 > router wishes to retain membership in (S,G) on that link.=A0 If the=20 > responding Join(S,G) is not received by the upstream router and the=20 > upstream router's subsequent Prune(S,G) message is lost, there is no=20= > recovery.=A0 Other failure scenarios can be conceived with similar=20 > consequences. > =A0 > Beyond that,=A0we really=A0want to retain interoperability with = existing=20 > implementations, which isn't really compatible with your proposal. > =A0 > Jonathan Nicholas > Network Systems Engineer > ITT Aerospace/Communications Division > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Rajib > Sent: Monday, April 19, 2004 11:58 PM > To: pim@ietf.org > Subject: [pim] Abt : PIM DM periodic nature > > > > > Hi, > > =A0 > > I will be very happy if=A0someone spare some time and give me some=20 > suggestions on the following issue. > > =A0 > > =A0 > > As per PIM DM- > > =A0 > > Prune state has a finite lifetime.=A0 When that lifetime expires, data=20= > will again be forwarded down the previously pruned branch. > > =A0 > > In order to minimize repeated flooding of packets and subsequent=20 > pruning associated with a particular (S,G) pair, PIM-DM uses a state > refresh message.=A0 This message is sent by the router(s) directly=A0=20= > connected to the source and is propagated throughout the network.=A0=20= > When > received by a router on its RPF interface, the state refresh message=20= > causes an existing prune state to be refreshed. > > =A0 > > 1. My question is what=A0was reason of=A0 giving finite lifetime to = Prune ? > > 2. In the version 2 it was overcome by the state refresh message. It=20= > seems that version1 was wrong and version 2 corrects it without making=20= > any major change in the protocol. Why not any major change like the=20 > following ways- > > =A0 > > What I am proposing- > > =A0 > > 1. There will be no periodic timer enable in any router except for the=20= > router directly connected to the source. I mean, when a router gets=20 > any data from it's=A0directly connected =A0source (not from any other=20= > router)=A0only then it will enable a timer for that particualar (S,G). > > =A0 > > 2.=A0 When a particular=A0(S,G) state is created in all routers after=20= > arriving multicast data. This (S,G) state for a particular source and=20= > group will not timeout and hence will not be deleted unless the router=20= > gets and proposed "Multicast session end" message from the router=20 > directly connected to the sender. > > =A0 > > 3. Pruned branches will never timeout. These pruned branches will only=20= > become active "Dense" when they get grafts.While the multicast session=20= > is in process. > > =A0 > > 4. When there is no (S,G) data (data for particular source and group)=20= > from the source to directly connected router,=A0for more than=A0a=20 > particular time (say 6 =A0minutes) then this router will assume that = the=20 > source=A0has finished or discontinued the session and the router=20 > will=A0flood=A0the proposed "Multicast=A0session end" message=A0for = particular=20 > (S,G) through out the network and all those particular (S,G) states in=20= > differnet routers=A0will be deleted. > > =A0 > > =A0 > > These make the protocol- > > =A0 > > 1.=A0Very simple. > > 2.Makes the protocol suitable for both dense and sparse mode. > > 3. No=A0unnecessary timers in routers. > > 4. No periodic flooding. > > 5.No=A0concern regarding=A0prune=A0or any other thing time out.=A0 > > =A0 > > I know my proposal goes far away from PIM DM. But it is PIM DM based.=20= > Is it ok to use ? > > =A0 > > =A0 > > I will be very happy if you please let me know is there any problem=20 > with my proposal. > > =A0 > > Rajib Bashir > > ************************************ > This email and any files transmitted with it are proprietary and=20 > intended solely for the use of the individual or entity to whom they=20= > are addressed. If you have received this email > in error please notify the sender. Please note that any views or=20 > opinions presented in this email are solely those of the author and do=20= > not necessarily represent those of ITT Industries, Inc. > The recipient should check this email and any attachments for the=20 > presence of viruses. ITT Industries accepts no liability for any=20 > damage caused by any virus transmitted by this > email. > ************************************ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Tue Apr 20 19:34:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07192 for ; Tue, 20 Apr 2004 19:34:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4bq-0006fm-Lb for pim-archive@odin.ietf.org; Tue, 20 Apr 2004 19:25:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KNOw5Y025646 for pim-archive@odin.ietf.org; Tue, 20 Apr 2004 19:24:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4Mj-0000iq-Db for pim-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 19:09:21 -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 TAA05927 for ; Tue, 20 Apr 2004 19:09:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG4Mg-0002os-4h for pim-web-archive@ietf.org; Tue, 20 Apr 2004 19:09:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG4Lm-0002kl-00 for pim-web-archive@ietf.org; Tue, 20 Apr 2004 19:08:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG4L5-0002hO-00 for pim-web-archive@ietf.org; Tue, 20 Apr 2004 19:07:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4Cj-0004So-GR; Tue, 20 Apr 2004 18:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3sh-0002u4-5H for pim@optimus.ietf.org; Tue, 20 Apr 2004 18:38:19 -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 SAA04373 for ; Tue, 20 Apr 2004 18:38:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG3se-0000k2-6J for pim@ietf.org; Tue, 20 Apr 2004 18:38:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG3rj-0000h4-00 for pim@ietf.org; Tue, 20 Apr 2004 18:37:20 -0400 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1BG3qx-0000a7-00 for pim@ietf.org; Tue, 20 Apr 2004 18:36:31 -0400 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i3L0hLAw008803; Tue, 20 Apr 2004 17:43:21 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i3KMZkd1022255; Tue, 20 Apr 2004 15:35:46 -0700 (PDT) Received: from [10.1.4.230] ([10.1.4.230]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 15:35:46 -0700 In-Reply-To: References: <2CA4524FA012F14BAE5D896D492B38681019EA@ACDNJMAILSRV02.acd.de.ittind.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <100E8865-931B-11D8-BD02-00039307689E@procket.com> Content-Transfer-Encoding: quoted-printable Cc: "Nicholas, Jonathan" , , John Zwiebel From: John Zwiebel Subject: Re: [pim] Abt : PIM DM periodic nature Date: Tue, 20 Apr 2004 15:35:45 -0700 To: "Rajib" X-Mailer: Apple Mail (2.613) X-OriginalArrivalTime: 20 Apr 2004 22:35:46.0050 (UTC) FILETIME=[D268AE20:01C42727] Content-Transfer-Encoding: quoted-printable Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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: quoted-printable Content-Transfer-Encoding: quoted-printable On Apr 20, 2004, at 1:15 PM, Rajib wrote: > Hi Nicholas, > > =A0 > > Thanks a lot for your suggestion. But I am not very clear about what=20= > you have mentioned. May be I have misinterpreted. So, can you please=20= > describe me the problem with a diagram or=A0any other way?=A0 > > =A0 > > Yes, I am considering reliable links as it is only at the early stage.=20= > But can you please also suggest me=A0any recovery for the problem you=20= > mentioned. Can I implement acknowledge messages for every=A0Prune=20 > and=A0Graft to overcome this problem? > Raib: You can do what you want, but consider that you have not included a=20 proposal for unreliable links so no one else is going to implement your=20 suggestion until you do. FWIW: many people have spent a lot of time with state-refresh and=20 dense-mode and even so, there are many PIM implementations which do not support=20 dense-mode at all. And of those that do, it isn't clear that it is in wide general use. So, then there is a subset of those few systems that do support dense-mode which support state-refresh. (ie, not everyone does) My point is that you are proposing interoperability problems and/or configuration problems. saying that version 1 was 'wrong' would be incorrect, it was an implementation choice. State-Refresh appeared to offer benefits but AFAIK, was never widely deployed so that those apparent benefits could be studied. version 1 worked and was "good enough" for a while. Likewise, PIM-SM (ASM) is "good enough", but after it was widely deployed, many problems started showing up in the interdomain space,=20 which is why we have defined SSM and Bi-Dir PIM. One can't say that PIM-SM was "wrong". WRT point 1: what happens when the first-hop router fails? No "session terminated" message will be sent so (S,G) state will never be timed out in the downstream routers. If you want to overcome this with a timer, then what is the advantage of your proposal. WRT point 3: How does the host signal the last-hop which specific (S,G) it is interested in listening to? If the host already knows the (S,G) and it sends an IGMPv3 host report, what is the advantage of having pruned state in the last-hop since this sounds a lot like SSM to me. WRT point 4: How do you reliably signal the session end message all the way down the tree? The upstream routers would have to get an ack back from each of the downstream routers, ie every PIM neighbor. How do you decide which upstream router will send the 'session terminate' message on a LAN that has determined the forwarder via the assert process? Is it OK that 5 upstream routers send such a message? Does the downstream router have to receive a "terminate" from every upstream or is any upstream router "good enough"? WRT making the protocol suitable for both sparse-mode and dense-mode, I don't think so. Sparse-mode wants to instantiate state in only those routers where it is required. Dense-mode creates state in every router in the domain. in the case of the Internet, that could mean every router in the world. Dense-mode with state refresh already deals with the periodic flood-and-prune problem that was in the original Dense-mode spec. The fact that you may be able to save a few timers on each router isn't that much of a save. 2cents > =A0 > > Rajib > > Graduate student > > Concordia University, Canada > > =A0 > =A0 > ----- Original Message ----- > From: Nicholas, Jonathan > To: Rajib ; pim@ietf.org > Sent: Tuesday, April 20, 2004 9:46 AM > Subject: RE: [pim] Abt : PIM DM periodic nature > > Hello, > =A0 > One=A0problem with your proposal is it assumes reliable links.=A0 > =A0 > Suppose on a link a router sends a Prune(S,G) upstream and another=20 > router wishes to retain membership in (S,G) on that link.=A0 If the=20 > responding Join(S,G) is not received by the upstream router and the=20 > upstream router's subsequent Prune(S,G) message is lost, there is no=20= > recovery.=A0 Other failure scenarios can be conceived with similar=20 > consequences. > =A0 > Beyond that,=A0we really=A0want to retain interoperability with = existing=20 > implementations, which isn't really compatible with your proposal. > =A0 > Jonathan Nicholas > Network Systems Engineer > ITT Aerospace/Communications Division > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Rajib > Sent: Monday, April 19, 2004 11:58 PM > To: pim@ietf.org > Subject: [pim] Abt : PIM DM periodic nature > > > > > Hi, > > =A0 > > I will be very happy if=A0someone spare some time and give me some=20 > suggestions on the following issue. > > =A0 > > =A0 > > As per PIM DM- > > =A0 > > Prune state has a finite lifetime.=A0 When that lifetime expires, data=20= > will again be forwarded down the previously pruned branch. > > =A0 > > In order to minimize repeated flooding of packets and subsequent=20 > pruning associated with a particular (S,G) pair, PIM-DM uses a state > refresh message.=A0 This message is sent by the router(s) directly=A0=20= > connected to the source and is propagated throughout the network.=A0=20= > When > received by a router on its RPF interface, the state refresh message=20= > causes an existing prune state to be refreshed. > > =A0 > > 1. My question is what=A0was reason of=A0 giving finite lifetime to = Prune ? > > 2. In the version 2 it was overcome by the state refresh message. It=20= > seems that version1 was wrong and version 2 corrects it without making=20= > any major change in the protocol. Why not any major change like the=20 > following ways- > > =A0 > > What I am proposing- > > =A0 > > 1. There will be no periodic timer enable in any router except for the=20= > router directly connected to the source. I mean, when a router gets=20 > any data from it's=A0directly connected =A0source (not from any other=20= > router)=A0only then it will enable a timer for that particualar (S,G). > > =A0 > > 2.=A0 When a particular=A0(S,G) state is created in all routers after=20= > arriving multicast data. This (S,G) state for a particular source and=20= > group will not timeout and hence will not be deleted unless the router=20= > gets and proposed "Multicast session end" message from the router=20 > directly connected to the sender. > > =A0 > > 3. Pruned branches will never timeout. These pruned branches will only=20= > become active "Dense" when they get grafts.While the multicast session=20= > is in process. > > =A0 > > 4. When there is no (S,G) data (data for particular source and group)=20= > from the source to directly connected router,=A0for more than=A0a=20 > particular time (say 6 =A0minutes) then this router will assume that = the=20 > source=A0has finished or discontinued the session and the router=20 > will=A0flood=A0the proposed "Multicast=A0session end" message=A0for = particular=20 > (S,G) through out the network and all those particular (S,G) states in=20= > differnet routers=A0will be deleted. > > =A0 > > =A0 > > These make the protocol- > > =A0 > > 1.=A0Very simple. > > 2.Makes the protocol suitable for both dense and sparse mode. > > 3. No=A0unnecessary timers in routers. > > 4. No periodic flooding. > > 5.No=A0concern regarding=A0prune=A0or any other thing time out.=A0 > > =A0 > > I know my proposal goes far away from PIM DM. But it is PIM DM based.=20= > Is it ok to use ? > > =A0 > > =A0 > > I will be very happy if you please let me know is there any problem=20 > with my proposal. > > =A0 > > Rajib Bashir > > ************************************ > This email and any files transmitted with it are proprietary and=20 > intended solely for the use of the individual or entity to whom they=20= > are addressed. If you have received this email > in error please notify the sender. Please note that any views or=20 > opinions presented in this email are solely those of the author and do=20= > not necessarily represent those of ITT Industries, Inc. > The recipient should check this email and any attachments for the=20 > presence of viruses. ITT Industries accepts no liability for any=20 > damage caused by any virus transmitted by this > email. > ************************************ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Apr 21 03:56:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02009 for ; Wed, 21 Apr 2004 03:56:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCWZ-0002YY-Lp; Wed, 21 Apr 2004 03:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCNT-0007KB-TV for pim@optimus.ietf.org; Wed, 21 Apr 2004 03:42:39 -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 DAA01439 for ; Wed, 21 Apr 2004 03:42:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCNR-00066M-Dv for pim@ietf.org; Wed, 21 Apr 2004 03:42:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCMa-000614-00 for pim@ietf.org; Wed, 21 Apr 2004 03:41:47 -0400 Received: from bay16-dav21.bay16.hotmail.com ([65.54.186.201] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BGCM1-0005tx-00 for pim@ietf.org; Wed, 21 Apr 2004 03:41:09 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Apr 2004 00:40:40 -0700 Received: from 209.197.137.33 by bay16-dav21.bay16.hotmail.com with DAV; Wed, 21 Apr 2004 07:40:40 +0000 X-Originating-IP: [209.197.137.33] X-Originating-Email: [rajibullah@hotmail.com] X-Sender: rajibullah@hotmail.com From: "Rajib" To: "John Zwiebel" Cc: Subject: Re: [pim] Abt : PIM DM periodic nature Date: Wed, 21 Apr 2004 03:40:30 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0116_01C42752.6507AD60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 21 Apr 2004 07:40:40.0695 (UTC) FILETIME=[F1EF9870:01C42773] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40, HTML_MESSAGE autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0116_01C42752.6507AD60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John Zwiebel, =20 Thanks a lot for the discussion. I like to add following points. =20 I am not saying PIM-DM is wrong or anything like that but what I want to = say that, there was problem with PIM DM V1 regarding periodic flooding and = that was overcome by version 2, introducing " State refresh". But still = version 2 faces some challenges. Even my proposal may also face many challenges = now or in future.=20 And the age of my idea is fairly 3-4 months, it is far away from being a draft, let alone a "Standard" or any implementation. But I like to work = on it. =20 When I am working on it, at first I am trying to give it a basic = structure. The matter of "reliability" will come later. =20 As you mentioned earlier - "The fact that you may be able to save a = few timers on each router isn't that much of a save." =20 But I think it saves not only some timers but many other things- =20 1. In version1, there was a massive flood in every 3 minutes. It was overcome by version2's "state re-fresh" message that appears in every = 60 seconds and resets the clocks. But I think you have not noticed in version2 , in = order to overcome a periodic " massive flood" a new periodic " tiny flood" is introduced = with the state refresh . It may be a tiny flood but it is a flood. Now you can tell me that I = have also introduced a tiny flood with my "multicast session end " message. = Yes, I am also introducing a tiny flood like version2's "state refresh". But = "multicast session end"=20 will flood the network only 1 time, I mean when the multicast session = will be over.=20 But version2's "state refresh" will create a tiny flood in every 60 = seconds.=20 So if there is a 60 minute multicast session, version2 needs -=20 1 (massive flood at the beginning) + 59 (tiny flood due to state = refresh) =20 and for my proposal, it needs- =20 1 (massive flood at the beginning) + 1 (tiny flood at the end of = session) =20 So, with the increase of session duration version2 faces overhead in = terms of number of tiny floods. =20 2. Now what happens if the number of (S,G) states increases ? Think that = there are 70 (S,G) states in your network now. =20 And all the sessions are of 60 minutes duration or greater. Then for a 60 minutes time period- with version2 , your network will = face-=20 =20 {1 (massive flood at the beginning) + 59 (tiny flood due to state = refresh)} x 70 numbers of floodings.=20 =20 I think it is not a very small figure. And will make an overhead anyway. =20 But the network with proposed "multicast session end" will face-=20 1 (massive flood at the beginning) + 1 (tiny flood at the end of = session) x 70 numbers of floodings.=20 This is much smaller and tolerable. =20 So, again with the increase of number of (S,G) states version2 faces = overhead. =20 So, you can see that in version2 number of control signalling increases = and still it is "periodic" in "true sense". Although it overcomes the problem of massive = flooding in every 3 minutes.=20 While with "multicast session end" it becomes "non- periodic" in "true = sense". =20 3. Thirdly, when there will be no periodic timers, definitely it will = create less processor load. A router may be associated with 70-80 different = (S,G) states and if there is one timer for every state, definitely it will = cause too much processor load. =20 4. You also mentioned about some other bugs, thanks a lot for those. As = I have told earlier, I have not worked on the reliability issues yet, but one = thing I can tell you, most of them will be overcome when I will introduce acknowledge messages with the control messages like Prune, graft and others, specially with proposed "multicast session end" message. When there will be acknowledging messages associated with these control = messages surely the reliability will increase. =20 5. Finally, it is very simple and it is "PIM - DM" based.=20 =20 Really, the discussion with you and others are helping me a lot to understand the whole thing . =20 Thanks again. =20 Rajib Bashir Graduate student Concordia university, Canada. ----- Original Message ----- From: "John Zwiebel" To: "Rajib" Cc: "Nicholas, Jonathan" ; ; = "John Zwiebel" Sent: Tuesday, April 20, 2004 6:35 PM Subject: Re: [pim] Abt : PIM DM periodic nature On Apr 20, 2004, at 1:15 PM, Rajib wrote: > Hi Nicholas, > > > > Thanks a lot for your suggestion. But I am not very clear about what > you have mentioned. May be I have misinterpreted. So, can you please > describe me the problem with a diagram or any other way? > > > > Yes, I am considering reliable links as it is only at the early stage. > But can you please also suggest me any recovery for the problem you > mentioned. Can I implement acknowledge messages for every Prune > and Graft to overcome this problem? > Raib: You can do what you want, but consider that you have not included a proposal for unreliable links so no one else is going to implement your suggestion until you do. FWIW: many people have spent a lot of time with state-refresh and dense-mode and even so, there are many PIM implementations which do not support dense-mode at all. And of those that do, it isn't clear that it is in wide general use. So, then there is a subset of those few systems that do support dense-mode which support state-refresh. (ie, not everyone does) My point is that you are proposing interoperability problems and/or configuration problems. saying that version 1 was 'wrong' would be incorrect, it was an implementation choice. State-Refresh appeared to offer benefits but AFAIK, was never widely deployed so that those apparent benefits could be studied. version 1 worked and was "good enough" for a while. Likewise, PIM-SM (ASM) is "good enough", but after it was widely deployed, many problems started showing up in the interdomain space, which is why we have defined SSM and Bi-Dir PIM. One can't say that PIM-SM was "wrong". WRT point 1: what happens when the first-hop router fails? No "session terminated" message will be sent so (S,G) state will never be timed out in the downstream routers. If you want to overcome this with a timer, then what is the advantage of your proposal. WRT point 3: How does the host signal the last-hop which specific (S,G) it is interested in listening to? If the host already knows the (S,G) and it sends an IGMPv3 host report, what is the advantage of having pruned state in the last-hop since this sounds a lot like SSM to me. WRT point 4: How do you reliably signal the session end message all the way down the tree? The upstream routers would have to get an ack back from each of the downstream routers, ie every PIM neighbor. How do you decide which upstream router will send the 'session terminate' message on a LAN that has determined the forwarder via the assert process? Is it OK that 5 upstream routers send such a message? Does the downstream router have to receive a "terminate" from every upstream or is any upstream router "good enough"? WRT making the protocol suitable for both sparse-mode and dense-mode, I don't think so. Sparse-mode wants to instantiate state in only those routers where it is required. Dense-mode creates state in every router in the domain. in the case of the Internet, that could mean every router in the world. Dense-mode with state refresh already deals with the periodic flood-and-prune problem that was in the original Dense-mode spec. The fact that you may be able to save a few timers on each router isn't that much of a save. 2cents > > > Rajib > > Graduate student > > Concordia University, Canada > > > > ----- Original Message ----- > From: Nicholas, Jonathan > To: Rajib ; pim@ietf.org > Sent: Tuesday, April 20, 2004 9:46 AM > Subject: RE: [pim] Abt : PIM DM periodic nature > > Hello, > > One problem with your proposal is it assumes reliable links. > > Suppose on a link a router sends a Prune(S,G) upstream and another > router wishes to retain membership in (S,G) on that link. If the > responding Join(S,G) is not received by the upstream router and the > upstream router's subsequent Prune(S,G) message is lost, there is no > recovery. Other failure scenarios can be conceived with similar > consequences. > > Beyond that, we really want to retain interoperability with existing > implementations, which isn't really compatible with your proposal. > > Jonathan Nicholas > Network Systems Engineer > ITT Aerospace/Communications Division > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Rajib > Sent: Monday, April 19, 2004 11:58 PM > To: pim@ietf.org > Subject: [pim] Abt : PIM DM periodic nature > > > > > Hi, > > > > I will be very happy if someone spare some time and give me some > suggestions on the following issue. > > > > > > As per PIM DM- > > > > Prune state has a finite lifetime. When that lifetime expires, data > will again be forwarded down the previously pruned branch. > > > > In order to minimize repeated flooding of packets and subsequent > pruning associated with a particular (S,G) pair, PIM-DM uses a state > refresh message. This message is sent by the router(s) directly > connected to the source and is propagated throughout the network. > When > received by a router on its RPF interface, the state refresh message > causes an existing prune state to be refreshed. > > > > 1. My question is what was reason of giving finite lifetime to Prune ? > > 2. In the version 2 it was overcome by the state refresh message. It > seems that version1 was wrong and version 2 corrects it without making > any major change in the protocol. Why not any major change like the > following ways- > > > > What I am proposing- > > > > 1. There will be no periodic timer enable in any router except for the > router directly connected to the source. I mean, when a router gets > any data from it's directly connected source (not from any other > router) only then it will enable a timer for that particualar (S,G). > > > > 2. When a particular (S,G) state is created in all routers after > arriving multicast data. This (S,G) state for a particular source and > group will not timeout and hence will not be deleted unless the router > gets and proposed "Multicast session end" message from the router > directly connected to the sender. > > > > 3. Pruned branches will never timeout. These pruned branches will only > become active "Dense" when they get grafts.While the multicast session > is in process. > > > > 4. When there is no (S,G) data (data for particular source and group) > from the source to directly connected router, for more than a > particular time (say 6 minutes) then this router will assume that the > source has finished or discontinued the session and the router > will flood the proposed "Multicast session end" message for particular > (S,G) through out the network and all those particular (S,G) states in > differnet routers will be deleted. > > > > > > These make the protocol- > > > > 1. Very simple. > > 2.Makes the protocol suitable for both dense and sparse mode. > > 3. No unnecessary timers in routers. > > 4. No periodic flooding. > > 5.No concern regarding prune or any other thing time out. > > > > I know my proposal goes far away from PIM DM. But it is PIM DM based. > Is it ok to use ? > > > > > > I will be very happy if you please let me know is there any problem > with my proposal. > > > > Rajib Bashir > > ************************************ > This email and any files transmitted with it are proprietary and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email > in error please notify the sender. Please note that any views or > opinions presented in this email are solely those of the author and do > not necessarily represent those of ITT Industries, Inc. > The recipient should check this email and any attachments for the > presence of viruses. ITT Industries accepts no liability for any > damage caused by any virus transmitted by this > email. > ************************************ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim =20 ------=_NextPart_000_0116_01C42752.6507AD60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi  = John=20 Zwiebel,

 

Thanks a lot for the discussion. I like to add = following=20 points.

 

I am not saying PIM-DM is wrong or anything = like that but=20 what I want to say

that, there was problem with PIM DM V1 = regarding periodic=20 flooding and that

was overcome by version 2, introducing " State = refresh".=20 But still version 2

faces some challenges. Even my proposal may = also face=20 many challenges now or in future.

And the age of my idea is fairly 3-4 months, it = is far=20 away from being a

draft, let alone a "Standard" or any = implementation. But=20 I like to work on it.

 

When I am working on it, at first  I am trying to give it a basic = structure. The

matter of "reliability" will come=20 later.

 

 As you=20 mentioned earlier -  "The = fact that=20 you may be able to save a few timers on

each router isn't that much of a=20 save."

 

But I think it saves not only some timers but = many other=20 things-

 

1. In version1, there was a massive flood in = every 3=20 minutes. It was

overcome by version2's  "state re-fresh" = message that=20 appears in every 60 seconds and

resets the clocks. But I think you have not = noticed in=20 version2 , in order to overcome a

periodic " massive flood" a new periodic " tiny flood" = is=20 introduced with the state refresh .

It may be a tiny flood but it is a flood. Now = you can=20 tell me that I have

also introduced a tiny flood with my "multicast = session=20 end " message. Yes,

I am also introducing a tiny flood like = version2=92s=20 =93state refresh=94. But =93multicast session end=94

will flood the network only 1 time, I mean when = the=20 multicast session  will=20 be over.

But version2=92s =93state refresh=94 will = create a tiny flood=20 in every 60 seconds.

So if  = there=20 is a 60 minute multicast session, version2 needs =96 =

1 (massive flood at the beginning) + 59 (tiny = flood due=20 to state refresh)

 

and for  = my=20 proposal, it needs- =20

1 (massive flood at the beginning) + 1 (tiny = flood at the=20 end of session)

 

So, with the increase of session duration = version2  faces overhead in terms = of  number of tiny=20 floods.

 

2. Now what happens if the number of (S,G) = states=20 increases ? Think that there are 70 (S,G) states in your network = now. 

And = all the=20 sessions are of 60 minutes duration or greater.

Then  = for a=20 60  minutes time = period-   with version2 , your = network will=20 face-

 

{1 (massive flood at the beginning) + 59 (tiny = flood due=20 to state refresh)}  x  70     numbers = of  floodings. =

 

I think it is not a very small figure. And will = make an=20 overhead anyway.

 

But the network with proposed =93multicast = session=20 end=94  will face-=20

1 (massive flood at the beginning) + 1 (tiny = flood at the=20 end of session) x 70   = numbers=20 of floodings.

This is much smaller and=20 tolerable.

 

So, again with the increase of number of (S,G) = states=20 version2 faces overhead.

 

So, you can =20 see that in version2 number of control signalling increases and = still it=20 is

"periodic" in "true sense". Although it = overcomes the=20 problem of massive flooding in every 3 minutes.

While with =93multicast session end=94 it = becomes =93non-=20 periodic=94 in =93true=20 sense=94.

 

3. Thirdly, when there will be no periodic = timers,=20 definitely it will create

less processor load. A router may be associated = with  70-80 different=20 (S,G)

states and if there is one timer for every = state,=20 definitely it will cause

too much processor = load.

 

4. You also mentioned about some other bugs, = thanks a lot=20 for those. As I have

told earlier, I have not worked on the = reliability issues=20 yet, but one thing

I can tell you, most of them will be overcome = when I=20 will introduce

acknowledge messages with the control messages = like=20 Prune, graft and

others, specially with  proposed "multicast session = end"=20 message. When

there will be acknowledging messages associated = with=20 these control messages

surely the reliability will=20 increase.

 

5. Finally, it is very simple and it is "PIM - = DM" based.=20

 

Really, the discussion with you and others are = helping=20 me  a lot=20 to

understand the whole thing =

 

Thanks again.

 

Rajib Bashir

Graduate student

Concordia university,=20 Canada.

 

 

 

----- Original Message -----
From: "John = Zwiebel"=20 <jzwiebel@procket.com>
To: = "Rajib" <rajibullah@hotmail.com>
= Cc:=20 "Nicholas, Jonathan" <Jonathan.Nicholas@itt.com&g= t;;=20 <pim@ietf.org>; = "John
Zwiebel" <jzwiebel@procket.com>
Sent= :=20 Tuesday, April 20, 2004 6:35 PM
Subject: Re: [pim] Abt : PIM DM = periodic=20 nature



On Apr 20, 2004, at 1:15 PM, Rajib = wrote:

> Hi=20 Nicholas,
>
>
>
> Thanks a lot for your = suggestion. But=20 I am not very clear about what
> you have mentioned. May be I have = misinterpreted. So, can you please
> describe me the problem with = a=20 diagram or any other way?
>
>
>
> Yes, I am = considering=20 reliable links as it is only at the early stage.
> But can you = please also=20 suggest me any recovery for the problem you
> mentioned. Can I = implement=20 acknowledge messages for every Prune
> and Graft to overcome this=20 problem?
>

Raib:

You can do what you want, but = consider that=20 you have not included a
proposal
for unreliable links so no one = else is=20 going to implement your
suggestion until
you do.

FWIW: many = people=20 have spent a lot of time with state-refresh and
dense-mode
and = even so,=20 there are many PIM implementations which do not support
dense-mode at = all.
And of those that do, it isn't clear that it is in wide general=20 use.

So, then there is a subset of those few systems that do=20 support
dense-mode which support state-refresh.  (ie, not = everyone=20 does)

My point is that you are proposing interoperability = problems=20 and/or
configuration problems.

saying that version 1 was = 'wrong' would=20 be incorrect, it was an
implementation choice.  State-Refresh = appeared=20 to offer benefits
but AFAIK, was never widely deployed so that those = apparent=20 benefits
could be studied.  version 1 worked and was "good = enough" for a=20 while.

Likewise, PIM-SM (ASM) is "good enough", but after it was=20 widely
deployed, many problems started showing up in the interdomain=20 space,
which
is why we have defined SSM and Bi-Dir PIM.  One = can't=20 say that PIM-SM
was "wrong".

WRT point 1: what happens when = the=20 first-hop router fails?  No
   "session terminated" = message=20 will be sent so (S,G) state will
   never be timed out in = the=20 downstream routers.  If you want to
   overcome this = with a=20 timer, then what is the advantage of your
   = proposal.

WRT=20 point 3:  How does the host signal the last-hop = which
  =20 specific (S,G) it is interested in listening to?  If the=20 host
   already knows the (S,G) and it sends an IGMPv3 host = report,
   what is the advantage of having pruned state in = the=20 last-hop
   since this sounds a lot like SSM to = me.

WRT=20 point 4: How do you reliably signal the session end = message
   all=20 the way down the tree?  The upstream routers would have = to
  =20 get an ack back from each of the downstream routers, ie = every
  =20 PIM neighbor.

How do you decide which upstream router will send = the=20 'session
terminate' message on a LAN that has determined the = forwarder
via=20 the assert process?  Is it OK that 5 upstream routers send
such = a=20 message?  Does the downstream router have to receive = a
"terminate" from=20 every upstream or is any upstream router
"good enough"?

WRT = making the=20 protocol suitable for both sparse-mode and
dense-mode, I don't think=20 so.  Sparse-mode wants to instantiate
state in only those = routers where=20 it is required.  Dense-mode
creates state in every router in the = domain.  in the case of
the Internet, that could mean every = router in=20 the world.

Dense-mode with state refresh already deals with the=20 periodic
flood-and-prune problem that was in the original Dense-mode=20 spec.
The fact that you may be able to save a few timers on each = router=20 isn't
that much of a save.

2cents

>
>
>=20 Rajib
>
> Graduate student
>
> Concordia = University,=20 Canada
>
>
>
> ----- Original Message=20 -----
>  From: Nicholas, Jonathan
> To: Rajib ; pim@ietf.org
> Sent: Tuesday, = April 20,=20 2004 9:46 AM
> Subject: RE: [pim] Abt : PIM DM periodic=20 nature
>
> Hello,
>
> One problem with your = proposal is=20 it assumes reliable links.
>
> Suppose on a link a router = sends a=20 Prune(S,G) upstream and another
> router wishes to retain = membership in=20 (S,G) on that link. If the
> responding Join(S,G) is not received = by the=20 upstream router and the
> upstream router's subsequent Prune(S,G) = message=20 is lost, there is no
> recovery. Other failure scenarios can be = conceived=20 with similar
> consequences.
>
> Beyond that, we = really want=20 to retain interoperability with existing
> implementations, which = isn't=20 really compatible with your proposal.
>
> Jonathan = Nicholas
>=20 Network Systems Engineer
> ITT Aerospace/Communications = Division
>=20 -----Original Message-----
> From: pim-admin@ietf.org=20 [mailto:pim-admin@ietf.org]On Behalf Of Rajib
> Sent: Monday, = April 19,=20 2004 11:58 PM
> To: pim@ietf.org
>=20 Subject: [pim] Abt : PIM DM periodic=20 nature
>
>
>
>
>=20 Hi,
>
>
>
> I will be very happy if someone = spare some=20 time and give me some
> suggestions on the following=20 issue.
>
>
>
>
>
> As per PIM=20 DM-
>
>
>
> Prune state has a finite lifetime. = When that=20 lifetime expires, data
> will again be forwarded down the = previously=20 pruned branch.
>
>
>
> In order to minimize = repeated=20 flooding of packets and subsequent
> pruning associated with a = particular=20 (S,G) pair, PIM-DM uses a state
> refresh message. This message is = sent by=20 the router(s) directly
> connected to the source and is propagated = throughout the network.
> When
> received by a router on its = RPF=20 interface, the state refresh message
> causes an existing prune = state to=20 be refreshed.
>
>
>
> 1. My question is what was = reason=20 of giving finite lifetime to Prune ?
>
>  2. In the = version 2=20 it was overcome by the state refresh message. It
> seems that = version1 was=20 wrong and version 2 corrects it without making
> any major change = in the=20 protocol. Why not any major change like the
> following=20 ways-
>
>
>
> What I am=20 proposing-
>
>
>
> 1. There will be no periodic = timer=20 enable in any router except for the
> router directly connected to = the=20 source. I mean, when a router gets
> any data from it's directly = connected=20 source (not from any other
> router) only then it will enable a = timer for=20 that particualar (S,G).
>
>
>
> 2. When a = particular=20 (S,G) state is created in all routers after
> arriving multicast = data.=20 This (S,G) state for a particular source and
> group will not = timeout and=20 hence will not be deleted unless the router
> gets and proposed = "Multicast=20 session end" message from the router
> directly connected to the=20 sender.
>
>
>
> 3. Pruned branches will never = timeout.=20 These pruned branches will only
> become active "Dense" when they = get=20 grafts.While the multicast session
> is in=20 process.
>
>
>
> 4. When there is no (S,G) data = (data=20 for particular source and group)
> from the source to directly = connected=20 router, for more than a
> particular time (say 6 minutes) then = this router=20 will assume that the
> source has finished or discontinued the = session and=20 the router
> will flood the proposed "Multicast session end" = message for=20 particular
> (S,G) through out the network and all those = particular (S,G)=20 states in
> differnet routers will be=20 deleted.
>
>
>
>
>
> These make the=20 protocol-
>
>
>
> 1. Very = simple.
>
>=20 2.Makes the protocol suitable for both dense and sparse = mode.
>
> 3.=20 No unnecessary timers in routers.
>
> 4. No periodic=20 flooding.
>
> 5.No concern regarding prune or any other = thing time=20 out.
>
>
>
> I know my proposal goes far away = from PIM=20 DM. But it is PIM DM based.
> Is it ok to use=20 ?
>
>
>
>
>
> I will be very happy = if you=20 please let me know is there any problem
> with my=20 proposal.
>
>
>
> Rajib Bashir
>
>=20 ************************************
> This email and any files=20 transmitted with it are proprietary and
> intended solely for the = use of=20 the individual or entity to whom they
> are addressed. If you have = received this email
> in error please notify the sender. Please = note that=20 any views or
> opinions presented in this email are solely those = of the=20 author and do
> not necessarily represent those of ITT Industries, = Inc.
> The recipient should check this email and any attachments = for=20 the
> presence of viruses. ITT Industries accepts no liability for = any
> damage caused by any virus transmitted by this
>=20 email.
>=20 ************************************


_________________________= ______________________
pim=20 mailing list
pim@ietf.org
https://www1.ietf.org= /mailman/listinfo/pim


 

------=_NextPart_000_0116_01C42752.6507AD60-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Apr 21 04:11:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02740 for ; Wed, 21 Apr 2004 04:11:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCnW-0001LX-55 for pim-archive@odin.ietf.org; Wed, 21 Apr 2004 04:09:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L89YGV005167 for pim-archive@odin.ietf.org; Wed, 21 Apr 2004 04:09:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCcA-00052x-BZ for pim-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 03:57:50 -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 DAA02105 for ; Wed, 21 Apr 2004 03:57:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCc7-0007iH-P8 for pim-web-archive@ietf.org; Wed, 21 Apr 2004 03:57:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCbM-0007c7-00 for pim-web-archive@ietf.org; Wed, 21 Apr 2004 03:57:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGCaf-0007UF-00 for pim-web-archive@ietf.org; Wed, 21 Apr 2004 03:56:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCWZ-0002YY-Lp; Wed, 21 Apr 2004 03:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCNT-0007KB-TV for pim@optimus.ietf.org; Wed, 21 Apr 2004 03:42:39 -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 DAA01439 for ; Wed, 21 Apr 2004 03:42:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCNR-00066M-Dv for pim@ietf.org; Wed, 21 Apr 2004 03:42:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCMa-000614-00 for pim@ietf.org; Wed, 21 Apr 2004 03:41:47 -0400 Received: from bay16-dav21.bay16.hotmail.com ([65.54.186.201] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BGCM1-0005tx-00 for pim@ietf.org; Wed, 21 Apr 2004 03:41:09 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Apr 2004 00:40:40 -0700 Received: from 209.197.137.33 by bay16-dav21.bay16.hotmail.com with DAV; Wed, 21 Apr 2004 07:40:40 +0000 X-Originating-IP: [209.197.137.33] X-Originating-Email: [rajibullah@hotmail.com] X-Sender: rajibullah@hotmail.com From: "Rajib" To: "John Zwiebel" Cc: Subject: Re: [pim] Abt : PIM DM periodic nature Date: Wed, 21 Apr 2004 03:40:30 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0116_01C42752.6507AD60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 21 Apr 2004 07:40:40.0695 (UTC) FILETIME=[F1EF9870:01C42773] Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40, HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0116_01C42752.6507AD60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John Zwiebel, =20 Thanks a lot for the discussion. I like to add following points. =20 I am not saying PIM-DM is wrong or anything like that but what I want to = say that, there was problem with PIM DM V1 regarding periodic flooding and = that was overcome by version 2, introducing " State refresh". But still = version 2 faces some challenges. Even my proposal may also face many challenges = now or in future.=20 And the age of my idea is fairly 3-4 months, it is far away from being a draft, let alone a "Standard" or any implementation. But I like to work = on it. =20 When I am working on it, at first I am trying to give it a basic = structure. The matter of "reliability" will come later. =20 As you mentioned earlier - "The fact that you may be able to save a = few timers on each router isn't that much of a save." =20 But I think it saves not only some timers but many other things- =20 1. In version1, there was a massive flood in every 3 minutes. It was overcome by version2's "state re-fresh" message that appears in every = 60 seconds and resets the clocks. But I think you have not noticed in version2 , in = order to overcome a periodic " massive flood" a new periodic " tiny flood" is introduced = with the state refresh . It may be a tiny flood but it is a flood. Now you can tell me that I = have also introduced a tiny flood with my "multicast session end " message. = Yes, I am also introducing a tiny flood like version2's "state refresh". But = "multicast session end"=20 will flood the network only 1 time, I mean when the multicast session = will be over.=20 But version2's "state refresh" will create a tiny flood in every 60 = seconds.=20 So if there is a 60 minute multicast session, version2 needs -=20 1 (massive flood at the beginning) + 59 (tiny flood due to state = refresh) =20 and for my proposal, it needs- =20 1 (massive flood at the beginning) + 1 (tiny flood at the end of = session) =20 So, with the increase of session duration version2 faces overhead in = terms of number of tiny floods. =20 2. Now what happens if the number of (S,G) states increases ? Think that = there are 70 (S,G) states in your network now. =20 And all the sessions are of 60 minutes duration or greater. Then for a 60 minutes time period- with version2 , your network will = face-=20 =20 {1 (massive flood at the beginning) + 59 (tiny flood due to state = refresh)} x 70 numbers of floodings.=20 =20 I think it is not a very small figure. And will make an overhead anyway. =20 But the network with proposed "multicast session end" will face-=20 1 (massive flood at the beginning) + 1 (tiny flood at the end of = session) x 70 numbers of floodings.=20 This is much smaller and tolerable. =20 So, again with the increase of number of (S,G) states version2 faces = overhead. =20 So, you can see that in version2 number of control signalling increases = and still it is "periodic" in "true sense". Although it overcomes the problem of massive = flooding in every 3 minutes.=20 While with "multicast session end" it becomes "non- periodic" in "true = sense". =20 3. Thirdly, when there will be no periodic timers, definitely it will = create less processor load. A router may be associated with 70-80 different = (S,G) states and if there is one timer for every state, definitely it will = cause too much processor load. =20 4. You also mentioned about some other bugs, thanks a lot for those. As = I have told earlier, I have not worked on the reliability issues yet, but one = thing I can tell you, most of them will be overcome when I will introduce acknowledge messages with the control messages like Prune, graft and others, specially with proposed "multicast session end" message. When there will be acknowledging messages associated with these control = messages surely the reliability will increase. =20 5. Finally, it is very simple and it is "PIM - DM" based.=20 =20 Really, the discussion with you and others are helping me a lot to understand the whole thing . =20 Thanks again. =20 Rajib Bashir Graduate student Concordia university, Canada. ----- Original Message ----- From: "John Zwiebel" To: "Rajib" Cc: "Nicholas, Jonathan" ; ; = "John Zwiebel" Sent: Tuesday, April 20, 2004 6:35 PM Subject: Re: [pim] Abt : PIM DM periodic nature On Apr 20, 2004, at 1:15 PM, Rajib wrote: > Hi Nicholas, > > > > Thanks a lot for your suggestion. But I am not very clear about what > you have mentioned. May be I have misinterpreted. So, can you please > describe me the problem with a diagram or any other way? > > > > Yes, I am considering reliable links as it is only at the early stage. > But can you please also suggest me any recovery for the problem you > mentioned. Can I implement acknowledge messages for every Prune > and Graft to overcome this problem? > Raib: You can do what you want, but consider that you have not included a proposal for unreliable links so no one else is going to implement your suggestion until you do. FWIW: many people have spent a lot of time with state-refresh and dense-mode and even so, there are many PIM implementations which do not support dense-mode at all. And of those that do, it isn't clear that it is in wide general use. So, then there is a subset of those few systems that do support dense-mode which support state-refresh. (ie, not everyone does) My point is that you are proposing interoperability problems and/or configuration problems. saying that version 1 was 'wrong' would be incorrect, it was an implementation choice. State-Refresh appeared to offer benefits but AFAIK, was never widely deployed so that those apparent benefits could be studied. version 1 worked and was "good enough" for a while. Likewise, PIM-SM (ASM) is "good enough", but after it was widely deployed, many problems started showing up in the interdomain space, which is why we have defined SSM and Bi-Dir PIM. One can't say that PIM-SM was "wrong". WRT point 1: what happens when the first-hop router fails? No "session terminated" message will be sent so (S,G) state will never be timed out in the downstream routers. If you want to overcome this with a timer, then what is the advantage of your proposal. WRT point 3: How does the host signal the last-hop which specific (S,G) it is interested in listening to? If the host already knows the (S,G) and it sends an IGMPv3 host report, what is the advantage of having pruned state in the last-hop since this sounds a lot like SSM to me. WRT point 4: How do you reliably signal the session end message all the way down the tree? The upstream routers would have to get an ack back from each of the downstream routers, ie every PIM neighbor. How do you decide which upstream router will send the 'session terminate' message on a LAN that has determined the forwarder via the assert process? Is it OK that 5 upstream routers send such a message? Does the downstream router have to receive a "terminate" from every upstream or is any upstream router "good enough"? WRT making the protocol suitable for both sparse-mode and dense-mode, I don't think so. Sparse-mode wants to instantiate state in only those routers where it is required. Dense-mode creates state in every router in the domain. in the case of the Internet, that could mean every router in the world. Dense-mode with state refresh already deals with the periodic flood-and-prune problem that was in the original Dense-mode spec. The fact that you may be able to save a few timers on each router isn't that much of a save. 2cents > > > Rajib > > Graduate student > > Concordia University, Canada > > > > ----- Original Message ----- > From: Nicholas, Jonathan > To: Rajib ; pim@ietf.org > Sent: Tuesday, April 20, 2004 9:46 AM > Subject: RE: [pim] Abt : PIM DM periodic nature > > Hello, > > One problem with your proposal is it assumes reliable links. > > Suppose on a link a router sends a Prune(S,G) upstream and another > router wishes to retain membership in (S,G) on that link. If the > responding Join(S,G) is not received by the upstream router and the > upstream router's subsequent Prune(S,G) message is lost, there is no > recovery. Other failure scenarios can be conceived with similar > consequences. > > Beyond that, we really want to retain interoperability with existing > implementations, which isn't really compatible with your proposal. > > Jonathan Nicholas > Network Systems Engineer > ITT Aerospace/Communications Division > -----Original Message----- > From: pim-admin@ietf.org [mailto:pim-admin@ietf.org]On Behalf Of Rajib > Sent: Monday, April 19, 2004 11:58 PM > To: pim@ietf.org > Subject: [pim] Abt : PIM DM periodic nature > > > > > Hi, > > > > I will be very happy if someone spare some time and give me some > suggestions on the following issue. > > > > > > As per PIM DM- > > > > Prune state has a finite lifetime. When that lifetime expires, data > will again be forwarded down the previously pruned branch. > > > > In order to minimize repeated flooding of packets and subsequent > pruning associated with a particular (S,G) pair, PIM-DM uses a state > refresh message. This message is sent by the router(s) directly > connected to the source and is propagated throughout the network. > When > received by a router on its RPF interface, the state refresh message > causes an existing prune state to be refreshed. > > > > 1. My question is what was reason of giving finite lifetime to Prune ? > > 2. In the version 2 it was overcome by the state refresh message. It > seems that version1 was wrong and version 2 corrects it without making > any major change in the protocol. Why not any major change like the > following ways- > > > > What I am proposing- > > > > 1. There will be no periodic timer enable in any router except for the > router directly connected to the source. I mean, when a router gets > any data from it's directly connected source (not from any other > router) only then it will enable a timer for that particualar (S,G). > > > > 2. When a particular (S,G) state is created in all routers after > arriving multicast data. This (S,G) state for a particular source and > group will not timeout and hence will not be deleted unless the router > gets and proposed "Multicast session end" message from the router > directly connected to the sender. > > > > 3. Pruned branches will never timeout. These pruned branches will only > become active "Dense" when they get grafts.While the multicast session > is in process. > > > > 4. When there is no (S,G) data (data for particular source and group) > from the source to directly connected router, for more than a > particular time (say 6 minutes) then this router will assume that the > source has finished or discontinued the session and the router > will flood the proposed "Multicast session end" message for particular > (S,G) through out the network and all those particular (S,G) states in > differnet routers will be deleted. > > > > > > These make the protocol- > > > > 1. Very simple. > > 2.Makes the protocol suitable for both dense and sparse mode. > > 3. No unnecessary timers in routers. > > 4. No periodic flooding. > > 5.No concern regarding prune or any other thing time out. > > > > I know my proposal goes far away from PIM DM. But it is PIM DM based. > Is it ok to use ? > > > > > > I will be very happy if you please let me know is there any problem > with my proposal. > > > > Rajib Bashir > > ************************************ > This email and any files transmitted with it are proprietary and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email > in error please notify the sender. Please note that any views or > opinions presented in this email are solely those of the author and do > not necessarily represent those of ITT Industries, Inc. > The recipient should check this email and any attachments for the > presence of viruses. ITT Industries accepts no liability for any > damage caused by any virus transmitted by this > email. > ************************************ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim =20 ------=_NextPart_000_0116_01C42752.6507AD60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi  = John=20 Zwiebel,

 

Thanks a lot for the discussion. I like to add = following=20 points.

 

I am not saying PIM-DM is wrong or anything = like that but=20 what I want to say

that, there was problem with PIM DM V1 = regarding periodic=20 flooding and that

was overcome by version 2, introducing " State = refresh".=20 But still version 2

faces some challenges. Even my proposal may = also face=20 many challenges now or in future.

And the age of my idea is fairly 3-4 months, it = is far=20 away from being a

draft, let alone a "Standard" or any = implementation. But=20 I like to work on it.

 

When I am working on it, at first  I am trying to give it a basic = structure. The

matter of "reliability" will come=20 later.

 

 As you=20 mentioned earlier -  "The = fact that=20 you may be able to save a few timers on

each router isn't that much of a=20 save."

 

But I think it saves not only some timers but = many other=20 things-

 

1. In version1, there was a massive flood in = every 3=20 minutes. It was

overcome by version2's  "state re-fresh" = message that=20 appears in every 60 seconds and

resets the clocks. But I think you have not = noticed in=20 version2 , in order to overcome a

periodic " massive flood" a new periodic " tiny flood" = is=20 introduced with the state refresh .

It may be a tiny flood but it is a flood. Now = you can=20 tell me that I have

also introduced a tiny flood with my "multicast = session=20 end " message. Yes,

I am also introducing a tiny flood like = version2=92s=20 =93state refresh=94. But =93multicast session end=94

will flood the network only 1 time, I mean when = the=20 multicast session  will=20 be over.

But version2=92s =93state refresh=94 will = create a tiny flood=20 in every 60 seconds.

So if  = there=20 is a 60 minute multicast session, version2 needs =96 =

1 (massive flood at the beginning) + 59 (tiny = flood due=20 to state refresh)

 

and for  = my=20 proposal, it needs- =20

1 (massive flood at the beginning) + 1 (tiny = flood at the=20 end of session)

 

So, with the increase of session duration = version2  faces overhead in terms = of  number of tiny=20 floods.

 

2. Now what happens if the number of (S,G) = states=20 increases ? Think that there are 70 (S,G) states in your network = now. 

And = all the=20 sessions are of 60 minutes duration or greater.

Then  = for a=20 60  minutes time = period-   with version2 , your = network will=20 face-

 

{1 (massive flood at the beginning) + 59 (tiny = flood due=20 to state refresh)}  x  70     numbers = of  floodings. =

 

I think it is not a very small figure. And will = make an=20 overhead anyway.

 

But the network with proposed =93multicast = session=20 end=94  will face-=20

1 (massive flood at the beginning) + 1 (tiny = flood at the=20 end of session) x 70   = numbers=20 of floodings.

This is much smaller and=20 tolerable.

 

So, again with the increase of number of (S,G) = states=20 version2 faces overhead.

 

So, you can =20 see that in version2 number of control signalling increases and = still it=20 is

"periodic" in "true sense". Although it = overcomes the=20 problem of massive flooding in every 3 minutes.

While with =93multicast session end=94 it = becomes =93non-=20 periodic=94 in =93true=20 sense=94.

 

3. Thirdly, when there will be no periodic = timers,=20 definitely it will create

less processor load. A router may be associated = with  70-80 different=20 (S,G)

states and if there is one timer for every = state,=20 definitely it will cause

too much processor = load.

 

4. You also mentioned about some other bugs, = thanks a lot=20 for those. As I have

told earlier, I have not worked on the = reliability issues=20 yet, but one thing

I can tell you, most of them will be overcome = when I=20 will introduce

acknowledge messages with the control messages = like=20 Prune, graft and

others, specially with  proposed "multicast session = end"=20 message. When

there will be acknowledging messages associated = with=20 these control messages

surely the reliability will=20 increase.

 

5. Finally, it is very simple and it is "PIM - = DM" based.=20

 

Really, the discussion with you and others are = helping=20 me  a lot=20 to

understand the whole thing =

 

Thanks again.

 

Rajib Bashir

Graduate student

Concordia university,=20 Canada.

 

 

 

----- Original Message -----
From: "John = Zwiebel"=20 <jzwiebel@procket.com>
To: = "Rajib" <rajibullah@hotmail.com>
= Cc:=20 "Nicholas, Jonathan" <Jonathan.Nicholas@itt.com&g= t;;=20 <pim@ietf.org>; = "John
Zwiebel" <jzwiebel@procket.com>
Sent= :=20 Tuesday, April 20, 2004 6:35 PM
Subject: Re: [pim] Abt : PIM DM = periodic=20 nature



On Apr 20, 2004, at 1:15 PM, Rajib = wrote:

> Hi=20 Nicholas,
>
>
>
> Thanks a lot for your = suggestion. But=20 I am not very clear about what
> you have mentioned. May be I have = misinterpreted. So, can you please
> describe me the problem with = a=20 diagram or any other way?
>
>
>
> Yes, I am = considering=20 reliable links as it is only at the early stage.
> But can you = please also=20 suggest me any recovery for the problem you
> mentioned. Can I = implement=20 acknowledge messages for every Prune
> and Graft to overcome this=20 problem?
>

Raib:

You can do what you want, but = consider that=20 you have not included a
proposal
for unreliable links so no one = else is=20 going to implement your
suggestion until
you do.

FWIW: many = people=20 have spent a lot of time with state-refresh and
dense-mode
and = even so,=20 there are many PIM implementations which do not support
dense-mode at = all.
And of those that do, it isn't clear that it is in wide general=20 use.

So, then there is a subset of those few systems that do=20 support
dense-mode which support state-refresh.  (ie, not = everyone=20 does)

My point is that you are proposing interoperability = problems=20 and/or
configuration problems.

saying that version 1 was = 'wrong' would=20 be incorrect, it was an
implementation choice.  State-Refresh = appeared=20 to offer benefits
but AFAIK, was never widely deployed so that those = apparent=20 benefits
could be studied.  version 1 worked and was "good = enough" for a=20 while.

Likewise, PIM-SM (ASM) is "good enough", but after it was=20 widely
deployed, many problems started showing up in the interdomain=20 space,
which
is why we have defined SSM and Bi-Dir PIM.  One = can't=20 say that PIM-SM
was "wrong".

WRT point 1: what happens when = the=20 first-hop router fails?  No
   "session terminated" = message=20 will be sent so (S,G) state will
   never be timed out in = the=20 downstream routers.  If you want to
   overcome this = with a=20 timer, then what is the advantage of your
   = proposal.

WRT=20 point 3:  How does the host signal the last-hop = which
  =20 specific (S,G) it is interested in listening to?  If the=20 host
   already knows the (S,G) and it sends an IGMPv3 host = report,
   what is the advantage of having pruned state in = the=20 last-hop
   since this sounds a lot like SSM to = me.

WRT=20 point 4: How do you reliably signal the session end = message
   all=20 the way down the tree?  The upstream routers would have = to
  =20 get an ack back from each of the downstream routers, ie = every
  =20 PIM neighbor.

How do you decide which upstream router will send = the=20 'session
terminate' message on a LAN that has determined the = forwarder
via=20 the assert process?  Is it OK that 5 upstream routers send
such = a=20 message?  Does the downstream router have to receive = a
"terminate" from=20 every upstream or is any upstream router
"good enough"?

WRT = making the=20 protocol suitable for both sparse-mode and
dense-mode, I don't think=20 so.  Sparse-mode wants to instantiate
state in only those = routers where=20 it is required.  Dense-mode
creates state in every router in the = domain.  in the case of
the Internet, that could mean every = router in=20 the world.

Dense-mode with state refresh already deals with the=20 periodic
flood-and-prune problem that was in the original Dense-mode=20 spec.
The fact that you may be able to save a few timers on each = router=20 isn't
that much of a save.

2cents

>
>
>=20 Rajib
>
> Graduate student
>
> Concordia = University,=20 Canada
>
>
>
> ----- Original Message=20 -----
>  From: Nicholas, Jonathan
> To: Rajib ; pim@ietf.org
> Sent: Tuesday, = April 20,=20 2004 9:46 AM
> Subject: RE: [pim] Abt : PIM DM periodic=20 nature
>
> Hello,
>
> One problem with your = proposal is=20 it assumes reliable links.
>
> Suppose on a link a router = sends a=20 Prune(S,G) upstream and another
> router wishes to retain = membership in=20 (S,G) on that link. If the
> responding Join(S,G) is not received = by the=20 upstream router and the
> upstream router's subsequent Prune(S,G) = message=20 is lost, there is no
> recovery. Other failure scenarios can be = conceived=20 with similar
> consequences.
>
> Beyond that, we = really want=20 to retain interoperability with existing
> implementations, which = isn't=20 really compatible with your proposal.
>
> Jonathan = Nicholas
>=20 Network Systems Engineer
> ITT Aerospace/Communications = Division
>=20 -----Original Message-----
> From: pim-admin@ietf.org=20 [mailto:pim-admin@ietf.org]On Behalf Of Rajib
> Sent: Monday, = April 19,=20 2004 11:58 PM
> To: pim@ietf.org
>=20 Subject: [pim] Abt : PIM DM periodic=20 nature
>
>
>
>
>=20 Hi,
>
>
>
> I will be very happy if someone = spare some=20 time and give me some
> suggestions on the following=20 issue.
>
>
>
>
>
> As per PIM=20 DM-
>
>
>
> Prune state has a finite lifetime. = When that=20 lifetime expires, data
> will again be forwarded down the = previously=20 pruned branch.
>
>
>
> In order to minimize = repeated=20 flooding of packets and subsequent
> pruning associated with a = particular=20 (S,G) pair, PIM-DM uses a state
> refresh message. This message is = sent by=20 the router(s) directly
> connected to the source and is propagated = throughout the network.
> When
> received by a router on its = RPF=20 interface, the state refresh message
> causes an existing prune = state to=20 be refreshed.
>
>
>
> 1. My question is what was = reason=20 of giving finite lifetime to Prune ?
>
>  2. In the = version 2=20 it was overcome by the state refresh message. It
> seems that = version1 was=20 wrong and version 2 corrects it without making
> any major change = in the=20 protocol. Why not any major change like the
> following=20 ways-
>
>
>
> What I am=20 proposing-
>
>
>
> 1. There will be no periodic = timer=20 enable in any router except for the
> router directly connected to = the=20 source. I mean, when a router gets
> any data from it's directly = connected=20 source (not from any other
> router) only then it will enable a = timer for=20 that particualar (S,G).
>
>
>
> 2. When a = particular=20 (S,G) state is created in all routers after
> arriving multicast = data.=20 This (S,G) state for a particular source and
> group will not = timeout and=20 hence will not be deleted unless the router
> gets and proposed = "Multicast=20 session end" message from the router
> directly connected to the=20 sender.
>
>
>
> 3. Pruned branches will never = timeout.=20 These pruned branches will only
> become active "Dense" when they = get=20 grafts.While the multicast session
> is in=20 process.
>
>
>
> 4. When there is no (S,G) data = (data=20 for particular source and group)
> from the source to directly = connected=20 router, for more than a
> particular time (say 6 minutes) then = this router=20 will assume that the
> source has finished or discontinued the = session and=20 the router
> will flood the proposed "Multicast session end" = message for=20 particular
> (S,G) through out the network and all those = particular (S,G)=20 states in
> differnet routers will be=20 deleted.
>
>
>
>
>
> These make the=20 protocol-
>
>
>
> 1. Very = simple.
>
>=20 2.Makes the protocol suitable for both dense and sparse = mode.
>
> 3.=20 No unnecessary timers in routers.
>
> 4. No periodic=20 flooding.
>
> 5.No concern regarding prune or any other = thing time=20 out.
>
>
>
> I know my proposal goes far away = from PIM=20 DM. But it is PIM DM based.
> Is it ok to use=20 ?
>
>
>
>
>
> I will be very happy = if you=20 please let me know is there any problem
> with my=20 proposal.
>
>
>
> Rajib Bashir
>
>=20 ************************************
> This email and any files=20 transmitted with it are proprietary and
> intended solely for the = use of=20 the individual or entity to whom they
> are addressed. If you have = received this email
> in error please notify the sender. Please = note that=20 any views or
> opinions presented in this email are solely those = of the=20 author and do
> not necessarily represent those of ITT Industries, = Inc.
> The recipient should check this email and any attachments = for=20 the
> presence of viruses. ITT Industries accepts no liability for = any
> damage caused by any virus transmitted by this
>=20 email.
>=20 ************************************


_________________________= ______________________
pim=20 mailing list
pim@ietf.org
https://www1.ietf.org= /mailman/listinfo/pim


 

------=_NextPart_000_0116_01C42752.6507AD60-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Apr 28 08:01:48 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09260 for ; Wed, 28 Apr 2004 08:01:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInN4-0007se-Eb; Wed, 28 Apr 2004 07:36:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIkbc-0007M6-Qk for pim@optimus.ietf.org; Wed, 28 Apr 2004 04:39: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 EAA01032 for ; Wed, 28 Apr 2004 04:39:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIkbX-0006VY-L4 for pim@ietf.org; Wed, 28 Apr 2004 04:39:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIkab-0006Fl-00 for pim@ietf.org; Wed, 28 Apr 2004 04:38:47 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIkZS-0005iQ-00 for pim@ietf.org; Wed, 28 Apr 2004 04:37:34 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3S8awr01608 for ; Wed, 28 Apr 2004 11:36:58 +0300 Date: Wed, 28 Apr 2004 11:36:58 +0300 (EEST) From: Pekka Savola To: pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id i3S8awr01608 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: quoted-printable Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, Another minor (but important) nit that I noticed: the document should=20 say, in abstract/introduction, that is obsoletes RFC2362. On Wed, 24 Mar 2004, Pekka Savola wrote: > I already raised one specific issue, some others below... >=20 > substantial > ----------- >=20 > 1) I've raised this issue in the past, but I think it would be appropr= iate > to explicitly describe how PIM is run inter-domain at the protocol over= view > section -- or just state that it's out of scope for this specification = ?? >=20 > 2) statement in 4.1.6, on page 25, says: >=20 > RPF'(*,G) and RPF'(S,G) indicate the neighbor from which data packets > should be coming and to which joins should be sent on the RP tree and > SPT respectively. >=20 > .. but based on on the security analysis draft, and comments made at M= BONED > at IETF59, this is not correct. Data packets are checked only to come = from > the _interface_ towards the neighbor, right? >=20 > 3) there are slight inaccuracies with TTL/Hop Limit of the register > tunnell, like: >=20 > Just like any forwarded packet, the TTL of the original data packet is > decremented after it is decapsulated from the Register Tunnel. > = =20 > =3D=3D> TTL is only decremented if the data packet is forwarded out of = the box.=20 > I.e., if the data packet was to be terminated at the router, it would n= ot be > decremented. >=20 > =3D=3D> the same applies to encapsulation to register tunnel. TTL is o= nly > decremented if it was _forwarded_ to the register tunnel -- but not if = it > was *originated* to the register tunnel (e.g., the router itself sendin= g the > packet to a group). {section 4.10.3} >=20 > 4) Is there any fundamental reason (broken implementations?) why you'r= e > explicitly allowing invalid destination IP addresses, rather than the > multicast address, on a link: >=20 > On unnumbered interfaces on point-to-point links, the router's address > should be the same as the source address it chose for the Hello message > it sent over that interface. However on point-to-point links we also > recommend that PIM Join/Prune messages with a destination address of al= l > zeros are also accepted. >=20 > .. this seems strange to me... (same in other places..) >=20 > 5) Section 4.7 on multicast border router behaviour describes the case > where PIM and non-PIM multicast domains should operate. However, secti= on > 4.8 abuse this section to expand that to describe how the operation bet= ween > different PIM domains functions. The latter should be more clearly sep= arate > from interworking with non-PIM protocols. >=20 > 6) The issue raised in a separate mail about wildcard receivers, that = is: >=20 > o Another component of the PMBR is a wildcard receiver. In this case > the PIM-SM component of the PMBR must ensure that traffic from all > internal sources reaches the PMBR until it is informed otherwise. >=20 > ... >=20 > In the former case, the PMBR will need to send a Join(*,*,RP) to all th= e > RPs in the PIM-SM domain. This will cause all traffic in the domain to > reach the PMBR. The PMBR may then act as if it were a DR with directly > connected receivers, and trigger the transition to a shortest path tree > (see Section 4.2.1). >=20 > =3D=3D> this presumes that PMBR is aware of all the transmissions in th= e > world(!!), and fails e.g. with SSM or Embedded-RP. As already mentione= d, > this is a very dangerous capability DoS-wise as well. >=20 > 7) Section 4.8 contains a technically unverifiable statement: >=20 > Any RP address configured or learned MUST be a domain-wide reachable > address. >=20 > .. the implementations have no way of ensuring this, so this sounds mor= e > like an operational requirement. Maybe adequate health warnings should= be > added, like: >=20 > Note that in general, it is impossible to verify that the RP > address is in fact reachable, making this requirement practically > moot. >=20 > 8) is the implementation of Address List option left to the discretion= of > the implementor? I'd say it's a SHOULD at least, if not a MUST: >=20 > Unknown options may be ignored. The "Holdtime" option MUST be > implemented; the "DR Priority" and "Generation ID" options SHOULD > be implemented. >=20 > 9) Is there anything preventing the Prune Pending Timer to be shorter = than > Join Pending time? AFAICS, the basics how these are formed are the sam= e.=20 > This would be highly disadvantageous if someone randomized the time for= Join > Pending to be e.g. 1.0 seconds and Prune Pending to 0.8 seconds -- and = state > would be removed before the Join would be sent? >=20 > 10) Nowhere does it specify the reception rules for the packets sent, j= ust > the rules which must be used for sending the packets. For example, if > someone sent you a PIM packet, over unicast, MUST it be discarded. The= se > should probably be formally specified. This stems from: >=20 > 11) DoS descriptions in section 6.4 appear to be rather weak at this=20 > point yet. I would refer informationally=20 > to draft-savola-mboned-mroutesec-00.txt (soon > draft-ietf-mboned-mroutesec-00.txt), at least. >=20 > These two attacks should probably be described a bit more. >=20 > Additional one, described at the separate note, is the Multicast Border > attack: if you can associate yourself as a multicast border with a rout= er, > you can make it send all groups in the Internet to you using a (single?= ) > message with a wildcard join. That must be spelled out unless the wild= card > join is removed from the spec. >=20 > 12) references; >=20 > [9] should probably be Informational; it is not critical in the text, a= nd it > could create a blockage. [7] should probably also be Informational. [1]= is > Informational and cannot be referred Normatively by PS; recommend movin= g to > info references, as it seems appropriate there. >=20 >=20 > 6.1.1. Forged link-local messages > = =20 > Join/Prune, Hello, and Assert messages are all sent to the link-local > ALL_PIM_ROUTERS multicast addresses, and thus are not forwarded by a > compliant router. A forged message of this type can only reach a LAN i= f > it was sent by a local host or if it was allowed onto the LAN by a > compromised or non-compliant router. >=20 >=20 >=20 > semi-editorial > -------------- > PIM-SM routers need to know the address of the RP for each group for > which they have (*,G) state. This address is obtained either through a > bootstrap mechanism or through static configuration. >=20 > =3D=3D> replace add "automatically, " before "bootstrap" (embedded-RP c= ase) >=20 > o Last RPF Neighbor towards RP that was used > = =20 > =3D=3D> this may be more than just an editorial issue, but would this b= e better > stated: "Last RPF Neighbor that was used towards RP" ? (same in many o= ther > places.) >=20 > void > CheckSwitchToSpt(S,G) { > if ( ( pim_include(*,G) (-) pim_exclude(S,G) > (+) pim_include(S,G) !=3D NULL ) > AND SwitchToSptDesired(S,G) ) { > restart KeepaliveTimer(S,G); > } > } >=20 > =3D=3D> you just indicate the desire for switchover, but do not actuall= y > initiate the switchover (here or in the definition of switchover) ? >=20 > neighbor.dr_priority > The DR Priority field of the PIM neighbor if it is present in > the Hello message. >=20 > =3D=3D> and otherwise, if it is not present, dr_priority is ....? It m= ust be > initialized to something, I guess.. >=20 > for each neighbor on interface I { > if ( neighbor.lan_delay > delay ) { > delay =3D neighbor.lan_delay > } > } >=20 > =3D=3D> you should probably clarify, (actually earlier but this is an e= xample of > this), that the router must keep its own values on record as well .. > essentially considering it as a neighbor as well on all of its interfac= es, > right? >=20 > Within one Address List Hello option, all the addresses MUST be of the > same address family. It is not permitted to mix IPv4 and IPv6 addresse= s > within the same message. In addition, the address family of the fields > in the message SHOULD be the same as the IP source and destination > addresses of the packet header. >=20 > =3D=3D> would it make sense to say how exactly this is to be verified (= i.e., > going through encoded-unicast formatting) >=20 > +-----------++---------------------------------------------------------= -- > | || Event > | ++-----------+------------+------------+------------+------= -- > |Prev State ||Register- | Could | Could | Register- | RP ch= an > | ||Stop Timer | Register | Register | Stop | > | ||expires | ->True | ->False | received | > +-----------++-----------+------------+------------+------------+------= -- >=20 > =3D=3D> many tables go beyond the RFC-editor limit 72 lines. This is o= ne of the > more important ID-nits, esp. for tables as they could be difficult to > compress. Could this be fixed easily? > = =20 > Subtracting off Register_Probe_Time is a bit unnecessary because i= t > is really small compared to Register_Suppression_Time, but was in >=20 > =3D=3D> that could end up as negative as well if you right the timers -= - what > would you do then? :)=20 >=20 > TU. The encapsulating DR may perform Path-MTU Discovery to the > RP to determine the effective MTU of the tunnel. This smaller MTU take= s > both the outer IP header and the PIM register header overhead into > account. >=20 > =3D=3D> s/Path-MTU/Path MTU/ for consistency? > =3D=3D> s/This smaller MTU takes/The assigned smaller MTU should take/ > (that is, just doing PMTUD does not give you the smaller MTU -- you hav= e to > subtract the header lengths from that as well...) >=20 > In IPv6, the DR MUST perform Path-MTU discovery, and an ICMP > Fragmentation Required message MUST be sent by the encapsulating DR if >=20 > =3D=3D> s/Fragmentation Required/Packet Too Big/ > =3D=3D> you could maybe add informative refs to PMTUD spec here as well= -- the > same would apply to the bit about copying ECN w/ tunnels. >=20 > (sect 4.5.7, sending S,G J/P) > Finally, > if it sees the Generation ID of its upstream neighbor change, it knows > that the upstream neighbor has lost state, and it should refresh the > state by scheduling a Join(S,G) to be sent almost immediately. >=20 > =3D=3D> why is this only discussed here -- this appears to be a more ge= neric > even, which should triggger sending Joins for *all* groups or S,G pairs > immediately? >=20 > MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing > metrics associated with the route to a particular (unicast) destination > X >=20 > =3D=3D> is it clear enough which specific preferences and metrics you'r= e talking > about .. now that many implementations provide so many of them? >=20 > This specification does not mandate the use of a single mechanism to > provide routers with the information to perform the group-to-RP mapping. > Currently three mechanisms are possible, and all three have associated > problems: > = =20 > Static Configuration > [...] >=20 > =3D=3D> make that "at least three mechanisms", or just include Embedded= -RP here, > with an informational reference. >=20 > 4.9. Source-Specific Multicast > = =20 > The Source-Specific Multicast (SSM) service model [6] can be implemente= d > with a strict subset of the PIM-SM protocol mechanisms. Both regular I= P > Multicast and SSM semantics can coexist on a single router and both can > be implemented using the PIM-SM protocol. A range of multicast > addresses, currently 232.0.0.0/8 in IPv4, is reserved for SSM >=20 > =3D=3D> worth spelling out the equivalent in IPv6 as well? >=20 > If the packet's length is > not an integral number of 16-bit words, the packet is padded with = a > trailing byte of zero before performing the checksum. >=20 > =3D=3D> this was under the IPv6 checksum part. If this isn't IPv6 spec= ific, > separate as a paragraph of it's own. >=20 > 11. Index >=20 > =3D=3D> add the IPR and copyright sections. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > editorial > --------- >=20 > This document is a product of the IETF PIM WG. Comments should be > addressed to the authors, or the WG's mailing list at > pim@catarina.usc.edu. >=20 > =3D=3D> the m-l is now pim@ietf.org >=20 > Designated Router (DR): > A shared-media LAN like Ethernet may have multiple PIM-SM routers > connected to it. If the LAN has directly connected hosts, then a > single one of these routers, the DR, will act on behalf of those > hosts with respect to the PIM-SM protocol. >=20 > =3D=3D> "If the LAN.." is not accurate, because this happens irrespecti= ve of > whether there are hosts on the LAN or not. Maybe like: >=20 > "A single one of these routers, the DR, will act on behalf of directly > connected hosts with respect to the PIM-SM protocol." >=20 > (the same in section 4.3) >=20 > ..... >=20 > MRIB Multicast Routing Information Base. This is the multicast > topology table, which is typically derived from the unicast > routing table, or routing protocols such as MBGP that carry > multicast-specific topology information. In PIM-SM, the MRIB is > used to decide where to send Join/Prune messages. >=20 > =3D=3D> MRIB is used for other purposes as well, mainly, where to expec= t to > receive such messages, right? >=20 > In phase one, a multicast receiver expresses its interest in receiving > traffic destined for a multicast group. Typically it does this using > IGMP [5] or MLD [3], but other mechanisms might also serve this purpose. > One of the receiver's local routers is elected as the Designated Router > (DR) for that subnet. >=20 > =3D=3D> s/is elected/has been elected/ (this happens before anyone expr= essing > interest) >=20 > The (*,G) Join travels > hop-by-hop towards the RP for the group, and in each router it passes > through, multicast tree state for group G is instantiated. >=20 > =3D=3D> wouldn't "initialized" be better than "instantiated". Anyway..= works > for me (this happens a lot elsewhere as well..) >=20 > o Traveling all the way to the RP, and then back down the shared tree > may entail the packets traveling a relatively long distance to reach > receivers that are close to the sender. For some applications, this > increased latency is undesirable. >=20 > =3D=3D> s/latency/latency or bandwidth consumption/ ? >=20 > While the RP is in the process of joining the source-specific tree for > S, the data packets will continue being encapsulated to the RP. >=20 > =3D=3D> s/being/to be/ >=20 > To obtain lower latencies, a router on the receiver's LAN, typically th= e > DR, may optionally initiate a transfer from the shared tree to a source= - > specific shortest-path tree (SPT). >=20 > =3D=3D> s/latencies/latencies or more efficient bandwidth consumption/ >=20 > At this point the receiver (or a router upstream of the receiver) will > be receiving two copies of the data >=20 > =3D=3D> s/receiver/receiver's DR/ ? (and/or remove the thing in ()'s) >=20 > Multi-access Transit LANs > = =20 > The overview so far has concerned itself with point-to-point links. >=20 > =3D=3D> s/links/transit links/ >=20 > o Neighbor's Gen ID. > = =20 > =3D=3D> consistency: some places say "GenID", some others "Gen ID" or > "Generation ID". >=20 > The SPTbit is used to indicate whether forwarding is taking place on th= e >=20 > =3D=3D> consistency: some places say "SPTbit", others "SPT bit". make = it > uniform. >=20 > The primary IP address of a neighbor is the link-local > address that it uses as the source of its PIM Hello messages. >=20 > =3D=3D> as these statements are generic, maybe do a lot of > s/link-local/(link-local)/ so it applies better to both v4 and v6. >=20 > pim_include(*,G) =3D > { all interfaces I such that: > ( ( I_am_DR( I ) AND lost_assert(*,G,I) =3D=3D FALSE ) > OR AssertWinner(*,G,I) =3D=3D me ) > AND local_receiver_include(*,G,I) } >=20 > =3D=3D> note that nowhere you seem to be defining "AssertWinner(x,x,x)"= even > though that's rather straightforward. >=20 > 4.2.1. Last-hop switchover to the SPT > = =20 > =3D=3D> s/switchover/Switchover/ (similar elsewhere as applicable) >=20 > PIM-Hello messages are sent periodically on each PIM-enabled interface. >=20 > =3D=3D> in some places it's "PIM-Hello", in others "PIM Hello". Make i= t > consistent. >=20 > 4.3.4. Maintaining Secondary Address Lists > = =20 > Communication of a routers interface secondary addresses to its PIM > neighbors is necessary to provide the neighbors with a mechanism for >=20 > =3D=3D> s/routers/router's/ >=20 > if( I_am_RP(G) AND outer.dst =3D=3D RP(G) ) { > bool sentRegisterStop =3D FALSE; >=20 > =3D=3D> remove "bool" -- typically the variables don't have the type in= the > pseudocode in this spec (same applies elsewhere as well) >=20 > message SHOULD be discarded without further processing. In addition, i= f > the Hello message from a neighbor was authenticated using IPsec AH (see > Section 6.3) then all Join/Prune messages from that neighbor MUST also >=20 > =3D=3D> s/AH/Authentication Header (AH)/ >=20 > Join (J) > The interface has (*,*,RP) Join state which will cause us to > forward packets destined for any group handled by RP from thi= s > interface except if there is also (S,G,rpt) prune information > (see Section 4.5.4) or the router lost an assert on this > interface. >=20 > =3D=3D> cause "us" -- what's us? reword..? >=20 > 4.7. PIM Multicast Border Router Behavior > = =20 > In some cases PIM-SM domains will interconnect with non-PIM domains. >=20 > =3D=3D> s/non-PIM/non-PIM multicast/ >=20 > 3ffe:b00:c18:1::10 would be computed as 0x3ffe0b00 ^ 0x0c180001 ^ > 0x00000000 ^ 0x00000010, where ^ represents the exclusive-or > operation. >=20 > =3D=3D> use 2001:db8::/32 in the examples, please. >=20 > The following rules override the normal PIM-SM behavior for a multicast > address G in the SSM reserved range: >=20 > =3D=3D> remove "reserved" >=20 > PIM messages are either unicast (e.g. Registers and Register-Stop), or > multicast with TTL 1 to the =01LL-PIM-ROUTERS' group (e.g. Join/Prune, > Asserts, etc.). The source address used for unicast messages is a > domain-wide reachable address; the source address used for multicast > messages is the link-local address of the interface on which the messag= e > is being sent. >=20 > =3D=3D> s/link-local/(link-local) primary/ ? >=20 > The IPv4 =01LL-PIM-ROUTERS' group is =E0.0.0.13'. The IPv6 =01LL-PIM- > ROUTERS' group is =06f02::d'. > = =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |PIM Ver| Type | Reserved | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > =3D=3D> add a prelude before the bit diagram, like "PIM header common t= o all > messages is:" >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > | Type =3D 1 | Length =3D 2 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > | Holdtime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > =3D=3D> s/Holdtime/Holdtime / >=20 > OptionTypes 17 thru 65000 are assigned by the IANA. OptionTypes > 65001 through 65535 are reserved for Private Use, as defined in > [10]. > Unknown options may be ignored. The "Holdtime" option MUST be > implemented; the "DR Priority" and "Generation ID" options SHOULD >=20 > =3D=3D> add a return after "[10]." >=20 > 4.10.5. Join/Prune Message Format > = =20 > =3D=3D> please cut down the format by a few lines; it gets cut into two= pages by > one line already, and it would be very nice if it fit in the same page > with the preamble of 4.10.5. >=20 > Values 128 through 250 are designated to be assigned by the IANA > based upon IESG Approval, as defined in [10]. >=20 > =3D=3D> s/assigned/assigned for PIM/ ? (at least so I think it said ear= lier in > the spec..) >=20 > Similarly, a Designated > Router SHOULD NOT accept a Register-Stop packet whose IP source address > is not a valid RP address for the local domain. >=20 > =3D=3D> s/for the local domain/as given by the group-to-RP mapping/ >=20 > multicast messages is addressed (one such proposal is [9] ), the anti- >=20 > =3D=3D> s/] /]/ >=20 >=20 >=20 >=20 --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Apr 28 08:22:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11789 for ; Wed, 28 Apr 2004 08:22:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInxR-0000Is-SW for pim-archive@odin.ietf.org; Wed, 28 Apr 2004 08:14:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SCEXXo001166 for pim-archive@odin.ietf.org; Wed, 28 Apr 2004 08:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInmJ-0004ts-TU for pim-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 08:03:03 -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 IAA09433 for ; Wed, 28 Apr 2004 08:03:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInmI-0003Z7-Vm for pim-web-archive@ietf.org; Wed, 28 Apr 2004 08:03:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInlR-0003EB-00 for pim-web-archive@ietf.org; Wed, 28 Apr 2004 08:02:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BInkc-0002sL-00 for pim-web-archive@ietf.org; Wed, 28 Apr 2004 08:01:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInN4-0007se-Eb; Wed, 28 Apr 2004 07:36:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIkbc-0007M6-Qk for pim@optimus.ietf.org; Wed, 28 Apr 2004 04:39: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 EAA01032 for ; Wed, 28 Apr 2004 04:39:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIkbX-0006VY-L4 for pim@ietf.org; Wed, 28 Apr 2004 04:39:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIkab-0006Fl-00 for pim@ietf.org; Wed, 28 Apr 2004 04:38:47 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIkZS-0005iQ-00 for pim@ietf.org; Wed, 28 Apr 2004 04:37:34 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3S8awr01608 for ; Wed, 28 Apr 2004 11:36:58 +0300 Date: Wed, 28 Apr 2004 11:36:58 +0300 (EEST) From: Pekka Savola To: pim@ietf.org Subject: Re: [pim] pim-sm-v2-new-09 comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id i3S8awr01608 Content-Transfer-Encoding: quoted-printable Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Another minor (but important) nit that I noticed: the document should=20 say, in abstract/introduction, that is obsoletes RFC2362. On Wed, 24 Mar 2004, Pekka Savola wrote: > I already raised one specific issue, some others below... >=20 > substantial > ----------- >=20 > 1) I've raised this issue in the past, but I think it would be appropr= iate > to explicitly describe how PIM is run inter-domain at the protocol over= view > section -- or just state that it's out of scope for this specification = ?? >=20 > 2) statement in 4.1.6, on page 25, says: >=20 > RPF'(*,G) and RPF'(S,G) indicate the neighbor from which data packets > should be coming and to which joins should be sent on the RP tree and > SPT respectively. >=20 > .. but based on on the security analysis draft, and comments made at M= BONED > at IETF59, this is not correct. Data packets are checked only to come = from > the _interface_ towards the neighbor, right? >=20 > 3) there are slight inaccuracies with TTL/Hop Limit of the register > tunnell, like: >=20 > Just like any forwarded packet, the TTL of the original data packet is > decremented after it is decapsulated from the Register Tunnel. > = =20 > =3D=3D> TTL is only decremented if the data packet is forwarded out of = the box.=20 > I.e., if the data packet was to be terminated at the router, it would n= ot be > decremented. >=20 > =3D=3D> the same applies to encapsulation to register tunnel. TTL is o= nly > decremented if it was _forwarded_ to the register tunnel -- but not if = it > was *originated* to the register tunnel (e.g., the router itself sendin= g the > packet to a group). {section 4.10.3} >=20 > 4) Is there any fundamental reason (broken implementations?) why you'r= e > explicitly allowing invalid destination IP addresses, rather than the > multicast address, on a link: >=20 > On unnumbered interfaces on point-to-point links, the router's address > should be the same as the source address it chose for the Hello message > it sent over that interface. However on point-to-point links we also > recommend that PIM Join/Prune messages with a destination address of al= l > zeros are also accepted. >=20 > .. this seems strange to me... (same in other places..) >=20 > 5) Section 4.7 on multicast border router behaviour describes the case > where PIM and non-PIM multicast domains should operate. However, secti= on > 4.8 abuse this section to expand that to describe how the operation bet= ween > different PIM domains functions. The latter should be more clearly sep= arate > from interworking with non-PIM protocols. >=20 > 6) The issue raised in a separate mail about wildcard receivers, that = is: >=20 > o Another component of the PMBR is a wildcard receiver. In this case > the PIM-SM component of the PMBR must ensure that traffic from all > internal sources reaches the PMBR until it is informed otherwise. >=20 > ... >=20 > In the former case, the PMBR will need to send a Join(*,*,RP) to all th= e > RPs in the PIM-SM domain. This will cause all traffic in the domain to > reach the PMBR. The PMBR may then act as if it were a DR with directly > connected receivers, and trigger the transition to a shortest path tree > (see Section 4.2.1). >=20 > =3D=3D> this presumes that PMBR is aware of all the transmissions in th= e > world(!!), and fails e.g. with SSM or Embedded-RP. As already mentione= d, > this is a very dangerous capability DoS-wise as well. >=20 > 7) Section 4.8 contains a technically unverifiable statement: >=20 > Any RP address configured or learned MUST be a domain-wide reachable > address. >=20 > .. the implementations have no way of ensuring this, so this sounds mor= e > like an operational requirement. Maybe adequate health warnings should= be > added, like: >=20 > Note that in general, it is impossible to verify that the RP > address is in fact reachable, making this requirement practically > moot. >=20 > 8) is the implementation of Address List option left to the discretion= of > the implementor? I'd say it's a SHOULD at least, if not a MUST: >=20 > Unknown options may be ignored. The "Holdtime" option MUST be > implemented; the "DR Priority" and "Generation ID" options SHOULD > be implemented. >=20 > 9) Is there anything preventing the Prune Pending Timer to be shorter = than > Join Pending time? AFAICS, the basics how these are formed are the sam= e.=20 > This would be highly disadvantageous if someone randomized the time for= Join > Pending to be e.g. 1.0 seconds and Prune Pending to 0.8 seconds -- and = state > would be removed before the Join would be sent? >=20 > 10) Nowhere does it specify the reception rules for the packets sent, j= ust > the rules which must be used for sending the packets. For example, if > someone sent you a PIM packet, over unicast, MUST it be discarded. The= se > should probably be formally specified. This stems from: >=20 > 11) DoS descriptions in section 6.4 appear to be rather weak at this=20 > point yet. I would refer informationally=20 > to draft-savola-mboned-mroutesec-00.txt (soon > draft-ietf-mboned-mroutesec-00.txt), at least. >=20 > These two attacks should probably be described a bit more. >=20 > Additional one, described at the separate note, is the Multicast Border > attack: if you can associate yourself as a multicast border with a rout= er, > you can make it send all groups in the Internet to you using a (single?= ) > message with a wildcard join. That must be spelled out unless the wild= card > join is removed from the spec. >=20 > 12) references; >=20 > [9] should probably be Informational; it is not critical in the text, a= nd it > could create a blockage. [7] should probably also be Informational. [1]= is > Informational and cannot be referred Normatively by PS; recommend movin= g to > info references, as it seems appropriate there. >=20 >=20 > 6.1.1. Forged link-local messages > = =20 > Join/Prune, Hello, and Assert messages are all sent to the link-local > ALL_PIM_ROUTERS multicast addresses, and thus are not forwarded by a > compliant router. A forged message of this type can only reach a LAN i= f > it was sent by a local host or if it was allowed onto the LAN by a > compromised or non-compliant router. >=20 >=20 >=20 > semi-editorial > -------------- > PIM-SM routers need to know the address of the RP for each group for > which they have (*,G) state. This address is obtained either through a > bootstrap mechanism or through static configuration. >=20 > =3D=3D> replace add "automatically, " before "bootstrap" (embedded-RP c= ase) >=20 > o Last RPF Neighbor towards RP that was used > = =20 > =3D=3D> this may be more than just an editorial issue, but would this b= e better > stated: "Last RPF Neighbor that was used towards RP" ? (same in many o= ther > places.) >=20 > void > CheckSwitchToSpt(S,G) { > if ( ( pim_include(*,G) (-) pim_exclude(S,G) > (+) pim_include(S,G) !=3D NULL ) > AND SwitchToSptDesired(S,G) ) { > restart KeepaliveTimer(S,G); > } > } >=20 > =3D=3D> you just indicate the desire for switchover, but do not actuall= y > initiate the switchover (here or in the definition of switchover) ? >=20 > neighbor.dr_priority > The DR Priority field of the PIM neighbor if it is present in > the Hello message. >=20 > =3D=3D> and otherwise, if it is not present, dr_priority is ....? It m= ust be > initialized to something, I guess.. >=20 > for each neighbor on interface I { > if ( neighbor.lan_delay > delay ) { > delay =3D neighbor.lan_delay > } > } >=20 > =3D=3D> you should probably clarify, (actually earlier but this is an e= xample of > this), that the router must keep its own values on record as well .. > essentially considering it as a neighbor as well on all of its interfac= es, > right? >=20 > Within one Address List Hello option, all the addresses MUST be of the > same address family. It is not permitted to mix IPv4 and IPv6 addresse= s > within the same message. In addition, the address family of the fields > in the message SHOULD be the same as the IP source and destination > addresses of the packet header. >=20 > =3D=3D> would it make sense to say how exactly this is to be verified (= i.e., > going through encoded-unicast formatting) >=20 > +-----------++---------------------------------------------------------= -- > | || Event > | ++-----------+------------+------------+------------+------= -- > |Prev State ||Register- | Could | Could | Register- | RP ch= an > | ||Stop Timer | Register | Register | Stop | > | ||expires | ->True | ->False | received | > +-----------++-----------+------------+------------+------------+------= -- >=20 > =3D=3D> many tables go beyond the RFC-editor limit 72 lines. This is o= ne of the > more important ID-nits, esp. for tables as they could be difficult to > compress. Could this be fixed easily? > = =20 > Subtracting off Register_Probe_Time is a bit unnecessary because i= t > is really small compared to Register_Suppression_Time, but was in >=20 > =3D=3D> that could end up as negative as well if you right the timers -= - what > would you do then? :)=20 >=20 > TU. The encapsulating DR may perform Path-MTU Discovery to the > RP to determine the effective MTU of the tunnel. This smaller MTU take= s > both the outer IP header and the PIM register header overhead into > account. >=20 > =3D=3D> s/Path-MTU/Path MTU/ for consistency? > =3D=3D> s/This smaller MTU takes/The assigned smaller MTU should take/ > (that is, just doing PMTUD does not give you the smaller MTU -- you hav= e to > subtract the header lengths from that as well...) >=20 > In IPv6, the DR MUST perform Path-MTU discovery, and an ICMP > Fragmentation Required message MUST be sent by the encapsulating DR if >=20 > =3D=3D> s/Fragmentation Required/Packet Too Big/ > =3D=3D> you could maybe add informative refs to PMTUD spec here as well= -- the > same would apply to the bit about copying ECN w/ tunnels. >=20 > (sect 4.5.7, sending S,G J/P) > Finally, > if it sees the Generation ID of its upstream neighbor change, it knows > that the upstream neighbor has lost state, and it should refresh the > state by scheduling a Join(S,G) to be sent almost immediately. >=20 > =3D=3D> why is this only discussed here -- this appears to be a more ge= neric > even, which should triggger sending Joins for *all* groups or S,G pairs > immediately? >=20 > MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing > metrics associated with the route to a particular (unicast) destination > X >=20 > =3D=3D> is it clear enough which specific preferences and metrics you'r= e talking > about .. now that many implementations provide so many of them? >=20 > This specification does not mandate the use of a single mechanism to > provide routers with the information to perform the group-to-RP mapping. > Currently three mechanisms are possible, and all three have associated > problems: > = =20 > Static Configuration > [...] >=20 > =3D=3D> make that "at least three mechanisms", or just include Embedded= -RP here, > with an informational reference. >=20 > 4.9. Source-Specific Multicast > = =20 > The Source-Specific Multicast (SSM) service model [6] can be implemente= d > with a strict subset of the PIM-SM protocol mechanisms. Both regular I= P > Multicast and SSM semantics can coexist on a single router and both can > be implemented using the PIM-SM protocol. A range of multicast > addresses, currently 232.0.0.0/8 in IPv4, is reserved for SSM >=20 > =3D=3D> worth spelling out the equivalent in IPv6 as well? >=20 > If the packet's length is > not an integral number of 16-bit words, the packet is padded with = a > trailing byte of zero before performing the checksum. >=20 > =3D=3D> this was under the IPv6 checksum part. If this isn't IPv6 spec= ific, > separate as a paragraph of it's own. >=20 > 11. Index >=20 > =3D=3D> add the IPR and copyright sections. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > editorial > --------- >=20 > This document is a product of the IETF PIM WG. Comments should be > addressed to the authors, or the WG's mailing list at > pim@catarina.usc.edu. >=20 > =3D=3D> the m-l is now pim@ietf.org >=20 > Designated Router (DR): > A shared-media LAN like Ethernet may have multiple PIM-SM routers > connected to it. If the LAN has directly connected hosts, then a > single one of these routers, the DR, will act on behalf of those > hosts with respect to the PIM-SM protocol. >=20 > =3D=3D> "If the LAN.." is not accurate, because this happens irrespecti= ve of > whether there are hosts on the LAN or not. Maybe like: >=20 > "A single one of these routers, the DR, will act on behalf of directly > connected hosts with respect to the PIM-SM protocol." >=20 > (the same in section 4.3) >=20 > ..... >=20 > MRIB Multicast Routing Information Base. This is the multicast > topology table, which is typically derived from the unicast > routing table, or routing protocols such as MBGP that carry > multicast-specific topology information. In PIM-SM, the MRIB is > used to decide where to send Join/Prune messages. >=20 > =3D=3D> MRIB is used for other purposes as well, mainly, where to expec= t to > receive such messages, right? >=20 > In phase one, a multicast receiver expresses its interest in receiving > traffic destined for a multicast group. Typically it does this using > IGMP [5] or MLD [3], but other mechanisms might also serve this purpose. > One of the receiver's local routers is elected as the Designated Router > (DR) for that subnet. >=20 > =3D=3D> s/is elected/has been elected/ (this happens before anyone expr= essing > interest) >=20 > The (*,G) Join travels > hop-by-hop towards the RP for the group, and in each router it passes > through, multicast tree state for group G is instantiated. >=20 > =3D=3D> wouldn't "initialized" be better than "instantiated". Anyway..= works > for me (this happens a lot elsewhere as well..) >=20 > o Traveling all the way to the RP, and then back down the shared tree > may entail the packets traveling a relatively long distance to reach > receivers that are close to the sender. For some applications, this > increased latency is undesirable. >=20 > =3D=3D> s/latency/latency or bandwidth consumption/ ? >=20 > While the RP is in the process of joining the source-specific tree for > S, the data packets will continue being encapsulated to the RP. >=20 > =3D=3D> s/being/to be/ >=20 > To obtain lower latencies, a router on the receiver's LAN, typically th= e > DR, may optionally initiate a transfer from the shared tree to a source= - > specific shortest-path tree (SPT). >=20 > =3D=3D> s/latencies/latencies or more efficient bandwidth consumption/ >=20 > At this point the receiver (or a router upstream of the receiver) will > be receiving two copies of the data >=20 > =3D=3D> s/receiver/receiver's DR/ ? (and/or remove the thing in ()'s) >=20 > Multi-access Transit LANs > = =20 > The overview so far has concerned itself with point-to-point links. >=20 > =3D=3D> s/links/transit links/ >=20 > o Neighbor's Gen ID. > = =20 > =3D=3D> consistency: some places say "GenID", some others "Gen ID" or > "Generation ID". >=20 > The SPTbit is used to indicate whether forwarding is taking place on th= e >=20 > =3D=3D> consistency: some places say "SPTbit", others "SPT bit". make = it > uniform. >=20 > The primary IP address of a neighbor is the link-local > address that it uses as the source of its PIM Hello messages. >=20 > =3D=3D> as these statements are generic, maybe do a lot of > s/link-local/(link-local)/ so it applies better to both v4 and v6. >=20 > pim_include(*,G) =3D > { all interfaces I such that: > ( ( I_am_DR( I ) AND lost_assert(*,G,I) =3D=3D FALSE ) > OR AssertWinner(*,G,I) =3D=3D me ) > AND local_receiver_include(*,G,I) } >=20 > =3D=3D> note that nowhere you seem to be defining "AssertWinner(x,x,x)"= even > though that's rather straightforward. >=20 > 4.2.1. Last-hop switchover to the SPT > = =20 > =3D=3D> s/switchover/Switchover/ (similar elsewhere as applicable) >=20 > PIM-Hello messages are sent periodically on each PIM-enabled interface. >=20 > =3D=3D> in some places it's "PIM-Hello", in others "PIM Hello". Make i= t > consistent. >=20 > 4.3.4. Maintaining Secondary Address Lists > = =20 > Communication of a routers interface secondary addresses to its PIM > neighbors is necessary to provide the neighbors with a mechanism for >=20 > =3D=3D> s/routers/router's/ >=20 > if( I_am_RP(G) AND outer.dst =3D=3D RP(G) ) { > bool sentRegisterStop =3D FALSE; >=20 > =3D=3D> remove "bool" -- typically the variables don't have the type in= the > pseudocode in this spec (same applies elsewhere as well) >=20 > message SHOULD be discarded without further processing. In addition, i= f > the Hello message from a neighbor was authenticated using IPsec AH (see > Section 6.3) then all Join/Prune messages from that neighbor MUST also >=20 > =3D=3D> s/AH/Authentication Header (AH)/ >=20 > Join (J) > The interface has (*,*,RP) Join state which will cause us to > forward packets destined for any group handled by RP from thi= s > interface except if there is also (S,G,rpt) prune information > (see Section 4.5.4) or the router lost an assert on this > interface. >=20 > =3D=3D> cause "us" -- what's us? reword..? >=20 > 4.7. PIM Multicast Border Router Behavior > = =20 > In some cases PIM-SM domains will interconnect with non-PIM domains. >=20 > =3D=3D> s/non-PIM/non-PIM multicast/ >=20 > 3ffe:b00:c18:1::10 would be computed as 0x3ffe0b00 ^ 0x0c180001 ^ > 0x00000000 ^ 0x00000010, where ^ represents the exclusive-or > operation. >=20 > =3D=3D> use 2001:db8::/32 in the examples, please. >=20 > The following rules override the normal PIM-SM behavior for a multicast > address G in the SSM reserved range: >=20 > =3D=3D> remove "reserved" >=20 > PIM messages are either unicast (e.g. Registers and Register-Stop), or > multicast with TTL 1 to the =01LL-PIM-ROUTERS' group (e.g. Join/Prune, > Asserts, etc.). The source address used for unicast messages is a > domain-wide reachable address; the source address used for multicast > messages is the link-local address of the interface on which the messag= e > is being sent. >=20 > =3D=3D> s/link-local/(link-local) primary/ ? >=20 > The IPv4 =01LL-PIM-ROUTERS' group is =E0.0.0.13'. The IPv6 =01LL-PIM- > ROUTERS' group is =06f02::d'. > = =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |PIM Ver| Type | Reserved | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > =3D=3D> add a prelude before the bit diagram, like "PIM header common t= o all > messages is:" >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > | Type =3D 1 | Length =3D 2 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > | Holdtime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > =3D=3D> s/Holdtime/Holdtime / >=20 > OptionTypes 17 thru 65000 are assigned by the IANA. OptionTypes > 65001 through 65535 are reserved for Private Use, as defined in > [10]. > Unknown options may be ignored. The "Holdtime" option MUST be > implemented; the "DR Priority" and "Generation ID" options SHOULD >=20 > =3D=3D> add a return after "[10]." >=20 > 4.10.5. Join/Prune Message Format > = =20 > =3D=3D> please cut down the format by a few lines; it gets cut into two= pages by > one line already, and it would be very nice if it fit in the same page > with the preamble of 4.10.5. >=20 > Values 128 through 250 are designated to be assigned by the IANA > based upon IESG Approval, as defined in [10]. >=20 > =3D=3D> s/assigned/assigned for PIM/ ? (at least so I think it said ear= lier in > the spec..) >=20 > Similarly, a Designated > Router SHOULD NOT accept a Register-Stop packet whose IP source address > is not a valid RP address for the local domain. >=20 > =3D=3D> s/for the local domain/as given by the group-to-RP mapping/ >=20 > multicast messages is addressed (one such proposal is [9] ), the anti- >=20 > =3D=3D> s/] /]/ >=20 >=20 >=20 >=20 --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Apr 28 16:56:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19742 for ; Wed, 28 Apr 2004 16:56:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIut8-0003w0-I4; Wed, 28 Apr 2004 15:38:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIumJ-0001ul-GT for pim@optimus.ietf.org; Wed, 28 Apr 2004 15:31:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11273; Wed, 28 Apr 2004 15:31:29 -0400 (EDT) Message-Id: <200404281931.PAA11273@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: pim@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 28 Apr 2004 15:31:29 -0400 Subject: [pim] I-D ACTION:draft-ietf-pim-bidir-06.txt Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , --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-06.txt,.ps Pages : 45 Date : 2004-4-28 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-06.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-06.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-06.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-4-28153240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-bidir-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-bidir-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28153240.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Apr 28 17:36:41 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24894 for ; Wed, 28 Apr 2004 17:36:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwPW-0006af-FF; Wed, 28 Apr 2004 17:16:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIvVO-0000zz-2R for pim@optimus.ietf.org; Wed, 28 Apr 2004 16:18:06 -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 QAA15484 for ; Wed, 28 Apr 2004 16:18:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIvVL-0006Pz-1t for pim@ietf.org; Wed, 28 Apr 2004 16:18:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIvUO-0006GG-00 for pim@ietf.org; Wed, 28 Apr 2004 16:17:05 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIvTM-00061a-00 for pim@ietf.org; Wed, 28 Apr 2004 16:16:00 -0400 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SKFUW9026559 for ; Wed, 28 Apr 2004 13:15:30 -0700 (PDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2004 11:54:33 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SJgYWB016698 for ; Wed, 28 Apr 2004 12:42:36 -0700 (PDT) Received: from irp-view6.cisco.com (irp-view6.cisco.com [171.70.65.143]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASN14308; Wed, 28 Apr 2004 12:35:00 -0700 (PDT) Date: Wed, 28 Apr 2004 12:35:47 -0700 (PDT) From: Mike McBride To: pim@ietf.org Subject: [pim] WG Last Call - draft-ietf-pim-bidir-06 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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=none autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Today begins a Working Group Last Call for the Bi-Directional PIM Specification. The Last Call runs 2 weeks from Wednesday, April 28th, 2004 to Wednesday, May 12th, 2004. Please review this document and send comments either to the list or directly to the authors. The document can be found here: http://www.icir.org/kouvelas/pim/draft-ietf-pim-bidir-06.ps http://www.icir.org/kouvelas/pim/draft-ietf-pim-bidir-06.txt Thanks, Mike & Tom _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Apr 28 17:44:29 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25369 for ; Wed, 28 Apr 2004 17:44:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwZ5-0003tY-PU for pim-archive@odin.ietf.org; Wed, 28 Apr 2004 17:25:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SLPxcT014969 for pim-archive@odin.ietf.org; Wed, 28 Apr 2004 17:25:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwIW-0001Zv-Kp for pim-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 17:08:52 -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 RAA20841 for ; Wed, 28 Apr 2004 17:08:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwIS-0005fA-GV for pim-web-archive@ietf.org; Wed, 28 Apr 2004 17:08:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwFZ-00059Q-00 for pim-web-archive@ietf.org; Wed, 28 Apr 2004 17:05:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIwDd-0004pQ-02 for pim-web-archive@ietf.org; Wed, 28 Apr 2004 17:03:49 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIw6K-0000iM-9t for pim-web-archive@ietf.org; Wed, 28 Apr 2004 16:56:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIut8-0003w0-I4; Wed, 28 Apr 2004 15:38:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIumJ-0001ul-GT for pim@optimus.ietf.org; Wed, 28 Apr 2004 15:31:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11273; Wed, 28 Apr 2004 15:31:29 -0400 (EDT) Message-Id: <200404281931.PAA11273@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: pim@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 28 Apr 2004 15:31:29 -0400 Subject: [pim] I-D ACTION:draft-ietf-pim-bidir-06.txt Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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-06.txt,.ps Pages : 45 Date : 2004-4-28 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-06.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-06.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-06.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-4-28153240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-bidir-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-bidir-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28153240.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Wed Apr 28 18:02:23 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26964 for ; Wed, 28 Apr 2004 18:02:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwvR-00066m-4J; Wed, 28 Apr 2004 17:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwcL-0005Ew-Jf for pim@optimus.ietf.org; Wed, 28 Apr 2004 17:29:21 -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 RAA23836 for ; Wed, 28 Apr 2004 17:29:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwcH-0000jY-UI for pim@ietf.org; Wed, 28 Apr 2004 17:29:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwZj-0000IJ-00 for pim@ietf.org; Wed, 28 Apr 2004 17:26:40 -0400 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIwXd-00000i-00 for pim@ietf.org; Wed, 28 Apr 2004 17:24:29 -0400 Received: from smtp2.procket.com (smtp2.procket.com [65.174.124.37]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i3SLNxbI022896 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Apr 2004 14:24:00 -0700 (PDT) (envelope-from dino@procket.com) Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i3SNVXAw000569 for ; Wed, 28 Apr 2004 16:31:33 -0700 (PDT) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i3SLNnd1015112 for ; Wed, 28 Apr 2004 14:23:49 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i3SLNnrl013123; Wed, 28 Apr 2004 14:23:49 -0700 Date: Wed, 28 Apr 2004 14:23:49 -0700 Message-Id: <200404282123.i3SLNnrl013123@dino-pc.procket.com> From: Dino Farinacci To: pim@catarina.usc.edu Subject: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-bidir-06.txt] 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=none autolearn=no version=2.60 Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Can the authors send diffs please. That is semantic diffs (in english) and not the output from 'diff'. Dino ------------------------------------------------------------------------------- ------- Start of forwarded message ------- Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: pim@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 28 Apr 2004 15:31:29 -0400 Subject: [pim] I-D ACTION:draft-ietf-pim-bidir-06.txt Sender: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , - --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-06.txt,.ps Pages : 45 Date : 2004-4-28 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-06.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-06.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-06.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-4-28153240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-bidir-06.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-bidir-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28153240.I-D@ietf.org> - --OtherAccess-- - --NextPart-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim ------- End of forwarded message ------- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Apr 28 18:23:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29125 for ; Wed, 28 Apr 2004 18:23:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxJb-0002kd-97 for pim-archive@odin.ietf.org; Wed, 28 Apr 2004 18:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SME3o3010555 for pim-archive@odin.ietf.org; Wed, 28 Apr 2004 18:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIx1x-0008Gg-Dt for pim-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 17:55:49 -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 RAA26346 for ; Wed, 28 Apr 2004 17:55: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 1BIx1t-0003c8-Dn for pim-web-archive@ietf.org; Wed, 28 Apr 2004 17:55:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwzl-0003Cy-00 for pim-web-archive@ietf.org; Wed, 28 Apr 2004 17:53:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIwxE-0002dE-02 for pim-web-archive@ietf.org; Wed, 28 Apr 2004 17:50:56 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIwj0-0001gU-62 for pim-web-archive@ietf.org; Wed, 28 Apr 2004 17:36:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwPW-0006af-FF; Wed, 28 Apr 2004 17:16:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIvVO-0000zz-2R for pim@optimus.ietf.org; Wed, 28 Apr 2004 16:18:06 -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 QAA15484 for ; Wed, 28 Apr 2004 16:18:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIvVL-0006Pz-1t for pim@ietf.org; Wed, 28 Apr 2004 16:18:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIvUO-0006GG-00 for pim@ietf.org; Wed, 28 Apr 2004 16:17:05 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIvTM-00061a-00 for pim@ietf.org; Wed, 28 Apr 2004 16:16:00 -0400 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SKFUW9026559 for ; Wed, 28 Apr 2004 13:15:30 -0700 (PDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2004 11:54:33 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3SJgYWB016698 for ; Wed, 28 Apr 2004 12:42:36 -0700 (PDT) Received: from irp-view6.cisco.com (irp-view6.cisco.com [171.70.65.143]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASN14308; Wed, 28 Apr 2004 12:35:00 -0700 (PDT) Date: Wed, 28 Apr 2004 12:35:47 -0700 (PDT) From: Mike McBride To: pim@ietf.org Subject: [pim] WG Last Call - draft-ietf-pim-bidir-06 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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=none autolearn=no version=2.60 Today begins a Working Group Last Call for the Bi-Directional PIM Specification. The Last Call runs 2 weeks from Wednesday, April 28th, 2004 to Wednesday, May 12th, 2004. Please review this document and send comments either to the list or directly to the authors. The document can be found here: http://www.icir.org/kouvelas/pim/draft-ietf-pim-bidir-06.ps http://www.icir.org/kouvelas/pim/draft-ietf-pim-bidir-06.txt Thanks, Mike & Tom _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Wed Apr 28 18:27:34 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29451 for ; Wed, 28 Apr 2004 18:27:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxKA-0003jC-6o for pim-archive@odin.ietf.org; Wed, 28 Apr 2004 18:14:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SMEcB7014325 for pim-archive@odin.ietf.org; Wed, 28 Apr 2004 18:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIx9Q-0003qT-V5 for pim-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 18:03:33 -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 SAA27054 for ; Wed, 28 Apr 2004 18:03:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIx9N-0004Li-0J for pim-web-archive@ietf.org; Wed, 28 Apr 2004 18:03:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIx8T-0004JJ-00 for pim-web-archive@ietf.org; Wed, 28 Apr 2004 18:02:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIx7o-0004GV-00 for pim-web-archive@ietf.org; Wed, 28 Apr 2004 18:01:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwvR-00066m-4J; Wed, 28 Apr 2004 17:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwcL-0005Ew-Jf for pim@optimus.ietf.org; Wed, 28 Apr 2004 17:29:21 -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 RAA23836 for ; Wed, 28 Apr 2004 17:29:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwcH-0000jY-UI for pim@ietf.org; Wed, 28 Apr 2004 17:29:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwZj-0000IJ-00 for pim@ietf.org; Wed, 28 Apr 2004 17:26:40 -0400 Received: from catarina.usc.edu ([204.57.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1BIwXd-00000i-00 for pim@ietf.org; Wed, 28 Apr 2004 17:24:29 -0400 Received: from smtp2.procket.com (smtp2.procket.com [65.174.124.37]) by catarina.usc.edu (8.12.9/8.12.9) with ESMTP id i3SLNxbI022896 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Apr 2004 14:24:00 -0700 (PDT) (envelope-from dino@procket.com) Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i3SNVXAw000569 for ; Wed, 28 Apr 2004 16:31:33 -0700 (PDT) Received: from dino-pc.procket.com (dino-pc.procket.com [10.4.17.33]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i3SLNnd1015112 for ; Wed, 28 Apr 2004 14:23:49 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id i3SLNnrl013123; Wed, 28 Apr 2004 14:23:49 -0700 Date: Wed, 28 Apr 2004 14:23:49 -0700 Message-Id: <200404282123.i3SLNnrl013123@dino-pc.procket.com> From: Dino Farinacci To: pim@catarina.usc.edu Subject: [Internet-Drafts@ietf.org: [pim] I-D ACTION:draft-ietf-pim-bidir-06.txt] Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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=none autolearn=no version=2.60 Can the authors send diffs please. That is semantic diffs (in english) and not the output from 'diff'. Dino ------------------------------------------------------------------------------- ------- Start of forwarded message ------- Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: pim@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 28 Apr 2004 15:31:29 -0400 Subject: [pim] I-D ACTION:draft-ietf-pim-bidir-06.txt Sender: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , - --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-06.txt,.ps Pages : 45 Date : 2004-4-28 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-06.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-06.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-06.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-4-28153240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-bidir-06.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-bidir-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28153240.I-D@ietf.org> - --OtherAccess-- - --NextPart-- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim ------- End of forwarded message ------- _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Apr 30 07:43:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11539 for ; Fri, 30 Apr 2004 07:43:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWKC-00040q-Ro; Fri, 30 Apr 2004 07:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWFT-0003Yd-Fk for pim@optimus.ietf.org; Fri, 30 Apr 2004 07:32:07 -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 HAA11049 for ; Fri, 30 Apr 2004 07:32:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWFS-0003Ih-JM for pim@ietf.org; Fri, 30 Apr 2004 07:32:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWEY-000393-00 for pim@ietf.org; Fri, 30 Apr 2004 07:31:11 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BJWE1-0002xS-00 for pim@ietf.org; Fri, 30 Apr 2004 07:30:37 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 12:30:10 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803580FEC@baker.datcon.co.uk> From: James Lingard To: "'ala@nexthop.com'" , "'jonathan.nicholas@itt.com'" , "'wfs@nexthop.com'" Cc: "'pim@ietf.org'" Date: Fri, 30 Apr 2004 12:29:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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=none autolearn=no version=2.60 Subject: [pim] Minor error in description of State-Refresh message in PIM-DM dra ft Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Hi, We've noticed an error in the description of the format of the State-Refresh message in draft-ietf-pim-dm-new-v2-04.txt. In section 4.7.10, page 44, the 'Originator Address' field of this message is incorrectly described as being of Encoded Source Address format, whereas it should actually be of Encoded Unicast Address format. (This is correct in the diagram, but incorrect in the following text.) I see that this was pointed out by someone else back in September (see email titled "[pim] Question about draft-ietf-pim-dm-new-v2-04.txt" from 2003-09-15), but as there hasn't been an updated version of the draft since then, I just wanted to check that this hasn't been forgotten about. Thanks, James. --- James Lingard Data Connection Ltd (DCL) http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Apr 30 07:51:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11772 for ; Fri, 30 Apr 2004 07:51:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWVe-0005yJ-BX for pim-archive@odin.ietf.org; Fri, 30 Apr 2004 07:48:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UBmoBf022955 for pim-archive@odin.ietf.org; Fri, 30 Apr 2004 07:48:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWS4-0005Vy-NR for pim-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 07:45:08 -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 HAA11622 for ; Fri, 30 Apr 2004 07:45:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWS3-0005XH-TB for pim-web-archive@ietf.org; Fri, 30 Apr 2004 07:45:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWR7-0005Mt-00 for pim-web-archive@ietf.org; Fri, 30 Apr 2004 07:44:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJWQM-0005Cu-00 for pim-web-archive@ietf.org; Fri, 30 Apr 2004 07:43:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWKC-00040q-Ro; Fri, 30 Apr 2004 07:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWFT-0003Yd-Fk for pim@optimus.ietf.org; Fri, 30 Apr 2004 07:32:07 -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 HAA11049 for ; Fri, 30 Apr 2004 07:32:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWFS-0003Ih-JM for pim@ietf.org; Fri, 30 Apr 2004 07:32:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWEY-000393-00 for pim@ietf.org; Fri, 30 Apr 2004 07:31:11 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BJWE1-0002xS-00 for pim@ietf.org; Fri, 30 Apr 2004 07:30:37 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 12:30:10 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803580FEC@baker.datcon.co.uk> From: James Lingard To: "'ala@nexthop.com'" , "'jonathan.nicholas@itt.com'" , "'wfs@nexthop.com'" Cc: "'pim@ietf.org'" Date: Fri, 30 Apr 2004 12:29:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [pim] Minor error in description of State-Refresh message in PIM-DM dra ft Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , 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=none autolearn=no version=2.60 Hi, We've noticed an error in the description of the format of the State-Refresh message in draft-ietf-pim-dm-new-v2-04.txt. In section 4.7.10, page 44, the 'Originator Address' field of this message is incorrectly described as being of Encoded Source Address format, whereas it should actually be of Encoded Unicast Address format. (This is correct in the diagram, but incorrect in the following text.) I see that this was pointed out by someone else back in September (see email titled "[pim] Question about draft-ietf-pim-dm-new-v2-04.txt" from 2003-09-15), but as there hasn't been an updated version of the draft since then, I just wanted to check that this hasn't been forgotten about. Thanks, James. --- James Lingard Data Connection Ltd (DCL) http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-admin@ietf.org Fri Apr 30 08:29:21 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13342 for ; Fri, 30 Apr 2004 08:29:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJX5f-0002DM-Gk; Fri, 30 Apr 2004 08:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWw2-0000k4-2n for pim@optimus.ietf.org; Fri, 30 Apr 2004 08:16:06 -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 IAA12668 for ; Fri, 30 Apr 2004 08:16:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWw0-0002tA-SH for pim@ietf.org; Fri, 30 Apr 2004 08:16:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWv7-0002im-00 for pim@ietf.org; Fri, 30 Apr 2004 08:15:09 -0400 Received: from gate12.itt.com ([151.190.254.107] helo=fwetgfw2r.itt.com) by ietf-mx with esmtp (Exim 4.12) id 1BJWuS-0002YZ-00 for pim@ietf.org; Fri, 30 Apr 2004 08:14:28 -0400 Received: from no.name.available by fwetgfw2r.itt.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Fri, 30 Apr 2004 07:14:28 -0500 Received: from njbridge.avionics.de.ittind.com ([151.190.100.204]) by fwdcmail5.fwdc.de.ittind.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 07:14:19 -0500 Received: from ACDNJMAILSRV01.acd.de.ittind.com ([151.190.3.217]) by njbridge.avionics.de.ittind.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 08:14:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Apr 2004 08:14:15 -0400 Message-ID: <2CA4524FA012F14BAE5D896D492B3868101A14@ACDNJMAILSRV02.acd.de.ittind.com> Thread-Topic: Minor error in description of State-Refresh message in PIM-DM draft Thread-Index: AcQupn5nZj7Bv9RST0+buZkfA1H5YgABc8bA From: "Nicholas, Jonathan" To: "James Lingard" , , Cc: X-OriginalArrivalTime: 30 Apr 2004 12:14:16.0417 (UTC) FILETIME=[A82FBD10:01C42EAC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [pim] RE: Minor error in description of State-Refresh message in PIM-DM draft Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thank you for your comment. No, it hasn't been forgotten about. That item= has been corrected and PIM-DM is in IESG review. Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communications Division > -----Original Message----- > From: James Lingard [mailto:James.Lingard@dataconnection.com] > Sent: Friday, April 30, 2004 7:30 AM > To: 'ala@nexthop.com'; Nicholas, Jonathan; 'wfs@nexthop.com' > Cc: 'pim@ietf.org' > Subject: Minor error in description of State-Refresh message in PIM-DM > draft >=0D >=0D > Hi, >=0D > We've noticed an error in the description of the format of=0D > the State-Refresh > message in draft-ietf-pim-dm-new-v2-04.txt. In section=0D > 4.7.10, page 44, the > 'Originator Address' field of this message is incorrectly=0D > described as being > of Encoded Source Address format, whereas it should actually=0D > be of Encoded > Unicast Address format. (This is correct in the diagram, but=0D > incorrect in > the following text.) >=0D > I see that this was pointed out by someone else back in=0D > September (see email > titled "[pim] Question about draft-ietf-pim-dm-new-v2-04.txt" from > 2003-09-15), but as there hasn't been an updated version of=0D > the draft since > then, I just wanted to check that this hasn't been forgotten about. >=0D > Thanks, > James. >=0D > --- > James Lingard > Data Connection Ltd (DCL) > http://www.dataconnection.com/ >=0D ************************************ This email and any files transmitted with it are proprietary and intended= solely for the use of the individual or entity to whom they are addressed.= If you have received this email in error please notify the sender. Please note that any views or opinions= presented in this email are solely those of the author and do not= necessarily represent those of ITT Industries, Inc. The recipient should check this email and any attachments for the presence= of viruses. ITT Industries accepts no liability for any damage caused by= any virus transmitted by this email. ************************************ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From exim@www1.ietf.org Fri Apr 30 08:35:10 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13853 for ; Fri, 30 Apr 2004 08:35:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJXCB-0003A2-Fh for pim-archive@odin.ietf.org; Fri, 30 Apr 2004 08:32:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UCWlY5012151 for pim-archive@odin.ietf.org; Fri, 30 Apr 2004 08:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJX9g-0002p6-Bv for pim-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 08:30:12 -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 IAA13391 for ; Fri, 30 Apr 2004 08:30:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJX9f-0005Mj-9G for pim-web-archive@ietf.org; Fri, 30 Apr 2004 08:30:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJX8f-0005C2-00 for pim-web-archive@ietf.org; Fri, 30 Apr 2004 08:29:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJX8Q-000525-00 for pim-web-archive@ietf.org; Fri, 30 Apr 2004 08:28:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJX5f-0002DM-Gk; Fri, 30 Apr 2004 08:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJWw2-0000k4-2n for pim@optimus.ietf.org; Fri, 30 Apr 2004 08:16:06 -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 IAA12668 for ; Fri, 30 Apr 2004 08:16:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJWw0-0002tA-SH for pim@ietf.org; Fri, 30 Apr 2004 08:16:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJWv7-0002im-00 for pim@ietf.org; Fri, 30 Apr 2004 08:15:09 -0400 Received: from gate12.itt.com ([151.190.254.107] helo=fwetgfw2r.itt.com) by ietf-mx with esmtp (Exim 4.12) id 1BJWuS-0002YZ-00 for pim@ietf.org; Fri, 30 Apr 2004 08:14:28 -0400 Received: from no.name.available by fwetgfw2r.itt.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Fri, 30 Apr 2004 07:14:28 -0500 Received: from njbridge.avionics.de.ittind.com ([151.190.100.204]) by fwdcmail5.fwdc.de.ittind.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 07:14:19 -0500 Received: from ACDNJMAILSRV01.acd.de.ittind.com ([151.190.3.217]) by njbridge.avionics.de.ittind.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 08:14:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Apr 2004 08:14:15 -0400 Message-ID: <2CA4524FA012F14BAE5D896D492B3868101A14@ACDNJMAILSRV02.acd.de.ittind.com> Thread-Topic: Minor error in description of State-Refresh message in PIM-DM draft Thread-Index: AcQupn5nZj7Bv9RST0+buZkfA1H5YgABc8bA From: "Nicholas, Jonathan" To: "James Lingard" , , Cc: X-OriginalArrivalTime: 30 Apr 2004 12:14:16.0417 (UTC) FILETIME=[A82FBD10:01C42EAC] Content-Transfer-Encoding: quoted-printable Subject: [pim] RE: Minor error in description of State-Refresh message in PIM-DM draft Sender: pim-admin@ietf.org Errors-To: pim-admin@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol Independent Multicast List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thank you for your comment. No, it hasn't been forgotten about. That item= has been corrected and PIM-DM is in IESG review. Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communications Division > -----Original Message----- > From: James Lingard [mailto:James.Lingard@dataconnection.com] > Sent: Friday, April 30, 2004 7:30 AM > To: 'ala@nexthop.com'; Nicholas, Jonathan; 'wfs@nexthop.com' > Cc: 'pim@ietf.org' > Subject: Minor error in description of State-Refresh message in PIM-DM > draft >=0D >=0D > Hi, >=0D > We've noticed an error in the description of the format of=0D > the State-Refresh > message in draft-ietf-pim-dm-new-v2-04.txt. In section=0D > 4.7.10, page 44, the > 'Originator Address' field of this message is incorrectly=0D > described as being > of Encoded Source Address format, whereas it should actually=0D > be of Encoded > Unicast Address format. (This is correct in the diagram, but=0D > incorrect in > the following text.) >=0D > I see that this was pointed out by someone else back in=0D > September (see email > titled "[pim] Question about draft-ietf-pim-dm-new-v2-04.txt" from > 2003-09-15), but as there hasn't been an updated version of=0D > the draft since > then, I just wanted to check that this hasn't been forgotten about. >=0D > Thanks, > James. >=0D > --- > James Lingard > Data Connection Ltd (DCL) > http://www.dataconnection.com/ >=0D ************************************ This email and any files transmitted with it are proprietary and intended= solely for the use of the individual or entity to whom they are addressed.= If you have received this email in error please notify the sender. Please note that any views or opinions= presented in this email are solely those of the author and do not= necessarily represent those of ITT Industries, Inc. The recipient should check this email and any attachments for the presence= of viruses. ITT Industries accepts no liability for any damage caused by= any virus transmitted by this email. ************************************ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim