From pi.marc@gmail.com Sun Nov 04 22:24:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IosZd-0000wN-Hv for pim-archive@lists.ietf.org; Sun, 04 Nov 2007 22:24:25 -0500 Received: from [82.200.211.146] (helo=fvnk-9b0cb37fcb) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IosZc-0001Ep-LF for pim-archive@lists.ietf.org; Sun, 04 Nov 2007 22:24:25 -0500 X-AntiVirus: Checked by Dr.Web [version: 4.33, engine: 4.33.5.10110, virus records: 165618, updated: 7.01.2007] Received: from Mercedes Mckinney (10.16.13.15) by fvnk-9b0cb37fcb (PowerMTA(TM) v3.2r4) id hfp12o79d23j87 for ; Mon, 5 Nov 2007 09:24:52 +0600 Message-Id: <20071105152452.2178.qmail@fvnk-9b0cb37fcb> To: Subject: October 70% OFF From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
From pimarianna@drachewyn.com Sun Nov 11 09:24:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrDjG-0004Dk-LZ for pim-archive@lists.ietf.org; Sun, 11 Nov 2007 09:24:02 -0500 Received: from router7.emserv.ru ([80.251.112.41]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrDjG-0001uv-2V for pim-archive@lists.ietf.org; Sun, 11 Nov 2007 09:24:02 -0500 Received: from Harriett Garland (10.10.14.12) by router7.emserv.ru (PowerMTA(TM) v3.2r4) id hfp35o78d28j06 for ; Sat, 10 Nov 2007 05:24:57 +0300 Message-Id: <20071110082457.11586.qmail@router7.emserv.ru> To: Subject: October 76% OFF From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
From pim-bounces@ietf.org Sat Nov 17 02:22:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItI0P-0004vy-Ik; Sat, 17 Nov 2007 02:22:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItI0O-0004sb-DE for pim@ietf.org; Sat, 17 Nov 2007 02:22:16 -0500 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItI0K-0001y0-31 for pim@ietf.org; Sat, 17 Nov 2007 02:22:16 -0500 X-IronPort-AV: E=Sophos;i="4.21,430,1188757800"; d="scan'208,217";a="91242126" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 18 Nov 2007 01:57:16 +0530 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAH7M9dF023157; Sat, 17 Nov 2007 12:52:09 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAH7M72J024826; Sat, 17 Nov 2007 07:22:07 GMT Received: from xmb-blr-416.apac.cisco.com ([64.104.140.145]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 12:52:08 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 17 Nov 2007 12:52:06 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A new draft on "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM" Thread-Index: Acgo6o7XQvJOIkF8RVyP38so8Qb7SA== From: "Archana J Patel (archanap)" To: X-OriginalArrivalTime: 17 Nov 2007 07:22:08.0196 (UTC) FILETIME=[8FE97840:01C828EA] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15550.000 X-TM-AS-Result: No--5.683300-8.000000-3 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4628; t=1195284130; x=1196148130; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=archanap@cisco.com; z=From:=20=22Archana=20J=20Patel=20(archanap)=22=20 |Subject:=20A=20new=20draft=20on=20=22PIM=20GR=20Enhancement=20for=20BSR, =20PIM-Bidir=20and=20PIM-SM=22 |Sender:=20; bh=POi3zGlQmpyqllVYjTqLraugnIHnT825ROYXcGnEqzM=; b=2Z7CGX9WrcZHgve+2o5/0oSluyS1PV48GQJH7iicXUyIeSiE3VKldvlsbP1XwdwRgcpnLq+U JnaoHhJhcbk55dcDwNDPp1HBxqO3TV+NJczVanWLNu+fCH8PGx5nIy2s; Authentication-Results: ind-dkim-2; header.From=archanap@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Subject: [pim] A new draft on "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM" X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0438767964==" Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============0438767964== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C828EA.8FC7F10C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C828EA.8FC7F10C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 We have submitted a new Draft "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM". http://www.ietf.org/internet-drafts/draft-kulkarni-pim-gr-enhancement-00 .txt =20 It attempts to address the following Issues : =20 -If Rebooted Router was E-BSR, some of the Group-to-RP mappings will be cleared, once it transitions back to E-BSR, and which might take, in worst case, upto BS_Period interval to get restored, because C-RP Router will not come to know that E-BSR=20 has rebooted, hence the C-RP adv message will be sent only after C-RP Adv Timer expiry. BSM generated by Rebooted Router will have only those Group-to-RP mappings which=20 received during BS_Min_Interval after it transition to E-BSR. =20 -Rebooted BIDIR Router will ignore the triggered joins from Downstream Routers,=20 if they are received almost immediately after hello with New Gen-ID is sent. As BIDIR Router might not have received the RP info or DF election might not=20 be complete yet(as unicast route information is absent). =20 -Same applies to PIM-SM router also, It might choose to ignore triggered (*, G) join in the absence of RP-Info. =20 This draft also suggests the mechanism to refresh active-source information=20 on Rebooted C-RP(if acting as active RP), and to refresh assert-loser and assert-winner state on Rebooted PIM-SM Router. =20 Please review the draft and provide your suggestions and comments. Thanks, Archana ------_=_NextPart_001_01C828EA.8FC7F10C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
 
It attempts to address the following = Issues=20 :
 
-If Rebooted Router was E-BSR, some of = the=20 Group-to-RP mappings will be cleared, once
 it transitions back = to=20 E-BSR, and which might take, in worst case, upto BS_Period = interval
 to=20 get restored, because C-RP Router will not come to know that E-BSR =
 has=20 rebooted, hence the C-RP adv message will be sent only after C-RP Adv = Timer=20 expiry.
 BSM generated by Rebooted Router will have only those=20 Group-to-RP mappings which
 received during BS_Min_Interval = after it=20 transition to E-BSR.
 
-Rebooted BIDIR Router will ignore the = triggered=20 joins from Downstream Routers,
 if they are received almost = immediately=20 after hello with New Gen-ID is sent.
 As BIDIR Router might not = have=20 received the RP info or DF election might not
 be complete = yet(as=20 unicast route information is absent).
 
-Same applies to PIM-SM router also, It = might=20 choose to ignore triggered (*, G) join in
 the = absence of=20 RP-Info.
 
This draft also suggests the mechanism = to refresh=20 active-source information
on Rebooted C-RP(if acting as active RP), = and to=20 refresh assert-loser and
assert-winner state on Rebooted PIM-SM=20 Router.
 
Please review the draft and provide = your=20 suggestions and comments.
Thanks,
Archana
------_=_NextPart_001_01C828EA.8FC7F10C-- --===============0438767964== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============0438767964==-- From pim-bounces@ietf.org Sun Nov 18 21:54:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwmB-0000j3-VU; Sun, 18 Nov 2007 21:54:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itwm9-0000is-UI for pim@ietf.org; Sun, 18 Nov 2007 21:54:18 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Itwm4-0007Ll-0B for pim@ietf.org; Sun, 18 Nov 2007 21:54:17 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRQ007ZEG0QCI@szxga01-in.huawei.com> for pim@ietf.org; Mon, 19 Nov 2007 10:53:15 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRQ00B7BG0OMW@szxga01-in.huawei.com> for pim@ietf.org; Mon, 19 Nov 2007 10:53:14 +0800 (CST) Received: from s33630C ([10.111.12.55]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRQ00B0BG0NYS@szxml03-in.huawei.com> for pim@ietf.org; Mon, 19 Nov 2007 10:53:12 +0800 (CST) Date: Mon, 19 Nov 2007 10:53:11 +0800 From: Su Haiyang Subject: RE: [pim] A new draft on "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM" In-reply-to: To: "'Archana J Patel (archanap)'" , pim@ietf.org Message-id: <004401c82a57$52e32b80$8119fea9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acgo6o7XQvJOIkF8RVyP38so8Qb7SABaTDSA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7191030d885084e634ab0f488bcd9d53 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2087971023==" Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============2087971023== Content-type: multipart/alternative; boundary="Boundary_(ID_kfcU6DWQP5ILPKgz76dYfw)" This is a multi-part message in MIME format. --Boundary_(ID_kfcU6DWQP5ILPKgz76dYfw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear All, Since PIM is a soft-state protocol, it should be the responsibility of the rebooted router to collect PIM joins or RP-Set after it boot up again. It shouldn't count on more cooperation from its neighborhood. And most of the enhancement mentioned at the following draft depends on timer adjustment, which can't give precise control of the router behavior. No prior negotiation may cause compatibility issues of PIM implementations from different vendors. Regarding the issue of RP-Set information inconsistence between rebooted routers, the current protocol definition has given solution: 1. A PIM-SM router can use the RP stored at the PIM join if it just boot up and hasn't got the copy of RP-Set from its neighbor. 2. The Group-RP Mapping expiry timer avoids the Non-BSR router purging its RP-Set after it receives an empty BSM from the rebooted BSR router. Thanks Su Haiyang _____ From: Archana J Patel (archanap) [mailto:archanap@cisco.com] Sent: Saturday, November 17, 2007 3:22 PM To: pim@ietf.org Subject: [pim] A new draft on "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM" Hi, We have submitted a new Draft "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM". http://www.ietf.org/internet-drafts/draft-kulkarni-pim-gr-enhancement-00.txt It attempts to address the following Issues : -If Rebooted Router was E-BSR, some of the Group-to-RP mappings will be cleared, once it transitions back to E-BSR, and which might take, in worst case, upto BS_Period interval to get restored, because C-RP Router will not come to know that E-BSR has rebooted, hence the C-RP adv message will be sent only after C-RP Adv Timer expiry. BSM generated by Rebooted Router will have only those Group-to-RP mappings which received during BS_Min_Interval after it transition to E-BSR. -Rebooted BIDIR Router will ignore the triggered joins from Downstream Routers, if they are received almost immediately after hello with New Gen-ID is sent. As BIDIR Router might not have received the RP info or DF election might not be complete yet(as unicast route information is absent). -Same applies to PIM-SM router also, It might choose to ignore triggered (*, G) join in the absence of RP-Info. This draft also suggests the mechanism to refresh active-source information on Rebooted C-RP(if acting as active RP), and to refresh assert-loser and assert-winner state on Rebooted PIM-SM Router. Please review the draft and provide your suggestions and comments. Thanks, Archana --Boundary_(ID_kfcU6DWQP5ILPKgz76dYfw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear All,

Since PIM is a soft-state protocol, it should be the responsibility of the rebooted router to collect PIM joins or RP-Set after it boot up again.

It shouldn’t count on more cooperation from its neighborhood.

And most of the enhancement mentioned at the following draft depends on timer adjustment, which can’t give precise control of the router behavior. No prior negotiation may cause compatibility issues of PIM implementations from different vendors.

Regarding the issue of RP-Set information inconsistence between rebooted routers, the current protocol definition has given solution:

1.     A PIM-SM router can use the RP stored at the PIM join if it just boot up and hasn’t got the copy of RP-Set from its neighbor.

2.     The Group-RP Mapping expiry timer avoids the Non-BSR router purging its RP-Set after it receives an empty BSM from the rebooted BSR router.

Thanks

Su Haiyang

 

From: Archana J Patel (archanap) [mailto:archanap@cisco.com]
Sent: Saturday, November 17, 2007 3:22 PM
To: pim@ietf.org
Subject: [pim] A new draft on "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM"

 

Hi,

 

We have submitted a new Draft "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM".
http://www.ietf.org/internet-drafts/draft-kulkarni-pim-gr-enhancement-00.txt

 

It attempts to address the following Issues :

 

-If Rebooted Router was E-BSR, some of the Group-to-RP mappings will be cleared, once
 it transitions back to E-BSR, and which might take, in worst case, upto BS_Period interval
 to get restored, because C-RP Router will not come to know that E-BSR
 has rebooted, hence the C-RP adv message will be sent only after C-RP Adv Timer expiry.
 BSM generated by Rebooted Router will have only those Group-to-RP mappings which
 received during BS_Min_Interval after it transition to E-BSR.

 

-Rebooted BIDIR Router will ignore the triggered joins from Downstream Routers,
 if they are received almost immediately after hello with New Gen-ID is sent.
 As BIDIR Router might not have received the RP info or DF election might not
 be complete yet(as unicast route information is absent).

 

-Same applies to PIM-SM router also, It might choose to ignore triggered (*, G) join in
 the absence of RP-Info.

 

This draft also suggests the mechanism to refresh active-source information
on Rebooted C-RP(if acting as active RP), and to refresh assert-loser and
assert-winner state on Rebooted PIM-SM Router.

 

Please review the draft and provide your suggestions and comments.

Thanks,

Archana

--Boundary_(ID_kfcU6DWQP5ILPKgz76dYfw)-- --===============2087971023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============2087971023==-- From pim-bounces@ietf.org Mon Nov 19 00:41:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItzO3-0006dA-BX; Mon, 19 Nov 2007 00:41:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItzO2-0006cg-1P for pim@ietf.org; Mon, 19 Nov 2007 00:41:34 -0500 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItzNz-0004h9-L3 for pim@ietf.org; Mon, 19 Nov 2007 00:41:33 -0500 X-IronPort-AV: E=Sophos;i="4.21,435,1188757800"; d="scan'208,217";a="91301290" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 20 Nov 2007 00:17:00 +0530 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAJ5fTTE014639; Mon, 19 Nov 2007 11:11:29 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAJ5fS2J014505; Mon, 19 Nov 2007 05:41:28 GMT Received: from xmb-blr-416.apac.cisco.com ([64.104.140.145]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 11:10:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [pim] A new draft on "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM" Date: Mon, 19 Nov 2007 11:10:57 +0530 Message-ID: In-Reply-To: <004401c82a57$52e32b80$8119fea9@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pim] A new draft on "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM" Thread-Index: Acgo6o7XQvJOIkF8RVyP38so8Qb7SABaTDSAAAXNTOA= From: "Archana J Patel (archanap)" To: , X-OriginalArrivalTime: 19 Nov 2007 05:40:58.0379 (UTC) FILETIME=[C2D865B0:01C82A6E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15554.000 X-TM-AS-Result: No--9.151200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=26560; t=1195450889; x=1196314889; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=archanap@cisco.com; z=From:=20=22Archana=20J=20Patel=20(archanap)=22=20 |Subject:=20RE=3A=20[pim]=20A=20new=20draft=20on=20=22PIM=20GR=20Enhancem ent=20for=20BSR,=20PIM-Bidir=20and=20PIM-SM=22 |Sender:=20; bh=9Xq+iNQvKNWS7ZTsOMcRF3n6BfSnXpt9ijk4nHTc3E4=; b=wjmEjzeJXVakIwriTivKt9xfsGM4qsOs217k3U/bfZ0EkFnzFbfDw/vF6lUJiK6OUlzBdRD6 2e1qDlMfM2L+NMIApeita1ud++2R3biNYagDbNjZCRMFpb2iCYJ27MYz; Authentication-Results: ind-dkim-2; header.From=archanap@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 489500194134bea022a3070ad86cad76 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1051671208==" Errors-To: pim-bounces@ietf.org This is a multi-part message in MIME format. --===============1051671208== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82A6E.C2C28B34" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82A6E.C2C28B34 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Su Haiyang, =20 Thanks for your Comment. =20 Enhancements mentioned for BSR, BIDIR and PIM-SM Assert-Winner do not depend on timer adjustment. =20 PIM-SM enhancements for Assert-loser and Joins depend on timer adjustment. There can be better solution. We want to address these issues, hence mentioned here.=20 =20 =20 >>1. A PIM-SM router can use the RP stored at the PIM join if it just boot up and hasn't got the copy of RP-Set=20 >>from its neighbor As per RFC, PIM-SM router may chose to ignore the join, if it doesnt have RP-Info. One of the solution can be it must accepts the joins, if it is rebooted router and it does not have RP-Info OR Downstream-router first send BSM with No-Forward bit first before sending Joins so Upstream routers can have RP-Info first. =20 >>2. The Group-RP Mapping expiry timer avoids the Non-BSR router purging its RP-Set after it receives an empty BSM >>from the rebooted BSR router. Group-RP mapping expiry timer is used, if Non-BSR router is receiving empty BSM but consider the case where Rebooted BSR router has received one CRP-Adv message and BSM has sent with one Group-to-RP mapping. Non-BSR routers will cleared all other remaining group-to-rp mappings.=20 Thanks, Archana ________________________________ From: Su Haiyang [mailto:suhaiyang@huawei.com]=20 Sent: Monday, November 19, 2007 8:23 AM To: Archana J Patel (archanap); pim@ietf.org Cc: pim@ietf.org Subject: RE: [pim] A new draft on "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM" Dear All, Since PIM is a soft-state protocol, it should be the responsibility of the rebooted router to collect PIM joins or RP-Set after it boot up again. It shouldn't count on more cooperation from its neighborhood. And most of the enhancement mentioned at the following draft depends on timer adjustment, which can't give precise control of the router behavior. No prior negotiation may cause compatibility issues of PIM implementations from different vendors. Regarding the issue of RP-Set information inconsistence between rebooted routers, the current protocol definition has given solution: 1. A PIM-SM router can use the RP stored at the PIM join if it just boot up and hasn't got the copy of RP-Set from its neighbor. 2. The Group-RP Mapping expiry timer avoids the Non-BSR router purging its RP-Set after it receives an empty BSM from the rebooted BSR router. Thanks Su Haiyang =20 ________________________________ From: Archana J Patel (archanap) [mailto:archanap@cisco.com]=20 Sent: Saturday, November 17, 2007 3:22 PM To: pim@ietf.org Subject: [pim] A new draft on "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM" =20 Hi, =20 We have submitted a new Draft "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM". http://www.ietf.org/internet-drafts/draft-kulkarni-pim-gr-enhancement-00 .txt =20 It attempts to address the following Issues : =20 -If Rebooted Router was E-BSR, some of the Group-to-RP mappings will be cleared, once it transitions back to E-BSR, and which might take, in worst case, upto BS_Period interval to get restored, because C-RP Router will not come to know that E-BSR=20 has rebooted, hence the C-RP adv message will be sent only after C-RP Adv Timer expiry. BSM generated by Rebooted Router will have only those Group-to-RP mappings which=20 received during BS_Min_Interval after it transition to E-BSR. =20 -Rebooted BIDIR Router will ignore the triggered joins from Downstream Routers,=20 if they are received almost immediately after hello with New Gen-ID is sent. As BIDIR Router might not have received the RP info or DF election might not=20 be complete yet(as unicast route information is absent). =20 -Same applies to PIM-SM router also, It might choose to ignore triggered (*, G) join in the absence of RP-Info. =20 This draft also suggests the mechanism to refresh active-source information=20 on Rebooted C-RP(if acting as active RP), and to refresh assert-loser and assert-winner state on Rebooted PIM-SM Router. =20 Please review the draft and provide your suggestions and comments. Thanks, Archana ------_=_NextPart_001_01C82A6E.C2C28B34 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Su Haiyang,
 
Thanks for your Comment.
 
Enhancements mentioned for BSR, BIDIR and = PIM-SM=20 Assert-Winner do not depend on timer = adjustment.
 
PIM-SM enhancements for Assert-loser and = Joins depend=20 on timer adjustment. There can be
better solution. We want to address these = issues, hence=20 mentioned here.
 
 
>>1.    =20 A=20 PIM-SM router can use the RP stored at the PIM join if it just boot up = and=20 hasn’t got the copy of RP-Set
>>from its neighbor
As per RFC, = PIM-SM router=20 may chose to ignore the join, if it doesnt have = RP-Info.  One of the solution = can be it=20 must accepts the joins,
if it is rebooted router and it does = not have=20 RP-Info OR Downstream-router first send BSM with = No-Forward
bit=20 first before sending Joins so Upstream routers can have RP-Info=20 first.
 
>>2.    =20 The Group-RP Mapping expiry = timer avoids=20 the Non-BSR router purging its RP-Set after it receives an empty BSM=20 >>from the rebooted BSR = router.
Group-RP = mapping=20 expiry timer is used, if Non-BSR router is receiving empty BSM but = consider the=20 case where Rebooted BSR router
has = received one=20 CRP-Adv message and BSM has sent with one Group-to-RP mapping. Non-BSR = routers=20 will cleared all other
remaining group-to-rp mappings. 
Thanks,
Archana
From: Su Haiyang = [mailto:suhaiyang@huawei.com]=20
Sent: Monday, November 19, 2007 8:23 AM
To: Archana = J Patel=20 (archanap); pim@ietf.org
Cc: pim@ietf.org
Subject: = RE: [pim]=20 A new draft on "PIM GR Enhancement for BSR, PIM-Bidir and=20 PIM-SM"

Dear=20 All,

Since PIM is = a=20 soft-state protocol, it should be the responsibility of the rebooted = router to=20 collect PIM joins or RP-Set after it boot up again.

It = shouldn’t count on=20 more cooperation from its neighborhood.

And most of = the=20 enhancement mentioned at the following draft depends on timer = adjustment, which=20 can’t give precise control of the router behavior. No prior = negotiation may=20 cause compatibility issues of PIM implementations from different=20 vendors.

Regarding the = issue of=20 RP-Set information inconsistence between rebooted routers, the current = protocol=20 definition has given solution:

1.    =20 A PIM-SM router can use the RP = stored at=20 the PIM join if it just boot up and hasn’t got the copy of RP-Set = from its=20 neighbor.

2.    =20 The Group-RP Mapping expiry = timer avoids=20 the Non-BSR router purging its RP-Set after it receives an empty BSM = from the=20 rebooted BSR router.

Thanks

Su=20 Haiyang

 

From: Archana J Patel = (archanap)=20 [mailto:archanap@cisco.com]
Sent: Saturday, November 17, 2007 = 3:22=20 PM
To: = pim@ietf.org
Subject: [pim] A new draft on = "PIM GR=20 Enhancement for BSR, PIM-Bidir and PIM-SM"

 

Hi,

 

We have submitted a new = Draft "PIM=20 GR Enhancement for BSR, PIM-Bidir and PIM-SM".
http://www.ietf.org/internet-drafts/draft-kulkarni-pim-gr-en= hancement-00.txt

 

It attempts to address the = following=20 Issues :

 

-If Rebooted Router was = E-BSR, some=20 of the Group-to-RP mappings will be cleared, once
 it = transitions back=20 to E-BSR, and which might take, in worst case, upto BS_Period=20 interval
 to get restored, because C-RP Router will not come to = know=20 that E-BSR
 has rebooted, hence the C-RP adv message will be = sent only=20 after C-RP Adv Timer expiry.
 BSM generated by Rebooted Router = will have=20 only those Group-to-RP mappings which
 received during = BS_Min_Interval=20 after it transition to E-BSR.

 

-Rebooted BIDIR Router = will ignore=20 the triggered joins from Downstream Routers,
 if they are = received=20 almost immediately after hello with New Gen-ID is sent.
 As = BIDIR Router=20 might not have received the RP info or DF election might not =
 be=20 complete yet(as unicast route information is = absent).

 

-Same applies to PIM-SM = router also,=20 It might choose to ignore triggered (*, G) join in
 the = absence of=20 RP-Info.

 

This draft also suggests = the=20 mechanism to refresh active-source information
on Rebooted C-RP(if = acting as=20 active RP), and to refresh assert-loser and
assert-winner state on = Rebooted=20 PIM-SM Router.

 

Please review the draft = and provide=20 your suggestions and comments.

Thanks,

Archana

------_=_NextPart_001_01C82A6E.C2C28B34-- --===============1051671208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============1051671208==-- From pim-bounces@ietf.org Mon Nov 19 08:10:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6Oc-000605-Hj; Mon, 19 Nov 2007 08:10:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6OY-0005vr-3f; Mon, 19 Nov 2007 08:10:34 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu6OV-0007jr-UT; Mon, 19 Nov 2007 08:10:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E13D6328B6; Mon, 19 Nov 2007 13:10:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu6O1-0004Fm-Qr; Mon, 19 Nov 2007 08:10:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 08:10:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: pim@ietf.org Subject: [pim] I-D Action:draft-ietf-pim-sm-linklocal-02.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Authentication and Confidentiality in PIM-SM Link-local Messages Author(s) : J. Atwood Filename : draft-ietf-pim-sm-linklocal-02.txt Pages : 25 Date : 2007-11-18 RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link local messages using the IP security (IPsec) Authentication Header (AH) or Encapsulating Security Payload (ESP). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, an optional automated group key management mechanism is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-linklocal-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-sm-linklocal-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-sm-linklocal-02.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: <2007-11-19080112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-sm-linklocal-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-sm-linklocal-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19080112.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From gnhllw@dolat.com.cn Mon Nov 19 09:15:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7PO-00081S-Ht for pim-archive@lists.ietf.org; Mon, 19 Nov 2007 09:15:30 -0500 Received: from [190.42.16.54] (helo=avdb) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iu7PK-0004Lt-TD for pim-archive@lists.ietf.org; Mon, 19 Nov 2007 09:15:30 -0500 Received: from [131.219.234.68] (helo=ujlfu) by avdb with smtp (Exim 4.62 (FreeBSD)) id 1JT0T@-0006g3-6E; Mon, 19 Nov 2007 09:18:57 -0500 Message-ID: <47419A75.8000202@dolat.com.cn> Date: Mon, 19 Nov 2007 09:15:17 -0500 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: pim-archive@lists.ietf.org Subject: re: did you get this yet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 EnerBrite Cuts Energy Costs By 30% EnerBrite Technologies Group, Inc. E t gU $0.008 5 Things to think about for Monday 1. The energy problems of the world are killing business left and right. 2. Government sees no real relief in sight. Corporations are finding their own way out. 3. EnerBrite (e T Gu) provides real solutions to energy costs, reducing them as much as 30%. 4. Already, Hotels like Radisson and Clarion are boasting e t G u's solution helps them meet the challenge of energy in today's market. 5. Huge media coverage on e t g U next week will draw attention from investors and brokers alike. Few penny stocks have the sizzle this company does. Look at the price, read the latest news, and see just how little it has to move to provide you great returns on your investment dollar. Set your buy for early Monday. From pim-bounces@ietf.org Mon Nov 19 18:04:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuFeu-0002WX-As; Mon, 19 Nov 2007 18:04:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuFes-0002WQ-JK for pim@ietf.org; Mon, 19 Nov 2007 18:04:02 -0500 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuFep-0007b2-3s for pim@ietf.org; Mon, 19 Nov 2007 18:04:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 1826F2BB26A; Tue, 20 Nov 2007 00:03:57 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16586-01-91; Tue, 20 Nov 2007 00:03:56 +0100 (CET) Received: from [158.38.160.252] (dhcp252.venaas.no [158.38.160.252]) by tyholt.uninett.no (Postfix) with ESMTP id BCE772BB264; Tue, 20 Nov 2007 00:03:56 +0100 (CET) Message-ID: <47421630.2060500@uninett.no> Date: Tue, 20 Nov 2007 00:03:12 +0100 From: Stig Venaas User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pim@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Mike McBride Subject: [pim] pim wg meeting in Vancouver X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org Please contact Mike and me ASAP with any agenda requests for Vancouver. The tentative slot for our meeting is Tuesday 1850-1950. Stig _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Nov 20 08:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTWZ-0001pN-4H; Tue, 20 Nov 2007 08:52:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTWX-0001og-PS for pim@ietf.org; Tue, 20 Nov 2007 08:52:21 -0500 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuTWU-0002YG-Gq for pim@ietf.org; Tue, 20 Nov 2007 08:52:21 -0500 Received: by py-out-1112.google.com with SMTP id d32so11948246pye for ; Tue, 20 Nov 2007 05:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=QDaD/UeR7cu0xlqIhq36ZMZqZTJcdLgVqSWxyQPCTok=; b=j5VjaAftwF03cBxlPsqHeZwcJtHfLAfNkOp/8PY4XOvFYwpPlGsaDGHjTfvIINTcFeRUlDbzKuV9sp2LSEvFxsjlLhLax4QttxWQP5unIZp2T4iE4NqnvYFYgvuo+oBvwGYWTvTxPOqGJJqb0nPBbOXZ2eV02RpNKoZh66rtFGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nveATRacdHLXuH0n1tp1cUp7AFTuAm82sys7ApdfdF+/tw94GyS37qx8wiirgCBEAha3S7H6t1CYOp13PeVlrL+3sR5E/yYfB1n/7+N82wE4zsYv1GuKLhelzHvDOTQIz9ELtqujuBEGykMzl+AABdUmI61491mgOGxmU+57nl4= Received: by 10.115.59.4 with SMTP id m4mr402314wak.1195566737341; Tue, 20 Nov 2007 05:52:17 -0800 (PST) Received: by 10.114.38.18 with HTTP; Tue, 20 Nov 2007 05:52:17 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 19:22:17 +0530 From: Krish... To: pim@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [pim] Query regarding Assert State Machine in PIMDM X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org This is a query regarding the Assert State machine in PIMDM (RFC3973). Consider the following scenario: ---------------------------------------------------- ----- Host---| A |-------| ----- | | ----- | | C |-----Source | ----- ----- | Host---| B |-------| ----- ---------------------------------------------------- Initially, A's and B's Upstream is C. When data flows, A and B assert on their connected downstream interface. Assume A is the Assert Loser and B is the Assert Winner. A being the loser sends a Prune to B so that B stops forwarding on this interface. So, On B's Downstream interface, AT and PT will be running and these timers will be refreshed with State Refresh messages. Now, Assume a case wherein A's Upstream Link (towards C) is Down. A's new upstream will now be towards B. But B will never send data to A as its AT and PT will be refreshed with SRMs. In such a case, it makes sense for A to send a Graft to B to rejoin the tree. On receipt of the Graft message, B's PT will be cancelled and data will be forwarded. But the AT will still get refreshed with SRMs and B will always be Assert Winner. As per the draft, the Assert State machine remains in Assert Winner state upon the receipt of a Graft message. Any reasons behind this? But, it makes sense that B's Assert state to move to NoInfo upon the receipt of a Graft message on the downstream interface. Please correct me know if I missed anything. Any comments on this are welcome. Thanks & Regards, Krish... _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Nov 20 09:36:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUDG-0000P7-08; Tue, 20 Nov 2007 09:36:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUDE-0000NH-TP for pim@ietf.org; Tue, 20 Nov 2007 09:36:28 -0500 Received: from edge2.itt.com ([151.190.254.12] helo=edge.itt.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuUDD-0004ST-S0 for pim@ietf.org; Tue, 20 Nov 2007 09:36:28 -0500 Received: from fwexhub1.itt.net (10.32.77.207) by fwexedge2.itt.net (10.32.16.12) with Microsoft SMTP Server (TLS) id 8.0.751.0; Tue, 20 Nov 2007 09:36:31 -0500 Received: from FWETGSMTP2.itt.net (10.32.77.201) by fwexhub1.itt.net (10.32.77.207) with Microsoft SMTP Server id 8.0.751.0; Tue, 20 Nov 2007 09:36:26 -0500 Received: from fwdefsmtp2.de.ittind.com ([10.32.77.203]) by FWETGSMTP2.itt.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 09:36:26 -0500 Received: from njbridge01.avionics.de.ittind.com ([10.37.1.77]) by fwdefsmtp2.de.ittind.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 09:36:25 -0500 Received: from ACDNJMAILSRV03.acd.de.ittind.com ([10.37.1.152]) by njbridge01.avionics.de.ittind.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 09:36:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [pim] Query regarding Assert State Machine in PIMDM Date: Tue, 20 Nov 2007 09:36:25 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pim] Query regarding Assert State Machine in PIMDM Thread-Index: AcgrfK1G1mZ/nG/oThWqZ3sIWnxnWgAAYRtw References: From: "Nicholas, Jonathan - ACD " To: "Krish..." , X-OriginalArrivalTime: 20 Nov 2007 14:36:25.0075 (UTC) FILETIME=[BA42EC30:01C82B82] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org Krish, Your assessment is essentially correct. The reason the Assert State Machine remains in the Assert Winner state for B is that (from an abstract specification point of view) there could be other Assert Losers on the A-B network that would become Assert Winners if B were to transition out of the Assert Winner state. Since the externally observable behavior of an Assert Winner is identical to an Assert No Info state, you could transition out of the Assert Winner state to an Assert No Info state and remain compliant with the specification *if* you determined that no other candidate upstream routers remained on the interface. However, the PIM-DM specification contains no mechanisms for making such a determination, so it seems safer to just maintain the Assert Winner state. Jonathan Nicholas > -----Original Message----- > From: Krish... [mailto:cskrishna@gmail.com] > Sent: Tuesday, November 20, 2007 8:52 AM > To: pim@ietf.org > Subject: [pim] Query regarding Assert State Machine in PIMDM > > This is a query regarding the Assert State machine in PIMDM (RFC3973). > > Consider the following scenario: > > ---------------------------------------------------- > ----- > Host---| A |-------| > ----- | > | ----- > | | C |-----Source > | ----- > ----- | > Host---| B |-------| > ----- > ---------------------------------------------------- > > Initially, A's and B's Upstream is C. > When data flows, A and B assert on their connected downstream > interface. > Assume A is the Assert Loser and B is the Assert Winner. > A being the loser sends a Prune to B so that B stops > forwarding on this interface. > So, On B's Downstream interface, AT and PT will be running > and these timers will be refreshed with State Refresh messages. > > Now, Assume a case wherein A's Upstream Link (towards C) is Down. > A's new upstream will now be towards B. > > But B will never send data to A as its AT and PT will be > refreshed with SRMs. > In such a case, it makes sense for A to send a Graft to B to > rejoin the tree. > On receipt of the Graft message, B's PT will be cancelled and > data will be forwarded. > But the AT will still get refreshed with SRMs and B will > always be Assert Winner. > > As per the draft, the Assert State machine remains in Assert > Winner state upon the receipt of a Graft message. > Any reasons behind this? > > But, it makes sense that B's Assert state to move to NoInfo > upon the receipt of a Graft message on the downstream interface. > > Please correct me know if I missed anything. > > Any comments on this are welcome. > > Thanks & Regards, > Krish... > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim > This e-mail and any files transmitted with it may be proprietary and are in= tended solely for the use of the individual or entity to whom they are addr= essed. If you have received this e-mail in error please notify the sender. = Please note that any views or opinions presented in this e-mail are solely = those of the author and do not necessarily represent those of ITT Corporati= on. The recipient should check this e-mail and any attachments for the pres= ence of viruses. ITT accepts no liability for any damage caused by any viru= s transmitted by this e-mail. _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Tue Nov 20 15:15:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZUw-0000zJ-0A; Tue, 20 Nov 2007 15:15:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZUs-0000xX-BA; Tue, 20 Nov 2007 15:15:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuZUr-0000q0-Vv; Tue, 20 Nov 2007 15:15:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id D38252AC5E; Tue, 20 Nov 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuZUr-0006D5-JT; Tue, 20 Nov 2007 15:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Nov 2007 15:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-rpf-vector-05.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : The RPF Vector TLV Author(s) : I. Wijnands, et al. Filename : draft-ietf-pim-rpf-vector-05.txt Pages : 10 Date : 2007-11-20 This document describes a use of the PIM Join Attribute as defined in draft-ietf-pim-join-attributes [I-D.ietf-pim-join-attributes] which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-rpf-vector-05.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-rpf-vector-05.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-rpf-vector-05.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: <2007-11-20141516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-rpf-vector-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-rpf-vector-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-20141516.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Thu Nov 22 13:29:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvGn9-0002cC-Ln; Thu, 22 Nov 2007 13:28:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvGn9-0002c7-9X for pim@ietf.org; Thu, 22 Nov 2007 13:28:47 -0500 Received: from web52108.mail.re2.yahoo.com ([206.190.48.111]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvGn6-0001cx-I3 for pim@ietf.org; Thu, 22 Nov 2007 13:28:47 -0500 Received: (qmail 6315 invoked by uid 60001); 22 Nov 2007 18:28:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=PO6NDYd6JALt1+4Y9F3DVuBDz5pPD3DM0r8eaydilyXCZdn4D6WJVOvIthUJizT+brCsX25EKZck7pBXkiEV755BlxMYpoFdNTAqKJiE9udxjwlXcXJn/J2vHZuEBc5LSojCrTFWRphJ4bJJIztH+GQfljGkqJerG0f+jyJEtBA=; X-YMail-OSG: 2aNumDsVM1ky8PHqjykj83Fm0DQ0MSgcpsC4gPPAejOgXEsP3AGV0Y2wVvnTDpxyP9Tg.JQB03vk3NYcTNkYBmx8OIJkscOycQHi8SSuiDEdhJzHmnwuqUIOmImyUg-- Received: from [75.192.62.139] by web52108.mail.re2.yahoo.com via HTTP; Thu, 22 Nov 2007 10:28:44 PST Date: Thu, 22 Nov 2007 10:28:44 -0800 (PST) From: Steven Giammarino To: pim@ietf.org MIME-Version: 1.0 Message-ID: <304247.5525.qm@web52108.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [pim] Cisco Multicast Manager X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1685345614==" Errors-To: pim-bounces@ietf.org --===============1685345614== Content-Type: multipart/alternative; boundary="0-1972919192-1195756124=:5525" Content-Transfer-Encoding: 8bit --0-1972919192-1195756124=:5525 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Greetings, I'm currently using Cisco's Multicast Manager for some light troubleshooting on trading system networks. The product is very expensive and from my experience, this is more or less a last resort. I'm looking for some feedback perhaps, on some newer tools out there that can assist in troubleshooting MCAST drops, packet delay, besides Sniffer's. It seems like nothing beats the Cisco CLI at the moment. Thanks in advance, Steven Giammarino President www.FasT.am --------------------------------- Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. --0-1972919192-1195756124=:5525 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Greetings,
I'm currently using  Cisco's Multicast Manager for some light troubleshooting on trading system networks.
The product is very expensive and from my experience, this is more or less a last resort.
I'm looking for some feedback perhaps, on some newer tools out there that can assist in troubleshooting MCAST drops, packet delay, besides Sniffer's.
It seems like nothing beats the Cisco CLI at the moment.

Thanks in advance,

Steven Giammarino
President
www.FasT.am

Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. --0-1972919192-1195756124=:5525-- --===============1685345614== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --===============1685345614==-- From pim-bounces@ietf.org Fri Nov 23 13:26:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvdET-0000t1-41; Fri, 23 Nov 2007 13:26:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvVF7-0003WO-J6 for pim@ietf.org; Fri, 23 Nov 2007 04:54:37 -0500 Received: from web36201.mail.mud.yahoo.com ([209.191.68.227]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvVF3-0002H3-BM for pim@ietf.org; Fri, 23 Nov 2007 04:54:37 -0500 Received: (qmail 2608 invoked by uid 60001); 23 Nov 2007 09:54:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=gKmwHQfxRrCSdgCIm8rjsK6v6LAZMsfRw0VQYViQijrJNZ+LO0lt5yc/ANNRj4+a30/OXXO9kTySppt3S0GkQA6GKyVTsbxRB+91Iu1ondG38+dc8R0eK/vEd0DKVJt9HigG0AzytlLubtM0QWw6gQvnLZZm/pqlHa87QW3g6sk=; X-YMail-OSG: vQHx.dEVM1ksh8gUlMCFj_0niY0WndAQsqnBveV9w_SnQg9JZpfzUJ.R9sflNyIBAabLi1l2uOrZwZj3gDhHSomz3L1L.IkBeWtsY96nMwrkPAJJhrs- Received: from [210.210.108.194] by web36201.mail.mud.yahoo.com via HTTP; Fri, 23 Nov 2007 01:54:32 PST Date: Fri, 23 Nov 2007 01:54:32 -0800 (PST) From: Satyanarayana Dillikar To: pim@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <820973.2109.qm@web36201.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Fri, 23 Nov 2007 13:26:27 -0500 Subject: [pim] PIMDM questions X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org 1) PIMDM uses State Refresh Message every 60secs. For large number of (S, G) (say 1024) , there will be a flood of PIMDM control packets in the pim domain. Instead the State Refresh Message Format should have allowed to club multiple (S, G)'s in a single State Refresh Message. This will reduce the control traffic but also has the effect of multiply the loss of (S, G) State-Referesh state. What is the rationale behind having one (S, G) in “RFC3973 Section 4.7.10. State Refresh Message Format” 2) PIMDM does not use the concept of DR-election. RFC3973 does not suggest using DR-Priority option in PIM-Hello packets (see RFC3973 Section 4.7.5. Hello Message Format). I think by using DR concept we can reduce the number of PIM Assert Messages on multi-access LANs when working with large number of (S,G) entires. Is there any specific reason for not using DR-priority in PIMDM? Thanks Satya ____________________________________________________________________________________ Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Sat Nov 24 06:51:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtXb-0001JS-43; Sat, 24 Nov 2007 06:51:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtXZ-0001C6-9w; Sat, 24 Nov 2007 06:51:17 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvtXY-0001mr-78; Sat, 24 Nov 2007 06:51:17 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm3947481e08; Sat, 24 Nov 2007 20:04:14 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm624741a992; Mon, 19 Nov 2007 22:00:54 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 22:00:54 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6Ob-0005wC-BP; Mon, 19 Nov 2007 08:10:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6OY-0005vr-3f; Mon, 19 Nov 2007 08:10:34 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu6OV-0007jr-UT; Mon, 19 Nov 2007 08:10:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E13D6328B6; Mon, 19 Nov 2007 13:10:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu6O1-0004Fm-Qr; Mon, 19 Nov 2007 08:10:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 08:10:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: pim@ietf.org Subject: [pim] I-D Action:draft-ietf-pim-sm-linklocal-02.txt X-BeenThere: pim@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Authentication and Confidentiality in PIM-SM Link-local Messages Author(s) : J. Atwood Filename : draft-ietf-pim-sm-linklocal-02.txt Pages : 25 Date : 2007-11-18 RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link local messages using the IP security (IPsec) Authentication Header (AH) or Encapsulating Security Payload (ESP). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, an optional automated group key management mechanism is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-linklocal-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pim-sm-linklocal-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pim-sm-linklocal-02.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: <2007-11-19080112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-sm-linklocal-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-sm-linklocal-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19080112.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From pim-bounces@ietf.org Sat Nov 24 07:57:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvuZM-0007jm-5A; Sat, 24 Nov 2007 07:57:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvuZL-0007jg-2H for pim@ietf.org; Sat, 24 Nov 2007 07:57:11 -0500 Received: from chip8og58.obsmtp.com ([64.18.15.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvuZI-0001SQ-J0 for pim@ietf.org; Sat, 24 Nov 2007 07:57:11 -0500 Received: from source ([151.190.254.200]) by chip8ob58.postini.com ([64.18.7.12]) with SMTP; Sat, 24 Nov 2007 04:57:05 PST Received: from fwdefsmtp2.de.ittind.com ([10.32.77.203]) by ittsmtp1 with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 07:57:30 -0500 Received: from njbridge01.avionics.de.ittind.com ([10.37.1.77]) by fwdefsmtp2.de.ittind.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Nov 2007 07:57:05 -0500 Received: from ACDNJMAILSRV03.acd.de.ittind.com ([10.37.1.152]) by njbridge01.avionics.de.ittind.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 07:57:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [pim] PIMDM questions Date: Sat, 24 Nov 2007 07:57:04 -0500 Message-ID: In-Reply-To: <820973.2109.qm@web36201.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pim] PIMDM questions Thread-Index: Acgt/ofiZzOsPwLjSvqwJhyxLOM83gAl/n6w References: <820973.2109.qm@web36201.mail.mud.yahoo.com> From: "Nicholas, Jonathan - ACD " To: "Satyanarayana Dillikar" , X-OriginalArrivalTime: 24 Nov 2007 12:57:04.0666 (UTC) FILETIME=[833BAFA0:01C82E99] X-Spam-Score: -4.0 (----) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org 1) No particularly good reason. There didn't seem to be a large need, and the there was a certain desire to remain compatible with existing implementations based on an earlier internet draft for State Refresh. 2) Use of DR Priority rather than Asserts could easily lead to erroneous behavior. Imagine a LAN with two or more PIM-DM routers. One is selected as the DR and the other is not. If we suppose a source behind the non-DR router begins originating traffic, then the DR will not be an upstream router for that data flow, but could easily be an upstream router for other data flows. Asserts MUST be based on source. Even within PIM-SM, DRs are for selecting a tunnel agent, not for resolving tree distribution mechanisms. Asserts are used to resolve tree distribution issues. Jonathan Nicholas > -----Original Message----- > From: Satyanarayana Dillikar [mailto:dsatya6@yahoo.com]=20 > Sent: Friday, November 23, 2007 4:55 AM > To: pim@ietf.org > Subject: [pim] PIMDM questions >=20 > 1) PIMDM uses State Refresh Message every 60secs. For large=20 > number of (S, G) (say 1024) , there will be a flood of PIMDM=20 > control packets in the pim domain. > Instead the State Refresh Message Format should have allowed=20 > to club multiple (S, G)'s in a single State Refresh Message.=20 > This will reduce the control traffic but also has the effect=20 > of multiply the loss of (S, G) State-Referesh state. What is=20 > the rationale behind having one (S, G) in "RFC3973 Section=20 > 4.7.10. State Refresh Message Format" >=20 >=20 > 2) PIMDM does not use the concept of DR-election. > RFC3973 does not suggest using DR-Priority option in=20 > PIM-Hello packets (see RFC3973 Section 4.7.5. Hello Message=20 > Format). I think by using DR concept we can reduce the number=20 > of PIM Assert Messages on multi-access LANs when working with=20 > large number of > (S,G) entires. Is there any specific reason for not using=20 > DR-priority in PIMDM? >=20 >=20 > Thanks > Satya >=20 >=20 >=20 > =20 > ______________________________________________________________ > ______________________ > Get easy, one-click access to your favorites.=20 > Make Yahoo! your homepage. > http://www.yahoo.com/r/hs=20 >=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim >=20 ***************************************************************** This e-mail and any files transmitted with it may be proprietary = and are intended solely for the use of the individual or entity to = whom they are addressed. If you have received this e-mail in = error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author = and do not necessarily represent those of ITT Corporation. The = recipient should check this e-mail and any attachments for the = presence of viruses. ITT accepts no liability for any damage = caused by any virus transmitted by this e-mail. ******************************************************************* =0D _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Sat Nov 24 09:22:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivvu1-0000l0-GB; Sat, 24 Nov 2007 09:22:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivvu0-0000ig-2N; Sat, 24 Nov 2007 09:22:36 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ivvtz-0006v9-1r; Sat, 24 Nov 2007 09:22:35 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm8f47483eca; Sat, 24 Nov 2007 22:35:31 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmac474356f5; Wed, 21 Nov 2007 04:35:00 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 21 Nov 2007 04:35:00 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZUv-0000yi-H4; Tue, 20 Nov 2007 15:15:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZUs-0000xX-BA; Tue, 20 Nov 2007 15:15:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuZUr-0000q0-Vv; Tue, 20 Nov 2007 15:15:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id D38252AC5E; Tue, 20 Nov 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuZUr-0006D5-JT; Tue, 20 Nov 2007 15:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Nov 2007 15:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: pim@ietf.org Subject: [pim] I-D ACTION:draft-ietf-pim-rpf-vector-05.txt X-BeenThere: pim@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : The RPF Vector TLV Author(s) : I. Wijnands, et al. Filename : draft-ietf-pim-rpf-vector-05.txt Pages : 10 Date : 2007-11-20 This document describes a use of the PIM Join Attribute as defined in draft-ietf-pim-join-attributes [I-D.ietf-pim-join-attributes] which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-rpf-vector-05.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-rpf-vector-05.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-rpf-vector-05.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: <2007-11-20141516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-rpf-vector-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-rpf-vector-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-20141516.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim --NextPart-- From rafael_lopez@netdoor.com Sun Nov 25 11:13:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwK70-00078k-A0 for pim-archive@lists.ietf.org; Sun, 25 Nov 2007 11:13:38 -0500 Received: from [190.42.235.225] (helo=ayirh) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwK6w-00008w-Km for pim-archive@lists.ietf.org; Sun, 25 Nov 2007 11:13:38 -0500 Received: from ilug ([159.217.204.90]) by ayirh with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Nov 2007 11:13:32 -0500 Message-ID: <002701c82f7e$1f8e8dc0$5accd99f@ilug> From: To: Subject: Got your fill of turkey this weekend? Date: Sun, 25 Nov 2007 11:13:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Score: 3.3 (+++) X-Scan-Signature: d6b246023072368de71562c0ab503126 E T G u Bails Out Hotels In Energy Crisis The top five reasons to Grab eTGU: 1. Energy problems are a Global issue 2. Companies are seeking their own solutions to reducing energy costs to save their business. 3. With results as high as 30% savings in energy bills, SensorStat is a solution that many business will be turning to. 4. One facility after another is boasting the huge savings et g U's SensorStat has brought to their business. 5. Huge media coverage on Et gu next week will draw attention from investors and brokers alike. e tG u has been doing heavy trading all week. During the Holiday Market makers are pushed the price down and grabbed huge blocks of shares in anticipation of the coming weeks trading. Move fast on Monday and get in before this continues to rise. From selena@calamuchitanet.com.ar Mon Nov 26 00:07:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwWC7-0004AE-Bw for pim-archive@lists.ietf.org; Mon, 26 Nov 2007 00:07:43 -0500 Received: from [122.167.159.244] (helo=ABTS-KK-Dynamic-244.159.167.122.airtelbroadband.in) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwWC3-00029L-I7 for pim-archive@lists.ietf.org; Mon, 26 Nov 2007 00:07:43 -0500 Received: from [132.192.91.177] (helo=bryaa) by ABTS-KK-Dynamic-244.159.167.122.airtelbroadband.in with smtp (Exim 4.62 (FreeBSD)) id 1J/WDL-0006Jc-Gy; Mon, 26 Nov 2007 10:38:59 +0530 Message-ID: <001301c82fea$410839d0$b15bc084@bryaa> From: To: Subject: Is there anymore stuffing Date: Mon, 26 Nov 2007 10:37:33 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 World Seeks Energy Solutions, E t Gu Investors Pile In The top 5 Things you should be considering over the holiday: 1. Global and domestic energy problems are rampant and taking their toll on businesses worldwide. 2. Governments are yet to provide real relief forcing business to find solutions themselves. 3. EnerBrite (E T Gu) provides real solutions to energy costs, reducing them as much as 30%. 4. Already, Hotels like Radisson and Clarion are boasting ETG u's solution helps them meet the challenge of energy in today's market. 5. E Tg U is launching a huge media campaign to increase investor awareness next week. The past week has been an absolute frenzy on E t Gu. Trading has gone through the roof and Market Makers have been buying up large blocks to take control of the trading next week. Act fast on Monday and get in on the action expected next week. From pim-bounces@ietf.org Tue Nov 27 03:31:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwvr9-0007yu-VS; Tue, 27 Nov 2007 03:31:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwvr8-0007yc-Bz for pim@ietf.org; Tue, 27 Nov 2007 03:31:46 -0500 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwvr7-0002Lh-Tk for pim@ietf.org; Tue, 27 Nov 2007 03:31:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 1C25F2BB17E; Tue, 27 Nov 2007 09:31:41 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24626-01-42; Tue, 27 Nov 2007 09:31:40 +0100 (CET) Received: from [IPv6?2001?700?1?0?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:0:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id E77A92BB172; Tue, 27 Nov 2007 09:31:40 +0100 (CET) Message-ID: <474BD5EC.2040401@uninett.no> Date: Tue, 27 Nov 2007 09:31:40 +0100 From: Stig Venaas User-Agent: Thunderbird 2.0.0.6 (X11/20070910) MIME-Version: 1.0 To: "Archana J Patel (archanap)" Subject: Re: [pim] A new draft on "PIM GR Enhancement for BSR, PIM-Bidir and PIM-SM" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: pim@ietf.org X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org Archana J Patel (archanap) wrote: [...] >>>2. The Group-RP Mapping expiry timer avoids the Non-BSR router > purging its RP-Set after it receives an empty BSM >>from the rebooted > BSR router. > Group-RP mapping expiry timer is used, if Non-BSR router is receiving > empty BSM but consider the case where Rebooted BSR router > has received one CRP-Adv message and BSM has sent with one Group-to-RP > mapping. Non-BSR routers will cleared all other > remaining group-to-rp mappings. The new BSR spec solves this IMO. When the BSR sends an empty BSM, it will trigger the C-RPs to send advertisements. The BSR is supposed to wait until it has had time to receive all the triggered advertisements before it sends a non-empty BSM. Stig > Thanks, > Archana _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim From pim-bounces@ietf.org Thu Nov 29 05:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgiY-0007wo-CL; Thu, 29 Nov 2007 05:34:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgiW-0007wT-Mu for pim@ietf.org; Thu, 29 Nov 2007 05:34:00 -0500 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxgiW-0004Oi-8M for pim@ietf.org; Thu, 29 Nov 2007 05:34:00 -0500 Received: by wa-out-1112.google.com with SMTP id k40so3034489wah for ; Thu, 29 Nov 2007 02:33:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=eKPSBZSZOtuiNiFNGaBHo/J5CbD6K3CGphMVELTODqM=; b=x921UqPE6mcYUQbR6qduFBTqU/I68XBwF1fOPj3tUpdGqdF7IDqffcn4MSCatobO0j7iLa6/KORYEy5wcCxSiQwJrjmIsRjuuuCArle9X2VQF76kLvI28zt4dE+LtZIUPo5UsttoULBThKyvBxG5ZftMYLq12++k1QwWdaqcCfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=lYrzjSrhSb2bF4gmhDKa+5JY9Xo9t94BaFr2oftuWPYEEzs9OyACPt/jZrSFwPrVy9okg80/PclkR+vTTZr4YSI1XZJ92emkIIHPnWFICqwAoVHzXFTE7OQW/sxHZ4fog/j+1rl1fnoJgYS3jJSiBxDrCPZ+sFvFZDaVSTTFRAw= Received: by 10.114.106.1 with SMTP id e1mr1118928wac.1196332437568; Thu, 29 Nov 2007 02:33:57 -0800 (PST) Received: by 10.114.38.18 with HTTP; Thu, 29 Nov 2007 02:33:57 -0800 (PST) Message-ID: Date: Thu, 29 Nov 2007 16:03:57 +0530 From: "Krishna Mohan" To: pim@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [pim] Query on PIMDM repeated Flooding/Pruning X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pim-bounces@ietf.org This is regarding the flood and prune behavior in PIM-DM [RFC3973]. I am actually thinking of ways to reduce this flood and prune behavior in networks that are not State Refresh capable. I am assuming the following: > Timer Name: Prune Timer (PT(S,G,I)) - From message (Default: 60 secs) > Timer Name: Prune Limit Timer (PLT(S,G)) - Default: 210 secs Consider the following scenario: +------+ +------+ | | | | Source --+ R1 +-----+ R2 | | | | | +------+ +------+ R2 doesn't have any neighbors/listeners and R2 Prunes its Upstream interface by setting the PLT for 210 secs. Upon Prune reception, R1 Prunes its Downstream interface by setting the PT for (3*60=180) secs. R1's PT expires and R1 resorts to flooding again until subsequently Pruned again by R2 (which it does after its PLT expiry i.e., after 30 secs). As per my understanding, the drawback here is that unwanted traffic floods the network unnecessarily for 30 secs and this is repeated every 180 secs. Below is one probable solution that I can think of here to tackle this(minimize the repeated flooding/pruning): 1. Reduce the interval of PLT(S,G) to make it less that PT(S,G,I). (or) Increase the interval of PT(S,G,I) so that it is greater than PLT(S,G), which means increasing the Prune Holdtime. 2. Upon PLT(S,G) expiry, if no downstream listeners are present, Send a Prune immediately. If this is done, R2's PLT expires much before than R1's PT so that R2 sends a Prune. Did I miss any point here that it can't be done? But one problem that I can see with this is the age-out of entries. Also, Is there any rationale behind the default value of 210 secs for PLT(S,G) and 60 secs for Prune Holdtime? Any comments on this are welcome. Thanks & Regards, Krish... _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim