Subject: RE: [pim] Question on Join Request

From: "David McWalter" <[email-masked]>
Date: Fri, 28 Oct 2005 17:18:44 +0100

PIM doesn't do that.
 
Just electing a different DR for each G would add state and complexity.  For your suggestion, we'd need to run these elections dynamically on unicast routing changes.
 
Look at the benefit and the cost.  I think the authors made a good choice here.
DMcW.
 
-----Original Message-----
From: vikram pim [mailto:[email-masked]]
Sent: 28 October 2005 16:33
To: David McWalter
Cc: [email-masked]; Christopher Thomas Brown
Subject: RE: [pim] Question on Join Request

HI David
 
The case I was mentioning is not the data path but the control path issue in that, R2 is still representing the mcast routers on the LAN segment towards R6 via R1. Theoretically R1 could start representing the group. 
 
Thanx
vikram
 
David McWalter <[email-masked]> wrote: 

Hi Vikram.
 
It is possible for R2 to know about it.  PIM relies on unicast routing on R2 working this out.
 
When the unicast route from R5 to RP(G) fails, R2 remains the DR.  Unicast routing on R2 works out that the route to RP(G) from R2 is now via R1.  R2 sends Prune(*,G) to R5 and Join(*,G) to R1.  R1 joins towards RP(G).  (*,G) traffic then reaches the receiver via R1.
 
There's no need to change the DR to achieve this.
 
The PIM-SM draft says it like this:
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-11.txt
Section 4.1.3:
 The last RPF neighbor towards the RP is stored because if the MRIB
changes then the RPF neighbor towards the RP may change.  If it does so,
then we need to trigger a new Join(*,G) to the new upstream neighbor and
a Prune(*,G) to the old upstream neighbor.
 
Hope that helps.
David McWalter.
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of vikram pim
Sent: 28 October 2005 02:46
To: Christopher Thomas Brown
Cc: [email-masked]
Subject: Re: [pim] Question on Join Request

Hi Chris,
 
I was wondering if it is possible for the R2 and R1 to decipher that R1 should be taking over as the DR for the RP in this particular PIM domain? or atleast R2 knowing about it?
 
Thanx
vikram

Christopher Thomas Brown <[email-masked]> wrote:

On Thu, 2005-10-27 at 15:11 -0700, vikram pim wrote:
> Hi Gurus,
> 
> In Diag2 below, However if R5 goes down and R6 is now the router used
> to reach RP/Source for (*,G) and (S,G).
> R2 would use R1 to reach R6 for joins and the path is pretty
> sub-optimal. Is there a way for R1 to somehow detect this and take
> over the DR ship because implicitly it is behaving as a DR. 

No, nothing in the protocol provides for detecting this.

Chris

> Diag 2 
> RP (*,G)
> 
> R5 X R6
> | |
> | |
> R2 * R1
> | 1 | 1
> | |
> &n! bsp; --------------------
> |
> |
> H1
> 
> Cheers,
> vikram
> 
> ______________________________________________________________________
> Yahoo! FareChase - Search multiple travel sit! es in one click. 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pim

  _____  

Yahoo!  <http://us.lrd.yahoo.com/_ylc=X3oDMTFqODRtdXQ4BF9TAzMyOTc1MDIEX3MDOTY2ODgxNjkEcG9zAzEEc2VjA21haWwtZm9vdGVyBHNsawNmYw--/SIG=110oav78o/**http%3a//farechase.yahoo.com/> FareChase - Search multiple travel sites in one click. 

  _____  

Yahoo!  <http://us.lrd.yahoo.com/_ylc=X3oDMTFqODRtdXQ4BF9TAzMyOTc1MDIEX3MDOTY2ODgxNjkEcG9zAzEEc2VjA21haWwtZm9vdGVyBHNsawNmYw--/SIG=110oav78o/**http%3a//farechase.yahoo.com/> FareChase - Search multiple travel sites in one click. 
_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim