Re: [pim] anycast-rp with pim (rfc4610) when an RP reboots
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pim] anycast-rp with pim (rfc4610) when an RP reboots



Hi Pekka,

Actually point 3 & 4 are interrelated. In practice, since SPT threshold
is configured as zero therefore recv should switch to SG (SPT).
Otherwise, I agree there would be a black hole for ~ 2 min.

In case where RP is also a DR, RP needs to originated register/reg-stop
mesg. 

 
Regards,
Prashant Jhingran

 
-----Original Message-----
From: Pekka Savola [mailto:pekkas at netcore.fi] 
Sent: Thursday, October 15, 2009 4:56 PM
To: Prashant Jhingran (pjhingra)
Cc: pavan_kurapati; Srimanikandan Ganesan; pim at ietf.org
Subject: Re: [pim] anycast-rp with pim (rfc4610) when an RP reboots

On Wed, 14 Oct 2009, Prashant Jhingran (pjhingra) wrote:
> - As long as RP_2 remains down there would not be an issue
> - However once RP_2 becomes operational then with the help of NULL 
> Registers (default every 60 sec or so), the black hole should get 
> patched up in < 2 mins
> - Also note that black hole would be created for only new/upcoming 
> receivers i.e. those behind RP_2 during this transient time
> - Recv behind RP_2 which would have ideally switched to SG would 
> remain unaffected.

Good points, thanks for summarizing.  However, I'm not sure if I see the
third point.  I see this is the case if the receiver had switched to SG
but otherwise..?

Another thing I noted is that if there are sources directly connected to
an RP, with anycast-RP using PIM it's not enough to copy/replicate
received register messages to other to the rest of the RP set.  In this
case, you will need to create register messages yourself.  In some
vendors' equipment this may be an issue and it might be interesting to
see if all the anycast-rp+pim implementations handle this correctly.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.